Kubernetesによる自動復旧を前提にステートレスなサービスのみ運用自動化

　OpenStack on Kubernetesだけでは実現できない機能を、ヤフーは「OpenStack Deploy Manager」として独自開発し、運用に組み込んだ。OpenStackの自動デプロイ、OpenStackコンポーネントの設定やパッケージの自動アップデートをするもので、それ自体もKubernetes環境で動作する。

　具体的には、初回構築時にOpenStackの設定ファイル（以下、OpenStack.conf）とChart、Valuesを用意した上で、Helmを使ってOpenStack.confをKubernetesにデプロイする。OpenStack.confは、各クラスタ固有の設定ファイルを含んでいる。人手で準備するのはここまで。後はOpenStack Deploy Managerが残りのデプロイ作業を全て自動で処理する。

　OpenStack Deploy Managerは各OpenStackコンポーネント用のWebデザイン用フレームワーク「Bootstrap」のスクリプトを自動で実行する。この段階で各OpenStackクラスタに必要なコンポーネントを読み込み、ネットワーク設定をする。デプロイに人手が介在するのは、この初回構築時だけだ。後はOpenStack Deploy ManagerとOpenStack on Kubernetesがアップデートを含めた全ての運用を自動的に行う。

　例えばnova.confを一部変更したとしよう。書き換えが終わったら、OpenStackクラスタの定義書であるValuesを書き換えてGitHubにプッシュする。するとCI（継続的インテグレーション）ツールの「Jenkins」がValues更新を検知してOpenStack.confをアップデートし、各Podがマウントしている設定ファイルも自動的に更新する。稼働中のPodに新しい設定を反映するため、OpenStack Deploy ManagerがPodのローリングアップデートもする。

　運用にヒューマンエラーが介在しないため、Kubernetesが健全に稼働していれば、その上で動いているOpenStackも100％健全に稼働していると判断できる。監視するのはKubernetesの動作だけでいい。

　ただしワークフロー監視やRabbitMQのクラスタ監視まではできなかった。「コンポーネントとして正常に作動しているだけではなく、インスタンスを正常に起動できているか、ボリュームを正常にマウントできているかというレベルでチェックする必要があります」（北田氏）

　ヤフーはここでも独自開発したツールを活用している。「OpenStack Monitor Manager」と「RabbitMQ Monitor Manager」がそれだ。前者は情報取得を目的とした参照系APIの返り値からPodの健全性を判断し、異常なものを強制終了する。Podを終了さえさせれば、KubernetesによってPodは自動的に再配置されるので、終了させるだけで健全性を確保できるというわけだ。後者のRabbitMQ Monitor ManagerはRabbitMQクラスタの状態やメッセージキューの正常性を自動監視する。異常なクラスタがあれば、こちらも強制終了し、Kubernetesによる再デプロイを促す。どちらも当然Kubernetes環境で動作するよう作られている。

　北田氏は「足りない機能を独自開発することで、Kubernetesを使ったOpenStackの運用自動化および障害の自動復旧を実現できました」と振り返る。ヤフーのこうした取り組みは、OpenStackの導入を検討している企業、プライベートクラウドの運用に悩む企業にとって、数多くの知見をもたらすことだろう。