翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon SQSデッドレターキュー
Amazon SQSは、デッドレターキュー(DLQ)をサポートしています。このキューは、正常に処理 (消費) できないメッセージの送信先として、他のキュー (ソースキュー) をターゲットにすることができます。デッドレターキューは、未使用のメッセージを分離して、処理が成功しなかった理由を調べることができるため、アプリケーションやメッセージングシステムのデバッグに役立ちます。Amazon SQS コンソールを使用したデッドレターキューの設定についての詳細は、「デッドレターキュー(コンソール)を設定」を参照してください。コンシューマアプリケーションをデバッグするか、コンシューマーアプリケーションがメッセージを使用できるようになったら、デッドレターキューのリドライブ機能をクリックして、メッセージをソースキューに戻すことができます。
重要
Amazon SQSはデッドレターキューを自動的に作成しません。デッドレターキューとして使用する前に、最初にキューを作成する必要があります。
トピック
デッドレターキューのしくみ
場合によっては、プロデューサーまたはコンシューマーアプリケーション内のエラー条件、予期しない状態変化によるアプリケーションコードでの問題発生など、さまざまな問題のためにメッセージを処理できないことがあります。たとえば、ユーザーが特定の製品 IDを持つウェブ注文を行ったが、製品 IDが削除された場合、ウェブストアのコードが失敗してエラーが表示され、注文リクエストを含むメッセージがデットレターキューに送信されます。
また、プロデューサーとコンシューマーの間で通信に使用されるプロトコルの要素を解釈できず、メッセージの破損や消失につながることもあります。コンシューマーのハードウェアエラーによってメッセージのペイロードが破損することもあります。
リドライブポリシーでは、ソースキュー、デッドレターキュー,を指定します。また、ソースキューのコンシューマーが指定回数、メッセージの処理を失敗した場合にAmazon SQSによってソースキューからデッドレターキューにメッセージが移動される条件も指定します。maxReceiveCountはデッドレターキューに移動する前に、コンシューマがキューから削除せずにメッセージを受信しようとする回数です。maxReceiveCount1などの低い値を設定して、メッセージの受信に失敗した場合にはメッセージがデッドレターキューに移動されます。このような障害には、ネットワークエラーやクライアントの依存関係エラーが含まれます。システムがエラーに対して回復力を持つようにするには、maxReceiveCount十分な再試行ができるように高めに設定してください。
リドライブ許可ポリシーはデッドレターキューにアクセスできるソースキューを指定します。このポリシーは、潜在的なデッドレターキューに適用されます。すべての送信元キューを許可するか、特定のソースキューを許可するか、すべての送信元キューを拒否するかを選択できます。デフォルトでは、すべてのソースキューがデッドレターキューを使用することを許可しています。特定のキューを許可することを選択した場合（byQueueオプション) の場合、ソースキューのAmazon リソースネーム (ARN)を使用して最大10個のソースキューを指定できます。denyAllを指定した場合、キューをデッドレターキューとして使用することはできません。
デッドレターキューを指定するには、コンソールまたは AWS SDK を使用します。これは、デッドレターキューにメッセージを送信する各キューに対して行う必要があります。1つのデッドレターキューを、同じタイプの複数のキューの送信先とすることができます。詳しい情報については「デッドレターキュー(コンソール)を設定」と、CreateQueue または SetQueueAttributes アクションの RedrivePolicy および RedriveAllowPolicy 属性をご参照ください。
重要
FIFOキューのデッドレターキューは、FIFOキューでもある必要があります。同様に、標準キューのデッドレターキューは、標準キューでもある必要があります。
デッドレターキューと、デッドレターキューにメッセージを送信する他のキューの作成には、同じAWS アカウントを使用する必要があります。また、デッドレターキューは、そのデッドレターキューを使用する他のキューと同じリージョンに存在する必要があります。たとえば、米国東部（オハイオ）リージョンにキューを作成し、そのキューでデッドレターキューを使用する場合、2番目のデッドレターキューも米国東部（オハイオ） リージョンに存在している必要があります。
スタンダードキューでは、メッセージの有効期限は、常に元のエンキューのタイムスタンプに基づきます。デッドレターキューに移動すると、エンキューのタイムスタンプは変更されません。ApproximateAgeOfOldestMessageメトリックは、メッセージが最初に送信された日ではなく、メッセージがデッドレターキューに移動した日を示します。たとえば、メッセージがデッドレターキューに移動される前に、元のキューで1日費やすと仮定します。デッドレターキューの保持期間が4日間である場合、メッセージは3日後にデッドレターキューから削除され、ApproximateAgeOfOldestMessageは3日間です。したがって、デッドレターキューの保持期間を、元のキューの保持期間よりも長く設定することがベストプラクティスです。
FIFO キューでは、メッセージがデッドレターキューに移動すると、エンキューのタイムスタンプがリセットされます。ApproximateAgeOfOldestMessage メトリクスは、メッセージがデッドレターキューに移動した日を示します。上記の同じ例では、メッセージは 4 日後にデッドレターキューから削除され、ApproximateAgeOfOldestMessage は 4 日間です。
デッドレターキューを使用するメリット
デッドレターキューの主なタスクは、未使用のメッセージのライフサイクルを処理することです。デッドレターキューは処理が成功しなかった理由を調べるために、正しく処理できないメッセージをサイドに置いて分離することができます。デッドレターキューをセットアップすることにより、次のことができます。
-
デッドレターキューに移動したメッセージに関するアラームを設定する。
-
デッドレターキューにメッセージが移動する原因となった例外をログを調べる。
-
デッドレターキューに移動したメッセージの内容を分析し、ソフトウェアや、プロデューサーまたはコンシューマーのハードウェアに関する問題を診断する。
-
コンシューマーがメッセージを処理するために十分な時間が設定されているかどうかを調べる。
キューの種類によるメッセージエラーの処理
スタンダードキュー
スタンダードキューは、保持期間が終わるまでメッセージの処理が継続します。このことで、メッセージが継続的に処理されるため、処理できないメッセージによりキューがブロックされる可能性を最小限に抑えることができます。連続メッセージ処理により、キューの高速復旧が可能になります。
大量のメッセージを処理するシステムでは、コンシューマーが承認と削除に繰り返し失敗するメッセージが多数あると、コストが増加し、ハードウェアへの負荷が大きくなる可能性があります。失敗となるメッセージを期限切れまで処理しようとする代わりに、処理を数回試みた後で、デッドレターキューに移動する方が合理的です。
注記
スタンダードキューは、多数の保留メッセージが許容されます。ただし、メッセージの大多数が送信されず、デッドレターキューに送信されない場合、有効なメッセージの処理速度が低下する可能性があります。このため、キューの効率を維持するには、アプリケーションが正しくメッセージを処理できているかを確認してください。
FIFOキュー
FIFOキューは、メッセージグループからメッセージを順番に送信することで、ジャストワンス処理を実現します。このため、コンシューマーは順序付けされたメッセージを別のメッセージグループから連続して取得できますが、最初のメッセージグループは、キューをブロックしているメッセージが正しく処理されるかデッドレターキューに移動するまで、使用不可の状態になります。
注記
FIFO キューで許容される保留メッセージは少数です。このため、メッセージによってFIFOキューがブロックされないようにするには、アプリケーションが正しくメッセージを処理できているか確認してください。
メッセージが FIFO キューから FIFO DLQ に移動されると、元のメッセージの重複排除 ID は元のメッセージの ID に置き換えられます。これは、重複排除 ID を共有している 2 つの独立したメッセージが DLQ 重複排除によって保存されなくなることがないようにするためです。
デッドレターキューが適している用途
デッドレターキューは、 スタンダードキューと組み合わせて使用してください。アプリケーションが順序に依存しない場合は常に、デッドレターキューを活かすことができます。デッドレターキューは、正しくないメッセージ送信操作に関するトラブルシューティングにも役立ちます。
注記
デッドレターキューを使用している場合もキューのモニタリングを継続し、一時的な理由で失敗したメッセージの送信を再試行できます。
メッセージ数を減らし、システムで ポイズンピルメッセージ (受信されたが処理できないメッセージ) が発生する可能性を抑えるためにデッドレターキューを使用してください。
メッセージの送信を無期限に再試行できる状態にしておく必要がある場合は、スタンダード キューと共にデッドレターキューを使用しないでください。たとえば、プロセスがアクティブまたは利用可能になるまで待機する必要があるプログラムでは、デッドレターキューを使用しないでください。
メッセージまたは操作の正確な順序を維持する必要がある場合は、FIFOキューでデッドレターキューを使用しないでください。たとえば、ビデオ編集スイートで Edit Decision List (EDL)の指示でデッドレターキューを使用しないでください。編集の順序が変わると、後続の編集作業のコンテキストが変わります。
デッドレターキューからメッセージを移動するには
デッドレターキューのリドライブを使用すると、未使用のメッセージのライフサイクルを管理できます。標準または FIFO デッドレターキューの未使用メッセージで使用可能な属性および関連するメタデータを調査したら、メッセージをソースキューに戻すことができます。デッドレターキューのリドライブでは、メッセージを移動しながらバッチ処理することで API コールの請求額を削減できます。
リドライブタスクは Amazon SQSのSendMessageBatch、ReceiveMessage、 およびDeleteMessageBatchを使用し、ユーザーに代わってAPIを使用してメッセージをリドライブします。したがって、すべてのリドリブンメッセージは、新しいメッセージとともにmessageid、enqueueTime、および保持期間となった新しいメッセージと見なされます。デッドレターキューのリドライブの設定料金は、呼び出された API 呼び出しの数と、Amazon SQS の設定料金
デフォルトでは、デッドレターキューのリドライブは、デッドレターキューからソースキューにメッセージを移動します。ただし、どちらのキューも同じタイプであれば、他のキューをリドライブの宛先として設定することもできます。例えば、デッドレターキューが FIFO キューの場合、リドライブの宛先キューも FIFO キューでなければなりません。さらに、リドライブベロシティを設定してAmazon SQSがメッセージを移動するレートを設定できます。デッドレターキューのリドライブを設定する手順については、「デッドレターキューを設定します。」を参照してください。
注記
Amazon SQSは、デッドレターキューからメッセージをリドライブするときにメッセージのフィルタリングと変更をサポートしていません。
デッドレターキューのリドライブタスクは、最大36時間実行できます。Amazon SQSでは、アカウントごとに最大100通のアクティブなリドライブタスクがサポートされます。
FIFO デッドレターキューからメッセージをリドライブしても、メッセージ GroupID と DeDuplicationID は同じままで、メッセージには新しい MessageID が割り当てられます。
Amazon SQS デッドレターキューは、メッセージを最も古いメッセージから受信順にリドライブします。ただし、宛先キューは、リドライブされたメッセージと他のプロデューサーからの新しいメッセージを、受信した順序に従って取り込みます。例えば、プロデューサーが送信元の FIFO キューにメッセージを送信しているときに、デッドレターキューからリドライブされたメッセージを同時に受信した場合、リドライブされたメッセージはプロデューサーからの新しいメッセージと混ざり合います。
デッドレターキューのトラブルシューティング
場合によっては、Amazon SQSのデッドレターキューの動作が必ずしも想定どおりではないこともあります。このセクションでは、一般的な問題の概要とそれらの解決方法を説明します。
コンソールを使用してメッセージを表示すると、メッセージがデッドレターキューに移動されることがあります。
Amazon SQSは、対応するキューの リドライブ ポリシーに対して コンソールでのメッセージの表示回数をカウントします。このため、コンソール にメッセージが表示される回数が、対応するキューの リドライブ ポリシーで指定された回数に達すると、そのメッセージは対応するキューのデッドレターキューに移動されます。
この動作を調整するには、次のオプションがあります。
-
対応するキューの Redrive ポリシーで、[Maximum Receives] 設定の値を大きくします。
-
対応するキューのメッセージがコンソールに表示されないようにします。
デッドレターキューの NumberOfMessagesSent と NumberOfMessagesReceived が一致しない
手動でデッドレターキューに送信したメッセージは、NumberOfMessagesSent メトリクスによってキャプチャされます。ただし、処理の試行が失敗した結果としてデッドレターキューにメッセージが送信された場合、メトリクスによってキャプチャされません。したがって、NumberOfMessagesSent と NumberOfMessagesReceived の値が異なることもあります。
デッドレターキューのリドライブ作成と設定について
デッドレターキューのリドライブでは、Amazon SQSがデッドレターキューからメッセージを受信し、送信先キューにメッセージを送信するために適切な権限を設定する必要があることに注意してください。権限が不十分な場合、ソースキューへのデッドレターキューのリドライブはメッセージのリドライブを開始せず、タスクが失敗する可能性があります。メッセージリドライブタスクのステータスを表示して、問題を修正し、再試行できます。
