Zenn
🐙

Google Cloud NCC の落とし穴と実践的な使い方

に公開
network
Google Cloud
VPC
WAN
ncc
tech

TL;DR

  • 複雑なネットワーク接続をシンプルに : NCC は、多数の VPC やオンプレミス拠点を「ハブ＆スポーク」モデルで一元管理するサービスです。VPC ピアリングでは管理が煩雑になる大規模・多拠点接続の課題を解決します。

  • 進化し続ける接続ハブ : VPC 間のルート交換や PSC 連携などの新機能が正式リリースされ、ハイブリッドクラウド環境におけるネットワーク管理の中核として、さらに強力で柔軟なソリューションになりました。

  • 設計・運用の重要ポイント : 共有 VPC と組み合わせる際は「ハブはホストプロジェクトに設置」というルールが必須です。また、見落としがちな ADN 料金などのコストや技術的上限を事前に把握することが、安定した運用を実現する鍵となります。

はじめに

クラウドエースの亀梨とダッフィです。

企業のクラウド活用が進むにつれて、VPC ネットワークやオンプレミス環境、そして他のクラウド環境など、接続が必要なネットワークは複雑化の一途をたどっています。このような多拠点・マルチクラウド環境におけるネットワーク接続の一元管理と簡素化を支援するのが、Google Cloud の Network Connectivity Center （NCC） です。

NCC は、ハブ＆スポーク モデルに基づいたネットワーク接続管理のためのオーケストレーションフレームワークです。中心となるグローバルリソースである ハブ に対して、接続したい各ネットワークを スポーク としてアタッチすることで、スポーク間での通信を容易に実現します。

ハブ＆スポークモデル
ハブ＆スポークモデル

この記事では、NCC に関する注目すべき最新情報や、多くの企業で利用されている共有 VPC 環境で NCC を利用する際の重要な注意事項について解説します。
https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/overview?hl=ja

NCC の基本をおさらい

NCC のハブには、以下の種類のスポークを接続できます:

  • VPC スポーク: Google Cloud 上の VPC ネットワーク同士を接続するために使用します。異なるプロジェクトや異なる組織にある VPC ネットワークも接続可能です。
  • ハイブリッド スポーク: オンプレミスネットワークや他のクラウドプロバイダのネットワークなど、Google Cloud 外部のネットワークと接続するために使用します。HA VPN トンネル、Cloud Interconnect の VLAN アタッチメント、および Router Appliance VM がハイブリッド スポークとして利用できます。
  • プロデューサー VPC スポーク: Private Service Access を使って Google のマネージドサービス（例: Cloud SQL）に接続している VPC ネットワークを、スポークとしてハブにアタッチする機能です。これにより、その VPC を「代理」として、ハブに接続された他のネットワーク（ VPC やオンプレミス拠点）からマネージドサービスへの接続性を一元的に提供できます。

NCC を使うことで、これらのスポークとして接続されたネットワーク間でルートが自動的に交換されます。その結果、ハブ＆スポークという構成をベースに、スポーク同士が全て通信できる「フルメッシュ」型の接続性や、特定のスポークとのみ通信を許可する「スター」型の接続性をシンプルに実現できます。

https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/connectivity-topologies

なお、NCC はスポークの利用時間やネットワーク間のデータ転送量に応じた従量課金モデルです。これらのコストや制限に関する具体的な注意点は、後の「設計・運用時の「落とし穴」と対策」の章で詳しく解説します。

よく似た技術との比較

Google Cloud の VPC 接続には、NCC の他にもいくつかの方法があります。NCC の役割を明確にするため、他の接続方法との違いとそれぞれに適したユースケースを比較します。

基本的なコンセプト

  1. VPC ピアリング (VPC Peering):
    2 つの VPC を 1 対 1 で直接繋ぐ、最もシンプルな方法です。

  2. 共有 VPC (Shared VPC):
    「ホストプロジェクト」の VPC を、他の「サービスプロジェクト」が共有する仕組みです。ネットワーク管理の一元化を目的としています。

  3. NCC:
    「ハブ＆スポーク」モデルで、多数の VPC やオンプレミス拠点を大規模に接続するためのマネージドサービスです。

より詳細な比較は以下の表の通りです。各機能の詳細は公式ドキュメントもご参照ください。

比較項目 VPC Peering 共有 VPC (Shared VPC) NCC
トポロジー 1 対 1 (Point-to-Point) 1 対多 (Hub-Spoke に近い) 多対多 (Hub-Spoke)
主な目的 2 つの VPC の直接接続 組織内でのネットワーク集約・管理 大規模な VPC ・オンプレミスの集約
推移的ルーティング ❌ 不可 ⚠️ ホスト VPC 内でのみ可 ⚠️ VPC ピアリング越えは不可
接続対象 VPC 間のみ ホスト VPC に接続された、サービスプロジェクト内のリソース VPC, VPN, Interconnect, ルーターアプライアンス
オンプレミス接続 各 VPC で個別設定が必要 ホスト VPC で一元化 ハブで一元化
管理の複雑さ 低 中 (IAM 管理が重要) 高 (ネットワーク全体の知識が必要)
スケーラビリティ 低 (接続数が増えると網の目に) 中 (組織内に閉じる) 高 (グローバルに拡張可能)
IP アドレス重複 ❌ 不可 ❌ 不可 ⚠️ 条件付きで可 (NAT が必要)

どの技術を選択すべきか？

VPC ピアリング、共有 VPC、NCC はどう使い分ければいいのでしょうか？それぞれに適したユースケースをご紹介します。

  • VPC ピアリングが適切なケース

    • シナリオ: 3~4 個程度の少数の VPC をシンプルに繋ぎたい。

    • 理由: VPC ピアリングには、設定が簡単でデータ処理コストもかからないという利点があるため、シンプルな接続に最適です。しかし、下図で示した 2 つの重要な制限から、将来 VPC が大幅に増える予定がある場合は、管理が煩雑になる可能性があります。

      1. 接続数の問題: 接続する VPC が増えるほど、必要なピアリング設定の数は指数関数的に増加します（例：10 個の VPC で 45 個の接続）。
      2. 推移的ルーティングが不可: VPC-A が VPC-B と、VPC-B が VPC-C と接続していても、VPC-A は VPC-B を経由して VPC-C と通信することはできません。
        これらの理由から、将来的に VPC が大幅に増える予定がない、シンプルな構成に最適な方法です。

VPC ピアリングの図
VPC ピアリングの図

  • 共有 VPC が最適なケース

    • シナリオ: 組織内で多数のプロジェクトがあり、ネットワーク設定（サブネット、ファイアウォール等）を情報システム部門で一元管理したい。

    • 理由: 共有 VPC には組織内ネットワークの一元管理機能があり、ガバナンスとセキュリティポリシーの統一に優れているため本シナリオに最適です。各開発チームはネットワークインフラを余り意識することなく、リソース作成に集中できます。共有 VPC は「異なる環境の接続」よりも「組織管理」に主眼を置いた技術です。

VPC 共有の図
VPC 共有の図(出典: Shared VPC overview | Google Cloud)

  • NCC が最適なケース

    • シナリオ:

      • 多数の VPC を相互に、あるいはオンプレミス拠点と接続する必要がある。

      • 複数のオンプレミス拠点（例：東京本社と大阪支社）同士を、Google のグローバルネットワークを介して通信させたい。

      • VPC ピアリングの「N 対 N」の複雑な接続（メッシュ化）を、シンプルなハブ＆スポークに集約したい。

    • 理由: NCC には多数のネットワークをスケーラブルに管理できる機能があり、グローバルなハイブリッドクラウド環境のネットワークハブとして機能するため本シナリオに最適です。VPC ピアリングや共有 VPC では解決が難しい、より大規模で複雑な要件に応えることができます。

NCC ハブ＆スポークの図
NCC ハブ＆スポークの図

機能比較：共有 VPC でできて、NCC でできないこと

NCC と共有 VPC は、どちらも複数のプロジェクトが関わるネットワークを扱いますが、その目的は根本的に異なります。NCC がネットワーク同士を 「接続」 するためのサービスであるのに対し、共有 VPC は組織の 「ガバナンスと管理」 に主眼を置いています。

この目的の違いから、共有 VPC にしかできないことがいくつか存在します。

  1. ファイアウォールポリシーの一元的な強制適用
    共有 VPC の最も強力な機能は、ファイアウォールルールの一元管理です。

    • 共有 VPC : ネットワークの所有者であるホストプロジェクトでファイアウォールルールを一度定義すれば、その VPC を利用する全てのサービスプロジェクト（例: 各事業部のプロジェクト）にそのルールが自動的かつ強制的に適用されます。これにより、組織全体のセキュリティポリシーを統一し、ガバナンスを効かせることが可能です。

    • NCC : NCC 自体にはファイアウォール機能はありません。 NCC はあくまでハブとして VPC 間を接続するだけであり、各 VPC スポークのファイアウォールは、それぞれのプロジェクトで個別に管理する必要があります。

  2. IP アドレス空間（サブネット）の一元管理
    組織内で使用する IP アドレスの管理も、共有 VPC が得意とする領域です。

    • 共有 VPC : サブネットの作成や IP アドレス範囲の割り当ては、全てホストプロジェクトの管理者が行います。サービスプロジェクトの利用者は、割り当てられたサブネット内にリソースを作成する権限しか持てないため、勝手に IP 範囲を消費したり、他のプロジェクトと IP が重複したりするのを防げます。

    • NCC : NCC は既存の VPC を接続するため、 IP アドレスの管理は行いません。むしろ、 IP アドレスが重複した VPC を接続できる（ただし NAT が必要）点が特徴であり、目的が異なります。

注目すべき最新情報！NCC の機能強化

NCC は継続的に機能強化されており、より多様な要件に対応できるようになっています。ここでは、最近発表された注目すべきアップデートをいくつかご紹介します。

静的ルートのサポート（プレビュー）

詳細
  • BGP を使わずに、特定の宛先へのネクストホップを手動で定義できる「静的ルート」機能がプレビューとして利用可能になりました。
  • この機能は 2025 年 6 月 26 日に公開されました。

IPv6 サブネット交換のサポート（GA）

詳細
  • VPC スポーク間で、IPv6 サブネットのルート交換が正式にサポートされました。
  • これにより VPC 間の IPv6 通信を NCC で一元管理できるようになりましたが、ハイブリッドスポークは現在も IPv4 のみのサポートである点に注意が必要です。
  • この機能は 2025 年 4 月 7 日に一般提供が開始されました。

プロデューサー VPC スポークの正式リリース (GA)

詳細
  • Private Service Access を使用する Google マネージドサービスへの接続を、NCC ハブ経由で実現するためのプロデューサー VPC スポークが正式に利用可能になりました。
  • これにより、Cloud Build プライベートプールから Cloud SQL などのサービスへのアクセスといったユースケースで、ハブ経由の接続性を活用できます。
  • この機能は 2025 年 2 月 27 日に一般提供 (GA) が開始されました。
  • なお、VPC ピアリングによる推移的接続の制限との関連で、特定の構成においては期待通りの通信が実現できないケースも報告されています。

Private Service Connect (PSC) 接続伝播の正式リリース (GA)

詳細
  • ある VPC スポークで作成した PSC エンドポイントへの接続情報を、ハブを介して他の VPC スポークへ自動的に共有できるようになりました。
  • これにより、VPC ごとに PSC エンドポイントへの接続設定をすることなく、一元的なサービス利用が可能になります。ただし、スポークの作成や削除後、PSC 接続の伝播が非同期に行われる場合がある点には注意が必要です。
  • この機能は 2025 年 2 月 26 日に一般提供が開始されました。

VPC スポークによるルート交換機能の正式リリース (GA)

詳細
  • これまで主にサイト間接続に利用されてきた NCC ですが、VPC スポークとハイブリッド スポーク間のルート交換機能が正式に利用可能になりました。
  • これにより、複数の VPC ネットワークと複数のオンプレミスサイト間での相互通信を、ハブを通じて一元的に管理することが可能になり、VPC ネットワークとオンプレミス間の接続管理が大幅に簡素化されます。
  • この機能は 2025 年 1 月 30 日に一般提供が開始されましたが、ルートフィルタ変更時に古いルートの削除が最大 30 分遅延する既知の問題が報告されています。

これらのアップデートにより、NCC は様々なネットワーク接続シナリオにおいて、より強力で柔軟なソリューションとして活用できるようになっています。
https://cloud.google.com/network-connectivity/docs/network-connectivity-center/release-notes

ケーススタディ：共有 VPC と NCC を共存させる際の注意事項

共有 VPC と NCC の組み合わせ図
共有 VPC と NCC の組み合わせ図
多くの企業で Google Cloud 環境を効率的かつセキュアに管理するために採用されている 共有 VPC は、組織内の複数のプロジェクト (サービスプロジェクト) が、1 つのホストプロジェクトで管理される VPC ネットワークを共有できる機能です。この共有 VPC 環境で NCC を利用する際には、いくつかの重要な注意事項があります。

最も重要な注意点は、ハブは必ずホストプロジェクトに作成する必要がある という点です。

https://cloud.google.com/network-connectivity/docs/network-connectivity-center/concepts/overview?hl=ja#shared-vpc-support

この制限は、NCC で ハイブリッド スポーク (HA VPN、Cloud Interconnect VLAN アタッチメント、Router Appliance VM) を使用する場合に適用されます。VPC スポークのみを利用する場合であれば、この制限は緩和される可能性がありますが、ハイブリッド スポークを組み合わせて使用する場合は、ハブをホストプロジェクトに配置することが必須となります。

これは、ハイブリッド スポークが参照する基盤となるネットワークリソース (Cloud VPN トンネルや Cloud Interconnect VLAN アタッチメントなど) や Router Appliance VM が、通常、接続の終端としてルーティング VPC ネットワーク (多くの場合、ホストプロジェクト内の VPC) に配置されることに起因する管理上の制約と考えられます。

共有 VPC 環境で NCC を利用し、特にサービスプロジェクトからハイブリッドスポークを介して通信を行う場合は、以下の点を考慮してください。

  • ハブの作成場所: ホストプロジェクトに作成する。
  • スポークの作成場所: サービスプロジェクトにある VPC ネットワークを NCC ハブに接続する場合、その VPC はサービスプロジェクト内で VPC スポークとして作成し、ハブへのアタッチを提案します。ハブ側 (ホストプロジェクト) の管理者がこの提案を承認することで、スポークが有効化されます。
  • ハイブリッド スポークの場所: オンプレミス接続などに使用するハイブリッド スポークの基盤リソース (Cloud VPN や Cloud Interconnect VLAN アタッチメントなど) は、通常、ホストプロジェクト内のルーティング VPC ネットワークに配置されることになります。ハイブリッド スポーク自体もハブと同じホストプロジェクトに作成されます。
  • 必要な IAM ロール: サービスプロジェクトの管理者が自分のプロジェクト内の VPC をハブにスポークとしてアタッチできるよう、ホストプロジェクトのハブ管理者によって適切な権限 (例えば networkconnectivity.groups.use 権限 や networkconnectivity.googleapis.com/spokeAdmin ロール) が付与されていることを確認してください。

共有 VPC と NCC を適切に組み合わせることで、複数のサービスプロジェクトから一元管理されたハイブリッド接続を利用したり、サービスプロジェクト間のネットワーク接続を簡素化したりすることが可能になります。上記の注意事項を理解し、適切なプロジェクトに適切なリソースを配置することが重要です。

ケーススタディ：スタートポロジと PSC の組み合わせによるセキュアなサービス公開

NCC と PSC の組み合わせ図
NCC と PSC の組み合わせ図

NCC のスタートポロジと Private Service Connect (PSC)を組み合わせることで、柔軟かつセキュアなサービス公開アーキテクチャを構築できます。これは、特定のサービスを、特定の利用者（VPC やオンプレミス拠点）にだけ限定的に公開したい場合に有効です。

考えられる利用シナリオは以下です：

  • 共通基盤チームが管理する VPC（センタースポーク）で、組織内向けの API やデータ分析基盤などの共通サービスを稼働させている。
  • 各事業部の VPC（エッジスポーク）や、特定のオンプレミス拠点（ハイブリッドスポーク）からは、この共通サービスを利用させたい。
  • ただし、事業部間の直接通信や、事業部から他の不要なオンプレミス拠点への通信はセキュリティ上禁止したい。

アーキテクチャのポイント

この構成は、NCC スタートポロジによる「経路制御」と、PSC による「サービスエンドポイントの公開」という 2 つの機能を組み合わせることで実現します。

  1. サービスの公開 (PSC)
    まず、共通サービスが稼働している VPC（プロバイダー VPC）内で、公開したいサービス（通常は内部ロードバランサー）をターゲットとする PSC サービスアタッチメントを作成します。これにより、サービスをプライベートに公開する準備ができます。

  2. 経路の制御 (NCC スタートポロジ)
    次に、NCC ハブでスタートポロジを構成します。

    • センタースポーク: サービスを公開しているプロバイダー VPC を「センター」として設定します。

    • エッジスポーク: サービスを利用させたい各事業部の VPC やオンプレミス拠点を「エッジ」として設定します。

この構成で何が起きるか

スタートポロジのルールにより、エッジスポークはセンタースポークとしか通信できません。エッジスポーク同士（例：事業部 A の VPC と事業部 B の VPC）のルートは交換されないため、ネットワークレベルで完全に分離されます。

サービスを利用したい事業部は、自分の VPC（エッジスポーク）内に PSC のエンドポイントを作成し、センタースポークで公開されているサービスに接続します。トラフィックは [エッジスポーク] → [NCC ハブ] → [センタースポーク] という経路を通り、安全にサービスに到達します。

この構成のメリット

  • 最小権限の実現
    利用者は許可された共通サービスにしかアクセスできず、他の事業部のネットワークや不要なオンプレミス拠点へは到達できません。これにより、ゼロトラストの原則に基づいたセキュアな環境を構築できます。

  • 管理の簡素化
    複雑な VPC ピアリングやファイアウォールルールを多数設定・管理する必要がありません。新しい事業部を追加する場合も、エッジスポークとして追加するだけで済みます。

  • IP アドレスの独立性
    PSC を利用するため、プロバイダー VPC とコンシューマー VPC の IP アドレス範囲が重複していても問題ありません。

設計・運用時の「落とし穴」と対策

NCC は非常に強力でスケーラブルなネットワークハブサービスですが、設計や運用時に注意すべき「落とし穴」がいくつか存在します。

  1. 想定外のコストに繋がりうる料金体系

    • 課題
      NCC の料金は主に「スポーク時間」「データ転送」「Advanced Data Networking (ADN)」の 3 要素で決まります。特に注意が必要なのは、ハブを通過するトラフィック量に応じて課金される「データ転送」と、 VPC スポーク間の通信で発生する見落としやすい「ADN」です。大容量のデータバックアップなどを定常的に行うと、これらのデータ関連料金が想定以上に高額になる可能性があります。

    • 対策
      通信要件を精査し、 NCC を経由させる通信かどうかを明確にしましょう。より積極的にコストを管理するには、各スポークに詳細な課金ラベルを設定します。そして課金データを BigQuery にエクスポートし、特定のスポーク間のトラフィックを可視化するダッシュボードを作成しましょう。これにより、請求書が届く前にどの接続がコストを押し上げているかを特定できます。最新の料金体系は必ず公式の料金ドキュメントで確認してください。

  2. 技術的な制約と仕様の理解不足
    NCC は万能ではありません。以下のような技術的な制約を理解しておくことが重要です。

    • リソース数の「割り当て」と「上限」
      NCC には、作成できるリソースの数に明確な制限があります。これらは変更可能な「割り当て」と、変更不可能な「上限」に分かれます。設計時に特に注意すべき点です。

      設計時に特に注意すべき点
      • 割り当て
        • ハブの数 : 1 プロジェクトにつきグローバルで 1 つまで。
      • 上限:
        • ハブあたりの VPC スポーク数 : アクティブなスポークは 250 まで。
        • ハイブリッドスポークあたりのリソース数:
          • VPN トンネル : 8
          • VLAN アタッチメント : 6
          • ルーター アプライアンス インスタンス : 8

      より詳細な上限と割り当ては公式サイトで確認できます。

    • レイテンシ
      ハブを経由するトポロジのため、最短経路で接続される VPC ピアリングと比べて経路長が伸びる可能性があります。ただし実際の遅延は、地域/ゾーンの配置、経路選択、混雑状況などの要因に依存するため、NCC が常に VPC ピアリングより高遅延と断定することはできません。重要な経路については要件に合わせて実測で確認することを推奨します。

      レイテンシに関する補足

      参考として、VPC ネットワーク ピアリングについては Google Cloud 公式ドキュメントに「ピアリングトラフィックのレイテンシは、同じ VPC ネットワーク内のトラフィックと同じです」と記載があります。これはピアリング経路が短いことを示すものであり、NCC の遅延の大小を直接示すものではありません。NCC はハブ&スポーク設計上、ハブ分のホップが追加されうるため、要件によっては遅延影響が顕在化する可能性があります。

    • 推移的ルーティングの限界
      NCC は、VPC ピアリングの「先」にあるネットワークまでは見通せません。複雑な構成ではこの制約が問題になることがあります。

  3. 運用の複雑さ
    NCC はネットワークの中心になるため、設定ミスやトラブルの影響範囲が広くなりがちです。

    • 問題の切り分け
      通信障害が起きた際、原因がオンプレミス側なのか、VPN/Interconnect なのか、 NCC ハブなのか、 VPC のファイアウォールなのか、といった切り分けが複雑になることがあります。トラブルシューティングでは、Network Intelligence Center の『接続テスト』を最大限に活用しましょう。 NCC の問題を疑う前に、必ず一方のスポーク内の送信元 VM からもう一方のスポークの宛先への接続テストを実行してください。多くの場合、問題のあるファイアウォールルール、ルーティングの問題、あるいは設定ミスを正確に特定でき、平均解決時間
      （MTTR）を劇的に短縮できます。
    • IP アドレスの重複
      重複 IP を持つスポークを接続する場合、ルーターアプライアンス等で慎重な NAT 設定が必要となり、構成とトラブルシューティングが非常に複雑になります。可能な限り、初期の IP アドレス設計で重複を避けることが極めて重要です。

https://cloud.google.com/network-intelligence-center/docs/connectivity-tests/concepts/test-through-ncc-hub?hl=ja

まとめ

NCC は、増加するネットワーク接続の複雑性に対処するための強力なソリューションです。ハブ＆スポークモデルにより、VPC 間、VPC とオンプレミス間、そしてサイト間の接続を一元的に管理し、構築と運用を大幅に簡素化します。

VPC スポークとハイブリッド スポーク間のルート交換の GA、PSC 接続伝播の GA、プロデューサー VPC スポークの GA といった最近の機能強化により、NCC はさらに多くのネットワークシナリオに対応できるようになっています。

ただし、共有 VPC 環境でのハブの配置に関する制約や、共有 VPC とは異なる思想のガバナンスモデルなど、いくつかの重要な考慮事項も存在します。これらの注意事項を理解し、スタートポロジや PSC と組み合わせて柔軟なサービス公開を実現するなど、自社のアーキテクチャ要件に合わせて適切に設計することで、NCC のメリットを最大限に引き出すことができるでしょう。

Google Cloud のネットワーキング機能は日々進化しており、NCC も例外ではありません。今後も新しい機能が追加され、さらに使いやすく強力なサービスになっていくことが期待されます。複雑なネットワーク管理にお悩みの方は、ぜひ NCC の活用を検討してみてはいかがでしょうか。

Discussion