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

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

Amazon SQS デッドレターキュー

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

重要

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

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

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

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

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

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

重要

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

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

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

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

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

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

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

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

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

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

標準キュー

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

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

注記

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

FIFO キュー

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

注記

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

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

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

注記

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

デッドレターキューを使用して、メッセージの数を減らし、システムを 毒-丸のメッセージ (受信はできるが処理できないメッセージ)。

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

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

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

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

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

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

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

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

  • コンソールで対応するキューのメッセージを表示しないでください。

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

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