GCP VPCの「自動」という名の甘美な罠：アーキテクトがカスタムモードを選ぶべき必然的理由
クラウドアーキテクトとして多くのインフラをレビューする際、私は決まって「VPCのモードは何か？」という問いから始める。GCPのVPC作成画面でついクリックしてしまう「自動モード（Auto Mode）」は、確かにプロトタイピングには便利だ。しかし、真に可用性とスケーラビリティを突き詰めるべき本番環境において、それは「制御不能なブラックボックス」になり得る。
今回は、自動モードとカスタムモードの根本的な差異を紐解き、パケットレベル、そしてインフラ設計の深淵からその本質を浮き彫りにする。
—
1. 自動モードとカスタムモード：パケットの「帰属」を制御する
自動モードのVPCを作成すると、GCPは各リージョンに対して 10.128.0.0/9 の範囲内から /20 のサブネットを自動的に切り出し、配置する。これは便利だが、オンプレミスとのVPN接続や、組織間でのVPCピアリングを検討した瞬間に悪夢へと変わる。
なぜ「自動」がエンタープライズで忌避されるのか
ネットワーク設計の鉄則は「IP重複の回避」と「ルーティングの予測可能性」だ。自動モードでは、将来的にどの範囲のCIDRがどのリージョンに割り当てられるかが動的に決定される。
もし君がハイブリッドクラウドを構築していて、オンプレ側の 10.128.0.0/16 とGCPの自動生成されたサブネットが衝突したらどうなるか？ 経路情報の伝播（BGPの経路交換）において、より具体的なプレフィックス（Longest Prefix Match）を持つ経路が優先され、パケットは迷子になる。これが「通信が時々途切れる」という、最もデバッグが困難なネットワークの怪奇現象の正体だ。
# カスタムモードで明示的に定義するVPCの作成例
gcloud compute networks create my-hardened-vpc \
--subnet-mode=custom \
--bgp-routing-mode=global # 広域的な経路最適化のためグローバルモードを推奨—
2. ネットワークパフォーマンスの極致：TCPバッファとRTTの最適化
インフラエンジニアとして避けて通れないのが、TCPスタックのチューニングだ。VPCのサブネット設計が適切であれば、次はパケットが駆け巡るトランスポート層を最適化する。
特に、広域なリージョン間通信や、TLSハンドシェイクが頻発するWebサービスでは、TCP Window Size の枯渇がボトルネックとなる。GCPの仮想ネットワークにおいて、高いスループットを維持するには、以下のカーネルパラメータを調整し、パケットがバッファでドロップされるのを防ぐ必要がある。
# /etc/sysctl.conf での設定例
# 高帯域・長距離通信におけるウィンドウサイズ拡張
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCP Fast Openを有効化し、ハンドシェイクのRTTを削減
net.ipv4.tcp_fastopen = 3TCP Fast Open を導入することで、二回目以降の接続において、最初の SYN パケットにデータを埋め込むことが可能になり、TLSネゴシエーションのレイテンシを理論上1RTT削減できる。これは、モバイルユーザーのUXを劇的に改善する一手となる。
—
3. セキュリティとヘッダー圧縮：通信の「深層」
現代のネットワークセキュリティにおいて、パケットの可視化は必須だ。VPCフローログを活用し、特定のサブネット間での異常なトラフィックパターンを検知する。
また、Cloud CDN や HTTP/3 (QUIC) の採用は、トランスポート層の最適化において避けられない。QUICは UDP をベースとしており、TCPのヘッド・オブ・ライン・ブロッキングを解消するが、その分、コネクションの維持管理には注意が必要だ。
セキュリティ上の教訓：IPマスキングとファイアウォール
自動モードに頼りすぎると、サブネットが広大になりすぎ、ファイアウォールルール（ingress/egress）を「特定のIP帯域」で絞り込むことが困難になる。カスタムモードなら、サブネットを論理層（Web, App, DB）ごとに最小単位で分割できるため、ゼロトラストなネットワーク設計が容易になる。
# 最小権限の原則に基づくファイアウォールルール定義例
name: allow-app-to-db
direction: INGRESS
priority: 1000
sourceRanges: ["10.0.1.0/24"] # App層のみ許可
allowed:
- protocol: tcp
ports: ["5432"] # DB接続ポートのみ—
結論：自動化の先にある「最適化」
自動モードのVPCは、クラウドへの入り口としては優秀だが、システムの血流であるネットワークを適切に「制御」することはできない。
優れたインフラアーキテクトは、パケットの行き先を自らの手で定義し、カーネルレベルのバッファをチューニングし、TLSハンドシェイクのオーバーヘッドを削ぎ落とす。GCPが提供する強力なコンピュートリソースを最大限に活かすためには、まずは「VPCの制御権」を自らの手に取り戻すことから始めてほしい。
ネットワークは決して無機質な箱ではない。君が設定したパラメータの一つひとつが、パケットの呼吸となり、ユーザーの体験という名の血流を加速させるのだ。次回の構築では、ぜひ「カスタムモード」の選択肢を検討してほしい。そこには、予測可能な未来が待っている。
コメント