Message Integration でのメッセージ配信の失敗は、データ損失や処理遅延を引き起こす可能性があります。リトライポリシーは、失敗した配信を自動的にリトライします。デッドレターキュー (DLQ) は、配信不能なメッセージを検査と再処理のために捕捉します。
仕組み
メッセージ配信が失敗すると、Message Integration は構成されたリトライポリシーを適用します。すべてのリトライが上限に達した場合、フォールトトレランスポリシーが次に何が起こるかを決定します。
Message delivery fails
|
v
Retry policy applies
(backoff or exponential decay)
|
v
All retries exhausted?
| |
No Yes
| |
v v
Retry Fault tolerance policy?
again | |
Allowed Prohibited
| |
v v
DLQ configured? Task status -> Ready
| | (processing stops)
Yes No
| |
v v
Send to Discard
DLQ messageシステムがリトライをまったく試行できない場合 (例えば、無効なリソース構成が原因の場合)、タスクステータスは [Start Failed] に変更され、通常のリトライフローは適用されません。
リトライポリシー
リトライポリシーは、Message Integration が失敗した配信をどのようにリトライするかを決定します。2つのポリシーが利用可能です。
| ポリシー | 動作 | 最大リトライ回数 | リトライ間隔 | 合計リトライウィンドウ |
|---|---|---|---|---|
| バックオフ再試行 (デフォルト) | 固定ランダム間隔 | 3 | 各10～20秒のランダム | 約60秒 |
| 指数減衰再試行 | 増加する間隔 | 176 | 1秒から始まり、最大512秒まで倍増 | 1日 |
バックオフ再試行
バックオフ再試行はデフォルトポリシーです。システムは、失敗したメッセージを最大3回、各試行間に10～20秒のランダムな間隔を置いてリトライします。
迅速な失敗検出が必要な場合、および失敗したメッセージをDLQに到達させるか、フォールトトレランスを迅速にトリガーしたい場合に、バックオフ再試行を使用します。
指数減衰再試行
指数減衰再試行は、試行間の待機時間を増加させます。間隔は1秒から始まり、各リトライで倍増し、最大512秒になります。完全な間隔シーケンスは次のとおりです。
1s, 2s, 4s, 8s, 16s, 32s, 64s, 128s, 256s, 512s
512秒に達した後、システムは残りの167回の試行について512秒間隔でリトライを続行し、1日で合計176回のリトライとなります。
ダウンストリームシステムが自力で回復する可能性がある場合に、指数減衰再試行を使用します。このポリシーは、DLQへのルーティングの前に配信成功の可能性を最大化します。
リトライポリシーの選択
| シナリオ | 推奨ポリシー | 理由 |
|---|---|---|
| ダウンストリーム障害が通常は永続的である場合 (例: 無効なメッセージフォーマット) | バックオフ再試行 | 迅速な失敗を検出し、手動点検のためにDLQにルーティングします。 |
| ダウンストリーム障害が通常は一時的である場合 (例: 一時的なサービス停止) | 指数減衰再試行 | ダウンストリームシステムが回復する時間を与えます。 |
| メッセージ損失が許容できず、ダウンストリームの回復が期待される場合 | 指数減衰再試行 + フォールトトレランス禁止 | 処理停止を最終的な安全策とする最大リトライカバー率。 |
| 高いメッセージスループットがあり、DLQベースの再処理が導入されている場合 | バックオフ再試行 + フォールトトレランス許可 | リトライオーバーヘッドを最小限に抑え、DLQを介して障害を処理します。 |
フォールトトレランスポリシー
フォールトトレランスポリシーは、すべてのリトライが上限に達した後に何が起こるかを決定します。2つのポリシーが利用可能です。
フォールトトレランス許可
すべてのリトライ後にメッセージが失敗した場合でも、イベント処理は続行されます。失敗したメッセージは次のいずれかです。
デッドレターキューが構成されている場合、デッドレターキューに配信されます。
デッドレターキューが構成されていない場合、破棄されます。
時折のメッセージ損失が許容できる場合、またはDLQベースの再処理ワークフローが導入されている場合に、このモードを使用します。
フォールトトレランス禁止
すべてのリトライ後にメッセージが失敗した場合、イベント処理は停止します。タスクステータスは [Ready] に変更され、問題を解決するまで、それ以上のメッセージは処理されません。
すべてのメッセージが配信される必要があり、メッセージ損失が許容できない場合に、このモードを使用します。
デッドレターキュー
デッドレターキュー (DLQ) は、すべてのリトライが上限に達した後に失敗したメッセージを捕捉します。システムは生メッセージデータをDLQに送信し、そこで検査または再処理できます。DLQ機能はデフォルトで無効になっています。失敗したメッセージの捕捉を開始するには、タスクレベルで有効にします。
サポートされているDLQターゲット
| サービス | ターゲットタイプ |
|---|---|
| ApsaraMQ for RocketMQ | キュー |
| Simple Message Queue (旧称：MNS) | キュー |
| ApsaraMQ for Kafka | キュー |
| EventBridge | イベントバス |
デッドレターメッセージの処理
メッセージがDLQに到達した後、次のステップを実行します。
障害原因を特定します。タスクログとDLQ内の生メッセージデータを確認します。障害がダウンストリームサービスエラー、無効なメッセージフォーマット、または権限の問題によって引き起こされたかどうかを判断します。
根本原因を解決します。ダウンストリームサービスの復元、メッセージフォーマットの修正、または権限の更新など、根本的な問題を修正します。
メッセージを再処理します。DLQからメッセージを消費し、元のターゲットに再送信するか、代替パスを介して処理します。
失敗したメッセージを迅速に検出するために、DLQでモニタリングを設定します。例えば、DLQターゲットサービス内のメッセージ数に基づいてアラートを設定し、見過ごされたメッセージ蓄積を回避します。