【ITニュース解説】Thirty four pods each failed a little and our alert judged them one at a time

今回の話は、システム運用におけるアラート設定の盲点と、現代の動的に変化するシステムでの監視の難しさについて解説する。ある日、ある企業の販売税計算サービスで異常が発生した。このサービスは、顧客が商品を会計する際に必要となる、外部の税計算APIと連携している。この重要なAPIが、通常は問題なく動作するはずが、8回に1回の頻度でエラーを返すようになってしまったのだ。

この問題は、外部からの報告、具体的には顧客からの問い合わせを受けたサポートチームを通じて運用チームに伝えられた。しかし、その時点で既にエラーが発生し始めてから2時間が経過していたという。システムには異常を検知するためのアラートルールが設定されていたはずだが、なぜかこの深刻な異常を検知しなかったのだ。

運用チームが調査を始めると、まさにこの種類のエラーを検出するために作られたアラートルールが存在していることが分かった。そのルールは「チェックアウトサービスを構成する任意のPod（アプリケーションの実行単位）が、1分間に40件を超えるアップストリームエラー（外部サービスへの呼び出しで発生するエラー）を記録した場合に通知する」というものだった。このルールは3年前に設定されたもので、当時のチェックアウトサービスは4つの大きなPodで稼働していた。その環境では、もし1つのPodで1分間に40件ものエラーが発生すれば、それはシステム全体にとって明らかに異常な状態であり、ルールは過去にも正しく機能していた実績があった。そのため、長らく誰もこのルールの内容を見直す必要性を感じていなかった。

しかし、このシステムは春に行われたコスト削減のためのプロジェクトで大きく変更されていた。これまで使っていた大きなPodから、より安価なサーバー上で動く小さなPodへと移行していたのだ。さらに、システムの負荷に応じてPodの数を自動的に増減させる「オートスケーラー」が導入されていた。これにより、通常の時間帯では30から38個のPodが同時に稼働するようになっていた。

今回の障害発生時、チェックアウトサービス全体では1分間に約600件ものアップストリームエラーを発生させていた。これは、サービス全体としては明らかに深刻な異常事態である。だが、システムは34個のPodで構成されており、この600件のエラーは34個のPodに分散して発生していた。つまり、1個のPodあたりに換算すると、1分間に約18件のエラーしか発生していなかったことになる。

ここで問題が明らかになる。個々のPodは、アラートルールが設定していた「1分間に40件」という閾値をはるかに下回るエラー数だったため、どの子のPodも単体ではアラートを発しなかったのだ。システム全体としては深刻な問題が発生しているにもかかわらず、個々のPodレベルで設定された監視ルールは「全て正常」と判断し続けてしまった。これは、たとえシステム全体で問題が起きていても、その問題が多くの小さな単位に分散されてしまうと、個々の単位だけを監視するルールでは検知できないという状況を示している。

さらに、システムの状況を表示するダッシュボードにあった「最もエラーが多いPodのエラー数」を示すパネルも、同様に問題の兆候を隠してしまっていた。Podの数が大幅に増えたことで、たとえ最もエラーの多いPodであっても、そのPodが担当するエラーは全体のごく一部に過ぎなかった。そのため、その数値だけを見ていても全体の問題を把握することはできなかったのだ。

この問題の根本原因は、アラートルールが持つ「閾値（しきいち）」の設計にあった。このルールにはPodのインスタンス数（稼働しているPodの数）に関する条件は一切記述されていなかったが、その閾値「40件/分」は、暗黙のうちに「数個のPodで構成される」という以前のシステムの前提に基づいていた。具体的には、サービス全体で許容されるエラー数を、当時のPod数（4個）で割って算出された定数として設定されていたのだ。しかし、システムのPod数はオートスケーラーによって大きく変動するようになり、古い固定された閾値は現実と乖離してしまった。システム全体の規模が大きくなり、Podの数が増えたにもかかわらず、個々のPodに対するエラーの上限値は据え置かれていたのである。オートスケーラーは、システムの柔軟性を高める一方で、このように個々のインスタンスに依存する閾値設定の有効性を変化させてしまう危険性をはらんでいるのだ。

この経験を受けて、チームは所有する全てのアラートルールを見直すことにした。そして、ルールを大きく二つの種類に分類し、再設計を行った。

一つ目の種類は「サービス全体の状態が異常かどうか」を問うルールだ。これは、全てのインスタンス（Pod）からのデータを集計し、全体での比率を比較するものだ。例えば、「サービス全体で発生したアップストリームエラーの数が、全アップストリーム呼び出し数に対して2パーセントを超えた状態が5分間続いたら通知する」といった形だ。この方法であれば、Podの数が4個であろうと40個であろうと、サービス全体としての健全性を正確に評価できる。エラーが多数のPodに分散して発生していても、全体のエラー率が高ければ問題として検出される。

二つ目の種類は「個々のインスタンス（Pod）が異常な振る舞いをしていないか」を問うルールだ。これは、あるPodの挙動を、他の兄弟Podと比較して判断するものだ。例えば、あるPodだけが他のPodよりも極端に高いエラー率を出している場合などに発火する。このアプローチも、Podの総数に影響されず、個々の異常を的確に捉えることができる。

さらに、インスタンスごとの絶対的なエラー数を閾値として設定するルールがまだ残っている場合のために、新しい運用ルールを設けた。そのようなルールには、必ずその説明に「この閾値が想定しているインスタンス数」を明記するように変更したのだ。そして、その想定インスタンス数と現在の実際の稼働Pod数とが半分以上異なるルールを自動的に検出するための月次ジョブを導入した。これにより、システムの構成変更によってアラート設定が古くなることを防ぎ、定期的な見直しを促すことができるようになった。

この出来事は、オートスケーラーのような動的なシステムにおいては、監視とアラートの設定が常にシステムの現在の状態と整合しているかを確認することの重要性を浮き彫りにした。オートスケーラーは、個々のインスタンスに対する閾値の「分母」となるインスタンス数を自動的に変更する。しかし、その閾値の「分子」（例えば許容エラー数）を設定した人間には、その分母の変化が直接的に通知されるわけではない。システムが進化する中で、アラートルールもまた、その進化に合わせて適切に更新され続けなければならないという、重要な教訓を与えてくれた事例だと言える。