クラウドの可用性設計では、自分で複数regionにアプリやDBを組むだけでなく、データ保存先のサービス選定やロケーション指定によってデータ層の可用性を高めるパターンがあります。
本記事は、可用性アーキテクチャそのものというより、GCPのマネージドなデータ保存サービスが multi-region / dual-region というロケーション指定で何を担保するのかを整理する記事です。Firestore、Spanner、Cloud Storage、BigQueryを例に、サービスごとの違いを見ます。
代表例は以下です。
- Firestore Native mode + multi-region location
- Spanner multi-region instance
- Cloud Storage dual-region / multi-region bucket
- BigQuery multi-region dataset
本記事では、マネージドサービスのmulti-regionが何を担保し、何を担保しないのかを整理します。
multi-regionはデータ配置の話
multi-region locationは、主にデータの配置場所を表します。
| ロケーション | 意味 |
|---|---|
| region | 1つのregionにデータを置く |
| dual-region | 指定した2つのregionにデータを置く |
| multi-region | US / EU / ASIA のような広域ロケーションにデータを置く |
これは、アプリケーション全体が自動でmulti-regionになるという意味ではありません。
- Firestore multi-region: Firestoreのデータ層がmulti-region
- Appがsingle region: Appはそのregionが落ちると止まる
Firestore multi-region
Firestore Native modeでmulti-region locationを選ぶと、データストア側の複製や可用性をGoogle管理に寄せられます。
flowchart TB
app["App<br/>Cloud Run / GKE / Web app"]
fs["Firestore Native mode<br/>multi-region location"]
subgraph managed["Google managed"]
r1["Region A"]
r2["Region B"]
witness["Witness / coordination"]
end
app --> fs
fs -. "managed replication" .-> r1
fs -. "managed replication" .-> r2
fs -. "managed coordination" .-> witness
この構成では、自分でprimary/replicaを管理するのではなく、Firestoreというマネージドサービスに書き込みます。
採用しやすいケースは以下です。
- ドキュメント型のデータモデルが合う
- RDBのJOINや複雑なトランザクションに強く依存しない
- データストア側のmulti-region可用性をサービス選定で担保したい
Spanner multi-region
Spannerは、強整合性を維持しながらmulti-region構成を選べる分散RDBです。
flowchart TB
app["App"]
spanner["Spanner<br/>multi-region instance"]
subgraph r1["Region A"]
replica1["Replica"]
end
subgraph r2["Region B"]
replica2["Replica"]
end
subgraph r3["Region C"]
replica3["Replica / witness"]
end
app --> spanner
spanner -. "managed replication" .-> replica1
spanner -. "managed replication" .-> replica2
spanner -. "managed replication" .-> replica3
Spanner multi-regionは、Cloud SQLにcross-region replicaを自分で組むのとは考え方が違います。アプリはSpannerというサービスにアクセスし、内部の複製や合意形成はサービス側が担います。
Cloud Storage dual-region / multi-region
Cloud Storageでは、bucketのlocationとしてregion、dual-region、multi-regionを選びます。
flowchart TB
app["App"]
bucket["Cloud Storage bucket<br/>dual-region / multi-region"]
subgraph r1["Region A"]
obj1["Object copy"]
end
subgraph r2["Region B"]
obj2["Object copy"]
end
app --> bucket
bucket -. "managed placement" .-> obj1
bucket -. "managed placement" .-> obj2
Cloud Storageのdual-region / multi-regionは、オブジェクトデータを複数regionに置くための選択です。アプリケーションやDBの可用性まで自動で担保するものではありません。
自前で組む冗長化との違い
Cloud SQL cross-region replicaのように、自分でprimary/replicaを意識する構成と、Firestore/Spannerのmulti-regionのようにサービス側へ任せる構成は違います。
| 観点 | 自前寄りの冗長化 | サービス選定型のmulti-region |
|---|---|---|
| 例 | Cloud SQL HA + read replica | Firestore / Spanner multi-region |
| アプリの見え方 | primary / replicaを意識しやすい | 1つのサービスとして使う |
| failover | 設計・運用が必要になりやすい | サービス側の機能に寄せる |
| 向くケース | RDB要件が強い | サービスのデータモデルに合わせられる |
注意: Appの可用性は別
マネージドデータサービスをmulti-regionにしても、Appがsingle regionならApp障害で止まります。
flowchart TB
subgraph r1["Region A"]
app["App<br/>single region"]
end
fs["Firestore<br/>multi-region"]
app --> fs
この構成は、データ層は強いですが、AppはRegion Aに依存しています。サービス全体を継続したいなら、App側も複数region化やDR構成を考える必要があります。
まとめ
- multi-region locationは主にデータ配置の話
- FirestoreやSpannerは、サービス選定によってデータ層の可用性を高められる
- Cloud Storage dual-region / multi-regionはオブジェクトデータを複数regionに置く選択
- これらはアプリ全体の可用性を自動で完成させるものではない
- App、入口、ネットワーク、運用切替は別途考える必要がある