【テクニカル・上級編】CloudFormationスタックのデプロイタイムアウトと失敗時の自動リトライ戦略：LambdaとStep Functionsを駆使した自作エラーハンドリング基盤 – インフラ構成管理（IaC）活用バイブル

CloudFormationの限界を突破せよ：Step FunctionsとLambdaで構築する「不落のデプロイ・エラーハンドリング基盤」

インフラストラクチャ・作為的コード（IaC）の黎明期からAWSを触ってきたエンジニアであれば、誰もが一度は経験する悪夢がある。

「`UPDATE_ROLLBACK_FAILED`」

この文字列を見た瞬間、冷や汗が流れる。CloudFormation（以下、CFn）の標準機能であるタイムアウト（最大60分）とロールバックは、シンプルなスタックであれば美しく機能する。だが、数千のリソース、複雑な依存関係、カスタムリソース（Lambda-backed Custom Resources）、そしてマルチAZに跨るECSやRDSの協調動作を含むエンタープライズ規模のトポロジーにおいて、標準のメカニズムはあまりにも無力だ。

標準のCFnには、以下の致命的な欠陥がある。
1. 粒度の粗すぎるタイムアウト: スタック全体、あるいはリソースごとの一律なタイムアウトしか設定できず、外部APIの応答遅延などの一時的なネットワーク揺らぎですぐに全体が巻き戻される。
2. 「途中で止まったロールバック」: リソースの削除・更新順序のデッドロックや、IAMの伝播遅延によりロールバック自体が失敗し、手動でAWS ConsoleやCLIに張り付いてリソースの漂流（Drift）を修復する羽目になる。
3. 可観測性の欠如: 失敗時にCloudWatch Logsの海をさまよい、どのリソースのどのプロパティ変更が原因でデプロイが頓挫したのかを人間が特定しなければならない。

本記事では、このCFnの限界を完全にハックし、AWS Step FunctionsとLambdaを駆使した「自作エラーハンドリング＆自動リトライ基盤」の設計と実装を解説する。

—

1. アーキテクチャ全体像：なぜStep Functionsなのか

単にLambdaでCFnをラップするだけでは不十分だ。デプロイメントパイプラインには「状態（State）」が存在する。

  • 「スタックのデプロイ実行中（Polling）」
  • 「タイムアウト・失敗の検知」
  • 「エラー原因の自動解析（CloudWatch Logs / EventBridgeからの抽出）」
  • 「戦略的リトライ vs 自動ロールバック or Slack通知を伴うエスカレーション」

これらを堅牢に非同期実行するためには、ステートマシン（AWS Step Functions）が唯一無二の解となる。

[CDK / Pipeline]
│
▼ (Start Execution)
┌──────────────────────────────────────────────┐
│ AWS Step Functions │
│ ┌──────────────┐ ┌──────────────────┐ │
│ │ Create/Update│─────▶│ Poll Stack Status│ │
│ │ Stack │ │ (Wait & Check) │ │
│ └──────────────┘ └────────┬─────────┘ │
│ │ │
│ ┌────────┴────────┐ │
│ ▼ (Failed/Timeout)│ │
│ ┌──────────────┐ │ │
│ │ Error Parser │ │ │
│ │ (Lambda) │ │ │
│ └──────┬───────┘ │ │
│ │ │ │
│ ┌─────────────┴─────────────┐ │
│ ▼ ▼ │
│ [Transient Error?] [Fatal Error?]│
│ YES ──▶ [Auto Retry] YES ──▶ [Slack]│
└──────────────────────────────────────────────┘

—

2. 実装：ステートマシンとエラー解析Lambdaの構築

ここからは、実際に本番稼働に耐えうるコードベースで解説する。IaCにはAWS CDK（TypeScript）を使用するが、本質はCFnのAPI（`CreateStack` / `UpdateStack` / `DescribeStackEvents`）をどう制御するかにある。

Step 1: 失敗原因をミリ秒単位で特定する解析Lambda

CFnが失敗した際、単に `UPDATE_FAILED` を検知するだけでは無能なオブザーバビリティだ。どの論理リソース（Logical ID）が、どのようなエラーメッセージ（例: `Rate Exceeded`, `Resource already exists`）で落ちたのかを抽出するLambdaを実装する。

lambda/error_parser/index.py
import os
import boto3
from botocore.exceptions import ClientError

cloudformation = boto3.client(‘cloudformation’)

def handler(event, context):
“””
CloudFormationのスタックイベントを走査し、失敗の原因となった
リソースとエラーメッセージを抽出する。
“””
stack_name = event.get(‘StackName’)

try:
# 最新のイベントから失敗要因を特定
response = cloudformation.describe_stack_events(StackName=stack_name)
events = response.get(‘StackEvents’, [])

failure_reasons = []
for e in events:
resource_status = e.get(‘ResourceStatus’, ”)
if ‘FAILED’ in resource_status or ‘ROLLBACK’ in resource_status:
logical_id = e.get(‘LogicalResourceId’)
resource_type = e.get(‘ResourceType’)
status_reason = e.get(‘ResourceStatusReason’, ‘No reason provided’)

failure_reasons.append({
‘LogicalResourceId’: logical_id,
‘ResourceType’: resource_type,
‘Reason’: status_reason
})

# 直近の致命的なエラーのみを抽出
root_cause = failure_reasons[0] if failure_reasons else {
‘LogicalResourceId’: ‘Unknown’,
‘ResourceType’: ‘Unknown’,
‘Reason’: ‘Unknown failure state’
}

# エラーが一時的なもの（Transient）か判定
is_transient = any(keyword in root_cause[‘Reason’] for keyword in [
‘Throttling’, ‘Rate Exceeded’, ‘InternalFailure’, ‘Timeout’
])

return {
‘StackName’: stack_name,
‘RootCause’: root_cause,
‘IsTransient’: is_transient,
‘AllFailures’: failure_reasons[:5] # 上位5件
}

except ClientError as e:
print(f”Error describing stack events: {e}”)
raise e

Step 2: Step Functions ステートマシンの定義（ASL）

次に、デプロイのキック、ポーリング、タイムアウト制御、エラー解析、そして条件分岐（リトライ or 通知）を司るASL（Amazon States Language）を構築する。

{
“Comment”: “CFn Advanced Deployment and Error Handling Orchestrator”,
“StartAt”: “DeployOrUpdateStack”,
“States”: {
“DeployOrUpdateStack”: {
“Type”: “Task”,
“Resource”: “arn:aws:lambda:REGION:ACCOUNT_ID:function:cfn-executor”,
“Parameters”: {
“Action.$”: “$.Action”,
“StackName.$”: “$.StackName”,
“TemplateURL.$”: “$.TemplateURL”,
“Parameters.$”: “$.Parameters”
},
“Next”: “WaitForStack”,
“Catch”: [
{
“ErrorEquals”: [“States.ALL”],
“Next”: “HandleDeploymentFailure”
}
]
},
“WaitForStack”: {
“Type”: “Wait”,
“Seconds”: 30,
“Next”: “CheckStackStatus”
},
“CheckStackStatus”: {
“Type”: “Task”,
“Resource”: “arn:aws:lambda:REGION:ACCOUNT_ID:function:cfn-status-checker”,
“Parameters”: {
“StackName.$”: “$.StackName”
},
“Next”: “EvaluateStackStatus”
},
“EvaluateStackStatus”: {
“Type”: “Choice”,
“Choices”: [
{
“Variable”: “$.Status”,
“StringEquals”: “CREATE_COMPLETE”,
“Next”: “DeploymentSuccess”
},
{
“Variable”: “$.Status”,
“StringEquals”: “UPDATE_COMPLETE”,
“Next”: “DeploymentSuccess”
},
{
“Variable”: “$.Status”,
“StringEquals”: “CREATE_IN_PROGRESS”,
“Next”: “WaitForStack”
},
{
“Variable”: “$.Status”,
“StringEquals”: “UPDATE_IN_PROGRESS”,
“Next”: “WaitForStack”
},
{
“Variable”: “$.Status”,
“StringEquals”: “UPDATE_COMPLETE_CLEANUP_IN_PROGRESS”,
“Next”: “WaitForStack”
}
],
“Default”: “HandleDeploymentFailure”
},
“HandleDeploymentFailure”: {
“Type”: “Task”,
“Resource”: “arn:aws:lambda:REGION:ACCOUNT_ID:function:cfn-error-parser”,
“Parameters”: {
“StackName.$”: “$.StackName”
},
“Next”: “IsRetryable”
},
“IsRetryable”: {
“Type”: “Choice”,
“Choices”: [
{
“Variable”: “$.IsTransient”,
“BooleanEquals”: true,
“Next”: “RetryWait”
}
],
“Default”: “NotifySlackAndFail”
},
“RetryWait”: {
“Type”: “Wait”,
“Seconds”: 60,
“Next”: “DeployOrUpdateStack”
},
“NotifySlackAndFail”: {
“Type”: “Task”,
“Resource”: “arn:aws:lambda:REGION:ACCOUNT_ID:function:slack-notifier”,
“Parameters”: {
“Payload.$”: “$”
},
“Next”: “DeploymentFailed”
},
“DeploymentSuccess”: {
“Type”: “Succeed”
},
“DeploymentFailed”: {
“Type”: “Fail”,
“Error”: “CloudFormationDeploymentError”,
“Cause”: “Stack deployment failed and exceeded retry limits or encountered fatal error.”
}
}
}

—

3. 実運用におけるリトライ設計の極意：プロが踏むべき「地雷」

上記の仕組みを導入すれば終わり、ではない。ここからが本番、SREとしての真価が問われる領域だ。実運用で破綻しないための設計ハックを授ける。

A. 冪等性（Idempotency）の担保：二重デプロイの呪縛を防ぐ

APIスロットリングやLambdaのタイムアウトによる再実行時、`CreateStack` や `UpdateStack` が意図せず二重に発行されると、CFnは `ConcurrentUpdateDetected` 例外を吐いてクラッシュする。
これを防ぐため、ステートマシンへ渡すペイロードには必ず一意のデプロイメントトークン（UUIDv4等）を含め、Lambda側でDynamoDBを用いたロック機構を実装するか、CFnの変更セット（ChangeSet）を明示的に作成・実行するフローを強制すること。

変更セットアプローチの概念コード
def create_change_set_safely(stack_name, template_url, token):
try:
response = cloudformation.create_change_set(
StackName=stack_name,
TemplateURL=template_url,
ChangeSetName=f”deploy-{token[:8]}”,
ChangeSetType=’UPDATE’ # or CREATE
)
return response[‘ChangeSetId’]
except ClientError as e:
if ‘AlreadyExists’ in str(e):
# 既に存在する場合は既存のIDを返す
…

B. 「リトライして良いエラー」と「してはいけないエラー」の厳密な峻別

すべてのエラーをリトライしてはならない。

  • リトライすべき（Transient / 一時的）:
  • AWS APIの `ThrottlingException`
  • カスタムリソースのタイムアウト（Lambda側の一時的な冷え込みや外部APIの微小な遅延）
  • `InternalFailure`
  • 即座にロールバック＆通知すべき（Fatal / 致命的）:
  • `ValidationError`（テンプレートの構文ミス、存在しないVPC IDの参照）
  • `AccessDenied`（IAM権限不足）
  • `ResourceAlreadyExists`（他スタックとのリソース名競合）

特に `ValidationError` をリトライしても結果は100%同じ（無駄なAPIコストと時間の浪費）であるため、エラー解析Lambdaで即座に `IsTransient = false` を返し、Slackにスタックトレースと失敗リソースの論理IDを飛ばしてパイプラインを停止させることが鉄則だ。

C. リーク（漂流）したリソースの回収スクリプトの自動化

カスタムリソースやVPCエンドポイントなどの一部リソースは、デプロイ失敗時にロールバックが途中でスタック（`UPDATE_ROLLBACK_FAILED`）することがある。
この状態になると、次回のデプロイは必ずブロックされる。これを人間の手で `aws cloudformation continue-update-rollback` やリソースの強制削除（Retainの設定変更など）を行うのはSREの仕事ではない。

先ほどの `error_parser` Lambda、あるいは専用のクリーンアップLambdaを拡張し、`UPDATE_ROLLBACK_FAILED` を検知した瞬間に、依存関係の順序を考慮した `–retention-options` 付きの自動復旧コマンド、または手動介入が必要なリソースの識別フラグをSlackへ投げる自動修復ループを組み込むこと。

—

4. 結び：インフラストラクチャを「意のままに」操るために

AWS CloudFormationは、時としてその厳格さゆえに開発者の足を引っ張るレガシーなツールのように語られることがある。しかし、それは「裸のCFn」をそのままCI/CDの直火に放り込んでいるからに他ならない。

今回解説した、Step Functionsによる状態管理、Lambdaによるきめ細やかなエラー解析、そしてインテリジェントなリトライ・エスカレーション戦略を組み合わせることで、CFnは「予測不能なブラックボックス」から「完全に制御された堅牢なエンジン」へと生まれ変わる。

インフラストラクチャをコードで定義する時代から、インフラストラクチャのライフサイクルそのものをコードとステートマシンで支配する時代へ。この基盤をあなたのパイプラインに組み込み、真の自動化の境地へ到達してほしい。

スポンサーリンク
タイトルとURLをコピーしました