エラーハンドリング（SQSのイベントソースマッピング）難易度 高無料
SQS標準キューをイベントソースとするLambda関数が、10件のメッセージからなるバッチを受け取って処理している。現状は1件でも処理に失敗すると、成功した9件も含めてバッチ全体が失敗扱いとなり、可視性タイムアウト後に10件すべてが再度キューに現れて重複処理されてしまう。成功した9件を再処理対象から除外し、失敗した1件だけを再試行させたい。この要件を満たす実装として最も適切なものを選べ。（単一選択）
- ASQSのイベントソースマッピングで関数レスポンスタイプ
ReportBatchItemFailuresを有効化し、ハンドラーが失敗したメッセージIDのみをbatchItemFailuresとして返すように実装する - Bイベントソースマッピングで「バッチをバイセクト（bisect batch on function error）」を有効化し、バッチを再帰的に半分に分割して問題のメッセージを切り分ける
- Cバッチサイズを1に設定し、常に1件ずつメッセージを処理することで部分失敗の問題自体を回避する
- DSQSキューをFIFOキューに変更すれば、失敗した1件だけが自動的に再試行対象となり成功分は除外される
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
SQSのイベントソースマッピングで関数レスポンスタイプReportBatchItemFailuresを有効化すると、
Lambda関数は処理結果として失敗したメッセージのIDだけを含むレスポンス（batchItemFailures）を返せるようになる。
- これにより、Lambdaのイベントソースマッピングはレスポンスで報告された失敗メッセージのみを可視性タイムアウト後に再度キューへ戻し、 成功した残りのメッセージはキューから正常に削除される（重複再処理を防ぐ）。
- この機能を有効化しない場合、既定の挙動としてバッチ内の1件でもエラーになるとバッチ全体が失敗扱いとなり、 成功したメッセージも含めて全件が再度可視化されてしまう（重複処理・非効率の原因）。
- 実装としては、関数がハンドラーの戻り値で
{"batchItemFailures": [{"itemIdentifier": "<失敗メッセージID>"}]}形式のレスポンスを返すようにする。
- BバイセクトはKinesis/DynamoDB Streamsのイベントソースマッピング向けの機能であり、SQSのイベントソースマッピングには適用されない。SQSでは
ReportBatchItemFailuresが該当機能。 - C実現可能ではあるがスループットが著しく低下し、コスト・レイテンシの観点で非効率。マネージドの部分的バッチ失敗報告機能を使う方が適切。
- DFIFOキューへの変更は順序保証・重複排除の性質を変えるものであり、部分的バッチ失敗の報告機能（
ReportBatchItemFailures）の代替にはならない。
ひっかけ： 「Kinesisと同様にバッチをバイセクトする設定を有効にすればよい（B）」は取り違え。SQSのイベントソースマッピングにおける部分的バッチ失敗の
標準的な解決策は
ReportBatchItemFailuresであり、バイセクトはKinesis/DynamoDB Streams向けの仕組みである。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）