Zenn
🔥

Network Connectivity Center(NCC) で 2 ホップ制限に勝ちたかった

に公開
network
Google Cloud
VPC
ncc
Private Service Connect
tech

TL;DR

  • NCC を使うと、VPC やオンプレミスとのフルメッシュ接続が簡単に構築・管理可能
  • ただし、VPC ピアリング(Private Service Access 含む)による 2 ホップ制限には注意

はじめに

みなさん、こんにちは。クラウドエースの田中です。

先日、以下の記事を公開しました。

今回のネットワークギルドからの Zenn 記事は、上記の記事の続編として、Google Cloud の Virtual Private Cloud(以下、VPC) における 2 ホップ制限を回避すべく、Network Connectivity Center(以下、NCC) を使ってみた、という記事になります。

最後までお読みいただけたら幸いです。

VPC における推移的接続の制限(おさらい)

簡易構成図

VPC における推移的接続の制限とは、上の図でいう VPC-a と VPC-c の間には接続が確立されない、ということです。これを 2 ホップ制限ともいいます。

前回の記事では踏み台 VM を用意しましたが、NCC もこの制限をくぐり抜けるための有力な選択肢となります。

Network Connectivity Center を活用する

VPC 間の接続が必要な場合、一般的には Cloud VPN や VPC Peering が用いられてきました。

Google Cloud にはさらに、Network Connectivity Center (以下、NCC) というプロダクトがあります。こちらは 2021 年 10 月に GA (一般提供) になりました。

これまでは下図のように、VPC それぞれに対して接続したい VPC との VPC ピアリングを設定する必要がありました。
そのため、VPC の増設にともない VPC ピアリングも増加し、管理コストが非常に高くなってしまいました。

これまで

これが NCC によって、ハブを中心としたフルメッシュ接続をカンタンに構築でき、アーキテクチャをシンプルにし、管理運用コストを大幅に削減することができます。

NCCを使うとこうなる

NCC ではハブと呼ばれるリソースを中心に、以下のスポークを接続することで、上記の構成を実現します。

NCC を使ってやりたいこと

構成図1

以前の記事と同じく、以下の両者の接続を目指します。具体的には、ビルド中にデータベースにアクセスする必要があるケースを想定しています。

  • PSC エンドポイント有効化済み Cloud SQL インスタンス
  • Cloud Build プライベートプール

ここでのポイントは、Cloud SQL インスタンスへの通信が PSC エンドポイントを経由することです。
実は NCC では、2025 年 2 月 26 日のリリースにて、Private Service Connect(以下、PSC) エンドポイントの伝播 (Propagation) 機能が GA(一般提供)になりました。

この機能により、PSC エンドポイントが各スポークに伝播され、ハブを通じて異なる VPC の PSC エンドポイントへ到達可能となります。
これまで各 VPC ごとに作成していた PSC エンドポイントを集約できるというわけです。

ではこれを Cloud Build から利用しようじゃないか、というのが今回の検証です。

PSC エンドポイントの伝播の考慮事項
  • VPC スポークでのみ利用できます
  • ハイブリッド VPC スポークを通してオンプレミスネットワークから PSC エンドポイントにアクセスしたい場合、
    • ルーティング VPC ネットワーク(ハイブリッドスポークを含んだ VPC ネットワークのこと) 1 つにハイブリッドスポークの情報を集約しなければいけません
    • 当該のルーティング VPC ネットワークが VPC スポークとして NCC ハブに接続されなければなりません

準備

では、NCC を使って接続できるか確認してみましょう。

検証に際しては、公式ドキュメントの手順をなぞっていきます。
今回は gcloud コマンドを用いての検証になっていますが、Google Cloud の Web コンソールや API を通じた操作も可能です。

ハブを作る

Network Connectivity API を有効化した後、下記の gcloud コマンドを実行します。
${HUB_NAME} には、構築したい NCC ハブの名前を入れてください。また --export-psc フラグにより、PSC エンドポイントの伝搬を有効にします。${PROJECT_ID} には検証に使用する Google Cloud プロジェクトの名前を代入してください。

  gcloud network-connectivity hubs create hub ${HUB_NAME} \
      --project=${PROJECT_ID} \
      --preset-topology="MESH" \
      --export-psc

ハブの作成が完了すると、以下のように表示されます。これで NCC ハブができました。

ハブの作成完了

スポークを作る

今回用意するスポークは VPC スポークおよびプロデューサー VPC スポークです。

まず、VPC スポークを作成します。この VPC の中に PSC エンドポイントがあります。

下記の gcloud コマンドを実行します。
${HUB} には上記で作成した NCC ハブの名前を、${VPC_URI} は VPC スポークとリンクする VPC の URI を指定します[3]。

gcloud network-connectivity spokes linked-vpc-network create SPOKE_NAME \
    --project=${PROJECT_ID} \
    --hub=${HUB} \
    --vpc-network=${VPC_URI} \
    --include-export-ranges=ALL_PRIVATE_IPV4_RANGES \
    --global

次に下記のコマンドで Cloud Build プライベートプール用の、プロデューサー VPC スポークを作成します。
コンシューマー VPC スポークを選ぶ必要がある点、--peering が必要な点が違うポイントです。

gcloud network-connectivity spokes linked-producer-vpc-network create ${SPOKE_NAME} \
    --project=${PROJECT_ID} \
    --hub=${HUB} \
    --network=${CONSUMER_VPC_URI} \
    --peering=servicenetworking-googleapis-com \
    --global

これでスポーク 2 つが作成できました。

スポーク作成完了

結果

準備は整ったので、通信が疎通できるのかを見ていきます。

ビルドに実行するのは下記の YAML ファイルです。通信の宛先に、PSC エンドポイントの IP アドレスを指定しています。
これまでは推移的接続の制限により、通信がタイムアウトエラーを起こしていたものになります。

build.yaml
steps:
  - name: 'postgres:15'
    entrypoint: 'bash'
    args:
      - '-c'
      - |
        echo "Check connectivity to DB via PSC endpoint"
        # PostgreSQL 例： PSC で割り当てられた private IP へ接続 (5432)
         psql -h 10.20.0.10 -p 5432 -U postgres -d postgres -c "SELECT NOW();"
options:
  pool:
    name: 'projects/${PROJECT_ID}/locations/asia-northeast1/workerPools/test_private_pool'

ではビルドしてみましょう。

ビルド失敗

はい、通信に失敗しました。

なぜでしょうか。通信テストの公式ドキュメントや有識者に聞くなどした結果、2 ホップ制限によるものだとわかりました。

失敗の原因解説

ここで思い出す必要があるのは、プロデューサー VPC スポークは Google 管理のマネージド VPC そのものではなく、あくまでそれと PSA(VPC ピアリング)を通して接続された VPC だということです。
Cloud Build プライベートプールのワーカーが Google 管理の VPC 内から接続しようとする場合、VPC ピアリングによって 1 ホップ、PSC エンドポイントによってさらに 1 ホップとなります。

これにより推移的接続の制限に引っかかってしまい、通信が失敗してしまったということです。

てっきり以下のように接続ができるんだと思っていたので、2 ホップ制限に引っかかっているとわかったときは思わず天を仰ぎました。

こうだったらよかったのに

まとめ

残念ながら今回の検証では希望した通りの通信はできませんでしたが、本来 NCC とは便利なものです。

今回 NCC を使って構築したネットワークは、VPC 2 つを接続するだけのシンプルなものでした。
しかし NCC が効果をもっとも発揮するのは、さらに多くの VPC などを接続して構築する、複雑なネットワークにおいてこそです。

通常の VPC のみならず、プロデューサー VPC スポークを通した Google マネージドの VPC の接続も別のケースでは刺さりますし、さらにオンプレミス用アプライアンスなど様々なものを NCC ハブに接続することで、ネットワークの構築・管理がより容易になることが期待できます。
PSC エンドポイントの伝搬も、これまで VPC ピアリングをせっせと構築していたことからすると、大きな進歩だと思います。

今回は悲しい検証結果になってしまいましたが、次の記事では上記のような NCC が活きる場面をテーマにした記事が書けたらと思います。
その際はお読みいただけると幸いです。

お知らせ

Google Cloud 旗艦イベントである Google Cloud Next '25 がラスベガスで開催されます。

弊社 PTE のシャンクスとラリオスがラスベガスから日本の皆様へ超速報（ReCAP）を生配信でお届けいたします！
この機会にぜひご参加ください。

開催日：2025年4月11日(金) 11:00-12:00
会場： オンライン配信
定員：500 名
参加費：無料

脚注

  1. 正確には、Private Service Access を通して Google が管理している VPC と接続している VPC がスポークと紐づくリソースになります ↩︎

  2. https://cloud.google.com/network-connectivity/docs/network-connectivity-center/release-notes#February_26_2025 ↩︎

  3. 確認には gcloud compute networks describe ${VPC_NAME} コマンドの結果の中にある selfLink が使えます ↩︎

Discussion