DLQ

背景

しかし、何らかの理由で処理に失敗する場合がある

e.g.

メッセージフォーマットが不正（JSON パースに失敗など）

一時的な外部 API 障害

データ不整合（存在しないリソース ID など）

消費者コードのバグ

こうした失敗を無視して再試行を繰り返すと、無限リトライや処理詰まりが発生する

そのため、いったんDLQに退避させておいて、後で手動で作業したり、再度投入したりする

例

gpt-5.icon

🕵️‍♀️ 運用上のポイント

DLQ を監視する

CloudWatch や Datadog で DLQ のメッセージ数をモニタリング。

急増したら、処理ロジックに問題があるサイン。

メッセージ内容を記録

何が原因で落ちたのか（例外・スタックトレース・入力データ）を残す。

原因分類（データ不整合 vs 一時障害）を行う。

再処理フローを設計

原因解消後、DLQ からメッセージを MainQueue に戻すバッチを用意。

自動再投入時には無限ループ防止策（再試行上限やタグ付け）を入れる。

⚠️ よくある落とし穴

table:_

問題 対策

DLQ に溜まり続ける 定期監視と自動通知を設定

同一メッセージが何度も再投入される 再処理時に「再投入済みフラグ」を付ける

DLQ を設定していない デフォルトでは破棄される可能性もあるため注意