送り直しても通らない処理があります。宛先が消えている、形式が違う。何度送っても結果は同じです。
500件のうち41件がこの種類でした。外さずに5回まで送り直すと、164回が完全に無駄になります。処理できた件数は同じ457件です。
外す場合と外さない場合を走らせました。処理できる件数は変わらず、試行の回数だけが減ります。
デッドレターキューを置くかどうかで何が変わるのかを、実際に走らせて測りました。用意したのは仕事500件です。
内訳はそのまま通るもの・送り直せば通るもの・何度送っても通らないものの3種類です。最後の種類が41件ありました。
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++;
}
仕事 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回で外しました。一時的な失敗と見分けられる場合に限れます。見分けられないなら、回数で決めることになります。
処理できる件数は同じ。減るのは無駄な試行だけ。
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も、この仕組みが処理できなかったものを切り離して、なぜ成功しなかったかを突き止められるので、不具合の調査に役立つとしています。調べるための場所という位置づけです。
1番目を外してしまうと、本来通るはずのものを捨てます。逆に2番目を残すと無駄が積み上がります。見分けが設計の中心です。
順番が意味を持つ処理では扱いが変わります。AWSも、順序を崩したくない場合は、順序保証のある待ち行列とデッドレターキューを併用しないよう注意しています。
1件だけ外すと、その後ろの処理が前提を失うことがあります。編集の指示のように、順番で意味が変わる処理が例に挙げられています。
失敗の種類はあらかじめ割り当てています。実際には、受け取ったエラーから種類を判断することになります。この判断が外れると、前の節の効果もそのまま外れます。判断の付け方はエラー処理設計の記事で扱う予定です。
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は、デッドレターキューの保管期間を、元の待ち行列の保管期間より必ず長く設定するのが良い作法だとしています。
理由は期限の数え方です。移しても元の待ち行列に入った時刻から数えられるため、同じ期間だと調べる前に消えます。
4番目まで決めておいてください。戻すか捨てるか決まらないものが溜まると、置き場そのものが見られなくなります。
移すだけでは終わらない。見る人と戻す道が要る。
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
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る