デッドレターと毒メッセージの処理設計

毒メッセージが本流を止める仕組み

非同期メッセージング（キュー、ストリーム、Pub/Sub）の信頼性は、配信失敗時のリトライに支えられています。コンシューマが処理に失敗してメッセージを ack しなければ、ブローカは「未処理」とみなして再配信する。一時的なネットワーク瞬断や下流の一過性エラーなら、再配信でいずれ成功します。これが at-least-once 配信の根幹です（/devops/message-queue-delivery-semantics/）。

問題は、何度処理しても必ず失敗するメッセージ——いわゆる毒メッセージ（poison message）——が混ざったときです。原因はデシリアライズできない壊れたペイロード、スキーマ不整合、参照先が消えた外部キー、コードのバグが踏む特定データなど。これらは再配信しても結果は変わりません。リトライが永遠に成功しないまま、ブローカはそのメッセージを延々と再配信し続けます。

毒メッセージの無限リトライが起こすこと
  1. ワーカーが毒メッセージの処理に時間と資源を費やし続ける
  2. ack されないので可視性タイムアウト後に何度も再配信される
  3. 順序保証つきキュー/パーティションでは、その1件が
     後続をブロックする（ヘッドオブラインブロッキング）
  4. リトライのCPU・下流呼び出しが正常メッセージの容量を奪う

とくに深刻なのがヘッドオブラインブロッキングです。順序保証のあるキューや、Kafka のような単一パーティション内 FIFO のストリームでは、先頭の1件が処理できないとその後ろの全メッセージが進めません。健全なメッセージが何百万件積まれていても、毒メッセージ1件がオフセットを進ませず、パーティション全体が停止する。無限リトライは資源を食うだけでなく、システムの前進そのものを止めるのです。

一時障害と恒久障害を分ける

リトライ設計の第一歩は、失敗を二種類に分類することです。

理想は、コンシューマが例外の種類でこの二つを見分けることです。HTTP 5xx や接続エラーは一時障害として再試行し、400 相当の検証エラーやパースエラーは恒久障害として即座に DLQ へ送る（fail fast）。恒久障害を律儀にリトライ上限まで再試行するのは、確実に失敗する処理に資源を払い、隔離を遅らせるだけです。

ただし現実には両者の判別は完璧にはできません。下流の 500 が一過性なのか恒久バグなのかは外からは分かりません。そこで実務では「判別できる恒久エラーは即隔離、判別できないものは上限つきでリトライし、上限超過で隔離」という二段構えを取ります。リトライ回数の上限こそが、判別不能な毒メッセージに対する最後の安全弁です。

リトライ回数の上限と指数バックオフ

判別できない失敗には、**リトライ回数の上限（maximum receive count / max delivery attempts）を設けます。ブローカは各メッセージの配信試行回数を数え、上限を超えたら本流のキューから外してデッドレターキュー（DLQ）**へ移します。SQS の maxReceiveCount と redrive policy、RabbitMQ の dead-letter exchange、Kafka なら再試行トピックと DLT（dead letter topic）が、それぞれこの役割を担います。

上限を決めたら、次は再試行の間隔です。失敗直後に即リトライ（連打）するのは最悪です。一時障害の典型は下流の過負荷であり、回復していない相手へ即座に再送すれば、負荷を上乗せして回復をさらに遅らせます。そこで間隔を試行ごとに広げる指数バックオフを使います。

指数バックオフ（base=200ms, factor=2 の例）
  試行1失敗 → 200ms 待つ
  試行2失敗 → 400ms 待つ
  試行3失敗 → 800ms 待つ
  試行4失敗 → 1600ms 待つ
  ... 上限 max_attempts に達したら DLQ へ
  待機時間 = min(base * factor^(attempt-1), cap)

さらに重要なのが**ジッタ（揺らぎ）**です。同じ障害で大量のメッセージが同時に失敗すると、指数バックオフだけでは全件が同じ時刻に足並みを揃えて再送され、回復しかけた下流を周期的な波が再び叩く（サンダリングハード）。各待機時間に乱数の揺らぎを加えて再送タイミングを散らすことで、波を平らにします。指数バックオフとジッタの組み合わせ、そしてリトライ予算でリトライ自体の総量を抑える原理は、同期 RPC のリトライと完全に同じ系譜です（/devops/retry-backoff-jitter/）。

順序保証つきキューでヘッドオブラインブロッキングを避けたい場合、即時リトライをその場で繰り返すと先頭が長時間ブロックされます。そこで「失敗したメッセージはいったん別の再試行キューへ退避させ、本流のオフセットは先へ進める」という設計が有効です。Kafka の再試行トピック方式がこれで、失敗メッセージを retry-5s・retry-30s のような遅延トピックへ送り、本パーティションの前進を止めません。順序保証と引き換えに前進性を取る判断です。

DLQ は終着点ではなく退避所

リトライ上限を超えたメッセージは DLQ へ移ります。ここで陥りがちな誤解が、DLQ をゴミ箱だと思うことです。DLQ は「捨てる場所」ではなく「人間が原因を調べ、修正し、本流へ戻すまで安全に保管する退避所」です。設計はここから本番です。

DLQ を退避所として機能させるには、最低限これらが要ります。

• 死因の保全：なぜ失敗したかを後から追えるよう、最後の例外・スタックトレース・失敗時刻・試行回数・元のキュー名をメッセージ属性やメタデータに付けて DLQ へ送る。本文だけ移して死因を捨てると、調査が始められません。
• 可観測性：DLQ の ApproximateNumberOfMessages、流入レート、毒メッセージのパターン（同一スキーマ・同一発信元への偏り）を可視化する。流入の急増は、上流のデプロイ事故やスキーマ変更の事故を示す早期シグナルになります。
• 分類と原因究明：DLQ のメッセージを死因ごとに束ねる。「壊れたペイロード」「下流が長時間ダウン」「特定バージョンのバグ」では取るべき手当てが違います。

redrive：本流へ戻す救済フロー

原因を直したら、退避したメッセージを本流へ戻します。これが**redrive（再投入）**です。SQS なら DLQ redrive、RabbitMQ なら shovel/再 publish、Kafka なら DLT から元トピックへの再送で実現します。救済フローの典型はこうです。

救済（redrive）フロー
  1. アラートで DLQ への流入を検知
  2. 死因メタデータから根本原因を特定（バグ/スキーマ/下流障害）
  3. 原因を修正（コード修正・デプロイ、下流の復旧、データ補正）
  4. DLQ から本流（または専用の再処理キュー）へ redrive
  5. 再処理が成功することを確認、DLQ の件数が減ることを監視

redrive 設計には三つの落とし穴があります。

第一に、修正前に redrive してはいけません。原因が直っていないまま戻せば、メッセージは再び同じ失敗を辿り、リトライ上限を消費してまた DLQ へ戻る。DLQ と本流を往復するだけの無駄なループになります。redrive は「原因が解消された」という前提を必ず満たしてから行います。

第二に、redrive の回数自体を追跡する必要があります。「DLQ から戻す → また失敗 → また DLQ」を無制限に許すと無限ループになりかねません。redrive 回数をメタデータに刻み、一定回数を超えたものは自動再投入の対象から外し、人手の判断（手動補正・破棄）に回します。

第三に、再処理は冪等でなければなりません。redrive されたメッセージは、最初の失敗時点で副作用（一部の DB 更新、外部 API 呼び出し）を起こしているかもしれません。これを冪等性なしで再処理すると、二重課金・二重発送が起きます。コンシューマは「同じメッセージを複数回処理しても結果が一度きりと同じ」になるよう設計しておくことが、redrive を安全にする前提条件です（/devops/idempotency-exactly-once/）。送信側でメッセージ生成自体を確実にする outbox 等と組み合わせると、生成から消費まで一貫した信頼性になります（/devops/transactional-outbox/）。

試験・面接で問われる勘所

まとめ

• 毒メッセージは何度処理しても失敗するため、無限リトライがワーカーとキューの容量を奪い、順序保証キューでは1件が後続全体を止めるヘッドオブラインブロッキングを招く。
• 対策の核心は失敗の分類。一時障害はバックオフして再試行、恒久障害は判別できしだい即DLQへ隔離（fail fast）。判別不能なものはリトライ回数の上限を最後の安全弁にする。
• 再試行間隔は指数バックオフ＋ジッタで広げ、回復していない下流への連打とサンダリングハードを避ける。順序保証下では別の再試行キューへ退避し本流の前進を止めない。
• DLQはゴミ箱ではなく退避所。死因メタデータの保全・滞留件数の監視・retention 超過による消失防止が必須。放置されたDLQは静かなデータ損失。
• redrive（再投入）は原因修正後にのみ行い、再投入回数を追跡して無限ループを防ぎ、再処理は冪等に設計する。下流全体の障害はサーキットブレーカで消費を止め、DLQへの不要な大量流入を防ぐ。