【テクニカル・上級編】 GCP VPC Network的ルーティングモード (グローバル vs リージョナル) – クラウドインフラと仮想化ネットワーク実践ガイド

グローバルか、リージョナルか：GCP VPCルーティングモードの深層と、パケットが辿る最適パスの物理学

ネットワーク機器のL3スイッチやルーターのベンダー選定で夜明かししたような、パケットの挙動に異常なまでの情熱を傾けるインフラエンジニアの皆さん、こんにちは。

私たちが日々当たり前のように使っているパブリッククラウド。その中でもGoogle Cloud（GCP）のVPC（Virtual Private Cloud）は、他のメガクラウドとは一線を画す「単一のグローバル分散ファブリック」として設計されています。物理的な境界をソフトウェアでいかに隠蔽するかというGoogleの執念が、このVPCネットワークの根底には流れています。

しかし、その圧倒的な抽象化の裏側で、インフラアーキテクトやテックリードとして避けて通れない極めて重要な分岐点が存在します。それが 「VPCネットワークのルーティングモード（グローバル vs リージョナル）」 の選択です。

今回は、Cloud Routerによる動的ルーティング、BGP（Border Gateway Protocol）セッションの張られ方、そしてそれがパケットのレイテンシ、TCPハンドシェイク、さらには広域障害時の挙動にどう影響するのか。Linuxカーネルのルーティングテーブルの視点も交えながら、現場の泥臭い知見とともに徹底的に解剖していきましょう。

—

1. GCP VPCルーティングモードの基本思想：何が変わるのか？

GCPのVPCネットワークを作成する際、私たちは必ずルーティングモードとして Global か Regional かを選択せまられます。この設定は、ひとたびCloud Router（BGP）やカスタムスタティックルートを導入した瞬間から、VPC全体のエントリポイントにおける「経路の広告範囲と計算アルゴリズム」を決定づけます。

リージョナルルーティングモード（Regional Routing Mode）の挙動

リージョナルモードを選択した場合、Cloud Routerは自分が配置されているリージョン内のサブネットに対してのみ、動的ルート（BGP学習ルート）を計算・適用します。

  • スコープ: 経路の有効範囲は同一リージョン内に限定されます。
  • 他リージョンへの影響: 例えば asia-northeast1（東京）にあるCloud RouterがオンプレミスからBGPでルートを学習しても、us-central1（アイオワ）のVPCネットワーク内からは、そのルートは見えません（明示的にクロスリージョンでルーティングする仕組みを別途用意しない限り、到達不能になります）。

グローバルルーティングモード（Global Routing Mode）の挙動

デフォルトであり、多くのモダンなマルチリージョンアーキテクトが採用するグローバルモードでは、Cloud Routerが特定のリージョンで学習したルートは、VPC内のすべてのリージョンのサブネットに即座に同期・適用されます。

  • スコープ: GCPのグローバルVPCファブリック全体に波及します。
  • クロスリージョンホッピング: 東京のCloud Routerが学習したオンプレミスへの経路を、オレゴンのCompute Engineインスタンスからも直接利用できるようになります。

一見すると「何も考えずにグローバルにしておけばすべてが繋がって便利」と思われがちですが、パケットがグローバルバックボーンをどう駆け巡るのか、その物理的および論理的コストを理解しなければ、予期せぬレイテンシの増大やトラフィックの迷子（Sub-optimal routing）を引き起こします。

—

2. パケットレベルで見るルーティングの内部挙動

では、東京とオレゴンにインスタンスを持ち、オンプレミス（例えば品川のデータセンター）とCloud Interconnect（Dedicated Interconnect）で結ばれた環境を想像してください。ここで「グローバルルーティングモード」を採用していると仮定します。

[品川オンプレミス DC] 
       │ (BGP)
[東京リージョン: Cloud Router] ──(Google Global Network)── [オレゴンリージョン: GCE Instance]

オレゴン（us-central1）のGCEインスタンスから品川のオンプレミスへ向けたパケットが送出されたとき、LinuxカーネルのルーティングテーブルとGCPのソフトウェア定義ネットワーク（SDN）レイヤーでは、次のような魔法のような（あるいは恐ろしい）ことが起きています。

1. エグレス（Egress）の決定: オレゴン側のインスタンスがパケットを送出すると、GCPのホスト仮想化レイヤー（Andromedaなど）は、VPCがグローバルモードであるため「東京のCloud Routerが知っている品川への経路」を有効な次ホップ（Next Hop）として認識します。
2. バックボーンの横断: パケットはオレゴンからGoogleのプライベート・グローバル・ファイバー（海底ケーブルを含む）を経由して、太平洋を渡り東京リージョンへと引き込まれます。
3. オンプレミスへの脱出: 東京のCloud Interconnectアタッチメントを経由して、パケットは品川へと到達します。

ここに潜む罠：RTTとTCPバッファチューニングのジレンマ

この挙動の何が問題でしょうか？ オレゴンから品川への通信なのに、あえてパケットを一度東京まで引き戻している（あるいはその逆の）ケースが発生し得ます。

ラウンドトリップタイム（RTT）は物理的な光速の限界に支配されます。オレゴン-東京間の片道遅延は約35ms〜40msです。もしオレゴンのインスタンスが直接オレゴン近郊のパートナーネットワーク経由で抜けられず、東京のCloud Router経由のグローバルルーティングに依存している場合、無駄なホップと遅延が上乗せされます。

さらに、TCPのウィンドウサイズ（Receive Window）はRTTの関数として動的にチューニングされます（BDP: Bandwidth-Delay Productの法則）。
$$\text{BDP} = \text{帯域幅} \times \text{RTT}$$

グローバルルーティングによって不必要にRTTが拡大すると、Linuxカーネル（tcp_rmem / tcp_wmem）はより大きなバッファメモリをコネクションごとに割り当てざるを得なくなります。結果として、同時コネクション数が多い高負荷なマイクロサービス群において、メモリ枯渇やバッファあふれによるパケットドロップの危険性が高まるのです。

—

3. インフラエンジニアが直面するトラブルシューティングとベストプラクティス

現場で実際に遭遇する障害として最も厄介なのが、「意図しないリージョンからのトラフィック流入（Cross-region egress charges の爆発）」と「非対称ルーティング（Asymmetric Routing）」です。

非対称ルーティングの恐怖

リージョナルモードで各リージョンに独立したCloud Routerを配置し、それぞれが独自のBGPセッションをオンプレミスと結んでいる場合を考えます。ここでルーティング設定を誤ると、次のようなパケットの往復不一致が起きます。

  • 往路: オレゴンからのパケットが、オレゴンのCloud Router経由でオンプレミスへ向かう。
  • 復路: オンプレミス側のルーターが「最良のパスは東京経由だ」と誤認し、東京のCloud Interconnectへパケットを投げ返す。

GCPのファイアウォールやステートフルなNATゲートウェイ、あるいはGoogle Cloud Firewallのコネクション追跡（Connection Tracking）は、異なるリージョンのエッジでパケットが不整合を起こすと、それを「不正なステートレスパケット」とみなしてドロップします。

対策：Terraformによるルーティングモードの明示的制御と検証

インフラの構成管理において、この設定をうっかりデフォルト（Global）のまま放置せず、アーキテクチャの要件に合わせて明示的にコード化することがテックリードとしての責務です。

以下に、Terraformを用いて明示的にリージョナルルーティングモードを設定し、Cloud Routerをデプロイする堅牢なコードスニペットを示します。

# VPCネットワークの定義（明示的にリージョナルモードを指定する場合の例）
resource "google_compute_network "vpc_network" {
  name                            = "production-core-vpc"
  auto_create_subnetworks         = false
  routing_mode                    = "REGIONAL" # グローバルではなくリージョナルを強制し、意図しないクロスリージョン経路伝搬を防止
  description                     = "厳格なリージョン分離とレイテンシ最適化のためのVPCファブリック"
}

# 東京リージョン用サブネット
resource "google_compute_subnetwork "tokyo_subnet" {
  name          = "subnet-tokyo-app-01"
  ip_cidr_range = "10.100.0.0/24"
  region        = "asia-northeast1"
  network       = google_compute_network.vpc_network.id
}

# 東京リージョンのCloud Router
resource "google_compute_router "tokyo_router" {
  name    = "router-tokyo-edge"
  region  = "asia-northeast1"
  network = google_compute_network.vpc_network.id
  bgp {
    asn               = 65001
    advertise_mode    = "CUSTOM"
    # 自リージョンのプレフィックスのみをアドバタイズ、あるいは厳密に制御
    advertised_groups = ["ALL_SUBNETS"]
  }
}

このコードでは、routing_mode = "REGIONAL" を明記することで、東京リージョンのCloud Routerが学習した経路が、無条件にオレゴンやヨーロッパのサブネットに波及するのを防いでいます。マルチリージョン展開において、各リージョンが独立した自律システム（AS）のような挙動を求める場合には、このリージョナルモードの選択が極めて有効な防衛策となります。

—

4. セキュリティとTLSハンドシェイクの観点から見た最適解

ネットワークのルーティングモードは、レイテンシやコストだけでなく、暗号化通信のパフォーマンス（TLSハンドシェイクのオーバーヘッド）にも直結します。

TLS 1.3の時代であっても、接続確立時の1-RTT（またはZero-RTT）ハンドシェイクにおいて、クライアントとサーバー間の物理的なラウンドトリップタイムが全体のレスポンスタイム（TTFB: Time to First Byte）を支配します。

もしグローバルルーティングモードの設計ミスにより、本来ならローカルのポッド/インスタンス間で完結すべきトラフィックが不必要に遠方のリージョンをホップしている場合、TLSの鍵交換フェーズ（Client Hello -> Server Hello -> Finished）における遅延が累積します。

特に、金融系やリアルタイム決済などのミリ秒単位のレイテンシがビジネス価値に直結するシステムでは、以下の原則を遵守すべきです。

1. データ locality の徹底: ユーザーに近いリージョンでリクエストを受け付け、VPC内のルーティングも極力同一リージョン（Regional Routing Mode）内で完結させることで、RTTを物理的限界まで切り詰める。
2. Anycastとの組み合わせ: Cloud CDNやCloud Load Balancingのグローバル外部HTTP(S)負荷分散と、VPC内のルーティングモードの整合性を検証し、エッジからバックエンドに至るまでのパケットの「最短経路（Shortest Path）」を常に担保する。

—

結びに代えて

GCPのVPCルーティングモードは、単なるネットワークのスイッチの切り替えではありません。それは、Googleの巨大なグローバルバックボーンという名の「高速道路網」に、あなたのアプリケーションのパケットをどう乗せるのかを決定する、極めて戦略的なアーキテクチャの意思決定です。

「とりあえずグローバル」という甘い罠を脱ぎ捨て、パケットがどこを通り、何ミリ秒の遅延を抱え、Linuxカーネルのバッファにどう負荷をかけているのか——その物理的実態に思いを馳せたネットワーク設計を、明日からのプロダクション環境にぜひ取り入れてみてください。

エッジを制する者が、クラウドインフラを制す。あなたの設計するネットワークが、最も美しく効率的なパケットの軌跡を描くことを願って。

スポンサーリンク

コメント

タイトルとURLをコピーしました