他のクラウドから Google Cloud に来ると、ネットワークの最初の一歩で手が止まります。VPC を作るときにリージョンを選ぶ欄がないからです。
AWS では VPC はリージョンの中に作るものですし、サブネットはさらにアベイラビリティゾーンの中に閉じます。公式ドキュメントにも、サブネットは1つのゾーンに完全に収まり、ゾーンをまたげないと明記されています。
Each subnet must reside entirely within one Availability Zone and cannot span zones.
（Amazon VPC ユーザーガイド）
Google Cloud の VPC ネットワークにはその制約がありません。1つの VPC が全リージョンにまたがり、東京のVMと大阪のVMが、ピアリングも VPN もなしに内部 IP で直接話せます。
便利ではあるものの、なぜそんなことが可能なのかが分からないと、どこまで信用していいのか判断できません。しかも実際に運用してみると、グローバルなはずの VPC の中に、リージョン単位でしか効かない部品がかなり混ざっています。事故の大半はそこで起きます。
仕様の確認から始めて、なぜグローバルにできるのか、そしてどこがグローバルではないのかを順に見ていきます。
VPC はグローバル、サブネットはリージョナル
公式の仕様はこうです。
VPC networks, including their associated routes and firewall rules, are global resources. They are not associated with any particular region or zone.
Subnets are regional resources.
（VPC networks）
グローバルなのは VPC ネットワーク本体だけではありません。ルートとファイアウォールルールも一緒にグローバルだと書かれています。この2つが付いてくるところが後々効いてきます。
リージョナルなのはサブネットです。サブネットは IP アドレス範囲を持ち、リージョンに属します。ここまでは AWS と同じ形に見えますが、下がもう1段ありません。
Google Cloud のサブネットはゾーンに紐づきません。asia-northeast1 のサブネットは、asia-northeast1-a にも -b にも -c にも使えます。VM を作るときにゾーンを選ぶと、そのゾーンの親リージョンが決まり、そのリージョンにサブネットを持つネットワークから選ぶことになる、という関係です。
Because subnets are regional resources, instances can have their network interfaces associated with any subnet in the same region that contains their zones.
サブネットをゾーンごとに切らなくていいので、3ゾーンに分散する構成でもサブネットは1つで済みます。マルチAZ構成のたびに /24 を3本用意する、という段取りがそもそも要りません。
細かいところでは、使えないアドレスの数も違います。Google Cloud がプライマリ IPv4 範囲から予約するのは先頭2つと末尾2つの計4つです。
| 使えないアドレス | 内容 |
10.1.2.0/24 の例 |
|---|---|---|
| ネットワークアドレス | 範囲の先頭 | 10.1.2.0 |
| デフォルトゲートウェイ | 範囲の2番目 | 10.1.2.1 |
| 末尾から2番目 | 将来利用のための予約 | 10.1.2.254 |
| ブロードキャストアドレス | 範囲の末尾 | 10.1.2.255 |
セカンダリ範囲にはこの予約がなく、全アドレスを使えます。エイリアス IP 用にセカンダリ範囲を切るときは、そのぶん詰めて計算して問題ありません。
物理装置がないから、リージョンで区切る理由がない
VPC がグローバルでいられる理由は、ルーティングの実装にあります。ルートのドキュメントに、こう書いてあります。
Every VPC network uses a scalable, distributed virtual routing mechanism. There is no physical device that's assigned to the network.
Each VM instance has a controller that is kept informed of all applicable routes from the network's routing table.
（Routes）
ルーティングテーブルに対応する箱がどこかのデータセンターに置かれているわけではありません。VPC のルーティングテーブルはネットワーク単位で定義された論理的な集合で、そこから各 VM のコントローラに配られます。ルートを足したり消したりすると、その差分が結果整合でコントローラに伝わっていきます。
配る先がソフトウェアなら、配る範囲を1リージョンに限る理由はありません。ここがリージョン境界を越えられる直接の理由です。
この仮想ネットワーク基盤には Andromeda という名前が付いていて、VPC のドキュメント冒頭にも登場します。
A Virtual Private Cloud (VPC) network is a virtual version of a physical network that is implemented inside of Google's production network by using Andromeda.
Andromeda については、Google の技術者が NSDI '18 で論文を出しています（Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization）。この論文に、グローバルな仮想ネットワークを作ると何が困るのかが書かれています。
Andromeda programs networks that can be global in scope, so the cluster control plane must receive updates for VMs in all other clusters. We must ensure that a bad update or overload in one region cannot spill over to the control planes for other regions.
ネットワークがグローバルだと、あるクラスタの制御プレーンは他の全クラスタの VM の更新を受け取らなければなりません。素直に作れば、1つのリージョンで起きた不正な更新や過負荷が他のリージョンの制御プレーンまで巻き込みます。グローバルにするというのは、障害の伝播範囲を広げることでもあります。
論文では、制御プレーンを2つに割ってこれに対処したと説明されています。リージョン内の接続だけを担当し、設定も自リージョンの VM に限定した RACP（regionally aware control plane）と、リージョン間の接続を担当し、他リージョンの更新も受け取る GACP（globally aware control plane）です。
This approach ensures that intra-region networking in each region is a separate failure domain.
リージョン内の通信は、リージョンごとに独立した障害ドメインになる。ここが設計の肝で、グローバルなネットワークを掲げつつ、リージョン内で完結する通信は他リージョンの事故から切り離しています。制御プレーンが落ちてもホストは最後の正常な状態でパケットを転送し続ける、という縮退の作り込みも同じ節に書かれています。
利用者から見ると、VPC がグローバルなのは単に便利な機能に見えますが、その裏でリージョンをまたぐ制御をどう隔離するかという作業が要ったわけです。
グローバルであることが設計に効いてくるところ
仕組みが分かったところで、実務にどう効くかを4点だけ挙げます。
IP 設計を最初にグローバルで決める必要がある
サブネットの IP 範囲は、VPC 全体で一意でなければなりません。
Each primary or secondary IPv4 range for all subnets in a VPC network must be a unique valid CIDR block.
リージョンごとに独立した VPC を作るクラウドなら、東京と大阪で同じ 10.0.0.0/16 を使ってもかまいません。Google Cloud で1つの VPC にまとめるなら、両方合わせて重複しない設計を最初に作ることになります。
これは面倒が増えたのではなく、面倒の発生する時期が前に来ただけだと考えています。あとからリージョンを足したときに IP がぶつかって、ピアリングできない、VPN が張れない、という形で表面化するよりは、最初に決めさせられるほうが安全です。
なお、自動モードの VPC は 10.128.0.0/9 の中から各リージョンに自動でサブネットを切ります。全プロジェクトの自動モードネットワークが同じ範囲を使うので、自動モード同士はピアリングでも VPN でも繋げません。本番は自動モードではなくカスタムモードで作る、という公式の推奨はここから来ています。
リージョンをまたいだ内部通信に、何も足さなくていい
サブネットルートは VPC ネットワーク全体に適用されます。東京のサブネットと大阪のサブネットは同じルーティングテーブルの中にいるので、VM 同士は内部 IP でそのまま通信できます。ピアリングもトランジットゲートウェイも要りません。
一方で、これは分離したいときに手当てが必要という意味でもあります。同じ VPC に置いた時点で経路は繋がっているので、本番と検証を分けたいならファイアウォールで塞ぐか、VPC そのものを分けるかを選ぶことになります。私は後者を勧めます。ルールで塞ぐ方式は、ルールを1つ間違えたときに何も守られなくなるためです。
ファイアウォールルールはネットワークに属し、共有できない
VPC ファイアウォールルールもグローバルなので、1本書けば全リージョンの対象 VM に効きます。逆に、VPC の外には出ていきません。
When you create a firewall rule, you must select a VPC network. While the rule is enforced at the instance level, its configuration is associated with a VPC network. This means that you cannot share firewall rules among VPC networks, including networks connected by VPC Network Peering or by using Cloud VPN tunnels.
（VPC firewall rules）
ピアリングで繋いだ相手のネットワークにも、VPN の向こうにも、こちらのルールは適用されません。ピアリング先からの通信を制御したいなら、自分の VPC 側で受信ルールを書きます。複数の VPC やプロジェクトに同じ方針をまとめて効かせたい場合は、組織やフォルダに紐づく階層型ファイアウォールポリシーを使うことになります。
クォータの多くがネットワーク単位で効く
VPC が大きな入れ物になるぶん、上限もそこに掛かります。クォータの一覧には、VPC ネットワークあたりのインスタンス数（正確には NIC 数）、エイリアス IP 範囲数、サブネットの IP 範囲数、ピアリング数、静的ルート数が並んでいます（VPC の割り当てと上限）。
プロジェクトを分ければ回避できる、という類のものではありません。共有 VPC で1つのネットワークに全社を寄せる設計をとると、上限は全社の合計に対して効きます。規模の大きい環境では、VPC を分ける判断材料の1つになります。
グローバルな VPC の中のリージョナルな部品
ここからが実務で一番引っかかるところです。VPC はグローバルでも、その上に載る部品にはリージョン単位のものが多くあります。
| 部品 | スコープ |
|---|---|
| VPC ネットワーク、ルート、VPC ファイアウォールルール | グローバル |
| 階層型ファイアウォールポリシー | 組織またはフォルダ |
| グローバルネットワークファイアウォールポリシー | グローバル |
| リージョナルネットワークファイアウォールポリシー | リージョン |
| サブネット | リージョン |
| Cloud NAT ゲートウェイ | リージョン |
| Cloud Router | リージョン |
| プロキシ専用サブネット | リージョン（用途が GLOBAL_MANAGED_PROXY と REGIONAL_MANAGED_PROXY に分かれる） |
| 内部パススルーネットワークロードバランサ | リージョン |
| VM とそのゾーン | ゾーン |
Cloud NAT は分かりやすい例です。ゲートウェイは NAT したいサブネットのリージョンに作ります。東京で作った NAT ゲートウェイは大阪のサブネットを見てくれません。VPC が1つだから NAT も1つでいい、とはならないわけです。
そして、最大の落とし穴だと思っているのが動的ルーティングモードです。
既定はリージョナル動的ルーティング
VPC ネットワークには動的ルーティングモードという設定があり、既定値は regional です。
The dynamic routing mode of a VPC network is either regional (default) or global.
（動的ルーティングモードの設定）
この設定は、オンプレミスや他ネットワークと BGP で繋いだときの経路の扱いを決めます。広報する側の挙動はこうです。
Regional dynamic routing mode: Each BGP session that advertises subnet ranges only sends the subnet ranges that are in the same region as the Cloud Router that contains the BGP session.
（Advertised routes）
東京に置いた Cloud Router は、東京のサブネットしかオンプレミスに広報しません。大阪にサブネットを増やしても、オンプレミス側の経路表には出てきません。
学習する側も同じ考え方で切れています。
Regional dynamic routing mode: Each region's dynamic route control plane only processes learned routes from the Cloud Router BGP tasks in its own region. The resulting dynamic routes created in a particular region of a VPC network have next hops only within that specific region.
（Learned routes）
東京の Cloud Router が学習したオンプレミスへの経路は、東京の VM にしか適用されません。大阪の VM からオンプレミス宛のパケットを出しても、そのリージョンには次ホップがないので届きません。
VPC はグローバルなのに、ハイブリッド接続だけリージョンに閉じている。この非対称が事故のもとです。東京で構築して疎通を確認し、後から大阪にサブネットを足したときに、VM 間は問題なく通るのにオンプレミスにだけ届かない、という形で出ます。ファイアウォールを何度見直しても原因が見つからないので、探す場所を知らないと時間を溶かします。
global に変えると、Cloud Router は他リージョンのサブネットも広報し、学習した経路も全リージョンから使えるようになります。他リージョンのサブネットを広報するときの MED には、リージョン間コストが加算されます。設定は VPC ネットワーク単位で、あとから変更できます。
# 現在のモードを確認する
gcloud compute networks describe NETWORK_NAME \
--format="get(routingConfig)"
# グローバルに変更する
gcloud compute networks update NETWORK_NAME \
--bgp-routing-mode=global
複数リージョンからオンプレミスに繋ぐ予定があるなら、最初から global にしておくほうが素直です。既定のままだと、繋がらない理由が見た目に現れません。
ルートとファイアウォールはどの順で選ばれるか
ルートもファイアウォールルールも VPC 全体で1つの集合になるので、複数の候補が同時に当たります。どれが選ばれるかを知らないと、書いたつもりの制御が効きません。
ルートの選択順
パケットが VM を出るとき、Google Cloud は次の順で候補を絞ります（Routing order）。
- 特殊なルーティングパス。該当すれば他は全部無視して確定する
- ポリシーベースルート。優先度だけで評価され、送信元 IP やプロトコルなどの条件で当てられる
- サブネットルート。宛先が VPC 内のサブネット範囲に入るなら、他のルートを全部無視してここで確定する
- 最長一致。残った静的ルートと動的ルートのうち、最も具体的な宛先を持つものだけを残す
- ルート種別の優先。ローカルの静的・動的ルートが、NCC 経由やピアリング経由のルートより優先される
3番目が重要です。宛先が自分の VPC のサブネット範囲に入っていたら、そこで確定します。静的ルートを書いてサブネット宛の通信を別の装置に迂回させる、という設計は成立しません。ここを通したいときに使うのが、2番目のポリシーベースルートです。例外はハイブリッドサブネット（--allow-cidr-routes-overlap を付けたサブネット）で、宛先が実際に稼働中の VM や内部転送ルールに紐づいていない場合は別扱いになります。オンプレミスと同じ IP 範囲を Google Cloud 側に延ばしたまま移行するための仕組みです。
もう1つ、0.0.0.0/0 の既定ルートは自動で作られますが、削除も置き換えもできます。インターネットへの出口を全部プロキシに寄せたいなら、既定ルートを消して自前の静的ルートを置くことになります。
ファイアウォールの評価順
ファイアウォールは、階層型ポリシー、システムポリシー、VPC ファイアウォールルール、ネットワークファイアウォールポリシーの4系統が同居しています。評価順の既定は AFTER_CLASSIC_FIREWALL で、次の順です（Firewall rule evaluation process）。
- 階層型ファイアウォールポリシー（組織、次にフォルダを上から順に）
- リージョナルシステムファイアウォールポリシー（Google が管理する。編集不可）
- VPC ファイアウォールルール
- グローバルネットワークファイアウォールポリシー
- リージョナルネットワークファイアウォールポリシー
- 暗黙のアクション
BEFORE_CLASSIC_FIREWALL に変えると、3番目と4・5番目が入れ替わります。ポリシーへ移行する途中で、既存の VPC ファイアウォールルールより先にポリシーを効かせたい場合に使います。
各段では、対象と方向が一致しないルールを外し、残りを優先度の高い順に見ます。1つ当たれば評価はそこで終わります。階層型ポリシーには goto_next があり、これに当たると判断を下の階層に譲ります。どこにも当たらなかった場合も暗黙の goto_next として扱われるので、上位で許可も拒否もしなければ下位の判断が生きます。
最後まで何も当たらなかったときの暗黙のアクションは、方向と対象で決まります。
- 受信は拒否。ただし内部アプリケーションロードバランサなどを支えるマネージドの Envoy プロキシが対象の場合は許可
- 送信は許可
外向きが既定で開いているので、外部への通信を絞りたいなら明示的に拒否ルールを書く必要があります。
なお、VM とメタデータサーバー（169.254.169.254）の通信は常に許可されていて、ファイアウォールルールでは止められません。
まとめ
- VPC ネットワーク、ルート、VPC ファイアウォールルールはグローバル。サブネットはリージョナルで、ゾーンには紐づかない
- グローバルにできるのは、ルーティングが物理装置ではなく各 VM のコントローラに配られるソフトウェアの仕組み（Andromeda）で動いているため
- グローバルにした代償として障害の伝播範囲が広がる問題は、制御プレーンをリージョン内用とリージョン間用に分けることで抑えられている。リージョン内の通信はリージョンごとに独立した障害ドメイン
- IP 範囲は VPC 全体で一意。IP 設計は最初にグローバルで決めることになる
- 主要なクォータは VPC ネットワーク単位で効く。共有 VPC で全社を1つに寄せるなら考慮に入れる
- Cloud NAT、Cloud Router、内部パススルー NLB はリージョン単位。特に動的ルーティングモードの既定は
regionalで、Cloud Router は自リージョンのサブネットしか広報せず、学習した経路も自リージョンにしか作らない - ルートは、宛先が VPC 内のサブネット範囲に入った時点で確定する。迂回させたいならポリシーベースルートを使う
- ファイアウォールの暗黙のアクションは、受信が拒否で送信が許可
VPC を作るときにリージョンを選ばされないのは、選ぶ必要がないからです。そのぶん、リージョンを意識しなければならない場所がどこかを覚えておく必要があります。