Cloud Service
AWS Step Functions
複数サービスをステートマシンとして可視化・連携させるサーバーレスなワークフロー基盤。状態遷移とリトライを宣言的に定義する。
中級DVA-C02SAA-C03DOP-C02運用上の優秀性信頼性
最終更新: 2026-06-13公式ドキュメント ↗
TL;DR要点だけ先に
- 1.処理の流れを状態の図として定義し各サービスを順に呼ぶ。
- 2.リトライ・分岐・並列・待機を自前コードなしで宣言できる。
- 3.実行履歴が可視化され失敗箇所と入出力を後から追える。
解決する課題
- 複数サービスをまたぐ処理の順序・分岐・待機をLambdaのコードに埋め込むと複雑化する
- 失敗時のリトライやエラー処理を一貫したルールで持ちたい
- 長時間かかる業務フローの進行状況や失敗箇所を後から追えるようにしたい
- 「人手の承認待ち」や「外部処理の完了待ち」を安全に待機したい
主要概念と用語
- ステートマシン: ワークフロー全体の定義。状態(ステート)の集合と遷移で表す
- ステート(状態): 1つの処理単位。種類により役割が異なる
- Task: 実際の処理を呼ぶ状態。Lambdaや他のAWSサービスを実行する
- Choice: 入力の値で分岐する状態
- Parallel / Map: 複数の処理を並列実行する状態(Mapは配列要素ごとに繰り返す)
- Wait: 指定時間または時刻まで待つ状態
- ASL: ステートマシンを定義するJSONベースの言語(Amazon States Language)
- 実行(Execution): ステートマシンを1回走らせた単位。入出力と履歴が記録される
仕様・制限・クォータ
- ワークフローには2つのタイプがある。**標準(Standard)**は長時間・完全な実行履歴向け、Expressは高頻度・短時間向け
- 標準は実行が最大1年程度の長期間にわたれる一方、Expressは短時間の実行に最適化されている
- 状態定義の入出力ペイロードには上限サイズがあり、大きなデータはS3に置いて参照を渡すのが定石
- 多数のAWSサービスを直接呼び出せる(サービス統合)ため、Lambdaを介さずに連携できる
内部の仕組み
ステートマシンを実行すると、Step Functionsは現在の状態の出力を次の状態の入力として渡しながら、定義された遷移をたどります。各状態はTaskならサービスを呼び、Choiceなら条件分岐し、ParallelやMapなら複数の枝を同時に進めます。各状態にはRetry(再試行)とCatch(エラー捕捉)を宣言でき、一時的な失敗は自動でリトライし、回復不能なエラーは別の状態へ遷移して後始末できます。すべての状態遷移は記録され、入出力とともに実行履歴として残ります。
リトライはコードに書かない
一時的なエラーへの指数バックオフ付きリトライは、各状態のRetry定義で宣言するのが基本。Lambda内に再試行ループを書くより、ワークフロー側に寄せると意図が可視化され運用も楽になります。
設計パターン / ベストプラクティス
- オーケストレーション: 注文処理など複数ステップの業務フローを1つのステートマシンに集約
- Mapで並列処理: 配列の各要素を並列に処理し、スループットを上げる
- コールバックで待機: タスクトークンを使い、外部処理や人手の承認の完了通知を待つ
- Sagaパターン: 途中で失敗したら
Catchで補償処理(ロールバック相当)へ遷移 - 大きなデータはS3経由: 状態間で渡すのは参照だけにしてペイロード上限を回避
標準とExpressの選び方
標準は実行履歴が完全で長時間処理・監査向け、Expressは大量・短時間のイベント処理向けで料金体系も異なります。要件(実行頻度・所要時間・履歴の必要性)で選び分けます。
運用・監視
- 各実行のステータス(成功・失敗・中断)と、どの状態で止まったかをコンソールのグラフ表示で確認できる
- CloudWatchメトリクスで実行数・失敗数・実行時間を監視する
- 失敗が増えたら、該当する状態のRetry/Catch定義と、呼び出し先サービスの権限・入力フォーマットを確認する
- EventBridgeから定期起動したり、実行状態の変化をイベントとして受け取ったりできる
コスト
- 標準は主に状態遷移の回数で課金される。遷移が多いほど費用が増える
- Expressは実行回数と実行時間・使用リソースに応じた課金で、高頻度・短時間の処理に向く
- 不要な状態遷移を減らす、
Choiceで早期に分岐を絞る、といった設計でコストを抑えられる
セキュリティ
- ステートマシンにはIAMロールを割り当て、呼び出すサービスへの権限を最小限に絞る
- 実行データはサービス側で暗号化され、必要に応じてKMSによる管理を組み合わせる
- VPC内のリソースを呼ぶ場合は、呼び出し先(Lambdaなど)側のネットワーク設定で制御する
- 入出力に機微なデータを含める場合は、ログ出力レベルやS3参照方式の利用を検討する
Well-Architected の観点
- 運用上の優秀性: ワークフローが可視化され、失敗箇所と入出力を履歴で追える
- 信頼性: Retry・Catch・並列・待機を宣言的に持ち、部分的な失敗から回復しやすい
試験で問われるポイント
頻出
- 複数サービスをまたぐオーケストレーションの中心=Step Functions
- Retry / Catch によるエラー処理を宣言的に定義できる
- **標準(長時間・履歴重視)vs Express(高頻度・短時間)**の使い分け
- Mapによる並列処理と、タスクトークンによるコールバック待機
関連サービス・比較
| 観点 | Step Functions | SQS |
|---|---|---|
| 役割 | ワークフローの統括 | メッセージのバッファ |
| 流れの制御 | 順序・分岐・並列を定義 | 順序保証はFIFOのみ |
| 可視化 | 実行履歴をグラフ表示 | キューの滞留を監視 |
| 向く用途 | 多段の業務フロー連携 | 送信側と処理側の疎結合 |
ハンズオン / CLI例
# ステートマシンの定義(ASL)を渡して作成
aws stepfunctions create-state-machine \
--name order-flow \
--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"}'
AWS Service
AWS Step Functionsを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
アプリ統合
比較で見る軸
クラウド: AWS / カテゴリ: アプリ統合 / 難易度: intermediate
導入後に効く点
リトライ・分岐・並列・待機を自前コードなしで宣言できる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- AWS
- カテゴリ
- アプリ統合
- 難易度
- intermediate
- 関連資格
- DVA-C02 / SAA-C03 / DOP-C02
- 設計柱
- operational / reliability
判断チェックリスト
- 自社の用途が「アプリ統合 / operational」に近いか確認する。
- 強みである「処理の流れを状態の図として定義し各サービスを順に呼ぶ。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。