前回、ハイブリッド構成の必然性と2つのモデル（エンタープライズ型/リーンモダナイズ型）を定義しました。

今回から、クラウド側のフロントエンドを構成するコンピューティング基盤の深掘りに入ります。フロントのコンピュート選定は—スケール、運用負荷、コストの3点で即座に差が出るため、最初に決めるべき最重要項目です。

本記事では、IaaS（VM）、PaaS（コンテナ）、FaaS（サーバーレス）の3モデルを比較し、ハイブリッド環境で最適なモデルを選択する判断軸を提供します。

TL;DR — レガシー・高制御が必要ならVM、汎用Web/マイクロサービスはコンテナ、短時間バーストやイベント処理はサーバーレス。ハイブリッドではコンテナが最もバランスが良いが、運用体制によってはVMやFaaSを併用する。

補足: ハイブリッド構成では「オンプレとクラウド間の接続方式」が制約になるため、データ往復のレイテンシと帯域要件を必ず先に確認する。

簡易チェックリスト:

「既存を完全制御したい」→ VM

「速く開発・頻繁にデプロイしたい」→ コンテナ/Cloud Run

「イベント駆動でコスト最小化」→ FaaS

ワークロードに適したコンピューティングモデルの選択軸

この節を読めば：どのモデルが、あなたのプロジェクトに適しているか、管理責任とコストから判断できます。

クラウドにおけるコンピューティング選定の基本は、「どこまでをクラウドプロバイダーに任せるか」、つまり管理責任の境界線で考えることです。

実行課金はFaaSが最も有利（短時間バースト）、VMは固定コスト優位（常時稼働）、PaaSは中間（予約と実行を組合せ）です。

モデル	技術例	管理責任範囲（ユーザー側）	初期/固定費	運用工数
IaaS (VM)	Google Cloud Compute Engine	OS以下、全て	高め（予約可能）	高
PaaS (Container)	Google Cloud Cloud Run/GKE	アプリケーション、データ	中	中〜高（K8s次第）
FaaS (Serverless)	Google Cloud Cloud Functions	アプリケーションコードのみ	低	低

VM（IaaS）: カスタム制御が必要な場合に適していますが、パッチ適用やOS管理など、運用負荷が最も高くなります。
コンテナ（PaaS）: OS管理から解放され、ポータビリティとスケーラビリティに優れます。マイクロサービスや高頻度リリースの標準モデルです。
サーバーレス（FaaS）: 実行時間・メモリで課金され、短時間処理ではコスト効率が高い一方、制約（実行時間・Cold start・ベンダー依存）があります。

コンテナ技術のメリットとサーバーレス採用時の注意点

この節を読めば：コンテナを採用する本質的な理由と、FaaSで設計ミスを避けるための注意点を理解できます。

エンタープライズ型、リーンモダナイズ型のどちらも、フロントエンドはコンテナ技術が最もバランスに優れています。

コンテナ採用の主要メリット
- ポータビリティと信頼性: 開発環境から本番環境まで動作の一貫性が保証される。
- リソース効率: VMより軽量で起動が速く、リソース効率と迅速なスケールアウトに優れる。
- マイクロサービス: サービス単位の独立性が高まり、開発とリリース頻度が向上する。
サーバーレス（FaaS）採用時の注意点
現場で後悔しやすい、FaaS特有の制約を設計時に必ず考慮してください。
- Cold start: 一定時間アクセスがないと起動に時間がかかり、レイテンシ要件に影響します。
  - Cold start の緩和：プロビジョンド・コンカレンシー／ウォームアップ関数／最小インスタンス設定を検討する。
  - ※Cloud Run でも min_instances によりCold startを実質回避可能（ただし常時課金が発生する）。
- 実行時間制限: 処理には時間制限があるため、長時間処理（バッチなど）は不向きであり、別設計が必要です。
- ベンダーロック: プロバイダ特有のサービス連携が多いため、移行を考慮した設計が必要です。

IaC実践: コンテナPaaSを含む基本コンピュートリソースの定義

この節を読めば：Terraformを使って、軽量コンテナ（Cloud Run）とサーバーレス（Cloud Functions）の最小構成をすぐ試せます。

以下では「Cloud Run」「Cloud Functions」「Serverless VPC Connector」という、ハイブリッド構成で最初に定義すべき3要素の最小例を示します。

# 例: Cloud Run (コンテナ PaaS) の最小構成断片
resource "google_cloud_run_v2_service" "svc" {
  name     = "my-lean-app"
  location = "asia-northeast1"

  template {
    containers {
      image = "gcr.io/my-project/my-app:latest"
    }
  }
  traffic {
    type            = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
    percent         = 100
  }
}

補足：Cloud Runは専用サービスアカウントを割り当て、最小権限のIAMロールでアクセスを制限してください（DB接続やシークレット参照用の権限だけ付与）。

# 例: Cloud Functions (FaaS) の最小構成断片
resource "google_cloudfunctions2_function" "function" {
  name        = "my-serverless-api"
  location    = "asia-northeast1"
  build_config {
    runtime     = "nodejs18"
    entry_point = "handler"
  }
}

実行チェックリスト:

terraform init

terraform plan

terraform apply

【ハイブリッド接続の注意】

注意：Cloud Run / Cloud Functions からオンプレDBへ接続する場合、Serverless VPC Connector や Private Service Connect などの専用接続と、適切な egress 設定が必須です。これを怠ると接続不可や大量の公衆網トラフィックが発生します。

# Serverless VPC Connector の例（リージョンと名前だけ示す最小例）
resource "google_vpc_access_connector" "connector" {
  name   = "my-connector"
  region = "asia-northeast1"
  network = "default"
  ip_cidr_range = "10.8.0.0/28"
}

※VPC Connector のCIDRは /28〜/24 の小さめブロック推奨（広すぎるCIDRはネットワーク設計を壊します）。
（この後の第3回で、このServerless VPC Connectorを用いたオンプレミス連携の接続設定を詳述します。）

最終判断式

制御したい度合いが高いほど VM → コンテナ → FaaS の順に選択し、ハイブリッドの場合はデータ出入りのレイテンシと接続要件で最終決定する。

まとめと次回予告

第2回では、ハイブリッド構成のフロントエンド選定の基礎として、VM、コンテナ、サーバーレスのモデル比較と、実務的な注意点、そしてIaCによる定義方法を解説しました。

コンテナは最もバランスが良いモデルですが、大規模なエンタープライズ型システムで真価を発揮させるには、K8sの導入と、オンプレミスDB接続時の課題解決が不可欠です。

次回予告

次回は、コンピューティング基盤（第2部）：K8sとコンテナランタイムの詳細設計をテーマに扱います。

Google Cloud のGKE採用判断と、オンプレ接続で実際に起きるレイテンシと接続問題の再現例を示します。ここで示す設計差が、運用コストと可用性を大きく左右します。

ハイブリッドクラウド × ゼロトラスト × IaC の実践アーキテクチャ設計