ある企業が AWS 上で稼働する SQS + Lambda のイベント処理システムを運用しています。最近、一部の SQS メッセージが繰り返し処理に失敗し、Lambda 関数が「毒矢（Poison Pill）」メッセージによって繰り返し呼び出され、関数の同時実行数の上限に達してしまう問題が発生しています。また、失敗したメッセージの内容を後で分析する必要があります。最も適切な解決策はどれですか？
- A. Lambda 関数のタイムアウトを延ばし、エラーハンドリングコードを追加してすべての例外をキャッチする
- B. Lambda 関数をスケジュール実行に変更し、1 時間ごとに SQS キューをポーリングして全メッセージを一括処理する
- C. SQS キューのデッドレターキュー（DLQ）を設定し、最大受信回数（maxReceiveCount）を超えたメッセージを DLQ に移動する。Lambda の最大バッチウィンドウと最大バッチサイズを調整し、バッチ内の一部失敗でメッセージを個別に DLQ に移動できるよう Lambda イベントソースマッピングの「失敗時の報告」機能を有効化する
- D. SQS の可視性タイムアウトをゼロに設定して失敗したメッセージを即座に再処理できるようにし、Lambda の予約済み同時実行数を増やす
解答と解説を見る
正解: C
SQS の DLQ と maxReceiveCount の設定により、一定回数失敗したメッセージが自動的に DLQ に移動し、メインキューとの無限ループを防ぎます。Lambda イベントソースマッピングの「失敗時の報告（Report batch item failures）」機能を有効化することで、バッチ内の一部のメッセージのみが失敗した場合、その失敗したメッセージだけを SQS の可視性タイムアウト外にし、成功したメッセージは削除されます。DLQ に移動したメッセージは後で分析できます。 A: タイムアウトの延長と例外キャッチだけでは Poison Pill メッセージの無限再試行ループを防止できず、DLQ の設定がなければメッセージは永続的にメインキューに残り続けます。 D: 可視性タイムアウトをゼロにすると失敗メッセージが即座に再表示され、より多くの Lambda 呼び出しを引き起こします。同時実行数の増加も問題を悪化させます。 B: スケジュール実行への変更はイベント駆動アーキテクチャの利点を失い、1 時間ごとの処理では遅延が大幅に増加します。
📚 関連サービスの解説: Amazon SQS ・ AWS Lambda