【ITニュース解説】Silent Breakage Detection: Poll Queries, Cron Jobs, and SaaS API Error Rates

システムを運用していると、プログラムが動かなくなったり、ウェブサイトが表示されなくなったりする、わかりやすい障害が発生することがある。しかし、もっと厄介な種類の障害も存在する。それは、システムが完全に停止しているわけではないのに、本来果たすべき仕事を黙ってサボってしまっているような「サイレントな障害」と呼ばれるものだ。例えば、毎日自動で実行されるはずのデータ集計が、気づかないうちに数日前から停止していても、システム自体はエラーを吐かずに正常に動いているように見える場合がある。このようなサイレントな障害をどうやって見つけ出すか、そのための効果的な方法について説明する。

まず、サイレントな障害を検知するための基本的な考え方として、大きく3つの重要なシグナルを用いる。1つ目は、多くのリクエストが発生するAPI通信において、エラーがどれくらいの割合で発生しているかを数える「エラーレートカウンター」だ。2つ目は、定期的に実行されるプログラム（例えばCronジョブと呼ばれる自動実行タスク）が最後に成功したのはいつだったかを、そのプログラムの外部から監視して記録する「最終成功タイムスタンプ」。そして3つ目は、アラートシステムが実際に機能し、障害発生時に適切に通知し、そして障害が解消されたときに正しく復旧を示すかを事前にテストすることだ。このテストは、アラートシステム自体が正しく動作することを確認する上で不可欠となる。

ここで重要なのは、ただ見た目がきれいなグラフをダッシュボードに表示するだけでは不十分だということだ。本当に必要なのは、システムが期待通りの成果を出せなかった場合と、単に処理が完了しただけの場合を明確に区別できるシグナルであり、さらに「そもそも処理が開始されなかった」という状況を検知できるシグナルである。表面的な情報に基づくチャートは、自信満々に間違った状態を報告してしまう可能性があるからだ。

このサイレントな障害検知は、開発したプログラムを本番環境で動かす「本番投入」の段階で、「評価」という観点から捉えることができる。具体的には、そのプログラムが達成すべき期待される結果を明確に定義し、次に意図的にいくつかの障害パターンを作り出して、その障害が発生したときにアラートシステムがどう反応するかをテストし、そのパスを評価する。この際、データの収集方法や、アラートを出すための検索言語、通知システムといった具体的なツールは、必要に応じて交換可能な部品と考えることができる。それよりも、どのような種類の失敗を検知すべきか、という「失敗に関する契約」こそが、長く使える最も重要な部分となる。

特に、SaaS（サービスとしてのソフトウェア）のAPIを呼び出して、定期的なタスク（Cronジョブ）を実行しているような場合、そのジョブが失敗していないかを監視する方法は重要だ。監視プログラムは、単にAPIへの通信が成功したかを確認するだけでなく、そのAPIが提供する最も具体的な「ビジネス上の成果」を検証すべきである。例えば、スケジュールされたデータ出力が最終的にファイルを生成することを目的としているならば、ポーリングプログラム（定期的にシステムの状態を確認するプログラム）は、APIのドキュメントに記載されている完了状態を確認するか、実際にそのファイルが生成されたことを確認すべきだ。単にAPIからの応答があったことだけを成功とみなしてはいけない。

具体的には、3つの異なる種類のシグナルを組み合わせる。1つ目は、APIへのリクエストがどれくらいの回数行われ、その結果が「成功」「拒否」「レート制限（処理できる量を超過）」「タイムアウト」といった、限られた種類のカテゴリに分類されたかを数えることだ。これにより、APIの利用状況とエラーの発生頻度を把握できる。2つ目は、最新のスケジュールされた実行が、事前に定められた完了条件を本当に満たしたかどうかを記録するフラグだ。これが「false」であれば、明示的にジョブが失敗したことを示す。そして3つ目は、最後にそのジョブが「検証済みの成功」を収めた日時を、ユニックスタイムスタンプという形で記録しておくことだ。このタイムスタンプが、最後に成功してからどれくらいの時間が経過したかを示してくれる。

この3つ目のシグナル、つまり「最後に検証された成功のタイムスタンプ」が、特に重要な役割を果たす。なぜなら、多くのシステムは「エラーが発生した」ことは報告できるが、「そもそも実行されなかった」という事態を自ら報告することはできないからだ。例えば、Cronジョブが何らかの理由で起動しなかった場合、そのジョブ自体は何も報告しないため、外部からの監視が不可欠となる。

そのため、この監視プログラム（ポーラー）は、監視対象のジョブとは完全に独立して実行されなければならない。また、いつまでに完了すべきかという「期限」と、ジョブが成功したとみなすための「完了条件」も、APIの契約に基づいて明確に定義する必要がある。メトリック（監視指標）のラベルには、テナントIDやリクエストID、エラーメッセージの本文、アクセストークンといった情報を直接含めるべきではない。これらの情報は種類が非常に多くなり（「高カーディナリティ」と呼ばれる）、監視システムのコストを増大させるだけでなく、機密情報を漏洩させるリスクもある。情報セキュリティのガイドライン（OWASPなど）が秘密情報や個人データをログから除外するかマスクすることを推奨しているように、監視データも同じように慎重に扱うべきだ。メトリックは「何らかのパターンが起きているか」を答え、詳細な診断にはアクセス制限された構造化されたログや、システム間の処理の流れを追跡するトレースを使うのが適切だ。

アラートを発生させるためのクエリ（問い合わせ）は、「どのような失敗が起きているか」という意味に基づいて構築する。APIのエラー率は、ある一定期間（ウィンドウ）における全試行回数に対する失敗した試行回数の比率で計算される。ただし、トラフィックが非常に少ない場合、例えば1回の試行が失敗しただけでエラー率が100%になるからといって、すぐに誰かを起こすべきではない。ある程度のトラフィック量（フロア）が必要であり、ウィンドウの期間やエラー率の閾値は、サービスの目的と通常のトラフィックパターンに基づいて決定する必要がある。

Cronジョブの監視では、「明示的な失敗」と「実行されなかったことによる不在」に対して、それぞれ異なるルールが必要となる。「最新の実行が失敗したかどうか」は、先述のフラグで判断できる。一方、「検証済みの成功から時間が経ちすぎたかどうか」は、成功タイムスタンプの経過時間で判断する。ジョブが失敗した場合でも、成功タイムスタンプをリセットしてはいけない。そのタイムスタンプが古くなること自体が、「実行されていない」という状態の証拠となるからだ。

アラートには、それが「復旧した」ことを示す条件も必要だ。エラー率が閾値を超えてアラートが発生した場合、復旧条件も同じ閾値を使うか、少し低い閾値を使うかを決める必要がある。これにより、閾値の近くで状態が頻繁に切り替わるのを防げる。成功の停滞が原因のアラートであれば、新しい成功が確認されたときにアラートが解除される。アラートが出て、それが解消されたかどうかオペレーターが推測するような状況は避けるべきだ。

ダッシュボードは、これらの監視ルールが確立された後に作成する。最初は、リクエスト量、エラー率、処理時間、最新実行ステータス、成功からの経過時間、リトライ回数、現在のアラート状態といった、必要最小限のコンパクトなビューで十分だ。それぞれのパネルは、障害対応手順書（ランブック）に記載されている質問に答えられるものであるべきで、それ以外は単なる装飾に過ぎない。

システムがサイレントな障害を適切に検知できるかを検証するには、どのような運用モデル（自社で監視システムを構築するか、外部のサービスを使うか、既存のシステムを使うか）であっても、同じテストケースを実行して評価することが有効だ。最低限、3つのケースでテストを行うべきだ。1つ目は、十分な回数の試行（例：20回）の中で数回の失敗（例：4回）が発生し、エラー率が閾値を超えるケース。これはエラー率の計算が正しく機能するかを検証する。2つ目は、最新の実行が「失敗」と明示的にマークされるが、その前の成功タイムスタンプはそのまま保持されているケース。これは明示的な失敗が検知されるかを見る。3つ目は、許容されるスケジュール間隔を超えて時間が経過しているのに、新しい実行記録が全く生成されないケース。これは「実行が欠落した」状態を検知できるかを検証する。これらのテストと同時に、システムが正常な状態や、トラフィックが非常に少ない状態では、不必要なアラートを出さないことを確認することも重要だ。

このテストは、アラートが実際に意図した宛先に届き、そのアラートに障害の原因や対応策といった有用な情報（コンテキスト）が含まれていることを確認するまで行う必要がある。そして最後に、障害が解消されたときにアラートも適切に復旧することを確認する。ただグラフが動いているのを見るだけでは十分な確認とは言えない。

メトリックベースのアラートは非常に有用だが、限界もある。個々のリクエストの詳細を再構築したり、監査のための証拠を生成したり、複雑な分散システム全体の因果関係を完全に説明したりするには向いていない。そのような目的のためには、保護された構造化ログやトレースを使うべきだ。また、単に失敗回数を数えるだけでは、AIが生成した回答の品質が適切かどうかを証明することはできない。AIの出力品質には、別途、適切な評価基準を設けて検証する必要がある。

サイレントな障害検知システムを導入する前に、エラー率の閾値超過、明示的なジョブの失敗、そしてジョブの実行欠落という3つの主要な障害シナリオを実際に発生させてみることが重要だ。そして、システムがそれらを正確に検知し、適切なコンテキスト（背景情報）を伴う通知を送り、予測どおりに復旧することを確認し、このシステムの責任者が明確になっているならば、このシンプルながらも堅牢なアーキテクチャは十分に機能していると言えるだろう。