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

この単元で学ぶこと

• 待機時間と完了条件から統合方式を選ぶ
• 失敗に応じて再試行・代替・補償を分ける
• 実行保証と監査要件を評価する

本文解説

1. 予約フローの要求 ホテル予約では空室を確保し、決済を行い、必要なら担当者の審査を待って確定します。担当者の判断が翌日になる可能性があるなら、Lambdaを起動し続けて待つ方式より長時間の状態管理を考えます。Standardとコールバックを候補にし、各Taskを短い業務操作に分けます。

2. 応答の意味を確認 決済APIが同期で最終結果を返す場合と、解析ジョブAPIが受付IDだけ返す場合は違います。Request Responseで受付IDを受け取っても解析完了ではありません。完了を待って結果を使うなら、対応サービスの .sync や完了通知のコールバック等を選びます。

3. 短い大量イベント 端末の計測値を短時間で検査・変換する処理ならExpressを検討できます。5分以内という制約、非同期再実行への冪等性、同期呼出しの必要性を確認します。Standardの方が常に正しい、Expressの方が常に安いという決め方ではなく、機能・所要時間・観測・料金を照合します。

4. 一時失敗への待ち方 外部APIが一時的に要求数を制限したとき、即座に大量再送すると回復を妨げます。再試行回数を限定し、待ち時間を増やすバックオフやジッターを検討します。一方、カード番号の形式エラーは同じ入力で再試行しても直らないため、利用者の修正要求などの経路に移します。

5. 業務上の後始末 空室確保後に決済が拒否された場合は予約枠を戻します。Catchはその経路へ遷移させる機能で、在庫を戻す実処理を自動生成するわけではありません。取消の失敗も通知し、再試行が二重取消や二重返金にならないよう、予約IDと処理状態を保持します。

6. 並行化の範囲 本人確認と不正検査が独立ならParallelで並行化できます。予約内の宿泊者一覧を同じ規則で検査するならMapが対応します。一方で決済前に在庫確保が必要なら、その順序は保持します。速度だけを目的に依存関係を無視して並行化すると、業務の整合性が崩れます。

7. 履歴とログ 予約番号からどの段階で失敗したか追えることを監査要件に含めます。Standardの実行履歴にも保持の制約があり、長期保存が必要なら別途設計します。ExpressではCloudWatch Logsを設定して調査に必要な情報を残します。ログへ決済情報や個人情報をそのまま含めないよう入力内容も絞ります。

8. 実行モデルの検証 Standardであっても定義したRetryはタスクを再実行します。外部決済成功直後の応答喪失を試し、同じ予約IDで再実行しても一回分の請求になるか確認します。Expressの同期と非同期では保証が異なるため、単に「Expressは少なくとも1回」とまとめず、呼出し方式まで設計書に記します。

図解

重要ポイント

• 受付応答しか返さないAPIを業務完了と見なさない
• 一時失敗は再試行、入力不正は修正経路、完了済み効果は補償
• 監査要件には保存期間と機密情報の扱いも含める

間違えやすい点

• Catchだけで予約や請求が元に戻ると思わない
• 依存関係のある処理を速度優先で並行化しない
• Standardの名称だけで外部請求の一回性を証明したと思わない

用語解説

バックオフ

再試行の待ち時間を段階的に増やし、障害先への集中を抑える方法。

ジッター

再試行時刻をランダムにずらし、一斉再送を抑える方法。

受付応答

処理要求を受理したという返答。長時間ジョブの完了を必ずしも意味しない。

関連教材

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