ストーリー
田
田中VPoE
セルフサービス設計、API駆動、Kubernetes抽象化、GitOps。設計の道具は揃った。実際にCloudOps社のセルフサービスプラットフォームを設計してもらう
あなた
Step 1で分析したCloudOps社のシナリオの続きですね
あ
田
田中VPoE
そうだ。セルフサービス率を15%から80%に引き上げるための具体的なアーキテクチャを設計してくれ。カタログ設計からAPI設計、GitOpsフローまで一気通貫で
田
田中VPoE
開発者が「これは使いたい」と思うプラットフォームにしてくれ。技術的に正しいだけでなく、開発者体験が優れていることが重要だ
ミッション概要
| 項目 | 内容 |
|---|
| 演習タイトル | セルフサービスプラットフォームの設計 |
| 想定時間 | 90分 |
| 成果物 | プラットフォームアーキテクチャ設計書 |
| 対象組織 | CloudOps社(Step 1から継続) |
Mission 1: セルフサービスカタログの設計
要件
CloudOps社の25マイクロサービスを支えるセルフサービスカタログを設計してください。
- カタログアイテムを最低8種類定義する
- 各アイテムのパラメータ、ガードレール、所要時間目標を明記する
- 優先順位を付け、Phase 1(3ヶ月)でリリースするアイテムを選定する
解答例
カタログ一覧
| # | カテゴリ | アイテム | Phase | 所要時間目標 |
|---|
| 1 | サービス | 新規マイクロサービス一式 | Phase 1 | 10分 |
| 2 | データベース | PostgreSQL | Phase 1 | 5分 |
| 3 | データベース | Redis | Phase 1 | 3分 |
| 4 | コンピュート | Kubernetesネームスペース | Phase 1 | 1分 |
| 5 | CI/CD | GitHub Actionsパイプライン | Phase 1 | 3分 |
| 6 | ストレージ | S3バケット | Phase 2 | 1分 |
| 7 | メッセージング | SQSキュー | Phase 2 | 1分 |
| 8 | 監視 | Datadogダッシュボード + アラート | Phase 2 | 2分 |
| 9 | ネットワーク | 内部DNSエントリ | Phase 2 | 30秒 |
| 10 | セキュリティ | Vaultシークレットパス | Phase 2 | 1分 |
Phase 1アイテム詳細: 新規マイクロサービス一式
| パラメータ | 型 | 必須 | バリデーション |
|---|
| service_name | string | はい | ^[a-z][a-z0-9-]{2,30}$ |
| team_name | enum | はい | 登録チーム一覧から選択 |
| language | enum | はい | typescript, python, go |
| template | enum | はい | api-service, worker, bff |
| size | enum | はい | small, medium, large |
| database | boolean | いいえ | デフォルト: false |
ガードレール:
- production環境は最低2レプリカ
- ヘルスチェックエンドポイント必須
- NetworkPolicy自動適用
- Datadogモニタリング自動設定
要件
カタログを支えるPlatform APIを設計してください。
- 主要エンドポイントを最低8つ定義する
- 各エンドポイントのリクエスト/レスポンスを記述する
- 認証・認可の設計を行う
解答例
API一覧
| メソッド | パス | 説明 | 認可 |
|---|
| GET | /api/v1/catalog | カタログ一覧 | 全員 |
| GET | /api/v1/catalog/{item_id} | カタログ詳細 | 全員 |
| POST | /api/v1/resources | リソース作成 | Developer以上 |
| GET | /api/v1/resources | リソース一覧(自チーム) | Developer以上 |
| GET | /api/v1/resources/{id} | リソース詳細 | Developer以上 |
| DELETE | /api/v1/resources/{id} | リソース削除 | Team Lead以上 |
| POST | /api/v1/resources/{id}/approve | リソース承認 | Team Lead以上 |
| GET | /api/v1/teams/{team}/costs | チームコスト | Team Lead以上 |
| POST | /api/v1/templates/render | テンプレートプレビュー | Developer以上 |
| GET | /api/v1/health | ヘルスチェック | 認証不要 |
リソース作成のフロー
POST /api/v1/resources
Authorization: Bearer <jwt_token>
Content-Type: application/json
{
"catalog_item": "microservice",
"parameters": {
"service_name": "notification-service",
"team_name": "platform-team",
"language": "typescript",
"template": "api-service",
"size": "medium",
"database": true
}
}
Response: 202 Accepted
{
"resource_id": "res-a1b2c3d4",
"status": "provisioning",
"steps": [
{ "name": "リポジトリ作成", "status": "completed" },
{ "name": "CI/CDパイプライン設定", "status": "in_progress" },
{ "name": "Kubernetesリソース作成", "status": "pending" },
{ "name": "データベース作成", "status": "pending" },
{ "name": "モニタリング設定", "status": "pending" }
],
"estimated_completion": "2026-03-04T10:10:00Z"
}
認証・認可
| 方式 | 対象 | トークン有効期限 |
|---|
| OAuth 2.0 + JWT | Webポータル | 1時間 |
| APIキー | CI/CD、自動化 | 90日(ローテーション) |
| ServiceAccount | 内部サービス | Kubernetes管理 |
Mission 3: GitOpsフローの設計
要件
CloudOps社のGitOpsフローを設計してください。
- リポジトリ構成を設計する
- プロモーションフロー(dev → staging → production)を設計する
- ロールバック手順を定義する
解答例
リポジトリ構成
アプリリポジトリ(8チーム × 各3-4リポジトリ):
{service-name}/
├── src/
├── Dockerfile
├── platform.yaml # Application CRD
└── .github/workflows/
└── ci.yaml # テスト→ビルド→プッシュ
GitOpsリポジトリ(プラットフォームチーム管理):
cloudops-gitops/
├── base/
│ ├── platform-defaults.yaml
│ └── security-policies/
├── environments/
│ ├── dev/
│ │ ├── payment-service/app.yaml
│ │ ├── user-service/app.yaml
│ │ └── ...(25サービス)
│ ├── staging/
│ │ └── ...
│ └── production/
│ └── ...
├── infrastructure/
│ ├── argocd/
│ ├── cert-manager/
│ └── monitoring/
└── argocd-apps/
└── applicationsets.yaml
プロモーションフロー
| ステージ | トリガー | 承認 | 自動テスト |
|---|
| dev | イメージプッシュ | 不要(自動) | スモークテスト |
| staging | devテスト成功 | 不要(自動PR) | E2Eテスト、負荷テスト |
| production | stagingテスト成功 | Team Lead承認必須 | カナリーリリース |
ロールバック手順
| 方法 | 手順 | 所要時間 |
|---|
| git revert | GitOpsリポジトリで前のコミットをrevert | 3分 |
| Argo CD UI | Historyから前のリビジョンを選択してSync | 1分 |
| 自動ロールバック | カナリーリリースのメトリクス悪化で自動発動 | 即座 |
達成度チェック
| 観点 | 達成基準 |
|---|
| カタログ設計 | 8種類以上のアイテムが定義され、パラメータとガードレールがある |
| API設計 | RESTfulなAPI設計で、認証・認可が定義されている |
| GitOpsフロー | リポジトリ構成、プロモーション、ロールバックが設計されている |
| 実現可能性 | CloudOps社の規模と技術スタックに適合した設計になっている |
| 開発者体験 | 開発者の認知負荷が軽減される設計になっている |
推定所要時間: 90分