エラーハンドリング（ストリームのイベントソースマッピング）難易度 標準無料
Kinesis Data Streamsをトリガーに動くLambda関数で、あるシャード内の特定の1レコード（不正なフォーマットの「毒レコード」）が原因で処理が常にエラーになり、そのシャードの後続レコードの処理まで滞留してしまっている。この問題レコードを迅速に切り分け、後続処理の滞留を最小化する設定として最も適切なものを選べ。（単一選択）
- Aイベントソースマッピングで「バッチをバイセクト（bisect batch on function error）」を有効にし、あわせて最大再試行回数・最大レコード経過時間を設定して問題レコードを迅速に切り分け・スキップできるようにする
- Bイベントソースマッピングの関数レスポンスタイプで
ReportBatchItemFailuresを有効化し、失敗したレコードのシーケンス番号だけを個別に返す - C関数のタイムアウト値を1秒に短縮し、処理が長引く前に強制終了させることで滞留を防ぐ
- DKinesisストリームのシャード数を増やし、並列度を上げることで問題レコードの影響を緩和する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
Kinesis/DynamoDB Streamsのイベントソースマッピングは、既定ではバッチ処理が失敗すると同じバッチ全体を再試行し、 成功するか設定した保持期間・再試行回数の上限に達するまでそのシャードの後続レコードの処理をブロックする。
- 「バッチをバイセクト（bisect batch on function error）」を有効にすると、エラー発生時にバッチを半分に分割して再試行し、 それでも失敗すればさらに半分に分割……と繰り返すことで、問題のあるレコードを迅速に特定・分離できる。
- あわせて最大再試行回数（maximum retry attempts）や最大レコード経過時間（maximum record age）を設定しておくと、 特定・分離された問題レコードを一定回数/時間で見切ってスキップし、残りの正常なレコードの処理を先に進められる。
- 問題レコードはon-failure destination（設定していれば）へ送信し、後で個別に調査・再処理することも可能。
- なお
ReportBatchItemFailures（部分的バッチ失敗報告）は2020年12月にKinesis Data Streams・DynamoDB Streams向けに提供が始まっており（SQS向けの提供は2021年11月）、バイセクトと併用可能な別軸の機能である。ただしこれは関数コード側が失敗したレコードのシーケンス番号を自ら識別してitemIdentifierとして返すことが前提の仕組みであり、本問のように関数が個々のレコードを識別できずバッチ全体に対して例外をスローするだけの状況では、有効化しても問題レコードの自動切り分けにはつながらない。
- B
ReportBatchItemFailuresは2020年12月からKinesis/DynamoDB Streamsのイベントソースマッピングで利用でき（SQS向けの提供は2021年11月）「SQS専用」ではない（バイセクトと併用可能な別軸の機能）。ただし本機能は関数コードが失敗したレコードのシーケンス番号を明示的に識別してitemIdentifierとして返すことが前提であり、本問のように関数が個々のレコードを識別できずバッチ全体に対して例外をスローするだけの状況では、有効化しても問題レコードの自動切り分けにはつながらない。コード変更なしに問題レコードを特定・スキップできるのはバイセクト（A）である。 - Cタイムアウト短縮はエラーの原因（不正フォーマットのレコード）自体を解決せず、正常なレコードまで処理が完了しなくなるリスクを高める。
- Dシャード分割は別のシャードへの影響を減らす効果はあるが、当該シャード内の毒レコードによる滞留そのものを解消しない。バイセクトによる切り分けが直接的な対策になる。
ひっかけ： 「ReportBatchItemFailuresを有効にする（B）」は、2020年12月からKinesis/DynamoDB Streamsのイベントソースマッピングでも利用できる（SQS専用ではない。SQS向けの提供は2021年11月）が、
本問の状況（関数が個々のレコードを識別できずバッチ全体でエラーになる）では、コード変更なしに問題レコードを自動的に切り分けられるバイセクト（A）が直接的な解決策になる。
両機能は排他ではなく併用可能な別軸の機能である点を混同しないこと。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）