ネットワークの「わらしべ長者」は許されない？VPCピアリングと「推移的ルーティング」の真実
こんにちは！SREの現場では日々、目に見えないパケットの旅路に思いを馳せているエンジニアです。
皆さんは、AWSやGCPで複数のVPC（Virtual Private Cloud）を繋ぐとき、真っ先に思い浮かべるのは何でしょうか？そう、「VPCピアリング」ですよね。手軽に2つのネットワークを直結できるこの機能、実は「推移的（すいいてき）ルーティングができない」という、ちょっとワガママなルールがあるのをご存知でしたか？
今回は、インフラ初学者の皆さんが一度はつまずくこの「VPCピアリングの制約」を、郵便局の配達ルールに例えながら紐解いていきましょう！
—
1. 「推移的ルーティング」って、どういうこと？
まずは言葉の意味から優しく整理していきましょう。「推移的」といっても、難しいことはありません。
例えば、A地点（VPC-A）からB地点（VPC-B）へ荷物を送り、さらにB地点（VPC-B）からC地点（VPC-C）へ荷物を転送してもらうような状況を想像してください。
- 推移的ルーティングができる世界： A → B → C と、荷物を中継して目的地まで運べる。
- VPCピアリングの世界： 「Aさんから来た荷物を、そのままCさんに横流しすることは禁止！」というルールがある。
これが「非推移的」という制約の正体です。「直接繋がっている相手としか通信できない」という、非常に厳格な「一対一の付き合い」を求められるのがVPCピアリングの性格なのです。
なぜこんな制限があるの？
もしこれが許されると、ネットワークが複雑に絡まりすぎて、どこでパケットが迷子になっているのか、どのルートを通るのが最短なのかを把握することが、エンジニアの手に負えないほど難しくなってしまうからです。安定性を守るための「優しい制限」とも言えますね。
—
2. メッシュ構造の罠：ルートテーブル設計の現実
では、VPC-A、VPC-B、VPC-Cの3つすべてを繋ぎたい場合はどうすればいいでしょうか？
「AとBを繋ぎ、BとCを繋げば、AとCも繋がるでしょ？」と思いたくなりますが、先ほどのルールの通り、それはできません。
結局、以下のように全ての組み合わせを繋ぐ「フルメッシュ構成」にする必要があるのです。
1. AとBを繋ぐ（ピアリング）
2. BとCを繋ぐ（ピアリング）
3. AとCも直接繋ぐ（ピアリング）
数が増えてくると管理が大変になりますよね？これが、VPCピアリングを使いすぎると「ネットワークのスパゲッティ化」を招くと言われる理由です。
ルートテーブルの設定例（Terraform風）
AWSでのルート設定をイメージしてみましょう。10.0.0.0/16（VPC-A）から 10.1.0.0/16（VPC-B）へ向かうためには、明示的に「こっちへ行け」と教えてあげる必要があります。
# VPC-Aのルートテーブル設定
resource "aws_route" "to_vpc_b" {
route_table_id = "rtb-abc12345" # VPC-Aのルートテーブル
destination_cidr_block = "10.1.0.0/16" # 相手先のVPC-BのIP範囲
vpc_peering_connection_id = "pcx-12345678" # ピアリング接続IDを指定
}
# ポイント：VPC-Cへ行くには、VPC-B経由ではなく、
# VPC-Cへの直接のルートをここに追加しなければなりません！—
3. この壁を乗り越える「大人の解決策」
「じゃあ、VPCが増えたら管理しきれないじゃん！」という声が聞こえてきそうです。その通り。実務では、この制約を突破するために「ハブ＆スポーク」というアーキテクチャを使います。
- Transit Gateway (AWSの場合) などの「中継専用ルーター」をVPCの間に配置する。
- このルーターが、いわば「郵便物の仕分けセンター」のように、各VPCからのパケットを中継してくれる仕組みです。
これなら、VPCの数が増えても、全てのVPCをこの「仕分けセンター」に繋ぐだけで、推移的な通信が可能になります。
—
最後に：ネットワーク設計は「地図」を描くこと
ネットワークの設計は、パケットという小さな郵便配達員に、「どの道を通れば迷わずに目的地へ着けるか」という地図を渡す作業です。
VPCピアリングの制限は、最初は「不便だな」と感じるかもしれません。しかし、「どこからどこへパケットが流れているかを明確に把握する」というインフラの鉄則を学ぶには、これ以上ない教材です。
まずは2つのVPCを繋ぐところから。そして、数が増えてきたらTransit Gatewayを検討する。そんなふうに、一歩ずつアーキテクチャの階段を登っていきましょう！
皆さんのクラウドインフラ構築が、迷子のパケットのない、健やかなものになりますように。それでは、また次回の記事でお会いしましょう！
コメント