可用性パターンは、個別に見ると分かりやすい一方、実際のシステムでは複数のパターンを組み合わせます。
本記事では、可用性アーキテクチャの組み合わせ方を、GCP上のWebサービス構成を具体例にして整理します。
たとえば、以下は別々のパターンです。
- Compute: Regional MIG / GKE regional cluster
- Ingress: Global external Load Balancer
- Data: Cloud SQL HA + cross-region replica
- Network: Interconnect + VPN backup
- DR: Active-Passive
本記事では、これらを1つのWebサービス構成として統合して見ます。
前提: 個別パターンの復習
個別パターンは以下の記事で扱っています。
- 『可用性設計を障害単位で整理する』
- 『Compute可用性設計』
- 『トラフィック分散設計』
- 『Cloud SQL HAとcross-region replicaの違い』
- 『Cloud VPNの可用性』
- 『Cloud Interconnectの可用性』
- 『HAとDRの違い』
本記事は新しい概念を増やすというより、既に学んだ部品をどう組み合わせるかを見るためのまとめです。
Active-Passive寄りの高可用Webサービス例
flowchart TB
user["Users"]
glb["Global External Load Balancer"]
subgraph primary["Primary Region"]
subgraph pz1["Zone A"]
app1["App instance / Pod"]
db1["Cloud SQL Primary"]
end
subgraph pz2["Zone B"]
app2["App instance / Pod"]
dbStandby["Cloud SQL Standby<br/>HA"]
end
pCompute["Regional MIG / GKE regional cluster"]
end
subgraph standby["Standby Region"]
appStandby["Standby App<br/>small or ready"]
dbReplica["Cloud SQL Cross-region Replica"]
end
subgraph hybrid["Hybrid Connectivity"]
onprem["On-prem"]
ic["Dedicated Interconnect<br/>primary path"]
vpn["HA VPN<br/>backup path"]
router["Cloud Router<br/>BGP"]
end
user --> glb
glb --> pCompute
glb -. "failover" .-> appStandby
pCompute --> app1
pCompute --> app2
app1 --> db1
app2 --> db1
db1 -. "sync HA" .-> dbStandby
db1 -. "async cross-region replica" .-> dbReplica
onprem <-->|"primary connection"| ic
onprem <-->|"backup connection"| vpn
ic --> router
vpn --> router
router --> pCompute
router -. "DR route" .-> appStandby
この図は全部入りの例です。実際のシステムでは要件に応じて削ります。
障害ごとの見方
この構成で、どの障害にどう備えているかを分解します。
| 障害 | 対応 |
|---|---|
| App 1台が落ちる | App instance / Podを複数持つ |
| Zone Aが落ちる | Zone BのApp / Cloud SQL Standbyで耐える |
| Primary Regionが落ちる | Standby Regionへfailoverする |
| DB primaryが落ちる | Cloud SQL HAでstandbyへfailoverする |
| データを別regionに残したい | cross-region replicaを持つ |
| Interconnectが落ちる | HA VPN backupへ切り替える |
| オンプレ接続経路が落ちる | Cloud Router/BGPで別経路へ切り替える |
Computeはzone冗長とregion冗長を分ける
Primary Region内では、Regional MIGやGKE regional clusterで複数zoneに分散し、zone障害に備えます。
一方、Primary Region全体の障害に備えるには、Standby Regionにもアプリを置き、入口を切り替えられるようにします。
DBはHAとreplicaを分ける
Cloud SQL HAは、同一region内のzone障害対策です。cross-region replicaは、別regionにデータを残す構成であり、Region障害時の復旧材料になります。
DB replicaだけではサービス継続になりません。Standby RegionのApp、入口切替、運用手順と組み合わせてDRになります。
Networkはアプリ可用性とは別に考える
オンプレ接続がある場合、アプリやDBを複数zone/regionにしても、オンプレ接続が単一経路ならそこが弱点になります。
- Interconnect: 通常時の主経路
- HA VPN: Interconnect障害時のbackup
- Cloud Router/BGP: 経路切替
Interconnect自体を強くするなら、99.9 / 99.99構成も検討します。
どこまでやるかは要件次第
この図は、すべてのシステムで必要な構成ではありません。
| 要件 | 削れるもの |
|---|---|
| オンプレ接続がない | Interconnect / VPN / Cloud Router |
| DR不要 | Standby Region |
| データだけ残ればよい | Standby App / failover入口 |
| zone障害だけ見ればよい | 複数region backend |
| Firestore/Spanner multi-regionを使う | DB replica設計の一部をサービス側へ寄せる |
可用性設計では、強い構成を全部入れるのではなく、RTO/RPO、コスト、運用能力に合わせて選びます。
まとめ
- 統合アーキテクチャは、新しい概念ではなく個別パターンの組み合わせ
- Computeはzone冗長とregion冗長を分ける
- DBはCloud SQL HAとcross-region replicaを分ける
- NetworkはVPN/Interconnectの経路冗長を別レイヤーとして考える
- DRはアプリ、入口、データ、運用手順まで含めたシステム全体の話
個別パターンを理解したら、最後にこのような統合図で「どの障害にどの部品が効いているか」を確認すると、可用性設計の全体像が掴みやすくなります。