デッドレターメッセージのポリシー理解と管理 - ApsaraMQ for RocketMQ

メッセージが最大リトライ回数を超えても消費に失敗した場合、それはデッドレターメッセージになります。デッドレターメッセージが生成されるのは、この条件のみです。デフォルトでは、ApsaraMQ for RocketMQ はデッドレターメッセージを破棄します。回復またはトラブルシューティングのためにそれらを保持するには、デッドレターメッセージ保存機能を有効にして、専用のデッドレタートピックにルーティングします。

仕組み

デッドレターメッセージは、消費リトライのライフサイクルにおける最終状態です。

コンシューマーがメッセージを受信し、その処理に失敗します。
ブローカーは、設定された最大リトライ回数まで配信をリトライします。
すべてのリトライ後もメッセージが失敗した場合、それはデッドレターメッセージになります。

デッドレターメッセージを破棄せずに保持するには、コンソールでデッドレターメッセージ保存機能を有効にします。デッドレターメッセージは、指定されたデッドレタートピックに保存されます。

Dead-letter message flow

デッドレタートピックにメッセージが保存された場合の動作

新しいメッセージ ID が生成されます。
カスタム属性とメッセージ本文は変更されません。
保存期間は、メッセージがデッドレタートピックに保存された時点から開始され、元の配信時間からではありません。たとえば、メッセージが 13:00:00 にブローカーに配信され、15:00:00 にデッドレターメッセージになった場合、その保存期間は 15:00:00 から開始されます。

デッドレターメッセージ保存の有効化

ApsaraMQ for RocketMQ コンソールでデッドレターメッセージ保存を有効にするには、次の手順を実行します。

インスタンス数 ページで、インスタンス名をクリックします。
左側のナビゲーションウィンドウで、グループ をクリックします。グループ ページで、グループの作成 をクリックします。

Console configuration

デッドレターメッセージの処理

専用のコンシューマーグループをデッドレタートピックに購読させ、通常のビジネストラフィックとは別に、失敗したメッセージを消費およびトラブルシューティングします。

元のトピックの追跡

デッドレターメッセージがどのトピックから発生したかを特定するには、次のいずれかのアプローチを使用します。

命名規則: デッドレタートピック名を元のトピック名にマッピングします。たとえば、元のトピックが testTopic の場合、デッドレタートピック名を DLQ-testTopic とします。
カスタム属性: メッセージプロパティに元のトピックを含めます。
```
  messageBuilder.addProperty("originalTopic", "testTopic")
```

メッセージアバランチの回避

不適切なデッドレター処理は、カスケード障害を引き起こす可能性があります。

元のトピックをデッドレタートピックとして使用しないでください。 これにより、デッドレターメッセージが元のトピックと失敗した消費の間で無期限に循環するリトライループが作成されます。システムがデッドレタートピックが元のトピックと一致することを検出した場合、メッセージは破棄されます。
通常のメッセージを処理するコンシューマーグループでデッドレターメッセージを消費しないでください。 デッドレタートピック専用の個別のコンシューマーグループを割り当てます。

デッドレターメッセージの監視

アラートルールを設定して、消費の失敗を早期に検出し、デッドレターメッセージが蓄積する前に対処します。

利用可能なメトリック

ソース	メトリック	説明
ダッシュボード	`rocketmq_send_to_dlq_messages`	1分あたりの新規デッドレターメッセージ数
CloudMonitor	`SendDLQMessageCountPerGid`	コンシューマーグループのトピックにおける1分あたりの新規デッドレターメッセージ数
CloudMonitor	`SendDLQMessageCountPerGidTopic`	コンシューマーグループにおける1分あたりの新規デッドレターメッセージ数
ダッシュボード	[コンシューマーラグ]	デッドレタートピック内の未消費デッドレターメッセージ
CloudMonitor	`ConsumerLagPerGidTopic`	トピックごとのコンシューマーグループごとのコンシューマーラグ

推奨される監視アプローチ

新しい障害の検出: ダッシュボードで rocketmq_send_to_dlq_messages を監視するか、SendDLQMessageCountPerGid を CloudMonitor アラートとして追加します。
未処理のバックログの追跡: デッドレタートピックのダッシュボードで [コンシューマーラグ] メトリックを確認するか、CloudMonitor アラートとして ConsumerLagPerGidTopic を追加します。

制限事項

デッドレタートピックは、通常メッセージタイプまたは順序付きメッセージタイプを使用する必要があります。
メッセージの元のトピックをデッドレタートピックとして使用することはできません。システムが一致を検出した場合、メッセージは破棄されます。
異なるトピックからのデッドレターメッセージは、同じデッドレタートピックに保存できます。
コンシューマーグループを削除しても、それに関連付けられたデッドレタートピックは削除されません。
デッドレターポリシーに関連付けられたトピックを削除するには、まずポリシーからトピックの関連付けを解除します。

次のステップ

消費リトライ