[ゼロから始めるInfrastructure as Code] 第5回 CloudFormationのベストプラクティス

大項目としてテンプレート作成・スタック作成・運用があり、それぞれにベストプラクティスを作成しています。 （このあたりの枠組みはAWSと一緒ですね）

• テンプレート作成
  • 汎用性を意識する
  • なるべく「処理」を記述しない
  • 組み込み関数を活用する
• スタック作成
  • ライフサイクル毎にリソースをまとめる
  • 環境ごとに共通のテンプレートを使用する
  • クロススタック参照等を活用する
• 運用
  • バージョン管理ツールを使用する
  • 必ずCloudFormation経由でリソースを更新する
  • driftを検知する
  • 更新前に変更セットを作成する

テンプレートを作成する際は、汎用性を意識しています。 汎用性を高めることで、モジュールとして再利用が可能になります。 モジュールとは「テンプレートに含めるリソース構成をパッケージ化すること」、つまり、予め使いやすい状態で部品を用意しておくこと、です。 モジュールを使い回すことで、設定値を統一出来たり、全体のコード量を減らすことが出来ます。

社内のポリシーに合わせてモジュールを作っておくのも良いですし、AWSもレジストリを用意しています。
※ AWS CloudFormation レジストリの使用: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry.html

CLoudFormationのメリットのうちの1つに、テンプレートを読むだけで現在の「状態」が分かる点が挙げられます。 このテンプレートに条件分岐などのプログラミング的「処理」を入れ込んでしまうと、可読性が著しく落ちてしまいます。 CloudFormationでもCondition句やFn::Ifなどの条件分岐機能はありますが、弊社内では可能な限り避けるようにしています。

複雑に条件分岐を実装したい場合は、いっそAWS CDKを使った方がいいかもしれません。

組み込み関数を活用することで、CLoudFormationの実装をグッと楽にできます。 弊社では参照系、操作系、その他と呼んでいて、特に参照系、操作系は覚えておきましょう。

• 参照系
  • Ref
  • Fn::GetAtt
  • Fn::ImportValue
  • Fn::Select
• 操作系
  • Fn::Sub
  • Fn::Join

ここまでの勉強会では触れませんでしたが、Fn::JoinはIAMポリシー作成時などでARNを指定する場面でよく使います。

スタック作成時、ライフサイクル毎にリソースをまとめましょう。 システムに対して、テンプレートの修正無しにリソースを追加・削除出来る事が理想です。 例えばスタックをNWレイヤー、バックエンドレイヤー、フロントエンドレイヤーのようにレイヤー分けする事で、リソース追加削除を自由にできます。

検証・本番環境では同じテンプレートを利用しましょう。 CFnを利用するメリットとして、同じテンプレートを用いれば必ず同じ状態を作れる = 検証・本番環境間での差異を無くせる点が挙げられます。 環境ごとにテンプレートを分けてしまうと、このメリットが失われてしまうのです。 Parametersセクションなどを活用して、パラメータを変えるだけで作り分けられることが理想です。

スタック作成の際、共有リソースについてはスタック跨ぎのパラメータ参照テクニックを利用しましょう。 上手く使う事で、テンプレートの分割や、レイヤー分けを簡単に出来ます。

• クロススタック参照
  • 同じネステッドスタック内であればコレ
  • Fn::ImportValueで利用する際はよく検討して使う
• ダイナミック参照
  • 別スタックから参照する際はこちらが無難

CloudFormationテンプレートを管理する際は、Github、CodeCommit等のバージョン管理ツールを利用しましょう。 これによって、コードの履歴だけでなく、リソースの更新履歴も残せるようになります。

CloudFormationでインフラを管理する場合、リソースの更新は必ずCLoudFormationベースで行いましょう。 手動で修正してしまうと、スタックの設定値と差異が発生し、修正できなくなる恐れがあります。

前述の通り、「更新は必ずCloudFormationを使う」とルールを定めても、うっかり手動で更新してしまう事はままあります。 CloudFormationでは、テンプレートと現環境の差異が発生した状態を「drift」と呼んでいます。 事故が起きても早めに検知出来るよう、drift検知の仕組みを実装しましょう。

CloudFormationのスタック更新には、通常の「更新」と「変更セットのデプロイ」の2種類あります。 変更セットとは、現在のテンプレートと新テンプレートの差異を確認する機能です。 変更セットを用いることで、スタックにどんな変更が加わるのかをデプロイ前に確認できます。 事故防止の為、必ず「変更セットのデプロイ」でスタックの更新を行いましょう。

以上が弊社でCloudFormationを扱う際にお話ししているベストプラクティスです。 AWS公式もしっかりした公式ドキュメントを出していますので、興味がある方はぜひ参照して下さい。

※ 参考URL: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/best-practices.html

「ゼロから始めるInfrastructure as Code」は、これにて終了です。 CloudFormaitonは私の一番好きなAWSサービスで、最初に「AWSってすごい！」と実感したサービスでもあります。 一連の記事で、少しでもCloudFormationに興味を持っていただけたら嬉しいです。 以上、クラウドエンジニアの濱田でした！