プラットフォーム エンジニアリングに関する 5 つの誤解: プラットフォーム エンジニアリングとは一体なのか

※この投稿は米国時間 2024 年 5 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

なぜ新しいトピックに対して否定的になってしまう人がいるのか、その理由は、群盲象を評すの寓話からわかります。その人自身の視点からのみで物事を見てしまうと、その全体像を見失ってしまうということです。プラットフォーム エンジニアリングはソフトウェア デリバリーの比較的新しい手法です。現在、IT 組織やソフトウェア エンジニアのチームの多くがプラットフォーム エンジニアリングについて検討している段階にあるのですが、プラットフォーム エンジニアリングとは何なのか、プラットフォーム エンジニアリングで何ができるのか、プラットフォーム エンジニアリングを導入すべきか（あるいはすべきではないか）について、多くの意見の相違が存在します。

Google は、ソフトウェア デリバリーについて総体的に考えることが重要であると考えており、Google がプラットフォーム エンジニアリングを好んでいるのはそのためです。個々のチームで捉えられる問題が断片的なものになっていると、システムが分断、あるいは問題を含むものになってしまいます。ソフトウェア デリバリー プラットフォームを構築されたひとつのプロダクトとして捉えることではじめて、「全体としての象」が見えてきます。  

今回は、全体像がわからない方に多い、プラットフォーム エンジニアリングに関する一般的な 5 つの誤解についてご説明します。このブログ投稿の第 2 回目では、プラットフォームの構築のされ方に関する誤解について取り上げ、何をすべきか、あるいは何をすべきではないかに関する話をします。

1. 誤解: デベロッパー ポータルと社内デベロッパー プラットフォームは同じものである

人によっては、すでにデベロッパー ポータルを使用している方もいるでしょう。そのため、プラットフォーム エンジニアリングにすでに取り組んでいると考える人もいると思います。ですが、デベロッパー ポータルとは実際にはインターフェースのことであり、社内デベロッパー プラットフォーム（「IDP」と呼ばれることもあります）のインターフェース以外の部分とをつなぐためのものです。デベロッパー ポータルとは単なる表玄関であり、これで問題全体を解決することはできません。確かに、社内デベロッパー プラットフォームとデベロッパー ポータルは非常に似通った名前ですが、重要な違いがいくつか存在します。この 2 つの違いを詳しく確認してみましょう。

デベロッパー ポータルとはインターフェースのことであり、ソフトウェア デベロッパーはここから、IDP が提供するさまざまなサービス、ツールを見つけて利用することができます。通常、デベロッパー ポータルでは次のようなものが提供されます:

• インフラストラクチャやアプリケーションをデプロイして構成するためのセルフサービス テンプレートの実行（ゴールデンパスとしても知られています）

• デプロイされたリソースやメタデータ（所有者や環境など）を追跡するためのサービス カタログ

• SLO、DORA 指標など、アプリケーション サービスのステータスを視覚的に表示したもの

• プラットフォーム、アプリケーション、API、あるいはコードそのものに関するドキュメント

一方で、社内デベロッパー プラットフォームとは、デベロッパーがゴールデンパスを活用して、セルフサービスで作業を進められるようにするためのものです。このプラットフォームでは、プラクティスのコード化、会社全体規模での構成の設定、セキュリティ管理の適用などの手法が採用されており、技術的な複雑さを排除することが可能です。それぞれの新しいサービスは IDP からデプロイされます。たとえば、Google Kubernetes Engine（GKE）、Cloud Run、Compute Engine、Cloud Workstations などは、オンデマンドですぐに利用できる状態になります。チケット、手動による承認、会議などを待つ必要はありません。

Cloud Run などの既存の Google Cloud プロダクトを使用することで、社内デベロッパー プラットフォームの取り組みを簡単に開始することもできます。Cloud Run には、ワークロードを作成、デプロイ、モニタリングするための UI が用意されており、自動化用の API や、gcloud を介してのコマンドライン アクセスも利用できます。ただ、Google Cloud プロダクトの多くでそれ自体がプラットフォームであるとみなすことができるものの、それら単体では不十分であることが多いです。制限を適用したり、特定のデベロッパーの行動を奨励する目的で、柔軟性に制限を加える、あるいは複数のプロダクトの使用をひとつのインターフェースに統合するなどの措置を行い、デベロッパー エクスペリエンスを簡素化することができます。

また、社内デベロッパー プラットフォームでは、適切な上限が設定する必要があります。これは、「適切なデフォルト値」を設定してゴールデンパスを提供することで、あるいは、組織のポリシーを満たす人にのみリソースとサービスの選択を制限することで達成できます。許可されないリソースや設定は、ポータルを介して提供されなくなります。また、許可されないという表示とともに、「非常時」のために制限を破るための説明やメソッドが示される場合もあります。

デベロッパーが実際に操作するものは、ほとんどの場合デベロッパー ポータルの UI であり、その背後にあるデベロッパー プラットフォームは隠された状態になっています。

2. 誤解: 社内デベロッパー プラットフォームは必要ない

これは場合によります。必要になることはありますし、もしかすると、あなたはすでにプラットフォームを持っているかもしれません。コードを本番環境に導入するために現在あなたが使用している手法が何であれ、それこそがまさにプラットフォームです。それは、さまざまなプロセスやシステムが混ぜ合わさったものであるかもしれませんし、人が介在することもあります。そして、毎回これが変わることもありえます。たとえば、サイロ化された複数の異なるチームに対して発行する一連のチケットがある場合、これを、「プラットフォームとしての事務作業」が存在する、というように説明できます。あるいは、何かをリリースする際に特定の個人と話をする必要がある場合は、これを「プラットフォームとしての人」が存在する、と説明できます（これは、The Phoenix Project に登場する Brent のことです）。

プラットフォーム エンジニアリングは、チームの全員に DevOps プラクティスに関する深い理解を要求することなく、現段階で運用しているプロセス（あるいはその改良バージョン）をモデル化して、自身に代わってそれを実行するソフトウェアを構築することから始まります。これは、簡単な CI / CD パイプラインから開始することが可能で、一貫性のあるオブザーバビリティやマネージド インフラストラクチャのサービスでこれを改善することができます。これらのコンポーネントをつなぎ合わせることで、ひとつのプラットフォームになります。デベロッパー チームに抽象化を提示し、このようなコンポーネントを一貫性のあるデベロッパー エクスペリエンスとして使用可能な状態にまとめ上げることが、プラットフォーム エンジニアリング チームの役目であり、社内デベロッパー プラットフォームは、これを達成するための手段です。

3. 誤解: プラットフォーム エンジニアリングとは「単に DevOps を発展させたもの」である

あらためて記す必要もないかもしれませんが、DevOps とは、ソフトウェア デリバリーの速度の向上、サービスの信頼性の改善、ソフトウェアの関係者間の共有オーナーシップの構築を目的とする、組織的、文化的な取り組みのことです。DevOps プラクティスには以下が含まれます。

• バージョン管理

• 継続的インテグレーション

• トランクベース開発

• 継続的なテスト

• 継続的デリバリー

• アーキテクチャ

• クラウド インフラストラクチャ

• テスト管理

インフラストラクチャ管理の手間は膨大になることがあり、その場合、DevOps モデルの拡張性に関する課題が顕在化することになります。これは、認知負荷の増大、デベロッパーの燃え尽き症候群、チーム間で発生する不一致、文化的な抵抗感の要因になる可能性があります。

プラットフォーム エンジニアリングは、「大規模な DevOps」への自然な進化の結果として、今になり登場したものです。プラットフォーム エンジニアリングの中で活用されている DevOps プラクティスには、以下があります。

• デベロッパー中心のアプローチの採用

• 自動化と Infrastructure as Code（IaC）

• セキュリティとコンプライアンス

• オブザーバビリティ

• 継続的な改善

プラットフォーム エンジニアリングとは、DevOps のプラクティスの一部をコードにしてソフトウェアに組み込む試みです。つまり、プラットフォーム エンジニアリングは「単に DevOps を発展させたもの」ではありません。そうではなく、これは「DevOps をシフトダウン」してプラットフォームに組み込む試みであり、デベロッパーに高い専門性を要求することなく、DevOps のプラクティスを実践できるようにするものです。

4. 誤解: プラットフォーム エンジニアリングとは「単なる自動化」のことである

チームで自動化を活用することで、システムの管理時に人間が介在する必要性を減らすことができます。自動化は、シェル スクリプトのような簡単な手法で達成できることもあれば、ずっと複雑で、微細で、スケーラブルな手法で行われることもあります。「単なる自動化」として冷ややかな目で見られることもありますが、それは、頻繁に壊れる粗末なシェル スクリプトが大量に存在することに対しての嘲笑であることがほとんどです。

そして、そのとおりです。自動化で、解決がより困難な問題が新たに発生してしまうこともあります。したがって、自動化の品質ではなく、シグナルの誤解釈、設計の誤解、不適切な仮定、インセンティブの不一致などの社会技術的な圧力を原因としたシステムの不具合の発生を回避するために、やみくもに自動化を進めないようにするというのは理にかなっています。

しかし、自動化に対する「スクリプトのバグ」のアプローチは場当たり的な対応であったのに対し、プラットフォーム エンジニアリングはそれよりもずっと総体的な手法であり、サービスの作成、構成、デプロイから、モニタリング、スケーリング、最終的な解体までの完全なシステム ライフサイクルが考慮されています。

つまり、プラットフォーム エンジニアリングとはまさに「自動化」のことです。ただし、このプラットフォームはひとつのプロダクトとして提供されるものであり、また、後付け的に登場したものではなく、完全なサービス ライフサイクルのために設計されています。

5. 誤解: プラットフォーム エンジニアリングは単に今流行しているだけである

最新のインフラストラクチャとソフトウェアのスタックの設計と管理の複雑性は近年になって増大しており、ソフトウェア開発チームにかかる認知負荷が大幅に増える結果になっています。そのため、このようなサービスのデプロイと管理の複雑さを排除することは必須です。数百、数千単位のマイクロサービスが、管理対象の多くのコンピューティング リソースのフリートに分散しているような状況の場合、インフラストラクチャとアプリケーション レイヤの両方に関する深い知識を習得することは、単に不可能であるといえるでしょう。

今日、プラットフォーム エンジニアリングは実際の問題の解決に役立てられており、具体的には以下があります。

1. DevOps の過剰負荷（認知負荷）- 現代のソフトウェアの増大する複雑性の管理に取り組むチームがボトルネックになる場合

2. デベロッパーの摩擦 - インフラストラクチャ、ツール、ポリシー、プロセスを扱うことに起因する、定量化できるレベルでのチームの生産性低下 DORA の指標もご覧ください。

プラットフォーム エンジニアリングであれば、組織の特定のニーズ、プロセス、ワークフロー、セキュリティ、インフラストラクチャに対応することができます。その目標は、摩擦や認知負荷を低減し、デベロッパー エクスペリエンスを改善することです。

これに関連して、プラットフォーム エンジニアリングより前に存在するものとして Platform as a Service（PaaS）がありますが、PaaS はどのチームにとっても適している、というわけではありませんでした。では、プラットフォーム エンジニアリングと PaaS の違いは何でしょうか。PaaS は、アプリケーションを効率的に構築して、必要となる基盤のインフラストラクチャを構成するためのテクノロジーを提供するものであり、PaaS を適切に導入するには、これを取り囲む、人とプロセスからなるエコシステムが必要になります。プラットフォーム エンジニアリングとは、PaaS を含むプロダクトの抽象化、拡張を構築するための手段であり、その組織にとって適した制約や自由を実現します。つまり、プラットフォーム エンジニアリングとは、PaaS の「テクノロジー中心」のモデルでは、さらなるカスタマイズを必要とする組織においてうまく機能しない場合があるため、それに対応するために現れたものであるとも言えます。

一言で言えば、プラットフォーム エンジニアリングとは、システムの規模の拡大に対して DevOps の手法が自然に進化した結果として、今になり現れたものです。「自身での開発と運用」のパラダイムは、複雑性が低く、サイズが小さなシステムではうまく機能していましたが、現代のソフトウェア システムはこれまでにないほどに巨大で複雑になっています。そして、プラットフォーム エンジニアリングが担う役割の重要性は、現代の世の中において増す一方です。

象の姿は見え始めています。これら 5 つの誤解を解くことで、プラットフォームとはいったい何なのかを理解しやすくなるかと思います。パート 2 もぜひご覧ください。プラットフォームの構築のされ方、何を行い、何を行わないかに関する他の 5 つの誤解について説明します。

-アプリケーション プラットフォーム担当 EMEA プラクティス ソリューション リード Darren Evans
-Google、信頼性アドボケイト Steve McGhee