Kubernetesエキスパートが注目する「Platform Engineering」とは何か？一体何が新しいのか？

クラウドネイティブ時代の新しいプラットフォームのあり方とは

2023/07/14 12:00

　近年、多くの企業が取り組もうとしている「クラウドネイティブ」なインフラ構築やアプリ開発の領域では、コンテナやKubernetes、アジャイルやDevOpsなど、新しいテクノロジーやコンセプトが次々と登場し、進化を続けています。組織がそうした進化に追従しながら、継続的に「クラウドネイティブ」のメリットを得られるようにするための考え方として、今「Platform Engineering」が注目されています。今回は、ヤフーとサイバーエージェントでKubernetesのエキスパートとして、社内のプライベートクラウド整備に尽力する2人に、Platform Engineeringの考え方や、それに基づいて、実際に自社のプラットフォームをどう進化させているか、今後どうしていきたいかといった展望を伺いました。

Kubernetes領域で共通点の多い2人

──お2人はクラウドネイティブやKubernetesの領域に関して、どのような取り組みをしていますか。

早川博氏（以下、早川）：ヤフーの早川です。現在取り組んでいることは、主に「プライベートクラウド」の構築と運用ですね。ヤフー社内の、アプリケーションとサービスの開発者向けにプラットフォームを開発しており、その中でも主にWebアプリケーションのデプロイや運用を容易にするための仕組みを提供しています。

　コミュニティ活動としては、「Cloud Native Developers JP」のオーガナイザーをしていたり、『Kubernetes実践ガイド』（インプレス刊）という書籍を執筆したりもしています。そういえば、書籍執筆の際は、青山さんにレビュワーをお願いしました。ありがとうございました。

青山真也氏（以下、青山）：こちらこそありがとうございました。サイバーエージェントの青山です。改めて、よろしくお願いします。現在、部署としては「CIU（CyberAgent group Infrastructure Unit）」というインフラ部隊に所属しています。

　部署の成り立ちをお話ししておくと、元々サイバーエージェントには、広告系AIの部署とメディア系の部署で、それぞれプライベートクラウドを運用するチームがあり、両者が合併してCIU生まれました。今は、CIUがサイバーエージェント全体のプライベートクラウドを統括するチームとなっています。

　CIUのプロダクトはいくつかあるのですが、私がメインで担当しているのは、KaaS（Kubernetes as a Service）としてKubernetesを払い出す仕組みを作っているチームで、そこでプロダクトオーナー兼ソフトウェアエンジニアをしています。そこでは、実際にどういうKubernetes環境を作っていくかや、どう払い出すかだけではなくて、Kubernetesを払い出した後に、それをより便利にするための周辺のシステムや、運用を楽にするような機能もいくつか作っています。Kubernetesを使うユーザーにとって何が必要かを考え、作りあげていく仕事ですね。

　また、サイバーエージェントには「Developer Experts」という制度があり、そのKubernetes領域を担当しています。社内のさまざまなプロダクトに対して、Kubernetesやクラウドネイティブの技術スタックを適用する際の技術支援やレビューなどを行うほか、各プロダクトで共通して同じようなことをやっていたりする場合に、それらを共通化していくような横断プロジェクトの推進をしています。

早川：私も社内の認定制度である「黒帯」（クラウドスタック領域）としての活動もしていますね。役割としては、サイバーエージェントのDeveloper Expertsと似ています。特定技術分野のエキスパートとして、社内で関連する技術の相談に乗ったり、社内向けのプラットフォームを作ったり、自分の技術分野についての情報発信を行ったり、社外対応をしたりしています。

早川博（はやかわ・ひろし）氏

　ヤフー株式会社テクノロジーグループシステム統括本部クラウドプラットフォーム本部所属。「クラウドスタック」領域の第12代黒帯を務める。ヤフーのプライベートクラウド開発部門にて、Kubernetesベースのコンピューティングプラットフォームの開発・運用に従事。業務の傍ら、技術コミュニティの運営や、書籍執筆等を通じてクラウドネイティブ技術の普及促進に取り組んでいる。技術コミュニティ「Cloud Native Developers JP」オーガナイザー。書籍『Kubernetes実践ガイドクラウドネイティブアプリケーションを支える技術』（インプレス刊）共著者。

青山：早川さんとのつながりを振り返ると、私が早川さんにコンタクトを取ったのが最初でした。早川さんが「Cloud Native Developers JP」を、私は「Cloud Native Meetup」というコミュニティを同時期に立ち上げようとしていて、バッティングした感じにならないように直接ご連絡をしたのが最初です。その後、カンファレンスの「CloudNative Days」の運営を一緒にやったり、お互いのイベントに互いに登壇し合ったりするうちに、仲良くなりました。

早川：コミュニティ関係の繋がりが多いですね。あと、書籍執筆の際は、互いにレビュワーをお願いしたりしています。

青山：会社での仕事内容も似ていますし、互いにイベントをオーガナイズしていたり、著書の名前も『Kubernetes実践ガイド』と『Kubernetes完全ガイド』で似ていたりと、共通点は多いですね。

「Platform Engineering」は何が新しいのか？

──早川さんは、Developers Summit 2023での講演で「Platform Engineering」に触れていましたね。ご自身が取り組んでおられるクラウドネイティブの領域と「Platform Engineering」に、強い関連性を感じているのだと思いました。まず「Platform Engineering」というのは、どういう概念なのかについて教えてください。

・参考：Kubernetesで高い開発者体験を作るには？ヤフーの開発環境の構築方法に学ぶ

早川：「プラットフォーム」という考え方自体は、特段新しいものではないですよね。エンジニアの生産性を上げるために、何らかの基盤（プラットフォーム）を作るということは、以前から行われています。

　最近出てきた「Platform Engineering」が、これまでのものと違うと感じる点は、単純にプラットフォーム化で「生産性を上げよう」とか「共通化しよう」という話だけではなくなってきているところです。

　クラウドネイティブの文脈の中で、DevOpsやマイクロサービスなど、新しいパラダイムが次々と登場しています。ただ、多くの概念が登場し、進化していく中で、それを実践するアプリケーションエンジニアの負荷が高くなってしまう状況も生まれています。そうした背景から、クラウドネイティブ時代の「プラットフォーム」がどういうものであるべきかを、改めて考えてみようという流れが出てきていると感じています。

　昨今の「Platform Engineering」と、従来行われてきた「共通基盤づくり」との違いは、ここ数年で積み上げられてきたパラダイムを受けて、それをより簡単に実践できるようにしたいといったモチベーションが根本にあると思います。ただ、ベースの基盤を作り、共通化して効率化するところだけを見てしまうと、これまでと大きく変わらないかもしれません。

青山：昨今のクラウドネイティブ技術によってさまざまなことが簡単にできるようになりましたが、だからといってどんどん導入していくと、認知負荷が高まって運用やキャッチアップが大変になります。そのあたりを、専門性を持ったチームが、「Platform Engineering」することで共通化したり、パフォーマンスチューニングしたり、信頼性高く運用していけるようにできる環境を作るイメージでしょうか。

　あと、クラウドネイティブとPlatform Engineeringの関係性という点で言えば、Cloud Native Computing Foundation（CNCF）にはApp Deliveryに関するTAG（Technical Advisory Group）というものがあるのですが、そこが「Platforms White Paper」を公開しています。

　CNCFがPlatform Engineeringについてまとめたことの意義を考えれば、クラウドネイティブな技術を扱っていくうえでは、当面「Platform Engineering」が重要になっていくのかなと見ています。

早川：プラットフォームを専門チームによって手厚く運用し、それを使うユーザーをきちんとサポートしていくのが、「Platform Engineering」で強調されているポイントのひとつですね。

　イメージとしては、GCPやAWSのようなパブリッククラウド企業が、自社のユーザーに対して広く周辺環境を含むプラットフォームを提供しているようなことを、自社のプライベートクラウドで行う感じでしょうか。従来だと、自社向けには「共通的な基盤を作りました」で終わってしまうことがあるかと思いますが、それに加えて、継続的なメンテナンスや、使ってもらうための工夫、エンジニアたちのサポートについても取り組んで行くというムーブメントだと感じますね。

青山：今の説明には、私も納得感がありますね。サイバーエージェントでもプライベートクラウドを提供しているのですが、GCPやAWSも同時に使っているので、パブリッククラウドが自社のプライベートクラウドの実質的な競合になるケースもあります。パブリッククラウドという選択肢がありながら、より自社組織にとって良いと思われるもの、選ばれるものを作っていくという点で、われわれの目指しているのは「Platform Engineering」だなと思うことがあります。

早川：GCPやAWSを競合と意識して、自社のプラットフォームの強みを出すというのは、具体的にどういうことでしょうか。

青山：当然ですが、パブリッククラウドの持っている汎用的な機能をすべて取りそろえて、かつそれぞれの機能で勝つことは到底不可能です。強みの出し方には大きく2つ軸があって、一つはコスト優位性。もう一つは、会社特有のニーズや技術レベル、組織文化といったところにフィットすることですね。全世界を相手にするプラットフォームに対して汎用性では負けますが、「自社への最適化」という観点で一番良いものを作ることに注力して優位性を確保する感じです。

早川：かなりチャレンジングですね。「自社への最適化」に関連して、そうした「自社で求められていること」を、どうやって見つけ出しているのか気になります。

青山：例えば、会社によってセキュリティをどこまで担保すべきかといった要件は違いますよね。あと、Kubernetes経験が豊富なメンバーが多いかや、目指すアプリのリリース頻度などの特性からも「どれぐらい運用しやすい方がいいか」というのが変わってきます。

　「コスト」についても、それぞれの会社や部署でどれだけきちんと見たいのかは違います。「パフォーマンスはお金で解決する」というスタンスの会社もありますから、そうした事情を汲みながら、どこをどの程度最適化したいかを聞き、それに合わせた機能開発をしている感じですね。

　他にも「ポリシー」の観点もありますね。うちのグループだと、どういう要件をどの程度担保するか、どういう標準設定にしておくかといったことを、事業部の有識者を集めて、標準化していく取り組みもしています。そういう観点でも自社に「合わせていく」取り組みが多いですね。ヤフーの場合はいかがですか？

早川：ヤフーは歴史的な経緯もあって、サイバーエージェントのように「プライベートクラウドとパブリッククラウドが競合する」ケースは多くないです。とはいえ、やっぱりエンジニアはGCPやAWSを気にしていて、機能を比較されることはありますね。

　その中でどう価値を出すかについて、もともとヤフーのプラットフォーム上には多様なプロダクトが動いています。それら多様なプロダクトと自分たちが作っているPaaSがいかにシームレスにつながるか、そのあたりがエンジニアにとって「役に立つ」ための基本的なラインになります。

　実際にプロダクトを作る上では、初期の段階で、ユーザーとなるアプリケーション開発者にインタビューして、ニーズを聞き出し、機能として提案しています。そのほかにも、ユーザーストーリーマッピングという手法を使い、われわれのプラットフォーム上でアプリケーションを開発するエンジニアが、どうやって開発し、ビルドし、デプロイして運用監視するかという一連の流れをストーリー化して、どのような機能を提供するのがよいのかを検討したりしています。

青山：私たちのチームが特に意識しているのは、Kubernetesの運用に必要なさまざまな機能や仕組みを我々が作り、アプリ開発者のために共通化するということです。

　Kubernetesを使っていく上で、そういった専門組織がなければ基本的にはアプリ開発者が周辺も含めてすべて自分で面倒を見なければならなくなり、どんどん負荷が上がっていきます。そこを専門性の高いチームが引き取って、アプリ開発者に向けて「Webアプリケーションをコンテナに乗せることだけを考えてください」と言える部分が一番大事ですね。

　あとは、運用していく際にハマりがちなポイントを把握しておき、その解決にあたって見ていく必要のあるメトリックスをダッシュボード化することもしています。Kubernetesの専門組織として6年以上の実績があるので、その中で蓄積したノウハウをベストプラクティスとしてまとめておいて、ユーザーは必要なタイミングで必要な情報を何げなく入手して使えるような環境作りと言えます。こういうノウハウは、いわゆる「Platform Engineering」の専門チームがないと、なかなか集約されたり、横展開されたりしていかないので、もったいないですね。

青山真也（あおやま・まさや）氏

　株式会社サイバーエージェントソフトウェアエンジニア。2016年に新卒入社し、アドテク本部に配属。入社後、配属先ではOpenStackを使ったプライベートクラウドやGKE互換なコンテナプラットフォームの構築にゼロから携わる。Kubernetesへの思いが強く、認定資格「Certified Kubernetes Application Developer」を、世界で2番目に取得。国内外の技術カンファレンスにおける登壇経験も多い。著書に『Kubernetes完全ガイド』（インプレス刊）、『みんなのDocker/Kubernetes』『Kubernetesの知識地図』（共著、技術評論社刊）がある。現在はOSSへのコントリビュート活動をはじめ、「CloudNative Days Tokyo」の共同議長、CNCF（Cloud Native Computing Foundation）公式の「Cloud Native Meetup Tokyo」や「Kubernetes Meetup Tokyo」のオーガナイザーなど、コミュニティ活動に従事。

早川：あるプロダクトでハマった個所について、他のプロダクトでハマらないようにする仕組み作りはヤフーでも取り組んでいますね。自分のチームのプロダクトの場合はKubernetesを払い出した上で、さらにもう1レイヤ乗せる構成になっているので、その部分で、アプリケーションを動かすための基本的な設定や簡単なチューニングをあらかじめしておく感じです。

「開発者のニーズに合ったプラットフォームづくり」の難しさとは

──両社のKubernetes基盤の概要を教えていただけますか。それぞれどのような構成で、どんな機能を提供しているのでしょう。

早川：これはDevelopers Summitの講演で使ったスライドなのですが、自分が担当している領域で、特にKubernetesが絡んでくる部分を図にするとこのような感じになります。

・参考：早川さんの発表資料「Kubernetesとカスタムコントローラーを活用したプラットフォーム開発・運用の勘所」

　これは簡単に言うと、「ものすごく大規模なアプリケーションをKubernetesで動かす」ことをしようとしています。

　Kubernetesのスケーラビリティは基本的に高いのですが、それでも限界があり、公式ドキュメントでもその限界がある程度示されています。ヤフーの場合はその限界を超える規模のサービスがあるので、運用するための特別な仕組みを考える必要がありました。

　まず、Kubernetesを何台も使います。1つのクラスタに他のクラスタを束ねる代表の役割を持たせ、その中にカスタムコントローラーコンポーネントをデプロイします。アプリケーションのデプロイの指示をこの代表クラスタにすると、束ねられている側のKubernetesクラスタの中から、いろいろな条件を考慮してクラスタを選び、動かしたいアプリケーションをそこにデプロイするという構成になっています。

　これ、アプリケーション開発者側からは、1つのクラスタを操作しているように見えるのですが、実際には、その背後で大量のクラスタが動いています。この仕組みを使って、大規模アプリケーションを含む、複数のプロダクトを全部1つのカスタムコントローラーでホストするような仕組みを作っています。

　アプリをデプロイするところは、本来「どのクラスタにデプロイするか」を細かく指定したり、データにアクセスするためのURLを洗い出したりとか、そういう面倒なことをやる必要があるのですが、それらを省略した形で簡潔に書けるようなYAMLファイルを、このプラットフォーム専用のフォーマットで用意しておき、アプリ開発者側ではあまり細かい設定を意識せず、アプリを動かせる仕組みにしています。

青山：私たちの場合は、先ほども少し話したようにKubernetesを払い出す仕組みや、使っていく上で必要な周辺システムを作り込んで提供しているのですが、早川さんのところでは、払い出したものを、もう一回束ねて抽象化するような仕組みを用意しているのですね。

　お話を聞いていて気になったのですが、この仕組みでは、メタクラスタ（束ねられる側のクラスタ）に普通のリソースを、この仕組みによる抽象化を行わずに立ち上げることはできるのですか。

早川：アプリ開発者視点では、ほとんどできません。コンセプトとしては「Kubernetesを使う」という意味での自由度は下げて、簡単に大規模なアプリをKubernetes上で動かし、運用できるようにすることに特化しています。

青山：なるほど。最近、よく議論される「KubernetesとCloud Runのどちらを使うべきか」といった話題とも共通する部分がありますね。

早川：そうなんです。ユーザーであるアプリ開発者に対して、どのくらいKubernetesを隠すか、どのくらい自由にKubernetesを使うことを許すかというのは、結構悩みどころです。ある程度Kubernetesそのものに慣れている人からすると「この基盤では、こういうことできないんですか？ Kubernetesだったらできるはずなんですけど」と思われてしまいがちです。逆に、さらに抽象化レベルが高いベンダー製のPaaSパッケージに慣れている人にとっては、今の状態でも設定すべき項目が多すぎると感じられたりします。

　いろんなエンジニアがいる中で、プラットフォームとしてどこに合わせていくのかについては、チームの中でも色んな意見があります。Kubernetesのプラットフォームができて数年経っているのですが、この先、さらに社内での定着度を上げていくことを考えても、どのような方向性でいくのかを改めて考えるべき時期に入ったのかなと感じています。

青山：たしかに、プラットフォームとして抽象化のレベルをどうすべきかには、いろんな要素が影響します。チームの成熟度だったり、事業のフェーズだったり。ソフトウェアシステム側の複雑さに応じて決めるケースもあるでしょう。導入ケースが増えて、このあたりの要素が複雑に入り組んでくると、個別に対応してほしいというニーズも当然出てきますが、そればかりやっているとプラットフォーム自体が複雑になりすぎて、エンジニアとしては「これって、われわれが目指しているものだったっけ？」みたいな気持ちも出てきがちになります。

　サイバーエージェントでも、Kubernetesより抽象度を上げた「Cloud Runのような仕組み」を作っていこうという話はあるのですが、こうした課題や議論は避けられないのだろうと思います。

　抽象化レベルの高い仕組みがあった場合のメリットというのは、Kubernetesの世界に入っていくユーザーを拾いやすいというのがあると思います。あと、素のKubernetesの場合には、ユーザーのオンボーディングなどを含め、導入サポートのコストが結構掛かるので、そこ減らせることもあるでしょう。

　結局のところ、抽象化レベルの高い仕組みを新しく作るかどうかは、やった時に実装コストやサポートコストをどれぐらい下げられるかという話と、それぞれの企業の技術力や事業フェーズに応じて、そうした仕組みが有用だと判断されるかどうかという点の組み合わせになるので、そこが難しいところではありますね。

企業が「Platform Engineering」を推進するべき理由

──「Platform Engineering」のコンセプトに沿ったクラウドネイティブなIT環境を推進していくには、組織や組織に属するエンジニアはどんなことができると思いますか。

早川：例えば、問題になっているのが、それこそ「変化が早くてキャッチアップが大変！」「アプリケーションエンジニアが運用まで手が回らない！」というようなことであれば、むしろ「Platform Engineering」によって、それを解決できるのではないかと思います。そうしたキャッチアップや運用の手間を、専門チームが手がけるプラットフォーム側で、自動化などを駆使して吸収してしまうことができます。

　あと、これまでPlatform Engineeringについて、コンテナやKubernetesの文脈で話していますが、別に「プラットフォーム上でコンテナやKubernetesを使うこと」自体がPlatform Engineeringというわけではありません。まずは、自社の状況を見直してみて、元々あるツールやインフラ、システムをうまく組み合わせ、どうすればプラットフォームを効率化できるかを考えて実践していくことも「Platform Engineering」のコンセプトを生かすことにはなるだろうと思います。

青山：Platform Engineeringについて、「技術やパラダイムの変化が速すぎるので実践が難しい」ということはないと思います。それをやるチームが、Kubernetesも、サービスメッシュもと、何でもやろうとすれば大変なのは間違いないですが、例えば、別に「Kubernetesの払い出しとダッシュボードだけ」をプラットフォームとして提供したとしても、それには価値があると思います。結局、各アプリ開発者やチームが、別々にやっている同じことをまとめられれば、会社全体としてのトータルコストは下がりますよね。プラットフォームエンジニアがやるべき範囲を決め、それに注力する形で進めていけば、その会社に適したプラットフォームができてくるのではないかと思います。

　それができた上で「実施コストの方が高い」ようだと、恐らくPlatform Engineeringで効果が出る規模に達していない可能性が高いです。ホワイトペーパーにも書かれているのですが、Platform Engineeringは、ある程度の規模がある会社が、インフラ運用の共通化を行って効率を上げるとか、開発者により良い環境を素早く提供するという考え方なので、2個のサービスで共通化するよりも、10個のサービスでやったほうが効果は大きいです。つまり、規模が大きい会社ほど実践から得られるメリットは多くなります。

　大きい会社ほど、組織の縦割りで面倒なケースなども多いとは思うのですが、現在の課題を現場同士で話し合う機会を作ったりすると、「Platform Engineering」へ取り組むことについて、意外と前向きな答えが出てくるのではないかと思います。

早川：所属する組織が違っていたとしても、現場レベルだと、隣の部の苦労話を聞いて共感できるケースは多いですよね。「Platform Engineering」的なことを全部やる必要はないので、まずは「自分だけでやるのはイヤだけど、みんなにとって便利でやりたいことを共通化するために、一緒に仕組みを作っていこう」という意識を持つといいと思います。

青山：あと、隣の部署がやっていることは分かるけど、さらにその隣でやっていることはわからないような状況は、大きな組織であればよくあります。そうした状況を改善するためにも、全体を俯瞰できる立場にある人が「Platform Engineering」を推進してみるというのも効果的かもしれないですね。

エンジニアとして「楽しい」と思えることに取り組み続けたい

──最後に、KubernetesやPlatform Engineeringについて、今後の展望やチャレンジしていきたいことについて聞かせてください。

早川：自分はプラットフォームに関わる中で、サービス開発に関わる人は、プラットフォームに関してより上位の「これがやりたい」という思いを持っていることが分かりました。その思いに応えるためにも、部門で提供している、さまざまなプラットフォームを俯瞰して、それらをどう組み合わせたらどういうことができるかが見えてくるといいなと思っています。まずは自分が担当しているプラットフォーム作りをしっかりやった上で、そうしたちょっと俯瞰的な視点でも動けるようになりたいなと思っています。

　あと、もう一つチャレンジしたいのは「KubeCon」で登壇することです。自社で得た経験やノウハウの中で、自社以外にも役立ちそうな部分についてはグローバルで発信していきたいと思っています。

青山：いいですね。私としては、引き続き、クラウドネイティブ技術や新たな手法、技術などがどんどん広がっていく中で、自社の開発者に良いと思ってもらえる機能を積極的に導入して、開発生産性向上に寄与していきたいです。

　さらに、生産性向上に関する成果の「可視化」も取り組みたい領域のひとつです。作ったものが、生産性向上やユーザーの満足度の向上に関して、どれくらいのインパクトがあったのかが分かるような指標を数値として計測し、仕組み化して、継続的に改善していきたいと思っています。

　もうひとつは、複数のクラスタをうまく管理するフレームワークやライブラリの開発にもチャレンジしたいです。例えば、監視基盤にデータを送り、その分析結果から、システム側に命令を出して、このクラスタを別に移す、といったことをうまくできるような仕組みを、うまくできないものかと模索中です。

早川：増えたクラスタ間でいかにバランスを取りながらメトリクスを送るのか、その送り先をシステム的にうまく調整しながら選択してくれる感じでしょうか。

青山：そうですね。結局、それぞれにメトリクスを送った後、それをどう見通せばいいかとか、いろんな問題が出てくると思うのですが、複数クラスタをさらに一段階抽象化したようなレイヤがあると、うまくできる仕組みが作れそうな気がしています。

早川：なるほど。あと、AIの適用も便利そうですね。AIによって、今よりもう一段階上の「自律制御」が可能になるのではないかと期待しています。

青山：なんだか、技術的な話になってきましたね（笑）。

早川：やはりエンジニアなので、何か自分たちが「楽しい」と思えることに、今度も引き続き取り組んでいきたいですね。

著：高橋美津
写真：丸毛透