#cmdevio2016 (レポート: E-3) プロビジョニングの今 ーフルマネージド・サービスを目指してー

CM雪山部の渡辺です。 今日はハイシーズン真っ只中での開催になるDevelopers.IO 2016です。 イベント当日にトンボ帰りして、明日はゲレンデです。 なお、天候が荒れてきているため、帰れる可能性は限りなく低くなっています（T_T

本日は「プロビジョニングの今 ーフルマネージド・サービスを目指してー」というタイトルで、CloudFormation, Ansible, CodeDeploy についてセッションを行いました。 これらのプロビジョニング・サービス/ツールを使い、AutoScalingを組み合わせることによりフルマネージド・サービスを実現することができます。

どうしてフルマネージドを目指すのか？

講演でもしつこく話しましたが、どうしてフルマネージドを目指すかという思想が重要です。

何はともあれ、運用が楽になることに比重をおいて環境を設計すべきだと思います。

システムは作り上げることが目的ではありません。 システムを楽に運用することが出来なければ、無駄にコストがかかるだけでなく、エンドユーザへの対応やサービス改善などにも影響が出てしまうでしょう。 結果としてシステムの寿命を短くしてしまいます。

また、障害の検知やその対応、問題が発生した時の切り戻し、属人化や人的ミスの発生などを極力排除することが大切です。 かといって、予算は有限ですので、完璧なシステムを作ることは通常はできません。 限られた予算の中で、AWSのサービスをうまく活用し、運用しやすいシステムを作るべきだと考えます。 そして、できる限り安く（笑）

そして、自動化は運用しやすいシステムを構築する手段です。 時折、自動化が目的になってしまう残念なパターンがありますが、自動化はあくまで手段です（まあデザパタとかみたいな病気なんですが...）。

去年からそんなことを考えながら色々なシステムのAWS環境を構築してきました。 そのひとつの回答が、本日紹介したAutoScaling + CodeDeployによるフルマネージドサービスです。

ほとんどの障害はAutoScalingで検知できるため、AutoScalingによるサーバ再起動でシステムは復旧するでしょう。 システムはCodeDeployを活用することで、最小限の手順でデプロイできるようになります。 これはアップデートの敷居を低くすることに貢献するでしょう。 ゴールデンAMIを作成する手間から解放されることもポイントです。 そして、Elastic Beanstalkのような導入の敷居が高いこともありません。

スライド

AutoScaling + CodeDeploy構成の補足

本エントリーでは、スライドで紹介しているAutoScaling + CodeDeploy構成について補足します。

ネットワークレイヤはCloudFormationを利用

ネットワークレイヤは、CloudFormationを利用するのがベストでしょう（手動で組んでも問題ありません）。 よくある構成のテンプレートを作成しておけば、再利用もしやすくなります。 ただ、この辺りは多くのプロジェクトを回しているCM特有のメリットかも知れません。

cloud-initでAnsibleとgitをインストールする

AutoScalingの設定では、ゴールデンAMI（ミドルウェアやアプリケーションがインストール済みのインスタンスから作成されたイメージ: 起動するだけでサービスが利用可能となる）を用意しません。 AutoScalingで起動するインスタンスのAMIには素のAmazonLinuxを指定します。

cloud-initでAnsibleとgitをインストールします。 cloud-initですべてをやろうとするとメンテナンスコストが大変なので注意してください。

cloud-initでAnsibleを実行する

cloud-initの最後で、git (CodeCommit）からAnsibleの設定ファイルをpullし、ローカルでAnsibleを実行します。 Ansibleの実行は外部サーバからLifeCycleHookで行うこともできますが、ローカルでAnsibleを実行する方法がベストとの結論です。

CodeCommitを利用する理由は、適切な権限を与えたIAM RoleをEC2インスタンスに付与しておけばgithubへのパスワードなどを保たなくて済むからです。

CodeDeployでアプリケーションをデプロイする

cloud-initでAnsibleが実行され、サーバの準備ができたならば、CodeDeployによりアプリケーションがデプロイされます。

最後に

これまでAutoScalingを利用する場合、ゴールデンAMIを作成することが手間でした。 アプリケーションのアップデート毎にゴールデンAMIを作成するのは辛いのです。 CodeDeployを使うことで、アプリケーションのアップデートが独立します。 もちろん、障害発生時やスケールアウト時に新しくインスタンスが追加される場合、これまで説明した手順で新しいインスタンスが作成されます。

素のAMIからミドルウェアをインストールするまでの手順はAnsibleを利用せずに、ここはゴールデンAMIを作成しておくのも良いでしょう。 その方が起動時間は短縮できます。 とはいっても、いつでもゴールデンAMIを作成し直せるように構成管理はAnsibleで行っておくのが良いでしょう。

それでは、皆さんのラクチン運用に貢献できることを願って！