ある医療記録管理企業が、Step FunctionsのStandard Workflowを使って患者データの変換・検証・保存パイプラインを実装している。パイプラインの途中でサードパーティAPIの呼び出し（最大15分待機）がある。Lambdaの15分タイムアウト制限を回避しつつ、待機中のコスト（Lambda実行時間課金）を削減したい。最も適切な実装パターンはどれか。
- A. Lambda関数をStep FunctionsのMapステートで並列実行し、それぞれのAPIコールの完了を待機する
- B. Lambdaの中でWhileループとSleepを使い、APIレスポンスをポーリングする。Lambda実行時間は最大15分まで許容する
- C. サードパーティAPIの呼び出しをEventBridgeスケジュールルールで5分ごとにポーリングするLambdaに分離し、完了時にEventBridgeでStep Functionsを再起動する
- D. Step FunctionsのWaitForTaskTokenパターンを使う。LambdaがタスクトークンとともにサードパーティAPIを呼び出し、その後Lambdaは終了する。APIが完了したら外部からSendTaskSuccessをコールしてワークフローを再開させる
解答と解説を見る
正解: D
WaitForTaskTokenはStep Functionsの「人間による承認」や「外部システム待機」に使われる非同期パターンである。Lambdaがタスクトークン（context.taskToken）をAPIに渡して終了することで、Lambda実行時間課金が発生しない。サードパーティAPIが処理を完了してSendTaskSuccess（またはSendTaskFailure）を呼ぶまでStep Functionsはコスト効率の良い「待機」状態になる。ハートビートタイムアウトを設定すれば無限待機も防止できる。BのLambdaポーリングは最大15分のLambda実行時間制限が制約になり、15分を超える待機には対応できない。また待機中も課金が発生し続けてコスト削減の要件を満たさない。AのMapステート並列実行は複数の独立したタスクを同時実行するためのものであり、単一APIの15分待機問題を解決しない。CのEventBridgeポーリングは複雑な非同期協調が必要でステートフルな管理が難しく、ワークフロー再起動では以前の実行コンテキストが失われる。
📚 関連サービスの解説: AWS Step Functions ・ AWS Lambda