ある企業が、Lambda 関数でサードパーティの外部 API を呼び出すワークフローを実装している。外部 API は時々タイムアウトや一時的なエラーを返すことがある。エラーが発生した場合は指数バックオフで最大 3 回リトライし、それでも失敗した場合は人間の確認が必要なワークフローを起動したい。最小限のコード実装で実現する最も適切なソリューションはどれか。
- A. AWS Step Functions のステートマシンを使い、Lambda の呼び出しに自動リトライ設定（指数バックオフ、最大 3 回）を定義し、MaxAttempts を超えた場合は Catch で人間承認タスクに遷移させる。
- B. Amazon EventBridge のリトライポリシーを使って Lambda を最大 3 回呼び出し、失敗した場合はデッドレターキューで捕捉する。
- C. Amazon SQS の可視性タイムアウトと再試行機能を使い、Lambda 関数を 3 回呼び出し後に DLQ に送信する。
- D. Lambda 関数内に try-catch と指数バックオフのリトライロジックを実装し、3 回失敗した場合は SNS で担当者に通知する。
解答と解説を見る
正解: A
AWS Step Functions はステートマシンの各タスクステートに Retry 設定（IntervalSeconds、BackoffRate、MaxAttempts）と Catch 設定を宣言的に記述できる。Lambda の呼び出しに「最大 3 回・指数バックオフ」のリトライを設定し、すべて失敗した場合は Catch ブロックで人間承認タスク（waitForTaskToken を使ったアクティビティ）に遷移させることで、コードを最小限にしながらこのワークフロー要件を完全に実現できる。選択肢Dは Lambda 内にリトライロジックを自前実装する方法で、コードが複雑になる。Lambda のタイムアウト制限の中でリトライを行う必要もあり、長い指数バックオフには向かない。選択肢BのEventBridge はイベントのリトライは行えるが、複雑なバックオフ設定や承認ワークフローとの統合は Step Functions ほど容易ではない。選択肢CのSQS リトライは失敗メッセージのリキューに使えるが、指数バックオフの細かい制御や人間承認ワークフローとの統合には追加の実装が必要になる。
📚 関連サービスの解説: AWS Step Functions ・ AWS Lambda