Amazon SQS デッドレターキューとは

正常に処理 (消費) できないメッセージのターゲットとして、他のキュー (ソースキュー) が使用することができます。 処理が成功しない理由を断定できるように未消費メッセージを分離できるため、デッドレターキューは、アプリケーションやメッセージングシステムのデバッグに役立ちます。

コンシューマアプリケーションをデバッグ処理、またはコンシューマーアプリケーションがメッセージ消費に使用できる場合、デッドレターキューの再処理機能を使用して、Amazon SQS コンソールのボタンをクリックするだけでメッセージをソースキューに戻すことができます。

Amazon SQS は自動的にデッドレターキューを作成しません。デッドレターキューとして使用する前、最初にキューを作成する必要があります。

デッドレターキューのしくみ

プロデューサーまたはコンシューマアプリケーション内のエラー条件、またはアプリケーションコードに問題が発生する予期しない状態変化など、さまざまな問題が原因でメッセージが処理できない場合もあります。たとえば、ユーザーが特定の製品 ID を持つウェブ注文を行ったが、製品 ID が削除された場合、ウェブストアのコードが失敗してエラーが表示され、注文リクエストを含むメッセージがデットレターキューに送信されます。 また、プロデューサーとコンシューマーの間で通信に使用されるプロトコルの要素を解釈できず、メッセージの破損や消失につながることもあります。また、コンシューマのハードウェアエラーによってメッセージのペイロードが破損する可能性もあります。

リドライブポリシー

ソースキューとデッドレターキューを指定し、さらにソースキューのコンシューマが一定回数でメッセージ処理に失敗した場合、Amazon SQS がメッセージをソースキューからデッドレターキューへ移動する条件を指定します。maxReceiveCount は、デッドレターキューに移動する前に、コンシューマがキューから削除せずにメッセージを受信しようとする回数です。maxReceiveCount を 1 などの低い値を指定すると、メッセージの受信に失敗し、そのメッセージをデッドレターキューに移動します。このような障害には、ネットワークエラーやクライアント依存エラーが含まれます。システムがエラーに対する回復力を確保するため、maxReceiveCount に十分な再試行を実行できるほど高い数値を設定します。

許可リドライブポリシー

デッドレターキューにアクセスできるソースキューを指定します。このポリシーは潜在的なデッドレターキューに適用されます。すべてのソースキューを許可、特定のソースキューを許可、すべてのソースキューを拒否するの 3 つから選択できます。デフォルトではすべてのソースキューがデッドレターキューを使用できるようにします。特定のキュー (byQueue のオプションを使用) の許可を選択した場合、ソースキュー Amazon リソースネーム (ARN) を使用するソースキューを最大 10 件指定できます。denyAll を指定した場合、キューをデッドレターキューとして使用できません。

デッドレターキューを指定する場合、コンソールまたは AWS SDK for Java を使用できます。これは、デッドレターキューにメッセージを送信する各キューに対して行う必要があります。1 つのデッドレターキューを、同じタイプの複数のキューの送信先とすることができます。