統合設計と相互運用性 - L0 カリキュラム

ストーリー

田

田中VPoE

プラットフォーム戦略の全体像は描けた。だが、プラットフォーム同士がバラバラに動いていたら意味がない

あなた

統合が重要ということですね。でも、各プラットフォームは別チームが運用しますよね？

あ

田

田中VPoE

だからこそ「統合設計」が必要だ。Month 5でマイクロサービスの通信パターンを学んだが、プラットフォーム間も同じだ。どのデータがどう流れるか、イベントがどう伝播するか。ここを設計しないと、プラットフォーム自体がサイロ化する

あなた

プラットフォームのサイロ化…それは本末転倒ですね

あ

統合設計のフレームワーク

データフローマップ

開発者がコードをPush
    │
    ↓
┌──────────────────────────────────────────────────┐
│ CI/CDパイプライン（GitHub Actions）                 │
│                                                    │
│  [Build] → [Test] → [SAST/SCA] → [Container] →   │
│                          ↑                         │
│                          │                         │
│                  セキュリティPF                      │
│                  (ポリシーチェック)                   │
│                                                    │
│  → [Deploy to Staging] → [DAST] → [Deploy to Prod]│
│                                        │           │
└────────────────────────────────────────┼───────────┘
                                         │
                           ┌─────────────┘
                           ↓
                  ┌─────────────────┐
                  │ オブザーバビリティPF │
                  │ (デプロイイベント   │
                  │  メトリクス収集    │
                  │  SLI/SLO計測)    │
                  └────────┬────────┘
                           │
                           ↓
                  ┌─────────────────┐
                  │ データPF          │
                  │ (デプロイメトリクス │
                  │  品質データ        │
                  │  ビジネスメトリクス) │
                  └────────┬────────┘
                           │
                           ↓
                  ┌─────────────────┐
                  │ AI/ML PF         │
                  │ (異常検知モデル    │
                  │  予測分析         │
                  │  レコメンデーション)│
                  └─────────────────┘

イベント駆動統合

event_catalog:
  deployment_events:
    - event: "deployment.started"
      producer: "CI/CD Platform"
      consumers:
        - "Observability Platform: デプロイ追跡開始"
        - "Security Platform: 変更監査ログ記録"

    - event: "deployment.completed"
      producer: "CI/CD Platform"
      consumers:
        - "Observability Platform: カナリアメトリクス監視開始"
        - "Data Platform: デプロイメトリクス記録"

    - event: "deployment.rollback"
      producer: "CI/CD Platform"
      consumers:
        - "Observability Platform: ロールバックアラート"
        - "Security Platform: インシデントチケット自動起票"

  security_events:
    - event: "vulnerability.detected"
      producer: "Security Platform"
      consumers:
        - "CI/CD Platform: パイプラインブロック判定"
        - "IDP: 開発者への通知"
        - "Data Platform: 脆弱性トレンド記録"

    - event: "policy.violation"
      producer: "Security Platform"
      consumers:
        - "CI/CD Platform: デプロイブロック"
        - "Observability Platform: アラート発火"

  observability_events:
    - event: "slo.budget_exhausted"
      producer: "Observability Platform"
      consumers:
        - "CI/CD Platform: デプロイ凍結"
        - "IDP: チームへのフリーズ通知"

    - event: "anomaly.detected"
      producer: "AI/ML Platform"
      consumers:
        - "Observability Platform: アラート発火"
        - "Security Platform: セキュリティ評価"

認証・認可の統合設計（Month 4の知見）

ゼロトラスト統合モデル

┌─────────────────────────────────────────┐
│          Identity Provider (IdP)         │
│          (Okta / Azure AD)              │
└──────────────────┬──────────────────────┘
                   │ OIDC/SAML
    ┌──────────────┼──────────────────┐
    ↓              ↓                  ↓
┌────────┐  ┌─────────────┐  ┌────────────┐
│ IDP    │  │ サービス     │  │ クラウド     │
│ (Web)  │  │ メッシュ     │  │ コンソール   │
│        │  │ (mTLS)      │  │ (SSO)       │
└────────┘  └─────────────┘  └────────────┘
    ↓              ↓                  ↓
┌──────────────────────────────────────────┐
│       Policy Engine (OPA/Cedar)          │
│  ┌──────────────────────────────┐        │
│  │ who + what + where + when    │        │
│  │ = allow / deny               │        │
│  └──────────────────────────────┘        │
└──────────────────────────────────────────┘

プラットフォームごとのアクセス制御

プラットフォーム	認証方式	認可モデル	ポリシー管理
IDP（Backstage）	OIDC via Okta	RBAC	Backstage権限プラグイン
CI/CD	GitHub App + OIDC	Repository権限	GitHub Branch Protection
クラウド	IAM + OIDC Federation	ABAC	Terraform + OPA
データ	OIDC + データカタログ	列レベルアクセス制御	Apache Ranger / Lake Formation
AI/ML	OIDC	プロジェクト単位RBAC	MLflowアクセス制御

標準API設計

プラットフォーム間API仕様

platform_apis:
  idp:
    base_url: "https://platform.internal/api/v1"
    endpoints:
      - "POST /services": "新サービスの作成"
      - "GET /services/{id}": "サービス情報の取得"
      - "GET /catalog": "サービスカタログの一覧"
      - "POST /environments": "環境のプロビジョニング"

  security:
    base_url: "https://security.internal/api/v1"
    endpoints:
      - "POST /scan": "セキュリティスキャンの実行"
      - "GET /vulnerabilities/{service}": "脆弱性一覧"
      - "GET /compliance/{standard}": "コンプライアンス状態"
      - "POST /policy/evaluate": "ポリシー評価"

  observability:
    base_url: "https://observability.internal/api/v1"
    endpoints:
      - "GET /slo/{service}": "SLO状態の取得"
      - "POST /alerts": "アラートルールの作成"
      - "GET /metrics/{service}": "メトリクスの取得"
      - "POST /incidents": "インシデントの起票"

  data:
    base_url: "https://data.internal/api/v1"
    endpoints:
      - "GET /catalog/datasets": "データセット一覧"
      - "GET /quality/{dataset}": "データ品質スコア"
      - "POST /pipelines": "パイプラインの作成"
      - "GET /lineage/{dataset}": "データリネージュ"

相互運用性のテスト戦略

統合テストの設計

テストレベル	対象	手法	頻度
コントラクトテスト	プラットフォーム間API	Pact / OpenAPI検証	PR毎
統合テスト	イベント駆動連携	テストイベント発火・検証	日次
E2Eテスト	開発者ジャーニー全体	サービス作成→デプロイ→監視まで	週次
カオスエンジニアリング	プラットフォーム障害時の影響	Chaos Monkey / Litmus	月次

まとめ

ポイント	内容
データフロー	コードPushからデプロイ、監視、分析までのデータの流れを設計
イベント駆動	プラットフォーム間はイベントで疎結合に連携
ゼロトラスト統合	統一IdPとPolicy Engineで全プラットフォームの認証認可を統合
標準API	各プラットフォームはRESTful APIで機能を公開
テスト戦略	コントラクトテストからカオスエンジニアリングまで多層的に検証

チェックリスト

プラットフォーム間のデータフローを設計できる
イベント駆動統合のイベントカタログを定義できる
ゼロトラスト統合モデルを理解した
標準API設計の考え方を把握した
統合テスト戦略を理解した

次のステップへ

次は「技術標準とガバナンス」を学びます。設計した目標アーキテクチャを組織全体で一貫して実現するための標準化とガバナンスの仕組みを整えましょう。

推定読了時間: 30分