Step Functionsによるワークフローを理解する

この単元で学ぶこと

• 状態とワークフローの役割を説明する
• StandardとExpressを要件から選ぶ
• 統合パターンとエラー処理を設計する

本文解説

1. 状態機械とは 注文処理を「在庫確保」「決済」「配送依頼」のような段階に分け、現在どの段階かと次へ進む条件を定義したものが状態機械です。Step Functionsは実行状態を管理します。実際の計算やデータ更新はLambda、ECS、各AWSサービス等が担当し、ワークフローの管理と業務処理を分担します。

2. 基本の状態 Taskはサービスへ仕事を依頼し、Choiceは結果に応じて経路を選び、Waitは時間経過を待ちます。Parallelは定義した複数経路を並行実行し、Mapは注文内の複数明細などへ同様の処理を適用します。処理の並列化では下流の同時実行上限や、一部が失敗したときの扱いも定めます。

3. StandardとExpress Standardは長時間で実行履歴を追跡したい処理や、人の承認待ち等に向きます。Expressは短時間で高頻度のイベント処理に向き、最大実行時間は5分です。Standardの状態遷移による課金とExpressの実行回数・時間・メモリーによる課金の違いもありますが、まず必要な時間と統合機能を満たすかで選びます。

4. 実行保証を正確に読む StandardはExactly-onceのワークフロー実行モデルですが、明示したRetry等ではタスクを再実行します。Expressは非同期が少なくとも1回、同期が高々1回の実行モデルです。どのモデルでも外部決済の成功後に応答が失われる問題等は業務設計で扱います。ワークフロー保証を外部副作用まで無条件に広げません。

5. 統合の待ち方 Request Responseは呼出先APIの応答で次へ進みます。ジョブの受付応答が返っても処理完了とは限りません。Standardでは対応サービスで .sync によりジョブ完了を待ち、タスクトークンのコールバックで外部完了通知を待てます。Expressはこれら二つのパターンに対応しないため、必要機能との照合が重要です。

6. RetryとCatch 一時的なスロットリングには間隔を空けたRetryが役立ちます。入力不正など再試行で直らない失敗は別扱いにします。Retryの対象、最大回数、待ち時間を定め、解消しない対象エラーはCatchで通知や代替経路へ移します。すべてのエラーを無限に再試行する設計は負荷と遅延を増やします。

7. 補償と冪等性 在庫確保後の決済失敗では、在庫予約を解除する業務処理を定義します。Step Functionsが各サービスの更新をまとめて自動ロールバックするわけではありません。取消自体の失敗や再実行も扱い、注文IDで二重確保や二重返金を防ぎます。補償の完了状態も追跡対象にします。

8. 権限と観測 サービス操作には実行ロールの権限が必要です。状態の定義が正しくても権限不足ならTaskは失敗します。Standardの履歴やExpressで設定したCloudWatch Logsを使って失敗段階を追い、入力に機密情報を不用意に含めないようにします。正常系だけでなく一時失敗、恒久失敗、応答喪失も試験します。

図解

重要ポイント

• Taskは処理委譲、Choiceは分岐、Mapは項目への反復
• 実行時間と必要な統合パターンから種別を選ぶ
• 再試行・補償・冪等性を別の責務として設計する

間違えやすい点

• API受付応答とジョブ完了を混同しない
• Expressの同期と非同期を同じ実行保証だと思わない
• ワークフローが外部サービス更新を自動で一括ロールバックすると思わない

用語解説

状態機械

処理の段階と遷移条件を定義する仕組み。

補償処理

完了済みの業務を取消や返金等で打ち消すために設計する処理。

タスクトークン

待機中のタスクへ外部から完了を通知する際に用いる識別情報。

関連教材

• Step Functionsによるワークフローのシナリオ判断