ストーリー
田
田中VPoE
Step 2でセルフサービスプラットフォームの裏側を設計した。ここからは開発者が実際に触る「表側」だ。Internal Developer Portal(IDP)を構築する
田
田中VPoE
単なるWebポータルではない。IDPはプラットフォームのすべてを統合する「開発者のためのワンストップショップ」だ。サービスカタログ、ドキュメント、API仕様、テンプレート、環境情報、メトリクス。開発者が必要とするすべてを一箇所に集約する
あなた
今は情報が散在していて、Confluenceにドキュメントがあったり、Datadogにメトリクスがあったり、Jiraにチケットがあったりして、情報を探すのに時間がかかります
あ
田
田中VPoE
その「情報の分散」が認知負荷の大きな原因だ。IDPは分散したツールを統合するのではなく、それぞれのツールへの「入り口」を一元化する。Googleで何でも検索できるように、IDPから何でもアクセスできる状態を目指す
IDPとは何か
IDPの構成要素
| コンポーネント | 役割 | 例 |
|---|
| サービスカタログ | 組織のすべてのサービスとその情報を一覧管理 | オーナー、API仕様、依存関係、SLO |
| ソフトウェアテンプレート | 新規サービスをワンクリックで作成 | テンプレート選択→パラメータ入力→自動生成 |
| テックドキュメント | ドキュメントの一元的なアクセスポイント | TechDocs(docs-as-code) |
| セルフサービスカタログ | インフラリソースのセルフサービス作成 | DB作成、環境構築 |
| 検索 | 横断的な情報検索 | サービス名、API、ドキュメント |
IDPの価値
IDPが解決する課題:
Before(IDP導入前):
「payment-serviceのAPIオーナーは誰?」
→ Confluenceを検索 → 見つからない → Slackで聞く → 30分
「新しいサービスを作りたい」
→ 過去のリポジトリをコピー → CI/CD設定 → インフラチケット → 3日
「staging環境のpostgresの接続情報は?」
→ VaultのUI → パスがわからない → 先輩に聞く → 20分
After(IDP導入後):
「payment-serviceのAPIオーナーは誰?」
→ IDPでサービス名を検索 → 即座に表示 → 10秒
「新しいサービスを作りたい」
→ IDPでテンプレート選択 → パラメータ入力 → 全自動 → 10分
「staging環境のpostgresの接続情報は?」
→ IDPのサービス詳細ページ → Resources タブ → 即座に表示 → 10秒
IDPの市場動向
主要なIDPソリューション
| ソリューション | タイプ | 特徴 | コスト |
|---|
| Backstage | OSS | CNCF、Spotifyが開発、プラグインエコシステム | 無料(運用コスト) |
| Port | SaaS | ノーコードでカスタマイズ、迅速な導入 | 有料 |
| Cortex | SaaS | サービス品質スコアカード、成熟度追跡 | 有料 |
| OpsLevel | SaaS | サービスオーナーシップ、成熟度チェック | 有料 |
| Humanitec | PaaS | スコアベースのプラットフォーム抽象化 | 有料 |
| 自社構築 | カスタム | 完全なカスタマイズ、組織固有の要件対応 | 高(開発コスト) |
選定基準
| 基準 | 重み | Backstage | SaaS型IDP | 自社構築 |
|---|
| カスタマイズ性 | 高 | 高(プラグイン) | 中 | 最高 |
| 初期導入コスト | 高 | 低(OSS) | 中(ライセンス) | 高 |
| 運用コスト | 中 | 中(自前運用) | 低(SaaS) | 高 |
| エコシステム | 中 | 大(700+プラグイン) | 限定的 | なし |
| 導入速度 | 中 | 中(1-3ヶ月) | 高(数週間) | 低(6ヶ月以上) |
| コミュニティ | 低 | 大(CNCF) | なし | なし |
「CloudOps社の規模(60名、25サービス)であれば、Backstageが最もバランスが良い。SaaSはコストが高すぎ、自社構築は開発コストが高すぎる」 — 田中VPoE
IDPのアーキテクチャ
全体構成
IDP アーキテクチャ:
┌─────────────────────────────────┐
│ Developer Portal │
│ (Backstage フロントエンド) │
│ ┌─────┬──────┬──────┬────────┐ │
│ │カタ │テン │ドキュ│サービス│ │
│ │ログ │プレート│メント│カタログ│ │
│ └──┬──┴──┬───┴──┬───┴───┬────┘ │
└─────┼─────┼──────┼───────┼──────┘
│ │ │ │
┌─────▼─────▼──────▼───────▼──────┐
│ Backstage Backend │
│ ┌─────────────────────────────┐ │
│ │ Plugin System │ │
│ │ ┌────┬────┬────┬────┬───┐ │ │
│ │ │K8s │Git │CI/ │Data│Vault│ │
│ │ │ │Hub │CD │dog │ │ │ │
│ │ └──┬─┴──┬─┴──┬─┴──┬─┴─┬─┘ │ │
│ └─────┼────┼────┼────┼───┼────┘ │
└────────┼────┼────┼────┼───┼──────┘
│ │ │ │ │
┌────▼┐┌──▼─┐┌─▼──┐┌▼──┐┌▼───┐
│EKS ││Git ││GH ││DD ││Vault│
│ ││Hub ││Act.││ ││ │
└─────┘└────┘└────┘└───┘└────┘
データフロー
| データ | ソース | 更新頻度 |
|---|
| サービス情報 | catalog-info.yaml(各リポジトリ) | Gitプッシュ時 |
| API仕様 | OpenAPI spec(各リポジトリ) | Gitプッシュ時 |
| デプロイ状況 | Argo CD / GitHub Actions | リアルタイム |
| メトリクス | Datadog | リアルタイム |
| ドキュメント | docs/(各リポジトリ) | Gitプッシュ時 |
| コスト | AWS Cost Explorer | 日次 |
| シークレット | Vault | リアルタイム |
IDP導入のロードマップ
段階的導入計画
| フェーズ | 期間 | 機能 | 目標 |
|---|
| Phase 1 | 1-2ヶ月 | サービスカタログ + 検索 | 全サービスの可視化 |
| Phase 2 | 3-4ヶ月 | ソフトウェアテンプレート + TechDocs | 新規サービス作成の自動化 |
| Phase 3 | 5-6ヶ月 | セルフサービスカタログ + メトリクス統合 | セルフサービス率80% |
まとめ
| ポイント | 内容 |
|---|
| IDP | 開発者に必要なすべての情報とツールへのワンストップアクセスを提供 |
| 5つのコンポーネント | サービスカタログ、テンプレート、ドキュメント、セルフサービス、検索 |
| ツール選定 | Backstage(OSS)、Port/Cortex(SaaS)、自社構築を比較検討 |
| 段階的導入 | サービスカタログ → テンプレート → セルフサービスの順に導入 |
チェックリスト
次のステップへ
次は「Backstageの導入」を学びます。CNCFのIDPフレームワークであるBackstageの具体的な導入方法を身につけましょう。
推定読了時間: 30分