GCPでCompute Engineを使ったWebアプリ構成を考えるとき、Load Balancer、Backend Service、Managed Instance Group、VM instanceの関係が混乱しがちです。
ロードバランサーで複数台のアプリサーバーに振り分ける考え方自体は、クラウド全般で共通です。一方で、Backend Service、Managed Instance Group（MIG）、serverless NEG などの部品名と組み合わせはGCP固有です。本記事では、負荷分散の一般概念を前提にしつつ、GCPの構成要素としての役割を整理します。
「ロードバランサーがVMを複数まとめる」と言いたくなりますが、正確には役割が分かれています。
| 部品 | 役割 |
|---|---|
| Load Balancer | 外からの入口 |
| Backend Service | どのbackendへ、どう流すかの設定 |
| Managed Instance Group | 同じ設定のVM群を作って維持する管理単位 |
| VM instance | 実際にアプリが動く1台のサーバー |
本記事では、この4つの関係を整理します。
全体の流れ
複数VMへ負荷分散する典型構成は以下です。
flowchart TB user["User"] lb["Load Balancer<br/>入口"] bs["Backend Service<br/>振り分け設定"] mig["Managed Instance Group<br/>VM群の管理単位"] vm1["VM #1"] vm2["VM #2"] vm3["VM #3"] user --> lb lb --> bs bs --> mig mig --> vm1 mig --> vm2 mig --> vm3
通信の理解としては、まず以下で十分です。
User
↓
Load Balancer
↓
Backend Service
↓
Managed Instance Group
↓
VM instancesただし厳密には、通信が物理的にMIGという箱を経由するというより、Backend ServiceがbackendとしてMIGを参照し、MIG配下の正常なVMに流す、という関係です。
VM instanceは1台の仮想サーバー
VM instanceは、アプリを動かす1台の仮想サーバーです。Compute Engine VMはゾーンリソースで、作成時にゾーン・VPC・サブネットなどを指定します。
- Zone:
asia-northeast1-a - VPC:
my-vpc - Subnet:
app-subnet - Internal IP:
10.0.0.10
VPC、サブネット、ゾーンの関係は『GCPのVPC・サブネット・リージョン・ゾーンの関係を整理する』で扱っています。
MIGはVM群を作って維持する
Managed Instance Group（MIG）は、同じ設定のVMを複数台まとめて作り、維持する管理単位です。
Instance Template
「この設定のVMを作る」
↓
Managed Instance Group
「このテンプレートでVMをN台維持する」
↓
VM #1 / VM #2 / VM #3MIGの役割は、ロードバランサーの代わりに分散することではありません。MIGはVM群を管理します。
MIGの仕事は以下です。
- VMを指定台数維持する
- 壊れたVMを作り直す
- autoscalingで増減する
- rolling updateする
- LBのbackendとしてVM群を提供する
Zonal MIGとRegional MIG
MIGには、Zonal MIGとRegional MIGがあります。
- Zonal MIG: 1つのZone内のVM群を管理する
- Regional MIG: 1つのRegion内の複数ZoneにVMを分散して管理する
flowchart TB
subgraph region["Region: asia-northeast1"]
subgraph zonal["Zonal MIG"]
subgraph zoneA["Zone: asia-northeast1-a"]
zvm1["VM #1"]
zvm2["VM #2"]
end
end
end
flowchart TB
subgraph region["Region: asia-northeast1"]
subgraph regional["Regional MIG"]
subgraph zoneA["Zone: asia-northeast1-a"]
vm1["VM #1"]
end
subgraph zoneB["Zone: asia-northeast1-b"]
vm2["VM #2"]
end
subgraph zoneC["Zone: asia-northeast1-c"]
vm3["VM #3"]
end
end
end
覚える形はこれです。
- Zonal MIG: 1 Zone
- Regional MIG: 1 Regionの中の複数Zone
- Global MIG: ない
複数リージョンにまたがる構成にしたい場合は、リージョンごとにRegional MIGを作り、Global Load Balancerで束ねます。これは可用性のテーマで深掘りする話です。
Backend Serviceは振り分け設定
Backend Serviceは、Cloud Load Balancingを構成するリソースの1つです。単独のアプリ本体ではなく、ロードバランサーが参照するバックエンド設定です。
Backend Serviceは以下を持ちます。
| 設定 | 意味 |
|---|---|
| backends | 振り分け先。MIGやNEGなど |
| health check | 正常なbackendだけに流すための確認 |
| balancing mode | CPU使用率、接続数、リクエスト数など、何を基準に振り分けるか |
| timeout | backend応答待ち時間 |
| session affinity | 同じユーザーを同じbackendに寄せるか |
VMに負荷分散する構成では、Backend ServiceのbackendとしてMIGを登録するのが典型です。
Load Balancer
↓
Backend Service
↓
MIG
↓
VM群MIGは必ず出るのか
「ロードバランサーで複数VMに分散させる」文脈なら、基本はMIGを使うと理解してよいです。
ただし、ロードバランサーのbackendはVMだけではありません。GKE Pod、Cloud Run、Cloud Storage bucketなどへ流す構成では、MIGではなくNEGやbackend bucketが登場します。
- VM群へ流す: MIGが典型
- GKE Podへ流す: NEGが出ることがある
- Cloud Runへ流す: serverless NEGが出る
- Cloud Storageへ流す: backend bucket
本記事ではCompute Engine VMへ流す構成に絞るため、MIGが中心です。
まとめ
- Load Balancerは外からの入口
- Backend Serviceはどのbackendへどう流すかの設定
- MIGは同じ設定のVM群を作って維持する管理単位
- VM instanceは実際にアプリが動く1台のサーバー
- Zonal MIGは1つのZone内、Regional MIGは1つのRegion内の複数Zoneを管理する
- 複数VMに負荷分散するCompute Engine構成では、Load Balancer → Backend Service → MIG → VM群で理解するとよい