Subscribed unsubscribe Subscribe Subscribe

AWSのCloudFormationのメリットについて

AWSを使う際の注意点ですが、ひとつあるとしたら、CloudFormationを使うことです。
これは同時にベスト・プラクティスでもあります。
※インフラに関する知識が少ない人が多い場合はElasticBeanstalkの使用をオススメします

Change setを使用することでjsonのdiffが実際どのような変更になるかより分かりやすくなりました。
New – Change Sets for AWS CloudFormation | AWS Blog

そこで、この機会にCloudFormationを使わない場合と使う場合の違いについてまとめてみます。

コンソールを使って自由にリソースを触る場合

  • ドキュメントと実態が一致しない
「ドキュメントはちゃんと更新されていないのですが、あります。」
「どうにか自動的に更新されるようにしたいのですが。。。」
  • ドキュメントを作成・更新する時間が必要
「まずは構成図の作成が必要ですね。」
「リソースを触ったら構成図に反映させるようにしておいてください」
「構成図の更新を忘れていました。。。」
  • 操作する人次第で、オペミスが発生する
「間違えてXXXを消してしまいました。。。。」
「Oh....」
  • AWSリソースの進化の過程が後任者に見えない
「なんで、これあるのでしょうか?」
「当時の開発者が今誰もいなくて、分かりませんが、多分〜〜じゃないでしょうか」
  • すべて消した場合はそれまで構築した手順が残って完璧でない限り、復活できない
「間違えてXXX消してしまいました。」
「残っている手順通りに復活させてみてください」
「手順通りやったらエラーになりました。。。。」
「一応できたのですが、以前を各種設定がまったく同じかは自信がありません。。。」
「再発防止策をお願い致します」
「再発防止策の作成に~日かかります。」
  • ごみリソースが大量に残る
「いろんなアプリケーションのものが混ざっていますね。タグで絞り込むしかないですね」
「タグ手入力だから、検索に引っかからない可能性もあるから、一応全部見てくださいね」
「インスタンス300個ありますね。。。」
  • 複数のアプリケーションが同一アカウントに混在する場合は見分けがつきにくい
「タグの付け方が微妙に違って、どれが何に使われているのか分かりません。。。」
  • 現状を把握するにはコンソールのポチポチして、関連しているリソースだけを見る
「ドキュメントは古いから、最新の状態はコンソール見てくださいね」
「リソースの数が多すぎて。。。。いえ、何でもないです。」
  • 誰がAWSリソースにどのような変更を加えようとしているか把握しずらい
「あれ、接続できなくなりましたね。」
「あ、すいません。NetworkACLのエントリ不要かなと思って消してしまいました。。」

AWS CloudFormationを使う場合

  • インフラのリビジョン管理ができる
「diffとChange Setのレビューをお願い致します」
「LGTM」
「プルリクマージしました」
「それでは実行します」
  • インフラの成長の過程が残る
「なんでこうなっているのでしょうか」
「リポジトリの履歴見れば分かりますよ。当時の開発者は誰も残っていませんが。」
  • ワンクリックで誰でも、既存のものと同じ構成のものが作れる
「本番のVPC、ウトウトしていたら消してしまいました。。。。」
「すぐ、CloudFormationでcreate stackしてください。」
  • NameやTagに統一され、一貫した名前を付けることができる
「Nameが統一されているので、どのリソースが何に使われているのかが分かりやすいですね」
「アプリケーション名をスタック名として、Nameに使用しているから、Nameを見ればどのアプリのものか分かりますね」
  • ゴミリソースができない
「ゴミリソースがないですね」
「CloudFormationで一貫して、運用しているから、リソースは荒れていないですよ」
「CloudFormationを使っているからこそ、ゴミに気付きやすいというのもありますね」
  • diff確認をするので、オペミスが発生しない
「誰が何を実行するかはプルリクとchange setを見ればよいので、間違えて消した等の事故が起きないようになっています」
  • diffが実行されるので、誰が何をするかだ一目瞭然
「誰が何を実行しようとしているかはGitHub見れば分かりますね」
「コンソールだと、CloudTrailかConfigで事後なので、事前に分かるのがいいですね」
  • 「なぜ」がコミットメッセージとして残る
「なるほど、そういう理由でこのリソースがあるのですね」
  • 全体の把握がjsonを見るだけで容易にできる
「ふむふむ。各アプリケーション毎にjsonが分かれていて、とても把握しやすいインフラですね」
「jsonが分かりづらければ、CloudFormation Designerで可視化してもよいかもしれません」
「jsonの方が分かりやすいですが、実態と一致した図にできるのがいいですね」
  • 開発環境を必要な時間帯だけ存在させることでAWS運用コストの半減
「CloudFormationを利用するとしないでは、コスト面はどうなのですか?」
「CloudFormationは無料です」
「CloudFormationによって、開発環境を勤務時間帯だけ存在させているので、月当たり20万削減できています」
「年間240万、10年で2400万コスト削減できます」
「そもそも開発環境はローカルでよくないですか?」
「そうですね、その場合は10年で4800万削減できますね」
  • ソースコードと同じようにインフラの管理していくことができます。
「インフラってソースのようにちゃんと管理しずらいですよね」
「ソースと同じようにGitHubで管理していますよ」

CloudFormation以外でAWSリソースを操作することはソースをgit管理せずに、直接本番で触っているようなものです。

DRYになる

「XXXXのCIDRが変わるらしいのですが、どうしましょう。」
「一箇所変えて、updateすれば全て変わりますよ。」
「手作業でしていた場合は1つ1つ変えていかないといけません。」
「オペミスももちろん発生すると思います。」