プラットフォームエンジニアリングについて学んでみた

はじめに

こんにちは、スカイアーチHRソリューションズのsugawaraです。

先日、「プラットフォームエンジニアリングって何？〜基本から AWS での実現方法について〜」というAWSのオンラインセミナーが開催＆公開されました。ここ最近自分も興味をもっていたトピックだったので、早速動画を視聴してみましたが、とてもおもしろかったです！視聴がまだの方は↑のリンクから動画と資料を確認してみてください。

さて、2023年のガートナーのハイプ・サイクルに出ていたプラットフォームエンジニアリングという言葉ですが、これから世界的に流行るようで、各クラウド事業者（Microsoft, AWS, Google Cloud）も解説などの記事を出しています。また、国内ではPlatform Engineering Information hubやPlatform Engineering Meetupというものも出てきており、盛り上がりを見せているような状況です。

今回はそんなプラットフォームエンジニアリングについて、一から学んでみたのでまとめてみました。なお、上記のAWSオンラインセミナーの「Amazon ECS で実現するプラットフォームエンジニアリング」の資料の一部を抜粋しております。もし興味のある方は動画と資料のほうで詳細をご確認ください。

プラットフォームエンジニアリングってなに？

現状では決まった定義はないようで、プラットフォームエンジニアリングは様々な説明がなされています。上記のガートナーのハイプ・サイクルでは、下記のように説明されています。

“プラットフォーム エンジニアリングは、ソフトウェア配信とライフサイクル管理のためのセルフサービスの社内開発者プラットフォームを構築および運用する分野です。これは、特に基盤となるシステムの技術専門家ではない開発者が、複雑な分散 IT システムを発見、運用、保護、改善し、構築するのに役立ちます。“

“プラットフォームは、厳選されたツールとサービスのセットにより、全体的な開発者のエクスペリエンスを向上させます。また、IT ソリューションの一貫性と品質を向上させ、冗長なツールとプロセスを削減し、複数のチームによる並行作業を統合し、セキュリティとコンプライアンスの標準を強化し、広範な自動化を組み込みます。“

重要な部分のみまとめると、「プラットフォームエンジニアリングはセルフサービスのプラットフォーム（プロダクト）を提供し、開発者体験と生産の向上に貢献する」、ということです。

プラットフォームエンジニアリングは、およそ 2026年までに80%の組織が使い始める技術要素とも言われており、今後の重要性が伺えます。では、なぜこのような傾向になっているのか？なぜ必要なのかについてみていきます。

なぜ必要なの？

プラットフォームエンジニアリングが必要とされる背景には、開発者の認知負荷の増加があります。

近年はマイクロサービスアーキテクチャやコンテナ、Infrastructure as Code（IaC）などの様々な技術が登場したことで、開発はどんどん複雑化しています。開発チームは、実際の開発業務以外にクラウドなどの最新技術へのキャッチアップ、各種開発ツールの熟知などの認知負荷がますます増えている状況です。

下記はState of Platform Engineering Report Vol.1の開発者の認知負荷（Cognitive Load）の変遷を表した図です。開発者の責任範囲と負荷の増加が増えているのがよくわかります。

近年はAWS CDKなどのIaCの登場により、開発者でもインフラの設定をコード化し、バージョン管理システムを通じてインフラを管理できるようになりました。しかし、開発者が開発業務と並行してインフラの構築と管理の知識という新しいスキルも必要とされるようになります。

また、継続的インテグレーション／継続的デリバリー（Continuous Integration/Continuous Delivery, CI/CD）の導入により、開発者はコーディングに加え、ビルドやデプロイまで担当する範囲が広がりました。これらは開発者の負担を増加させ、開発業務に集中することが難しくなります。

そのため、開発者の認知的負荷を軽減し、開発業務に注力できる環境を提供できるプラットフォームエンジニアリングが必要とされているということです。

具体的にどうやってするの？

ガートナーのハイプ・サイクルから、「プラットフォームエンジニアリングはセルフサービスのプラットフォーム（プロダクト）を提供し、開発者体験と生産の向上に貢献する」ものであると説明しました。

ここまでで、プラットフォームエンジニアリングが「なにを（開発体験と生産性の向上）」行うものかがわかったかと思います。では、具体的に「どうやって」実現していくのかを見ていきます。ここで紹介するキーワードは「Platform as a Product」と「Internal Developer Platform (IDP)」の2つです。

Platform as a Product

プラットフォームエンジニアリングでは、プラットフォーム自体を一つのプロダクトとして捉え、開発者を顧客とみなします。開発者がセルフサービスで利用できるツールやサービスを1つのプラットフォームに統合することで、煩雑な設定や管理作業から解放され、コーディングに集中できる環境を提供します。例えば、コンテナオーケストレーションツール（Kubernetes）、インフラのコード化ツール（Terraform）などを統合し、開発プロセスを自動化します。これにより、開発者体験や生産性を向上させることができます。

IDP

IDPはプラットフォームエンジニアリングチームがプロダクトとして構築するものとなります。開発者が必要なリソースやツールにセルフサービスでアクセスできるようなプラットフォームのことです。開発者が自分の作業環境を簡単にカスタマイズし、プロジェクトに必要なリソースをすぐに確保できるようにします。例えば、CI/CDパイプライン（Jenkins、GitLab CI/CD）やアプリケーションモニタリングツール（Prometheus、Grafana）を統合し、開発からデプロイメントまでのプロセスをスムーズにします。

どんなサービスやツールを利用するの？

IDPの構築に利用できるAWSサービスやOSSがいくつかあります。AWSオンラインセミナーの「Amazon ECS で実現するプラットフォームエンジニアリング」で紹介されていたものを抜粋して簡単に紹介します。これまで利用したことがないサービスばかりだったので、とても興味深かったです。

AWS Proton

AWS ProtonはAWSが提供するマネージドサービスで、インフラとアプリのデプロイを自動化し、管理するためのツールです。主な対象はマイクロサービスアーキテクチャやコンテナ、サーバーレスアプリケーションとなります。これにより、開発者はアプリのコードに集中できる一方で、インフラチームはアプリの実行環境テンプレートを定義し、これらのテンプレートでアプリの環境を一貫してセキュアにデプロイできます。2021年に一般提供を開始したAWSサービスのため、比較的新しいサービスとなります。（GA時のAWS公式ブログはこちら）

AWS Service Catalog

AWS Service Catalogとは、IT管理者が承認済みのAWSリソースのカタログ（ポートフォリオ）を作成して管理し、組織内のユーザーやチームが利用できるようにするためのサービスです。AWS認定試験でも、ガバナンスの強化といった分野で度々出題されるサービスであり、よく目にするサービスかとは思われます。

Backstage

Backstageは音楽配信サービスで有名なSpotifyが元々開発していましたが、現在はオープンソースとなっているサービスです。開発者がソフトウェアの開発、管理、探索を効率化できるように設計されています。主に、大規模なマイクロサービスアーキテクチャを持つ組織での使用を想定しており、開発者が必要な情報やツールへ簡単にアクセスできる一元化された場所を提供します。

おわりに

いま話題のプラットフォームエンジニアリングについて紹介してみました。なんとなく自分にはこれが合っている気がするので、今後さらに深ぼっていきたいです。まずはAWS ProtonやAWS Service Catalog、Backstageを実際に触っていきます！