Google Cloud の土台
リージョン・ゾーンと可用性
ゾーンは障害の区画で、リージョンは複数のゾーンを持つ独立した地域です。ゾーン障害に耐えるにはリージョン内の複数ゾーンに、リージョン障害に耐えるには複数リージョンに置きます。
Google Cloud のリソースは、ゾーン、リージョン、グローバルのどれかの範囲に属します。ゾーンは 1 つの障害で同時に止まりうる区画で、リージョンは複数のゾーンを持つ独立した地域です。VM 1 台はゾーンに属するので、そのゾーンが止まれば一緒に止まります。可用性の設計では、耐える障害の範囲を決め、それより広く配置します。
リソースが属する範囲で、一緒に止まるものが決まる
ゾーンの名前はリージョン名に 1 文字を付けた形 (asia-northeast1-a) です。GPU を大量に並べる AI ゾーン (us-west4-ai2b など) は、通常のゾーンとは別枠です。リージョンの数は増え続けるので、一覧は暗記せず リージョンとゾーン (公式) で確かめます。
| 範囲 | Compute Engine の例 | 止まる条件 |
|---|---|---|
| ゾーン | VM、ゾーン永続ディスク、ゾーン MIG、GPU | そのゾーンの障害 |
| リージョン | サブネット、リージョン MIG、リージョン永続ディスク、リージョンの静的外部 IP | そのリージョン全体の障害 |
| グローバル | VPC、ファイアウォールルール、ルート、イメージ、スナップショット、グローバルの静的外部 IP | 特定の場所の障害では止まらない |
VPC がグローバルでサブネットがリージョンに属する点は、AWS の経験者ほど間違えます。1 つの VPC に東京と大阪のサブネットを作れます (VPC の設計)。ゾーン永続ディスクは同じゾーンの VM にしか付けられないので、ゾーン障害のあとはスナップショットかリージョン永続ディスクから作り直します。
ゾーン障害には複数ゾーン、リージョン障害には複数リージョン
Compute Engine の SLA は、複数ゾーンに置いたインスタンスで月間稼働率 99.99% 以上、単一のインスタンス (メモリ最適化以外) で 99.9% 以上です。プレミアム ティアのネットワークの値で、一部のリージョンに例外があります。99.9% は月に約 43 分、99.99% は約 4 分の停止に当たるので、要件が 99.99% なら VM 1 台の構成は外れます。最新の値は Compute Engine の SLA (公式) で確かめます。
ゾーン障害に耐える基本は、リージョン MIG のように複数ゾーンへ自動で分散させる仕組みです。Cloud SQL の高可用性構成は別のゾーンに待機系を置き、GKE のリージョン クラスタはコントロール プレーンとノードを複数のゾーンに置きます (コンピューティングの選び方、ストレージとデータベースの選び方)。リージョン障害まで耐えるには 2 つ以上のリージョンに置くしかなく、データの複製、リージョン間の通信料金、切り替えの手順が増えます。どこまで求めるかは RTO と RPO で決めます (可用性と災害復旧)。
データはデュアルリージョンとマルチリージョンにも置ける
リージョンは処理する VM と同じ場所に置いてレイテンシと通信料金を抑えたいとき、マルチリージョンは広い地域へ配信したいときに選びます。データを置く国が法律や契約で決まっているなら、範囲を確かめます。ASIA は香港とインドネシアを除くアジアのデータセンターを、EU は EU 加盟国の中のデータセンターを使います (コンプライアンスとデータの所在)。
参考: バケットのロケーション (公式)
リージョンは規制、提供状況、レイテンシ、料金の順に選ぶ
データの所在の規制を満たさないリージョンは候補から外れます。次に、使いたいサービスやマシンタイプ (新しい GPU など) があるか、利用者からのレイテンシが小さいかを見て、残った中から料金で決めます。料金を先に見て遠いリージョンを選ぶと、レイテンシとリージョン間の通信料金で結局高くつきます。
試してみる
Cloud Shell で東京リージョンのゾーンを調べ、東京と大阪のデュアルリージョンにバケットを作ります。数バイトのファイルだけなので、費用はクレジットの範囲でごくわずかです。
PROJECT_ID=$(gcloud config get-value project)
gcloud services enable compute.googleapis.com
# 東京リージョンのゾーンと、その状態を一覧する
gcloud compute zones list --filter="region:asia-northeast1"
gcloud compute regions describe asia-northeast1 --format="value(zones)"
# 東京と大阪のデュアルリージョンにバケットを作り、場所を確かめる
BUCKET="gs://${PROJECT_ID}-dual"
gcloud storage buckets create "$BUCKET" --location=ASIA1
gcloud storage buckets describe "$BUCKET" --format="value(location,location_type)"
echo "hello" > hello.txt
gcloud storage cp hello.txt "$BUCKET/"最後にバケットを中身ごと削除します。
gcloud storage rm --recursive "$BUCKET"
rm hello.txt試験で問われる判断
自作の例です。実際の試験問題ではありません。
- 「1 つのゾーンが止まっても続けたい。費用は抑えたい」なら、リージョン MIG で複数ゾーンに分散し、ロードバランサの後ろに置きます。2 リージョンに分けるのは過剰です。
- 「東京リージョン全体が使えなくなっても、1 時間以内に大阪で再開したい」なら、データを大阪へ複製し、切り替え先を用意します。東京の複数ゾーンだけでは耐えられません。
- 「VM のディスクを、ゾーン障害のときに別のゾーンからすぐ使いたい」なら、リージョン永続ディスクを選びます。
- 「日本国内にデータを置く規制がある」と書かれ、Cloud Storage の選択肢に
ASIAとASIA1があればASIA1を選びます。ASIAは国外を含みます。