AWS CloudFormationのスタックを分割する際の基準についてまとめる。

公式の記述

CFnの公式Docでは、以下のような基準が提案されている。

AWS リソースのライフサイクルと所有権を使用して、各スタックでどのリソースを使うを判断します。最初はすべてのリソースを 1 つのスタックに置いてもかまいませんが、スタックの規模が大きくなり範囲が拡大するにつれて、単一のスタックの管理は面倒で時間かかる場合があります。共通のライフサイクルと所有権を持つリソースのグループ化により、所有者は独自のプロセスやスケジュールを使用して、他のリソースに影響を与えることなくリソースのセットを変更できます。

多層アーキテクチャーは、スタックを積み上げて構築する複数の水平の層に整理します。各層はその直下の層に依存します。各層には 1 つ以上のスタックを持つことができますが、各層のスタックは類似したライフサイクルと所有権を持つ AWS リソースを持つ必要があります。

サービス指向アーキテクチャーを使用すると、業務上の大きな問題を処理しやすい大きさに整理できます。これらのパートはそれぞれ、明確に定義された目的があり、機能の自己充足単位を表します。これらのサービスを、それぞれ独自のライフサイクルと所有者があるスタックにマッピングできます。これらのサービス (スタック) を 1 つに繋いで、相互に通信するようにできます。

CDKの公式Docでは、以下のような基準が提案されている。

アプリケーションが必要とするスタックの数には、ハードかつ高速なルールはありません。通常、デプロイパターンに基づいて決定します。次のガイドラインに注意してください。

• 通常、できるだけ多くのリソースを同じスタックに保持する方が簡単です。したがって、分離したいことがわかっていない限り、リソースをまとめておきます。
• ステートフルリソース (データベースなど) は、ステートレスリソースとは別のスタックに保存することを検討してください。その後、ステートフルスタックで終了保護を有効にできます。これにより、データ損失のリスクなしに、ステートレススタックの複数のコピーを自由に破棄または作成できます。
• ステートフルリソースは、コンストラクトの名前変更の影響を受けやすくなります。名前を変更すると、リソースが置き換えられます。したがって、移動または名前が変更される可能性が高いコンストラクト内にステートフルリソースをネストしないでください (キャッシュのように状態が失われた場合に状態を再構築できない場合を除く）。これは、ステートフルリソースを独自のスタックに配置する別の良い理由です。

整理

スタック分割に正解はない。

楽して手早くリソースを立ち上げたいのであれば、分離したい理由がないのであれば、スタックを1つにまとめてしまえば良い。

しかし、Softwareと同様にInfrastructureも生ものだ。

要求や状況が変われば、変更が発生する。その際に、スタックを分割していないと、変更の影響範囲を限定できない。本当に分離したい理由がないのか、一考の余地がある。

スタックをどのように分割するかによって、ソフトなInfrastructureになるのか、ハードなInfrastructureになるのかが決まる。

キーワードは公式Docの記述のとおり「ライフサイクルと所有権」「ステートフルリソース」である。

• ライフサイクルと所有権
  • 管理するチームやプロセスが異なるリソースを分割する
• ステートフルリソース
  • データベースなどの状態を持つリソースは分割する

マイクロサービスであったり、更新タイミングが異なる多層アーキテクチャの各レイヤーは、個別にデプロイできると望ましい。 特にリソース群を管理するチームが異なる場合、スタックを分割することで、チーム間の不要なコミュニケーションコストを減らすことができるはずだ。

また、データベースなどのステートフルリソースは、アプリケーションサーバーなどのステートレスリソースとは別のスタックに保存したうえで終了保護することで、更新時のデータ損失リスクを軽減できる。