← AWSサービスの内部原理 コース
116. CloudFormationは『あるべき状態』を書く言語である — テンプレート(宣言)とスタック(実体)の分離
手作業やスクリプトが「この順でこのAPIを呼べ」と手順を書くのに対し、CloudFormationは「何が欲しいか」だけを書く——その宣言と実体がエンジンでどうつながるのかを、図で追っていきます。
① 命令的 vs 宣言的
命令的モデル手作業・スクリプト
「この順でこのAPIを呼べ」と手順を書く手順②
EC2作成APIを呼ぶ
手順③
instance-idを控える順序・依存を人間が管理
対比
EIP関連付けAPI控えたIDを渡して呼ぶ
結果だけ書く
宣言的モデルCloudFormation
「あるべき状態」だけを書くEC2が1台+EIPが1つ両者が関連付いている状態
手順は書かない- CloudFormationは「何が欲しいか(desired state)」を受け取り、「どう作るか(API呼び出しの列とその順序)」はエンジン側が導出する。これが宣言的(declarative)の定義そのもの
- 「EC2+EIPを関連付ける」は公式ドキュメントの複数リソーステンプレート例そのもの。テンプレートでは !Ref で参照を書くだけで、関連付けの手順は書かない
命令的モデルは「どう作るか」を人間が書く。宣言的モデルは「何が欲しいか」だけ書き、手順の導出をエンジンに委ねる——CloudFormationは後者である。
② テンプレート・エンジン・スタック
テンプレートYAML/JSONのテキスト
宣言=設計図(blueprint)プロビジョニング
CFnエンジンテンプレートを読み必要なAWS APIを呼ぶ
スタックテンプレート通りに作られた実体
例: 動いているEC2インスタンス- テンプレートは「YAML or JSON formatted text file」で、拡張子は .yaml .json .template .txt など任意。公式は「CloudFormation uses these templates as blueprints for building your AWS resources」と定義
- テンプレートに書けるプロパティの公式例: EC2のインスタンスタイプ・AMI ID・キーペア名・ブロックデバイスマッピング(値の例: t2.micro / ami-0ff8a91507f77f867)
- 人が触る概念はテンプレートとスタックの2つだけ(公式: you work with templates and stacks)。テンプレートはテキスト(設計図)、スタックは実体(作られたモノ)——この分離が編全体の土台
テンプレート=あるべき状態を書いたテキスト、スタック=それを元にエンジンが作った実体。人が書くのはテキストだけで、実体はエンジンが生む。
③ t2.microと書くと何が起きるか
テンプレートの1行InstanceType: t2.micro
実行
API呼び出しを導出EC2 create instance APIを呼ぶ
引数: instance type = t2.micro実体t2.microのEC2インスタンスが起動
- 公式: The calls that CloudFormation makes are all declared by your template — エンジンが呼ぶAPIはすべてテンプレートによって宣言されている
- 公式の言い回し: t2.microと書いたテンプレートでスタックを作ると、CloudFormationはEC2のcreate instance APIを instance type=t2.micro で呼ぶ
- Step Functions編で見た「宣言(ASL)と実体(実行)の分離」のインフラ版。SQLが「何が欲しいか」だけを書きクエリプランナーが「どう取るか」を決めるのと同じ構図
テンプレートのプロパティ1つ1つが、エンジンが呼ぶAPIの引数に翻訳される。宣言的モデルの正体は「宣言→API呼び出し列」への自動翻訳である。
④ スタックは1単位
1枚のテンプレートELB+ASG+RDSを記述
delete stack(1回の操作)
ELBロードバランサー
ASGAuto Scaling Group
横並び=スタックとして1単位RDSDBインスタンス
まとめて消える3つのリソースが一括で削除される
- 公式の例そのまま: Auto Scalingグループ・Elastic Load Balancingのロードバランサー・RDSデータベースインスタンスを含むテンプレートからスタックを作ると、CloudFormationがそれら全部をプロビジョニングする(ロードバランサーの種類は指定されていない)
- 公式: create, update, and delete a collection of resources by creating, updating, and deleting stacks — コレクションの操作がスタックの操作に一本化される
- コンテナ編のECSサービス(desired stateを宣言するとスケジューラが現実を合わせる)と同族。この編では「あるべき状態への収束」をインフラ全体へ広げていく
スタックは関連リソースを1単位に束ねる。ロードバランサー+ASG+RDSを1回の操作で作り、1回の操作で消せる——管理の粒度がリソースではなくスタックになる。
⑤ 事前検証と自動ロールバック
create stack
検証成功
事前検証プロパティ構文エラー・リソース名の衝突を検査
失敗→操作を停止。リソースを1つも作らない結果は2つに1つ
プロビジョニングリソースを順に作る
全部成功スタック作成完了
自動ロールバック作成済みリソースを削除して元に戻す
途中失敗でも中途半端な状態を残さない- 事前検証は Create Stack / Update Stack / Create Change Set のすべてで自動実行される
- 検証失敗時の公式: the operation stops before any resources are created
- ロールバックの公式: If stack creation fails, CloudFormation rolls back your changes by deleting the resources that it created
- DynamoDB編・メッセージング編で繰り返したAll-or-Nothing(原子性)をインフラ構築に持ち込んだもの——作れるなら全部、無理なら何もなかったことに
事前検証は「作る前」に構文・名前衝突で止め、ロールバックは「作った後の失敗」で作った分を消す。宣言した状態か、元の状態か——中間の壊れた状態を残さない。
⑥ テンプレートはS3の住人
手元のテンプレート./template.yaml
ローカルのテキストファイルS3に置かれた状態で
S3へ自動アップロードアカウント内のS3バケットへ
リージョンごとに作成/既にあればそこへ追加スタック作成が進むプロビジョニング開始
- 公式: If you specify a template file stored locally, CloudFormation uploads it to an S3 bucket in your AWS account
- バケットはリージョンごとに作られ、既存なら再利用される。自前のバケットに手で置いてS3 URLを指定してもよい
- S3編で見たオブジェクトストレージが、ここでテンプレートの置き場として顔を出す——宣言の実体もまた、どこかのストレージに住んでいる
「テキストファイル」であるテンプレートも、実行時にはS3上のオブジェクトになる。以後の全レッスンは、この「宣言(テンプレート)と実体(スタック)のずれを、エンジンがどう埋めるか」の各論である。