ある金融サービス企業が SQS Standard キューをイベントソースとする Lambda 関数で決済トランザクションを処理しています。Lambda 関数は下流の決済処理 API を呼び出しますが、この API は最大 28 秒かかることがあります。現在の設定は以下の通りです。 ・Lambda タイムアウト：30 秒 ・SQS キューの可視性タイムアウト（Visibility Timeout）：30 秒 ・DLQ（Dead Letter Queue：処理失敗メッセージの退避キュー）：未設定 負荷テスト中に以下の問題が確認されました。 ①一部の決済が二重請求されている ②下流 API が完全停止中、Lambda が繰り返し失敗しているにもかかわらず失敗数や失敗したトランザクション内容を把握する手段がなく、メッセージが保持期限切れ後に警告なく消失するリスクがある これらの問題の根本原因と正しい修正策の組み合わせはどれですか？
正解の根本原因は、可視性タイムアウト（30秒）が Lambda タイムアウト（30秒）と同値である点です。 AWS は可視性タイムアウトを Lambda 関数タイムアウトの少なくとも6倍に設定することを推奨しています（30秒×6＝180秒）。同値の場合、API が最大28秒かかる処理の途中でメッセージが SQS キューで再び可視状態となり、別の Lambda インスタンスが同じメッセージを処理して二重請求が発生します。また DLQ とリドライブポリシーがないと、失敗メッセージはデフォルト保持期間（4日）経過後に警告なく削除されます。DLQ の滞留数（ApproximateNumberOfMessagesVisible）に CloudWatch アラームを設定することで失敗の可視性が確保されます。 選択肢Aは、Lambda スロットリングは処理遅延の一因ですが二重請求や失敗メッセージ消失の根本原因ではありません。 選択肢Cは、FIFO のコンテンツベース重複排除は短時間の重複を排除するだけで、可視性タイムアウトのレースコンディションを解消せず大幅なアーキテクチャ変更も要します。 選択肢Dは、冪等性の実装は有効な防御ですが根本原因を修正しておらず、DLQ 未設定による失敗メッセージ追跡・消失リスクも残ります。