メッセージの消費に失敗すると、メッセージリトライが自動的にトリガーされます。最大リトライ回数に達してもメッセージの消費に失敗し続ける場合、そのメッセージはデッドレターメッセージになります。ApsaraMQ for RocketMQ では、これらのデッドレターメッセージを指定したトピックに保存し、その後のビジネスリカバリや遡及的分析に利用できます。このトピックでは、デッドレターメッセージの利用シーン、デッドレターポリシー、制限事項、設定方法、および注意事項について説明します。
利用シーン
-
デッドレターメッセージの典型的な処理シーン
メッセージリトライが失敗した後、デッドレターメッセージを指定のデッドレタートピックに保存します。別のコンシューマーグループを作成してこれらのメッセージを消費・処理することで、エラーパスの処理やデッドレター分析が可能になります。
-
デッドレターメッセージの典型的な誤用
デッドレターメッセージを複数のレイヤーを経由してルーティングしたり、元のトピックにダンプバックしたりすると、リトライのループに再突入する可能性があります。これにより、雪崩効果が引き起こされることがあります。
デッドレターポリシー
メッセージがデッドレターになるとき
メッセージが最大リトライ回数に達しても正常に消費されない場合、そのメッセージは配信を停止し、デッドレターメッセージになります。
デッドレターメッセージの保持ルール
ApsaraMQ for RocketMQ では、デフォルトで、デッドレターメッセージは保持されず、デッドレター状態になった後に破棄されます。
コンソールでデッドレターメッセージの保持を有効にできます。有効にすると、デッドレターメッセージはデッドレタートピックと呼ばれる指定のトピックに保存されます。詳細については、「デッドレターメッセージの保持ルールの設定」をご参照ください。
デッドレターメッセージは、新しいメッセージとしてデッドレタートピックに保存されます。そのプロパティは次のように変更されます：
-
メッセージ ID：デッドレターメッセージがデッドレタートピックに保存される際に、新しいメッセージ ID が生成されます。
-
ユーザー定義属性、メッセージ本文、およびその他のユーザー提供情報は変更されません。
-
デッドレターメッセージの保存期間は、デッドレタートピックに入った時点からカウントが開始されます。たとえば、メッセージが 13:00:00 にサーバーに送信され、2 時間後 (15:00:00) に消費とリトライに失敗した場合、その保存期間は 15:00:00 から始まります。
制限事項
-
デッドレタートピックは、通常メッセージトピックまたは順序付きメッセージトピックである必要があります。トランザクションメッセージトピックおよびスケジュールメッセージトピックは、デッドレタートピックとして使用できません。
-
元のメッセージのトピックをデッドレタートピックとして使用することはできません (循環リトライと雪崩効果を防ぐため)。転送中にシステムがデッドレタートピックと元のトピックが一致することを検出した場合、メッセージは破棄されます。
-
異なるトピックからのデッドレターメッセージを、同じデッドレタートピックに保存できます。
-
コンシューマーグループを削除しても、関連付けられたデッドレタートピックは削除されません。
-
トピックがデッドレターポリシーによって参照されている場合、そのトピックを削除する前にこのポリシーを削除する必要があります。
デッドレターメッセージの保持ルールの設定
ApsaraMQ for RocketMQコンソールで、デッドレターメッセージを保持するかどうかを設定できます。
この設定にアクセスするには：
-
インスタンス数 ページで、ターゲットインスタンス名をクリックします。
-
左側のナビゲーションウィンドウで グループ をクリックします。グループ ページで、グループの作成 をクリックします。
[グループの作成] ダイアログボックスで、[詳細設定] セクションを展開して、[消費リトライポリシー] (デフォルト：エクスポネンシャルバックオフ)、[最大リトライ回数] (デフォルト：16)、および [デッドレターメッセージの保持] トグルスイッチを設定します。このトグルスイッチがオフの場合、リトライ上限を超えたメッセージは破棄されます。
デッドレターメッセージの可観測性メトリック
メトリックの説明
|
メトリックタイプ |
メトリック |
|
rocketmq_send_to_dlq_messages：1分あたりのデッドレター状態になるメッセージ数 |
|
|
メトリックの使用
ApsaraMQ for RocketMQ は、デッドレターメッセージのアラート設定をサポートしています。これにより、ビジネスフィードバックが発生する前に異常を検出し、さらにダッシュボードのメトリックを確認してその原因を特定するのに役立ちます。
-
利用シーン 1：1分あたりのデッドレター状態になるメッセージ数を表示する
[ダッシュボード] で、[1分あたりのデッドレター状態になるメッセージ数] のゲージを確認します。また、[Cloud Monitor] を使用して、[1分あたりのデッドレター状態になるメッセージ数 (GroupId & Topic)] のアラートを設定することもできます。
-
利用シーン 2：未処理のデッドレターメッセージがいくつ残っているかを確認する
デッドレターメッセージが指定のトピックに保存された後、[ダッシュボード] でそのデッドレタートピックの [消費のバックログ] メトリックを表示します。または、[Cloud Monitor] を使用して、[メッセージのバックログ (GroupId & Topic)] のアラートを作成することもできます。
ベストプラクティス
コンシューマーが元のトピック情報を取得する方法
-
オプション 1：各デッドレタートピックを元のトピックと 1 対 1 でマッピングする。
たとえば、元のトピックが testTopic の場合、デッドレタートピックを DLQ-testTopic と命名します。
-
オプション 2：元のトピック名をカスタムメッセージ属性に埋め込む。例：
messageBuilder.addProperty("originalTopic","testTopic")
デッドレター処理を主要なビジネスロジックから分離する
デッドレターメッセージは、通常のビジネスフローでリトライしても失敗したメッセージです。通常の操作を妨げないように、これらは個別に処理してください。
-
デッドレタートピックは、元のメッセージトピックとは異なる必要があります。元のトピックを再利用すると、デッドレターメッセージが消費ループに再突入し、通常のコンシューマーグループをブロックして雪崩効果を引き起こす可能性があります。
-
主要な本番フローのコンシューマーグループを使用してデッドレターメッセージを消費しないでください。これは通常のメッセージ処理を妨げる可能性があります。