【クラウドネイティブ会議】チーム内の課題解決から共通基盤へ育てるPlatform Engineeringの始め方

マイクロサービスアーキテクチャは、サービスごとの独立した開発やリリースを可能にする一方、言語ランタイムのEoL対応やライブラリの脆弱性対応、リリース準備といった作業がサービスの数だけ繰り返し発生し、本来進めたい開発の工数を圧迫することがある。「クラウドネイティブ会議」に登壇したアクセンチュア テクノロジー コンサルティング本部の崎原晴香氏は、こうした横断的な課題を共通の仕組みで解決するPlatform Engineeringについて「“うちにはまだ早い”は本当？ ─ 小さく始めるPlatform Engineering入門」と題して、Kubernetesや大規模な専任組織がなくても、身近な困りごとの共有や小さな便利ツール作りから始められるとして、その考え方と段階的な進め方を解説した。

Kubernetesは必須ではない ―― 共通化こそPlatform Engineeringの本質

アクセンチュアの崎原晴香氏は冒頭、自身が業務で直面した二つの出来事を紹介した。

一つは、Python 3.9を使用するAWS LambdaのランタイムがEoLを迎えるという通知が大量に届いたことである。多数のLambdaを利用していたため、更新に伴う修正やデグレード確認が大きな作業になった。

そしてもう一つは、広く使われているライブラリに脆弱性が見つかり、複数のマイクロサービスのリポジトリにDependabotからプルリクエストが作成されたことである。期限までに本番環境へ反映する必要があり、大きな割り込みタスクとなった。「一度やって終わりではなく、こうした作業は何度も繰り返しやってきます。そのたびに、本来やるはずだった開発がこぼれ落ちていきます」と崎原氏は語った。

EoL対応や脆弱性対応、リリース準備は必要だが、顧客へ直接価値を届けるビジネスロジックの開発ではない。しかも、同じような作業が各サービスで個別に発生する。崎原氏は、この繰り返し作業に開発工数が奪われる問題への答えとして、Platform Engineeringを挙げた。

Platform Engineeringという言葉から、Kubernetesを思い浮かべる人は多い。しかし崎原氏は「Kubernetesがないとできない、というのはウソです」と指摘した。

k8sがなくてもできるPlatformEngineering

KubernetesとPlatform Engineeringが結び付けられて語られることが多い理由は、その設計にある。Kubernetesでは、PodやServiceなどのリソースに対する操作がkube-apiserverへ集約される。そこで認証・認可やアドミッションコントロールを実施するため、クラスタ全体へ共通ルールを適用しやすい。

この仕組みを利用する例として、崎原氏は、クラスタ全体へポリシーやセキュリティ、通信制御を適用するKyverno、Cosign、Istioを紹介した。

ただし重要なのはKubernetes自体ではなく「どこか一ヶ所に集まるオペレーションに対して、共通の統制を利かせる」という考え方である。

Kubernetesを使わない例として、崎原氏は、組織ポリシーを反映した自作AWS CDKコンストラクタ、CI/CD設定や便利なスクリプトを組み込んだサンプルリポジトリ、AWS Configによるリソース設定の検知・修正を挙げた。「サービスごとにバラバラに行われている作業を、一ヶ所の基盤でまとめて制御できるのであれば、どのような環境や技術スタックでもPlatform Engineeringはできます」と崎原氏は説明した。

完成形を急がない ―― Level 1はチーム内の課題共有から始まる

全サービスへ適用できる共通基盤を一度に作ろうとすると、三つの壁に直面する。一つ目は、全サービスに適用できる統一設定を作る「プラットフォーム設計の難しさ」である。二つ目は、作っても現場に使ってもらえない「プラットフォーム浸透の難しさ」である。そして三つ目が、利用手順や制約が増え、かえって開発速度を下げる「プラットフォーム利用の難しさ」である。

自分たちだけでもできるPlatform Engineering Platform Engineeringの難しさ

しかし崎原氏は、「まあ待て、早まるな」と呼びかける。なぜなら、最初から完成度の高い共通プラットフォームを目指す必要はないからだ。

CNCFが公開するPlatform Engineeringの成熟度モデルでは、成長段階をLevel 1からLevel 4までに整理している。Level 1はボランティアベースで、必要に応じてアドホックに開発する段階である。Level 2では専任チームが置かれ、Level 3ではセルフサービス化され、Level 4では統合されたマネージドサービスへ成長する。

一般にプラットフォームという言葉から想像されるのは、Level 3やLevel 4の姿である。しかし、最初に目指すべきはLevel 1だという。「ボランティアベースでも、利用方法がバラバラでも、何もしていないLevel 0よりは確実に良い状態です」と崎原氏は説明した。

崎原氏はLevel 0からLevel 1へ進むための行動として「積極的な自己開示」「積極的なナレッジ共有」「気軽なコミット」の三つを挙げた。

まず、Daily Standupや定例会などで、自分が困っていることを共有する。次に、解決方法や作成したスクリプトをSlackやTeamsへ投稿する。さらに、ほかのメンバーにも需要がありそうなら、便利な設定やツールをリポジトリへコミットし、再利用できる状態にする。「『ほかの人も同じことで困っていないか』『みんなにも役立つかもしれない』という意識でナレッジを共有する風土を作ることが、Level 1への道です」と崎原氏は強調した。

未完成のツールやアイデアでも気軽に共有できる心理的安全性があれば、改善の種が蓄積される。Level 1でこうした土台を作っておけば、将来Level 2へ移行する際にも、効果を確認した仕組みを展開しやすくなる。

強制せずに広げる ―― フィードバックが共通基盤を育てる

Platform Engineeringの設計、浸透、利用に関する難しさは、主にLevel 2以降で顕在化する。というのも、Level 1では自チーム内の課題を解決すればよいが、Level 2では、作った仕組みをほかのチームにも利用してもらわなければならないからだ。

この段階で生じやすいのが、「強制されている感」である。基盤を作る側は効率化や安全性の向上を意図していても、利用する側からすれば、既存の開発方法を上から変えさせられるように見える可能性があるというわけだ。

Platform普及の壁をどう超えるか？ Platform Engineeringの難しさ= Level2の難しさ

そこで崎原氏は、最初から強制するのではなく、推奨という形で展開することを提案した。「全部のサービスで今日から使ってください、と強制するのではなく、まずは推奨というスタンスで始めます。使うかどうかは各チームに委ねます」と崎原氏は説明した。

例えば、一部のマイクロサービスだけを対象にする、本番環境ではなく開発環境から始める、重大なルールのみを強制して、それ以外は警告にとどめるといった方法がある。

ただし、利用を任意にするだけでは改善につながらない。使わなかった理由を収集するとともに、問い合わせ用のSlackチャンネルなどを用意し、現場と継続的に対話できる状態を作ることが重要である。既存の仕組みと合わない、導入方法が分からない、必要な機能が不足しているといった理由を把握できれば、プラットフォームの改善につなげられるのだ。

崎原氏は、「作って渡して終わりにすると、ルールを作る側と使う側の距離がどんどん遠くなります。双方向にフィードバックできる仕組みが必要です」と語った。

CloudNative・SRE・Platform Engineeringが重なり合い、開発生産性を生み出す

最後に崎原氏はCloudNative、SRE（Sight Reliability Engineering）、Platform Engineeringの関係を示した。三者はそれぞれ独立した取り組みではなく、実践する領域が重なり合い、相互に補完しながら開発を支えているという。

CloudNativeは、クラウドの特性を活用し、アジリティとスケーラビリティを確保する。SREは、信頼性を担保しながらシステムを安全に進化させる。そしてPlatform Engineeringは、開発者が本質的な作業に集中できる環境を整える。これが三者それぞれの主要な役割だ。

CI/CDや自動化、オブザーバビリティ、推奨設定の提供といった取り組みは、複数の領域にまたがる。「三つの間に境目があるわけではありません。互いに補完し、助け合いながら、一丸となって開発を支えています」と崎原氏は説明した。

開発生産性の源泉CloudNativeとSREとPlatform Engineeringの関係

三つの領域はそれぞれ成熟度モデルを持つが、個別対応からチーム間連携、組織的な協業へ進む方向性は共通しており、同じ軸で比較することで組織のボトルネックを把握しやすくなる。

例えばCloudNativeの成熟度が高くても、SREやPlatform Engineeringの成熟度が追い付いていなければ、そこが組織全体のボトルネックとなる可能性がある。

崎原氏は、サービスごとに繰り返される作業を一ヶ所の基盤で制御できれば、環境や技術スタックを問わずPlatform Engineeringを実践できるとまとめた。まずは自チーム内の課題解決から始め、Level 1からLevel 2へ進む際には、段階的に展開しながら双方向のフィードバック機構を整えることが重要になる。「皆さんの開発に何か課題があるのであれば、解決のために足りないものはPlatform Engineeringかもしれません。まずは最初の一歩から始めてみてください」と崎原氏は呼びかけた。

Platform Engineeringは、一部の先進企業だけの取り組みではない。日々繰り返している面倒な作業を共有し、一つのスクリプトや設定へまとめるといった小さなことも、その出発点なのである。