「Platform Engineering」は何を解決するのか？ 誰が何をするものなのか？：サイバーエージェントのグループインフラ部門はパブリッククラウドとの戦いに

Gartnerが紹介し、海外で広まりつつある「Platform Engineering」とはどのようなものなのか。誰がどう取り組めばよいのか。2023年3月に開催された「Platform Engineering Meetup #1」に登壇したHashiCorp Japanの草間一人氏とサイバーエージェントの青山真也氏のセッション内容を要約してお伝えする。

[齋藤公二，＠IT]

　「Platform Engineering」（プラットフォームエンジニアリング）が、にわかに注目を集めている。Gartnerが「ハイプサイクル」や「2023年の戦略的テクノロジーのトップトレンド」の中でも紹介し、海外の企業IT担当者に広く知られるようになった。

　Gartnerの説明によれば、プラットフォームエンジニアリングは「ソフトウェアのデリバリーとライフサイクル管理を目的としたセルフサービス型の企業内開発者プラットフォームの構築と運用に関する専門分野」であり、取り組みの目標は「複雑なインフラストラクチャを自動化し、開発者のエクスペリエンスを最適化することで、プロダクトチームによる顧客価値のデリバリーを加速させること」だという。

　ただ、Gartnerも明確にプラットフォームエンジニアリングを定義しているわけではなく、企業がこれまで取り組んできた「共通基盤構築」や「DevOps」「運用自動化」などのキーワードと何がどう違うのか分かりづらさもある。

　そうした中で国内の有志が2023年3月9日に「Platform Engineering Meetup #1」を開催した。同Meetupには、HashiCorp Japanシニアソリューションエンジニアの草間一人氏（@jacopen）と、サイバーエージェント アドテク本部 インフラストラクチャエンジニアの青山真也氏（@amsy810）が登壇した。

DevOpsは「認知負荷の高さ」と「人材不足」が課題に

HashiCorp Japan シニアソリューションエンジニア 草間一人氏

　草間氏のセッションでは、プラットフォームエンジニアリングの動向と、ソフトウェア開発や企業担当者が踏まえておきたいポイントが解説された。

　プラットフォームエンジニアリングについて、「決まった定義はないのですが（Gartnerの説明から）共通する点を抜き出してみると、『開発者と生産性を向上させるためにセルフサービスで利用できるツールチェーンとワークフローを設計、構築する分野』とまとめられる」と説明。プラットフォームエンジニアリングが注目されるようなった背景には、DevOpsを推進する際の「認知負荷の高さ」と「やり切れる人材の少なさ」があると草間氏は話す。

　「開発者がアプリをエンドツーエンドでデプロイして実行することが『真のDevOps』と言えます。しかし、多くの組織にとって真のDevOpsを実現するのは非現実的です。クラウドネイティブの時代になり、ツールやフレームワークが増え、それらを組み合わせてDevOpsを実現しています。さまざまな観点で気を使う必要があり、1人のエンジニア、1つの組織が全部やっていくことはしんどい。認知負荷が高いのです。これらを全部やれるスーパーマンもそうそういません」（草間氏）

理想は分かっていても、やることが多過ぎる（草間氏の講演資料より）

共通プラットフォームの4割は生まれた時点で失敗、4割はうまく運用できずに失敗する

　とはいえ、DevとOpsが分断したクラウド以前（1990〜2000年代初頭）の開発スタイルに戻すことはできない。一方で、よく陥りがちなアンチパターンとしては、Devチーム内にOpsを担う人材を抱えることが挙げられるという。この場合、幅広い知見を持つチームの中で最も価値のあるエンジニアがシャドーオペレーションを担うことが多くなり、チームの能力を最大限に発揮できなくなるという。

　そこで、登場した概念が「インターナルデペロッパープラットフォーム」（IDP）だ。

　「IDPは『プラットフォームチーム』というチームを作って、開発者がセルフサービスで利用するプラットフォームを、そのチームが構築するというアプローチです。プラットフォームはさまざまな技術やツールで構成され、抽象化し過ぎることなく、開発者の認知負荷を軽減していきます」（草間氏）

IDPのイメージ（草間氏の講演資料より）。「画像のツール名やOSS（オープンソースソフトウェア）はあくまで例です。自前のツールやOSSに限らず、パブリッククラウドのマネージドサービスを活用したゴールデンパスも普通にあり得えます」（草間氏）

　ただ、IDPは新しい考え方ではない。業種業態を問わず、一定規模以上の企業なら、共通のプラットフォームを構築、提供する取り組みは存在した。また「Platform as a Service」として認知負荷を下げる取り組みも過去には存在した。しかし、そうした共通プラットフォームの取り組みのほとんどが失敗しているのも現実だという。

　「うまくいくプラットフォーム作りは本当に難しいです。個人的な経験に基づけば、共通プラットフォームの4割は生まれながら失敗していて、4割はうまく運用できずに失敗します。成功するのは2割かそれ以下です。失敗する理由は、そのプラットフォームを利用する人にとって価値がないためです。『誰に』『何を』『どうやって』という要素があると『どうやって』ばかり見ていたことが問題です」（草間氏）

　「どうやって」に注目すると、コンテナ、Kubernetes、オブザーバビリティなどの技術にだけ注目して共通基盤を構築してしまったり、開発者が欲しいものにマッチしていなかったりすることが起こりやすい。また、特定技術に依存して廃れてしまったり、期限のあるプラットフォーム構築プロジェクトとなり継続性がないまま終わってしまったりする。

　「『誰に』『何を』に注目し、継続的に回していくことが大切です。そこでポイントになるのが『Platform as a Product』という考え方です。開発者を顧客として考え、顧客にプラットフォームというプロダクトを提供していきます。チームに専任のプロダクトマネジャーを置き、プロダクトとしてプラットフォームの方向性を定めていくことで、プロダクトマネジメントの手法をそのまま使えるのがメリットです」（草間氏）

　その上で草間氏は、プラットフォームエンジニアリングとは何かをこうまとめた。

　「プラットフォームエンジニアリングとは、『真のDevOps』のために、開発者の認知負荷を下げ、セルフサービスで利用できるプラットフォームを提供し、迅速なアプリケーションの開発体験とデリバリーを実現する。そのために、顧客を正確に理解し、継続的なプラットフォームの開発体制をプロダクト開発の知見を取り入れながら作り上げていくことです」（草間氏）

Kubernetesサービスで、共通プラットフォームチームを組織するサイバーエージェント

サイバーエージェント CIU（CyberAgent Infrastructure Unit）ソフトウェアエンジニア 青山真也氏

　こうした考え方をすでに実践しているのが、サイバーエージェントだ。サイバーエージェントでは、社内の共通プラットフォームとしてマネージドKubernetesサービス（Kubernetes as a Service: KaaS）として「AKE」を提供している。

　「AI、広告とメディア、ゲームという事業領域ごとにそれぞれプライベートクラウド環境（OpenStackベース）が存在していました。2021年ごろに両者が合併し、CIU（CyberAgent group Infrastructure Unit）が設立されます。それを機にKaaSやML Platformなどの共通基盤を開発する約10人で構成されるチームがカバーする範囲も事業部から会社全体へと変わりました。草間さんの話にもありましたが、何かを作って手動で更新することが多いと10人では回せなくなります。そこで少人数で効率的に運用するために、ソフトウェアによる自律化を推進しています」（青山氏）

　KaaSとしての「AKE」がリリースされたのは2017年4月で、当初は、クラスタ管理の仕組みとしてOpenStack Heatを利用、Kubernetes Controllerを実装して2020年まで運用していた。ただ、自動化がしづらい点や将来的な拡張を考え、2021年4月から大規模なリプレースに取り組んだ。

　「Cluster APIベースKaaSとしてAKE v2の開発にかじを切りました。Kubernetesクラスタ自体を管理クラスタから管理するような仕組みで、管理クラスタでManifestを書くと、うまい具合にKubernetesクラスタを作ってくれます。また、Controllerを使った自動化の仕組みも作りやすいという特徴があります」（青山氏）

AKEの歴史（青山氏の講演資料より）

　AKEが提供している機能としては、クラスタのアップグレードなどのライフサイクル管理、クラスタのオートスケールやオートヒーリングがある。その上で、Kubernetes上に載せるシステムの管理も実現している。

　「Kubernetes上に載せたシステムは、管理し続けることが難しい。運用負荷が上がって塩漬けになることもあります。そこでAKEでは、ユーザーのクラスタ上に何かOSSを導入したい場合、アドオンで導入できる仕組みを提供しています。ユーザークラスタだけでなく、われわれが管理するクラスタ側にデプロイしてユーザーに提供する仕組みも持っています」（青山氏）

アプリケーションだけでなくプラットフォームも塩漬けさせずに進化させ続けるべき

　ユーザークラスタに提供するOSSは、バージョン管理などが必要になるが、それも共通基盤チームで管理する。

　「各Kubernetesに対応するOSSセットを管理しています。それぞれのバージョンで動いているアプリケーションの動作確認はわれわれのチームで自動的に行っています。動作が確認できたアプリケーションをユーザーが利用します。ユーザーは、特定のアプリケーションをアップデートするときに、GitHubのタグを更新するだけです。Kubernetesは運用が大変、更新の追従が大変といわれます。その大変さをわれわれのチームが吸収して、プラットフォームとして提供する体制です」（青山氏）

　さまざまなKubernetes環境を管理することはチームにとっての負担になることから、アップデートの追従などは自動化しているという。

　「Cert Managerの更新、Argo CDの更新などは、GitHubに自動的にPull Requestが上がってくるようになっています。変更点もPull Requestで確認でき、われわれは変更点をマージしてテストする仕組みまで自動化しています」（青山氏）

　サイバーエージェントには約100のプロジェクト（子会社、事業）があり、CIUがターゲットにしているのは、各プロジェクトのユーザーとなる。ユーザーは「Google Kubernetes Engine（GKE）」や「Amazon Elastic Kubernetes Service（EKS）」を選ぶこともできるため、AKEチームが戦う相手は、パブリッククラウドになるという。

　「コスト、利便性、運用容易性、手厚いサポートを武器に、パブリッククラウドと勝負しています。Kubernetesの環境をリリースするだけでなく、ユーザーが車輪の再発明をしたり、ベストプラクティスが他のチームに行き渡らなかったりする課題を解決するために、ユーザーのニーズをプラットフォームとして提供する仕組みを作っています。クラウドネイティブにおいてはサービス、アプリケーションを進化させることに注目されがちですが、プラットフォーム側も塩漬けさせずに進化させ続けるべきです」（青山氏）

　進化の例としては、本来エキスパートやコンサルが行うような改善提案を機能として提供していることが挙げられる。例えば、余剰リソースの検知と通知、余剰権限の検知と通知、非推奨、廃止APIの検知と通知などだ。他にも、サイバーエージェント横断でGatekeeperのポリシーを作成しており、63個のポリシーを使って、Kubernetesを使っていく上でのベストプラクティスや非推奨の設定などを確認できるようにしている。これらはAKEだけでなく、サイバーエージェントが利用する全てのKubernetes環境で利用できるという。オブザーバビリティのための各種ツールのインストール、コンテナイメージの脆弱（ぜいじゃく）性スキャンやSBOM（利用しているソフトウェア部品表）スキャンの提供などもAKEチームで担う形だ。

Kubernetes利用の最適化、改善支援例（青山氏の講演資料より）

　青山氏は最後に次のようにプラットフォームエンジニアリングを展望し、セッションを締めくくった。

　「長年のKubernetes運用の経験から、ユーザーが負担と感じる運用や実装、進化し続けるベストプラクティスをAKEチームが提供しています。アプリケーションだけでなく、進化し続けるプラットフォームにすることを目指していきます」（青山氏）