本記事は Google Cloud Japan Advent Calendar 2022 の通常版 の 25 日目の記事です。
皆様、いかがお過ごしでしょうか？ Google Cloud カスタマーエンジニアの大嶋です。
本記事では、 Network Connectivity Center (以下NCCを略称) のサイト間データ転送 についてご紹介します。
海外に事業を展開している企業がGoogle Cloudをグローバル規模で導入した場合、複数のオンプレミス拠点（例えば、東京本社、大阪支社、インド支社、東京データセンターなど）からGoogle Cloudへハイブリット接続すると以下のようなネットワーク要件が考えられます。
- 各オンプレミス拠点からGoogle Cloud の Virtual Private Cloud（VPC)へのサイトツークラウド 接続
- Google のバックボーンを広域ネットワーク（WAN）として使用し、オンプレミス拠点間のデータ通信を行う サイト間データ転送
今回は、最近実務で既存契約の30MbpsグローバルWAN回線における費用圧縮と帯域幅の増強を必要とするお客様にNCCのサイト間データ転送をご提案していることもあり、後者の「サイト間データ転送」について説明していきます。
Google Cloudの活用と聞くと、コンピューティングリソースやデータ分析基盤、そして機械学習サービスなどが真っ先に思い浮かぶかもしれませんが、この記事を読んで NCC と Google Cloudのネットワーク活用に少しでも興味をもって頂けたらと思います。
Network Connectivity Center (NCC) の概要
まずは、NCC の概要を説明します。NCCは、Googleのグローバルインフラストラクチャを活用し、オンプレミス拠点からの異なるネットワーク接続や他社クラウドネットワークとの接続を簡単に作成、接続、管理する事を目的としたGoogle Cloudの統合ネットワーク接続管理ソリューションです。
2021年10月18日に一般提供開始となっており、以下のように Google Cloud コンソールだと「ハイブリッド接続」メニューから設定します。
NCC は、2022年12月25日時点で、米国、英国、インド、オーストラリア、日本を含む5つの拠点 の14ロケーション で一般提供しています。そうです、日本でもご利用頂けます!
他の拠点も順次対応予定となっています。
NCC の構成とサイト間データ転送の接続フロー
NCC は以下図のようにハブ-スポークモデルで構成されます。
上記のオンプレミス拠点である、東京データセンターと大阪支店間でのデータ転送を行うまでの接続フローは以下の通りです。
1. 図上の各オンプレミス機器（CPE）とルーター アプライアンス間で、SD-WAN オーバーレイ トンネルや IPsec VPN トンネルなどのネットワーク接続を確立します。
2. 各ルーター アプライアンスはスポーク リソースとして NCC ハブに接続し、東京DCのnetwork A と大阪支社の network B が相互にデータを送信するためのサイト間データ転送を有効にします。サイト間データ転送は、先に説明したサポートロケーション のみで利用可能です。
3. 各リージョンで、ルーター アプライアンスとCloud Router間で Border Gateway Protocol（BGP）ピアリングを確立します。次に各 Cloud Router は、対向のオンプレミスの拠点からルート プレフィックスを受け取ってルーター アプライアンスにアドバタイズします。
4. 各 Cloud Router は、受信したすべてのルートを動的に交換し、東京データセンターの network A と 大阪支店の network B 間でエンドツーエンドの動的ルート交換およびデータプレーン接続を開始します。
今回の構成は、東京⇔大阪間という国内拠点接続ですが、もちろんサポートロケーションであれば、東京⇔LA、大阪⇔ムンバイなどグローバル拠点とのデータ転送を Google バックボーン経由で行うことも可能です。
設定例
では、実際に設定してみます。
構成は、以下の図にある NCC ハブと Cloud VPN スポークを設定し、2つのオンプレ拠点間のデータ転送を Google バックボーン経由で行います。
手順は以下の通りです。
- テストに必要な以下ネットワークリソースの構築
- VPC network-a の作成（動的ルーティングモードをglobalに！理由はこちらを参照)
- vpc-office1,vpc-office2,Firewall rule x3、VPN tunnel x8、Cloud router x4、BGP sessions x8
- NCC ハブ(my-hub)の設定
- スポークの作成と スポークのリソースの設定
- テスト用仮想マシンの設定と疎通確認
1. テストに必要なネットワークリソースの設定
まずは、以下の構成を構築します。(テスト用の仮想マシンは最後に設定します）
VPC network-a を作成
gcloud compute networks create --subnet-mode=custom --bgp-routing-mode=global network-a
office1のVPCとSubnetを作成します。コマンドは以下：
gcloud compute networks create vpc-office1 --project=<自分のプロジェクトID> --subnet-mode=custom --mtu=1460 --bgp-routing-mode=regional
gcloud compute networks subnets create office1-subnet --project=<自分のプロジェクトID> --range=10.2.0.0/16 --stack-type=IPV4_ONLY --network=vpc-office1 --region=us-west1
以下設定結果：
- office2も同様にVPCとSubnetを作成します。**
gcloud compute networks create vpc-office2 --project=<自分のプロジェクトID> --subnet-mode=custom --mtu=1460 --bgp-routing-mode=regional
gcloud compute networks subnets create office2-subnet --project=<自分のプロジェクトID> --range=10.3.0.0/16 --stack-type=IPV4_ONLY --network=vpc-office2 --region=us-east1
Firewall ルールを３つ作ります。（ブログ用のテスト環境なので特にIPアドレスやプロトコルの制限は設定していません。）
gcloud compute --project=<自分のプロジェクトID> firewall-rules create vpc-office1-fw --direction=INGRESS --priority=1000 --network=vpc-office1 --action=ALLOW --rules=all --source-ranges=0.0.0.0/0
gcloud compute --project=<自分のプロジェクトID> firewall-rules create vpc-office2-fw --direction=INGRESS --priority=1000 --network=vpc-office2 --action=ALLOW --rules=all --source-ranges=0.0.0.0/0
gcloud compute --project=<自分のプロジェクトID> firewall-rules create network-a-fw --direction=INGRESS --priority=1000 --network=network-a --action=ALLOW --rules=all --source-ranges=0.0.0.0/0
コンソールで設定を確認します。
続けて、VPN tunnel x8、Cloud router x4、BGP sessions x8を設定します。
設定方法はこちらのドキュメントを参考にしました。
もし、「ドキュメントを見てもよく分からん！」と思われた方は、Google Cloud Skillboost のアカウント登録後、Configuring Network Connectivity Center as a Transit Hubのラボが今回の構成と類似していますので、チャレンジされると良いかと思います。Google Cloud Skillboost のラボは、詳細な設定手順を示すチュートリアルと設定画面のスクリーンショット付きで説明していますので、はじめてGoogle Cloud を設定される方にもオススメしたい学習方法です。 Google Cloud Skillboost の概要やアカウント登録方法については、こちらで説明しています。
また、設定前に各VPNトンネルのIPアドレスを示す簡易ネットワーク図を用意し、それを確認しながら設定を進めることをオススメします。VPNトンネルは拠点ごとに２本ｘ２拠点で合計４本ですが、Google Cloud 上の設定は、対向ペアで双方向に設定する為、計８個の VPN トンネル設定が必要となります。また、そのVPNトンネル毎に BGP 設定を行うため設定項目が多く構成図でIPアドレスとネットワーク構成の整理ができてないと混乱しがちです。（私だけかもしれませんが・・・）
以下が設定結果です。
2. NCC ハブ(my-hub)の設定
次に、NCC の Hub と Spoke を設定します。
まずは、Hubから。
ここからの手順はこちらのドキュメントを参考にしています。
ハブを設定するには、gcloud network-connectivity hubs create コマンドを使用します。
以下コマンドの my-hub の部分は、新しく作成する Hub の名前を入力し、--description="ncc-hub"の部分は省略可能です。
gcloud network-connectivity hubs create my-hub --description="ncc-hub"
設定が完了しました。まだスポークを設定していないのでスポークのカウントは 0 の状態です。
3. スポークの作成とスポークのリソースの設定
スポークを作成するには、gcloud network-connectivity spokes linked-vpn-tunnels create コマンドを使用します。1. のステップで設定した2つの HA VPN トンネル(vpn-tunnel1-1、vpn-tunnel1-1-2)を office-1-spoke の基盤リソースとして設定します。
gcloud network-connectivity spokes linked-vpn-tunnels create office-1-spoke --hub=my-hub --vpn-tunnels=vpn-tunnel1-1,vpn-tunnel1-1-2 --region=us-west1 --site-to-site-data-transfer
続けて、Office2 のスポークを作成します。こちらも2つの HA VPN トンネル（networka-to-office2-tu1、networka-to-office2-tu2)を office-1-spoke の基盤リソースとして設定します。
gcloud network-connectivity spokes linked-vpn-tunnels create office-2-spoke --hub=my-hub --vpn-tunnels=networka-to-office2-tu1,networka-to-office2-tu2 --region=us-east1 --site-to-site-data-transfer
Hub と Spoke x2 の設定が完了しました。
4. テスト用の仮想マシンの設定と疎通テスト
以下の構成で、仮想マシン２台を追加後、疎通テストを行います。
Office1の拠点とOffice2の拠点間で Ping 疎通テストを行う為の仮想マシン２台を設定します。
Office1拠点 → Office2拠点へのPing疎通確認
office1-vm に SSH でログインし、office2-vm1 の内部IP アドレス 10.3.0.2/16 にPingします。
結果、Office1の仮想マシン→Office2の仮想マシンへの疎通がOKとなりました。
Office2拠点 → Office1拠点へのPing疎通確認
office2-vm に SSH でログインし、office1-vm1 の内部IP アドレス 10.2.0.2/16 にPingします。
こちらも問題なく疎通できました。
試しに、NCCが実際に拠点間のルーティングに関与しているのかを確認する為に office-2-spoke を削除し、同じPingテストをやってみます。
想定通り、どちらの仮想マシンからも疎通NGとなりました。
では、再度 office-2-spoke を設定し、拠点間の疎通が以前のようにOKとなるか確認します。
気持ちよくPingが双方の仮想マシンから通るようになりました。Pingがこのようにサクサクと通る時って本当に気分がいいですよね！
NCC トラブルシューティング情報
設定がうまくいかない、もしくはトラブルシューティングが必要な場合、まずはこちらの考慮事項から既知の問題について確認することをお勧めします。
次にログの確認ですが、NCCの ハブのログは、Logging に送信されます。ログの確認方法や説明については、こちらのドキュメントをご確認ください。
Google Cloud のバックボーンネットワーク
ここでは、少しでも多くのお客様にリーチできるよう拡大を続けている Google Cloud のバックボーンネットワークについてご紹介したいと思います。以下は、2022年12月25日現在の Google Cloud のロケーションと ネットワーク網の配置図となります。
上記の図にあるように、Google Cloud Network は、200 以上の国と地域にまたがる 35 のリージョン、106 のゾーン、173 のネットワーク エッジ ロケーション でサービスを提供しており、今も継続的にグローバルインフラストラクチャへの投資を行っています。この理由として、クラウドにおけるネットワークはまさにデジタルの神経系であり、高品質なクラウドサービスをお客様に提供するにはネットワークとセキュリティポートフォリオの強化が必須だからです。
更に、Google は、世界中のネットワークの網羅性の確保、そして広帯域で低遅延のグローバルネットワークを実現すべく世界中の電気通信事業者パートナーとともに、これまで22か所の海底ケーブル プロジェクトに投資してきました。そうです、Google はYouTubeや検索エンジンというグローバルインターネットサービスや Google Cloud サービスを高品質かつ安定して提供する為に海底ケーブルの設置にも貢献しているんです。
これは、私達日本人の生活にも関係していて、最近、初めて日本とカナダを結ぶ光ファイバーケーブルとして新しい海底ケーブル「Topaz」の設置について今年の4月6日に発表しています。このケーブルは 2023年の開通を予定しており、Google 検索、Gmail、YouTube、Google Cloud、その他の Google サービスへの低遅延アクセスを提供するだけでなく、日本とカナダのさまざまなネットワーク事業者とも共有し、この地域での伝送容量を拡大させる予定です。
Topaz に関する詳しい発表内容は、こちらのブログでご紹介しております。ネットワークに関心がある方にはとても興味深い内容となっています。
また2022年11月18日に発表したこちらのブログでは、今何かと話題の太陽嵐による海底インターネットケーブル機能への影響について Google の科学者チームによる検証と評価結果について発表しています。
このように日夜皆様の生活に必須となっているネットワーク通信の保全にも深く関わっている Google なのです。私は昨年Google Cloud に入社しましたが、このようなネットワークに対する投資や取り組みについて少しでも多くのお客様に知ってもらい、素晴らしいグローバルネットワークバックボーンをもつ Google Cloud の良さを理解頂けるよう日々お客様にご紹介しています。
最後に
いかがでしたでしょうか。
ここまでお読み頂いた方は、かなりネットワークにご感心があるのではないでしょうか。
私もこのあたりの回線やグローバルネットワーク網については昔から興味があり、2003年にネットワークエンジニアとして働き始めてから来年で20年目のキャリアとなります。
振り返れば、2013年頃、外資系テレコム会社でアーキテクトとして稼働していた頃からGoogle やパブリッククラウド企業による国際回線網利用について耳にする機会が増え、「将来はGoogle や Public Cloud 企業が通信業も行い、グローバルネットワーク回線の発展に貢献していくだろう」と感じていました。Google Cloud に入社してから、その予想は現実となっていると感じています。
今回のご紹介で、Google Cloud ネットワークの活用について少しでも興味を持っていただければ幸いです。
Discussion