導入
複数の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
読んでみよう
SAPでは「Lambda関数の中に大量の分岐処理を書いている」という既存構成を、Step Functionsで書き直す改善問題が出ます。ビジネスロジックの流れそのものをコードでなく状態機械として外に出すという発想の転換を押さえておきましょう。