【CNDW2024】Platform Engineeringの成熟度モデルごとにフェーズに応じてリファレンスアーキテクチャを提示、開発の効率化と品質向上を実現

CloudNative Days Winter 2024で、AWSの山田 亮太氏が「成熟度別Platform Engineeringアーキテクチャ道場！」と題した講演を行った。本セッションではPlatform Engineeringの本質を探り、成熟度モデルを軸にInfrastructure、CI、CDといった主要領域の課題とその解決策を具体的に解説した。セッションの詳細を振り返りながら、その示唆に富む内容をレポートする。

成熟度モデルで見るプラットフォームの提供方法

Platform Engineeringは、現代のソフトウェア開発において注目を集める重要なトレンドだ。山田氏はPlatform Engineeringを実現するためには、自律性と説明責任を持った少人数のチーム「Two Pizza Team」、プラットフォームを製品として自律性と説明責任を持って開発および改善するチーム「Platform Team」の、2つのTeamを必ず用意するべきとした。

そのうえで、Platform Teamが提供するプラットフォームの提供範囲を整理し、Software Development Lifecycleに基づいてコーディング、ビルド、テスト、デプロイ、運用、観測といった各フェーズでプラットフォームが果たすべき役割を示した。「Platform Teamが提供できるプラットフォームは、認知負荷を軽減するためのプロダクトであれば何を作ってもよく、本質的に重要なのはそれが開発チームにとって役立つかどうかという点です」と山田氏は強調した。

さらに山田氏は、プラットフォーム提供の進化を示す、独自の「成熟度モデル」を提示した。このモデルは、テンプレートの提供から始まり、完全自動化されたプラットフォームへと進化する4段階のステップで構成されている。

Platformの成熟度レベル

最初の段階である「テンプレート提供」では、Gitリポジトリにホスティングされたプロジェクトテンプレートを提供する形が主流だが、開発チームがその後の運用責任を負うため、認知負荷が大きくなる。次の段階の「パッケージ化」では、HelmやTerraformモジュールを利用してテンプレートを管理しやすい形で提供し、更新作業を効率化する。さらに「インフラ提供」の段階では、Platform Teamがインフラ全体をホスティングし、開発チームはAPIやSDKを通じて利用するだけで済むようになる。そして最終段階の「完全自動化」では、Kubernetesクラスターのバージョン管理やデプロイが自動化され、開発チームはプラットフォームの存在を意識せずに作業できる環境が整うというわけだ。

今回のセッションで山田氏は、Platform Teamが提供する以下の3つの領域にスコープを当てて、成熟度モデルとリファレンスアーキテクチャを活用することで、各組織に適したPlatform Engineeringの実装を可能とし、ソフトウェア開発の効率化と品質向上を実現するための方法論を紹介した。

1. Infrastructure
2. CI
3. CD

Infrastructureにおける責任分界点と自動化への道

山田氏はまず、Platform Engineeringの基盤となるInfrastructureに焦点を当てた。「Platform Teamがどこまで責任を持ち、どこから開発チームが担うべきか。この境界をはっきりさせることで、無駄な混乱を避け、効率的な運用が可能になります」と述べ、責任分界点を明確にすることの重要性を指摘した。

InfrastructureをPlatform Teamが提供するアーキテクチャの例

Infrastructureにおける最も基本的な提供方法としては、GitリポジトリにKubernetesマニフェストやTerraform HCLコードなどのプロジェクトテンプレートをホスティングする形がある。しかし「テンプレートを提供するだけでは、ダウンロード後の運用やバージョン管理はすべて開発チームの責任になります」と山田氏は言い、このことがもたらす課題について次のように指摘した。テンプレート内で使用しているリソースのバージョンアップに誰の責任で追従するのか、またテンプレートの内容をより効率的かつセキュアに改善する責任がどこにあるのかが不明確な場合、運用上の負担が開発チームに集中し、結果として認知負荷が増大する可能性があるという。

こうした課題を解決する方法として、山田氏は次のようなプラットフォーム提供の進化を提案した。まずテンプレートをHelmやTerraformモジュールとしてパッケージ化し、バージョン管理を可能にすることで、Platform Teamがテンプレート内容の更新を一元的に行えるようにする。これにより開発チームは必要最小限の設定変更だけで最新のプラットフォームに追従できるようになる。またツールを活用することで、古いバージョンを使用しているチームに対して自動的に警告を送る仕組みを整備することも可能になる。

さらに進化した形として、Platform TeamがホスティングするKubernetesクラスターやAWS S3のような実行環境そのものを提供する段階に至る。これにより、開発チームはインフラの具体的な設定や運用を意識せず、APIやSDKを通じて利用するだけで済むようになる。この段階では、Platform Teamがインフラ全体を管理し、開発チームがアプリケーション開発に専念できる環境が整う。ArgoCDを利用したデプロイ管理や、Cluster APIによるクラスター管理はこの段階で有効な手法として挙げられた。

その次のステップとして、プラットフォーム運用の自律化と自動化が進められる。たとえばブルーグリーンデプロイメントの仕組みを用いて、新しいクラスターをプロビジョニングし、リソースを移行する方法が紹介された。これにより、問題が発生した場合にはロールバックを行うことで、運用負荷を大幅に軽減することができる。また設定値の検証や変更を自動化する仕組みの導入についても紹介し、インターフェースの抽象化が進み、開発チームの認知負荷をさらに低減させるという。

最終的には「すべてを手作業で管理するのは現実的ではありません。自律化と自動化が成熟したPlatform Engineeringの基盤です」と、責任分界点を明確にして自動化を推進することがいかに重要であるかを改めて強調した。

CIにおけるセキュリティと効率化

山田氏は、「CI環境は開発プロセス全体の基盤となる部分です。しかしセキュリティの確保や運用負荷の軽減が課題となる場合が多いです」と語り、とくにセキュリティ強化と効率化を両立する設計が必要であると語った。

CI環境の構築における最大の懸念はセキュリティリスクだ。CI環境はソースコードやシークレットキー、アクセスキーなどの重要なデータを含むため、マルウェアのターゲットになりやすい。またインターネット経由で外部パッケージを取得する運用では、パッケージ自体がマルウェアにすり替えられるリスクや、脆弱なパッケージを誤って使用してしまうリスクが伴う。このためCI環境ではインターネットアクセスを制限し、プラットフォームチームが管理するセキュアなリソースのみを利用可能にする仕組みが求められる。またランナーのバージョン管理や依存パッケージの更新、コンテナイメージのセキュリティ対応など、運用面での課題も多く、これらに対する適切な解決策が効率的なCI環境構築の鍵となる。

CI環境のアーキテクチャの例

山田氏は、こうした課題を解決するための具体的なアーキテクチャを提示した。「まずCI環境をAWSのVPC内に設置し、インターネットへのアクセスを遮断することが基本です」と説明した上で、GitHub ActionsのセルフホステッドランナーをKubernetesクラスター上にデプロイする方法を紹介。外部パッケージに起因するセキュリティリスクを大幅に低減し、また監査ログを収集して不審な挙動を早期に発見する振る舞い検知を実装することの重要性も指摘した。さらにこれらの監視データをツールで可視化する仕組みも説明された。これによりセキュリティの担保だけでなく、運用の効率化も実現するという。

さらに山田氏はCI環境のさらなる最適化に向けて、メトリクスを活用することの重要性を強調した。具体的には、ビルドにかかる時間や成功率、最後に成功したビルドからの経過日数、ビルド失敗から修正までに要した時間などのデータを収集することで、CIの効率を評価する基盤が整うと語った。これらの情報は開発チームに提供され、データドリブンで改善策を立案する際に活用される。山田氏は「メトリクスを活用することで、CI環境をさらに効率化し、開発スピードを向上させることができます」と語り、Platform Teamが提供すべき価値を具体的に示した。

CDにおける効率と安全性の実現

CDについて山田氏は「CDはPlatform Engineeringの中核を成す重要な要素であり、適切に設計されることで、開発チームは迅速かつ安全にアプリケーションをリリースできるようになります」と語った。

CD環境における主要な課題としては、権限管理と環境の一貫性が挙げられる。開発チームがデプロイ可能なリソースを適切に制限し、異なるチーム間での干渉を最小限に抑える必要がある一方で、環境間での整合性を確保することも求められる。とくに大規模な環境ではデプロイ競合や設定の不整合といったリスクが高まりやすく、これらに対応するための適切なガバナンスと運用設計が不可欠であると山田氏は指摘した。

こうした課題への対策として、山田氏はNamespace分離による権限管理を提案した。Argo CDを活用することで、Namespace単位で権限を分離し、各開発チームが管理可能なリソースを限定する仕組みを構築する。これによりチーム間の干渉を防ぎつつ、Namespaceごとに設定されたポリシーに基づいてリソースを管理できる。またNamespaceごとに収集されたログや監視データを活用すれば、デプロイに起因する問題の特定やトラブルシューティングも迅速化される。

権限管理された GitOps Pipeline

次に山田氏はスケーラブルなCD環境を構築するための手段として、カスタムコントローラーの活用について触れた。カスタムコントローラーを導入することで、特定のチームやリソースの要件に応じた柔軟な管理が可能になる。この仕組みは単に運用を効率化するだけでなく、環境全体の安定性と信頼性を向上させる役割も果たすと山田氏は説明した。

さらにデプロイの安全性を確保するための手法として、カナリアリリースやブルーグリーンデプロイメントの活用が提案された。これらの手法を用いることで、新しいリリースを段階的に展開し、問題が発生した際には迅速なロールバックの実行が可能になる。これにより開発チームはリリースに伴うリスクを最小限に抑えながら、新機能の導入を進められる。

Platform Engineeringの未来に向けて

山田氏は、「プラットフォームが成熟すればするほど、開発チームは安心してアプリケーション開発に集中できるようになります。その結果、組織全体の生産性が向上します」と言い、Platform Engineeringが技術的な課題解決にとどまらず、組織全体の競争力を高めるための戦略的な取り組みであることを強調した。

「本日の内容が、Platform Engineeringを実践する上での指針となれば幸いです。成熟度モデルやアーキテクチャ設計の考え方を活用し、皆さんのチームがさらに効率的かつ効果的に活動できることを願っています」と山田氏はセッションを締めくくった。