ヤフーがプライベートクラウドの運用を始めたのは2011年。2013年にはOpenStackを利用し始めたというから、かなり早い段階から運用の省力化に取り組んできたことが分かる。今ではOpenStackクラスタ監視対象は50個を超え、ハイパーバイザー数は6000台以上、仮想マシン（VM）数は9万台以上という大規模なクラウドインフラへと成長している。

　ヤフーのシステム統括本部に勤める木下裕太氏は、「プライベートクラウドの規模が大きくなっただけではなく、使われ方も変化してきました」と語る。2013年当初は開発環境用の汎用（はんよう）クラスタと、本番環境用の汎用クラスタの2種類しかなかったが、今ではサーバ仮想化製品「VMware vSphere」をバックエンドに使った高可用性クラスタや、性能を保証する高性能クラスタなど、多様なクラスタを提供している。

　近年特に増えているのは、アプリケーションのバックエンドシステムを稼働するインフラとしての利用だという。インフラを意識せずアプリケーションを開発できるので、新サービスを開発する部門にとってはありがたい話だ。一方で、インフラの正常稼働がアプリケーションの信頼性を左右することにもなるため、プライベートクラウド環境の運用担当者には大きな責任がのしかかることになる。

　「OpenStackの健全性がシステム全体の健全性を左右します。インフラの機能停止は、アプリケーション単位の障害とは比較にならない致命的な事態を引き起こします。クラスタ数が増え続ける中で健全性も担保していくためにどうすればいいか、対応策を考えなければなりませんでした」（木下氏）

　クラスタ数の増大そのものも課題だった。クラスタ当たりのOpenStackコントローラーは約50台。現在50クラスタが稼働しており、2500台のコントローラーを管理しなければならない状況になっている。管理すべきOpenStackコンポーネントの設定やパッケージ情報は膨大な数に上り、手作業では負担が大きい上にヒューマンエラーの恐れもあった。また、クラスタの数が増えれば障害も増える。手作業での復旧もエンジニアの大きな負担となっていた。

　クラスタ数の増加には、オープンソースの構成管理ツール「Chef」を使って対処した。「クラスタの構築や更新をコード化することで作業負担を軽減し、ヒューマンエラーを排除していましたが、それだけでは追い付かなくなってきたのです」（木下氏）

「OpenStack on Kubernetes」の採用で運用課題の大部分を解消

　プライベートクラウド基盤の運用改善には、欠かせない要件があった。障害の自動復旧、OpenStackクラスタの構築・更新の自動化、ワークフローレベルの正常性担保の3つだ。

　これらを解決するためには、人手ではなく、システムによるオーケストレーション（自動化）を運用に取り入れる必要があった。「Chefもそのために導入しましたが、100％の自動化には至っていませんでした」（木下氏）

　オーケストレーションのより高度な自動化を求めてヤフーが目を付けたのは、Kubernetesだ。コンテナのオーケストレーションツールで、コンテナのデプロイ（配備）やスケジューリング（複数サーバへの自動割り当て）に加えてヘルスチェックなどの機能を備える。小規模なサービス群で構成する「マイクロサービスアーキテクチャ」を採用したシステムの管理に適したツールといえる。Kubernetesは、複数のコンテナをまとめたアプリケーションの最小単位である「Pod」というグループを基に、Podの数を管理する「ReplicaSet」や、ReplicaSetを生成・管理する「Deployment」によって成り立っている。仮に障害が発生してPodが停止した場合、健全なハードウェアで新たなPodを自動生成し、ReplicaSetで指定されたPod数を保つ仕組みになっている。HTTPなどの各プロトコルでPodの健全性をチェックし、異常なPodを自動削除する。もちろん削除後にはReplicaSetに合わせて新たなノードが生成されるので、パフォーマンスも維持できる。

　「Kubernetesによって、ハードウェア障害、ソフトウェア障害を含めて、冗長化や障害対応のための再起動などを気にする必要がなくなります」（木下氏）。さらに「プローブ」という監視機能を使って各コンテナの正常性を担保することもあるという。

　Kubernetes環境にアプリケーションを展開するためには、データ交換フォーマットのYAMLかJSONで記述した定義ファイルをAPI経由でKubernetesに渡すだけでいい。これにより、アプリケーションのデプロイや更新を自動化できる。マニフェスト（設定）ファイル群を「Chart」というパッケージにして、アプリケーションをテンプレート化し、パッケージマネジメントツール「Helm」を使って展開することもできる。

　Kubernetes環境でOpenStackを稼働させる「OpenStack on Kubernetes」による運用環境を構築したことで、障害の自動復旧、個々のコンポーネントの正常性監視、デプロイの簡略化は実現した。しかし「ワークフローレベルでの正常性監視やデプロイの完全自動化までには至りませんでした」（木下氏）

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

　ヤフーが目指していたのは、障害の自動復旧、OpenStackクラスタの構築・更新の自動化、ワークフローレベルの正常性担保を完全に自動化することだった。「初回のデプロイはどうしても人手に頼らなければなりませんが、その後のデプロイや障害復旧は完全に自動化したいと考えました」。ヤフーのシステム統括本部に勤める北田駿也氏は、OpenStack on Kubernetesを選んだ理由をこう語る。

　だがOpenStack on Kubernetesだけでは、運用の完全自動化を実現する上で不十分だったという。実際にどのような点が不足していたのか。

　ヤフーが構築したのは、アプリケーションのソースコードやクラスタの構成仕様を全てソースコード管理サービスの「GitHub」で一元管理し、最新の変更をクラスタへ自動的に反映する仕組みだ。この仕組みにより、プライベートクラウド環境の運用の大部分を自動化できた。アプリケーションのデプロイに必要なものはDockerファイル、Chart、「Values」の3つ。Valuesは、クラスタごとにマニフェストの中身を書き換え、Kubernetes環境にOpenStackを展開するために使う固有設定情報ファイルだ。

デプロイに必要なもの

　北田氏は「方針として、（1回のやりとりごとに状態を初期化する）ステートレスなサービスだけをKubernetesに移行しました」述べる。具体的には各API、「Keystone」「Glance」「Nova」などのOpenStackコンポーネントだ。また、ステートレスではないものの、フロー情報しか扱わず再起動によりデータが消失しても困らないサービスも、一部Kubernetesに移行しているという。メッセージ転送システム「RabbitMQ」やメモリキャッシュシステム「memcached」がこれに当たる。

　データベースやOpenStackコンポーネントの「Swift」、VMのライブラリである「Libvirt」など、やりとりをまたいで状態を保持するステートフルなサービスは、Kubernetesでの運用に不安が残ったのでコンテナ化しなかったという。障害復旧を自動化するという観点から、再起動を前提に運用できるものだけをKubernetesで管理するという選択だった。

　これでは「OpenStack on Kubernetesで、私たちが考える完全な運用自動化はできません」と北田氏は言い、講演で同氏は、OpenStack on Kubernetesを補う仕組みを含め、ヤフーにおけるアプリケーションデプロイフローを紹介した。