コマンド1つでKubernetesクラスタを作成　ゼットラボが開発したKubernetesを容易に管理できるサービス「CaaS」

ヤフー/ゼットラボのステートフルアプリケーションへの挑戦

坂下幸徳氏（以下、坂下）：では発表を始めたいと思います。『ヤフー/ゼットラボのステートフルアプリケーションへの挑戦』と題しまして発表いたします。

本日のアジェンダです。まず前半は私からKubernetes as a Service向けステートフルサービスの実現と題しまして発表します。後半はヤフーの飯田からステートフルアプリケーションの事例を紹介します。

まず簡単に私の自己紹介をします。坂下と申します。ゼットラボで働いています。SNIAというストレージの業界団体の日本支部の技術委員会の副委員長も務めています。またアメリカにあるSNIA本部の全テクニカルワーキンググループの取りまとめをしているTechnical Councilにも所属しています。

私はよくストレージ屋さんと言われがちなんですが、ストレージをちょっと知っている運用管理技術屋さんです。前職は日立製作所の研究所に勤めていました。ゼットラボに転職前はシリコンバレーにある海外のラボのラボ長なんかも務めていました。

ヤフーとゼットラボの運用体制

ではここから紹介していきたいと思います。まずヤフーとゼットラボが作るKubernetes as a Service、こちらについて紹介いたします。

ご存知の方も多いかと思いますが、まずヤフーについて簡単に紹介します。ヤフーは、Yahoo!ニュースですとか、ヤフオク、天気など100以上のWebサービスを提供しています。日本国内に5拠点、アメリカに2拠点のデータセンターをもっています。

このデータセンターでOpenStackやKubernetesなどを活用したプライベートクラウドを構築し、その上でWebサービスを構築、サービス展開しています。

次にゼットラボについて紹介します。ゼットラボは2015年に設立されたヤフー株式会社の100パーセント子会社です。ヤフーの次世代インフラを研究開発しています。ヤフー向けにKubernetes as a Service、我々はCaaSと呼んでいるのですが、このCaaSを開発しています。

ここでヤフーとゼットラボの体制について紹介します。ゼットラボはCaaSを開発し、ヤフーに提供しています。ヤフーのCaaS管理者、こちらのメンバーが実際にKubernetesを払い出し、Kubernetesの利用者、Webのサービスの開発者たちにKubernetesを提供しサポートしてくれています。さらにゼットラボは、この利用者向けにも設計相談や技術セミナーを実施しています。

またこのCaaSを支えるインフラとしてサーバー、ネットワーク、ストレージなどがありますが、それぞれのチームに対してもゼットラボではCaaS向けにインフラの評価や構成を検討しています。

場合によってはヤフーのメンバーとともに外部のベンダーに要望や問い合わせなども行っています。このような体制で我々はヤフーに対してCaaSを提供しサポートしています。

ヤフーにおけるKubernetes as a Service

次にゼットラボにて開発してヤフーで運用してくれているKubernetes as a Service、こちらについて紹介します。ご存知の方も多いかと思いますが、Yahoo! JAPANのWebサービスの一部は現在Kubernetes上で稼働しています。

さらにこのKubernetes。よく言われていますが、管理は非常に難しくて大変です。そこで我々ゼットラボでは、ヤフーのメンバーが容易に管理できるようにマネージドなKubernetesサービスとしてKubernetes as a Service、CaaSを提供しています。2017年8月にベータを提供し、2018年8月にGAとしてサービスインしています。現在ヤフーのメインとなる2つのリージョンのデータセンターでこれが稼働しています。

このCaaS、社内でも非常に好評で、2020年5月の段階で現在680以上のKubernetesクラスタを払い出しています。ヤフーのWebサービスの利用している開発チーム数としては210チーム以上が利用しています。またKubernetesを構成するNode、我々だとVMなのですが、この数は1万3000以上です。コンテナの数は非常に多いですね。12万以上と非常に多い数が使われています。

CaaSのアーキテクチャ

次に簡単にCaaSのアーキテクチャについて紹介します。CaaSはKubernetesのCRDとカスタムコントローラー活用して開発しています。左側のこのKubernetes、こちらがOpenStackのAPIを通じてVMを管理します。その後、左側のKubernetesがVM上にまたKubernetesのクラスタをセットアップします。アプリケーションの開発者はこちらの上側のKubernetesを使い、コンテナを実行しサービス展開しています。

CaaSはいくつかパワフルな機能をもっているのですが、ここでは代表的な機能をいくつか紹介します。1つ目はセルフヒーリングです。VMが壊れたことを左側のKubernetesが検知すると、セルフヒーリングのフレームワークに従ってVMを再作成します。さらにこの壊れたVMと新しいVMをリプレイスするということでKubernetesクラスタ自体のセルフヒーリングを実現しています。

次はスケーリングです。右側のこちらのKubernetesでリソース不足が発生した場合、OpenStackを通じて新しいVMを追加します。その後このKubernetesクラスタにVM（Node）を追加するということで、Kubernetesのクラスタ自体のスケーリングをサポートしています。

通常Kubernetesですと、Podのスケールアウトを実現していますが、CaaSではKubernetesクラスタ自体もスケールできるようになっています。またこのようにVMの作成追加を行うようにすることで、サービスを止めることなくVMのセキュリティパッチやOSなどのアップデートが可能となります。

次の特徴として、Addon-managerがあります。これはKubernetesのAddon-managerの仕組みを利用し、ゼットラボにて開発しているものです。Grafana、Prometheusなどみんなが使うであろうアプリケーションを提供しています。

提供するアプリはゼットラボにて開発のGrafanaダッシュボードやアラートルールなども組み込み、パッケージ化して配布しています。これによりユーザーはCaaSを使い、Kubernetesクラスタを作成した直後からGrafanaのダッシュボードでKubernetesの監視ができ、アラートも受け取ることができます。

また独自のAddon-managerは、Kubernetesのバージョンがアップデートされると、それに合わせて配布するアプリもアップデートするようにしています。

CaaSの特徴

ここでCaaSの特徴を簡単に整理して紹介します。まずCaaSを使うことで、コマンド1つでVM作成からKubernetesのクラスタの作成までを行うことが可能です。また先ほど説明したアーキテクチャを使い、サービス無停止でKubernetesクラスタ自体のローリングアップデートが可能です。これにより3ヶ月に1回のKubernetesのアップデートにも追随可能です。

またNodeを再作成しますので、NodeのOSのセキュリティパッチなどにも対応が容易です。これは個人的な感想なのですが、このように日頃からNodeを作り直すということを当たり前にするということで、障害に強いヤフーのWebサービスを実現できているのではないかと感じています。

そのほかとしては先ほど紹介したKubernetesクラスタのセルフヒーリングやスケールアウト／スケールイン、Addon-managerによるアプリケーションのデプロイ／アップデートがあります。

2019年までは、CaaSではステートレスアプリケーションをメインターゲットとして運用してきました。これは過去、コンテナがステートフルが苦手だったためですね。しかしみなさんご存知のようにWebのサービスは、Webサーバーなどのステートフルなアプリケーションと、データを保持するデータベースのようなステートフルなアプリケーションで構築されています。

ヤフーでもKubernetesを利用し始めた開発者のメンバーからはステートフルなアプリケーションも動かしたいよという要望が日々高まっています。そこでゼットラボではCaaS向けにステートフルサービスを構築し、ステートフルアプリケーションのサポートに挑戦しています。

ゼットラボでは2018年のQ3から検討を始め、まずはゼットラボ社内でサービスを2018年のQ4に展開しています。その後ヤフーでステートフルサービスのパイロットサービスが始まり、もうちょっとでヤフー社内でGAされるというようなスケジュールとなっています。

ステートフルサービスへの挑戦

ではここから、我々が取り組んでいるヤフー／ゼットラボ向けのCaaSにおけるステートフルサービスについて掘り下げて紹介していきます。先ほど紹介したCaaS向けにステートフルサービスを提供するには課題がありました。まず1つ目はWebサービスごとに独立したデータアクセスが必要。これはセキュリティの要件ですね。

次の課題としては、先ほどご紹介したように我々は680以上のKubernetesクラスタがあること。これ、増え続けています。一方でこれを管理してくれるCaaSの管理者は増えないですね。増えない管理者です。

さらにはKubernetesは非常にアップデートも早く、3ヶ月に1回のアップデートがあります。当然我々はこれに追随していかなくちゃいけない。さらにはCaaSの特徴であるNodeのセルフヒーリングやスケーリングへの対応。これもステートフルでしっかりとやっていかなくちゃいけないといった課題があります。

このような課題に対して我々は3つの施策を取ってきました。まずはじめの施策はセキュリティです。ストレージは高価なことが多いので、複数のKubernetesクラスタでストレージを共有することが多いかと思います。

一方でセキュリティの観点としては不要なユーザーからのアクセスを禁止したいのではないでしょうか。例えばこちらのKubernetes1、これを使っているユーザーがKubernetes2の使っているボリュームにアクセスできてしまうとか、Kubernetes2のユーザーがKubernetes1のボリュームにアクセスしてしまう。これは禁止したいわけですね。

そこで、このような複数Kubernetesが存在する環境向けに、我々はストレージのマルチテナント機能を利用し、Kubernetesクラスタごとのアクセスをコントロールしています。上側のKubernetesは、Kubernetesの中のリソースはコントロールできるんですが、さすがに隣のリソースまではコントロールできないので、下側のストレージの共有しているところのこちらでテナントを切ってコントロールしています。

注意するポイントとしては、ストレージのマルチテナント機能。これ実装がマチマチだというところです。テナントでコントロールできるリソースは必ず確認する必要がありました。とくにマルチテナントサポートという言葉だけでKubernetes向けにマッチしたマルチテナントかどうかは不明のため、ストレージを選定する際に、アクセスをコントロールしたいリソースが正しく制御できるかどうかを我々は確認し検証しています。

次の施策としては自動化です。Kubernetesは、3ヶ月に1回マイナーアップデートがあります。さらにはKubernetesのバージョンアップ時にストレージ部分のCSI Driverや関連ソフトなどのアップデートも必要となります。これらの状況の中で680以上のKubernetesクラスタを運用するヤフーでは人手のアップデートはもう無理があって、自動化することが必達となっていました。

そこでまず我々が取り組んだのがAddon-managerによる自動化です。CaaS向けに提供しているAddon-managerを使い、StorageClassやベンター提供のCSI Driver、Persistent Volumeの監視で利用するダッシュボードやアラートルールなどステートフルサービスで必要なものを自動デプロイすることで、セットアップを自動化しています。

さらにはこのAddon-managerではKubernetesのバージョンアップに連動し、StorageClassやCSI Driverなども自動でアップデートしています。

次の施策としては自動化の第2弾です。ヤフー／ゼットラボのCaaSではアップデート時にNode、我々はVMを再作成します。ただしNodeを再作成することでIPやIQNといったものも変更されるようになるため、ストレージ側のNFS、iSCSIのACLの更新が必要になります。

図を用いて説明します。まずCaaSのローリングアップデートでは、新しいNodeを新規作成したのち、KubernetesのクラスタへNodeを追加します。

このとき新しいNodeは新しいIP、新しいIQNとなります。その後、古いNodeの中からこちらをUnscheduledにし、Podを新しいNodeへ移動させます。このとき新しいNodeのIPやIQNがストレージ側のACLに登録されていないと、当然、PodからVolumeに対してアクセスできなくなります。

そこで我々はNodeをウォッチし、ACLを自動更新するカスタムコントローラーを開発しました。こちらのカスタムコントローラーがexport-policy-mgrです。これによりNodeが追加されるとストレージのACLへIPやIQNも自動登録するようにします。

Nodeが削除されるときも同様に、Nodeの削除のイベントを検知しストレージのACLを更新します。このカスタムコントローラーの機能はGitHubで公開されているベンダーのCSIプラグインへリクエストを送り、残念ながら我々のコードそのままではありませんが、ベンダーにより正式にサポートが開始されました。

このようにCaaS向けステートフルサービスを提供するにあたり、セキュリティや自動化にも取り組み、少人数で運用可能なサービスに仕上げています。