はじめに

Google Cloud のアーキテクチャセンターというドキュメントをご存知でしょうか？こちらには様々なアーキテクチャの構成パターンや、今回の記事を書くきっかけになった各ベストプラクティスのようなものが掲載されていたりと、Google Cloud 上での構築を取り組むにあたり参考になる情報が多く記載されております。私自身も前から改めて整理したいと考えていた、Google Cloud のネットワークについて、眺める機会があったため、そこから学んだ内容について、おさらいとともに紹介させていただきます。

概要

Google Cloud でインフラを構築することを考えると、自然と VPC を作成し、サブネットを作成し、、といった形で進むかと思いますが、VPC が単一となるケースや複数になるケース、独立した VPC とするか共有 VPC にするかなどの考慮事項があり、それによって運用や設計に大きく関わってきます。主に VPC にフォーカスをあてて、メリデメや、想定できる適したユースケース、適さないケースを改めて考えてみたいと思います。

※記載内容はVPC 設計のためのおすすめの方法とリファレンス アーキテクチャをベースに解説していきます。

単一 VPC と共有 VPC

単一 VPC について

Google Cloud のドキュメント上では、単一 VPC で構築することについて以下のように記載されております。

共通の要件と特性を持つリソースを単一の VPC ネットワークにグループ化することで、起こりうる問題の防衛線として VPC ネットワーク境界を設定できます。

このことから、権限や役割の分離が不要な場合には、1つの VPC 上で動作させるような形になるかと思います。懸念点として、1つの VPC 上に複数の要件の違うシステムが動作すると、Firewall の制御が複雑化してしまうのと、問題発生時の影響が他システムにも及んでしまう可能性があることを記載しているのだと思います。Firewall については Google Cloud では AWS のようにインスタンスに紐づく Security Group で通信を制御するのではなく、VPC 内の Firewall Rule に基づいた制御を行うため、Rule 数が多くなりがちになり、管理も煩雑になることが想定されます。

単一 VPC の主なケース
  • 小規模・単一チームでの利用
    • 管理する主体が一つで、複雑な権限分離が不要な場合。
  • 迅速なプロトタイピングや PoC
    • スピードが重視される場合。
  • 完全に独立したワークロード
    • 他のシステムとの連携がほとんどなく、自己完結しているアプリケーション。

共有 VPC について

Google Cloud のドキュメント上では、共有 VPC を活用することについて以下のように記載されております。

組織内に複数のチームがある場合、共有 VPC は、単一 VPC ネットワークのシンプルなアーキテクチャを複数の作業グループに拡張するための効果的なツールになります。シンプルなアプローチは、単一の共有 VPC ネットワークをホストプロジェクトにデプロイしてから、サービスプロジェクトをホストプロジェクトのネットワークに接続することです。

ここで記載されているのは、VPC を一つにしたことで、ネットワークの境界を設け、システム上の機能・役割等により分離できた状態となりますが、作業を行うグループや部門として、権限を分離したい場合に有用だと言うことが記載されています。それの簡単な例としては、 共有 VPC を作成したプロジェクトをホストプロジェクトとして位置づけ、共有 VPC 上に構築する GCE を作成しているプロジェクトをサービスプロジェクトとして作成することで、プロジェクト単位で権限の分離ができるということ、NW はホストプロジェクト側で管理し、アプリケーションはサービスプロジェクト側で NW 以外のリソースを管理し責任範囲が明らかになります。

sharedvpc-basic

共有 VPC の主なケース
  • 中規模〜大規模組織での利用 複数のチームや事業部が関わる場合。
    • NW 周りはインフラ部門が管理し、Webアプリケーションは A という開発部門、データベースは B という開発部門といった形で、部門単位で責任分界点を明確に分けることが可能になります。
    • 補足すると、中央集権的なネットワーク管理として、インフラ部門がオンプレミス接続（VPN/Interconnect）や Firewall Rule やサブネットの払い出しなどが、権限も分離されていることから一元的に管理・統制を行いやすくなります。
    • ドキュメントに記載のあるサブネット レベルでネットワーク ユーザーロールを付与するでは、組織での権限制御も踏まえて記載されています。
    • ドキュメントの中を読み解いてみると、複数のパターンで書かれていますが、組織(Google Cloud の組織)の階層構造を利用して、組織の権限で共有 VPC 管理者など共通するインフラ権限を付与し、開発者に対してはプロジェクト単位でネットワークユーザを付与するというシナリオが書かれています。実際には組織のフォルダ単位で権限付与するなどもあるかと思いますが、権限のあてかたや必要なものを理解しておければ、柔軟に組織単位やプロジェクト単位で権限を調整することが可能になります。
共有 VPC が「適していない」ケース

以下のケースでは、導入することにより逆に管理を複雑にする可能性があります。

  • チームの自律性が高い場合
    • 同じネットワークポリシーも含めて、各事業部や開発チームが完全に独立して意思決定を行いたい組織文化の場合、中央集権的な共有 VPC は非効率になる可能性があります。
  • 中央管理チームが存在しない場合
    • ホストプロジェクトを管理・運用するチームが存在しない場合に、形だけ共有 VPC を導入することも非効率となります。
  • 共有する共通リソースがない場合
    • オンプレミスとの共通接続や、集約したいファイアウォールルールなどが特にないのであれば、共有 VPC のメリットはなくなってしまいます。

推奨される VPC の分け方

VPCは分離できる境界に基づいて分けることがおすすめです。以下例となります。

  • 環境による分離
    • prd-vpc, stg-vpc, dev-vpc のように、本番・ステージング・開発環境でVPCを分離します。
  • 組織や事業部による分離
    • 経理システムと営業システムのように管轄部署が明確に異なる場合や、同一 NW 内で動作することが不要であれば、VPCレベルで分離することで、責任範囲と権限を明確に分離することができます(単一 VPC で記載したケースと似たようなイメージです)
  • セキュリティ要件による分離
    • PCI-DSS準拠が求められるシステムと、そうでないシステムを別のVPCに分離するなど、セキュリティ要件を境界として分離します。

プロジェクトあたり複数 VPC は避けるべきか？

Google Cloud のドキュメント上では、複数 VPC について以下のように記載されております。

プロジェクトごとに単一 VPC ネットワークを作成することをおすすめします。そうすれば、プロジェクト レベルの割り当ての増加を各 VPC ネットワークにマッピングできるので、同じプロジェクト内の VPC の組み合わせにマッピングするより簡単です。
Google サポートはスケーリングの上限を上げることはできますが、スケーリング要件を満たすために複数の VPC ネットワークを何度も作成しなければならないことがあります。VPC ネットワークが上限を超えてスケーリングする必要がある場合は、Google Cloud セールスチームおよびサポートチームと相談して、要件を満たす最適な方法を検討してください。

1プロジェクトあたり、複数　VPC を作成するようなケースとして、VPC リソースあたりのクォータ制限にフォーカスをあてた内容で記載されております。ただ、プロジェクトの制限イコール VPC 制限とマッピングしたほうがわかりやすく区別できることから、プロジェクトあたり 1 VPC であることが推奨されていることが記載されております。これによって同一の役割や権限の中においても、複数 VPC 利用については推奨されていないことがわかるかと思います。

VPC間の接続方法

分離したVPC同士を接続する必要がある場合、以下の選択肢があります。

  • VPC ピアリング
    • 2つのVPCを直接接続します。設定はシンプルですが、推移的ルーティング（A-B、B-CとピアリングしてもAとCは通信できない）はサポートされない点に注意が必要です。
  • Cloud VPN / Cloud Interconnect
    • VPC（またはオンプレミス）と VPCをプライベート通信を行いたい場合に利用し、上記とは異なり推移的なルーティングが可能になります。この構成をより大規模かつ管理しやすく実現するのが次のNetwork Connectivity Centerです。
  • Network Connectivity Center
    • VPC 同士や、オンプレミスとの VPN 接続や、Interconnect 接続を管理することが可能な、Google Cloud のマネージドな接続サービスです。VPCや、オンプレないしVPCとのVPN、オンプレとの Interconnect 接続などを「スポーク」として中央の「ハブ」に接続することで、ネットワークを一元管理することが可能です。VPCピアリングの課題であった推移的ルーティングも実現可能で、大規模なネットワークを管理したい場合に有効な選択肢です。
    • こちらにメリットが記載されておりますが、VPC 間で IP アドレスの再利用ができるというのは、移行やシフトリフトするうえで、重要な考慮事項になるかと思います。
  • Private Service Connect (PSC)
    • VPC 間で特定のサービスをプライベートに公開・利用するための仕組みです。ピアリングや VPN 接続をせずにプライベートに対象インスタンスやサービスへアクセス可能です。そのため、VPC 全体を接続するのではなく、特定のエンドポイントを通じてサービスを共有したい場合に良き選択肢となります。Google Cloud 自体のサービスを公開するケース、AlloyDB、Cloud SQL をプライベートに公開するケースなど、Private Service Connect は複数の意味合いもあるので、詳細はこちらをご確認ください。

考慮ポイント

Google Cloud のドキュメントに、ポイントの記載がありましたので、その内容の中で考慮するケースが多いと感じられる内容にフォーカスを当てて記載します。

プライベート IP の通信が不要な場合外部ルーティングする

こちらに以下のような記載があります。

外部アドレス指定された VM は、リージョンおよびネットワーク サービス階層にかかわらず、Google のバックボーンを介して互いに限定公開で通信します。ファイアウォール ルールを使用して、VM への外部からの上り（内向き）トラフィックを制御します。 Google Cloud

和訳に若干違和感がありますが、Google Cloud 内のパブリック IP 同士の通信は Google Cloud の提供しているバックボーン内で解決するため、公衆回線にでていかないことを意味しています。プライベート通信によって NW が煩雑化することを加味して、この記載があるものと思いますが、デメリットとして、ネットワーク通信の金額面に影響があるため、実際の設計にあたっては、その点も加味する必要があります。

VPC に関連するネットワークセキュリティ

ここまでは VPC の分け方などをユースケースを交えて記載しましたが、最後に VPC に関わる NW セキュリティについて記載します。 Google Cloud のドキュメント上のこちらに書いている内容を中心に記載します。
※ここでは今まで記載した VPC の分離、プロジェクトの分離にかかるものと、VPC内の基本的な NW 制御について記載しており、Cloud Armor 、Cloud NGFWについては対象外しております。

  • VPC Service Controls
    • VPCファイアウォールがL4レベルの通信を制御するのに対し、VPC Service Controlsはデータ漏洩を防ぐためのサービス境界を作成します。この境界内からのみ、BigQuery や Cloud Storage といった Google Cloud のマネージドサービスへの API アクセスを許可する、といった制御が可能です。
  • 外部アクセスの制限
    • 限定公開アクセスによって、外部 IP アドレスを持たない VM インスタンスから、Google API やサービスにプライベートにアクセスするための機能で、外部アクセスを制限した際に、Google API を叩くのに必須な機能となります。
    • すでに登場している、Private Service Connect を利用して、データベースや各種サービスとプライベート通信を行うことが可能となり、これも外部接続を制限するうえで必要な機能となります。
    • そもそもの外部アクセスを根本から制御したい場合、組織の制限にて、外部 IP アドレスの割当を GCE に禁止させたりすることも可能となります。
  • サービスアカウントを使用したVM分離
    • ファイアウォールルールは、ネットワークタグだけでなくサービスアカウントにも紐付けることができます。これにより、IPアドレスやサブネットといったネットワーク情報ではなく、「VMのID」に基づいて通信を制御できます。同じサブネット内にあるVM同士でも、サービスアカウントが異なれば通信をブロックする、といった動的でよりセキュアなルールが実現可能です。

まとめ

今回は、Google Cloud の VPC 設計について、アーキテクチャセンターの記載から、気になる点をピックアップし、一歩踏み込んで意図を自分なりに解釈してみました。

特に 共有 VPC、複数 VPC の扱いに関して重点的に記載しておりますが、共有 VPC という仕組みに対する必要性について、事前に権限の分離、作業対象に関する責任分界点を明確にするという表面的な認識だけでしたが、踏み込んだことで、その意味合いを認識しました。

記載した内容を加味すると通常の VPC 利用を選ぶケースが多いと感じましたが、共有 VPC による複数プロジェクトを利用した設計を行ったほうが、より効率的に強固な設計を行うことが可能な場面は訪れると思うので、自身の業務や案件に割り当てて考え、どういったケースが適しているか再度考え直すきっかけとなりました。また、他 VPC との接続を考慮した際の、PSC の有用性について、ただのピアリングだったり、VPN、Interconnect でつなぐ以上の価値を改めて痛感しました。

こういったアーキテクチャに関する事項は正解がない内容になるため、その時々アップデートの情報により左右される面もあり、十分考慮が必要ということを再認識しました。深し。