クラウド エンジニアブログ

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

2023年3月1日掲載

始めに

クラウドインテグレーション課 クラウドエンジニアの濱田です。 「ゼロから始めるInfrastructure as Code」シリーズ、最終回! これまででCloudFormationの基本的な文法について勉強してきました。 今回でベストプラクティスについて体系的に勉強して、CloudFormationをマスターしましょう。

という訳で、弊社が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ベースで行いましょう。 手動で修正してしまうと、スタックの設定値と差異が発生し、修正できなくなる恐れがあります。

[運用] driftを検知する

前述の通り、「更新は必ず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に興味を持っていただけたら嬉しいです。 以上、クラウドエンジニアの濱田でした!

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

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