Amazon でのデッドレターキューの使用 SQS

Amazon はデッドレターキュー (DLQs) SQSをサポートしています。ソースキューは正常に処理されなかったメッセージをターゲットにできます。 DLQsは、未使用のメッセージを分離して処理が成功しなかった理由を特定できるため、アプリケーションのデバッグに役立ちます。最適なパフォーマンスを得るには、ソースキューと を同じ AWS アカウント およびリージョンDLQ内に保持することがベストプラクティスです。メッセージがデッドレターキューに入ったら、以下の操作を実行できます。

• デッドレターキューにメッセージが移動する原因となったと思われる例外をログで調べる。

• デッドレターキューに移動したメッセージの内容を分析してアプリケーションの問題を診断する。

• コンシューマーがメッセージを処理するための十分な時間を割り当てられていたかどうかを判断する。

• デッドレターキューの再処理を使用して、デッドレターキューからメッセージを移動する。

最初にキューを作成してから、これをデッドレターキューとして設定する必要があります。Amazon SQSコンソールを使用してデッドレターキューを設定する方法については、「」を参照してくださいAmazon SQS コンソールを使用してデッドレターキューを設定する方法について説明します。。デッドレターキューに移動したメッセージにアラームを設定する方法など、デッドレターキューのヘルプについては、「Amazon CloudWatch を使用してデッドレターキューのアラームを作成する」を参照してください。

デッドレターキューのポリシーの使用

再処理ポリシーを使用して maxReceiveCount を指定します。maxReceiveCount は、メッセージがデッドレターキューに移動するまでに、コンシューマがソースキューからメッセージを受信できる回数です。例えば、maxReceiveCount を 1 などの低い値に設定した場合、メッセージの受信に 1 回失敗すると、メッセージはデッドレターキューに移動します。システムがエラーに対して回復力を持つようにするには、十分な再試行ができるように maxReceiveCount を高めに設定してください。

[許可ポリシーの再実行] は、デッドレターキューにアクセスできるソースキューを指定します。デッドレターキューの使用を、すべてのソースキューを許可するか、特定のソースキューを許可するか、すべてのソースキューに拒否するかを選択できます。デフォルトでは、デッドレターキューの使用をすべてのソースキューに許可します。byQueue オプションを使用して特定のキューを許可する場合は、ソースキューの Amazon リソースネーム () を使用して最大 10 個のソースキューを指定できますARN。denyAll を指定すると、キューをデッドレターキューとして使用することはできません。

デッドレターキューのメッセージ保持期間を理解する

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

FIFO キューの場合、メッセージがデッドレターキューに移動されると、エンキューのタイムスタンプがリセットされます。ApproximateAgeOfOldestMessage メトリクスは、メッセージがデッドレターキューに移動した日を示します。上記の同じ例では、メッセージは 4 日後にデッドレターキューから削除され、ApproximateAgeOfOldestMessage は 4 日間です。