AWS Step Functions

解決する課題

• 複数サービスをまたぐ処理の順序・分岐・待機をLambdaのコードに埋め込むと複雑化する
• 失敗時のリトライやエラー処理を一貫したルールで持ちたい
• 長時間かかる業務フローの進行状況や失敗箇所を後から追えるようにしたい
• 「人手の承認待ち」や「外部処理の完了待ち」を安全に待機したい

主要概念と用語

• ステートマシン: ワークフロー全体の定義。状態（ステート）の集合と遷移で表す
• ステート（状態）: 1つの処理単位。種類により役割が異なる
• Task: 実際の処理を呼ぶ状態。Lambdaや他のAWSサービスを実行する
• Choice: 入力の値で分岐する状態
• Parallel / Map: 複数の処理を並列実行する状態（Mapは配列要素ごとに繰り返す）
• Wait: 指定時間または時刻まで待つ状態
• ASL: ステートマシンを定義するJSONベースの言語（Amazon States Language）
• 実行（Execution）: ステートマシンを1回走らせた単位。入出力と履歴が記録される

仕様・制限・クォータ

• ワークフロー種別は作成後に変更不可。Standard は最大 1 年、Express は最大 5 分
• Standard は実行一回、非同期 Express は最低一回、同期 Express は最大一回の実行モデル
• 状態・タスク・実行の入出力は 256 KiB。大きなデータは S3 に置いて参照を渡す
• Standard の履歴は 25,000 イベント、実行中はリージョンあたり既定 100 万件
• Distributed Map は一回の Map Run で最大 10,000 子実行。Express 自体は Distributed Map 非対応
• 多数のAWSサービスを直接呼び出せる（サービス統合）ため、Lambdaを介さずに連携できる

内部の仕組み

横にスクロール

ステートマシンを実行すると、Step Functionsは現在の状態の出力を次の状態の入力として渡しながら、定義された遷移をたどります。各状態はTaskならサービスを呼び、Choiceなら条件分岐し、ParallelやMapなら複数の枝を同時に進めます。各状態にはRetry（再試行）とCatch（エラー捕捉）を宣言でき、一時的な失敗は自動でリトライし、回復不能なエラーは別の状態へ遷移して後始末できます。すべての状態遷移は記録され、入出力とともに実行履歴として残ります。

Standard は実行一回モデルですが、明示した Retry はタスクを再実行します。外部更新は業務IDで冪等化し、複数サービスをまたぐ取消しは Catch から補償処理へ進めます。非同期 Express は実行自体が重複し得るため全ステップを冪等にします。同期 Express は失敗時に自動再実行されないので、呼び出し元が応答不明をどう扱うか決めます。

設計パターン / ベストプラクティス

• オーケストレーション: 注文処理など複数ステップの業務フローを1つのステートマシンに集約
• Mapで並列処理: 配列の各要素を並列に処理し、スループットを上げる
• コールバックで待機: タスクトークンを使い、外部処理や人手の承認の完了通知を待つ
• Sagaパターン: 途中で失敗したらCatchで補償処理（ロールバック相当）へ遷移
• 大きなデータはS3経由: 状態間で渡すのは参照だけにしてペイロード上限を回避

運用・監視

• 各実行のステータス（成功・失敗・中断）と、どの状態で止まったかをコンソールのグラフ表示で確認できる
• CloudWatchメトリクスで実行数・失敗数・実行時間を監視する
• 失敗が増えたら、該当する状態のRetry/Catch定義と、呼び出し先サービスの権限・入力フォーマットを確認する
• EventBridgeから定期起動したり、実行状態の変化をイベントとして受け取ったりできる

コスト

• 標準は主に状態遷移の回数で課金される。遷移が多いほど費用が増える
• Expressは実行回数、100ミリ秒単位の時間、64 MB単位のメモリで課金される
• Standard は月 4,000 状態遷移の継続無料枠があり、Retry も追加の遷移として数える
• 不要な状態遷移を減らす、Choiceで早期に分岐を絞る、といった設計でコストを抑えられる

セキュリティ

• ステートマシンにはIAMロールを割り当て、呼び出すサービスへの権限を最小限に絞る
• 実行データはサービス側で暗号化され、必要に応じてKMSによる管理を組み合わせる
• VPC内のリソースを呼ぶ場合は、呼び出し先（Lambdaなど）側のネットワーク設定で制御する
• 入出力に機微なデータを含める場合は、ログ出力レベルやS3参照方式の利用を検討する

Well-Architected の観点

• 運用上の優秀性: ワークフローが可視化され、失敗箇所と入出力を履歴で追える
• 信頼性: Retry・Catch・並列・待機を宣言的に持ち、部分的な失敗から回復しやすい

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# ステートマシンの定義(ASL)を渡して作成
aws stepfunctions create-state-machine \
  --name order-flow \
  --type STANDARD \
  --role-arn "arn:aws:iam::123456789012:role/StepFunctionsRole" \
  --definition '{
    "Comment": "簡単な順次フロー",
    "StartAt": "Validate",
    "States": {
      "Validate": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:validate",
        "Retry": [{"ErrorEquals": ["States.ALL"], "MaxAttempts": 2, "BackoffRate": 2.0}],
        "Next": "Charge"
      },
      "Charge": {
        "Type": "Task",
        "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:charge",
        "End": true
      }
    }
  }'

# 実行を開始して入力を渡す
aws stepfunctions start-execution \
  --state-machine-arn "arn:aws:states:ap-northeast-1:123456789012:stateMachine:order-flow" \
  --input '{"orderId":"A-1001"}'