Amazon SQS デッドレターキュー - Amazon Simple Queue Service

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon SQS デッドレターキュー

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

重要

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

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

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

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

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

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

重要

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

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

メッセージの有効期限は、常に元のエンキュータイムスタンプに基づきます。メッセージがデッドレターキューに移動されると、エンキューのタイムスタンプは変更されません。-ApproximateAgeOfOldestMessageメトリックは、メッセージがデッドレターキューに移動した日時を示します。ないメッセージが最初に送信された時点。たとえば、メッセージがデッドレターキューに移動される前に、元のキューで 1 日を費やしていると仮定します。デッドレターキューの保持期間が 4 日である場合、メッセージは 3 日後にデッドレターキューから削除され、ApproximateAgeOfOldestMessageは3日です。したがって、デッドレターキューの保持期間を常に元のキューの保持期間よりも長く設定することをお勧めします。

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

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

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

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

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

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

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

標準キュー

標準キューは、保持期間が終わるまでメッセージの処理を継続します。このメッセージの継続的な処理により、処理できないメッセージによってキューがブロックされる可能性が最小限になります。また、継続的なメッセージ処理により、キューの復旧時間が短縮されます。

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

注記

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

FIFO キュー

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

注記

FIFO キューでは、保留メッセージは少数です。したがって、FIFO キューがメッセージによってブロックされないようにするには、アプリケーションがメッセージ処理を正しく処理するようにしてください。

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

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

注記

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

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

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

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

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

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

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

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

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

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

  • 対応するキューのメッセージはコンソールに表示されません。

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

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