ストーリー

抽象化レイヤーの設計原則

3つの原則

抽象化の4つのレベル

レベル別の対象

L1: IaCレイヤーの抽象化

Terraformによるマルチクラウドの構成例:

terraform/
├── modules/
│   ├── compute/         # クラウド非依存のコンピュート定義
│   │   ├── aws/         # AWS固有の実装
│   │   ├── gcp/         # GCP固有の実装
│   │   └── azure/       # Azure固有の実装
│   ├── database/        # データベース定義
│   │   ├── aws/
│   │   ├── gcp/
│   │   └── azure/
│   └── network/         # ネットワーク定義
│       ├── aws/
│       ├── gcp/
│       └── azure/
├── environments/
│   ├── production/
│   │   ├── aws.tf       # AWS本番環境
│   │   └── gcp.tf       # GCP本番環境（データ分析）
│   └── staging/
└── variables.tf         # 共通変数

L2: コンテナ/Kubernetesレイヤーの抽象化

Kubernetesはマルチクラウドにおける最も強力な抽象化レイヤーです。

マルチクラウドKubernetesの構成:

                    GitOps (ArgoCD / Flux)
                         │
         ┌───────────────┼───────────────┐
         │               │               │
    EKS (AWS)       GKE (GCP)       AKS (Azure)
    ├── App A       ├── Analytics    ├── Auth
    ├── App B       └── ML Pipeline  └── EU Apps
    └── App C
         │               │               │
    ┌────┴────┐    ┌────┴────┐    ┌────┴────┐
    │ Aurora  │    │ BigQuery│    │Entra ID │
    │ S3     │    │ GCS    │    │Blob     │
    └─────────┘    └─────────┘    └─────────┘

L3: アプリケーションレイヤーの抽象化

アプリケーション層の抽象化パターン:

// ストレージの抽象化例
interface CloudStorage {
  upload(key: string, data: Buffer): Promise<string>;
  download(key: string): Promise<Buffer>;
  delete(key: string): Promise<void>;
  getSignedUrl(key: string, expiry: number): Promise<string>;
}

class S3Storage implements CloudStorage { ... }
class GCSStorage implements CloudStorage { ... }
class AzureBlobStorage implements CloudStorage { ... }

// ファクトリーパターンで切替
class StorageFactory {
  static create(provider: 'aws' | 'gcp' | 'azure'): CloudStorage {
    switch (provider) {
      case 'aws': return new S3Storage();
      case 'gcp': return new GCSStorage();
      case 'azure': return new AzureBlobStorage();
    }
  }
}

抽象化すべきもの vs すべきでないもの

L4: データレイヤーの抽象化

まとめ

チェックリスト

• 抽象化レイヤーの3つの設計原則を理解した
• 4つのレベルの抽象化対象を理解した
• 抽象化すべきもの・すべきでないものの判断基準を理解した
• Kubernetesを中心としたマルチクラウド構成を理解した

次のステップへ

次は「演習：ワークロード配置マップを作成しよう」で、学んだフレームワークを使って実際のワークロード配置を設計します。

推定読了時間: 30分