Network Connectivity Center を使用してスケーラブルで復元力のあるエンタープライズ ネットワークを構築する
Srikant Sharma
Software Engineer, Google Cloud
Gopinath Balakrishnan
Customer Engineer, Google Cloud
※この投稿は米国時間 2025 年 9 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。
クラウド プラットフォームを導入する大企業にとって、VPC、オンプレミス データセンター、その他のクラウドにわたるネットワーク接続を管理することは非常に重要です。しかし、従来型のモデルはスケーラビリティに欠けることが多く、管理上のオーバーヘッドが増大します。そこで魅力的な代替手段となるのが、Google Cloud の Network Connectivity Center です。
ネットワーク リソースの接続と管理を行う一元化されたハブアンドスポーク型サービスである Network Connectivity Center は、スケーラブルで復元力のあるネットワーク基盤を提供します。この記事では、Network Connectivity Center のアーキテクチャ、可用性モデル、設計原則について説明し、レジリエンスを最大化して問題の「影響範囲」を最小限に抑えるための価値と設計上の考慮事項について詳しくお伝えします。この情報があれば、Network Connectivity Center が組織にどのように適合するかをより適切に評価し、使用を開始できます。
大規模な企業ネットワークの課題
大規模な VPC ネットワークは、スケーラビリティ、複雑さ、一元管理の必要性という 3 つの主要な課題に常に直面しています。Network Connectivity Center は、以下の機能により、これらの課題に正面から対処できるように設計されています。
-
大規模にスケーラブルな接続: 従来の制限や VPC ピアリングの割り当てをはるかに超える規模へスケーリングできます。Network Connectivity Center は、ハブごとに最大 250 の VPC スポークと数百万の VM をサポートします。また、ファイアウォール挿入などのクロスクラウド接続の強化機能が今後リリースされる予定で、ネットワークが将来の需要に備えられます。
-
ワークロードのモビリティとサービス ネットワーキングの円滑化: VPC 間でワークロードを簡単に移行できます。Network Connectivity Center は、プライベート サービス アクセス(PSA)をサポートするプロデューサー VPC スポーク統合 や Private Service Connect(PSC)の伝播などの機能を通じて、推移性の課題をネイティブに解決し、組織全体でのサービス共有を合理化します。
-
運用上のオーバーヘッドの軽減: Network Connectivity Center は、VPC とオンプレミス接続の単一の制御ポイントを提供し、スポーク間のフルメッシュ接続を自動化して、運用上の負担を大幅に軽減します。
仕組み: 復元力を高める設計
Network Connectivity Center がどのようにして復元力を維持しているのかに焦点を当ててみましょう。その重要な部分がアーキテクチャです。アーキテクチャは、独立した 3 つの異なるプレーン上に構築されています。


Network Connectivity Center と Google Cloud ネットワーキング スタックの非常に簡略化されたビュー
-
管理プレーン: これは、ネットワークを構成するために使用する API、gcloud コマンド、Google Cloud コンソール アクションなどのインタラクション レイヤで、ハブの作成、スポークの接続、設定の管理を行います。
-
コントロール プレーン: これはオペレーションの頭脳です。管理プレーンから構成を取得し、基盤となるネットワークをプログラムします。すべてを機能させるソフトウェア定義ネットワーキング(SDN)を担当する、分散型シャーディング システムです。
-
データプレーン: 実際のトラフィックが流れる場所です。コントロール プレーンによってプログラムされた指示に基づいてパケットを移動する、ネットワーク ハードウェアと個々のホストの集合です。
Network Connectivity Center がこのアーキテクチャ全体で使用する基本原則は、fail-static 動作です。つまり、上位のプレーン(管理プレーンやコントロール プレーンなど)で問題が発生した場合、その下のプレーンは最後に確認された正常な構成に基づいて動作を継続し、既存のトラフィック フローは維持されます。これにより、たとえばコントロール プレーンの問題でネットワーク全体がダウンするといったことがなくなります。
Network Connectivity Center で障害を処理する方法
ネットワークの強度は、負荷がかかったときの動作によって明らかになります。Network Connectivity Center の設計は、潜在的な問題を封じ込め、その影響を最小限に抑えるために、基本的に安定性を重視しています。Network Connectivity Center の設計に関する次の点を考慮してください。
-
インフラストラクチャの影響は限定的: リージョン停止などの基盤となるインフラストラクチャの問題は、その特定のスコープ内のリソースにのみ影響します。Network Connectivity Center ハブはグローバル リソースであるため、1 つのリージョンで障害が発生しても、ネットワーク ハブ全体がダウンすることはありません。影響を受けなかった他のすべてのスポーク間の接続はそのまま維持されます。
-
構成障害の分離: 障害を慎重に分離することで、構成エラーの影響範囲を意図的に制限します。1 つのスポークまたはハブで発生したミスは隔離され、ネットワークの他の部分に波及して障害を引き起こすことはありません。この障害分離は、単一のルーティング構成ミスが広範囲に影響する可能性がある複雑な VPC ピアリング トポロジと比較して、重要な利点です。
-
中断のないデータフロー: フェイルスタティックの原則により、既存のデータフローは管理プレーンやコントロール プレーンの中断から高度に分離されます。障害が発生した場合、ネットワークは最後に正常にプログラムされた状態に基づいてトラフィックの転送を継続し、アプリケーションの安定性と継続性を維持します。
構成変更の影響範囲の管理
インフラストラクチャの停止がスコープ内のリソースに影響する場合でも、他のゾーンやリージョンにおける Network Connectivity Center の接続は機能し続けます。重要な点として、Network Connectivity Center の構成エラーは、変更されている特定のハブまたはスポークに限定され、ネットワークの無関係な部分にカスケードされません。これは、複雑な VPC ピアリング アプローチに対する重要な利点です。
安定性と運用効率をさらに高めるため、Network Connectivity Center の構成管理の合理化も行いました。更新は基盤となる SDN によって動的に処理されるため、構成変更のための従来のメンテナンス ウィンドウは不要です。変更は API レベルで透過的に適用され、下位互換性を持つように設計されているため、ネットワークをスムーズかつ中断なく進化させることができます。
複数のリージョン ハブの接続
Network Connectivity Center ハブはグローバル リソースです。マルチリージョンの復元力のある設計では、リージョンごとに専用のハブを使用したリージョン デプロイが必要になる場合があります。これには、複数のハブにわたる接続が必要です。Network Connectivity Center はハブ間のネイティブな接続を提供していませんが、代替方法を使用すると、Network Connectivity Center ハブ間で通信でき、特定の制御されたアクセスニーズを満たすことができます。
-
Cloud VPN または Cloud Interconnect: 専用の HA VPN トンネルまたは VLAN アタッチメントを使用して、Network Connectivity Center ハブを接続します。
-
Private Service Connect(PSC): PSC のプロデューサー/コンシューマー モデルを活用して、Network Connectivity Center ハブ全体で制御されたサービス固有のアクセスを提供します。
-
マルチ NIC VM: 異なるハブのスポークにネットワーク インターフェースを持つ VM を使用して、Network Connectivity Center ハブ間のトラフィックをルーティングします。
-
フルメッシュ VPC ピアリング: データベースの同期などの特定のユースケースでは、異なる Network Connectivity Center ハブのスポーク間にピアリングを確立します。
よくある質問
Network Connectivity Center コントロール プレーンが失敗した場合、トラフィックはどうなりますか?fail-static 設計により、既存のデータフローは、最後に成功した既知の構成に基づいて機能し続けます。動的ルーティングの更新は停止しますが、既存のルートはアクティブに保たれます。
新しい VPC スポークを追加すると、既存の接続に影響はありますか?いいえ。新しいスポークを追加するプロセスは動的であり、既存のデータフローが中断されることはありません。
Network Connectivity Center を介して VPC 間を通過するトラフィックにパフォーマンスのペナルティはありますか?いいえ。Network Connectivity Center で接続された VPC 間のトラフィックは、VPC ピアリングの場合と同じパフォーマンスになります。
復元力に関するベスト プラクティス
Network Connectivity Center は強力で復元力のあるプラットフォームですが、可用性を最大限に高めるネットワークを設計するには、お客様による慎重な計画が必要です。次のおすすめの方法を考慮してください。
-
冗長性の活用: データプレーンの可用性はローカル化されています。インフラストラクチャの局所的な障害を回避するには、重要なアプリケーションを複数のゾーンとリージョンにデプロイするようにしてください。
-
トポロジを慎重に計画する: ハブトポロジの選択は、設計上の重要な決定です。単一のグローバル ハブは運用がシンプルで、ほとんどのユースケースで推奨されるアプローチです。複数のリージョン ハブを検討するのは、厳格なリージョン分離またはコントロール プレーンの影響範囲の最小化が主な要件である場合に限ります。また、複雑さが増すことにも注意してください。最後に、Network Connectivity Center ハブはリージョン リソースですが、それでも「グローバル リソース」です。つまり、グローバルな障害が発生した場合、管理プレーンのオペレーションはリージョンの可用性とは関係なく影響を受ける可能性があります。
-
転送接続には Network Connectivity Center を選択する: 共有サービスに転送接続が必要な大規模ネットワークの場合、従来の VPC ピアリングよりも Network Connectivity Center を選択することで、運用を簡素化し、PSC/PSA 伝播などの機能を活用できます。
-
Infrastructure as Code を採用する: Terraform などのツールを使用して Network Connectivity Center の構成を管理します。これにより、手動エラーのリスクが軽減され、ネットワークのデプロイを繰り返し可能で信頼性の高いものにできます。
-
ネットワークの健全性をモニタリングする: Google Cloud の Service Health ダッシュボードとPersonalized Service Health ダッシュボードを定期的に使用して、Network Connectivity Center やその他のサービスのステータスを把握します。
-
スケーリングの計画: Network Connectivity Center のスケーリングの上限は高く設定されていますが、無限ではありません(例: ハブごとに 250 個の VPC スポーク)を考慮して、ネットワークの成長を計画してください。
スケーラブルで復元力のあるネットワーキングを実現するシンプルなアプローチ
Network Connectivity Center は、企業ネットワーキングの複雑さを大幅に軽減し、組織にシンプルでスケーラブルかつ復元力のある基盤を提供します。レイヤード アーキテクチャ、フェイルスタティック動作、設計原則を理解することで、現在のニーズを満たすだけでなく、将来の課題にも対応できるネットワークを構築できます。
使用を開始するには、設計上の考慮事項と Network Connectivity Center の公式ドキュメントを確認するか、Google Cloud チームに連絡して、複雑なマルチハブ ネットワーク設計に関するガイダンスを入手してください。
ー Google Cloud、ソフトウェア エンジニア Srikant Sharma
ー Google Cloud、カスタマー エンジニア、Gopinath Balakrishnan