[アップデート] CloudFormation に”CONFIGURATION_COMPLETE”のイベントを追加、スタック作成が最大 40% 高速に

平木佳介

2024.03.13

こんにちは、AWS 事業本部の平木です！

今回 CloudFormation のアップデートによりスタック作成の速度が向上したようなのでブログにしました。

忙しい人向け

以下にアップデート内容をまとめてみました。

AWS CloudFormation のスタックの作成速度を最大 40% 改善
新しいスタックイベント「CONFIGURATION_COMPLETE」を導入
このイベントにより、リソースの作成後、構成適用と整合性チェック待ちの段階が明示される
CloudFormation がこのイベントを利用して、依存リソースの並列作成を開始できるようになり、スタック作成が高速化
ユーザーは必要に応じてこのイベントを活用し、整合性チェックが不要な場合にスタック作成を短縮できる

詳しく知りたい場合はこれ以降をお読みください。

何があったの？

今回のアップデートで起きたことを簡単に言うと、
CloudFormation におけるリソース作成のプロセスを見直し、リソースの安定化を待つ必要がない場合には次の作成プロセスを開始することでトータルのリソース作成時間を短縮できるようになりました。

アップデート内容を知る

CloudFormation のプロビジョニング時間に影響を与えるもの

まず初めに CloudFormation において、スタック作成のボタンを押してからステータスがCREATE_COMPLETEになるまでの時間に影響を与える要素を知る必要があります。

プロビジョニングの時間に影響を与えるものは以下です。

テンプレート情報の解析
リソースの作成（Creation）
リソースの安定化（Stabilization）
リソースの依存関係（明示的、暗黙的を含む）

これをふまえてアップデート前後でどうなったのかを見ていきます。

リソースの安定化（Stabilization）とは

ところでリソースの安定化（Stabilization）とはなんでしょうか。

調べてみました。

通常、AWS CLI やマネジメントコンソールでリソースを作成する場合、作成した直後からいきなり対象リソースにアクセスできるわけではありません。

EC2 であれば作成直後であればライフサイクル上ではpendingであり、
直後にいきなりアクセスはできず基本的にrunningになってからアクセスできます。
インスタンスのライフサイクル - Amazon Elastic Compute Cloud

また EC2 に限らず ECS なども同様でステータスActiveにならないと正常にアクセスできません。

しかし CloudFormation の場合、各リソースに対してDescribeInstancesなどの Describe 系 API を呼び出し続け、ステータスが Active になるまで作成完了のステータスとなりません。

CloudTrail で確認すると一部を切り出したものですが下記のようにcloudformation.amazonaws.com経由で参照系 API が叩かれているのが確認できます。

    "invokedBy": "cloudformation.amazonaws.com"
},
"eventTime": "2024-03-13T08:18:10Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "DescribeInstances",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "cloudformation.amazonaws.com",
"userAgent": "cloudformation.amazonaws.com",
"requestParameters": {
    "instancesSet": {
        "items": [
            {
                "instanceId": "i-xxxxxxxxxxxxxxxxx"
            }
        ]
    },

そのため CloudFormation では作成完了のCREATE_COMPLETEになったタイミングですぐにそのリソースにアクセスできるようになります。

この Describe 系 API を呼び出し続ける期間がリソースの安定化（Stabilization）のようです。

ちなみにこの安定化の検証が所定のタイムアウト期間内に完了しない場合は、CREATE_FAILEDとマークされロールバックされます。

このタイムアウト期間は AWS サービスごとに一意に定義されています。

今まで

本題に戻ります。

今までは、DependsOn による明示的な場合や暗黙的なものを含めてリソースごとに依存関係が存在する場合には、
リソースの作成（Creation）とそのリソースが安定化（Stabilization）するのを待ってから依存関係のある後続のリソース作成のプロセスが開始されていました。

イメージ図は下のような形です。

画像： How we sped up AWS CloudFormation deployments with optimistic stabilization | AWS DevOps Blog

上記の場合だと、ECR リポジトリが安定化してから ECS のタスク定義が作成開始され、依存関係のない ECS クラスターはすぐに作成開始されています。

リソースが安定するまで待つため、リソースが多ければ多いほどプロビジョニングの時間が非常に長くなります。

これから

今回のアップデートにより、リソースの作成（Creation）とリソースの安定化（Stabilization）の間に明確な境界線を設け、暗黙的な依存関係を持っている場合にはリソースの安定化を待たずに次のリソース作成のプロセスを開始するようになりました。
DependsOnを使用した明示的な依存関係の場合には、現在のところ今まで通り安定化を待ってからリソース作成が開始されます。

イメージ図は下のような形です。

画像： How we sped up AWS CloudFormation deployments with optimistic stabilization | AWS DevOps Blog

上記の場合、

ECR リポジトリのリソースの作成（Creation）直後に ECS タスク定義を実行
ECS のタスク定義の作成直後に ECS サービスの作成を開始

を行っているためトータルの時間が短縮されています。

また、もし ECS タスク定義が安定していないことで ECS サービスの作成が失敗してしまったとしても自動的に再試行されます。

画像： How we sped up AWS CloudFormation deployments with optimistic stabilization | AWS DevOps Blog

"CONFIGURATION_COMPLETE"イベントの追加

また今回の作成と安定化の明確な分離により、新しく"CONFIGURATION_COMPLETE"というイベントが追加されました。

例えば Nat Gateway を CloudFormation で作成してみましたが、

作成プロセスの開始①
安定化の確認開始②
作成完了③

という流れが見て取れます。

この②のとこでも気づいた方もいると思いますが、新しくCONFIGURATION_COMPLETEというイベントが追加されたことが分かります。

このイベントは AWS システム内だけでなくユーザーが直接利用することもできるため、例えば EventBridge で所定のリソース ID の安定化の検証開始をトリガーにして何かを実行するなんてこともできるんじゃないかなと思います。

参照

おわりに

今回は、CloudFormation に新規イベントが追加されスタック作成が早くなったアップデートを書きました。

いつも少し長いなと思っていたリソース作成が高速化されより一層使うモチベーションが上がってきましたね。

この記事がどなたかの役に立つと嬉しいです。

[アップデート] CloudFormation に”CONFIGURATION_COMPLETE”のイベントを追加、スタック作成が最大 40% 高速に

忙しい人向け

何があったの？