Amazon Simple Queue Service
開発者ガイド

Amazon SQS デッドレターキュー

Amazon SQS は、デッドレターキューをサポートしています。このキューは、正常に処理 (消費) できないメッセージの送信先として、他のキュー (ソースキュー) が使用することができます。問題のあるメッセージを分離して、処理が成功しない理由を調べることができるため、デッドレターキューは、アプリケーションやメッセージングシステムのデバッグに役立ちます。AWS マネジメントコンソール または AWS SDK for Java (および CreateQueueSetQueueAttributesGetQueueAttributes の各アクション) を使用したキューの作成およびデッドレターキューの設定については、「デッドレターキューを設定する」を参照してください。

重要

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

場合によっては、プロデューサーまたはコンシューマーアプリケーション内のエラー条件、予期しない状態変化によるアプリケーションコードでの問題発生など、さまざまな問題のためにメッセージを処理できません。たとえば、ユーザーが特定の製品 ID を持つウェブ注文を行ったが、製品 ID が削除された場合、ウェブストアのコードが失敗してエラーが表示され、注文リクエストを含むメッセージがデットレターキューに送信されます。

また、プロデューサーとコンシューマーの間で通信に使用されるプロトコルの要素を解釈できず、メッセージの破損や消失につながることもあります。コンシューマーのハードウェアエラーによってメッセージのペイロードが破損する可能性もあります。

Redrive ポリシーでは、ソースキューデッドレターキュー,を指定します。また、ソースキューのコンシューマーがメッセージの処理を指定回数失敗した場合に Amazon SQS によってソースキューからデッドレターキューにメッセージが移動される条件も指定します。メッセージの ReceiveCount がキューの maxReceiveCount を超える場合、Amazon SQS はこのメッセージをデッドレターキューに (元のメッセージ ID で) 移動します。たとえば、ソースキューの Redrive ポリシーで maxReceiveCount が 5 に設定されている場合に、ソースキューのコンシューマーがメッセージを削除せず 5 回受信すると、このメッセージは Amazon SQS によってデッドレターキューに移動されます。

デッドレターキューを指定するには、 AWS マネジメントコンソール または AWS SDK for Java を使用します。これは、デッドレターキューにメッセージを送信する各キューに対して行う必要があります。1 つのデッドレターキューを複数のキューの送信先とすることができます。詳細については、「デッドレターキューを設定する」と、 アクション CreateQueue または SetQueueAttributesRedrivePolicy 属性を参照してください。

重要

FIFO キューのデッドレターキューは、FIFO キューでもある必要があります。同様に、スタンダード キューのデッドレターキューは、スタンダード キューでもある必要があります。

デッドレターキューの作成と、デッドレターキューにメッセージを送信する他のキューの作成には、同じ AWS アカウントを使用する必要があります。また、デッドレターキューは、そのデッドレターキューを使用する他のキューと同じリージョンに存在する必要があります。たとえば、米国東部 (オハイオ) リージョンでキューを作成し、そのキューでデッドレターキューを使用する場合、デッドレターキューが 米国東部 (オハイオ) リージョンに存在している必要があります。

メッセージの有効期限は、常に元のキュー追加のタイムスタンプに基づいています。メッセージが dead-letter queue に移動されると、キュー追加のタイムスタンプは変更されません。たとえば、メッセージがデッドレターキューに移動される前に元のキューに 1 日を費やし、デッドレターキューの保存期間が 4 日に設定されている場合、メッセージは 3 日後にデッドレターキューから削除されます。したがって、デッドレターキューの保持期間を元のキューの保持期間よりも長く設定することが、常にベストプラクティスとなります。

デッドレターキューを使用するメリット

デッドレターキューの主なタスクは、メッセージの失敗を処理することです。デッドレターキューを使用すると、正しく処理できないメッセージを分離して、処理が成功しなかった理由を調べることができるというメリットがあります。デッドレターキューをセットアップすることにより、次のことができます。

  • デッドレターキューに配信されたメッセージに関するアラームを設定する。

  • ログを調べて、メッセージがデッドレターキューに配信される原因となった可能性のある例外を特定する。

  • デッドレターキューに配信されたメッセージの内容を分析し、ソフトウェアに関する問題や、プロデューサーまたはコンシューマーのハードウェアに関する問題を診断する。

  • コンシューマーがメッセージを処理するために十分な時間が設定されているかどうかを調べる。

キューの種類によるメッセージエラーの処理

スタンダード キュー

スタンダード キューでは、保持期間が終わるまでメッセージの処理が継続されます。これにより、メッセージが継続的に処理されるため、処理できないメッセージによってキューがブロックされる可能性が最小限になります。また、キューの高速復旧が可能になります。

大量のメッセージを処理するシステムでは、コンシューマーが承認と削除に繰り返し失敗するメッセージが多数あると、コストが増加し、ハードウェアへの付加が大きくなる可能性があります。失敗となるメッセージを期限切れまで処理しようとする代わりに、処理を数回試みた後で、デッドレターキューに移動する方が合理的です。

注記

スタンダード キューでは、多数の保留メッセージが許容されます。ただし、メッセージの大多数が消費されず、デッドレターキューにも送信されないと、有効なメッセージの処理速度が低下する可能性があります。このため、キューの効率を維持するには、アプリケーションでメッセージを正しく処理できているか確認する必要があります。

FIFO キュー

FIFO キューでは、メッセージグループからメッセージを順番に消費することで、処理回数が 1 回に限定されます。このため、コンシューマーは順序付けされたメッセージを別のメッセージグループから連続して取得できますが、最初のメッセージグループは、キューをブロックしているメッセージが正しく処理されるまで、使用不可の状態になります。

注記

FIFO キューで許容される保留メッセージは少数です。このため、メッセージによって FIFO キューがブロックされないようにするには、アプリケーションでメッセージを正しく処理できているか確認する必要があります。

デッドレターキューが適している用途

デッドレターキューは、スタンダード キューと組み合わせて使用してください。アプリケーションが順序に依存しない場合は常に、デッドレターキューのメリットを活かすことができます。デッドレターキューは、正しくないメッセージ送信操作に関するトラブルシューティングにも役立ちます。

注記

デッドレターキューを使用している場合もキューのモニタリングを継続し、一時的な理由で失敗したメッセージの送信を再試行できます。

メッセージ数を減らし、システムで ポイズンピルメッセージ (受信されたが処理できないメッセージ) が発生する可能性を抑えるには、デッドレターキューを使用してください。

メッセージの送信を無期限に再試行できる状態にしておく必要がある場合は、スタンダード キューと共にデッドレターキューを使用しないでください。たとえば、従属プロセスがアクティブまたは使用可能になるまで待機する必要があるプログラムでは、デッドレターキューを使用しないでください。

メッセージまたは操作の正確な順序を維持する必要がある場合は、FIFO キューと共にデッドレターキューを使用しないでください。たとえば、ビデオ編集スイートで Edit Decision List (EDL) 内の指示と共にデッドレターキューを使用しないでください。編集の順序が変わると、後続の編集作業のコンテキストが変わります。

デッドレターキューのトラブルシューティング

場合によっては、Amazon SQS のデッドレターキューの動作が常に想定どおりではないこともあります。このセクションでは、一般的な問題の概要と解決方法を示します。

AWS マネジメントコンソール を使用してメッセージを表示すると、メッセージがデッドレターキューに移動されることがある

Amazon SQS は、対応するキューの Redrive ポリシーに対して AWS マネジメントコンソール でのメッセージの表示回数をカウントします。このため、AWS マネジメントコンソール にメッセージが表示される回数が、対応するキューの Redrive ポリシーで指定された回数に達すると、そのメッセージは対応するキューのデッドレターキューに移動されます。

この動作を調整するには、次のオプションがあります。

  • 対応するキューの Redrive ポリシーで、[Maximum Receives] 設定の値を大きくします。

  • 対応するキューのメッセージが AWS マネジメントコンソール に表示されないようにします。

デッドレターキューの NumberOfMessagesSentNumberOfMessagesReceived が一致しない

手動でデッドレターキューに送信したメッセージは、NumberOfMessagesSent メトリクスによってキャプチャされます。ただし、処理の試行が失敗した結果としてデッドレターキューに送信されたメッセージは、メトリクスによってキャプチャされません。したがって、NumberOfMessagesSentNumberOfMessagesReceived の値が異なることもあります。