Kubernetes as a Serviceの利用者を支える機能

Transcript

サイバーエージェントの青山です。Kubernetes as a Serviceの利用者を支える機能というテーマで発表させていただきます。

まず軽く自己紹介ですが、私はサイバーエージェントという会社で、今日紹介するKubernetes as a Service、いわゆるマネージドのKubernetesを提供するようなサービスのプロダクトオーナーを務めております。他にもクラウドネイティブやKubernetes関連のコミュニティや、いくつか他社さんのKubernetes関連のお仕事もさせていただいたりして、Kubernetesとかクラウドネイティブ関連の情報やユースケースを知ったりしています。

AKEのお話の前に、まずサイバーエージェントのプライベートクラウドと弊社の開発チームのお話を少しさせていただきます。

実はサイバーエージェントにはもともと事業領域ごとに2つのプライベートクラウドが存在していました。1つがAIとか広告事業側のプライベートクラウド、もう1つがメディアとかゲーム事業側のプライベートクラウドです。両方ともオープンスタックベースですが、これが2年前ぐらいに合併してCIUという共通の組織に移り変わりました。もともと私はAI側のプライベートクラウドの共通組織にいました。

その中で私たちのサイバーエージェントグループのインフラストラクチャーユニット、通称CIUができて、その中に我々の共通基盤を開発するチームが生まれました。私たちのチームは開発チームで、約10名ぐらいで開発をしています。この10名でマネージドのKubernetesサービスと、MLのプラットフォーム両方を開発しているので、明らかに人が足りないと私は思っています。

こういった人数構成で2つの新次世代基盤を開発していかないといけないので、少人数で効率的に運用するためにソフトウェアによる自立化をどんどん推進しながら開発を進めています。なので、先ほどのjacopenさんのお話にもありましたが、プラットフォームを作って自立化を進めているような形です。

運用することを考えていくと、作って手動で更新していくとか、手動で何かをやっていくというものが多いと、到底少人数では回せなくなってしまうので、自動化・自立化をしっかりと進めながらプラットフォームを作っています。

今日お話しするのは、この開発チームで作っているKubernetes as a Service、マネージドのKubernetesをユーザーに提供して、そこで社内のプラットフォームを作っていくというのが、ユーザーにKubernetesを使いながら開発をしてもらうという基盤について紹介していきたいと思います。

我々のKubernetes as a Serviceは、大体6年前ぐらいの2017年4月ごろにリリースをしています。そこからさまざまな機能追加や大幅なリプレイスなんかを行いながら、今もなおAKEは稼働しています。

ちょっと技術的な話になってしまって恐縮ですが、大幅なリプレイスを何のためにやったのかというと、2021年4月ごろに実施したんですけれども、クラスターを管理するための仕組みが昔はOpenStack Heatというものを使っていたんですが、やはり自動化がしづらい、Kubernetesの世界から取り扱いにくい、OpenStackのAPIで管理しづらい、自動化できる範囲が限られてしまうという問題にぶち当たりました。

このまま元のKubernetesを使っていくというのが限界に達してきて、もっと拡張していくことを考えると、一旦ここで大規模なリプレイスをしようかというところで舵を切って、今後も使っていける、今後も拡張していけるプロダクトにするために、我々はクラスターAPIという仕組みに切り替えました。

クラスターAPIについての詳細は細かくは紹介しませんが、Kubernetesクラスター自体を管理クラスターで管理できるような仕組みになっています。なので我々のシステムから、この管理クラスター上に左にあるようなクラスターというリソースを、マニフェストを書いて適用してあげると、うまいこと自動的にKubernetesクラスターを作ってくれるような仕組みになっています。

これはただ単にクラスターを作ってくれるだけに見えると思うんですけれども、なんでクラスターAPIにしたかというと、Kubernetesのリソースとしてクラスターが表現されるということは、Kubernetesのコントローラーという自立的なクラスターを作ってくれるという意味で、自立化自動化の仕組みがあるので、それに伴ってさまざまな自動化を進めていくことができます。

例えばクラスターが作られたときに、アドオン管理の仕組みと自動的に連携させたりとか、あとは各マシンの状態もKubernetesのリソースとして登録されているので、マシンがこういう状態になったらこういうことをさせましょうとか、そういったさまざまな自動化というのを、すべてKubernetesの世界に持ち込むと、ソフトウェアで管理することができるようになってきます。

ここら辺は基本的な機能になってくるんですけど、我々のクラスターの管理のところでは、クラスターのアップグレードとか、クラスターのライフサイクル管理とか、あとは特定の状況下でクラスターに操作をさせないようにするようなライフサイクル管理とか、そういったことも行っていますし、あとは当然オートスケールなんかも実装しています。

このオートスケールのときにも、プライベートクラウドだとあるあるだと思うんですけれども、在庫が足りないゾーンがあるとか、裏側のハイパーバイザーを考慮すると、アフィニティをかけられないので、そういったのを考慮して配置したいとか、そういったロジックもすべてソフトウェアで制御するようにしています。

そういった制御がなかった頃は、プライベートクラウド側にAPIリクエストが飛んで、VMを作ろうとするんですけど、裏側の在庫がないので、頑張ってスケジューリングし直すとか、ごめんなさい、ここのゾーンがないと、このゾーンはもう無理なんで、こっちのノードプールを増やしてくださいみたいな有人対応が結構あったんですけれども、そういったところもなくして、少人数で回していけるような体制にしていっています。

あとは細かい紹介は置いておくんですけど、ノードの自動復旧みたいな仕組みとかも用意しています。

ここら辺はどんなKubernetesサービスでも存在すると思うんですけれども、我々はもう一歩踏み込んで、Kubernetes上に乗っかるようなシステムっていうのも、我々の方でマネージして管理しています。

どんなことをしているかっていうと、ユーザーにKubernetesを提供すると、大体のケースでいろんなシステムをKubernetes上に乗せます。OSSをKubernetesに追加して、よし最高のシステムができたというケースが多いと思うんですけど、実際その上に乗せたOSSとかっていうのは、管理し続けることって結構難しいケースが多く、運用負荷が上がって結局塩漬けになりがちだったりします。

そうしたところをAKEの方では全て吸収するようにしています。どんなことをしているかというと、ユーザー向けにユーザーのクラスター上に何かしらのOSSを導入したいというときは、アドオンの仕組みを提供しているので、そこから入れてもらうことができます。

あとは、何かしらのOSSを導入したいというときは、提供の方法としては、ユーザーのクラスターにアドオンを追加する以外にも、我々の方で管理している管理したアプリケーションを、ユーザー側に提供するというような仕組みも持っていたりします。

こうした各ユーザーのKubernetesクラスターに提供するOSSなんですけど、当然バージョン管理とかを行っていかなきゃいけないので、これも我々の方でKubernetesバージョンに対応するOSSのセットみたいなものを、我々の方で管理しています。それぞれのバージョンで動いている各アプリケーションというのは、動作確認を我々の方で自動的に行うようにしているので、それが通ったものというのをユーザーは使っていけるようになっています。

なのでユーザーがやらなきゃいけないことというのは、特定のアプリケーションとかを上げていきたいなというときに、AKEバージョンというのが内部的には切られていて、実質的にはGitHubのタグなんですけど、そのタグを更新していくことによって、ユーザーは自分たちが使っているアプリケーションをどんどん上げていくことができるようになっています。

なのでこうしたところを我々の方で持つことによって、Kubernetes運用が大変、更新していくのが大変、追従していくのが大変というよく声を受けて選定を悩むケースもあると思うんですけれども、こういったところは我々のDevチームがプラットフォームとして提供しているので、全部吸収して提供するような形で行っています。

当然これを我々が管理するのも大変なので、基本的には我々の方にこのアップデートの追従というのは全部自動化していて、例えばPrometheusの更新とかArgoCDの更新とかっていうのは、GitHubに自動的にプルリクが上がってくるようになっていて、変更点というのもプルリクで確認できるようになっています。これをマージして我々はテストをすればいいというような形の仕組みまで自動化しています。

ここまでがKubernetesを提供して、そのKubernetes上で動くOSS類も我々が管理しましょう、いろんなところで聞いたこともあるような話かなと思います。

ここからはサイバーエージェントとAKEがどういう世界観を目指してプロダクトを開発しているかについて少し紹介したいと思います。

サイバーエージェントにおけるKubernetesとかマネージドKubernetesサービスを取り巻く現状なんですけれども、まずサイバーエージェントには約100ぐらいのプロダクトであるとかプロジェクト、子会社、事業が存在しています。我々の開発チームがターゲットとしているのは、こうした各プロジェクトのユーザーさんになっています。

こうしたユーザーさんは、GKEを使ってもいいし、EKSを使ってもいいし、我々が作っているAKEを使ってもいいですし、すべて技術選定は自由になっています。なのでAKEチームは何と戦わないといけないかというと、パブリッククラウドと戦って利用を決めていただく必要があります。

なので我々はパブリッククラウドと比較しても利用される、必要とされるプラットフォームというのを目指していかなきゃいけないと。ここにはよく言われるようなコストというのももちろんありますし、コストだけだと結果的に開発効率が下がるんだったらコストトントンだよねという話にもなりやすいので、利便性であるとか、あとは運用が容易であるか、先ほど言ったようなさまざまな自動化の機能とかで容易かどうか、あとは手厚いサポートが受けられるかどうか、そういったところで我々は勝負しています。

あとは、先ほどもちょっとお伝えしましたけれども、ただKubernetesを提供するだけだと、各利用者というのはKubernetesだけが払い出されても、さまざまなKubernetes上のOSSとかさまざまな仕組みというのを、各プロダクトが手間をかけて用意する必要が出てきます。

これが仮に100プロジェクト全てで個別で行われたとすると、かなり無駄が多い、車輪の再発明が多いですし、ベストプラクティスが当然他のチームに伝播しない。ここでは吸収できたところを、それを知らないで他のチームはそのまま使ってしまうとか、あとは当然各チームがキャッチアップしていくと、膨大なキャッチアップが必要と。

そういったところを解決するために、我々はユーザーが遭遇した問題の対応とか、要望がある機能というのを共通化してプラットフォームできるようになると、プラットフォーム側で提供するような仕組みを作っていっています。

なんでこんなことをやっているかというと、クラウドネイティブって、サービスのアプリケーションを進化させ続けましょう、実装してユーザーに早く提供し続けましょうというところに注目されがちだと思うんですけれども、Kubernetesとかプラットフォーム側は、一度作ったらそのままになっているケースというのが結構多いなと私自身は感じていて、ここはKubernetesプラットフォーム側も、使い古されさせずに進化させ続けるべきだと思っています。

なのでAKEがどんな世界観を目指しているかというと、Kubernetesとかクラウドネイティブは運用が大変というような課題に対しては、CICDで従来では自前で作らなきゃいけなかった機能とか、あとエキスパートのエンジニアとかコンサルみたいな人が改善提案するような内容というのも、プラットフォーム側で提供されています。提供しましょうというところであったり、あとキャッチアップが大変というところに関しては、当然Kubernetesとかクラウドネイティブに関するベストプラクティスってさまざま広がっていると思うんですけれども、そういったプラクティスを是正するような仕組みであるとか、エコシステムというものをプラットフォーム側で提供するということを目指しています。

例えば運用が大変なので改善する提案を提供しましょうというところで、最近作っているものとしては、これはKubernetesを運用したことある人には刺さると思うんですけれども、Kubernetesってコンテナに割り当てるリソースとかリクエストって、なんとなく手作業で設定したり、それをアジャストする機会ってあんまりないと思うんですね。最初に設定したらそのままだったりすることが多いので、そういったところを我々の方で自動的に検知して通知するような仕組みっていうのを作っています。

これがない場合って、各開発チームのSRE担当の人とかが、どこかで時間を取って、半年に1回とか3ヶ月に1回時間を取って1個1個ちまちま直すとか、そういったことをしなきゃいけないと思うんですけれども、そういったところをAKEでは手間なく直せたりするような機能を提供しています。

あと権限に関しても同様ですね。本当にこの権限でいいのかっていうのは、監査ログとRBACの関連のリソースを見てあげれば、不要な権限を算出したり、あとは足りていない機能を算出することができるので、そういった情報をもとに自動的に通知して、ユーザーはその情報をもとに自分たちで直せるっていうような仕組みを整えています。

あと3つ目がKubernetesのバージョンアップに関連するところですけれども、KubernetesのAPI、Kubernetesのリソースっていうのは非推奨なものっていうのがどんどん出てきて、更新を余儀なくされていくんですね。そういったものを手動で一個一個直したり、またはCIのツールを組み込んで直すみたいなケースが多かったりすると思うんですけれども、そういったところもKubernetesのAPIなんかを使って自動的に検知して直すような提案っていうのを出せるようにしています。

こうした非推奨のAPIとかポリシーとかっていうのは、今回Kubernetesのリソースに限ったところをお話したんですけれども、実はサイバーエージェント横断で今ゲートキーパーのポリシーっていうのを作っています。もう大体できてるんですね、63個ぐらいポリシーがあるんですけれども。

これは何をしているかというと、Kubernetesの非推奨になったAPIを検知するのはもちろんですし、Kubernetesを使っていく上での必要なベストプラクティスとか制約とか、これはやらないほうがいいというようなことをしています。それを1個1個ユーザーが確認していくのっていうのは、結構現実的ではないんですね。

なのでサイバーエージェント横断としてポリシーを策定して、それをユーザーに使ってもらえるような形で提供しています。ちなみにこれはDev Teamの戦略でもあるんですけれども、オンプレミスのKubernetesでしか使えない機能っていうのは、オンプレミスが将来的にどうなっていくのかというのは分からないので、我々の開発チームとしては、サイバーエージェントで使われているすべてのKubernetes環境で使えるように、ユーザーに向けて提供している機能っていうのは、すべてのKubernetesのユーザーに展開できるような形で作っていっています。

これによって我々のチームが開発しているプロダクトというか、これの場合はサブプロダクトになると思うんですけど、そうしたサブプロダクトはすべての組織で使ってもらって価値を提供するということを目指しています。

ちょっとここら辺は飛ばします。

あとはベストプラクティス、先ほどのゲートキーパーもそうなんですけど、ベストプラクティスであるとかエコシステムを提供するっていうところで言うと、例えばオブザーバビリティ周りの環境であるとかだと、Kubernetesを提供するというところで言うと、デプロイした後にPrometheusを入れてとか、Datadogを入れてログのエージェントを入れて、一個一個設定していったり、それぞれをアップデートしていくのっていうのは、結構それも運用の手間がかかってしまうので、ここもすべてAKEチームで持っています。

あとはただ単にログを収集したり、メトリクスを収集するだけではなくて、実際にKubernetesを運用する上で必要なダッシュボードであるとか、一般的なアラートルールっていうのもAKEチームで提供しています。Kubernetesを使い始めたユーザーっていうのは、どういったメトリクスを見ないといけないかとか、運用しているとどういう問題に遭遇して、その時にどういうメトリクスが必要になるかっていうのは、知らないケースがほとんどなんですね。知ってるのは多分1%とか2%ぐらいだと思います。

なのでそうしたところもAKEチームの運用ノウハウっていうのがあるので、すべて提供していく。で別のケースもあるんですけれども、別のチームで遭遇した問題っていうのを、他のユーザーさんには起きてほしくないので、そういったところもAKEチームが間に入って横展開していくことによって、すべてのユーザーに利便性を提供していくっていうような動き方をしています。

最後にその他のOSSの利用とか提供っていうところで言うと、ユーザーさんにとっては様々な課題がどんどん出てきます。例えばベストプラクティスでSBOMを組織上管理しておく方がいいよねっていう話とかっていうのは、ここ1,2年ぐらいですかね、出てきたと思うんですけれども、そういったときにキャッチアップして自分たちでその仕組みを作るっていうのは、結構やっぱり骨が折れるので、こういったところはAKEが市場の動向であるとか、弊社のサイバーエージェントでもその機能が必要なのかっていうのを吟味した上で、必要と判断した場合にはAKE側で提供できるような仕組みっていうのがあるので、提供できるような仕組みっていうのを整えていったりします。

このときに我々開発チームは結構そのキャッチアップも市場の動向とかも見てるエンジニアが多いので、そういったシステムの状況とかごめんなさい市場の動向とかを見ながら、適切な技術選定をして提供していくということをやっています。

あとは最近だとCNIっていうネットワークのプラグインっていうのも、新しいバージョンに切り替えることによって、我々のアドテク領域なんかでは結構レイテンシーがシビアだったり、クライアントIPが保持しなきゃいけなかったりするので、そういったところを見据えて整備なんかを行っていったりしています。

最後にまとめなんですけれども、弊社は、弊チームは6年ぐらいにわたってマネージドのKubernetesサービスっていうのを提供してきました。我々はその少人数で開発をしていかなきゃいけないので、その中での自立化っていうのを進めていって、少人数でも運用し続けられるような組織っていうのを構築してきました。

我々が作るKubernetesプラットフォームっていうのは、長年の運用経験っていうのがあるので、そうした経験とあとはユーザーがこういうところは負担に感じるっていう部分を全て把握しているので、そういったものを低減するような実装をし続けて、進化し続けるベストプラクティスであるとか、プラットフォームっていうものを弊チームは提供し続けています。

はい、ということでご清聴ありがとうございました。