G-gen の出口です。当記事では、Google Cloud Next Tokyo '24「Google Cloud のインフラストラクチャ構成のベスト プラクティスを一挙に紹介」に関する速報レポートをお届けします。
セッションレポートなど、Google Cloud Next Tokyo '24 の関連記事は Google Cloud Next Tokyo '24 の記事一覧からご覧いただけます。
概要
本セッションでは、VPC、外部接続、サービスへのアクセスと3つの場合におけるインフラストラクチャ構成のベストプラクティスが紹介されました。
VPC
特別な要件がない場合、VPC は1つだけ利用することが推奨されます。別々のプロジェクトにあるリソースも、同一組織であれば、共有 VPC を利用して1つの VPC に収容することができます。
一方で、VPC が複数必要になる場合があります。異なる VPC 間で通信する必要がある場合、従来までは VPC ネットワークピアリングで接続するのが一般的でしたが、最近では Network Connectivity Center を用いて VPC 間をハブアンドスポーク構成で接続することもできます。
Network Connectivity Centerについての詳しい情報は、以下の記事をご覧ください。
VPC のファイアウォール機能には、ファイアウォールルールとファイアウォールポリシーの2種類があります。ファイアウォールルールは VPC に対して個別に設定する必要がありますが、ファイアウォールポリシーは複数の VPC で使い回すことができます。
さらに、ファイアウォールポリシーはフォルダや組織単位でも設定でき、トラフィックの許可・拒否だけでなく L7 レイヤ （アプリケーション層）の検査も可能です。
ただし、ファイアウォールルールが無料で利用できるのに対し、ファイアウォールポリシーは適用される VM の台数に応じた料金が発生するため、注意が必要です。
ファイアウォールルールおよびファイアウォールポリシーの詳細については、以下の記事をご覧ください。
外部接続
オンプレミスとのマルチリージョン接続では、それぞれのリージョンで Cloud Interconnect を2本、接続するとが推奨されます。これによって、SLA 99.99%での提供が可能です。
オンプレミスのアドレスが VPC サブネットのアドレスと重複してしまう場合は、Cloud NAT のハイブリット NAT 機能を用いることで、アドレス範囲が重複していても通信できます（ハイブリット NAT 機能は2024年8月現在、プレビュー提供です）。
また、Private Service Connect 機能を使うと、同機能がプロキシの役割を果たし、IP レイヤでのリーチャビリティが無くても、オンプレミスから VM 等に接続させることができます。これにより、サブネットの IP アドレスレンジが重複している場合でも通信することができます。
オンプレミスのネットワークと VPC ネットワークで同じ IP アドレスレンジを利用したい場合、ハイブリッドサブネットを用いるという選択肢もあります。BGP による広告を利用し、論理的に単一サブネットを構成できます（ハイブリッドサブネット機能は2024年8月現在、プレビュー提供です）。
サービスへのアクセス
Cloud Load Balancing
Google Cloud が提供するロードバランサーである Cloud Load Balancing には多くの種類があります。「トラフィックがレイヤ4（TCP/UDP）かレイヤ7（HTTP/HTTPS）か」、レイヤ4の場合は「プロキシ型かパススルー型か」、「接続元クライアントがインターネット経由でアクセスするか、プライベートネットワーク経由でアクセスするか」、「ロードバランサーの配置場所はグローバル展開されているか、リージョンに閉じているか」といった観点で使い分けを検討します。
各種ロードバランサーにはそれぞれに適切な用途が存在しますが、次のように検討します。
- 外部ロードバランサで、レイヤ7のHTTP（S）トラフィックを受け取る場合、特別な理由がなければ「グローバル外部アプリケーションロードバランサ」を検討
- 外部ロードバランサで、レイヤ4の場合、TCP プロトコルでグローバルに分散したい場合は「外部プロキシネットワークロードバランサ」を、TCP プロトコルを単一リージョン内で分散したい場合や UDP プロトコルの場合は「外部パススルーネットワークロードバランサ」を検討
- 内部ロードバランサで、レイヤ7のHTTP（S）トラフィックを受け取る場合、特別な理由がなければまず「クロスリージョン内部アプリケーションロードバランサ」を検討
- 内部ロードバランサで、レイヤ4の場合、TCP プロトコルでグローバルに分散したい場合は「内部プロキシネットワークロードバランサ」を、TCP プロトコルを単一リージョン内で分散したい場合や UDP プロトコルの場合は「内部パススルーネットワークロードバランサ」を検討
以下の画像は内部ウェブアプリケーションの構成図です。クロスリージョンのロードバランサを用いることで、バックエンドがダウンした場合でもセッションが終了することなく切り替えることができます。
内部ウェブアプリケーションで Cloud Armor（Google Cloud が提供するフルマネージドの WAF）を用いる場合は、リージョナルのロードバランサを用います。
以下の画像はウェブアプリと非 VM バックエンドの構成図です。非 VM バックエンドとは、Cloud Run や App Engine など、VM 以外のサーバーレスなバックエンドを指します。ロードバランサのバックエンドには、VM や非 VM のバックエンドだけでなく Google Cloud のノードを指定することもできます。
Private Service Connect
プロジェクトを越えて通信したい場合で VPC 同士を接続する必要がある場合、VPC の項で説明したように、これまでは VPC ネットワークピアリングが利用されてきました。しかし今後は Private Service Connect が推奨されています。Private Service Connect を利用すると、サブネット間でアドレスが重複していても問題がありません。
Private Service Connect については、以下の記事で詳しく説明されているので、ぜひご覧ください。
また、Cloud SQL や Vertex AI などの Google が管理する専用の VPC 内に作成されるサービスに、ユーザーが作成した VPC からアクセスするには、これまで Private Service Access が用いられてきましたが、これも Private Service Connect に置き換えることができます。
Private Service Access は VPC ネットワークピアリングを使う仕組みのため、VPC をまたいだ接続（推移的な接続）ができず、VPC ネットワークピアリングで繋がった VPC のさらに先にある VPC とは通信ができません。一方、Private Service Connect であれば VPC ネットワークピアリングを用いないため各 VPC から直接接続できます。さらに Network Connectivity Center ハブを経由して Private Service Connect に接続することで、各 VPC に Private Service Connect エンドポイントを用意する必要もありません。
関連記事
セッションレポートなど、Google Cloud Next Tokyo '24 の関連記事は、以下の記事一覧からご覧いただけます。
