【ITニュース解説】Retrying Failed Jobs in Small Apps — Node.js Queues, DLQs, and 3 Practical Trade-offs

ソフトウェア開発において、アプリケーションが実行する処理（ジョブ）は常に成功するとは限らない。ネットワークエラー、データベースの一時的な不調、外部サービスの停止、または予期せぬデータの問題など、さまざまな原因でジョブは失敗することがある。システムエンジニアを目指す上で、このような失敗にどのように対処し、システムの信頼性を確保するかは非常に重要な課題である。この記事では、特に小さなアプリケーションにおいて、失敗したジョブをどのように再試行（リトライ）し、運用上の問題を最小限に抑えるかについて、いくつかの主要なアプローチとそのトレードオフを解説する。

まず、なぜジョブのリトライ処理が重要なのかを考える。例えば、不動産管理システムで「期限切れの物件情報を削除する」というジョブが失敗した場合、物件情報が残り続け、ユーザー体験の低下やデータの不整合につながる可能性がある。このようなビジネス上重要なジョブが失敗した場合でも、自動的に再試行され、最終的には成功に導かれる仕組みが必要になる。単にジョブが失敗したからといって、開発者が手動で介入するのでは、時間とコストがかかり、ビジネスのスピードを阻害する。つまり、信頼性の高いリトライ機構は、開発コストを抑えつつ、アプリケーションの安定稼働とビジネス価値の維持に貢献するのだ。

失敗したジョブのリトライを実現する方法はいくつかある。主な選択肢として、メッセージキューとデッドレターキュー（DLQ）の組み合わせ、データベースのポーリング、そしてワークフローエンジンが挙げられる。それぞれの方法には特徴があり、アプリケーションの規模や要件に応じて最適な選択が異なる。

メッセージキューとDLQの組み合わせは、多くのアプリケーションで推奨される堅牢なアプローチである。メッセージキューは、処理すべきジョブをメッセージとして一時的に保持し、ワーカーと呼ばれる別のプログラムがそのメッセージを順次取り出して処理する仕組みだ。例えば、AWS SQSのようなマネージドサービスや、Node.jsアプリケーションでよく使われるBullMQとRedisの組み合わせがこれに当たる。ワーカーがジョブの処理に成功したら、キューからメッセージを削除（承認：ACK）する。もし一時的なエラーで失敗した場合は、ワーカーはメッセージを承認せず、キューに戻すことで再試行を促すことができる。

ここで重要なのは「デッドレターキュー（DLQ）」の役割である。DLQは、何度も再試行しても成功しない、いわゆる「毒性メッセージ（poison message）」を隔離するための特別なキューだ。例えば、入力データが根本的に間違っているために処理が絶対に成功しないようなメッセージは、メインのキューで永遠に再試行され続けると、他の正常なジョブの処理を妨げかねない。DLQに隔離することで、開発者はそのメッセージを後で調査し、手動で修正して再処理（redrive）したり、破棄したりできる。これにより、システム全体の処理が滞ることを防ぎ、運用上の可視性を高めることができる。

メッセージキューを利用する際には、「べき等性（idempotency）」の概念が非常に重要になる。メッセージキューは「少なくとも一度（at-least-once）」の配信を保証する場合が多く、これは同じメッセージが複数回ワーカーに配信される可能性があることを意味する。例えば、ネットワークの一時的な問題でワーカーがメッセージの承認に失敗した場合、キューはメッセージを再配信するかもしれない。もしワーカーの処理がべき等でない場合、同じ処理が複数回実行され、意図しない結果（例えば、二重の課金やデータの重複）を引き起こす可能性がある。これを避けるためには、ジョブの処理が何回実行されても、結果が一度実行された場合と同じになるように設計する必要がある。具体的には、ジョブIDのような一意のキーを使って、既に処理済みのジョブであれば何もせずスキップする、といった実装が考えられる。

一方で、データベースのポーリングという選択肢もある。これは、failed_jobsのようなテーブルを作成し、失敗したジョブの情報をそこに記録し、別のプロセスが定期的にそのテーブルを監視（ポーリング）して再試行するというシンプルな方法だ。非常に小規模で、単一のプロセスで動作し、ジョブの量が少ないアプリケーションでは、最初の実装が簡単で魅力的に見えるかもしれない。しかし、このアプローチはすぐに限界を迎える。複数のワーカーが同時にジョブを処理しようとすると競合が発生したり、再試行の間隔を指数関数的に伸ばす「指数バックオフ」を実装するには複雑なタイムスタンプ計算が必要になったりする。また、ワーカーがクラッシュした場合に、処理中のジョブの状態が「実行中」のまま停止してしまい、誰にも処理されなくなる「スタックしたジョブ」の問題も発生しやすい。これらをすべてアプリケーションコードで実装すると、本来のビジネスロジックよりも、キューの機能自体を自前で作り込むことに多くの時間と労力を費やしてしまうことになる。それは多くの運用上の懸念を生み出し、機能開発の足を引っ張る可能性が高い。

さらに複雑なビジネスプロセスに対応するためには、Temporalのようなワークフローエンジンも選択肢となる。これは、複数のステップからなる長期的なビジネスプロセスや、条件分岐を含む複雑な処理のステート（状態）を永続的に管理し、明確なリトライ機能を提供する。しかし、単に特定のクリーニングジョブを一度実行するようなシンプルなタスクには、機能が豊富すぎて大げさすぎる場合が多い。

結論として、ほとんどの小さなSaaSアプリケーションにおいては、メッセージキューとDLQの組み合わせがデフォルトの選択肢として推奨される。このアプローチは、ジョブの失敗を明確に区別し、再試行の管理を容易にする。例えば、あるプロパティのクリーニングコマンドをキューに発行し、そのコマンドをべき等にすることで、システム全体の安定性を保ちながら、問題が発生した場合にはDLQで個別に処理できる。これは、高速道路に例えるなら、メインの車線で交通を流し、問題のある一台（毒性メッセージ）は路肩（DLQ）に寄せて交通全体を滞らせないようにするイメージだ。

もちろん、どの選択肢を選ぶかは、アプリケーションの具体的な要件と運用の実現可能性によって異なる。週に一度しか実行されないような、バースト性がなく、運用チームがRedisやマネージドキューの運用を望まない場合は、PostgreSQLのトランザクションを使って行をロックし、ジョブを処理するシンプルなデータベースポーリングが適切な場合もある。しかし、その場合でも、キューのセマンティクス（バックオフ、並行処理、スタックしたジョブの検出など）を自前のコードで維持するコストは理解しておくべきだ。

最終的な意思決定のルールはシンプルである。もし失敗したクリーニングジョブが安全に再実行できるなら、それをキューに投入し、ハンドラーをべき等に設計し、繰り返し失敗するジョブはDLQで隔離する。もし実行しなくても許容されるようなスケジュールであればcronのようなスケジューラーがトリガーとなるが、もしジョブが長時間かかる場合は、cronは単にバッチをキューに投入する役割に留め、実際の処理はワーカーに任せるべきである。もし監査が必要であれば、キューからメッセージを承認する前に、処理結果をアプリケーションのデータベースに永続的に記録することが重要だ。キューはあくまでメッセージを運ぶための「輸送手段」であり、永続的な「帳簿」ではないことを理解しておく必要がある。

運用コストと顧客に提供する価値のバランスを見極めることが重要だ。自前でキューの機能を実装することに多くの時間と労力を費やすよりも、マネージドサービスや既存のライブラリを活用して「差別化されないキューのメカニズム」をアウトソースし、その分、本来のビジネスロジックや顧客価値を向上させることに集中すべきなのだ。この原則は、システムエンジニアとして技術選定を行う上で常に心に留めておくべき視点である。