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

GCPのルーティングモードでハマる前に：グローバルか、リージョナルか。ネットワーク設計の「正解」を紐解く

ネットワークエンジニアとして現場に立っていると、「とりあえずグローバルルーティングモードにしておけば安心でしょ？」という安易な設計に遭遇することがあります。確かに、GCPのVPCはデフォルトでグローバルルーティングモードですが、それがあなたのWeb APIやマイクロサービスにとって「最適解」であるとは限りません。

今日は、パケットがVPCの境界を越えるとき、裏側で何が起きているのか。そして、なぜあなたのサービスが「リージョナル」を選択すべき瞬間があるのかを、現場の知見を交えて解説します。

—

1. ルーティングモードとは何か？：パケットの「地図」の持ち方

GCPのVPCネットワークにおけるルーティングモードは、「Cloud Routerが学習した動的ルートや、ユーザーが作成したスタティックルートを、VPC内のどの範囲にまで伝搬させるか」を決定するフラグです。

リージョナルルーティングモード

挙動: ルート情報は「そのリージョン内」でのみ有効です。
メリット: ルーティングテーブルがシンプルになり、意図しない経路制御（例えば、東京から米国経由で戻ってくるようなループ）を物理的に防げます。
向いているケース: 低レイテンシが命のAPI、あるいはリージョン間を厳密に分離したいマルチリージョン構成。

グローバルルーティングモード

挙動: VPC内のすべてのリージョンにルートが伝搬します。
メリット: 設定が楽です。どのリージョンからでも、他のリージョンのサブネットへ（Cloud Router経由で）到達可能になります。
向いているケース: ネットワーク構成を意識せず、とりあえずフルメッシュに繋ぎたい開発初期段階や、小規模な拠点間接続。

—

2. 現場で直面する「グローバルモード」の落とし穴

多くのエンジニアが陥る罠は、グローバルモードの「広範囲な伝搬」による非対称ルーティングです。

例えば、東京リージョン(asia-northeast1)と米国リージョン(us-central1)でVPNを張っているとします。グローバルモードでは、東京のCloud Routerが受け取ったルートが米国にも伝搬されます。もし米国側のトラフィックが、東京を経由してインターネットへ抜けようとした場合、思わぬ高遅延や帯域圧迫を招きます。

gcloudでのルーティングモード確認方法

まずは現在、自分のネットワークがどちらの設定になっているか確認しましょう。

# 現在のVPCネットワークのルーティングモードを確認
gcloud compute networks describe [VPC_NAME] \
    --format="get(routingConfig.routingMode)"

もし「リージョナル」へ変更したい場合は、慎重に行う必要があります（既存の通信が切れるリスクがあるため）。

# リージョナルモードへの切り替え（本番環境ではメンテナンス時間中に！）
gcloud compute networks update [VPC_NAME] \
    --routing-mode=REGIONAL

—

3. 実践：Pythonで疎通確認を自動化する

ネットワーク設計の変更前後には、必ず疎通試験が必要です。以下は、異なるリージョン間でのレイテンシと到達性を確認するためのシンプルなPythonスクリプトです。これをCI/CDパイプラインに組み込むと、「設定変更でAPIが繋がらなくなった」という事故を防げます。

import os
import subprocess

# 疎通確認先のリスト（VPC内のIPアドレス）
targets = ["10.128.0.5", "10.140.0.5"] 

def check_connectivity(ip):
    # pingコマンドで疎通確認
    response = subprocess.call(["ping", "-c", "3", "-W", "2", ip])
    if response == 0:
        print(f"[OK] {ip} への到達を確認しました。")
    else:
        print(f"[NG] {ip} への疎通ができません。ルーティング設定を確認してください。")

if __name__ == "__main__":
    for ip in targets:
        check_connectivity(ip)

—

4. Web API設計における戦略的Tips

インフラ側でグローバルルーティングモードを採用している場合、アプリケーション側でも意識すべきことがあります。特に、マイクロサービスが異なるリージョンのデータベースやキャッシュ（Memorystore等）を参照する場合です。

HTTPヘッダーの活用: X-Forwarded-For や X-GCP-Region などのカスタムヘッダーを付与し、どのリージョンを経由したパケットかをアプリケーションレイヤーで追跡できるようにしておくと、障害時の切り分けが劇的に速くなります。
Fetch APIでのタイムアウト制御: グローバルルーティングモードの複雑な経路では、時折パケットロスが発生します。タイムアウトは必ず短めに設定し、リトライ戦略を考慮してください。

// Fetch APIでのタイムアウト実装例
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 2000); // 2秒でタイムアウト

fetch('https://api.internal-service.local/v1/data', {
  signal: controller.signal
})
.then(response => response.json())
.catch(err => {
  if (err.name === 'AbortError') {
    console.error('リージョン間通信のタイムアウトを検出');
  }
});

—

最後に：ネットワークは「見えないコード」である

クラウドインフラは抽象化されていますが、パケットの旅路は物理的な制約を受けます。「設定が簡単だから」という理由でグローバルモードを選択するのではなく、「なぜそのモードが必要なのか」という意図を設計書に残してください。

リージョナルルーティングモードは、ネットワークを「整理整頓」するための強力な武器です。大規模な構成になればなるほど、ルートをリージョンという箱に閉じ込めることで、障害範囲の極小化が可能になります。

皆さんの構築するクラウドネットワークが、より堅牢で、かつトラブルシューティングのしやすいものになることを願っています。もし不明点があれば、いつでもコマンドを叩いて、パケットの向こう側を覗いてみてください。