可用性設計を学ぶときに混乱しやすいのは、regional、multi-region、global、HA VPN、Cloud SQL HA、DR などの用語が同じ「止めないための設計」に見えてしまうことです。
本記事は、可用性という一般的な設計テーマを、GCPのサービスや用語を例にして整理します。GCP固有の機能名だけを覚えるのではなく、障害単位ごとに「何を複数持つのか」を見るための記事です。
整理の起点はサービス名ではなく、何が壊れる想定なのかです。VMが1台落ちるのか、zoneが落ちるのか、regionが落ちるのか、オンプレ接続が切れるのか、災害から復旧したいのかで、採るべき構成は変わります。
本記事では、可用性パターンを障害単位で整理し、それをGCPの構成例に落とし込みます。個別サービスの詳細は、関連記事へ委譲します。
可用性は「何が壊れるか」から考える
可用性設計は、雑に言うと以下の問いです。
- 何が壊れても動かしたいのか
- その障害単位に対して何を複数持つのか
主要な障害単位は以下です。
| 障害・要件 | 覚える構成 | 対応レイヤー |
|---|---|---|
| VM / Podが落ちる | 複数VM、複数Pod、MIG | Compute |
| zoneが落ちる | Regional MIG、GKE regional cluster、Cloud SQL HA | Compute / DB |
| regionが落ちる | Global LB + 複数region backend、cross-region replica、dual-region storage | トラフィック分散 / Compute / Data |
| 正常なbackendへ通信を逃がしたい | Regional LB、Global external LB、Cross-region internal LB | トラフィック分散 |
| データを失いたくない | Cloud SQL HA、read replica、backup、multi-region data service | Data |
| オンプレ接続を止めたくない | HA VPN、multi-region Cloud VPN、Interconnect 99.9 / 99.99、VPN backup | Network |
| 大規模災害から復旧したい | backup/restore、pilot light、warm standby、active-passive、active-active | System DR |
この表が、可用性設計を障害単位で見るときの大枠です。構成例ではGCPのサービス名を使っています。
Computeの可用性
Computeの可用性では、VMやPodをどこに複数配置するかを考えます。
- VM単体障害: 複数VM / MIG
- zone障害: Regional MIG / GKE regional cluster
- region障害: 複数region backend + Global Load Balancer
1つのregion内の複数zoneに分散すればzone障害に強くなります。region障害まで見るなら、regionそのものを複数持つ必要があります。
Compute側の詳細は『Compute可用性設計: GCPのRegional MIG・GKE regional cluster・複数region backendで考える』で扱います。
トラフィック分散の可用性
トラフィック分散の可用性では、Load Balancer自体の故障対応ではなく、通信をどのスコープで受け、どの範囲の正常なbackendへ逃がせるようにするかを考えます。
- 1 region内で分散: Regional Load Balancer
- 外部ユーザーを複数region backendへ分散: Global external Load Balancer
- VPC内部で複数region backendへ分散: Cross-region internal Load Balancer
重要なのは、Global Load Balancerを置いただけではregion冗長にはならないことです。backendが1 regionだけなら、アプリ本体は単一region依存です。
トラフィック分散の詳細は『トラフィック分散設計: GCPのRegional LB・Global external LB・Cross-region internal LBで考える』で扱います。
Dataの可用性
Dataの可用性は、DBやStorageがどこまで壊れてもデータを守れるかです。
- DBのzone障害: Cloud SQL HA
- DBのregion障害に備えたデータコピー: Cloud SQL cross-region read replica
- オブジェクトのregion冗長: Cloud Storage dual-region / multi-region
- マネージドサービス側でmulti-region化: Firestore / Spanner multi-region
Cloud SQL HAは同一region内のzone冗長です。cross-region replicaは別regionにデータを逃がす構成です。両者は似ていますが、想定障害が違います。
Cloud SQLの詳細は『Cloud SQL HAとcross-region replicaの違い』、FirestoreやSpannerなどのmulti-regionデータサービスは『GCPのmulti-regionデータサービス: Firestore・Spanner・Cloud Storage・BigQueryの違い』で扱います。
Networkの可用性
Networkの可用性では、オンプレミスや他クラウドとGCP VPCをつなぐ経路を冗長化します。
- VPN tunnel / interface障害: HA VPN
- VPN接続を1つのGCP regionに依存させたくない: 各region Cloud VPN gateway
- 専用線接続を冗長化したい: Interconnect 99.9 / 99.99 topology
- 専用線そのものの障害に備えたい: Interconnect + Cloud VPN backup
VPNとInterconnectは「オンプレとGCP VPCをつなぐ」という役割は近いですが、冗長化の考え方は分けて理解したほうがよいです。
VPNは『Cloud VPNの可用性』、Interconnectは『Cloud Interconnectの可用性』で扱います。
HAとDRの違い
HA（High Availability）は、普段起きうる故障でもなるべく止めない設計です。一方、DR（Disaster Recovery）は、大規模障害や災害で本番環境が使えなくなったときに復旧する設計です。
- HA: VM、zone、DBインスタンス、VPN tunnelなどの障害に耐える
- DR: region障害や大規模災害から復旧する
DRには以下のような段階があります。
| パターン | 状態 | コスト | 復旧速度 |
|---|---|---|---|
| Backup / Restore | バックアップだけある | 低 | 遅い |
| Pilot Light | 最小部品だけ待機 | 低〜中 | 中〜遅い |
| Warm Standby | 縮小環境を常時起動 | 中 | 中〜速い |
| Active-Passive | 待機系をほぼ準備済み | 中〜高 | 速い |
| Active-Active | 複数regionで常時稼働 | 高 | 最速 |
DRパターンの詳細は『HAとDRの違い』で扱います。
まとめ
可用性設計は、サービス名から覚えるよりも、障害単位で整理したほうが理解しやすいです。GCPでもAWSでもオンプレでも、最初に見るべき問いは「何が壊れても動かしたいのか」です。
- VM/Pod障害にはComputeの複数化で備える
- zone障害にはregional構成で備える
- region障害には複数region構成で備える
- データ保護にはreplica、backup、multi-region serviceを使う
- オンプレ接続にはVPNやInterconnectの経路冗長を使う
- 大規模障害にはDRパターンで備える