【ITニュース解説】Cron Worker Retry Failure Capture Explained — Durable Background Evidence for SaaS

SaaS（Software as a Service）のようなシステムでは、ユーザーが直接操作する部分だけでなく、裏側でたくさんの自動処理が動いている。例えば、夜間にデータを集計したり、定期的にメールを送信したりする処理だ。これらは「バックグラウンドジョブ」や「Cron Worker」と呼ばれ、システムが円滑に動くために欠かせない。しかし、これらのジョブが失敗した場合、何が起こったのか、なぜ失敗したのかを正確に把握するのは非常に難しいことがある。従来のやり方では、失敗情報をアプリケーションのログファイルに記録することが多かったが、ログだけでは不十分で、特にシステム障害が起きたときに、「特定のお客様のこの操作に対して何が実行され、何が失敗し、何回リトライ（再試行）され、最終的にどうなったのか」という重要な問いに答えられないことが課題となっていた。

この課題を解決するためには、バックグラウンドジョブの個々の実行を、単なるログではなく「永続的な証拠記録（durable evidence record）」として扱うべきだという考え方がある。これは、ジョブの実行に関する情報を構造化されたデータとしてデータベースに保存し、後からいつでもその履歴を正確に追跡できるようにすることを目指す。具体的には、論理的なジョブ（たとえば「顧客Aの月次レポート生成」のような一連の作業）には安定した一意の識別子（job_id）を与え、そのジョブが実際に実行される個々の試行（たとえば「レポート生成の1回目」「リトライ後の2回目」）には、それぞれ異なる一意の識別子（attempt_id）を与える。さらに、そのバックグラウンドジョブの実行を引き起こした顧客の操作（operation_id）も明確に紐づける。これらの識別子をそれぞれ独立して管理することで、後で調査する際に「2つのエラーがそれぞれ異なるジョブの実行なのか、それとも同じジョブのリトライなのか」といった混乱を避け、何が起こったかを明確に区別できる。もしこれらが曖昧だと、問題解決が遅れる原因となる。

従来のシステムでは、ジョブの現在の状態を保持するデータベースの単一の行を繰り返し更新する設計がよく見られた。しかし、この方法だと、例えば前回の失敗情報が新しい情報で上書きされてしまい、過去の試行履歴が失われてしまう問題がある。ログファイルだけでは、ログの保存期間がシステムによって異なったり、サーバーの時刻がずれたり、ジョブの処理が完全に完了する前にログが出力されたりする可能性があり、信頼性に欠ける場合がある。そこで、永続的な証拠記録としては「追記型（append-oriented）」のアプローチが推奨される。これは、各試行ごとに新しい行（レコード）をデータベースに挿入していく方式で、以前のデータを上書きすることなく、すべての履歴が積み重なって残る。例えば、ジョブの処理中にワーカーが予期せず停止した場合でも、単に成功を示すログがないという理由だけで「失敗」と断定するのではなく、その試行が開始されたタイムスタンプを記録しておき、最終的な結果が判明したときに初めてその試行の状態を更新する。リトライが発生した場合も、以前の失敗レコードを更新するのではなく、新しい試行として新たな行を挿入するべきだ。

この証拠記録には、いつ実行されたかを示すタイムスタンプ、何回目の試行か、結果（成功・失敗）、エラーの種類、簡潔なエラーメッセージ、そして詳細な監視データ（テレメトリー）への関連付けキーなどを含めるべきだ。しかし、非常に重要な点として、セッション情報、データベース接続文字列、生のHTTPリクエスト本文、パスワード、個人情報といった機密性の高い情報は絶対に含めてはならない。OWASP（Open Web Application Security Project）のロギングに関するガイドラインでも、アクセスIDやパスワード、機密性の高い個人情報、データベース接続文字列を直接記録しないよう明確に警告しており、悪意のあるデータがログに挿入される「ログインジェクション」を防ぐためにイベントデータを安全な形に加工すること（サニタイズ）を推奨している。機密情報は、障害調査のための「証拠」として適切ではない。また、GDPR（一般データ保護規則）という個人情報保護の規制には「忘れられる権利」が含まれており、特定の条件下で個人データの消去を求めるユーザーの権利に対応する必要がある。そのため、データをどのように保存するかを設計する際には、データの分類、保持期間、削除のルールを明確にし、どのフィールドが個人を特定できる情報であるか、そして消去要求がどのように各保存場所に伝達されるかを文書化する必要がある。

実際の記録処理は、データベースのトランザクションという一連の処理の中で行われる。簡単な例で考えると、まず新しい試行の識別子を生成し、その試行が「実行中」の状態であるとしてデータベースに挿入する。この処理はトランザクション内で実行され、データの一貫性が保たれる。その後、ジョブの実際の処理を実行し、成功すればその試行レコードを「成功」として更新し、エラーが発生すればエラー情報と共に「失敗」として更新する。この際、エラーメッセージは機密情報が含まれないようにサニタイズされる。例えば、パスワードやトークンといった情報が含まれていれば、それらを「[REDACTED]」（編集済み）といった形で置き換える処理が組み込まれる。ただし、ジョブの処理が外部システムに変更を加えた後、データベースへの成功更新が完了する前にプロセスが停止する可能性も考慮する必要がある。この場合、試行レコードは「実行中」のままになり、回復ロジックはこれを「処理中に放棄された試行」と分類し、運用担当者や定義されたポリシーに基づいて再実行の安全性を判断できるようにする必要がある。エラー概要の文字数に制限を設けることは、データベースの行サイズを適切に保ち、運用上のクエリを読みやすくする上で重要であり、詳細な情報が必要な場合には関連付けキーを使って参照するというバランスを取ることを意味する。

ジョブが何度もリトライを繰り返した後、最終的に「これ以上リトライしない」という終端の失敗（terminal failure）に達したかどうかを、最後の例外メッセージの内容から推測すべきではない。リトライのポリシーはスケジューラ（ジョブの実行を管理するシステム）が持っているため、スケジューラが「これ以上試行をスケジュールしない」と判断したときに、その旨を明示的にジョブの論理レコードに記録する必要がある。個々の例外情報は各試行のレコードに属し、ジョブ全体の最終的な状態はジョブの論理レコードに属するという区別が重要だ。ジョブの具体的な状態モデルとしては、「保留中」「実行中」「リトライ待機中」「成功」「終端失敗」などが考えられる。状態の変更は一箇所で制御され、古い更新が新しい状態を上書きしないよう、バージョン番号などを用いて適切に管理する必要がある。

このような設計が本当に堅牢であるかを検証するためには、いくつかの重要なテストを行うことが推奨される。例えば、外部システムへの副作用が完了した後、データベースへの成功更新がコミットされる前にワーカーを強制終了させるテスト。また、エラー情報を外部の監視システムに送信できない状況でも、データベースには情報が適切に残るかを確認するテスト。さらに、同じジョブが二重に実行された場合に、それが適切に区別されて記録されるかを確認するテストも重要だ。これらのテストの後、このシステムに慣れていないエンジニアに、永続的な証拠テーブルだけを見て、何が起こったのかを再構築してもらう。もしエンジニアが推測しなければならないようなら、そのモデルには何らかの重要な状態や識別子が欠けている可能性がある。アラートの仕組みも、個々のリトライ可能な失敗（通常の運用ノイズの場合がある）と、顧客に影響を与える終端の失敗を区別して設計すべきだ。リトライ率の上昇は、終端失敗に至る前の劣化の兆候として警告を発するのに役立つことがある。

このような新しい「証拠記録」の仕組みをシステム全体に一度に導入するのではなく、段階的に進めることが推奨される。まず、ビジネス上の影響が大きく、最も重要なジョブタイプ一つに絞って導入を開始する。既存のエラーキャプチャ（エラー記録方法）はそのまま残しつつ、新しいジョブ、試行、操作、テナントの識別子を追加し、既存のシステムと新しい証拠記録システムの両方にデータを書き込む「デュアルライト」を行う。そして、意図的に障害を発生させるテスト中に、新しいシステムで再構築された履歴が、ワーカーの強制終了、ジョブの二重実行、詳細な監視データのエクスポート失敗といった状況でも正確に生存することを確認する。その後、フィールドごとのデータ保持期間や消去ポリシーを文書化し、証拠テーブルへのアクセス制御を追加し、不正な状態遷移が拒否されることを監視する。他のジョブタイプは、その副作用がべき等性（何回実行しても結果が同じになる性質）を持つことや、ジョブのペイロード（処理するデータ）が適切に分類されたことを確認してから移行する。

この設計アプローチは、バックグラウンドジョブの実行履歴、特に失敗やリトライの履歴において、不明確な部分や不確実性が明確にわかるような「実用的な履歴」を提供することを目指している。これにより、顧客に影響する障害が発生した際に、何が起こったのか、なぜ失敗したのか、そして最終的にどうなったのかを正確に、そして信頼性高く調査できるようになり、迅速な問題解決と顧客対応に大きく貢献する。