こんにちは！SREとして日々クラウドのインフラやネットワークの海を泳いでいるライターの私です。
AWSやGCPといったメガクラウドの世界に飛び込むと、最初に出会う巨大な壁の一つが「ネットワーク」ですよね。「サブネット」「ルーティング」「ファイアウォール」……。単語だけでもお腹いっぱいになりそうですが、特にGCPを触り始めると、誰もが一度はこの言葉に驚かされます。
「GCPのVPCは、世界中のリージョンをまたぐグローバルネットワークなんですよ」
……えっ？ 東京とアメリカのサーバーが、まるで同じオフィスの隣の机にあるかのように、同じプライベートIPアドレスで直接通信できるってどういうこと！？ と思いませんでしたか？
今回は、このGCPの「グローバルVPC」という魔法のような仕組みの裏側を、難しい専門用語のジャングルを避けて、身近な例えを交えながら一歩ずつ一緒に紐解いていきましょう！
—
1. そもそも「VPC」ってなんだっけ？（現実世界の郵便システムに例えてみよう）
ネットワークの世界に初めて触れるとき、私たちはよく「手紙や荷物の配達」に例えて考えます。
いま、あなたが東京にいて、大阪の友人へ荷物を送りたいとします。
- 宛先には、相手の「住所（IPアドレス）」を書きますよね。
- 荷物は、道路（ネットワーク経路）を通って、途中の郵便局（ルーター）を経由し、相手の家に届きます。
従来のクラウドや、昔ながらのオンプレミス（自社サーバー）の世界では、「東京の郵便局」と「大阪の郵便局」はまったく別の独立した世界でした。東京から大阪へ荷物を送るには、わざわざ一度「関所（VPNや専用線）」を通し、お互いのルールを確認し合わなければならなかったのです。
しかし、GCPの「グローバルVPC」の考え方は、これとは全く違います。
GCPのグローバルVPCは「全国共通の巨大なマンション」
GCPのVPCをイメージするときは、「世界中に棟（リージョン）が建っているけれど、管理組合とルールがすべて共通の、超巨大なグローバルマンション」を想像してください。
このマンションでは、東京棟に住む人（サーバーA）も、アイオワ（アメリカ）棟に住む人（サーバーB）も、同じ「VPC」という巨大な屋根の下に暮らしています。
だから、東京棟の住人がアメリカ棟の住人に手紙を出すとき、わざわざ厳重な「関所」を通る必要がありません。マンション内の内線電話や、同じ敷地内の回覧板のように、自然にプライベートな空間でやり取りができてしまうのです。
これが、GCPが誇る「グローバルVPC」の正体です。
—
2. なぜそんな離れた場所が「同じ空間」でつながるの？（裏側の仕組み）
「でもさ、東京からアメリカまで、実際には海を越えて数千キロも離れているよね？ どうやってひとつの空間に見せかけているの？」
鋭い疑問ですね！ ここで、GCPの「コントロールプレーン（頭脳）」と「データプレーン（実際の道路網）」の話を少しだけしましょう。
GCPは、世界中に自分たちの専用の海底ケーブルや超高速なバックボーンネットワークを持っています。いわば、Googleが世界中に張り巡らせた「超特急の新幹線専用レール」です。
私たちがGCP上で「東京とアイオワを同じVPCにするぞ！」と設定すると、GCPの頭脳（コントロールプレーン）が裏側で次のような魔法をかけます。
1. グローバルIP管理の統一: VPCという大枠の中では、世界中のどこにサブネット（部屋）を作っても、お互いのIPアドレスの重複がチェックされ、ひとつの巨大な住所録として管理されます。
2. Googleプライベート網の活用: パケット（データ）が東京のサーバーから送り出されると、パケットはいったんパブリックなインターネット（危険な一般道）には出ず、Googleが完全に管理する超高速なプライベートネットワーク（専用特急レール）に乗せられます。
3. カプセル化とルーティング: パケットはGoogleのネットワーク内を光の速さで駆け抜け、海を越えて瞬時にアメリカのサーバーの足元まで届けられます。
つまり、「物理的な距離は遠いけれど、Googleが用意してくれた超高速な専用道路のおかげで、まるで同じ部屋にいるかのように通信できる」ということなんです。
—
3. 実践！グローバルVPCを作ってみよう
百聞は一見にしかず。実際にGCPでこのグローバルな空間を作ってみましょう。
今回は、GCPのコマンドラインツールである gcloud を使って、東京 (asia-northeast1) と アイオワ (us-central1) にまたがるカスタムVPCネットワークを作る設定例を見てみます。
実務や開発の現場でそのまま参考にできるよう、丁寧にコメントを入れました。
# 1. まず、グローバルでひとつの「カスタムVPCネットワーク」を作成します
# ※ ここがすべての基本となる「巨大なマンションの土地」を買い取るイメージです
gcloud compute networks create my-global-vpc \
--subnet-mode=custom \
--description="世界中をひとつなぎにする私たちのグローバルVPC"
# 2. 東京リージョン（アジア・東日本）にサブネット（部屋）を作ります
gcloud compute networks subnets create subnet-tokyo \
--network=my-global-vpc \
--region=asia-northeast1 \
--range=10.100.1.0/24 \
--description="東京リージョンのプライベート空間"
# 3. アイオワリージョン（アメリカ中部）にサブネット（部屋）を作ります
gcloud compute networks subnets create subnet-iowa \
--network=my-global-vpc \
--region=us-central1 \
--range=10.100.2.0/24 \
--description="アイオワリージョンのプライベート空間"このたった数行の設定を行うだけで、東京の 10.100.1.x というIPを持つサーバーと、アイオワの 10.100.2.x というIPを持つサーバーが、追加のVPN設定なしで、直接プライベートIPアドレスを使って通信できるようになります。すごいですよね！
—
4. 現場のSREが教える！グローバルVPC設計の注意点とリアルなメリット
このグローバルVPC、何でもかんでも一つのVPCにまとめればハッピーかというと、現場のSREとしては少しだけ注意すべきポイントもあります。最後に、実務で役立つ生きた知見をいくつかシェアしますね。
メリット：何が最高なの？
- 管理の圧倒的なシンプルさ: リージョンごとに複雑なVPNゲートウェイやルーティングテーブルを組み合わせて接続する必要がありません。「VPCがひとつ」なので、セキュリティポリシー（ファイアウォールルール）も一元管理しやすく、設定ミスを減らせます。
- レイテンシー（遅延）の低さ: ユーザーからのリクエストをGoogleの最寄りのエッジで受け取り、そこからGoogleの超高速バックボーンに乗せて各リージョンのバックエンドへ安全に運べるため、通信品質が非常に安定します。
注意点：気をつけるべきことは？
- IPアドレス枯渇の罠: グローバルでVPCをひとつにすると、社内や他のシステムとのIPアドレスの重複（CIDRブロッキング）問題が起きやすくなります。「適当に大きな範囲を取ったら、後から別のシステムと繋げられなくなった…」というのは、インフラあるあるの悲劇です。
- 「遠い場所」の物理的限界を忘れないこと: ネットワークがスムーズに繋がるとはいえ、光が東京からアイオワ（地球の裏側）まで届くには、物理的な時間の壁（伝搬遅延）がどうしても存在します。「同じVPC内だから」といって、東京とアイオワの間でデータベースの同期をミリ秒単位の超高速でやろうとすると、物理法則に嫌われて失敗します。
—
まとめ
いかがでしたでしょうか？
今回は、GCPのグローバルVPCの仕組みについて、現実世界の例えや実際のコマンドを交えながら解説しました。
- GCPのVPCは、世界中のリージョンをひとまとめにする「グローバルな空間」である。
- 物理的な距離の壁は、Googleが誇る圧倒的な専用バックボーンネットワークが裏側で支えてくれている。
- 設定はシンプルだが、IPアドレスの設計や物理的な遅延への配慮はSREの腕の見せ所！
クラウドインフラの世界は、一見すると難解な用語の連続ですが、その本質を紐解いていくと「私たちが普段使っている仕組みの超巨大版」であることがよく分かります。
ぜひ、皆さんもご自身のハンズオン環境でグローバルVPCを立ち上げ、東京と海外のリージョン間でパケットを飛ばしてみてくださいね。それでは、次回のクラウドインフラ解説でお会いしましょう！
コメント