DLQと毒メッセージの処理

Dead Letter Queue （DLQ）は、特定の回数の試みの後に通常の消費者によって処理できなかったメッセージや、明らかな技術的/ビジネス上の理由（無効なスキーム、タイムアウト、バージョン競合など）のための分離されたキュー/トピックです。毒メッセージ-一貫して再処理が失敗し、パイプラインの安定性を脅かす記録。

DLQの目的は、SLOを維持し、故障をローカライズし、メインストリームのブロックを防ぎ、分析と安全なリプレイ（再描画）の可能性を保証することです。

1）有毒なメッセージの出所

スキーマ/コントラクト：互換性のない変更、必須フィールドの欠落、誤ったタイプ。
ビジネス検証：重複、違反不変、期限切れのイベント。
順序と因果性：「Update」から「Create」になりました。相関関係がなく、順序外です。
Idempotency：再処理は副作用を生成します。
外部依存関係：制限された制限/タイムアウト、APIが利用できません。
データ：ペイロードの破損、誤ったエンコード、オーバーサイズ。

2） DLQ提出基準

• 消費者/作業者での処理のmaxAttemptsを超えました。
• このエラーは、無効なスキーム、重要なリソースの欠如、ビジネスの禁止など、再検討できないものに分類されます。
• 締め切りメッセージ（TTL/有効期限）が期限切れになりました。
• このキー/テナントのサーキットブレーカまたは入場制御ポリシーがトリガーされました。
• 明示的なオペレータソリューション（メインスレッドから手動で「イジェクト」）。

3） DLQトポロジーとパターン

キューごとのDLQ：各キュー/トピックには独自のDLQがあります。シンプルで透明。
セントラルDLQ（駐車場）：複雑なケースのための一般的な「駐車場」、統一された分析ツールに便利。
DLT （Dead Letter Topic）：ログ指向のバス（イベントログ）-障害の原因のメタデータを持つ別のトピック。
検疫：手動分析のためのハードアクセスとPII衛生を備えた検疫バッファ。
Shadow-stream：安全な固定実験のための「shadow」に問題のあるメッセージを複製する。

4） DLQに同行するために必要なメタデータ

• エラーの原因：エラーコード/クラス、スタック/トレースID。
• コンテキストの再試行：'attempts'、 'maxAttempts'、 'first_seen_ts'、 'last_attempt_ts'。
• 相関：'trace_id'、 'span_id'、 'tenant_id'、 'entity_id'、パーティションキー。
• 元のオフセット/パーティション/シーケンス（ログバス用）またはmessage-id。
• 契約/スキーマ/ペイロードのバージョン。
• Idempotency-key/Request-id（もしあれば）。
• ルーティングソース：キュー名/トピック、コンシューマーグループ。

5） DLQ前のリトレイポリシー

• 短い消費者リトレイ：'maxAttempts' 2-5、指数関数バックオフ+ジッタ、同時性のキャップ。
• 協働バックプレッシャー：エラーが増加するにつれて競争を減らします。
• エラー分類：retryable （'5xx'、 timeout）とnon-retryable（検証、スキーマの不一致）。
• ディレイキュー：5s→30s→2m（一時的な障害の場合）
• キーごとの分離：特定のキーが「騒々しい」場合、パーティー全体をブロックしないでください。

6）安全なRedrive （DLQからの再配達）

Redriveは、DLQから処理へのメッセージの制御されたリターンです。

1.修正：コード/構成/スキームを修正した後、または外部依存関係を復元した後にのみ再描画します。

2.Idempotency：ハンドラは反復に対して抵抗力がある必要があります（upsert、 effect-toluant演算）。

3.'idempotency_key'/'message_id'/'business_key'による重複除外。

4.バッチとウィンドウ：Nメッセージによるバッチ、redriveによるレート制限、時間/パーティーによる「ウィンドウ」。

5.ローカル検証：再描画の前にスキームを迅速に検証します（初期の無効なケースを拒否します）。

6.優先順位：redriveは販売トラフィック（労働者/個々のプールの低優先度）を置き換えるべきではありません。

7.観測可能性：redriveのための個々のメトリックとトレイル。成果レポート（成功/DLQ/損失を繰り返します）。

7）配達意味論および順序

最低1回は最も一般的なモードです。idempotenceと重複除外が必要です。
At-once-DLQを無効にすることができます。損失のリスク。損失が許容される場合にのみ使用します。
正確に一度（効率的）：トランザクションとビジネスストレージの重複排除によって達成されます。高価で特別なものです。
注文：DLQは通常、特定のキー/パーティーの注文を破ります。注文が重要な場合は、キーと順番に再描画します。

8）スキーム、契約、検証

スキーマレジストリ/コントラクト：明確なバージョニング、後方/前方互換性のある進化。
入り口での検証：重いステップの前にJSON スキーマ/Protobuf/Avroを介して安価なチェック。
互換性のないポリシー：「breaking」フィールドを使用すると、DLQですぐに'SCHEMA_INCOMPATIBLE'というコードが表示されます。
Redaction PII：必要なものだけをDLQに保存します。マスクセンシティフィールド。

9） Idempotencyと重複除外

Idempotency-key： 「business sense」（テナント+エンティティ+操作+ts-bucket）からプロデューサーにフォームを作成します。
デッドアップログ：TTLで最後の'N'キーを保持します。操作の「効果」を覚えておいてください。
Upsert/merge：制限なしで「insert-only」を避けます。
副作用：外部呼び出しの場合-ログとチェック「繰り返し」呼び出す前に。

10）観察可能性およびSLO

• DLQ率（msg/s）、メッセージの割合、DLQの平均/中央値「年齢」。
• redrave（％）の成功、繰り返しDLQシェア。
• 原因の分類：スキーマ、検証、タイムアウト、依存性、不明。
• p95/p99主流の治療レイテンシとredrive。
• DLQサイズ、オーバーフローのリスク。

• 必要なタグは'message_id'、 'entity_id'、 'tenant_id'、 'attempt'、' reason'、'redrive_batch_id'です。
• 「DLQブランチ」のトレース：ソースから繰り返し成功へ。

• 正常に処理されたメッセージの割合≥ T分でX％です。
• DLQケースの調査と修正時間≤ Y時間。
• DLQ ≤ Z時間内のメッセージの最大「年齢」（アラート付き）。

11）安全性とコンプライアンス

最小特権アクセス：Redrive-演算子/プレイブックのみ。
監査：redrive/delete/editメタデータをトリガーしたユーザー。
衛生：中央DLQに転送するときは、不要なPII/秘密を削除します。
保持：DLQの個別の保持ポリシーと削除ポリシー。

12）複数のテナント

タグ'tenant_id/plan'：制限の区別、優先順位の再描画、レポート。
テナントごとのDLQまたはパーティー：「騒々しい」クライアントが全体のDLQを詰まらないようにします。
請求/クォータ：DLQボリュームと使用中の再利用コストを考慮してください。

13）コンフィギュレーションテンプレート（例）

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14）動作プレイブック（runbooks）

1.異常なDLQの増加：本番コンシューマーのスロットリングをオンにし、トップの理由を分析し、リリース/スキームをチェックします。
2.スキーマの不一致：ロールバック/コミットスキーマ、アダプターの移行、検証後に再配置。
3.外部依存関係が利用できない：一時停止の再訓練、遅延キューの有効化、リカバリ後の再配置。
4.redrive後に繰り返されるDLQ： 「shadow」ハンドラ/シミュレータを有効にし、idempotency、 narrow batchをチェックします。
5.DLQオーバーフロー：アーカイブストレージへの避難、キー/理由の選択的再描画を有効にします。

15）テストおよび混乱

エラーインジェクション：スキーマブレイク、検証、タイムアウト、1-on-Nスティッキーエラー。

大量改訂： 投与量のチェックと生産への影響

順序の順序：正しいキー処理を保障して下さい。
ペイロードの破損：検証と安全な障害。
redrive workerの落下後のリカバリ：バッチ操作のidempotency。

16）典型的なエラー

DLQでメタデータが不足→原因をクラスタ化して安全に変更することは不可能です。
限界のない大量再描画→生産の再分解。
idempotency/deduplication→duplicatesおよび副作用なし。
衛生なしで中央DLQでのPII混合。
メッセージの進化におけるスキーム/契約の欠如→「驚き」。
テナント/キーのパーティショニングなしで唯一の一般的なDLQ。
初期DLQの代わりに無限のリトレイが再試行可能でないエラーの場合。

17）クイックレシピ

通常の業務フロー：3-4試行、ジッタ付き指数関数バックオフ、エラーの早期分類、フルメタデータのDLQ。
クリティカルイベント（決済）：厳格なidempotence、短いタイムアウト、最小試行、高速DLQ、手動解析。
修正後の大量の再描画：小さなバッチ（100-500）、レートリミット、作業者の個別のプール、スピードを上げる前に成功>95％を監視します。
マルチテナント：テナントごとのredriveの限界、DLQの上の顧客の発電機のレポート。

結論

DLQは「ゴミ箱」ではなく、制御された信頼性ループです。明確なヒットルール、豊富なメタデータ、idempotencyと重複排除、セキュアなメーター付きredrive、スキーマ規律とオブザビリティにより、SLOに対する脅威から有毒なメッセージが管理可能なエンジニアリングプロセスに変わります。