業務自動化・iPaaS・RPA

デッドレターキューとは|通らない41件が、164回の無駄な試行を生んでいた

デッドレターキューとは何か外さないと何が起きるのか何回で外せばよいのか

送り直しても通らない処理があります。宛先が消えている、形式が違う。何度送っても結果は同じです。

500件のうち41件がこの種類でした。外さずに5回まで送り直すと、164回が完全に無駄になります。処理できた件数は同じ457件です。

この記事の要点

  • 試行の合計が725回から561回
  • 処理できた件数はどちらも457件
  • 無駄な試行は164回
  • 外したものは見に行かないと消える

通らない41件が、164回の無駄な試行を生んでいた

外す場合と外さない場合を走らせました。処理できる件数は変わらず、試行の回数だけが減ります。

デッドレターキューを置くかどうかで何が変わるのかを、実際に走らせて測りました。用意したのは仕事500件です。

内訳はそのまま通るもの・送り直せば通るもの・何度送っても通らないものの3種類です。最後の種類が41件ありました。

javascript
for (const j of jobs) {
  let okd = false;
  for (let n = 1; n <= MAX; n++) {
    tries++;
    if (j.kind === 'ok' || (j.kind === 'temp' && rr() < 0.5)) { okd = true; break; }
    if (j.kind === 'perm') { moved++; break; }   // 送り直さずに外す
  }
  if (okd) done++;
}
text
仕事 500件。うち一時的な失敗 65件・恒久的な失敗 41件

やり方                      試行の合計  処理できた件数  最後まで残った件数
全部を最大5回まで送り直す                     725回          457件               43件
恒久的な失敗は1回で外に出す                    561回          457件               41件

外に出さない場合、恒久的な失敗が待ち行列に居座り続ける。
  無駄な試行: 41件 × 5回 = 205回
  外に出す場合: 41件 × 1回 = 41回

上の表を見てください。処理できた件数はどちらも457件です。外しても損はしていません。

減ったのは試行の回数

違うのは試行の合計です。725回から561回になりました。差は164回です。

この164回は結果が分かっている処理を繰り返したぶんです。宛先が消えている相手に、5回続けて送っていました。

何回で外すか

外す回数はAWSでも設定できます。ドキュメントは送り元の待ち行列から何回受け取ったら移すかを指定するものだと説明しています。

この計測は1回で外しました。一時的な失敗と見分けられる場合に限れます。見分けられないなら、回数で決めることになります。

処理できる件数は同じ。減るのは無駄な試行だけ。

単位: 回全部を5回まで送り直す725回通らないものは1回で外す561回−23%仕事500件・恒久的な失敗41件での実測。処理できた件数はどちらも457件。
図1 ── 試行の合計と処理できた件数
出典AWS「Using dead-letter queues in Amazon SQS」2026-08-18 確認
The maxReceiveCount is the number of times a consumer can receive a message from a source queue before it is moved to a dead-letter queue.
原文AWS「Using dead-letter queues in Amazon SQS」 この内容の有効期限2027-02-18

デッドレターキューとは、通らないものの置き場

処理できなかったものを、本来の待ち行列から外して別の置き場に移します。原因を調べるための場所です。

デッドレターキューは、処理できなかったものを移しておく別の置き場です。日本語では配信不能の置き場と呼ばれます。

なぜ分けるのか

本来の待ち行列に残したままだと、通らないものが延々と送り直されます。前の節の164回がこれです。

AWSも、この仕組みが処理できなかったものを切り離して、なぜ成功しなかったかを突き止められるので、不具合の調査に役立つとしています。調べるための場所という位置づけです。

2種類の失敗

  1. 一時的な失敗。相手が混んでいる、回線が切れた。送り直せば通る
  2. 恒久的な失敗。宛先が消えた、形式が違う。何度送っても通らない
  3. 見分けがつかない失敗。回数で区切るしかない
  4. 成功。ここは何もしなくてよい

1番目を外してしまうと、本来通るはずのものを捨てます。逆に2番目を残すと無駄が積み上がります。見分けが設計の中心です。

順序を守る場合は注意

順番が意味を持つ処理では扱いが変わります。AWSも、順序を崩したくない場合は、順序保証のある待ち行列とデッドレターキューを併用しないよう注意しています。

1件だけ外すと、その後ろの処理が前提を失うことがあります。編集の指示のように、順番で意味が変わる処理が例に挙げられています。

余談 この計測での注意

失敗の種類はあらかじめ割り当てています。実際には、受け取ったエラーから種類を判断することになります。この判断が外れると、前の節の効果もそのまま外れます。判断の付け方はエラー処理設計の記事で扱う予定です。

出典AWS「Using dead-letter queues in Amazon SQS」2026-08-18 確認
DLQs are useful for debugging your application because you can isolate unconsumed messages to determine why processing did not succeed.
原文AWS「Using dead-letter queues in Amazon SQS」 この内容の有効期限2027-02-18

移したあとに見に行かないと、静かに消える

置き場に移すこと自体は解決ではありません。中身を見て、原因を直すところまでが運用です。

デッドレターキューに移した時点では、何も解決していません。移した先を誰も見ないなら、捨てたのと変わりません。

気づく仕組みを付ける

前の節の実測では41件が移りました。この41件は、見に行かなければ誰にも知られません

本来の処理は正常に見えます。失敗した処理が待ち行列から消えているからです。件数が増えたことを知らせる仕組みを別に置いてください。

保管の期間

移したものにも保管の期限があります。AWSは、デッドレターキューの保管期間を、元の待ち行列の保管期間より必ず長く設定するのが良い作法だとしています。

理由は期限の数え方です。移しても元の待ち行列に入った時刻から数えられるため、同じ期間だと調べる前に消えます。

戻す道を用意する

  1. 中身を見る。何が原因で通らなかったか
  2. 原因を直す。宛先の登録漏れ、形式の食い違い
  3. 待ち行列に戻す。直したものは処理できる
  4. 直せないものを決める。戻さないと決めた記録を残す

4番目まで決めておいてください。戻すか捨てるか決まらないものが溜まると、置き場そのものが見られなくなります。

移すだけでは終わらない。見る人と戻す道が要る。

充足 2 / 4件数が増えたことを知らせている移すと本来の処理は正常に見えるので、見に行かないと気づけない保管期間を元の待ち行列より長くしている期限は元の待ち行列に入った時刻から数えられる移すこと自体を解決だと考えている移した41件は、原因を直さない限り処理されない戻す道を用意していない直しても戻せないなら、調べる意味がなくなる仕事500件・恒久的な失敗41件での実測にもとづく。無駄な試行は164回だった。
図2 ── デッドレターキューの点検項目
出典AWS「Using dead-letter queues in Amazon SQS」2026-08-18 確認
it is a best practice to always set the retention period of a dead-letter queue to be longer than the retention period of the original queue.
原文AWS「Using dead-letter queues in Amazon SQS」 この内容の有効期限2027-02-18

よくある質問

外しても処理できる件数は減りませんか
この計測では減りませんでした。どちらも457件です。外したのは何度送っても通らないものだけです。
何回で外せばよいですか
AWSは、十分な送り直しができる程度に高く設定するよう案内しています。低すぎると一時的な失敗まで外れます。
外したあとはどうするのですか
中身を見て原因を調べます。直したうえで、待ち行列に戻す仕組みが用意されていることもあります。
外したことに気づけますか
見に行かなければ気づけません。件数が増えたことを知らせる仕組みを別に置く必要があります。

まとめ

  • 通らない処理を別の置き場に移す仕組み
  • 試行の合計が725回から561回
  • 処理できた件数はどちらも457件
  • 移したあとに見に行く仕組みが要る

今日から始められること

  1. いま失敗した処理がどこへ行くか確かめる
  2. 行き先がなければ、置き場を1つ用意する
  3. 何回で外すかを決める
  4. 置き場の件数が増えたことを知らせる仕組みを付ける

実務で組んだデッドレターキューのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る