デッドレター(失敗したjob)とは？解説

デッドレターとは、何度も失敗しすぎてシステムがリトライをあきらめ、人間の対応のために脇へ置く作業の保管場所です。

リトライは永遠に成功し続けることはできません。ある時点で、システムは特定の項目について立ち止まり、敗北を認めなければなりません。メッセージキューに由来するデッドレターパターンは、これを捉えます - リトライを使い果たした後、失敗した項目はデッドレターキューへ移され、失われることも、後続のすべてをブロックすることもありません。

パターン

workerがメッセージの処理を試みます。リトライ上限を超えて失敗し続ける場合、際限なくリトライする(キューをブロックしてしまう)のでも、破棄する(データを失ってしまう)のでもなく、システムはそれをデッドレターキューへ振り分けます。そこで検査を待つ一方、通常の処理は妨げられずに続きます。

なぜ存在するのか

デッドレターの送り先がないと、常に失敗する単一の毒入り項目が、キューを永久に詰まらせるか、静かに消えてしまうかのどちらかになります。デッドレターキューは安全弁です - 失敗を隔離し、健全な作業を妨げることなく、可視化され回復可能な状態にします。

CIとの類推

自己修復型のpipelineでも同じ論理が当てはまります。一時的に失敗するjobはリトライされますが、リトライ予算を超えて失敗し続けるjobを永遠にリトライすべきではありません。これがデッドレターのケースです - リトライを止め、本物の失敗として印を付け、人間の目に触れるようにします。これ以上のリトライは役に立たないからです。

デッドレター化した作業をどうするか

検査して、実際の持続的な原因を突き止めます。
毒入り項目(決して成功しない)を、長時間の障害と区別します。
根本原因を修正し、その後任意で再実行またはreplayします。
静かな失敗が蓄積しないよう、デッドレターの量についてアラートを出します。

Latchkeyの視点

限定されたリトライは、誠実な自己修復の中心です。Latchkeyの自己修復型マネージドrunnerは、一度きりの乱れがあなたのbuildを失敗させないよう、一時的および機械的な障害をリトライしますが、永遠にはリトライしません - 上限を超えて失敗し続けるjobは、静かにループするのではなく、本物の失敗として浮かび上がります。

重要なポイント

デッドレターは、リトライを続けるには失敗しすぎた作業を保持します。
毒入り項目がキューを詰まらせたり、静かに失われたりするのを防ぎます。
CIでは、リトライが尽きて人間が必要になるケースです。
誠実な自己修復には、無限のリトライではなく、リトライの上限があります。