はじめに
こんにちは、とある初級インフラエンジニアです。 来月から参画するGCP案件（金融系）に向けて、設計・構築のキャッチアップを進めています。
前回の「予算アラート」に続き、今回はネットワーク（VPC）の検証を行いました。 そこで、従来のクラウド（AWS等）の常識を覆す、GCP特有の「グローバルVPC」という概念に衝撃を受けたので、検証結果を共有します。
クラウドエンジニアが抱く「VPCの常識」
通常、VPC（仮想ネットワーク）を作成する際、まず考えるのは「どのリージョンに作るか？」です。
これが一般的なクラウドのネットワーク設計です。 しかし、GCPのドキュメントには「VPC はグローバル リソースです」と書かれています。 正直、文字で読んでもピンと来なかったので、実際に環境を作って試してみました。
検証構成：東京と大阪を「同じVPC」に入れる
今回は以下の構成で検証を行いました。
-
VPC:
vpc-handson-01を1つだけ作成（グローバル） -
サブネットA: 東京リージョン (
10.0.1.0/24) -
サブネットB: 大阪リージョン (
10.0.2.0/24) -
VM: それぞれのサブネットに1台ずつサーバーを構築
驚いたポイント VPCを作成する段階で、リージョンを選択する必要がありませんでした。 「VPC」という大きな箱の中に、「東京の部屋」と「大阪の部屋」を同居させる設定があっさりと完了しました。
実験：PeeringなしでPingは通るのか？
東京のVMから、大阪のVMのプライベートIPに向けてPingを打ってみました。 ルーティングテーブルの設定も、Peeringの設定も一切していません。
# 東京(10.0.1.x) から 大阪(10.0.2.x) へ
ping -c 4 10.0.2.2
結果： 何事もなくPingが返ってきました。 まるで同じデータセンター内の隣のラックにあるサーバーと通信しているような感覚です。
なぜこれが可能なのか？ GCPのVPCは世界中のリージョンにまたがって存在できるため、リージョン間の通信もGoogleのバックボーンネットワーク（専用線）を通って、デフォルトでルーティングされる仕様になっているそうです。 マルチリージョンでDR（災害復旧）構成を組む際、この仕様は圧倒的に設計コストを下げてくれると感じました。
ハマりポイント：SSH接続が遅い…？
スムーズにいったように書きましたが、1点だけ躓いたことがありました。 VMを作成直後、SSH接続（ブラウザコンソール）を試みたところ、接続確立までに異常に時間がかかる（またはタイムアウトする） 現象が発生しました。
原因：ファイアウォール設定 GCPのファイアウォールは「デフォルトですべて拒否（※プロジェクト作成時のdefaultネットワーク以外）」です。 「内部通信（10.0.0.0/16）」を許可するルールは入れていたのですが、「SSH接続（外部からのアクセス）」を許可するルールを入れ忘れていました。
AWSのSecurity Groupのような「インスタンス単位」の設定ではなく、「VPC全体に対するルール」として以下を追加することで解消しました。
また、設定画面で「ファイアウォール ポリシー」と「ファイアウォール ルール」という似たメニューがあり迷いましたが、今回は従来のシンプルな「ルール」の方を使用しました。
まとめ
今回の検証で分かった、GCPネットワークの強みは以下の通りです。
「AWSとは作法が違う」と聞いてはいましたが、ここまで物理的な距離を感じさせないアーキテクチャだとは思いませんでした。 次回は、この環境を使ってさらに踏み込んだ設定を試してみたいと思います。
↓IT転職をお考えの方はコチラ↓
