障害に備える
障害は起きてしまうものとはいえ、なるべく防ぎたいですよね。Kubernetesには障害に有効な機能が標準機能として備えられています。このセクションではKubernetesの標準機能を紹介しつつ、他にも障害の備えに有効な手段もあわせて紹介します。
Kubernetesの標準機能の紹介
Kubernetesの特徴の一つとして「Self Healing」というものがあります。Self Healingとは具体的にどういった機能を指しているのか、みていきましょう。
KubernetesにはLiveness Probe、 Readiness ProbeそしてStartup Probeという設定項目があります。これらの機能では、一定間隔でヘルスチェックを行います。サービスが正常なレスポンスが返せなくなったとしても、お客さまに影響を出さないように利用するための機能です。
Liveness Probe
Liveness Probeを利用してコンテナを自動再起動するタイミングを設定します。例えばデッドロックのように、「アプリケーションは正常に起動しているが、処理を継続できなくなってしまった」ということを検知して再起動するようなケースを想定しています。
Liveness Probeでは例えばヘルスチェック用のパス/healthzを指定し、このパスからエラーコードが返ってきたらコンテナを再起動します。
Liveness Probeは便利である一方、設定内容を間違えるとコンテナが常に再起動を行うようになってしまいます。慎重に設定した方が良い項目でしょう。少し古い記事ですが、こちらを参考にしてLiveness Probeを適切に設定してください。
Readiness Probe
Readiness Probeではコンテナがトラフィックを受け入れ可能なタイミングを設定します。Pod内の全てのコンテナがReadiness Probeを満たしていると、ステータスがReadyになります。PodがReadyになるまでServiceを経由したPodへのアクセスはできません。
Readiness Probeの設定はコンテナのライフサイクルの全てにおいて実行されます。そのため、突然アプリケーションがバグによってトラフィックを受け入れられなくなってしまった場合、Readiness Probeの設定に従いServiceのロードバランシングから自動ではずします。こうすることで、ユーザーからのトラフィックがReadyではなくなったPodに送られることを防げます。
Startup Probe
Startup Probeは初回起動のみ遅いコンテナに対して設定する項目です。Liveness Probeは設定したいけれど、コンテナの起動が遅くあまり短い時間に設定できない場合に使用します。Startup Probeは一度成功した後は利用されることがありません。
それぞれのProbeの機能を最大限活用するために、アプリケーション開発エンジニアはヘルスチェック用のパスを作成したり、「何が正常なのか」を定義したりする必要があります。これらはKubernetesに限らず必要になってくると思いますが、本番運用でSelf Healingをうまく活用するためにはぜひ準備しておきたいですね。
以上、各Probeについてさらに詳細を知りたい場合は公式ドキュメントを参照してください。
Node障害時の自動復旧
第1回でも紹介した通り、Kubenetesでは「Reconcile Loop」を利用してマニフェストに書かれた設定（Desired state）で稼働し続けようとします。
これはNode障害時でも同じです。あるNodeが故障してしまった場合、そのNodeに乗っていたコンテナは自動的に他のNode上に作成されます。ただし、あらかじめコンテナを冗長化しておかなければ、Nodeが故障してから次に作成されるまでの間、ユーザーからみるとコンテナへのアクセスは完全に断たれてしまいます。
冗長化する
障害に備えるために冗長化するというのはKubernetesに限った話ではないですが、Deploymentを利用することで簡単にコンテナを冗長化できます。
コンテナを稼働する最小の単位はPodですが、ユーザーが直接Podを作成することはありません。Deploymentを作成することで、複数のPodを簡単に作成することができます。
マニフェストのreplicasの値に設定しておいた数だけPodを複製することができます。
また、増えたPodに対してServiceを経由したロードバランシングも自動で行われるため、非常に便利です。
障害発生の訓練を行う
これもKubernetesに限った話ではありません。防災のために避難訓練を行うのと同様、日頃から障害発生時の訓練を行うことで障害に備えることができます。
訓練の方法は色々ありますが、ここではKubernetesの登場で活性化している「カオスエンジニアリング」について紹介します。
カオスエンジニアリングとは、本番環境が障害等による不安定な状況にも耐えられることができるという自信をつけるための方法論です。具体的な方法として、なにかしらの障害（カオス）を発生させ、システムが自動で障害から復旧できるかどうか確認します（参考：エンタープライズでも注目の「カオスエンジニアリング」とは何か？ 求められる背景と実践のプロセス）。
カオスエンジニアリングを実現するツールはいくつかあります。その中でもChaos MeshはKubernetesに特化しており、今年の2月にCNCFのIncubatingプロジェクト（※）に認定されました。
本番運用の自信がつくようになる、という理想的なカオスエンジニアリングですが、一方、本番環境で障害を意図的に発生させるのはかなりハードルが高いですよね。また、ある程度運用の知見が溜まっていたり、Kubernetesを安定運用できていたりする土壌が必要なので、本番運用に慣れるまでは知識を持っておく程度に止めても良いと思います。
※CNCFとはCloud Native Computing Foundationの略称で、このFoundationに認定されるプロジェクトにはGraduated、 Incubating、 Sandboxの3種類があります。ソフトウェアの成熟度によってどの種類に位置するのか決まります。
他社の障害事例を知る
他社の障害事例を知るのも障害に備える助けになります。
例えば以下の企業の紹介事例をインターネットで閲覧することができます。
- Spotify社：テスト環境と間違えて本番環境を削除してしまう
- Airbnb社：クリーンアップ処理で本番環境のコンテナイメージを次々と削除してしまう
どんなにしっかり運営している企業でも事故は起こりうる、と思うと勇気が出ますよね（これはKubernetesに限った問題ではなく、本番環境の運用を継続していれば障害はつきものということです）。
また、以下のサイトでさまざまな企業のFailure Storyを参照することができます。たくさん先人から学んで障害に備えましょう！
