【ITニュース解説】WJb Resilient Actions: Designing Fault-Tolerant Background Jobs

システムが正常に動作し続けることは、ITサービスを提供する上で非常に重要だ。しかし、システムは常に完璧に動くわけではない。時に予期せぬ問題が発生し、システムの一部が停止したり、全体の動作に悪影響を及ぼしたりすることがある。今回取り上げるニュース記事は、このような問題、特に「バックグラウンドジョブ」と呼ばれる裏側で動く処理が停止したときに何が起こり、どのように対処すべきかについて深く掘り下げている。

記事が指摘するのは、ごく単純な状況だ。複数のバックグラウンドジョブがスケジュール通りに実行され、キュー（処理待ちの列）に積まれ、ワーカーと呼ばれる処理実行部がそれらを順次こなしていた。しかし、たった一つの処理（「アクション」と呼ぶ）が途中で動かなくなってしまった。その結果、新たなジョブは生成され続け、キューはどんどん増えていき、他の正常な処理も実行されなくなり、最終的にシステム全体が停滞してしまう事態に陥った。この問題はシステムを再起動するまで解決しなかったという。この例は、システムが完璧な状態でどのように振る舞うかではなく、障害が発生したときにどう対処するかによって、その信頼性が決まるという重要な教訓を示している。

このような経験から、記事は「アクションは失敗を前提に設計されるべきだ」と強く主張する。なぜなら、実際のアクションは常に「敵対的な環境」で動作しているからだ。具体的には、ネットワークの接続が突然切れたり、データベースの応答が極端に遅くなったり、外部のサービスとの連携でAPIがハングアップ（応答不能になること）したり、あるいはサーバー自体が突然再起動したり、ユーザーによって処理が途中でキャンセルされたりする可能性がある。このような予測不可能な状況がいつ発生してもおかしくないため、システムを設計する際には、まるで失敗が避けられない運命であるかのように考える必要があるのだ。

障害に強いアクションを設計するための最初のポイントは、常にCancellationTokenという仕組みを使うことだ。これは、実行中の処理に対して「もうこの作業は中止してください」という信号を送るためのものと考えるとよい。例えば、Webページからのデータ取得や一定時間の待機など、時間のかかる操作を実行する際、CancellationTokenを渡すことで、外部からの指示やタイムアウトによって、その操作を安全に途中でキャンセルできるようになる。もしこの仕組みがなければ、処理がいつまでも完了せず、ワーカーはそのアクションを停止させることができず、他の処理にも影響が出てしまうことになる。

CancellationTokenを使うことは大切だが、それだけでは十分ではない。外部のリソース（例えば、別のサーバーやデータベース）が応答しなかったり、応答が極端に遅れたりすることはよくある。そのため、外部との通信や特定の処理には必ず「タイムアウト」の時間を設定することが重要だ。例えば、Webサーバーへのリクエストであれば「30秒経っても応答がなければ諦める」といった設定をする。これにより、応答が永遠に来ないといった最悪のシナリオでも、システムがいつまでも待ち続けることを防ぎ、次の処理に進むことができる。

障害が発生したとき、最も困るのは「どこで、何が起こったのか」がわからないことだ。この問題を解決するために、アクションの重要な実行段階ごとにログ（記録）を残すことが非常に役立つ。例えば、「データ読み込み中」「データダウンロード完了」「データ保存中」「処理完了」といったシンプルなメッセージを記録するだけでも、アクションが途中で停止した場合、最後に記録されたメッセージを見ることで、どの段階で問題が発生したのかをすぐに特定できる。これは問題解決の時間を大幅に短縮し、初心者でも原因の特定に役立つ非常に有効な手段だ。

システムが障害に遭遇し、一度失敗したアクションが再実行されることはよくある。このとき、もし同じ処理が二度実行されることで、データベースに重複したデータが書き込まれたり、意図しない副作用が発生したりすると、システム全体の整合性が失われてしまう。これを防ぐために、「べき等性」という特性を持たせる必要がある。べき等性とは、「何回実行しても結果が同じになる」という意味だ。例えば、データをデータベースに挿入する際に、既に同じデータが存在しないかを確認してから挿入する、あるいは重複を許さないユニークな制約を設けるといった工夫が必要になる。これにより、万が一処理が複数回実行されても、安全に動作し続けることができる。

アクションが実行中に、その途中の状態（例えば、これまでに処理した件数など）をサーバーのメモリ上に保存することは避けるべきだ。なぜなら、サーバーが再起動したり、処理が別のワーカーに移されたりすると、メモリ上の情報はすべて失われてしまうからだ。アクションは、プロセスの再起動にも耐えられるように設計する必要がある。そのため、途中の状態を保存する必要がある場合は、データベースやメッセージキュー、あるいは永続的な状態を管理する専用のストレージなど、再起動後も情報が失われない場所に保存するべきだ。

一つのアクションが非常に多くの処理をまとめて行う場合、キャンセルや再試行、問題の特定が難しくなる。そこで、大きな処理を「ダウンロード」「処理」「集計」「公開」といった複数の小さなアクションに分割することが推奨される。小さなアクションにすることで、それぞれのアクションがシンプルになり、問題が発生した際にどこに原因があるのかを特定しやすくなる。また、一部のアクションだけをキャンセルしたり、失敗した部分だけを再実行したりすることも容易になり、全体としてシステムの回復力を高めることができる。

アクションがタイムアウトによって停止したことを確認するだけでは不十分だ。より重要なのは、そのアクションが停止した後も、メッセージキューが正常に動作し続け、他の待機中のジョブが問題なく実行されるかを確認することだ。具体的には、テスト環境で「最初のジョブを意図的に停止させる（タイムアウトさせる）」「その後に、二番目のジョブが問題なく実行され、システム全体が正常に処理を継続していること」を確認するような統合テストを行うべきだ。これは、実際の運用環境で発生する可能性のあるシナリオを正確にシミュレートし、システムの堅牢性を検証するための重要なステップとなる。

上記のような具体的な設計指針を踏まえた上で、記事は一つの実用的なルールを提案している。それは、プログラム中でawaitというキーワードを使って非同期処理を待機する箇所が出てきたら、必ず自分自身に「もしこの操作が永遠に完了しなかったらどうなるだろうか？」と問いかけることだ。もしこの問いに対する答えが「何も良いことはない」というものであれば、そのアクションはまだ本番環境で使うには準備不足であると判断できる。この自己問答を通じて、潜在的な問題点を見つけ出し、タイムアウトやキャンセル処理の導入を促すことができる。

理想的な世界では、システムに障害は起こらない。しかし、現実の運用環境では、日々のどこかで必ず何らかの障害が発生している。だからこそ、システムが障害に遭遇したときに、ただ停止してしまうのではなく、その後も動作し続けられるように設計することが非常に重要だ。

今回解説した、シンプルで障害に強いアクションは、主に五つの特性を持っている。それは、処理を安全に中断できるCancellationTokenをサポートしていること、外部リソースの応答待ちで止まらないように適切な「タイムアウト」を定義していること、問題発生時に原因を特定しやすくするために主要な「実行段階をログに記録」していること、そして、処理が再実行されてもシステムに悪影響を与えない「べき等性」を持っていること、最後に、再起動後も安全に動作を継続できるように「状態を永続的な場所に保存し、再実行も安全にできる」ことだ。優れたアクションとは、決して失敗しないアクションではない。むしろ、失敗が起こったとしても、その後もシステム全体が安定して動作し続けられるように設計されたアクションこそが、真に良いアクションと言えるだろう。システムエンジニアを目指す皆さんにとって、このような「障害に強いシステム設計」の考え方は、非常に価値のある学びとなるはずだ。