ランディング ゾーンを設計する際は、組織に適したネットワーク設計を選択する必要があります。このドキュメントでは、4 つの一般的なネットワーク設計について説明します。これにより、組織の要件に最適なオプションと、集中管理または分散管理に関する組織の設定を選択できます。このドキュメントは、組織のランディング ゾーンのネットワーク設計に関与するネットワーク エンジニア、アーキテクト、技術者を対象としています。
この記事は、ランディング ゾーンに関するシリーズの一部です。
ネットワーク設計を選択する
どのネットワーク設計を選択するかは、主に次の要因によって異なります。
- 一元管理または分散管理: 組織の目的に応じて、次のいずれかを選択する必要があります。
- IP アドレス指定、ルーティング、異なるワークロード間のファイアウォールなどのネットワークの制御を一元管理します。
- チームの自律性を高め、独自の環境を運用し、環境自体でネットワーク要素を構築できるようにします。
- オンプレミスまたはハイブリッド クラウドの接続オプション: このドキュメントで説明するネットワーク設計はすべて、Cloud VPN または Cloud Interconnect を通してオンプレミスからクラウド環境へのアクセスを提供します。ただし、一部の設計では複数の接続を並行して設定する必要があり、その他の設計ではすべてのワークロードで同じ接続を使用します。
- セキュリティ要件: 組織では、Google Cloud の異なるワークロード間のトラフィックが、次世代ファイアウォール（NGFW）のような一元管理されたネットワーク アプライアンスを通過する必要がある場合があります。この制約は、Virtual Private Cloud（VPC）ネットワークの設計に影響します。
- スケーラビリティ: デプロイするワークロードの数と仮想マシン（VM）の数、内部ロードバランサ、ワークロードで使用するその他のリソースによっては、一部の設計が他の設計と比較して組織により適している可能性があります。
ネットワーク設計の意思決定のポイント
次のフローチャートは、組織に最適なネットワーク設計を選択するために必要な決定事項を示しています。
上の図は、次の質問について示しています。
- Google Cloud の異なるワークロード間でネットワーク アプライアンスを使用したレイヤ 7 検査が必要ですか？
- 「はい」の場合は、一元管理されたアプライアンスを使用したハブアンドスポーク トポロジをご覧ください。
- 「いいえ」の場合は、次の質問に進みます。
- 多くのワークロードでオンプレミス接続が必要ですか？
- 「はい」の場合は、決定事項 4 に進みます。
- 「いいえ」の場合は、次の質問に進みます。
- ワークロードは、サービス プロデューサー モデルとコンシューマ モデルのプライベート エンドポイントを使用して通信できますか？
- 「はい」の場合は、Private Service Connect を使用してコンシューマ プロデューサー モデルでサービスを公開するをご覧ください。
- 「いいえ」の場合は、次の質問に進みます。
- ファイアウォールとルーティングを一元管理しますか？
- 「はい」の場合は、各環境の共有 VPC ネットワークをご覧ください。
- 「いいえ」の場合は、アプライアンスを使用しないハブアンドスポーク トポロジをご覧ください。
このグラフは意思決定に役立つものですが、組織によっては複数の設計が適している場合もあります。そのような場合は、ユースケースに最適な設計を選択することをおすすめします。
ネットワーク設計オプション
以降のセクションでは、4 つの一般的な設計オプションについて説明します。ほとんどのユースケースに対して、オプション 1 をおすすめします。このセクションで説明する他の設計は、特定の組織のエッジケースの要件に適用される代替案です。
ユースケースに最適なネットワークは、このセクションで説明する複数の設計オプションの要素を組み合わせるネットワークである場合もあります。たとえば、ハブアンドスポーク トポロジで共有 VPC ネットワークを使用することで、コラボレーションを強化し、集中管理を行い、VPC スポークの数を制限できます。また、大部分のワークロードは共有 VPC トポロジで設計しますが、少数のワークロードは個別の VPC ネットワークに分離して、Private Service Connect で少数の定義済みエンドポイントを介してのみサービスを公開することもできます。
オプション 1: 各環境の共有 VPC ネットワーク
ほとんどのユースケースに、このネットワーク設計をおすすめします。この設計では、Google Cloud のデプロイ環境（開発、テスト、本番環境）ごとに個別の共有 VPC ネットワークを使用します。この設計により、ネットワーク リソースを共通のネットワークで一元管理し、異なる環境間のネットワーク分離を実現できます。
この設計は、次の条件に該当する場合に使用します。
- ファイアウォール ルールとルーティング ルールを一元管理する必要がある。
- シンプルでスケーラブルなインフラストラクチャを必要としている。
- 一元化された IP アドレス空間の管理が必要である。
次の条件に該当する場合は、この設計の使用を回避してください。
- 独自のファイアウォール ルール、ルーティング、他のチーム ネットワークとのピアリングを管理する機能など、完全な自律性をデベロッパー チームに付与する必要がある。
- NGFW アプライアンスを使用したレイヤ 7 検査を必要としている。
次の図は、この設計の実装例を示しています。
上の図は、次のことを示しています。
- オンプレミス ネットワークは 2 つの地理的位置に分散しています。
- オンプレミス ネットワークは、冗長な Cloud Interconnect インスタンスを介して 2 つの個別の共有 VPC ネットワーク（本番環境と開発環境）に接続します。
- 本番環境と開発環境は、それぞれ異なる VLAN アタッチメントを使用して、両方の Cloud Interconnect インスタンスに接続されます。
- 各共有 VPC には、ワークロードをホストするサービス プロジェクトがあります。
- ファイアウォール ルールはホスト プロジェクトで一元管理されます。
- 開発環境の VPC 構造は本番環境と同じです。
設計上、ある環境からのトラフィックは別の環境に到達することはできません。ただし、特定のワークロードが相互に通信する必要がある場合は、オンプレミスで制御されたチャネルを介したデータ転送を許可できます。また、Cloud Storage や Pub/Sub などの Google Cloud サービスを使用してアプリケーション間でデータを共有できます。環境間で誤ってデータを混在させるリスクが増えるため、VPC ネットワーク ピアリングを介して個別の環境を直接接続しないことをおすすめします。大規模な環境間で VPC ネットワーク ピアリングを使用すると、ピアリングとピアリング グループに関する VPC に達するリスクも高まります。
詳しくは以下をご覧ください。
- 共有 VPC の概要
- エンタープライズ基盤ガイドの共有 VPC アーキテクチャ
- VPC 設計のためのベスト プラクティスのリファレンス アーキテクチャ
- Fabric FAST フレームワークを構成する Terraform デプロイ ステージ: 個別の環境でのネットワーク
- Cloud Foundation Toolkit を使用した Terraform のサンプル基盤のネットワーク ステージ
この設計オプションを実装するには、オプション 1: 各環境の共有 VPC ネットワークを作成するをご覧ください。
オプション 2: 一元管理されたアプライアンスを使用するハブアンドスポーク トポロジ
このネットワーク設計では、ハブアンドスポーク トポロジを使用します。ハブ VPC ネットワークには、ワークロードを含むスポーク VPC ネットワークに接続する NGFW などの一連のアプライアンス VM が含まれます。ワークロード、オンプレミス ネットワーク、インターネット間のトラフィックは、検査とフィルタリングのためにアプライアンス VM を経由してルーティングされます。
この設計は、次の条件に該当する場合に使用します。
- 異なるワークロードやアプリケーション間でレイヤ 7 検査を必要とする。
- すべてのトラフィックにセキュリティ アプライアンス ベンダーを指定する企業義務がある。
次の条件に該当する場合は、この設計の使用を回避してください。
- ほとんどのワークロードでレイヤ 7 検査は不要である。
- Google Cloud のワークロードが相互にまったく通信しないようにする必要がある。
- オンプレミス ネットワークに送信されるトラフィックのレイヤ 7 検査のみを必要としている。
次の図は、このパターンの実装例を示しています。
上の図は、次のことを示しています。
- ハブ VPC ネットワークとワークロードを含む複数のスポーク VPC ネットワークを含む本番環境。
- スポーク VPC ネットワークは、VPC ネットワーク ピアリングを使用してハブ VPC ネットワークに接続されます。
- ハブ VPC ネットワークには、マネージド インスタンス グループ内の仮想アプライアンスの複数のインスタンスがあります。マネージド インスタンス グループへのトラフィックは、内部パススルー ネットワーク ロードバランサを通過します。
- スポーク VPC ネットワークは、内部ロードバランサをネクストホップとする静的ルートを使用し、仮想アプライアンスを介して相互に通信します。
- Cloud Interconnect は、トランジット VPC ネットワークをオンプレミス ロケーションに接続します。
- オンプレミス ネットワークは、個別の VLAN アタッチメントを使用して同じ Cloud Interconnect を介して接続されます。
- トランジット VPC ネットワークは、仮想アプライアンス上の別のネットワーク インターフェースに接続されます。このインターフェースでは、アプライアンスを使用して、これらのネットワークを経由するすべてのトラフィックを検査およびフィルタできます。
- 開発環境の VPC 構造は本番環境と同じです。
- この設定では、ソース ネットワーク アドレス変換（SNAT）は使用されません。Google Cloud では、対称ハッシュが使用されるため、SNAT は必要ありません。詳細については、対称ハッシュをご覧ください。
設計上、あるスポーク ネットワークからのトラフィックは別のスポーク ネットワークに到達することはできません。ただし、特定のワークロードが相互に通信する必要がある場合は、VPC ネットワーク ピアリングを使用してスポーク ネットワーク間にダイレクト ピアリングを設定できます。また、Cloud Storage や Pub/Sub などの Google Cloud サービスを使用してアプリケーション間でデータを共有することもできます。
アプライアンスがワークロード間の通信時に低レイテンシを維持するには、アプライアンスがワークロードと同じリージョン内に存在する必要があります。クラウド デプロイで複数のリージョンを使用する場合は、各リージョンの環境ごとに 1 つのアプライアンスと 1 つのハブ VPC を使用できます。または、ルートを含むネットワーク タグを使用して、すべてのインスタンスが最も近いアプライアンスと通信するように設定できます。
ファイアウォール ルールで、ワークロードを含むスポーク VPC ネットワーク内の接続を制限できます。多くの場合、ワークロードを管理するチームはこれらのファイアウォール ルールも管理します。中央ポリシーの場合は、階層型ファイアウォール ポリシーを使用できます。中央のネットワーク チームがファイアウォール ルールを完全に管理する必要がある場合は、GitOps アプローチを使用して、すべての VPC ネットワークにそのルールを一元的にデプロイすることを検討してください。この場合、IAM 権限を、ファイアウォール ルールを変更できる管理者のみに制限します。複数のチームがスポークにデプロイする場合は、スポーク VPC ネットワークを共有 VPC ネットワークにすることもできます。
この設計では、複雑性を最小限に抑えるため、VPC ネットワーク ピアリングを使用してハブ VPC ネットワークとスポーク VPC ネットワークを接続することをおすすめします。ただし、スポークの最大数は、次の要因によって制限されます。
- 1 つの VPC ネットワークからの VPC ネットワーク ピアリング接続の上限。
- ピアリング グループの上限（例: 各ピアリング グループの内部 TCP / UDP ロード バランシングに使用される転送ルールの最大数）。
これらの上限に達することが想定される場合は、Cloud VPN を経由してスポーク ネットワークを接続できます。Cloud VPN を使用すると、費用と複雑性が増大し、Cloud VPN トンネルごとに帯域幅の上限が設定されます。
詳しくは以下をご覧ください。
- エンタープライズ基盤ガイドのハブアンドスポークの推移的アーキテクチャ
- Fabric FAST フレームワークの一部としての Terraform デプロイ ステージ: ネットワーク仮想アプライアンスを使用したネットワーキング
- サンプル基盤の一部としての Terraform ハブアンドスポークの推移的モジュール
この設計オプションを実装するには、作成オプション 2: 一元管理されたアプライアンスを使用するハブアンドスポーク トポロジをご覧ください。
オプション 3: アプライアンスを使用しないハブアンドスポーク トポロジ
このネットワーク設計では、ハブアンドスポーク トポロジも使用します。ハブ VPC ネットワークは、ワークロードを含むオンプレミス ネットワークとスポーク VPC ネットワークに接続します。VPC ネットワーク ピアリングは推移的ではないため、スポーク ネットワークは直接通信できません。
この設計は、次の条件に該当する場合に使用します。
- Google Cloud のワークロードまたは環境が内部 IP アドレスを使用して互いにまったく通信しないようにする一方、オンプレミス接続を共有するように設定する必要がある。
- チームが独自のファイアウォールとルーティング ルールを自律的に管理できるようにする必要がある。
次の条件に該当する場合は、この設計の使用を回避してください。
- ワークロード間のレイヤ 7 検査を必要としている。
- ルーティング ルールとファイアウォール ルールを一元管理する必要がある。
- VPC ネットワーク ピアリングは推移的でないため、オンプレミス サービスから別の VPC ネットワーク ピアリングを介してスポークに接続されているマネージド サービスへの通信が必要です。
次の図は、この設計の実装例を示しています。
上の図は、次のことを示しています。
- ハブ VPC ネットワークとワークロードを含む複数のスポーク VPC ネットワークを含む本番環境。
- スポーク VPC ネットワークは、VPC ネットワーク ピアリングを使用してハブ VPC ネットワークに接続されます。
- オンプレミスの場所の接続は、ハブ VPC ネットワーク内の Cloud Interconnect 接続を経由します。
- オンプレミス ネットワークは、個別の VLAN アタッチメントを使用して Cloud Interconnect インスタンスを介して接続されます。
- 開発環境の VPC 構造は本番環境と同じです。
設計上、あるスポーク ネットワークからのトラフィックは別のスポーク ネットワークに到達することはできません。ただし、特定のワークロードが相互に通信する必要がある場合は、VPC ネットワーク ピアリングを使用してスポーク ネットワーク間にダイレクト ピアリングを設定できます。また、Cloud Storage や Pub/Sub などの Google Cloud サービスを使用してアプリケーション間でデータを共有することもできます。
このネットワーク設計は、多くの場合にチームが自律的に行動し、ファイアウォールとルーティング ルールが一元管理されていない環境で使用されます。ただし、この設計の規模は以下の要因によって制限されます。
ピアリング グループの上限（各ピアリング グループの内部パススルー ネットワーク ロードバランサ用の転送ルールの最大数など）
したがって、この設計は通常、Google Cloud 上に多数の異なるワークロードがある大規模な組織では使用されません。
設計のバリエーションとして、VPC ネットワーク ピアリングの代わりに Cloud VPN を使用できます。Cloud VPN ではスポークの数を増やすことができますが、各トンネルの帯域幅上限が追加され、複雑さとコストが増加します。カスタム アドバタイズ ルートを使用する場合、Cloud VPN ですべてのスポーク ネットワークを直接接続せずに、スポーク間の推移性を実現できます。
詳しくは以下をご覧ください。
- ハブアンドスポーク ネットワーク アーキテクチャ
- エンタープライズ基盤ガイドのハブアンドスポーク アーキテクチャ
- Fabric FAST フレームワークの一部としての Terraform デプロイ ステージ: VPC ネットワーク ピアリングを使用したネットワーキング
- Fabric FAST フレームワークの一部としての Terraform デプロイ ステージ: Cloud VPN を使用したネットワーキング
この設計オプションを実装するには、作成オプション 3: アプライアンスを使用しないハブアンドスポーク トポロジをご覧ください。
オプション 4: Private Service Connect を使用してコンシューマ プロデューサー モデルでサービスを公開する
このネットワーク設計では、各チームまたは各ワークロードが独自の VPC ネットワークを使用できます。これは、共有 VPC ネットワークにすることもできます。各 VPC ネットワークは個別に管理され、Private Service Connect を使用して、VPC ネットワークの外部からアクセスする必要があるすべてのサービスを公開します。
この設計は、次の条件に該当する場合に使用します。
- ワークロードは、定義されたエンドポイントを介してオンプレミス環境でのみ、相互に通信している。
- チームが互いに独立して、独自の IP アドレス空間、ファイアウォール、ルーティング ルールを管理できるようにする必要がある。
次の条件に該当する場合は、この設計の使用を回避してください。
- サービスとアプリケーション間の通信に、さまざまなポートまたはチャネルが使用される。または、ポートとチャネルが頻繁に変更される。
- ワークロード間の通信には、TCP または UDP 以外のプロトコルが使用されている。
- ワークロード間のレイヤ 7 検査を必要としている。
次の図は、このパターンの実装例を示しています。
上の図は、次のことを示しています。
- 個別のワークロードは別々のプロジェクトと VPC ネットワークに配置されます。
- ある VPC ネットワーク内のクライアント VM が、Private Service Connect エンドポイントを介して別の VPC ネットワーク内のワークロードに接続できます。
- エンドポイントは、サービスが配置されている VPC ネットワーク内のサービス アタッチメントに接続されています。エンドポイントがグローバル アクセス用に構成されている場合、サービス アタッチメントはエンドポイントとは異なるリージョンに存在できます。
- サービス アタッチメントは、Cloud Load Balancing を介してワークロードに接続します。
- ワークロード VPC のクライアントは、次のようにオンプレミスに配置されているワークロードに到達できます。
- エンドポイントは、トランジット VPC ネットワークのサービス アタッチメントに接続されます。
- サービス アタッチメントは、Cloud Interconnect を使用してオンプレミス ネットワークに接続します。
- 内部アプリケーション ロードバランサはサービス アタッチメントに接続され、ハイブリッド ネットワーク エンドポイント グループを使用して、オンプレミスにあるエンドポイント間でトラフィックの負荷を分散します。
- オンプレミス クライアントは、ワークロード VPC ネットワーク内のサービス アタッチメントに接続するトランジット VPC ネットワークのエンドポイントにも到達できます。
詳しくは以下をご覧ください。
この設計オプションを実装するには、作成オプション 4: Private Service Connect を使用してコンシューマ プロデューサー モデルでサービスを公開するをご覧ください。
ネットワークのデプロイのベスト プラクティス
ユースケースに最適なネットワーク設計を選択したら、次のベスト プラクティスを実装することをおすすめします。
- カスタムモードの VPC ネットワークを使用し、デフォルト ネットワークを削除して、ネットワークの IP アドレスをより適切に制御します。
インターネット アクセスが必要なリソースに Cloud NAT を使用し、Cloud Load Balancing 経由でアクセスできるリソースにパブリック IP アドレスを使用することなく、外部アクセスを制限します。詳細については、プライベート VM のインターネット接続の構築をご覧ください。
Cloud Interconnect を使用する場合は、ミッション クリティカルでないアプリケーションまたは本番環境レベルのアプリケーションに推奨されるトポロジに従ってください。冗長接続を使用してサービスの SLA を満たします。また、Cloud VPN を介して Google Cloud をオンプレミス ネットワークに接続することもできます。
組織のポリシーを使用して外部アクセスを制限するで導入したポリシーを適用して、VPC からのインターネットへの直接アクセスを制限します。
階層型ファイアウォール ポリシーを使用して、組織またはフォルダ全体でファイアウォール ポリシーを一貫して継承します。
オンプレミス ネットワークと Google Cloud の間のハイブリッド DNS については、DNS のベスト プラクティスに従ってください。
詳細については、VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャをご覧ください。
次のステップ
- Google Cloud ランディング ゾーンのネットワーク設計を実装する。
- Google Cloud ランディング ゾーンのセキュリティを決定する（このシリーズの次のドキュメント）。
- VPC ネットワーク設計のベスト プラクティスを確認する。
- Private Service Connect の詳細を確認する。