【入門編】 GCP共有VPC（Shared VPC）のホストプロジェクトとサービスプロジェクトのアーキテクチャ – クラウドインフラと仮想化ネットワーク実践ガイド

皆さん、こんにちは！最前線のSRE兼クラウドアーキテクトとして、日々クラウドの最深部を探求している私が、今回はGoogle Cloud (GCP) の超強力なネットワーク機能の一つ、「Shared VPC（共有VPC）」について、皆さんと一緒にじっくり紐解いていきたいと思います。

「VPC？」「ネットワーク？」「プロジェクト？」…なんだか難しそうな言葉が並んで、もう頭が痛くなってきた、という方もいらっしゃるかもしれませんね。でも大丈夫！私たちが普段使っている「郵便配達」や「家」の仕組みに例えながら、パケットがどんな風にネットワークを駆け巡るのか、そのリアルな挙動を想像しながら、一歩ずつ理解を深めていきましょう。

この記事を読み終える頃には、Shared VPCがなぜ強力なのか、組織のネットワーク管理にどんなメリットをもたらすのか、きっとその魅力に気づいているはずですよ！

—

Shared VPCって、そもそも何がすごいの？

皆さんの会社で、たくさんのチームがそれぞれGCPプロジェクトを使って、Webサービスやアプリケーションを開発している光景を想像してみてください。チームごとに「このプロジェクトはWebサービス用」「このプロジェクトはデータベース用」といった感じで、役割分担していること、よくありますよね。

でも、それぞれが勝手にネットワークを作ってしまうと、どうなるでしょう？
Aチームが作ったネットワークと、Bチームが作ったネットワークが、互いに通信しようとすると、設定が大変だったり、IPアドレスがぶつかっちゃったり、セキュリティの抜け穴ができちゃったり…と、色々な問題が起こりがちなんです。

Shared VPCは、そんな「カオス」になりがちなネットワークを、組織全体で統一されたルールと一元的な管理のもとで、安全に共有するための仕組みなんです。まるで、たくさんの家族が住む大きなマンションで、水道や電気といった共通インフラを管理会社が一括で見てくれるようなイメージですね。

この記事でわかること

GCPのVPCネットワークの基本的な考え方（軽くおさらい）
Shared VPCの「ホストプロジェクト」と「サービスプロジェクト」の関係性
Shared VPCを使うと、どんな良いことがあるのか（メリット）
誰が何をできるのか？ IAM権限の考え方
実際に設定するためのCLIコマンドのイメージ

さあ、ネットワークの世界へ、一緒に旅立ちましょう！

—

VPCネットワークって、そもそも何だっけ？（軽くおさらい）

Shared VPCの話に入る前に、まずはGCPの「VPCネットワーク」って何だったか、簡単に思い出してみましょう。

VPCは「Virtual Private Cloud」の略で、直訳すると「仮想のプライベートなクラウド」です。簡単に言うと、GCPの中に皆さんの会社専用の「仮想的なデータセンター」を作るようなもの、と考えると分かりやすいかもしれません。

郵便配達で例えてみよう

私たちの家をイメージしてみてください。

1. 家（Compute Engineなどのリソース）: 皆さんがGCP上に立てる仮想マシン（Compute Engine）や、コンテナ（GKE）、データベース（Cloud SQL）などがこれにあたります。
2. 住所（IPアドレス）: それぞれの家には、郵便物が届くための住所がありますよね。GCPのリソースにも、互いに通信したり、インターネットと通信したりするための「IPアドレス」という住所が割り当てられます。
3. 郵便局の集配エリア（サブネット）: 郵便局は、効率的に郵便物を配るために、担当するエリア（町内や区画）を定めていますよね。VPCネットワークの中にも、「サブネット」という概念があります。これは、IPアドレスを効率的に管理し、リソースをグループ化するための範囲のこと。「この町内の家は、この郵便局が担当ね！」といった具合です。
4. 道路網（VPCネットワーク）: そして、これらの家と郵便局をつなぐのが、広大な道路網です。GCPでは、この道路網全体を「VPCネットワーク」と呼びます。この道路網があるからこそ、異なる住所の家同士でも、郵便物をやり取りしたり、遠くのインターネットにアクセスしたりできるわけです。
5. 検問所・警備員（ファイアウォールルール）: 郵便局や町内には、怪しい荷物が入ってこないように、あるいは重要な郵便物が漏洩しないように、検問所や警備員がいますよね。GCPのVPCには、「ファイアウォールルール」という仕組みがあり、どのIPアドレスから、どのポート番号へ、通信を許可するか/拒否するか、細かく制御できます。これによって、セキュリティが守られます。

VPCネットワークは、これらすべてをGCP上に「仮想的に」構築し、皆さんのアプリケーションが安全に、そして効率的に稼働するための土台を提供してくれる、とっても大切な基盤なんです。

—

Shared VPCって、どんな仕組み？ホストとサービスの関係

さあ、VPCネットワークの基本が分かったところで、いよいよShared VPCの核心に迫りましょう！

Shared VPCは、文字通り「VPCネットワークを共有する」仕組みです。でも、ただ共有するだけではありません。ここには、「ホストプロジェクト」と「サービスプロジェクト」という、二つの特別な役割を持ったプロジェクトが登場します。

親と子、あるいは本局と支局の例え

もう一度、郵便配達の例えを使ってみましょう。

1. ホストプロジェクト（郵便本局・親プロジェクト）:

Shared VPCでは、まず「ホストプロジェクト」と呼ばれる特別なプロジェクトを一つ用意します。
このホストプロジェクトが、VPCネットワークのすべての基盤（道路網、郵便局の集配エリア＝サブネット、検問所のルール＝ファイアウォール）を所有し、管理します。
まるで、組織全体の郵便システムを統括する「郵便本局」のような存在です。本局が、どこのエリアに新しい道路を作るか、どこに新しい郵便局の集配所を置くか、どんな郵便物をチェックするか、といった大元のルールを決め、インフラを整備するイメージです。

2. サービスプロジェクト（郵便支局・子プロジェクト）:

一方、「サービスプロジェクト」は、ホストプロジェクトが持つネットワークを利用して、アプリケーションなどのリソースをデプロイするプロジェクトです。
それぞれの開発チームが、Webサーバーやデータベースなどを立てる場所になります。
彼らは、ホストプロジェクトが整備した道路網やサブネットという「インフラ」を借りて、自分たちの郵便物（アプリケーションのデータ）を配送したり、受け取ったりします。
これは、郵便本局が整備したインフラを使って、実際に郵便物を集配する「地域の郵便支局」のような存在です。支局は、道路や集配エリアを自分で作るのではなく、本局が用意したものを使って業務を行う、というわけですね。

Shared VPCのアーキテクチャ解剖！

この関係性を図にすると、ホストプロジェクトがネットワークの中心にドンと構え、複数のサービスプロジェクトがそこからネットワークの「線」を引いて、自分たちのリソースをデプロイする、という形になります。

+-------------------------------------------------------+
|                 ホストプロジェクト (Host Project)     |
|   - VPCネットワーク（道路網全体）                     |
|   - サブネット（郵便局の集配エリア）                   |
|   - ファイアウォールルール（検問所・警備員）           |
|   - VPN/Cloud Interconnect（外部との接続）             |
|   - Cloud Router（経路制御）                          |
|   - Cloud DNS（名前解決）                             |
+--------------------------|---------------------------+
                           |
                           | ネットワークを共有
                           |
        +------------------+------------------+
        |                  |                  |
        |                  |                  |
+-------v-------+  +-------v-------+  +-------v-------+
| サービスP JT A |  | サービスP JT B |  | サービスP JT C |
| - Compute Engine|  | - GKE Cluster  |  | - Cloud SQL   |
| - Cloud Run    |  | - Cloud Function|  | - App Engine  |
| - その他のアプリ |  | - その他のアプリ |  | - その他のアプリ |
+---------------+  +---------------+  +---------------+

サービスプロジェクトは、ホストプロジェクトのネットワーク（具体的にはサブネット）に、自分たちの仮想マシンやGKEクラスター、Cloud SQLインスタンスなどを「配置」します。これにより、異なるサービスプロジェクトにデプロイされたリソース同士でも、まるで同じVPCネットワーク内にいるかのように、プライベートなIPアドレスで安全に通信できるようになるんです。すごいでしょう？

—

なぜShared VPCを使うの？メリットを深掘り！

Shared VPCの仕組みが分かってきたところで、具体的にどんな「いいこと」があるのか、そのメリットを詳しく見ていきましょう。

1. ネットワーク管理の一元化と統制強化

これがShared VPCの最大のメリットと言っても過言ではありません。

中央集権的な管理: ネットワークチームやインフラチームが、ホストプロジェクト一つを見るだけで、組織全体のネットワークインフラ（IPアドレス範囲、サブネット、ファイアウォールルールなど）を一元的に管理できます。
設定ミスやセキュリティリスクの低減: 各プロジェクトがバラバラにネットワークを設定する手間や、それに伴う設定ミス、セキュリティ設定の漏れなどを大幅に減らせます。まるで、郵便本局が全ての郵便物をチェックするルールを決めるので、支局が勝手なルールで送ることを防げるようなものです。
コンプライアンス対応: 企業や業界のセキュリティ基準（PCI DSS, HIPAAなど）に沿ったネットワーク構成を、組織全体で強制しやすくなります。

2. IPアドレス管理の効率化と衝突防止

計画的なIPアドレス割り当て: ホストプロジェクトで、組織全体で利用するIPアドレス空間を計画的に設計し、サブネットを割り当てることができます。
IPアドレスの衝突回避: 各サービスプロジェクトが勝手にIPアドレス範囲を選んでしまうと、プロジェクト間でIPアドレスが重複し、通信ができなくなる「IPアドレス衝突」という厄介な問題が起こりがちです。Shared VPCなら、ホストプロジェクトがIPアドレス空間を管理するため、このような衝突を未然に防げます。

3. セキュリティの向上

一貫したファイアウォールルール: 組織全体のセキュリティポリシーに基づいたファイアウォールルールをホストプロジェクトで定義し、すべてのサービスプロジェクトに適用できます。
内部通信の保護: 異なるサービスプロジェクトにデプロイされたアプリケーション同士が、インターネットを経由せず、プライベートなIPアドレスで安全に通信できます。これにより、データの漏洩リスクを低減し、通信経路をシンプルに保てます。

4. コスト効率とリソースの共有

VPN/Cloud Interconnectなどの共有: 外部ネットワークとの接続（VPNトンネルや専用線接続であるCloud Interconnect）などの高価なネットワークリソースをホストプロジェクトに集約し、複数のサービスプロジェクトで共有できるため、コストを最適化できます。
ネットワークデバイスの集約: Cloud NATやプロキシなどのネットワークアプライアンスもホストプロジェクトにデプロイし、サービスプロジェクトから利用することで、運用コストと管理負荷を削減できます。

5. 組織のスケーラビリティ

新しいプロジェクトの迅速な立ち上げ: 新しい開発プロジェクトが立ち上がった際、ネットワークを一から設計・構築する手間がなく、既存のShared VPCネットワークに「参加」するだけで、すぐに開発に着手できます。
開発と運用の分離: 開発チームはアプリケーションの開発に集中でき、ネットワークの複雑な管理から解放されます。ネットワークチームは、インフラの安定稼働とセキュリティに集中できます。まさに「適材適所」ですね！

—

IAM権限モデル：誰が何をできるの？

Shared VPCを安全に運用するために、誰がどの操作をできるのか、という「IAM（Identity and Access Management）権限」の管理は非常に重要です。

郵便局の例で言えば、「郵便本局のインフラ担当者」と「地域の郵便支局の荷物発送担当者」では、できることが違いますよね？

郵便本局のインフラ担当者（ホストプロジェクトの管理者）:
道路を建設したり、集配エリアを区切ったり、新しい検問所を設置したりする権限を持っています。
つまり、VPCネットワーク、サブネット、ファイアウォールルールといったネットワークリソースそのものを作成・変更・削除する権限です。
具体的なGCPのIAMロールとしては、roles/compute.networkAdmin などがこれにあたります。

地域の郵便支局の荷物発送担当者（サービスプロジェクトの管理者・開発者）:
本局が用意した道路や集配エリアを使って、郵便物（アプリケーション）を発送したり受け取ったりします。
つまり、ホストプロジェクトが共有しているサブネット内に、Compute EngineインスタンスやGKEクラスターなどのリソースをデプロイする権限です。
彼らがホストプロジェクトのネットワーク構成を勝手に変更することはできません。
具体的なGCPのIAMロールとしては、サービスプロジェクトの管理者に、ホストプロジェクトの特定のサブネットに対して roles/compute.networkUser というロールを付与します。このロールは、「このサブネットを使っていいよ」という許可を与えるものだと考えてください。

IAM権限の最小権限の原則

ここで大切なのが、「最小権限の原則」です。必要な人に、必要な権限だけを与える、というセキュリティの基本ですね。

サービスプロジェクトの管理者に、ホストプロジェクト全体へのNetwork Admin権限を与えてしまうと、誤ってネットワーク構成を変更したり、セキュリティポリシーを緩めてしまったりするリスクがあります。そのため、通常は特定のサブネットに対してcompute.networkUserロールを与えるのがベストプラクティスとなります。

—

実際にShared VPCを設定してみよう！ (CLIでの手順)

Shared VPCの設定は、GCPコンソール（Web UI）からでも可能ですが、ここではCLI（コマンドラインインターフェース）での基本的な流れを見てみましょう。プロジェクトIDなどは皆さんの環境に合わせて読み替えてくださいね。

事前準備

1. GCPプロジェクトの用意:

ホストプロジェクトとして使うプロジェクト (your-host-project-id)
サービスプロジェクトとして使うプロジェクト (your-service-project-id)
これらのプロジェクトには、それぞれ請求先アカウントがリンクされている必要があります。

2. gcloud CLIの認証とプロジェクト設定:

# gcloudコマンドの認証
    gcloud auth login

    # ホストプロジェクトのプロジェクトIDを設定
    gcloud config set project your-host-project-id

Step 1: ホストプロジェクトでShared VPCを有効にする

まず、ホストプロジェクトでShared VPCの機能を有効にします。これにより、このプロジェクトがネットワークリソースを共有する「親」になれるようになります。

# ホストプロジェクトでShared VPCを有効化
# コマンド実行後、確認メッセージが表示されるので 'y' で続行します。
gcloud compute shared-vpc enable your-host-project-id

# 完了すると、"Shared VPC host project 'your-host-project-id' enabled." のようなメッセージが表示されます。

Step 2: ホストプロジェクトのサブネットを作成 (もしなければ)

ホストプロジェクトには、サービスプロジェクトが利用するためのサブネットが必要です。もし既存のVPCネットワークとサブネットがあるなら、このステップはスキップできます。

ここでは、新しいVPCネットワークとサブネットを作成する例を示します。

# ホストプロジェクトに新しいVPCネットワークを作成
gcloud compute networks create shared-vpc-network \
    --subnet-mode=custom \
    --project=your-host-project-id # ホストプロジェクトIDを指定

# 作成したVPCネットワーク内にサブネットを作成
# region: サブネットを作成するリージョン（例: asia-northeast1）
# range: サブネットのIPアドレス範囲（例: 10.10.0.0/20）
gcloud compute networks subnets create shared-subnet-tokyo \
    --network=shared-vpc-network \
    --region=asia-northeast1 \
    --range=10.10.0.0/20 \
    --project=your-host-project-id # ホストプロジェクトIDを指定

# もう一つ別のリージョンにサブネットを作成することも可能
gcloud compute networks subnets create shared-subnet-osaka \
    --network=shared-vpc-network \
    --region=asia-east1 \
    --range=10.20.0.0/20 \
    --project=your-host-project-id

Step 3: サービスプロジェクトをホストプロジェクトに接続する

次に、サービスプロジェクトがホストプロジェクトのネットワークを利用できるように、両者を関連付けます。

# サービスプロジェクトをホストプロジェクトに接続
gcloud compute shared-vpc associated-projects add your-service-project-id \
    --host-project=your-host-project-id

# 完了すると、"Project 'your-service-project-id' added to Shared VPC host project 'your-host-project-id'." のようなメッセージが表示されます。

Step 4: サービスプロジェクトのユーザーにIAM権限を付与する

最も重要なステップの一つです。サービスプロジェクトの管理者（または、そのサービスアカウント）が、ホストプロジェクトの共有サブネットを利用できるよう、compute.networkUserロールを付与します。

注意点: SVC_PROJECT_NUMBERは、サービスプロジェクトの「プロジェクト番号」であり、プロジェクトIDではありません。GCPコンソールでプロジェクトを選択し、「プロジェクト情報」から確認できます。

# サービスプロジェクトのプロジェクト番号を取得 (例: 123456789012)
# gcloud projects describe your-service-project-id --format="value(projectNumber)"
# 上記コマンドで取得したプロジェクト番号を SVC_PROJECT_NUMBER に設定します。
SVC_PROJECT_NUMBER="123456789012" # ここは皆さんのプロジェクト番号に置き換えてください

# ホストプロジェクトの特定のサブネットに対して、サービスプロジェクトのサービスアカウントに networkUser ロールを付与
# これにより、サービスプロジェクトは host-project-id の shared-subnet-tokyo を利用できるようになります。
gcloud compute networks subnets add-iam-policy-binding shared-subnet-tokyo \
    --role=roles/compute.networkUser \
    --member=serviceAccount:service-"${SVC_PROJECT_NUMBER}"@compute-system.iam.gserviceaccount.com \
    --region=asia-northeast1 \
    --project=your-host-project-id

# 必要であれば、別のサブネットにも同様に権限を付与
gcloud compute networks subnets add-iam-policy-binding shared-subnet-osaka \
    --role=roles/compute.networkUser \
    --member=serviceAccount:service-"${SVC_PROJECT_NUMBER}"@compute-system.iam.gserviceaccount.com \
    --region=asia-east1 \
    --project=your-host-project-id

補足: 上記のserviceAccount:service-"${SVC_PROJECT_NUMBER}"@compute-system.iam.gserviceaccount.comは、サービスプロジェクトのCompute Engineデフォルトサービスアカウントです。もし特定のユーザーや別のサービスアカウントに権限を付与したい場合は、そのアカウントのメールアドレスを指定してください。

Step 5: サービスプロジェクトでリソースを作成してみる

これで、サービスプロジェクトからホストプロジェクトのネットワークを利用する準備ができました！サービスプロジェクトでCompute Engineインスタンスを立ててみましょう。

# gcloudコマンドのプロジェクトをサービスプロジェクトに切り替え
gcloud config set project your-service-project-id

# サービスプロジェクトでCompute Engineインスタンスを作成
# --subnet オプションでホストプロジェクトのサブネットを指定します。
gcloud compute instances create my-app-instance-1 \
    --machine-type=e2-medium \
    --zone=asia-northeast1-b \
    --subnet=shared-subnet-tokyo \
    --project=your-service-project-id # サービスプロジェクトIDを指定

# インスタンスが作成されると、ホストプロジェクトの shared-subnet-tokyo からIPアドレスが割り当てられます。
# 別のサービスプロジェクトでも同様に、同じサブネットや別の共有サブネットにインスタンスをデプロイできます。

これで、my-app-instance-1は、ホストプロジェクトのshared-vpc-network内にデプロイされ、shared-subnet-tokyoのIPアドレス範囲からIPアドレスが割り当てられます。

—

注意点とベストプラクティス

Shared VPCは強力な機能ですが、いくつかの注意点とベストプラクティスがあります。

ネットワーク設計の重要性: ホストプロジェクトのVPCネットワーク設計（IPアドレス範囲、サブネット設計、ルーティング、ファイアウォールルール）は、組織全体の基盤となります。将来を見据えた、堅牢かつ柔軟な設計が不可欠です。IPアドレスの枯渇や、ルーティングの複雑化は避けるようにしましょう。
IAM権限の徹底: 前述の通り、最小権限の原則を徹底し、不要な権限を与えないように注意してください。特にホストプロジェクトへの広範な権限付与は避けるべきです。
ホストプロジェクトのライフサイクル: ホストプロジェクトは組織のネットワークの根幹となるため、安易に削除したり、変更したりしないように厳重な管理が必要です。運用チームが責任を持って管理する体制を整えましょう。
トラブルシューティング: ネットワーク関連のトラブルが発生した場合、ホストプロジェクトとサービスプロジェクト、両方の設定を確認する必要があります。どこで問題が起きているのかを切り分けるスキルが求められます。

—

まとめ

GCPのShared VPCは、複数のプロジェクトにまたがるアプリケーションを運用する組織にとって、ネットワーク管理を劇的にシンプルにし、セキュリティとスケーラビリティを向上させる非常に強力なツールです。

ホストプロジェクトがネットワークの基盤を一手に引き受け、サービスプロジェクトがその恩恵にあずかることで、開発チームはインフラの複雑さから解放され、本来のアプリケーション開発に集中できるようになります。まるで、信頼できるインフラ担当者が、安心して使える高品質な道路と郵便局のネットワークを提供してくれるようなものですね。

最初は少し難しく感じるかもしれませんが、概念をしっかりと理解し、実際に手を動かしてみることで、その強力なメリットを実感できるはずです。
ぜひ、皆さんのGCP環境でShared VPCの導入を検討し、より効率的でセキュアなクラウドインフラを構築してください！

これからも、クラウドの奥深い世界を一緒に探求していきましょう！