Google CloudのShared VPCを用いたハイブリッド環境設計の勘所

はじめに

こんにちは。
マイクロアド基盤開発グループでインフラエンジニアをしている森( id:bosq )です。

マイクロアドでは広告配信サーバはオンプレミス環境を利用していますが、去年頃からパブリッククラウドへのスケールアウトを目的とした検証に取り組んでいます。
本記事では、検証環境の準備にあたり、オンプレミスとGoogle Cloudでハイブリッド環境を設計した際に考慮した点について解説します。

はじめに
VPC と Shared VPC
- 構築時の権限について
- 組織ポリシーによる制約
Cloud DNS
オンプレミスネットワークとの接続
全体のネットワーク設計
おわりに
参考情報
インフラエンジニア募集

VPC と Shared VPC

まずはハイブリッド環境を構築するためのネットワークについて説明します。

Google Cloudでは、VPC（Virtual Private Cloud）というネットワーキング機能を提供されており、VMなどを稼働させるにはまずVPCに仮想ネットワークが必要となります。 VPCはグローバルリソースですので、実際にVMを作成する際には、各リージョンにVPCと紐づくサブネットワーク（サブネット）を作成し、VMはいずれかのサブネットに所属します。また、アクセスを制限・許可するためのファイアウォールルールは、VPC毎に定義でき、VPCに属するサブネット内で利用できます。

Google CloudではVPCなどのリソースはプロジェクト単位で分離されています。そのため、通常のVPCではプロジェクト毎に共通の設定があったとしても再設定する必要があります。

共通の設定を一元管理したい場合には、Shared VPCという特殊なVPCを利用することで、複数のプロジェクトから共通のVPCネットワークを利用できます。 Shared VPCが定義されたプロジェクトをホストプロジェクト、サブネットを利用するプロジェクトをサービスプロジェクトと呼ばれます。

Shared VPCの利点として、ホストプロジェクトでファイアウォールルールやVPN設定を管理することで、用途毎にサービスプロジェクトを分けつつ、元となるネットワーク設定を流用できる点があります。

Google Cloudではアプリケーションや環境(開発、ステージング、本番など)毎でプロジェクトを分けることが一般的な推奨事項とされています¹。そのため、Shared VPCの利用によって、初回のネットワーク構築後は、利用用途毎にサービスプロジェクトを割り当てられるため、権限の分離が容易になります。

以下にShared VPCを用いてアプリケーション（APP1とAPP2）と環境（開発・本番）でネットワークを分離した設計を示します。この設計では、開発用VPCネットワークと本番用VPCネットワークでVPNが構築されており、「APP1」と「APP2」でそれぞれ開発用と本番用でサブネットを分けて利用するようになっています。これによって、開発環境の通信が本番環境に影響を与えることなく、構築したVPNを各環境に対応するアプリケーションで共有して利用できます。

参考:
ハイブリッドクラウドのシナリオ | Google Cloud
VPC 設計のためのおすすめの方法とリファレンスアーキテクチャ | Google Cloud

構築時の権限について

Shared VPCを管理（ホストプロジェクトの有効化やサービスプロジェクトをホストプロジェクトに接続する操作など）するには、以下のIAMロールが必要となります。

※ ロールの割り当て操作には、組織管理者(resourcemanager.organizationAdmin)ロール相当の権限が必要となります。

共有 VPC 管理者（compute.xpnAdmin）ロールについては、フォルダレベルでの設定は2023年3月13日から可能になる予定となっています²。

筆者が構築作業をした2022年12月9日時点では、上記ロールをフォルダレベルで付与した際には権限不足で構築できませんでした。また、公式ドキュメントにも以下のようにベータ版と記載がありました。

• フォルダ内の IAM プリンシパル（ベータ版）

そのため、構築時はフォルダレベルでなく、組織レベルで必要最小限に絞った権限を持つカスタムロールを作成・付与することで対応しました。

Shared VPCの管理には少なくとも以下の権限が必要だと判断し、設定しました。

compute.organizations.enableXpnHost
compute.organizations.disableXpnHost
compute.organizations.enableXpnResource
compute.organizations.disableXpnResource

また、Shared VPCの管理側とは別にサブネットを利用する側には、サービスプロジェクト管理者として以下のロールが必要となります。

Compute ネットワークユーザー（roles/compute.networkUser）

参考:
必要な管理者のロール | 共有 VPC | Google Cloud

組織ポリシーによる制約

Google Cloudでは、組織ポリシーを設定することで各リソースの利用を制約できます。設定には、組織ポリシー管理者（roles/orgpolicy.policyAdmin）のロールが必要となります。

組織ポリシー管理者は、Shared VPCに関連する以下の2つの組織ポリシーを定義できます。

constraints/compute.restrictSharedVpcHostProject：ホストプロジェクトの接続を制限するポリシー
constraints/compute.restrictSharedVpcSubnetworks：サービスプロジェクトがアクセスできるShared VPCサブネットを制限するポリシー

参考:
組織ポリシーの制約 | 共有 VPC | Google Cloud

マイクロアドでは、基盤開発グループで一元的にインフラを管理しており、ホストプロジェクト・サービスプロジェクトの初期設定も基盤開発グループで担当します。そのため、constraints/compute.restrictSharedVpcHostProjectのポリシーは不要と判断し定義していません。

constraints/compute.restrictSharedVpcSubnetworksは、ユーザが複数のサービスプロジェクトの権限を持つ場合に有効です。定義することで、ユーザが意図しないサブネットにリソースを作成することを防止できます。

参考:
組織のポリシーの制約 | Resource Manager のドキュメント | Google Cloud

Cloud DNS

Cloud DNSはGoogle Cloudで利用できるDNSサービスです。ゾーンには、一般公開ゾーンと限定公開ゾーンがあり、文字通りVPCネットワーク内だけに限定した名前解決には限定公開ゾーンを利用します。

名前解決の設定としては、以下の３種類を考慮する必要があります。

VPC内の名前解決
アウトバウンド（VPCからオンプレミスへの問い合わせ）の名前解決
インバウンド（オンプレミスからVPCへの問い合わせ）の名前解決

VPC内の名前解決

同一VPC内にあるGCEインスタンス同士の名前解決については、内部DNSという仕組みがあるため、特に設定は必要ありません。

インスタンスの作成・削除に合わせて、以下のどちらかの形式でAレコードが自動的に作成・削除されます。

<インスタンス名>.<ゾーン>.c.<プロジェクトID>.internal
<インスタンス名>.c.<プロジェクトID>.internal

上記以外の命名規則でレコード登録をしたい場合は、手動でのゾーン追加が必要となります。
今回の設計では、オンプレミス側の命名規則に従って命名するため、限定公開ゾーンとして登録することにしました。

アウトバウンドの名前解決

アウトバウンドの名前解決では、ゾーン転送という機能を利用することで特定のドメインに関するクエリのみオンプレミス側に転送できます。

クエリが転送されるとクエリの送信元はCloud DNSのIPアドレスとなります。
そのため、戻りパケットがインターネットでなく、トンネルを経由するようにCloud Routerで経路情報を広報する必要があります。
具体的には、Cloud Routerでカスタム経路広報の設定で 35.199.192.0/19 を指定します。

VPNトンネルなど複数の接続を考慮する場合は、DNSピアリングが必要となります。理由としては、オンプレミス側から見るとDNSの戻りパケットの経路情報はCloud DNSのものしか見えず、それがどの経路に返せばいいかわからないためです。

公式ドキュメントとしてCloud DNSのベストプラクティスが用意されており、その中で「ハイブリッド DNS のリファレンスアーキテクチャ」の項目で設計パターンが紹介されています。今回の設計では、Shared VPCを用いた設計パターン「複数の VPC ネットワークを使用するハイブリッドアーキテクチャ」を採用しました。

インバウンドの名前解決

アウトバウンドの名前解決はゾーンを設定していたのに対して、インバウンドの名前解決では、「DNS ポリシー」の設定で実現します。
ポリシー設定後、受信転送用にIPアドレスが払い出されるため、そのIPアドレスをオンプレミスのリゾルバサーバで転送先として設定します。

マイクロアドでは、オンプレミス環境で利用しているプライベートIPアドレスはDnsmasqで管理し、サーバ一覧をhostsファイルとしてGit管理しています。
今回の設計にあたっては、以下の2点の理由で DNS ポリシーによる設定をせず、オンプレミス側のhostsで管理する設計としました。

他のサーバ同様にオンプレミス側で一覧として管理したいこと
構築時点でGoogle Cloud側でのIPアドレスの払い出しが多くはなく、hosts編集の手間があまりないこと

オンプレミスネットワークとの接続

オンプレミスネットワークとVPCネットワークを接続するには以下の２種類の方法があります。

専用線を用いたCloud Interconnect
インターネットを経由するCloud VPN

利用目的としては、実運用ではなく検証目的のため、一旦Cloud VPNを用いた構成を採用しました。 Google Cloud側で利用するVPN接続には、VPNトンネルを張るCloud VPNとCloud Routerを利用します。オンプレミス側の設定には、strongSwanとFRRを利用しましした。

	オンプレミス	Google Cloud
IPsec VPNの構築	strongSwan	Cloud VPN
BGPによる経路広報	FRR	Cloud Router

オンプレミス環境の具体的な設定について以下の記事で解説していますので、そちらをご参照ください。

developers.microad.co.jp

全体のネットワーク設計

以下の図が最終的に構築したネットワークとなります。検証などが主目的となるため、一旦開発用と本番用の2環境のみとし、開発用のVPNトンネルは常設するため開発側のCloud DNSをピアリングする構成としています。

今回の構成は最小限の構築のため、今後の利用状況によってはShared VPCやトンネルを増やすような想定となっています。例えば、特定のアプリによるオンプレミス環境への通信で帯域を専有する可能性がある場合は、トンネルを分ける必要が出てくる可能性があります。リソースを作成する際は、増築を考慮しリソース名にナンバリングを含めるなど命名を統一しやすくする工夫を検討することを推奨します。

参考:
VPN トンネルの過剰使用を確認する | Google Cloud