【ITニュース解説】Our Outage Was Not a Bug. Our Kubernetes Liveness Probe Killed 5 Healthy Pods

今回のシステム障害は、プログラムの欠陥、つまり一般的に「バグ」と呼ばれるようなものではなかった。代わりに、システムを自動的に安定稼働させるための重要な機能が、意図しない振る舞いをしたことで発生した。

まず、システム障害とは、ウェブサイトが表示されない、サービスが利用できないなど、システムが正常に機能しなくなる状態を指す。バグはプログラムコード内の間違いによって発生するが、今回の事例では、プログラム自体は正しく動作していた。問題は、そのプログラムが動く環境を管理する仕組みの、設定と振る舞いとの間に生じたズレだった。

この問題の舞台となったのは「Kubernetes（クバネティス）」という技術だ。現代のシステム開発では、アプリケーションを「コンテナ」と呼ばれる小さな仮想環境にまとめて動かすのが一般的になっている。Kubernetesは、たくさんのコンテナ化されたアプリケーションを、複数のサーバー上で効率よく、そして安定して動かすための管理システムだ。アプリケーションの起動、停止、サーバーへの配置、さらに問題が発生した際の自動的な復旧など、多岐にわたる運用作業を自動化する役割を担う。

Kubernetesが管理するアプリケーションの最小単位は「Pod（ポッド）」と呼ばれる。Podは、アプリケーションの実行に必要な一つまたは複数のコンテナ、ストレージ、ネットワークなどのリソースをまとめて含む。私たちが使うスマートフォンのアプリが、それぞれ独立したインスタンスとして動くように、Kubernetes環境ではアプリケーションの各インスタンスがPodとして動作すると考えるとよい。Kubernetesは、このPodを必要な数だけ起動したり、異常があれば再起動したりして、システム全体のサービス提供を維持する。

今回の障害の直接的な原因となったのが「Liveness Probe（ライブネスプローブ）」という機能だ。これは、Pod内で動いているアプリケーションが本当に正常に動作しているか（生きているか）を、Kubernetesが定期的にチェックするための仕組みを指す。「Liveness」は「生存していること」を意味する。もしアプリケーションが応答しなくなったり、フリーズしてしまったりした場合、Liveness Probeはそれを検知し、「このPodは異常だ」とKubernetesに報告する。報告を受けたKubernetesは、システムを健全な状態に戻すため、その異常なPodを自動的に終了させ、新しいPodを起動し直すことで回復を図る。これは、システムが停止するのを防ぐための非常に重要な自動回復機能として設計されている。

しかし、今回の障害では、このLiveness Probeが正常に動作している「健全なPod」を、誤って「異常なPod」だと判断し、終了させてしまった。これが問題の核心だった。Liveness Probeは、アプリケーションに対して特定のポートへのアクセスや、特定のファイルの存在確認、コマンドの実行などを行い、その結果が期待通りであるかをチェックする。もし応答がない、またはエラーが返ってきた場合、Probeは異常と判断するのだ。通常は、応答しないアプリケーションを自動的に復旧させるための仕組みだが、設定によっては逆効果になる。

なぜ健全なPodが異常と判断されたのか。それは、Liveness Probeの設定が、実際のアプリケーションの動作特性と合っていなかったためと考えられる。例えば、アプリケーションが起動するまでに時間がかかる場合、Liveness Probeのチェック開始タイミングを早すぎたり、タイムアウト時間を短く設定しすぎたりすると、まだ起動途中であるにもかかわらず「応答しない」と判断されてしまうことがある。また、一時的なネットワークの遅延や、アプリケーション内部の一時的な処理負荷の高まりによって、一時的に応答が遅れることがある。このような状況でも、Liveness Probeが厳しすぎる設定になっていると、正常なアプリケーションを異常と誤判断してしまう可能性がある。

記事では「5 Healthy Pods Killed」と表現されており、これはつまり、正常に稼働していたアプリケーションのインスタンスが5つ、Liveness Probeによって強制的に終了させられたことを意味する。アプリケーションが提供するサービスは、通常、複数のPodに分散して処理されることで、高い可用性や処理能力を保っている。しかし、健全なPodが次々と終了させられてしまうと、その分サービスを提供できるPodの数が減少し、最終的にはユーザーからのリクエストに応えられなくなり、システム障害に至ってしまう。

このようにして、アプリケーションのコードにバグがないにもかかわらず、KubernetesのLiveness Probeという自動回復のための機能が、誤った設定によって健全なPodを次々に停止させ、結果として大規模なシステム障害を引き起こした。この事例は、Kubernetesのような自動化された管理システムを導入する際、その機能や設定を深く理解し、アプリケーションの特性に合わせて適切にチューニングすることの重要性を強く示唆している。自動化は運用を効率化するが、その設定一つがシステム全体の安定性に大きな影響を及ぼすことを認識し、慎重な設計とテストが不可欠だという教訓となる。