デッドレターキューとは何ですか?
デッドレターキュー (DLQ) は、エラーのためにソフトウェアシステムが処理できないメッセージを一時的に保存する特別なタイプのメッセージキューです。メッセージキューは、分散システムにおける非同期通信をサポートするソフトウェアコンポーネントです。これにより、ソフトウェアサービス間でメッセージを任意の量で送信でき、メッセージの受信者が常に待機している必要がなくなります。デッドレターキューは特に、宛先が指定されていない、または目的の受信者が処理できない、エラーを含むメッセージを格納します。
デッドレターキューはなぜ重要なのですか?
デッドレターキュー (DLQ) は通常のメッセージキューと並んで存在します。誤ったメッセージや失敗したメッセージの一時的な保存場所として機能します。DLQ は、ソースキューが未処理のメッセージであふれるのを防ぎます。
例えば、通常のメッセージキューと DLQ を備えたソフトウェアを考えてみましょう。ソフトウェアは通常のキューを使用して、宛先に送信する予定のメッセージを保持します。受信者が送信メッセージへの応答またはその処理に失敗した場合、ソフトウェアはそのメッセージをデッドレターキューに移動します。
メッセージが DLQ パイプラインに移動する場合、メッセージの内容の誤りと、受信者のシステムの変更の 2 つの原因が考えられます。
誤ったメッセージの内容
送信されたメッセージに誤りがある場合、メッセージは DLQ に移動します。ハードウェア、ソフトウェア、ネットワークの状態により、送信データが破損する可能性があります。例えば、ハードウェアの干渉により、送信中に情報の一部がわずかに変化します。予期しないデータ破損により、受信者はメッセージを拒否または無視する可能性があります。
受信者のシステムの変更
また、受信側のソフトウェアで送信者が気付いていない変更が行われた場合、メッセージが DLQ に移動することもあります。例えば、CUST_ID_005 にメッセージを送信して、顧客の情報を更新しようとすることができます。ただし、システムのデータベースから顧客が削除されたことにより、受信者が受信メッセージの処理に失敗する可能性があります。
デッドレターキューにはどのような利点がありますか?
次に、デッドレターキュー (DLQ) の利点について説明します。
通信コストの削減
通常のメッセージキューまたは標準メッセージキューは、保存期間が終了するまでメッセージの処理を続けます。これにより、メッセージを継続的に処理でき、キューがブロックされる可能性を最小限に抑えることができます。
ただし、システムが何千ものメッセージを処理する場合、エラーメッセージの数が多いと、通信オーバーヘッドコストが増加し、通信システムに負担がかかります。失敗しているメッセージについては有効期限が切れるまで処理を試みるより、処理を数回試みた後にデッドレターキューに移動する方がよいでしょう。
トラブルシューティングの改善
誤ったメッセージを DLQ に移動すると、デベロッパーはエラーの原因の特定に集中できます。受信者がメッセージを処理できなかった理由を調査し、修正を適用し、メッセージの配信を新たに試みることができます。
例えば、バンキングソフトウェアでは、毎日何千ものクレジットカード申請書をバックエンドシステムに送信して承認を求めることがあります。そこから、バックエンドシステムはアプリケーションを受信しますが、情報が不完全なため、すべてのアプリケーションを処理することはできません。ソフトウェアでは、IT チームが問題を解決するまでメッセージを DLQ に移動させるため、何度も試行を繰り返す必要はありません。これにより、システムはパフォーマンスの問題なしに残りのメッセージを処理して配信できます。
デッドレターキューはどのような場合に使用すべきですか?
システムに次の問題がある場合は、デッドレターキュー (DLQ) を使用できます。
順序付けされていないキュー
アプリケーションが順序に依存しない場合は、DLQ を活用できます。DLQ は誤ったメッセージ送信操作のトラブルシューティングに役立ちますが、引き続きキューをモニタリングし、失敗したメッセージを再送信するようにします。
FIFO キュー
先入れ先出し (FIFO) キューでは、メッセージの順序付けが重要です。すべてのメッセージは、次のメッセージを配信する前に処理する必要があります。FIFO キューではデッドレターキューを使用できますが、DLQ の実装も FIFO にする必要があります。
デッドレターキューを使用すべきでないのはどのような場合ですか?
メッセージの送信を無期限に再試行できるようにしたい場合は、順序付けされていないキューでデッドレターキュー (DLQ) を使用しないでください。例えば、依存プロセスがアクティブになるか使用可能になるのをプログラムが待つ必要がある場合は、デッドレターキューを使用しないでください。
同様に、メッセージや操作の正確な順序を変えたくない場合は、先入れ先出し (FIFO) キューを備えたデッドレターキューを使用しないでください。例えば、動画編集スイートでは、編集決定リスト (EDL) に命令が記載されたデッドレターキューを使用しないでください。この場合、編集の順序を変更することで、後続の編集のコンテキストが変更されます。
デッドレターキューの仕組みを教えてください。
ほとんどの場合、デッドレターキュー (DLQ) は通常のメッセージキューと同じように機能します。誤ったメッセージは、処理してエラーの原因を調査するまで保存されます。
次に、DLQ のリドライブポリシーと、メッセージが DLQ に出入りする方法について説明します。
リドライブポリシーの作成
ソフトウェアは、リドライブポリシーを参照してメッセージをデッドレターキューに移動します。リドライブポリシーは、ソフトウェアがメッセージをデッドレターキューに移動するタイミングを決定するルールで構成されています。リドライブポリシーは、主に最大再試行回数を定義することにより、ソースキューとデッドレターキューの相互作用の方法を規制します。
例えば、デベロッパーが最大再試行回数を 1 回に設定した場合、システムは 1 回の試行で失敗した配信をすべて DLQ に移動します。配信の失敗の中には、一時的なネットワークの過負荷またはソフトウェアの問題が原因で発生するものもあります。これにより、DLQ に未配信のメッセージが多数送信されます。適切なバランスをとるために、デベロッパーは最大再試行回数を最適化して、メッセージを DLQ に移動する前にソフトウェアが十分な再試行を行うようにします。
メッセージをデッドレターキューに移す
送信者と受信者の間で配信を試みると、受信者は、いくつかの理由で失敗に直面する可能性があります。
- メッセージが存在しないため、受信者はメッセージを受信できません。
- メッセージにはエラーが含まれています。
- メッセージがキューまたはメッセージの長さの制限を超えています。例えば、一部の受信者は特定のサイズを超えるメッセージを処理できません。
- メッセージの有効期間 (TTL) が期限切れになりました。TTL は、特定のデータパケットがネットワーク上でどれくらいの期間有効かを示す値です。
デッドレターキューからのメッセージの移動
メッセージがデッドレターキューに移動すると、デベロッパーは誤ったメッセージを調べて原因を特定します。DLQ のメッセージには、今後同様の問題が再発するのを防ぐための貴重な情報が含まれている可能性があります。デベロッパーが問題を分析して修正すると、システムはメッセージを DLQ からソースキューに移動します。これにより、送信者はメッセージの処理を続行できます。
AWS はデッドレターキューの要件をどのようにサポートできますか?
Amazon Simple Queue Service (Amazon SQS) は、分散システム間でメッセージを大規模に交換するためのスケーラブルなアプローチを提供します。デベロッパーは Amazon SQS を使用して、フルマネージドな標準キューと先入れ先出し (FIFO) キューを備えた信頼性の高いウェブアプリケーションを構築します。
Amazon SQS のその他の利点は次のとおりです。
- Amazon SQS では、システムがメッセージキューをいくつでも作成できる
- デベロッパーはメッセージを一括して転送できるため、コスト効率が向上する
- Amazon SQS はメッセージロックをサポートしているため、複数のコンピュータが同じメッセージを同時に処理することはできない
今すぐ AWS アカウントを作成して Amazon Web Services (AWS) の使用を開始しましょう。
