DVAトラブルシューティングと最適化
Lambda 関数を SQS 標準キューのイベントソースとして使用しており、バッチサイズを 10 に設定しています。特定の不正フォーマットのメッセージ（いわゆるポイズンピル：ポイズンピルとは処理不可能なメッセージのことで、繰り返し失敗し続けるメッセージを指します）が混入すると、バッチ全体が繰り返し再処理され、正常なメッセージの処理が遅延します。DLQ（デッドレターキュー）は設定済みですが、maxReceiveCount に達するまで時間がかかります。最小限の変更でスループット低下を防ぐ最も効果的な解決策はどれですか？
ASQS キューの可視性タイムアウト（Visibility Timeout）を延長して再処理間隔を広げる
SQS可視性タイムアウトを延長するとメッセージが再表示されるまでの間隔が広がりますが、バッチ内に失敗メッセージが含まれる場合にバッチ全体がキューに戻されるという根本問題は解消されません。正常なメッセージの処理遅延は継続します。
BLambda イベントソースマッピングの functionResponseTypes に ReportBatchItemFailures を設定し、失敗メッセージの ID をレスポンスで返す
✓ 正解
functionResponseTypesにReportBatchItemFailuresを設定することで、Lambda関数はバッチ内で失敗した特定メッセージのIDのみをbatchItemFailuresとして返せます。成功したメッセージはキューから削除され、失敗メッセージのみ再試行されるため、最小限の変更でスループット低下を防げます。
Cバッチサイズを 1 に変更し、1 メッセージずつ個別処理する
バッチサイズを1に変更すれば1メッセージずつ処理されるためポイズンピルの影響範囲は最小化できます。しかし、バッチ処理のメリットが失われスループットが大幅に低下するため、「スループット低下を防ぐ」という要件に反しており最適な解決策ではありません。
DSQS FIFO キューに変更してメッセージの順序保証を確立する
SQS FIFOキューはメッセージの送信順序を保証し重複排除を提供しますが、バッチ内の一部メッセージが失敗した際にバッチ全体が再処理される問題は解決しません。標準キューからFIFOへの変更は既存アーキテクチャへの影響も大きく「最小限の変更」という要件に反します。
解説
Lambda イベントソースマッピングの functionResponseTypes に ReportBatchItemFailures を設定し、失敗メッセージの ID をレスポンスで返す。
デフォルトでは、バッチ内のいずれかのメッセージが失敗するとバッチ全体がキューに戻されます。ReportBatchItemFailures を有効にすると、Lambda 関数は失敗した特定メッセージの messageId のみをレスポンスの batchItemFailures に返すことができ、成功したメッセージはキューから削除され失敗メッセージのみ再試行されます。
選択肢Aの可視性タイムアウト延長はバッチ全体の繰り返し再処理という根本問題を解消しません。
選択肢Cはバッチサイズを 1 にすることでもポイズンピルの影響を回避できますが、スループットが大幅に低下するため「スループット低下を防ぐ」という要件に反します。
選択肢DはSQS FIFOキューへの変更でメッセージ順序保証は得られますが、バッチ部分失敗の問題は解決されず、既存のアーキテクチャへの影響も大きく「最小限の変更」という要件に反します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDVAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →