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

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

Amazon SQS デッドレターキュー

Amazon SQS はデッドレターキュー (DLQ) をサポートしており、このキューは、正常に処理 (消費) できないメッセージのターゲットとして、他のキュー (ソースキュー) が使用することができます。処理が成功しない理由を断定できるように未消費メッセージを分離できるため、デッドレターキューは、アプリケーションやメッセージングシステムのデバッグに役立ちます。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 つのデッドレターキューを、同じタイプの複数のキューの送信先とすることができます。詳しい情報については「デッドレターキュー(コンソール)を設定」と、CreateQueue または SetQueueAttributes アクションの RedrivePolicy および RedriveAllowPolicy 属性をご参照ください。

重要

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

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

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

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

デッドレターキューの主なタスクは、未消費メッセージのライフサイクルを処理することです。デッドレターキューは、処理が成功しなかった理由を断定するため、正しく処理できないメッセージを保留にして分離できます。デッドレターキューをセットアップすることにより、次のことができます。

  • デッドレターキューに移動されたメッセージにアラームを設定します。

  • ログを閲覧してメッセージがデッドレターキューに移動される例外的な原因を調べます。

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

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

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

標準キュー

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

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

注記

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

FIFO キュー

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

注記

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

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

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

注記

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

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

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

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

メッセージをデッドレターキューから移動

ではを使用できます。デッドレターキュー再ドライブを使用して、未使用メッセージのライフサイクルを管理します。デッドレターキュー内の標準の未使用メッセージで使用可能な属性および関連するメタデータを調査した後、メッセージをソースキューに再ドライブできます。デッドレターキューのリドライブは、移動中にメッセージをバッチ処理することで、API 呼び出しの請求を削減します。

リドライブタスクは Amazon SQS の SendMessageBatchReceiveMessageDeleteMessageBatch API をユーザーに代わってメッセージをリドライブします。したがって、リドライブされたすべてのメッセージは、新しい messageidenqueueTime、保持期間を持った新しいメッセージとして見なされます。デッドレターキューのリドライブ料金は呼び出された API コール数と Amazon SQS 料金に基づいた請求書を採用します。

デフォルトでデッドレターキューのリドライブは、メッセージをデッドレターキューからソースキューに移動します。ただし、他の標準キューをリドライブの宛先として設定することもできます。さらに、リドライブ速度を設定して Amazon SQS がメッセージを移動するレートを設定できます。Amazon SQS コンソールを使用してデッドレターキューのリドライブを設定する手順については「デッドレターキューリドライブを設定します。(コンソール)」をご参照ください。

注記

Amazon SQS は、Amazon SQS コンソールの標準キューに対してのみ、デッドレターキューのリドライブをサポートします。

Amazon SQS は、デッドレターキューからメッセージをリドライブするときにフィルタリングと変更をサポートしていません。

デッドレターキューのリドライブタスク実行は最大 36 時間かかる場合があります。Amazon SQS は、アカウントごとに最大 100 件のアクティブリドライブタスクをサポートします。

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

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

コンソールでメッセージを閲覧する場合、メッセージがデッドレターキューに移動される可能性があります。

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

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

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

  • コンソールで対応するキューのメッセージの閲覧を避けてください。

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

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

Amazon SQS コンソールを使用してデッドレターキューのリドライブ作成と設定の詳細については

デッドレターキューのリドライブは、デッドレターキューからメッセージを受信して、送信先キューにメッセージを送信するために Amazon SQS に適切な許可を設定する必要があることにご留意ください。許可が不十分な場合、デッドレターキューからソースキューへのリドライブはメッセージのリドライブを開始せず、タスクが失敗する可能性があります。メッセージのリドライブタスクのステータスを閲覧して、問題を修正してもう一度試すことができます。