CNPA — クラウドネイティブプラットフォームエンジニアリングアソシエイト
プラットフォームの成熟度とIDPの構成要素
一言でいうと
内部開発者プラットフォーム(IDP)は、ポータル1つではなく5つのプレーン(plane)が集まったものです。そして成熟度は、ツールの数ではなく「誰がどのように決定し、何で測るか」で上がっていきます。
なぜ必要なのか
「IDPを導入しよう」という話が出ると、たいていはポータル製品を選ぶ会議から始まります。しかしポータルはIDPの表面にすぎません。その下に、実際に何かを作って動かす層がなければ、ポータルはリンク集になります。どの部品が必要かを先に描いてこそ、何が足りないかが見えてきます。
どう動くのか
IDPの5つのプレーン
CNCFのプラットフォームホワイトペーパーが整理した区分を、実務の言葉に置き換えると次のようになります。
| プレーン | 役割 | よくある実装 |
|---|---|---|
| Developer Control Plane | 開発者が触れる表面です | ポータル(Backstage)、CLI、リポジトリテンプレート、マニフェストの抽象化 |
| Integration & Delivery | ビルドしてデプロイします | CI、イメージレジストリ、GitOpsエージェント、Secretオペレーター |
| Monitoring & Logging | 何が起きているかを見ます | メトリクス、ログ、トレース、ダッシュボード、アラート |
| Security | アイデンティティとポリシーを扱います | 認証・認可、ポリシーエンジン、イメージの署名・スキャン |
| Resource Plane | 実際のリソースです | クラスター、ノード、ネットワーク、ストレージ、データベース |
ここに2つの軸が横断します。APIとインターフェース(各プレーンをどう呼び出すか)と、ケイパビリティの提供(capabilities)です。試験で「ポータルはIDPそのものか」と問われたら、答えはいいえで、ポータルはDeveloper Control Planeの1つの実装にすぎません。
成熟度の段階
数字よりも、各段階の症状を覚えるほうが問題を解くうえで有利です。
- 暫定(Provisional): チームごとにスクリプトがばらばらです。新しいサービスを1つ立ち上げるのに数日かかります。知識は人の頭の中にあります。
- 運用(Operational): 共通のスクリプトとドキュメントができます。それでもプラットフォームチームがチケットを受け付けて代行します。ボトルネックは人です。
- スケーラブル(Scalable): セルフサービスになります。開発者がチケットなしで自分でプロビジョニングします。プラットフォームチームはリクエスト処理ではなく、機能開発を行います。
- 最適化(Optimizing): 利用データとユーザーフィードバックで、プラットフォーム自体を改善します。廃止やマイグレーションが計画的に行われます。
段階を分ける本当の基準は、「チケットが必要か」です。第2段階と第3段階の間に崖があり、ほとんどの組織がここで止まります。自動化はしたのに、実行ボタンをプラットフォームチームしか押せないなら、依然として第2段階です。
セルフサービスが成立するには
セルフサービスは、「権限を与える」だけではありません。3つが同時に必要です。
- 安全なデフォルト値: 何も指定しなくても、リソース制限、セキュリティコンテキスト、オブザーバビリティが付きます。
- 境界: 他人のネームスペースに触れられず、クラスター全体を壊すこともできません。
- 速いフィードバック: 間違って書くと、すぐに人が読める言葉で拒否されます。30分後にパイプラインのログ900行で知らせるようでは、セルフサービスではありません。
3つ目が特に重要です。Kubernetesでは、これはそのままスキーマ検証です。CRDのOpenAPIスキーマにmaximum: 10を入れておけば、APIサーバーが即座に拒否します。ポリシーエンジンのWebhookも同じ役割を果たします。
現場での姿
筆者がホームラボの上に作っているものは、まさに第3段階を目指す試みです。受講生がボタンを押すとラボ用Podが起動し、採点を受け、終わったら消えるシステムです。ここに、プラットフォームの視点からの要求がそのまま表れています。ラボ用Podは他人のPodを見られてはならず(境界)、リソースを際限なく使えてはならず(ガードレール)、何も設定しなくても必要なツールが入っていなければならず(安全なデフォルト値)、終わったら自分で消えなければなりません(ライフサイクル)。
そして、その下のクラスターには、次のような制約がすでに存在します。コントロールプレーン3台でetcdのクォーラムは確保できていますが、controlPlaneEndpointが最初のノードの物理IPに固定されているため、そのノードが落ちるとAPIへのアクセスが途切れます。GPUは24GB・32GB・8GB(2枚)と等級がばらばらなので、nvidia.com/gpu: 1だけを要求すると、見当違いのカードに載ってしまいます。そのため、gpu.homelab/tierのような意味ベースのラベルを人が定義して付ける必要がありました。
これがプラットフォームAPI設計の出発点です。物理的な事実(GPUカードのモデル)をそのまま公開せず、開発者が理解できる語彙(tier=xlarge)に翻訳してあげること、それが抽象化であり、次のモジュールのテーマです。
次のクイズで確認すること
次のモジュールでは、CRDでWebServiceというプラットフォームAPIを自分で作ります。スキーマで不正な値を即座に拒否し、サーバーがデフォルト値を補い、ネームスペース・ResourceQuota・LimitRangeでテナントの境界を引き、RBACでセルフサービスの権限を与える、という一式を実際のクラスターで完成させます。