コンテンツに移動
Google Cloud

Shared VPC : 複数プロジェクトにまたがる仮想ネットワークを一元管理

2017年6月28日
Google Cloud Japan Team

複数のクラウド プロジェクトを同時に進めている大規模組織は、物理リソースの共有機能を重視しつつ、グループや部署単位では論理的にリソースを分離したいと考えています。

そこで私たちは、Google Cloud Next '17 で Shared VPC(旧称 : Cross-Project Networking)を発表しました。これは、組織内で複数のプロジェクトにまたがる 1 つもしくは複数の仮想ネットワークの構成や一元管理を可能にするもので、Google Cloud Platform(GCP)のリソース階層におけるトップ レベルの Cloud Identity & Access Management(Cloud IAM)リソースです。

Shared VPC を利用すれば、組織全体に対するルートやファイアウォール、サブネット IP アドレス範囲、VPN 接続などの作成を一元管理できるほか、開発者が自ら請求、割当、IAM 権限を所有でき、自律的に開発プロジェクトを運用できます。

この投稿では、先ごろ正式公開(GA)となった Shared VPC の概要や推奨例を紹介します。

Shared VPC の仕組み

Shared VPC は、仮想ネットワークのデータ プレーンに対して透過的な管理制御プレーン内に完全に実装されています。管理制御プレーンでは、一元管理されたプロジェクトがホスト プロジェクトとして有効化されており、そこには 1 つまたは複数の共有仮想ネットワークが含まれます。

必要な Cloud IAM 権限を設定したら、1 つまたは複数のサービス プロジェクトとホスト プロジェクトをリンクすることで、共有仮想ネットワーク内に仮想マシン(VM)を作成できます。このように仮想ネットワークを共有することで、ファイアウォールなどの重要なネットワーク リソースへのアクセスを制御でき、小さい負荷で一元管理できるようになるのです。

さらに共有仮想ネットワークでは、VM は共有ネットワーク上に配置されていない場合と同様のネットワーク スループットの上限や VM 間レイテンシの恩恵を受けられます。これは、VM と VPN、さらにはロード バランサと VM の通信においても同様です。

例として、単一の外部向けウェブ アプリケーション サーバーを考えてみましょう。そのアプリケーション サーバーは、パーソナライゼーションやレコメンデーション、アナリティクスなどのサービスを使っており、すべては内部で利用可能になっているものの、異なる開発チームが構築したものとします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/ypM4Ke820iknCDrlu0Vb25Z95bvGlBiBqbRHeIWRk6Kf.max-700x700.PNG
Shared VPC 設定における接続形態の例

このような仮想ネットワークを自社で設計するときの推奨パターンを見ていきましょう。

Shared VPC 管理者の役割

共有ホスト プロジェクトのネットワーク管理者は、組織内で Shared VPC 管理者の役割も担う必要があります。そうすることで単一の中央グループが、Shared VPC のホスト プロジェクトにリンクされた新たなサービス プロジェクトを設定できるようになります。また同時に、個々のサブネットワークを共有ネットワーク内にセットアップし、特定のサービス プロジェクトの管理者が利用する IP 範囲を設定することもできます。通常、これらの管理者はサービス プロジェクトのインスタンス管理者という役割を有します。

サブネットワークの USE 権限

サービス プロジェクトを共有ネットワークに接続するときは、サービス プロジェクトの管理者に対して、リージョンごとに 1 つ(または複数)のサブネットワーク上における compute.subnetworks.use の権限を(ネットワーク ユーザーの役割を通じて)与えることをお勧めします。こうすることで、サブネットワークが単一のサービス プロジェクトで利用されることになります。

これにより、組織内の異なるチームがサブネットワークをきれいに分けて利用できるようになります。将来的には、どのサービス プロジェクトを利用しているかに応じて、各サブネットワークに特定のネットワーク ポリシーを関連づけることも可能でしょう。

サブネットワークの IP 範囲

同一もしくは異なるリージョンにおいてサブネットワークの IP アドレス範囲を設定するときは、今後の拡張に備えて、サブネットワーク間に十分な IP スペースを確保しておきましょう。GCP の場合、仮想ネットワーク内の既存 VM が所有する IP アドレスに影響を与えずに、またダウンタイムを発生させることもなく、既存のサブネットワークを拡張できます。

Shared VPC とフォルダ

組織内で作成したプロジェクトを管理するにあたってフォルダを利用する場合は、Shared VPC セットアップのホスト プロジェクトとサービス プロジェクトをすべて同一フォルダに配置してください。ホスト プロジェクトの親フォルダは、サービス プロジェクトの親の階層に配置しておく必要があります。

こうすることで、ホスト プロジェクトの親フォルダに Shared VPC セットアップ内のすべてのプロジェクトが含まれることになります。サービス プロジェクトとホスト プロジェクトを関連づける場合は、今後これらのプロジェクトが別フォルダに移動しないようにしつつ、ホスト プロジェクトとリンクした状態を保つようにしてください。

外部アクセスの制御

パブリック IP を保有するためインターネットにアクセスできる VM を制御し制限するには、VM の外部 IP アクセスを無効にする組織ポリシーの設定が効果的です。これは、パーソナライゼーションやレコメンデーション、アナリティクス サービスなど、上記で挙げた例のように内部アクセスだけで進めるプロジェクトに対してのみ適用しましょう。

以上のように、Shared VPC は組織にとって GCP をより柔軟に管理しやすくする強力なツールです。Shared VPC の詳細についてはこちらのドキュメントを参照してください。

* この投稿は米国時間 6 月 7 日、Staff Software Engineer である Neha Pattan によって投稿されたもの(投稿はこちら)の抄訳です。

- By Neha Pattan, Staff Software Engineer

投稿先