導入
複数のLambda関数やサービス呼び出しを順番に、あるいは条件分岐やリトライを挟みながらつなぐ処理を、Lambda関数の中でif文とtry-catchを積み重ねて書くと、すぐに管理不能になります。Step Functionsは、その手続きの流れそのものを1つの状態機械として管理するサービスです。
説明
AWS Step Functions は、各処理ステップ（Lambda呼び出し、他のAWSサービスのAPI呼び出しなど）をステートマシンとして定義し、順序・分岐・並列・リトライ・エラーハンドリングをサービス側にまかせるオーケストレーションツールです。
flowchart TD
START["注文受付"] --> PAY["決済処理"]
PAY -->|成功| SHIP["出荷指示"]
PAY -->|失敗| CANCEL["注文キャンセル<br/>（補償処理）"]
SHIP --> NOTIFY["完了通知"]
| ワークフロータイプ | 特徴 | 向いている用途 |
|---|---|---|
| Standard | 実行履歴を長期保持、最大1年実行可、正確に1回実行 | 人の承認待ちを含む長時間の業務フロー |
| Express | 高頻度・短時間、最大5分、少なくとも1回実行 | IoTデータ処理など大量・高速なイベント処理 |
複数サービスにまたがる一連の処理の中で、途中のステップが失敗したときにそれまでの処理を打ち消す補償トランザクションを組む設計を Sagaパターン と呼びます。分散システムでは、データベースのトランザクションのように全体を一括ロールバックすることができないため、「失敗したら逆向きの処理を1つずつ実行して帳尻を合わせる」という考え方が必要になります。Step Functionsは、この補償フローの分岐・リトライを状態機械として表現するのに向いています。
- 「処理の途中経過を可視化したい」「複雑な分岐・リトライをコードで書きたくない」→ Step Functions
- 「分散したサービスをまたぐトランザクションを安全に扱いたい」→ Sagaパターン＋Step Functions
具体例
旅行予約サービスの「①航空券予約 → ②ホテル予約 → ③決済」を考えます。データベースが分かれているため、途中で失敗しても一括ロールバックができません。②まで成功して③決済で失敗したら、①②の予約が宙に浮いてしまいます。
ここでStep Functions＋Sagaパターンの出番です。
- 各ステップをステートマシンとして定義し、順序・分岐・リトライをサービスに任せる
- ③決済が失敗したら、補償トランザクション（逆向きの打ち消し処理）を実行：②ホテル予約をキャンセル → ①航空券予約をキャンセル、と1つずつ帳尻を合わせる
- 進行状況はコンソールで可視化され、どのステップで止まったか一目瞭然
もしこれを1つの巨大なLambdaにif文とtry-catchで書くと、補償処理の分岐が絡み合って管理不能に。SAPでは「Lambdaに大量の分岐を書いた既存構成をStep Functionsへ書き直す」改善問題が頻出。ビジネスの流れをコードでなく状態機械として外に出す発想を押さえましょう。
読んでみよう
SAPでは「Lambda関数の中に大量の分岐処理を書いている」という既存構成を、Step Functionsで書き直す改善問題が出ます。ビジネスロジックの流れそのものをコードでなく状態機械として外に出すという発想の転換を押さえておきましょう。