「プラットフォームエンジニアリング」の基礎と「Kubernetes」開発基盤の要点を整理する

はじめに

最近、「プラットフォームエンジニアリング」という言葉をよく耳にするようになりました。プラットフォームエンジニアリングは、近年の複雑化したソフトウェア開発における開発者体験や生産性の向上、ビジネス価値の迅速な提供を目指しています。

本連載では、プラットフォームエンジニアリングをスモールスタートからハンズオンで学べるように構成しています。第1回の今回は、その概要と「Kubernetes」を使用したスモールスタートでの技術的アプローチについて解説します。

プラットフォームエンジニアリングが
解決したい課題

現代のソフトウェア開発は、パブリッククラウドやIaC(Infrastructure as Code)の普及により、インフラ担当者がいなくてもプロダクトチームが簡単にプロダクトを立ち上げられるようになりました。しかし、その一方でプロダクトチームはプロダクトの開発だけでなく、インフラの構築、デプロイ、運用まで幅広い業務を担う必要が出てきました。

また、多くの組織には守るべきセキュリティやコンプライアンスの要件があります。プロダクトチームはそれらを守るため、セキュリティやコンプライアンスの専門家と連携し、必要な対策を講じる必要がありますが、多くの場合、プロダクトチームはそれらに多くの時間を費やすことになります。

このように、業務内容や使用するツールが多岐にわたり、学習コストが高くなる状態を「認知負荷が高い」と言います。

プラットフォームエンジニアリング導入前

認知負荷の高い状態を放置すると、プロダクトチームはインフラ管理やセキュリティ対策に追われ、プロダクト開発に集中できなくなります。仮に幅広い業務を完璧にこなせる「ドリームチーム」(すべての分野に精通した理想的なチーム)を作れたとしても、その方法は再現性が低く、組織全体で同じように適用するのは難しいでしょう。

また、昨今はマイクロサービスアーキテクチャを採用する組織が増えています。認知負荷が高い状態で開発速度や柔軟性を求めてマイクロサービスアーキテクチャを採用すると、以下のような問題が発生します。

• お互いのチームの状況が分からず、各チームが独自にライブラリの開発やセキュリティ対策を行うことになり、二重開発が発生する
• 各マイクロサービスのどこか1つでもセキュリティ的に脆弱だと、システム全体が危険にさらされる

プラットフォームエンジニアリングが
課題を解決する仕組み

プラットフォームエンジニアリングでは、プロダクトチームにプラットフォームを提供することでこれらの問題を解決します。プラットフォームには以下のような特性があります。

• インフラ、ミドルウェア、開発ツールなどを統合し、開発・デプロイ・運用に必要なツールを提供する
• プロダクトチームは必要な機能をセルフサービスで利用できる
• ドキュメントやサンプルが充実しており、開発者が簡単に利用できる
• APIのドキュメントやライブラリを共有するサービスカタログ機能を持ち、チーム間の情報共有を促進する
• 組織が定義したセキュリティやコンプライアンスをデフォルトで検証できるように設計されている

これにより、プロダクトチームはインフラやセキュリティの専門家に依存することなく、各チームが独立してプロダクトを開発できるようになります。このアプローチは、組織内のすべてのチームをハイレベルなドリームチームで構成するよりも再現性が高く、組織全体で生産性を向上させることができます。

プラットフォームエンジニアリング導入後

また、サービスカタログ機能によりチーム間の情報共有を促進し、作業の重複を減らします。さらに、デフォルトでセキュリティやコンプライアンスを検証することにより、セキュリティの考慮漏れやコンプライアンス違反のリスクを軽減できます。

プラットフォームチームとは

このプラットフォームを提供するのがプラットフォームチームです。プラットフォームチームは、プロダクトチームが必要とするインフラやツールを提供し、プロダクトチームがプロダクトの開発に集中できるようにサポートします。

そのために、プラットフォームチームは以下のことを行います。

• プロダクトチームのニーズを調査し、ロードマップを作成する
• 適切なツールやサービスを選定・構築し、運用する
• プロダクトチームからのフィードバックを受け取り、プラットフォームを改善する

これらは、プロダクト開発のようなプロセスだと感じた方も多いのではないでしょうか。まさにその通りです。プラットフォームチームはプラットフォームをプロダクトとして捉え、ユーザー(プロダクトチーム)の開発体験を向上させるために継続的に改善を行います。

プラットフォームの成熟度モデル

組織がプラットフォームエンジニアリングを導入する際、どのようなプラットフォームを目標とするのか、どのように計画を立てれば良いのかを考えるにあたり、CNCFが発行しているプラットフォームエンジニアリングの成熟度モデルを参考にすることが有効です。このモデルによると、プラットフォームの成熟度を表す5つの観点があり、それぞれに4つのレベルがあります。

• 投資：プラットフォームの機能に人員と資金がどれだけ割り当てられているか。専門のプラットフォームチームを持っているかなど
• 採用：プロダクトチームがどのようにプラットフォームを採用しているか。組織の推奨でプラットフォームを利用しているのか、それともプロダクトチームが自発的にプラットフォームを利用しているのか
• インターフェース：ユーザーがどのようにしてプラットフォームの機能と対話し、利用しているか
• 戦略：プラットフォームとその機能がどのように計画され、優先順位がつけられ、開発され、維持されているか
• 計測：どのようなプロセスでフィードバックを収集し、取り入れているか

この成熟度モデルから、組織が目指すべきプラットフォームのレベルを定義し、計画を立てることができます。また、定期的に評価し、自分たちが今どのレベルにいるのかを把握することもできます。成熟度モデルは、組織がプラットフォームエンジニアリングを導入する際の指針となるものです。

例えば、インターフェースのレベル3「スケーラブルである - セルフサービスのソリューション」を目標とする場合、プロダクトチームがセルフサービスで簡単にプラットフォームの機能を利用できるようにする必要があります。そのため、ユーザーのワンクリックでプラットフォームの機能がプロビジョニングされるような仕組みを設計しよう、などといった計画を立てることができます。

プラットフォームに
「Kubernetes」を利用する

本連載では、APIプラットフォームに「Kubernetes」を利用します。なぜKubernetesを利用することがAPIプラットフォームに適しているのでしょうか。その理由を解説していきます。

CNCFのプラットフォームホワイトペーパーによると、プラットフォームは必要に応じて開発者ポータル、ゴールデンパス、プラットフォームの機能を自動的にプロビジョニングするためのAPI、データサービス、CI/CDなど様々な機能を提供します。このうち、Kubernetesはプラットフォームの機能を自動的にプロビジョニングするためのAPIを実現します。Kubernetesを利用することで、各機能を自動的にプロビジョニングするための統一的なAPIを提供できます。 またKubernetesは多くのエコシステムを持ち、そのほかの機能もKubernetes上で実現できます。

これを聞いて「Kubernetesはコンテナしか扱えないから、プラットフォームとしては不十分だ」と考える方もいるかもしれません。確かに、素のKubernetesだけではコンテナオーケストレーターとしての機能しか持っていません。しかし、KubernetesはそのAPIを拡張することでデータベースやパイプライン、さらにはパブリッククラウドのリソースも管理できます。このKubernetesのAPIを拡張する機能を持つのがオペレーターです。オペレーターはKubernetes上で特定のプロダクトやサービスを自動的に管理するためのソフトウェア拡張です。オペレーターには以下の特徴があります。

• プロダクトのライフサイクル管理を自動化する
• ユーザーとのインターフェースにKubernetesのAPIを利用する

例えば、PostgreSQLのオペレーターだと「Cloud Native PG」があります。Cloud Native PGをKubernetesクラスタにインストールすれば、ユーザーは以下のようなマニフェストをkubectl applyでデプロイするだけでPostgreSQLのクラスターを作成・管理できます。マニフェストを作る必要があるため「ワンクリック」とまではいきませんが、他のサービスも同じ操作感で利用でき、さらにマニフェストをIaCで管理できるので、プロダクトチームの開発体験は大きく向上します。

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: example
spec:
  instances: 3
  storage:
    size: 1Gi

オペレーターを利用することで、プロダクトチームは簡単にプラットフォームの機能を利用でき、その管理もオペレーターに任せることができます。また、オペレーターで提供する機能はユーザーとのインターフェースがKubernetesのAPIに統一されるため、利用する機能で異なるツールを使い分ける必要が少なくなります。これによりプロダクトチームの認知負荷を軽減し、開発体験を向上させることができます。

また、他にもオペレーターを使うと以下のようなことが実現できます。

• Crossplaneを利用し、KubernetesのAPIを通じてパブリッククラウドのリソースを払い出す
• cert-manager、ArgoCDなどの強力なKubernetesエコシステムを利用できる。
• 組織独自のAPIを開発し、KubernetesのAPIを通じてリソースを管理する
  (例えば、Environmentというリソースを定義して検証環境や本番環境を払い出すなど)

以上のような理由から、Kubernetesをプラットフォームとして利用することで、以下のようなメリットがあります。

• プロダクトチームがセルフサービスでリソースを管理できる
• プロダクトチームが一貫した操作感でリソースを管理できる
• 拡張が容易で必要な機能を追加しやすい
• 強力なエコシステムを利用できる

Kubernetesを使うだけであれば、必ずしもプロダクトチームに高度なKubernetesの知識は必要ありません。しかし、プラットフォームチームはKubernetesの導入・運用や、さまざまなエコシステムの管理、場合によっては独自のオペレーター開発も求められるため、高度なクラウドネイティブ技術の専門性が必要です。もし社内に専門家がいない場合は、外部の専門家の協力を得て設計や実装を進めることも検討しましょう。

テナント分離の方法

プラットフォームは複数のプロダクトチームの共通基盤として機能するため、マルチテナント構成が必要です。それでは、各テナントをどのように分離するのでしょうか。

Kubernetesにおけるテナント分離の主な方法は次の3つです。

• Namespace分割：同一クラスター内でNamespaceを使い論理的に分離する。コストが低くテスト環境やスモールスタートに適するが、自由度は低め
• vCluster分割：vClusterを利用して同一クラスター内で仮想的なクラスターを作成する。仮想的ではあるがクラスターが分離されるため、プロダクトチームが独自にオペレーターを追加することも可能
• Cluster分割：新たにKubernetesクラスターを作成し、完全に分離する。リソースの独立性は最も高いがコストも高くなる。大規模プロダクト向き

vClusterのドキュメントに、それぞれの特性を比較した表があるので、以下に引用します。

状況に応じてこれらの手段を使い分けられるのが理想ですが、本連載ではスモールスタートとして導入コストの低いNamespace分割を採用し、解説を進めます。

ルーティングの方法

Namespaceごとにプロダクトチームが独立してプロダクトをデプロイできるようにするには、ルーティングの仕組みが必要です。Kubernetesには「Ingress」と「Gateway API」という2つのルーティング方式があります。

Ingressは従来の標準的なルーティング機能ですが、Gateway APIはIngressの次世代版として開発され、2023年10月にGAとなりました。Gateway APIは、より柔軟で拡張性の高いルーティングを実現します。

マルチテナント構成では、以下の理由からGateway APIの利用をおすすめします。

• プラットフォームチームとプロダクトチームの役割分担が明確になる
• プラットフォームチームが共通のレートリミットやセキュリティポリシーをGateway API経由で適用できる

Gateway APIの主なリソースは以下の通りです。

• Gateway：Gateway APIのリソースでGatewayごとにNGINXやEnvoyなどのリバースプロキシが作成される。プラットフォームチームが管理し、Gatewayに共通のレートリミットやセキュリティポリシーを適用することで、組織のセキュリティ要件を満たすことができる
• HTTPRoute：Gateway APIでルーティングを定義するリソースで、プロダクトチームが管理する

Gateway API

まとめ

今回は、プラットフォームエンジニアリングの概要と、スモールスタートで始める場合の技術的アプローチについて解説しました。プラットフォームエンジニアリングはまだ新しい分野であり、今後も進化していくことが期待されます。プラットフォームエンジニアリングを導入することで、プロダクトチームはインフラやセキュリティの専門家に依存せず、独立してプロダクトを開発できるようになります。これにより、開発者体験や開発生産性の向上、ビジネス価値の迅速な提供が可能となります。

本記事では技術的な観点からプラットフォームエンジニアリングについて解説しましたが、プラットフォームエンジニアリングでは技術だけでなく、組織としての戦略も非常に重要です。少し抽象的ではありますが、組織的観点からもプラットフォームエンジニアリングを学びたい方には、以下の参考文献をおすすめします。

• CNCFプラットフォームホワイトペーパー：プラットフォームエンジニアリングの概要やプラットフォームに必要な機能、成果の測定など、全体像を理解するのに役立つ
• プラットフォームエンジニアリングの成熟度モデル：プラットフォームエンジニアリングの成熟度を評価するためのモデル。組織の目標や計画を策定する際に役立つ

次回以降は、プラットフォームエンジニアリングの具体的な実装をハンズオン形式で解説していきます。