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

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

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

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

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

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

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

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

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

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

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

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

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