CloudFormation StackSetsの極致：並列デプロイを制する者がマルチアカウントを制す
大規模なマルチアカウント環境において、AWS CloudFormation StackSetsは「管理の要」である。しかし、数百のアカウントへ一斉にIaCを流し込む際、単にデプロイボタンを押すだけのエンジニアは、必ず「スロットリングの地獄」と「予測不能なロールアウトの停滞」に足元を掬われる。
本稿では、StackSetsのデプロイオペレーション制御を極限まで最適化し、ミッションクリティカルな環境で「止まらないインフラ」を実現するための深淵なる知見を共有する。
—
1. 並行性と耐性の数学的設計
StackSetsのデプロイ制御における二大指標、`MaxConcurrentCount` と `FailureToleranceCount` は、単なるパラメータではない。これらはデプロイという名の分散システムを制御するためのスライディングウィンドウである。
設計の黄金律
- 並行度（Concurrency）の罠: `MaxConcurrentCount` を高く設定しすぎると、AWS APIのレート制限（特にIAMやOrganizations周り）に抵触し、予期せぬAPIコールの拒否が発生する。
- 失敗許容度（Failure Tolerance）の境界: これを過信してはいけない。これは「何台まで失敗しても後続を止めないか」という閾値だが、ここを超えた瞬間、デプロイは強制的に停止（SUSPEND）される。
現場の最適解:
デプロイサイズが100アカウントを超える場合、線形的なデプロイではなく、指数関数的な初期検証と、安定後のバーストデプロイを組み合わせるのが鉄則だ。
推奨されるCLIデプロイ戦略の断片
初回は狭い範囲で、かつ失敗を許容しない（Strict Mode）
aws cloudformation create-stack-instances \
–stack-set-name “prod-network-stack” \
–deployment-targets “Accounts=[‘123456789012’]” \
–operation-preferences “FailureToleranceCount=0,MaxConcurrentCount=1”
成功を確認後、並列度を上げてロールアウトする
aws cloudformation create-stack-instances \
–stack-set-name “prod-network-stack” \
–deployment-targets “OrganizationalUnitIds=[‘ou-xxxx-xxxxxxxx’]” \
–operation-preferences “FailureTolerancePercentage=10,MaxConcurrentPercentage=20”
—
2. API背後の挙動を掌握する：スロットリングの回避
StackSetsの内部で何が起きているか。それは、StackSet管理者アカウントから各ターゲットアカウントの「実行ロール（AWSCloudFormationStackSetExecutionRole）」へのクロスアカウントSTSセッションの大量発行である。
ここで発生しやすいのが、ターゲットアカウント側のIAMスロットリングだ。特に、スタック内でIAMリソースを大量に作成する場合、Account-levelのIAM APIレート制限がボトルネックとなる。
極限最適化のためのハック
1. Deployment Targetsの最適化: AWS OrganizationsのOU単位でデプロイする場合、スタックセットは内部でアカウントのリストを再帰的に解決する。アカウント数が多い場合、APIを叩く前にスタックセットを分割せよ。「単一の巨大スタックセット」は、障害の起爆剤となる。
2. スタックの疎結合化: 依存関係を一つのスタックセットに詰め込むな。`Networking` -> `Security` -> `Application` と、StackSetの依存グラフを構築し、個別に制御せよ。
—
3. 完全自動化のためのパイプライン制御：Pythonでの制御ハック
CLIの単発実行では不十分だ。我々は「デプロイの進捗を監視し、異常を検知した瞬間にロールバックをトリガーし、さらに次のバッチへ自動移行する」エンジンを構築する必要がある。
以下は、`DescribeStackSetOperation` を用いた、状態遷移駆動型のデプロイ制御の概念コードだ。
import boto3
import time
def execute_safe_deployment(stack_set_name, operation_id):
cf = boto3.client(‘cloudformation’)
while True:
res = cf.describe_stack_set_operation(StackSetName=stack_set_name, OperationId=operation_id)
status = res[‘StackSetOperation’][‘Status’]
# 進行中のステータスを取得
if status in [‘SUCCEEDED’]:
print(“Batch Deployment Successful.”)
break
elif status in [‘FAILED’, ‘STOPPED’]:
raise Exception(f”Deployment halted: {status}”)
# 進行状況に応じて動的に待機時間を調整するアダプティブポーリング
time.sleep(10)
ポイント: 冪等性を確保するため、OperationIdをタグとして管理し、
過去のデプロイが完了していない場合は新規実行をブロックするガードロジックを実装せよ。
—
4. 最後に：現場のエンジニアへ
StackSetsを使いこなすということは、AWSという巨大な分散システムの一部として、自分のIaCを「行儀よく」振る舞わせるということだ。
- 冪等性の極致: どんなに並列デプロイが失敗しようとも、何度再実行しても「壊れない」状態を維持すること。
- オブザーバビリティ: StackSetのAPI呼び出し回数とエラーレートを、CloudWatch Metricsで監視し、自分のデプロイが「AWSの限界」にどれだけ近づいているかを常に可視化すること。
ツールを単に使う段階は卒業せよ。ツールの限界値を知り、その限界値の少し手前を狙って最速かつ最も安全なロールアウトを行う。それこそが、我々SREが果たすべき真の責務だ。
さあ、次は貴方の環境で、この理論を証明してみせてほしい。