このドキュメントは、一連の 3 つのドキュメントのうち 3 つ目です。ハイブリッド クラウドとマルチクラウドのネットワーキング アーキテクチャ パターンについて説明します。このパートでは、ハイブリッド アーキテクチャとマルチクラウド アーキテクチャに使用できる一般的で安全なネットワーク アーキテクチャ パターンをいくつか紹介します。これらのネットワーキング パターンが適しているシナリオについて説明し、 Google Cloudでそれらを実装するためのベスト プラクティスを示します。
ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターンのドキュメント セットは、次の部分で構成されています。
- ハイブリッド クラウドとマルチクラウドのアーキテクチャを構築する: Google Cloudでハイブリッド クラウドとマルチクラウドの設定を設計するための戦略の計画について説明します。
- ハイブリッド クラウドとマルチクラウドのアーキテクチャ パターン: ハイブリッド クラウドとマルチクラウド戦略の一部として採用する一般的なアーキテクチャ パターンについて説明します。
- ハイブリッド クラウドとマルチクラウドの安全なネットワーキング アーキテクチャ パターン: ネットワーキングの観点から、ハイブリッド クラウドとマルチクラウドのネットワーキング アーキテクチャ パターンについて説明します（このドキュメント）。
ハイブリッド クラウドとマルチクラウドのアーキテクチャを成功させるには、プライベート コンピューティング環境を Google Cloud に安全かつ信頼できる方法で接続することが不可欠です。ハイブリッドおよびマルチクラウドの設定に選択するハイブリッド ネットワーキング接続とクラウド ネットワーキング アーキテクチャ パターンは、エンタープライズ ワークロードの固有の要件を満たす必要があります。また、適用するアーキテクチャ パターンにも適している必要があります。各設計を調整する必要がある場合もありますが、ブループリントとして使用できる一般的なパターンがあります。
このドキュメントのネットワーキング アーキテクチャ パターンは、 Google Cloudのランディング ゾーンの設計の代替手段と見るべきではありません。代わりに、 Google Cloud ランディング ゾーンの全体的な設計の一環として、選択したアーキテクチャ パターンを設計してデプロイする必要があります。この設計は、次の領域にまたがっています。
- ID
- リソース管理
- セキュリティ
- ネットワーキング
- モニタリング
アプリケーションごとに異なるネットワーキング アーキテクチャ パターンを使用できます。これらのパターンは、ランディング ゾーン アーキテクチャの一部として組み込まれます。マルチクラウド設定では、すべての環境でランディング ゾーンの設計の一貫性を維持する必要があります。
このシリーズには次のページが含まれます。
寄稿者
著者: Marwan Al Shawi | パートナー カスタマー エンジニア
その他の寄稿者:
- Saud Albazei | アプリケーション モダナイゼーション担当カスタマー エンジニア
- Anna Berenberg | エンジニアリング フェロー
- Marco Ferrari | クラウド ソリューション アーキテクト
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Johannes Passing | クラウド ソリューション アーキテクト
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Daniel Strebel | アプリケーション モダナイゼーション担当 EMEA ソリューション リード
- Ammett Williams | デベロッパー リレーションズ エンジニア
アーキテクチャ パターン
このシリーズのドキュメントでは、 Google Cloud と他の環境（オンプレミス、他のクラウド、またはその両方）にあるアプリケーション間の必要な通信モデルに基づいて設計されたネットワーキング アーキテクチャ パターンについて説明します。
これらのパターンは、組織のランディング ゾーンの全体的なアーキテクチャに組み込む必要があります。このアーキテクチャには、さまざまなアプリケーションの特定の通信要件とセキュリティ要件に対応する複数のネットワーキング パターンを設定できます。
このシリーズのドキュメントでは、各アーキテクチャ パターンで使用できるさまざまな設計バリエーションについても説明します。次のネットワーキング パターンは、アプリケーションの通信要件とセキュリティ要件を満たす際に有効です。
ミラーパターン
ミラーリング パターンは、特定の既存の環境の設計を新しい環境に複製することを前提としています。そのため、このパターンは主に、環境ハイブリッド パターンに従うアーキテクチャに適用されます。このパターンでは、ある環境で開発ワークロードとテスト ワークロードを実行し、別の環境でステージング ワークロードと本番環境ワークロードを実行します。
ミラーリング パターンでは、テスト ワークロードと本番環境ワークロードが互いに直接通信しないことが前提とされています。ただし、両方のワークロードのグループを一貫した方法で管理およびデプロイすることは可能です。
このパターンを使用する場合は、次の要件を満たすように 2 つのコンピューティング環境を接続します。
- 継続的インテグレーション / 継続的デプロイ（CI / CD）により、すべてのコンピューティング環境または特定の環境でワークロードをデプロイおよび管理できる。
- モニタリング、構成管理、その他の管理システムは、コンピューティング環境を横断して機能する必要があります。
- ワークロードはコンピューティング環境をまたいで直接通信できない。必要に応じて、通信はきめ細かく制御される。
アーキテクチャ
次のアーキテクチャ図は、CI / CD、モニタリング、構成管理、その他の管理システム、ワークロード通信をサポートするこのパターンのリファレンス アーキテクチャの概要を示しています。
上に示した図のアーキテクチャの説明は次のとおりです。
- ワークロードは、機能環境（開発、テスト、CI/CD、管理ツール）に基づいて、 Google Cloud 側の個別の VPC に分散されます。
- 共有 VPC は、ワークロードの開発とテストに使用されます。CI / CD と管理ツールには、追加の VPC が使用されます。共有 VPC の場合:
- アプリケーションは、環境とサービス プロジェクトごとに異なるチームによって管理されます。
- ホスト プロジェクトは、開発環境とテスト環境間、および VPC の外部とのネットワーク通信とセキュリティ管理を制御します。
- CI / CD VPC は、プライベート コンピューティング環境で本番環境ワークロードを実行しているネットワークに接続されます。
- ファイアウォール ルールは、許可されたトラフィックのみを許可します。
- 侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise を使用して、設計やルーティングを変更せずに、脅威防止のための詳細なパケット検査を実装することもできます。Cloud Next Generation Firewall Enterprise は、パケット インターセプト テクノロジーを使用して、構成された脅威シグネチャを使用してワークロードを透過的に検査する Google 管理のゾーン ファイアウォール エンドポイントを作成します。また、ワークロードを脅威から保護します。
- 内部 IP アドレスを使用してピアリングされた VPC 間の通信を有効にします。
- このパターンのピアリングにより、CI / CD と管理システムは、開発ワークロードとテスト ワークロードをデプロイして管理できます。
- 一般的なベスト プラクティスを検討してください。
この CI / CD 接続を確立するには、ビジネスとアプリケーションの要件を満たす、前述のハイブリッド クラウドとマルチクラウドのネットワーキング接続オプションのいずれかを使用します。本番環境のワークロードをデプロイおよび管理できるように、この接続は、さまざまなコンピューティング環境間でプライベート ネットワークの到達性を提供します。すべての環境で、重複のない RFC 1918 IP アドレス空間を使用する必要があります。
開発環境とテスト環境のインスタンスにインターネット アクセスが必要な場合は、次のオプションを検討してください。
- Cloud NAT は、同じ共有 VPC ホスト プロジェクト ネットワークにデプロイできます。同じ共有 VPC ホスト プロジェクト ネットワークにデプロイすると、これらのインスタンスにインターネットから直接アクセスできなくなります。
- アウトバウンド ウェブ トラフィックには、Secure Web Proxy を使用できます。このプロキシにはいくつかのメリットがあります。
Google Cloud とハイブリッド環境やマルチクラウド環境での構築、テスト、デプロイに役立つ Google Cloud のツールと機能の詳細については、 Google Cloud での DevOps と CI/CD についてのブログをご覧ください。
バリエーション
すべての通信要件を考慮しながら、さまざまな設計要件を満たすために、ミラーリング アーキテクチャ パターンでは次のオプションが提供されます。これらのオプションについては、以下のセクションで説明します。
環境あたりの共有 VPC
環境あたりの共有 VPC の設計オプションを使用すると、環境間でアプリケーションまたはサービスレベルを分離できます。たとえば、特定の組織のセキュリティ要件を満たすために必要な CI / CD や管理ツールを分離できます。これらの要件により、さまざまなサービス間の通信、管理ドメイン、アクセス制御が制限され、これらのサービスは異なるチームによって管理される必要があります。
この設計で分離を実現するには、異なる環境間でネットワーク レベルとプロジェクト レベルの分離を行います。これにより、よりきめ細かい通信と Identity and Access Management（IAM）アクセス制御が可能になります。
管理と運用の観点から、この設計により、環境ごとに、サービス プロジェクトごとに、さまざまなチームによって作成されたアプリケーションとワークロードを柔軟に管理できます。VPC ネットワーキングとそのセキュリティ機能は、次の可能な構造に基づいてネットワーク オペレーション チームによってプロビジョニングおよび管理できます。
- 1 つのチームがすべての環境のすべてのホスト プロジェクトを管理する。
- 各チームがそれぞれの環境でホスト プロジェクトを管理する。
ホスト プロジェクトの管理に関する決定は、各チームのチーム構造、セキュリティ運用、アクセス要件に基づいて行う必要があります。この設計バリエーションを、各環境の共有 VPC ネットワークのランディング ゾーン設計オプションに適用できます。ただし、ハイブリッド ネットワークを介した通信など、異なる環境間で許可される通信を定義するには、ミラーリング パターンの通信要件を考慮する必要があります。
次の図に示すように、メイン環境ごとに共有 VPC ネットワークをプロビジョニングすることもできます。
一元化されたアプリケーション レイヤ ファイアウォール
シナリオによっては、セキュリティ要件により、Cloud Next Generation Firewall の機能を超える高度なファイアウォール メカニズムを使用して、アプリケーション レイヤ（レイヤ 7）と詳細なパケット検査を検討することが義務付けられる場合があります。組織のセキュリティ要件と標準を満たすには、ネットワーク仮想アプライアンス（NVA）にホストされている NGFW アプライアンスを使用できます。複数の Google Cloud セキュリティ パートナーが、このタスクに適したオプションを提供しています。
次の図に示すように、複数のネットワーク インターフェースを使用して、Virtual Private Cloud とプライベート コンピューティング環境の間のネットワーク パスに NVA を配置できます。
この設計は、次の図に示すように、複数の共有 VPC でも使用できます。
この設計の NVA は、境界セキュリティ レイヤとして機能します。また、インライン トラフィック検査を有効にして、厳格なアクセス制御ポリシーを適用するための基盤としても機能します。
VPC ファイアウォール ルールと侵入防止サービス機能を含む堅牢な多層セキュリティ戦略では、East-West と North-South の両方のトラフィック フローに、より詳細なトラフィック検査とセキュリティ制御を含めます。
ハブアンドスポーク トポロジ
別の設計バリエーションとして、開発とさまざまなテストの段階で別々の VPC（共有 VPC を含む）を使用する方法もあります。このバリエーションでは、次の図に示すように、すべてのステージ環境がハブアンドスポーク アーキテクチャで CI / CD と管理 VPC に接続します。各環境で管理ドメインと関数を分離する必要がある場合は、このオプションを使用します。ハブアンドスポーク通信モデルは、次の要件に役立ちます。
- アプリケーションは、モニタリング、構成管理ツール、CI / CD、認証などの一般的なサービスセットにアクセスする必要があります。
- 共通のセキュリティ ポリシー セットを、ハブを介して一元的にインバウンド トラフィックとアウトバウンド トラフィックに適用する必要があります。
ハブアンドスポーク設計オプションの詳細については、一元管理されたアプライアンスを使用したハブアンドスポーク トポロジと一元管理されたアプライアンスを使用しないハブアンドスポーク トポロジをご覧ください。
上の図に示すように、VPC 間の通信とハイブリッド接続はすべてハブ VPC を通過します。このパターンでは、接続要件に合わせてハブ VPC での通信を制御して制限できます。
ハブアンドスポーク ネットワーク アーキテクチャの一部として、 Google Cloudでは、スポークとハブ VPC 間の接続オプションとして次のオプションが提供されています。
- VPC ネットワーク ピアリング
- VPN
- ネットワーク仮想アプライアンス（NVA）の使用
- 複数のネットワーク インターフェースの使用
- Network Connectivity Center（NCC）の使用
設計で検討する必要があるオプションの詳細については、ハブアンドスポーク ネットワーク アーキテクチャをご覧ください。スポークとハブ VPC 間の VPC ピアリングで VPN を選択する際の重要な要因は、トラフィックの推移性が必要な場合です。トラフィックの推移性は、スポークからのトラフィックがハブを介して他のスポークに到達できることを意味します。
マイクロサービス ゼロトラスト分散型アーキテクチャ
ハイブリッド アーキテクチャとマルチクラウド アーキテクチャでは、本番環境を開発環境やテスト環境から分離するなど、技術的およびビジネス上の目標を達成するために、複数のクラスタが必要になる場合があります。そのため、ネットワーク境界セキュリティ制御は重要です。特に、特定のセキュリティ要件に準拠する必要がある場合は重要です。
現在のクラウドファースト分散マイクロサービス アーキテクチャのセキュリティ要件を満たすだけでは不十分です。ゼロトラスト分散型アーキテクチャも検討する必要があります。マイクロサービス ゼロトラスト分散型アーキテクチャは、マイクロサービス レベルのセキュリティ ポリシーの適用、認証、Workload Identity を使用してマイクロサービス アーキテクチャをサポートします。信頼は ID ベースであり、各サービスに適用されます。
サービス メッシュなどの分散プロキシ アーキテクチャを使用すると、サービスは呼び出し元を効果的に検証し、リクエストごとにきめ細かいアクセス制御ポリシーを実装できるため、より安全でスケーラブルなマイクロサービス環境を実現できます。Cloud Service Mesh を使用すると、Google Cloud とオンプレミス デプロイにまたがる共通のメッシュをフレキシブルに利用できるようになります。メッシュは、認可ポリシーを使用してサービス間通信を保護します。
このアーキテクチャに、Kubernetes クラスタ内の軽量な Apigee API ゲートウェイ デプロイである Apigee Adapter for Envoy を組み込むこともできます。Apigee Adapter for Envoy は、クラウド ファースト アプリケーション用に設計されたオープンソースのエッジおよびサービス プロキシです。
このトピックの詳細については、以下の記事をご覧ください。
- ゼロトラスト分散型アーキテクチャ
- GKE Enterprise ハイブリッド環境
- Google に接続する
- オンプレミス GKE Enterprise クラスタをGoogle Cloud ネットワークに接続します。
- マルチクラウドまたはハイブリッド メッシュを設定する
- 環境とクラスタに Cloud Service Mesh をデプロイします。
ミラーリング パターンのベスト プラクティス
- 本番環境のデプロイまたは再構成に必要な CI / CD システムは、高可用性である必要があります。つまり、すべてのアーキテクチャ コンポーネントが、想定されるレベルのシステム可用性を実現するように設計されている必要があります。詳細については、Google Cloud インフラストラクチャの信頼性をご覧ください。
- コードの更新などの繰り返しのプロセスで構成エラーを排除するには、ビルド、テスト、デプロイを標準化するために自動化が不可欠です。
- この設計で一元化された NVA を統合するには、セキュリティ アクセス制御のレベルが異なる複数のセグメントを組み込む必要がある場合があります。
- NVA を含むソリューションを設計する際は、すべての通信をブロックする可能性のある単一障害点を回避するために、NVA の高可用性（HA）を考慮することが重要です。NVA ベンダーが提供する HA と冗長性の設計と実装のガイダンスに従ってください。
- VPC ピアリングまたは VPN を介してオンプレミス IP ルートを開発とテストの VPC にエクスポートしないようにすることで、開発環境とテスト環境からオンプレミス環境へのネットワーク到達性を制限できます。詳細については、VPC ネットワーク ピアリングでのカスタムルートの交換をご覧ください。
- Google API のアクセスを必要とする可能性のあるプライベート IP アドレスを持つワークロードの場合、VPC ネットワーク内の Private Service Connect エンドポイントを使用して Google API を公開できます。詳細については、このシリーズの上り（内向き）ゲート型をご覧ください。
- ハイブリッド クラウドとマルチクラウドのネットワーキング アーキテクチャ パターンに関する一般的なベスト プラクティスを確認します。
メッシュ パターン
メッシュ パターンは、ハイブリッド ネットワーク アーキテクチャの確立に基づいています。このアーキテクチャは複数のコンピューティング環境にまたがっており、こうした環境ではすべてのシステムが相互に通信できます。アプリケーションのセキュリティ要件に応じて、システムが一方向通信に制限されることはありません。このネットワーク パターンは主に、階層型ハイブリッド アーキテクチャ、パーティション分割されたマルチクラウド アーキテクチャ、バースト アーキテクチャに適用されます。また、 Google Cloudに障害復旧（DR）環境をプロビジョニングするために、ビジネス継続性の設計に適用することもできます。いずれの場合も、次の通信要件に沿ってコンピューティング環境を接続する必要があります。
- RFC 1918 のプライベート IP アドレスを使用して、ワークロードが環境の境界を越えて相互に通信できること。
- どちら側からでも通信を開始できること。通信モデルの詳細は、後述の設計オプションで説明する通信モデルなど、アプリケーションとセキュリティ要件によって異なる場合があります。
- パターンが設計されるアプリケーションの要件に基づき、使用するファイアウォール ルールで特定の IP アドレスの送信元と宛先間のトラフィックを許可すること。理想的には、多層セキュリティ アプローチを使用して、コンピューティング環境間とコンピューティング環境内で行われるトラフィック フローをきめ細かく制限します。
アーキテクチャ
次の図は、メッシュ パターンのリファレンス アーキテクチャの概要を示しています。
- すべての環境で、重複のない RFC 1918 IP アドレス空間を使用する必要があります。
- Google Cloud 側では、ワークロードを 1 つまたは複数の共有 VPC または非共有 VPC にデプロイできます。このパターンの他の設計オプションについては、以下の設計バリエーションをご覧ください。選択した VPC 構造は、組織のプロジェクトとリソース階層の設計に沿っている必要があります。
- Google Cloud の VPC ネットワークは、他のコンピューティング環境に拡張できます。オンプレミスの環境でも、別のクラウド内の環境でも構いません。ビジネスとアプリケーションの要件に応じて、ハイブリッド クラウドとマルチクラウドのネットワーキング接続オプションのいずれかを使用してください。
送信元と宛先の許可された IP アドレスに通信を限定します。次のいずれかの機能を使用するか、複数の機能を組み合わせて使用します。
次世代ファイアウォール（NGFW）検査機能を備え、ネットワーク パスに配置されたネットワーク仮想アプライアンス（NVA）。
侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise。ネットワークの設計やルーティングを変更せずに、脅威防止のための詳細なパケット検査を実装します。
バリエーション
メッシュ型アーキテクチャ パターンを他のアプローチと組み合わせると、パターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。次のセクションでは、パターンのオプションについて説明します。
環境ごとに 1 つの VPC
環境ごとに 1 つの VPC のオプションを検討する一般的な理由は次のとおりです。
- クラウド環境では、組織のリソース階層の設計に沿って、VPC ネットワークとリソースをネットワーク レベルで分離する必要があります。管理ドメインの分離が必要な場合は、このオプションと一緒に、環境ごとに個別のプロジェクトを使用することもできます。
- 共通ネットワーク内のネットワーク リソースを一元管理し、異なる環境間でネットワークを分離するには、 Google Cloudにある開発環境、テスト環境、本番環境といった各環境の共有 VPC ネットワークを使用します。
- 単一の VPC またはプロジェクトの VPC 割り当てを超えるスケーリング要件があることがあります。
次の図に示すように、環境ごとに 1 つの VPC を使用する設計では、VPN を使用するか、複数の VLAN アタッチメントを備えた Cloud Interconnect を使用して、各 VPC をオンプレミス環境または他のクラウド環境に直接統合できます。
上の図に示されているパターンは、ランディング ゾーンのハブアンドスポーク ネットワーク トポロジに適用できます。このトポロジでは、1 つ（または複数）のハイブリッド接続をすべてのスポーク VPC と共有できます。この共有は、トランジット VPC を使用してハイブリッド接続と他のスポーク VPC の両方を終端することで行われます。次のセクション「一元化されたアプリケーション レイヤ ファイアウォールを使用する」で説明されているように、次世代ファイアウォール（NGFW）検査機能を備えた NVA をトランジット VPC に追加して、この設計を拡張することもできます。
一元化されたアプリケーション レイヤ ファイアウォールを使用する
技術要件により、Cloud Next Generation Firewall の機能を超える高度なファイアウォール機能によるアプリケーション レイヤ（レイヤ 7）と詳細なパケット検査が必要な場合は、NVA でホストされている NGFW アプライアンスを使用できます。ただし、この NVA は組織のセキュリティ要件を満たしている必要があります。これらのメカニズムを実装するには、次の図に示すように、すべてのクロス環境トラフィックが一元化された NVA ファイアウォールを通過するようにトポロジを拡張します。
一元管理されたアプライアンスを使用するハブアンドスポーク トポロジを使用すると、次の図のパターンをランディング ゾーン設計に適用できます。
上の図に示すように、NVA は境界セキュリティ レイヤとして機能し、インライン トラフィック検査を有効にするための基盤の役割を果たします。また、厳格なアクセス制御ポリシーも適用されます。east-west と north-south の両方のトラフィック フローを検査するために、一元化された NVA の設計には、セキュリティ アクセス制御のレベルが異なる複数のセグメントが含まれる場合があります。
マイクロサービス ゼロトラスト分散型アーキテクチャ
コンテナ化されたアプリケーションを使用する場合、ミラーリング パターンのセクションで説明されているマイクロサービス ゼロトラスト分散型アーキテクチャも、このアーキテクチャ パターンに適用できます。
このパターンがミラーリング パターンと大きく異なる点は、 Google Cloud のワークロードと他の環境のワークロード間の通信モデルをどちら側からでも開始できることです。サービス メッシュ を使用して、アプリケーション要件とセキュリティ要件に基づいてトラフィックをきめ細かく制御する必要があります。
メッシュ パターンのベスト プラクティス
- 他の操作を行う前に、リソース階層の設計と、プロジェクトおよび VPC をサポートするために必要な設計を決定します。これにより、 Google Cloud プロジェクトの構造に沿った最適なネットワーキング アーキテクチャを選択できます。
- プライベート コンピューティング環境とGoogle Cloud内で Kubernetes を使用する場合は、ゼロトラスト分散型アーキテクチャを使用します。
- 一元化された NVA を設計で使用する場合は、セキュリティ アクセス制御とトラフィック検査ポリシーのレベルが異なる複数のセグメントを定義する必要があります。これらの制御とポリシーは、アプリケーションのセキュリティ要件に基づいて決定します。
- NVA を含むソリューションを設計する際は、すべての通信をブロックする可能性のある単一障害点を回避するために、NVA の高可用性（HA）を考慮することが重要です。NVA の供給元である Google Cloud セキュリティ ベンダーが提供する、HA と冗長性の設計と実装に関するガイダンスに従ってください。
- プライバシー、データの整合性、制御された通信モデルを強化するために、エンドツーエンドの mTLS が備わっている Apigee や Apigee ハイブリッド などの API ゲートウェイを使用して、API を介してアプリケーションを公開します。同じ組織リソースで、Apigee による共有 VPC を使用することもできます。
- ソリューションの設計の要件として、 Google Cloudベースのアプリケーションを公共のインターネットに公開する必要がある場合は、インターネットに接続するアプリケーションの配信のためのネットワーキングで紹介している設計推奨事項を検討してください。
- プロジェクト内の Google Cloud サービスを保護してデータ漏洩のリスクを軽減するために、VPC Service Controls を使用して、プロジェクト レベルまたは VPC ネットワーク レベルでサービス境界を指定します。また、承認済みの VPN または Cloud Interconnect 経由でハイブリッド環境にサービス境界を拡張することもできます。サービス境界の利点については、VPC Service Controls の概要をご覧ください。
- ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認します。
Google Cloudでホストされているアプリケーションと他の環境のアプリケーションの間で、より厳密な分離ときめ細かいアクセスを適用する場合は、このシリーズの他のドキュメントで説明しているゲートパターンの使用を検討してください。
ゲートパターン
ゲートパターンは、さまざまな環境間で公開されている特定の API またはエンドポイントに基づいて、選択したアプリケーションとサービスをきめ細かく公開するアーキテクチャに基づいています。このガイドでは、このパターンを 3 つのオプションに分類します。それぞれ、特定の通信モデルによって決まります。
- 下り（外向き）ゲート型
下り（外向き）ゲート型と上り（内向き）ゲート型（双方向のゲート型）
このガイドですでに説明したように、ここで説明するネットワーキング アーキテクチャ パターンは、多様な要件を持つさまざまなアプリケーションに適応できます。さまざまなアプリケーションの特定のニーズに対応するために、メインのランディング ゾーン アーキテクチャに、1 つのパターンまたは複数のパターンの組み合わせを同時に組み込むことができます。選択したアーキテクチャの具体的なデプロイは、各ゲートパターンの特定の通信要件によって決まります。
このシリーズでは、各ゲートパターンとその設計オプションについて説明します。ただし、すべてのゲートパターンに適用できる一般的な設計オプションとして、マイクロサービス アーキテクチャを使用したコンテナ化アプリケーション向けのゼロトラスト分散型アーキテクチャがあります。このオプションでは、Cloud Service Mesh、Apigee、Apigee Adapter for Envoy（Kubernetes クラスタ内の軽量な Apigee ゲートウェイ デプロイ）を活用しています。Apigee Adapter for Envoy は、クラウドファースト アプリケーション用に設計された、よく使われているオープンソースのエッジおよびサービス プロキシです。このアーキテクチャは、許可された安全なサービス間通信と通信の方向をサービスレベルで制御します。トラフィック通信ポリシーは、選択したパターンに基づいてサービスレベルで設計、微調整、適用できます。
ゲートパターンを使用すると、Cloud Next Generation Firewall Enterprise に侵入防止サービス（IPS）を実装して、設計やルーティングを変更することなく、脅威防止のための詳細なパケット検査を実行できます。この検査は、アクセスされる特定のアプリケーション、通信モデル、セキュリティ要件によって異なります。セキュリティ要件で、Cloud Next Generation Firewall の機能を超える高度なファイアウォール メカニズムによるレイヤ 7 と詳細なパケット検査が必要な場合は、ネットワーク仮想アプライアンス（NVA）でホストされている一元化された次世代ファイアウォール（NGFW）を使用できます。複数の Google Cloud セキュリティ パートナーが、セキュリティ要件を満たす NGFW アプライアンスを提供しています。NVA をこれらのゲートパターンと統合するには、ネットワーク設計内に複数のセキュリティ ゾーンを導入し、それぞれに異なるアクセス制御レベルを設定する必要があります。
下り（外向き）ゲート型
下り（外向き）ゲート型ネットワーキング パターンのアーキテクチャは、オンプレミス環境または別のクラウド環境から、 Google Cloudにデプロイされたワークロードに一部の API を公開することをベースにしています。オンプレミス環境や他のクラウド環境からパブリック インターネットに直接公開することなく、これを行うことができます。この制限された公開は、既存のワークロードのファサードとして機能する API ゲートウェイ、プロキシ、ロードバランサを介して容易に実現できます。API ゲートウェイ機能は、境界ネットワークなどの分離された境界ネットワーク セグメントにデプロイできます。
ゲート付き下り（外向き）ネットワーク パターンは、主に（ただしこれらに限定されません）、階層型アプリケーション アーキテクチャ パターンとパーティション分割されたアプリケーション アーキテクチャ パターンに適用されます。内部ネットワーク内にバックエンド ワークロードをデプロイする場合、ゲート付き下り（外向き）ネットワークを使用すると、オンプレミス コンピューティング環境内のセキュリティ レベルを高く維持できます。このパターンでは、次の通信要件を満たすようにコンピューティング環境を接続する必要があります。
- Google Cloud にデプロイするワークロードは、内部 IP アドレスを使用して、アプリケーションを公開する API ゲートウェイまたはロードバランサ（または Private Service Connect エンドポイント）と通信できます。
- プライベート コンピューティング環境内の他のシステムに Google Cloud内から直接アクセスすることはできません。
- プライベート コンピューティング環境から Google Cloud にデプロイされたワークロードへの通信は許可されません。
- 他の環境の非公開 API へのトラフィックは、 Google Cloud 環境内からのみ開始されます。
このガイドでは、プライベート ハイブリッド ネットワークで接続されたハイブリッド環境とマルチクラウド環境について説明します。組織のセキュリティ要件で許可されている場合は、パブリック IP アドレスを持つリモート ターゲット API への API 呼び出しにインターネット経由で直接アクセスできます。ただし、次のセキュリティ メカニズムを考慮する必要があります。
- Transport Layer Security（TLS）を備えた API OAuth 2.0。
- レート制限。
- 脅威保護ポリシー。
- API レイヤのバックエンドに構成された相互 TLS。
- 事前定義された API の送信元と宛先との通信のみを両側から許可するように構成された IP アドレス許可リスト フィルタリング。
API プロキシを保護するには、その他のセキュリティの側面も考慮してください。詳細については、Apigee を使用したアプリケーションと API の保護のベスト プラクティスをご覧ください。
アーキテクチャ
次の図は、前のセクションで説明した通信要件をサポートするリファレンス アーキテクチャを示しています。
上の図では、データは次のように流れます。
- Google Cloud 側では、ワークロードを仮想プライベート クラウド（VPC）にデプロイできます。VPC は単一または複数（共有または非共有）にできます。デプロイは、組織のプロジェクトとリソース階層の設計に沿っている必要があります。
- Google Cloud 環境の VPC ネットワークは、他のコンピューティング環境に拡張されます。環境はオンプレミスまたは別のクラウドに配置できます。内部 IP アドレスを使用して環境間の通信を容易にするには、適切なハイブリッドおよびマルチクラウド ネットワーキング接続を使用します。
特定の VPC IP アドレスから発信され、リモート ゲートウェイまたはロードバランサ宛てのトラフィックを制限するには、IP アドレスの許可リスト フィルタリングを使用します。ステートフル ファイアウォール ルールを使用すると、これらの接続からの戻りトラフィックが許可されます。次の機能の任意の組み合わせを使用して、通信を保護し、許可された送信元と宛先の IP アドレスのみに制限できます。
次世代ファイアウォール（NGFW）検査機能を備え、ネットワーク パスに配置されたネットワーク仮想アプライアンス（NVA）。
侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise。脅威防止のための詳細なパケット検査を実装します。
すべての環境で、重複のない RFC 1918 IP アドレス空間を共有します。
バリエーション
下り（外向き）ゲート型アーキテクチャ パターンによって、他のアプローチと組み合わせて、このパターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。このパターンには次のオプションがあります。
Google Cloud API ゲートウェイとグローバル フロントエンドを使用する
この設計アプローチでは、API の公開と管理はGoogle Cloud内に存在します。上の図に示すように、API プラットフォームとして Apigee を実装することで、これを実現できます。リモート環境に API Gateway またはロードバランサをデプロイするかどうかは、特定のニーズと現在の構成によって異なります。Apigee には、接続をプロビジョニングするための 2 つのオプションがあります。
- VPC ピアリングを使用
- VPC ピアリングを使用しない
Cloud Load Balancing、Cloud CDN（Cloud Interconnect 経由でアクセスした場合）、Cross-Cloud Interconnect などのGoogle Cloud グローバル フロントエンド機能により、オンプレミス環境や他のクラウド環境でホストされているバックエンドを持つアプリケーションにユーザーがアクセスする速度が向上します。
コンテンツ配信速度の最適化は、 Google Cloud ポイント オブ プレゼンス（PoP） Google Cloud からアプリケーションを配信することで実現されます。PoP は、世界中の 180 を超えるインターネット エクスチェンジと 160 を超える相互接続施設に存在します。
Apigee と Cloud CDN を使用して次のことを実現する場合に、POP が高パフォーマンス API の提供にどのように役立つかについては、YouTube で Apigee と Cloud CDN を使用した高パフォーマンス API の提供をご覧ください。
- レイテンシを短縮します。
- API をグローバルにホストします。
- トラフィックのピーク時に可用性を高めます。
上の図に示す設計例は、VPC ピアリングなしの Private Service Connect に基づいています。
この設計のノースバウンド ネットワークは、次の方法で確立されます。
- ロードバランサ（図の LB）でクライアント リクエストが終了し、トラフィックが処理されて Private Service Connect バックエンドにルーティングされます。
- Private Service Connect バックエンドを使用すると、 Google Cloud ロードバランサは、プロデューサー サービス アタッチメントに関連付けられた Private Service Connect 接続を介して、Private Service Connect ネットワーク エンドポイント グループ（NEG）を使用して、公開サービス（Apigee ランタイム インスタンス）にクライアント リクエストを送信できます。
サウスバウンド ネットワーキングは、次の方法で確立されます。
- 顧客 VPC の内部ロードバランサ（図の ILB）に関連付けられたサービス アタッチメントを参照する Private Service Connect エンドポイント。
ILB は、ハイブリッド接続ネットワーク エンドポイント グループ（ハイブリッド接続 NEG）を使用してデプロイされます。
ハイブリッド サービスには、VPN や Cloud Interconnect などのハイブリッド ネットワーク接続を介して、ハイブリッド接続 NEG を介してアクセスします。
詳細については、ハイブリッド接続でリージョン内部プロキシ ネットワーク ロードバランサを設定すると Private Service Connect のデプロイ パターンをご覧ください。
Private Service Connect を使用してリモート サービスを公開する
Private Service Connect オプションを使用して、次のシナリオでリモート サービスを公開します。
- API プラットフォームを使用していない場合、または次の理由で VPC ネットワーク全体を外部環境に直接接続することを避けたい場合。
- セキュリティ上の制限またはコンプライアンス要件がある。
- 合併や買収のシナリオなどで、IP アドレス範囲が重複している。
- 期限が迫っている場合でも、環境間でクライアント、アプリケーション、サービス間の安全な単方向通信を有効にする。
- サービス プロデューサー VPC（トランジット VPC）を介して複数のコンシューマー VPC に接続を提供し、スケーラビリティの高いマルチテナントまたはシングルテナントのサービスモデルを提供して、他の環境で公開されているサービスにアクセスする必要がある場合があります。
API として使用されるアプリケーションに Private Service Connect を使用すると、公開されたアプリケーションに内部 IP アドレスが提供され、リージョン間およびハイブリッド接続を介してプライベート ネットワーク内で安全にアクセスできるようになります。この抽象化により、ハイブリッド接続モデルとマルチクラウド接続モデルを介して、さまざまなクラウド環境とオンプレミス環境のリソースを統合できます。Private Service Connect を使用して、オンプレミス環境または別のクラウド環境にあるアプリケーションを安全に公開し、アプリケーション統合を加速できます。これには、きめ細かいアクセス制御でサービスを公開します。この場合は、次のオプションを使用できます。
- リージョン内部プロキシ ネットワーク ロードバランサまたは内部アプリケーション ロードバランサを参照するサービス アタッチメント。
- ロードバランサは、この設計でトランジット VPC として機能するプロデューサー VPC のハイブリッド ネットワーク エンドポイント グループ（ハイブリッド接続 NEG）を使用します。
上の図では、次の図に示すように、アプリケーションの VPC ネットワーク内のワークロードは、Private Service Connect エンドポイントを介して、オンプレミス環境または他のクラウド環境で実行されているハイブリッド サービスにアクセスできます。この一方向通信の設計オプションは、トランジット VPC へのピアリングの代替オプションを提供します。
上の図の設計では、複数のフロントエンド、バックエンド、エンドポイントを同じサービス アタッチメントに接続できます。これにより、複数の VPC ネットワークまたは複数のコンシューマーが同じサービスにアクセスできます。次の図に示すように、アプリケーションを複数の VPC でアクセスできるようにすることができます。このアクセシビリティは、IP アドレス範囲が重複していても、複数のコンシューマー VPC でサービスが使用されるマルチテナント サービスのシナリオで役立ちます。
IP アドレスの重複は、異なる環境に存在するアプリケーションを統合する際に最もよく発生する問題の 1 つです。次の図の Private Service Connect 接続は、IP アドレスの重複問題を回避するのに役立ちます。この処理では、IP アドレス変換を実行するために、Cloud NAT や NVA などの追加のネットワーキング コンポーネントのプロビジョニングや管理は必要ありません。構成例については、Private Service Connect を使用してハイブリッド サービスを公開するをご覧ください。
この設計には次のような利点があります。
- 共有スケーリングの依存関係と、大規模な複雑な管理性を回避します。
- きめ細かい接続制御を提供することで、セキュリティを強化します。
- サービスとリモート外部環境のプロデューサーとコンシューマー間の IP アドレスの調整を削減します。
上の図の設計アプローチは、後の段階で拡張して、Private Service Connect オプションなど、前述のネットワーキング設計オプションを使用して Apigee を API プラットフォームとして統合できます。
Private Service Connect のグローバル アクセスを使用すると、他のリージョンから Private Service Connect エンドポイントにアクセスできるようになります。
Private Service Connect エンドポイントに接続するクライアントは、エンドポイントと同じリージョンに配置することも、別のリージョンに配置することもできます。このアプローチは、複数のリージョンにホストされているサービスに高可用性を提供したり、他のリージョンから単一リージョンで使用可能なサービスにアクセスしたりするために使用できます。Private Service Connect エンドポイントに他のリージョンでホストされているリソースからアクセスすると、グローバル アクセスが有効なエンドポイント宛てのトラフィックにリージョン間のアウトバウンド料金が適用されます。
ベスト プラクティス
- Apigee と Apigee ハイブリッドを API プラットフォーム ソリューションとして検討すると、いくつかのメリットがあります。バックエンド サービス API のプロキシレイヤと抽象化またはファサードを提供し、セキュリティ、レート制限、割り当て、分析の機能も備えています。
- 要件とアーキテクチャに該当する場合は、Kubernetes を使用した Apigee Hybrid のデプロイ アーキテクチャで Apigee Adapter for Envoy を使用します。
- Google Cloud の VPC とプロジェクトの設計は、リソース階層と安全な通信モデルの要件に基づいて行う必要があります。
- API ゲートウェイを使用する API を使用する場合は、IP アドレスの許可リストも使用する必要があります。許可リストを使用すると、異なる環境でホストされている可能性のある API コンシューマーと API ゲートウェイの特定の IP アドレスの送信元と宛先への通信が制限されます。
- VPC ファイアウォール ルールまたはファイアウォール ポリシーを使用して、Private Service Connect エンドポイントを介して Private Service Connect リソースへのアクセスを制御します。
- アプリケーションがアプリケーション ロードバランサを介して外部に公開されている場合は、DDoS 攻撃やアプリケーション レイヤのセキュリティの脅威から保護するための追加のセキュリティ レイヤとして Google Cloud Armor の使用を検討してください。
インスタンスにインターネット アクセスが必要な場合は、アプリケーション（コンシューマー）VPC で Cloud NAT を使用して、ワークロードがインターネットにアクセスできるようにします。これにより、API ゲートウェイまたはロードバランサの背後にデプロイされているシステムで、外部パブリック IP アドレスを持つ VM インスタンスを割り当てることを回避できます。
- アウトバウンド ウェブ トラフィックには、 Google Cloud Secure Web Proxy を使用できます。このプロキシにはいくつかのメリットがあります。
ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認します。
上り（内向き）ゲート型
上り（内向き）ゲート型パターンのアーキテクチャは、 Google Cloud で実行されているワークロードの一部の API を、公共のインターネットに公開することなく、プライベート コンピューティング環境に公開することをベースにしています。このパターンは、下り（外向き）ゲート型パターンに対応するものであり、エッジ ハイブリッド、階層型ハイブリッド、パーティション分割されたマルチクラウドのシナリオに適しています。
下り（外向き）ゲート型パターンと同様に、この制限された公開は、既存のワークロードまたはサービスのファサードとして機能する API ゲートウェイまたはロードバランサを介して容易に実現できます。これにより、次のように、プライベート コンピューティング環境、オンプレミス環境、または他のクラウド環境で利用できます。
- プライベート コンピューティング環境または他のクラウド環境にデプロイするワークロードは、内部 IP アドレスを使用して API ゲートウェイまたはロードバランサと通信できます。Google Cloud にデプロイされた他のシステムにはアクセスできません。
- Google Cloud からプライベート コンピューティング環境または他のクラウド環境への通信は許可されません。トラフィックは、プライベート環境または他のクラウド環境から Google Cloudの API に対してのみ開始されます。
アーキテクチャ
次の図は、上り（内向き）ゲート型パターンの要件を満たすリファレンス アーキテクチャを示しています。
上に示した図のアーキテクチャの説明は次のとおりです。
- Google Cloud 側では、ワークロードをアプリケーション VPC（または複数の VPC）にデプロイします。
- Google Cloud 環境ネットワークは、ハイブリッド クラウドまたはマルチクラウドのネットワーク接続を使用して他のコンピューティング環境（オンプレミスまたは別のクラウド）に拡張し、環境間の通信を容易にします。
- 必要に応じて、トランジット VPC を使用して次のことができます。
- 境界セキュリティ レイヤを追加して、アプリケーション VPC の外部にある特定の API へのアクセスを可能にします。
- API の IP アドレスにトラフィックを転送します。VPC ファイアウォール ルールを作成して、一部のソースがエンドポイント経由で特定の API にアクセスできないようにすることが可能です。
- ネットワーク仮想アプライアンス（NVA）を統合して、トランジット VPC でレイヤ 7 トラフィックを検査します。
- API ゲートウェイまたはロードバランサ（プロキシまたはアプリケーション ロードバランサ）を介して API にアクセスし、プロキシレイヤとサービス API の抽象化レイヤまたはファサードを提供します。複数の API ゲートウェイ インスタンスにトラフィックを分散する必要がある場合は、内部パススルー ネットワーク ロードバランサを使用します。
- Private Service Connect を介してロードバランサを使用してアプリケーションまたはサービスを公開し、Private Service Connect エンドポイントを介して公開されたサービスへの限定的で詳細なアクセス権を付与します。
- すべての環境で、重複のない RFC 1918 IP アドレス空間を使用する必要があります。
次の図は、Apigee を API プラットフォームとして使用したこのパターンの設計を示しています。
上の図では、Apigee を API プラットフォームとして使用することで、上り（内向き）ゲート型パターンを有効にする次の機能が提供されます。
- ゲートウェイまたはプロキシの機能
- セキュリティ機能
- レート制限
- アナリティクス
設計では、次のようにします。
- 上り（他の環境からのトラフィック）のネットワーキング接続は、Apigee VPC に関連付けられたアプリケーション VPC の Private Service Connect エンドポイントを経由します。
- アプリケーション VPC では、内部ロードバランサを使用して、Apigee VPC に表示される Private Service Connect エンドポイントを介してアプリケーション API を公開します。詳細については、VPC ピアリングが無効になっているアーキテクチャをご覧ください。
アプリケーション VPC でファイアウォール ルールとトラフィック フィルタリングを構成します。これにより、詳細なアクセス制御が可能になります。また、Private Service Connect エンドポイントと API ゲートウェイを経由せずにシステムがアプリケーションに直接アクセスするのを防止することもできます。
さらに、アプリケーション VPC 内のバックエンド ワークロードの内部 IP アドレス サブネットの広告をオンプレミス ネットワークに制限して、Private Service Connect エンドポイントと API ゲートウェイを通過せずに直接アクセスできる状態を回避できます。
特定のセキュリティ要件では、アプリケーション VPC の外部で境界セキュリティ検査（ハイブリッド接続トラフィックなど）が必要になる場合があります。このような場合は、トランジット VPC を組み込んで、追加のセキュリティ レイヤを実装できます。複数のネットワーク インターフェースを備えた次世代ファイアウォール（NGFW）NVA、侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise などのこれらのレイヤは、次の図に示すように、アプリケーション VPC の外部で詳細なパケット検査を実施します。
上の図に示すように、
- ノースバウンド ネットワーク接続（他の環境からのトラフィック用）は、別のトランジット VPC を経由して、Apigee VPC に関連付けられているトランジット VPC 内の Private Service Connect エンドポイントに送信されます。
- アプリケーション VPC では、内部ロードバランサ（図の ILB）を使用して、Apigee VPC の Private Service Connect エンドポイントを介してアプリケーションを公開します。
次の図に示すように、同じ VPC ネットワーク内に複数のエンドポイントをプロビジョニングできます。さまざまなユースケースに対応するために、Cloud Router と VPC ファイアウォール ルールを使用して、さまざまなネットワーク パスを制御できます。たとえば、複数のハイブリッド ネットワーク接続を使用してオンプレミス ネットワークを Google Cloud に接続する場合は、オンプレミスから特定の Google API または公開サービスに送信するトラフィックの一部を 1 つの接続経由で送信し、残りのトラフィックを別の接続経由で送信できます。また、Private Service Connect のグローバル アクセスを使用して、フェイルオーバー オプションを提供することもできます。
バリエーション
上り（内向き）ゲート型アーキテクチャ パターンによって、他のアプローチと組み合わせて、パターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。このパターンには次のオプションがあります。
他の環境から Google API にアクセスする
公共のインターネット経由でトラフィックを送信せずに、Cloud Storage や BigQuery などの Google サービスにアクセスする必要があるシナリオでは、Private Service Connect がソリューションを実現します。次の図に示すように、Private Service Connect エンドポイントの IP アドレスを使用して、ハイブリッド ネットワーク接続を介してオンプレミス環境または他のクラウド環境からサポートされている Google API とサービス（Google マップ、Google 広告、Google Cloudなど）への到達可能性を有効にします。Private Service Connect エンドポイントを介した Google API へのアクセスについて詳しくは、エンドポイントを介した Google API へのアクセスについてをご覧ください。
上の図では、オンプレミス ネットワークは、Cloud VPN トンネルまたは Cloud Interconnect VLAN アタッチメントを使用して、トランジット（コンシューマー）VPC ネットワークに接続されている必要があります。
Google API には、エンドポイントまたはバックエンドを使用してアクセスできます。エンドポイントで Google API のバンドルをターゲットにできます。バックエンドで、特定のリージョン Google API をターゲットにできます。
Private Service Connect を使用してアプリケーション バックエンドを他の環境に公開する
階層型ハイブリッド パターンで示されているように、特定のシナリオでは、プライベート コンピューティング環境でフロントエンドを維持しながら、 Google Cloud にバックエンドをデプロイすることが必要な場合があります。あまり一般的ではありませんが、このアプローチは、従来のコンポーネントに依存する可能性のある大規模なモノリシック フロントエンドを扱う場合に適用できます。または、より一般的には、オンプレミスや他のクラウドなど、複数の環境にわたって分散アプリケーションを管理する場合は、ハイブリッド ネットワーク経由で Google Cloud でホストされているバックエンドへの接続が必要になります。
このようなアーキテクチャでは、プライベート オンプレミス環境または他のクラウド環境でローカル API ゲートウェイまたはロードバランサを使用して、アプリケーション フロントエンドを公共のインターネットに直接公開できます。 Google Cloud で Private Service Connect を使用すると、Private Service Connect エンドポイントを介して公開されるバックエンドへのプライベート接続が容易になります。その際に理想的には、次の図に示すように、事前定義された API を使用します。
上の図の設計では、 Google Cloud の管理プレーンと他の環境でホストされているランタイム プレーンで構成される Apigee ハイブリッド デプロイメントを使用しています。ランタイム プレーンは、オンプレミス環境または他のクラウド環境でサポートされている Kubernetes プラットフォームのいずれかにデプロイされた API ゲートウェイにインストールして管理できます。 Google Cloud と他の環境にわたる分散ワークロードの要件に応じて、Apigee Hybrid で Google Cloud の Apigee を使用できます。詳細については、分散 API ゲートウェイをご覧ください。
ハブアンドスポーク アーキテクチャを使用して、アプリケーション バックエンドを他の環境に公開する
特定のシナリオでは、 Google Cloud でホストされているアプリケーション バックエンドから異なる VPC ネットワークに API を公開することが必要になる場合があります。次の図に示すように、ハブ VPC はさまざまな VPC（スポーク）の相互接続の一元的なポイントとして機能し、プライベート ハイブリッド接続を介した安全な通信を可能にします。必要に応じて、Apigee Hybrid などの他の環境のローカル API ゲートウェイ機能を使用して、アプリケーション フロントエンドがホストされている場所でクライアント リクエストをローカルで終了できます。
上の図に示すように、
- NGFW レイヤ 7 検査機能を追加するには、NGFW 機能を備えた NVA を必要に応じて設計に統合します。組織の特定のセキュリティ要件とセキュリティ ポリシー標準を遵守するには、これらの機能が必要になる場合があります。
この設計では、スポーク VPC に VPC 間の直接通信は必要ないと想定しています。
- スポーク間の通信が必要な場合は、NVA を使用してそのような通信を促進できます。
- 異なる VPC に異なるバックエンドがある場合は、Private Service Connect を使用してこれらのバックエンドを Apigee VPC に公開できます。
- スポーク VPC とハブ VPC 間のノースバウンド接続とサウスバウンド接続に VPC ピアリングを使用する場合は、VPC ピアリングを介した VPC ネットワーキングの推移性制限を考慮する必要があります。この制限を回避するには、次のいずれかのオプションを使用します。
トラフィック検査（他の環境からのトラフィックを含む）に NVA が必要な場合は、オンプレミス環境または他のクラウド環境へのハイブリッド接続をハイブリッド トランジット VPC で終端する必要があります。
設計に NVA が含まれていない場合は、ハブ VPC でハイブリッド接続を終端できます。
Google Cloud Armor DDoS 保護や WAF の追加など、特定のロード バランシング機能やセキュリティ機能が必要な場合は、外部クライアント リクエストをバックエンドに転送する前に、外部 VPC を介して境界に外部アプリケーション ロードバランサをデプロイできます。
ベスト プラクティス
- インターネットからのクライアント リクエストを、プライベート オンプレミスまたは他のクラウド環境でホストされているフロントエンドによってローカルで受信する必要がある場合は、API ゲートウェイ ソリューションとして Apigee Hybrid の使用を検討してください。このアプローチでは、API プラットフォーム（Apigee）の一貫性を維持しながら、ソリューションを完全に Google Cloudでホストされる環境にシームレスに移行することもできます。
- 要件とアーキテクチャに該当する場合は、Kubernetes を使用した Apigee Hybrid のデプロイ アーキテクチャで Apigee Adapter for Envoy を使用します。
- Google Cloud の VPC とプロジェクトの設計は、このガイドで説明されているリソース階層と安全な通信モデルの要件に従っている必要があります。
- この設計にトランジット VPC を組み込むと、ワークロード VPC の外部に追加の境界セキュリティ対策とハイブリッド接続を柔軟にプロビジョニングできます。
- Private Service Connect を使用すると、ハイブリッド接続ネットワークを介してエンドポイントの内部 IP アドレスを使用して、オンプレミス環境または他のクラウド環境から Google API とサービスにアクセスできます。詳細については、オンプレミス ホストからエンドポイントにアクセスするをご覧ください。
- プロジェクト内の Google Cloud サービスを保護し、データの漏洩のリスクを軽減するために、VPC Service Controls を使用して、プロジェクト レベルまたは VPC ネットワーク レベルでサービス境界を指定します。
- 必要に応じて、VPN または Cloud Interconnect を介してハイブリッド環境にサービス境界を拡張できます。サービス境界の利点については、VPC Service Controls の概要をご覧ください。
- VPC ファイアウォール ルールまたはファイアウォール ポリシーを使用して、Private Service Connect エンドポイントを介して Private Service Connect リソースへのネットワーク レベルのアクセスを制御します。たとえば、アプリケーション（コンシューマー）VPC のアウトバウンド ファイアウォール ルールでは、VM インスタンスからエンドポイントの IP アドレスまたはサブネットへのアクセスを制限できます。一般的な VPC ファイアウォール ルールの詳細については、VPC ファイアウォール ルールをご覧ください。
- NVA を含むソリューションを設計する際は、すべての通信をブロックする可能性のある単一障害点を回避するために、NVA の高可用性（HA）を考慮することが重要です。NVA ベンダーが提供する HA と冗長性の設計と実装のガイダンスに従ってください。
- 境界セキュリティを強化し、それぞれの環境にデプロイされた API ゲートウェイを保護するために、必要に応じて、他のコンピューティング環境（ハイブリッド クラウドまたは他のクラウド）にロード バランシングとウェブ アプリケーション ファイアウォール メカニズムを実装できます。これらのオプションは、インターネットに直接接続されている境界ネットワークに実装します。
- インスタンスにインターネット アクセスが必要な場合は、アプリケーション VPC で Cloud NAT を使用して、ワークロードがインターネットにアクセスできるようにします。これにより、API ゲートウェイまたはロードバランサの背後にデプロイされているシステムで、外部パブリック IP アドレスを持つ VM インスタンスを割り当てることを回避できます。
- アウトバウンド ウェブ トラフィックには、Secure Web Proxy を使用します。このプロキシにはいくつかのメリットがあります。
- ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認します。
下り（外向き）ゲート型と上り（内向き）ゲート型
下り（外向き）ゲート型と上り（内向き）ゲート型パターンは、ワークロード間で選択された API を双方向で使用する必要があるシナリオで、下り（外向き）ゲート型と上り（内向き）ゲート型を組み合わせて使用します。ワークロードは、 Google Cloud、プライベート オンプレミス環境、または他のクラウド環境で実行できます。このパターンでは、API ゲートウェイ、Private Service Connect エンドポイント、ロードバランサを使用して特定の API を公開し、必要に応じて認証、認可、API 呼び出し監査を提供できます。
このパターンとメッシュ パターンの主な違いは、双方向 API の使用または特定の IP アドレスの送信元と宛先との通信のみを必要とするシナリオ（Private Service Connect エンドポイントを介して公開されたアプリケーションなど）に適用される点です。通信は公開された API または特定の IP アドレスに制限されるため、環境間のネットワークを設計で調整する必要はありません。一般的な適用シナリオとしては次のものが挙げられますが、これらに限定されません。
- 合併と買収。
- パートナーとのアプリケーション統合。
- 組織のアプリケーションとサービスを、独自のアプリケーションを管理し、異なる環境でホストする異なる組織部門と統合します。
通信は次のように機能します。
- Google Cloud にデプロイするワークロードは、内部 IP アドレスを使用して API ゲートウェイ（または特定の宛先 IP アドレス）と通信できます。プライベート コンピューティング環境にデプロイされた他のシステムにはアクセスできません。
- 逆に、他のコンピューティング環境にデプロイするワークロードは、内部 IP アドレスを使用して Google Cloud側の API ゲートウェイ（または特定の公開エンドポイント IP アドレス）と通信できます。 Google Cloud にデプロイされた他のシステムにはアクセスできません。
アーキテクチャ
次の図は、下り（外向き）ゲート型と上り（内向き）ゲート型のパターンのリファレンス アーキテクチャを示しています。
上の図の設計アプローチには、次の要素があります。
- Google Cloud 側では、ワークロードをインターネットに直接公開せずに、VPC（または共有 VPC）にデプロイします。
- Google Cloud 環境ネットワークは、他のコンピューティング環境に拡張されます。オンプレミス環境でも、別のクラウド環境でも構いません。環境を拡張するには、適切なハイブリッドおよびマルチクラウド接続通信パターンを使用して、環境間の通信を容易にし、内部 IP アドレスを使用できるようにします。
- 必要に応じて、特定のターゲット IP アドレスへのアクセスを有効にすることで、トランジット VPC を使用してアプリケーション VPC の外部に境界セキュリティ レイヤを追加できます。
- トランジット VPC で Cloud Next Generation Firewall または次世代ファイアウォール（NGFW）を備えたネットワーク仮想アプライアンス（NVA）を使用して、トラフィックを検査し、アプリケーション VPC に到達する前に特定のソースから特定の API へのアクセスを許可または禁止できます。
- API ゲートウェイまたはロードバランサを介して API にアクセスし、プロキシレイヤとサービス API の抽象化またはファサードを提供します。
- API として使用されるアプリケーションの場合、Private Service Connect を使用して、公開されたアプリケーションの内部 IP アドレスを指定することもできます。
- すべての環境で、重複のない RFC 1918 IP アドレス空間を使用します。
このパターンの一般的なアプリケーションでは、アプリケーション バックエンド（またはアプリケーション バックエンドのサブセット）を Google Cloud にデプロイし、他のバックエンド コンポーネントとフロントエンド コンポーネントをオンプレミス環境または他のクラウドでホストします（階層型ハイブリッド パターンまたはパーティション分割されたマルチクラウド パターン）。アプリケーションが進化してクラウドに移行すると、特定のクラウド サービスに対する依存関係や設定が頻繁に発生します。
これらの依存関係と設定により、アプリケーションとバックエンドが異なるクラウド プロバイダに分散されることがあります。また、一部のアプリケーションは、オンプレミス環境と複数のクラウド環境に分散されたリソースとサービスを組み合わせて構築されている場合があります。
分散アプリケーションの場合、外部 Cloud Load Balancing ハイブリッドおよびマルチクラウド接続の機能を使用して、ユーザー リクエストを終了し、他の環境のフロントエンドまたはバックエンドに転送できます。このルーティングは、次の図に示すように、ハイブリッド ネットワーク接続を介して行われます。この統合により、アプリケーション コンポーネントをさまざまな環境に段階的に配布できます。 Google Cloud でホストされているバックエンド サービスへのフロントエンドからのリクエストは、内部ロードバランサ（図の ILB）によって確立されたハイブリッド ネットワーク接続を介して安全に通信します。
上の図の Google Cloud 設計を使用すると、次のことが可能になります。
- このパターンの通信モデルに沿って、両側で定義された API を使用して、 Google Cloud、オンプレミス、他のクラウド環境間の双方向通信を容易にします。
- 分散アプリケーション コンポーネント（フロントエンドまたはバックエンド）を使用してインターネットに接続されたアプリケーションのグローバル フロントエンドを提供し、次の目標を達成するには、ポイント オブ プレゼンス（PoP）に分散された Google Cloud の高度なロード バランシング機能とセキュリティ機能を使用します。
- サーバーレス マネージド サービスを使用して、設備投資を削減し、運用を簡素化します。
- 速度とレイテンシを考慮して、アプリケーション バックエンドへの接続をグローバルに最適化します。
- Google Cloud Cross-Cloud Network を使用すると、最適なプライベート接続を介してアプリケーション コンポーネント間のマルチクラウド通信が可能になります。
- 需要の高い静的コンテンツをキャッシュに保存し、Cloud CDN へのアクセスを提供することで、グローバル Cloud Load Balancing を使用するアプリケーションのアプリケーション パフォーマンスを向上させます。
- グローバルに分散されたウェブ アプリケーション ファイアウォール（WAF）と DDoS 軽減サービスを提供する Google Cloud Armor の機能を使用して、インターネットに接続するアプリケーションのグローバル フロントエンドを保護します。
- 必要に応じて、Private Service Connect を設計に組み込むことができます。これにより、公共のインターネットを経由せずに、他の環境から Google Cloud サービス API または公開サービスへのプライベートできめ細かいアクセスが可能になります。
バリエーション
下り（外向き）ゲート型と上り（内向き）ゲート型アーキテクチャ パターンによって、他のアプローチと組み合わせて、このパターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。このパターンには次のオプションがあります。
- 分散 API ゲートウェイ
- Private Service Connect を使用した双方向 API 通信
- Private Service Connect エンドポイントとインターフェースを使用した双方向通信
分散 API ゲートウェイ
パーティション分割されたマルチクラウド パターンに基づくシナリオなどでは、アプリケーション（またはアプリケーション コンポーネント）をプライベート オンプレミス環境を含むさまざまなクラウド環境で構築できます。一般的な要件は、クライアント リクエストをアプリケーション フロントエンドからアプリケーション（またはフロントエンド コンポーネント）がホストされている環境に直接ルーティングすることです。この種の通信には、ローカル ロードバランサまたは API ゲートウェイが必要です。これらのアプリケーションとそのコンポーネントでは、統合のために特定の API プラットフォーム機能が必要になることもあります。
次の図は、Apigee と Apigee ハイブリッドが、各環境のローカライズされた API ゲートウェイを使用して、このような要件に対応するように設計されていることを示しています。API プラットフォームの管理は Google Cloudで一元化されています。この設計により、事前承認された IP アドレス（ターゲット API と宛先 API、または Private Service Connect エンドポイントの IP アドレス）のみが Google Cloud と他の環境間で通信できる厳格なアクセス制御対策を適用できます。
次のリストは、Apigee API ゲートウェイを使用する上記の図の 2 つの異なる通信パスを示しています。
- クライアント リクエストは、アプリケーション（またはフロントエンド コンポーネント）をホストする環境のアプリケーション フロントエンドに直接届きます。
- 各環境内の API ゲートウェイとプロキシは、複数の環境にわたって異なる方向にクライアントとアプリケーションの API リクエストを処理します。
- Google Cloud（Apigee）の API ゲートウェイ機能は、 Google Cloudでホストされているアプリケーション（フロントエンドまたはバックエンド）コンポーネントを公開します。
- 別の環境（ハイブリッド）の API ゲートウェイ機能は、その環境でホストされているアプリケーション フロントエンド（またはバックエンド）コンポーネントを公開します。
必要に応じて、トランジット VPC の使用を検討してください。トランジット VPC を使用すると、懸念事項を分離し、セキュリティ検査とハイブリッド接続を別の VPC ネットワークで実行できます。IP アドレスの到達可能性の観点から、トランジット VPC（ハイブリッド接続が接続されている）は、エンドツーエンドの到達可能性を維持するために次の要件を満たします。
- ターゲット API の IP アドレスは、クライアント/リクエスタがホストされている他の環境にアドバタイズする必要があります。
- ターゲット API と通信する必要があるホストの IP アドレスは、ターゲット API が存在する環境（API リクエスト元（クライアント）の IP アドレスなど）にアドバタイズする必要があります。例外は、ロードバランサ、プロキシ、Private Service Connect エンドポイント、NAT インスタンスを介して通信が行われる場合です。
リモート環境に接続を拡張するために、この設計ではカスタムルート交換機能を使用してダイレクト VPC ピアリングを使用します。この設計により、 Google Cloud アプリケーション VPC 内でホストされているワークロードから発信された特定の API リクエストを、トランジット VPC 経由でルーティングできます。また、トランジット VPC のハイブリッド ネットワーク エンドポイント グループ バックエンドを持つロードバランサに関連付けられているアプリケーション VPC で Private Service Connect エンドポイントを使用することもできます。この設定については、次のセクション（Private Service Connect を使用した双方向 API 通信）で説明します。
Private Service Connect を使用した双方向 API 通信
企業によっては、API ゲートウェイ（Apigee など）をすぐに使用する必要がない場合や、後で追加したい場合があります。ただし、異なる環境にある特定のアプリケーション間の通信と統合を有効にするビジネス要件がある場合があります。たとえば、会社が別の会社を買収した場合、特定のアプリケーションをその会社に公開する必要があるかもしれません。アプリケーションを会社に公開する必要がある場合があります。両社はそれぞれ異なる環境（Google Cloud、オンプレミス、他のクラウド）でホストされている独自のワークロードを持ち、IP アドレスの重複を回避する必要があります。このような場合は、Private Service Connect を使用して効果的な通信を促進できます。
API として使用されるアプリケーションの場合、Private Service Connect を使用して、公開されたアプリケーションにプライベート アドレスを提供することもできます。これにより、リージョン間のプライベート ネットワーク内およびハイブリッド接続を介して安全にアクセスできます。この抽象化により、ハイブリッド接続モデルとマルチクラウド接続モデルを介して、さまざまなクラウド環境とオンプレミス環境のリソースを統合できます。また、マルチクラウド環境とオンプレミス環境にまたがるアプリケーションのアセンブリも可能にします。これにより、API ゲートウェイが使用されていない、または使用が予定されていない安全なアプリケーションの統合など、さまざまな通信要件を満たすことができます。
次の図に示すように、Private Service Connect と Cloud Load Balancing を使用すると、2 つの異なる通信パスを実現できます。各パスは、別の接続目的で異なる方向から開始されます（理想的には API 呼び出し経由）。
- このガイドで説明する Private Service Connect の設計上の考慮事項と推奨事項は、この設計にもすべて適用されます。
- レイヤ 7 インスペクションを追加する必要がある場合は、この設計（トランジット VPC）に NVA を統合できます。
- この設計は、API ゲートウェイの有無にかかわらず使用できます。
上の図に示されている 2 つの接続パスは独立した接続を表しており、単一の接続またはフローの双方向通信を示しているわけではありません。
Private Service Connect エンドポイントとインターフェースを使用した双方向通信
ゲート付き上り（内向き）パターンで説明したように、クライアントとサービスの通信を有効にする方法の 1 つは、Private Service Connect エンドポイントを使用して、プロデューサー VPC のサービスをコンシューマー VPC に公開することです。この接続は、ハイブリッド接続を介してオンプレミス環境や別のクラウド プロバイダ環境に拡張できます。ただし、シナリオによっては、ホスト型サービスでプライベート通信が必要になることもあります。
特定のサービスにアクセスする場合（コンシューマー VPC 内または外部でホストできるデータソースからデータを取得するなど）、このプライベート通信は、アプリケーション（プロデューサー）VPC とオンプレミス環境などのリモート環境の間で行うことができます。
このようなシナリオでは、Private Service Connect インターフェースにより、サービス プロデューサーの VM インスタンスがコンシューマーのネットワークにアクセスできます。これは、プロデューサーとコンシューマーのロールが分離されている状態を維持しながら、ネットワーク インターフェースを共有することで実現されます。このネットワーク インターフェースをコンシューマー VPC に配置することで、アプリケーション VM は、コンシューマー リソースがプロデューサー VPC 内にローカルに存在しているかのように、コンシューマー リソースにアクセスできます。
Private Service Connect インターフェースは、コンシューマー（トランジット）VPC に接続されたネットワーク インターフェースです。Private Service Connect インターフェースが接続されているコンシューマー（トランジット）VPC から到達可能な外部宛先に到達できます。したがって、この接続は、次の図に示すように、オンプレミス環境などのハイブリッド接続を介して外部環境に拡張できます。
コンシューマー VPC が外部組織またはエンティティ（サードパーティ組織など）の場合、通常はコンシューマー VPC の Private Service Connect インターフェースへの通信を保護することはできません。このようなシナリオでは、Private Service Connect インターフェース VM のゲスト OS でセキュリティ ポリシーを定義できます。詳細については、Private Service Connect インターフェースのセキュリティを構成するをご覧ください。また、組織のセキュリティ コンプライアンスや標準に準拠していない場合は、別の方法を検討することもできます。
ベスト プラクティス
インターネットからのクライアント リクエストを、プライベート オンプレミスまたは他のクラウド環境でホストされているフロントエンドによってローカルで受信する必要がある場合は、API ゲートウェイ ソリューションとして Hybrid の使用を検討してください。
- このアプローチでは、API プラットフォーム（Apigee）の一貫性を維持しながら、ソリューションを完全に Google Cloudホストされる環境に移行することもできます。
環境が長期的なハイブリッドまたはマルチクラウドのセットアップにある場合に、他の環境へのアウトバウンド データ転送量が多い場合のレイテンシを最小限に抑え、コストを最適化するには、次の点を考慮してください。
- Cloud Interconnect または Cross-Cloud Interconnect を使用します。
- 適切な環境のターゲット フロントエンドでユーザー接続を終了するには、ハイブリッドを使用します。
要件とアーキテクチャに該当する場合は、Kubernetes を使用したハイブリッド デプロイで Apigee Adapter for Envoy を使用します。
接続パスとルーティング パスを設計する前に、ローカルまたはリモートの API ゲートウェイに転送する必要があるトラフィックまたは API リクエストと、送信元環境と宛先環境を特定する必要があります。
VPC Service Controls を使用して、プロジェクト内の Google Cloud サービスを保護し、プロジェクト レベルまたは VPC ネットワーク レベルでサービス境界を指定してデータ漏洩のリスクを軽減します。
- 承認済みの VPN または Cloud Interconnect 経由でハイブリッド環境にサービス境界を拡張できます。サービス境界の利点については、VPC Service Controls の概要をご覧ください。
Virtual Private Cloud（VPC）ファイアウォール ルールまたはファイアウォール ポリシーを使用して、Private Service Connect エンドポイントを介して Private Service Connect リソースへのネットワーク レベルのアクセスを制御します。たとえば、アプリケーション（コンシューマー）VPC のアウトバウンド ファイアウォール ルールでは、VM インスタンスからエンドポイントの IP アドレスまたはサブネットへのアクセスを制限できます。
Private Service Connect インターフェースを使用する場合は、Private Service Connect インターフェースのセキュリティを構成して、インターフェースへの通信を保護する必要があります。
プライベート サブネット内のワークロードにインターネット アクセスが必要な場合は、Cloud NAT を使用して、ワークロードに外部 IP アドレスを割り当ててパブリック インターネットに公開することを回避します。
- アウトバウンド ウェブ トラフィックには、Secure Web Proxy を使用します。このプロキシにはいくつかのメリットがあります。
ハイブリッド クラウドとマルチクラウドのネットワーキング パターンに関する一般的なベスト プラクティスを確認します。
引き継ぎパターン
ハンドオーバー パターンでは、Google Cloudが提供するストレージ サービスを使用して、プライベート コンピューティング環境を Google Cloudのプロジェクトに接続します。このパターンは、分析のハイブリッド マルチクラウド アーキテクチャ パターンに従っている設定に主に適用され、次のように機能します。
- プライベート コンピューティング環境または別のクラウドで実行中のワークロードは、共有ストレージの場所にデータをアップロードします。ユースケースに応じて、アップロードは一括で行われることも、小刻みに行われることもあります。
- Google Cloudでホストされるワークロードや他の Google サービス（データ分析サービスや人工知能サービスなど）は、共有ストレージ ロケーションからデータを使用して、ストリーミング方式またはバッチ方式で処理します。
アーキテクチャ
次の図は、ハンドオーバー パターンのリファレンス アーキテクチャを示しています。
上記のアーキテクチャ図は、次のワークフローを示しています。
- Google Cloud 側では、ワークロードをアプリケーション VPC にデプロイします。こうしたワークロードには、データ処理、分析、分析関連のフロントエンド アプリケーションが含まれます。
- フロントエンド アプリケーションをユーザーに安全に公開するには、Cloud Load Balancing または API Gateway を使用します。
- Cloud Storage バケットまたは Pub/Sub キューのセットは、プライベート コンピューティング環境からデータをアップロードし、 Google Cloudにデプロイされたワークロードでそのデータを処理できるようにします。Identity and Access Management（IAM）ポリシーを使用して、信頼できるワークロードのみにアクセスを制限できます。
- VPC Service Controls を使用して、サービスへのアクセスを制限し、 Google Cloud サービスからの不正なデータ引き出しのリスクを最小限に抑えます。
- このアーキテクチャでは、Cloud Storage バケットまたは Pub/Sub との通信は、公開ネットワーク経由で行われるか、VPN、Cloud Interconnect、Cross-Cloud Interconnect を使用したプライベート接続経由で行われます。通常、接続方法の決定は、次のようなさまざまな側面に左右されます。
- 予想されるトラフィック量
- 一時的なセットアップか永続的なセットアップか
- セキュリティとコンプライアンス要件
バリエーション
ゲート付き上り（内向き）パターンで説明されている設計オプション（Google API 用の Private Service Connect エンドポイントを使用）も、このパターンに適用できます。具体的には、Cloud Storage、BigQuery、その他の Google サービス API へのアクセスを提供します。このアプローチでは、VPN、Cloud Interconnect、Cross-Cloud Interconnect などのハイブリッドおよびマルチクラウド ネットワーク接続を介したプライベート IP アドレス指定が必要です。
ベスト プラクティス
- Cloud Storage バケットと Pub/Sub トピックへのアクセスを制限します。
- 該当する場合は、 Google Cloud ソリューション スイートなどのクラウド ファーストの統合データ移動ソリューションを使用します。これらのソリューションは、ユースケースのニーズを満たすために、データの移動、統合、変換を効率的に行うように設計されています。
費用、想定される転送時間、セキュリティなど、データ転送オプションに影響するさまざまな要素を評価します。詳細については、転送オプションの評価をご覧ください。
レイテンシを最小限に抑え、公共のインターネット経由での大容量のデータ転送と移動を防ぐには、Cloud Interconnect または Cross-Cloud Interconnect の使用を検討してください。これには、Google API 用の Virtual Private Cloud 内の Private Service Connect エンドポイントへのアクセスも含まれます。
プロジェクト内の Google Cloud サービスを保護し、データの漏洩のリスクを軽減するには、VPC Service Controls を使用します。これらのサービス制御では、プロジェクト レベルまたは VPC ネットワーク レベルでサービス境界を指定できます。
- 承認済みの VPN または Cloud Interconnect 経由でハイブリッド環境にサービス境界を拡張できます。サービス境界の利点については、VPC Service Controls の概要をご覧ください。
API Gateway、ロードバランサ、または仮想ネットワーク アプライアンスを介して、VM インスタンスでホストされている一般公開のデータ分析ワークロードと通信します。セキュリティを強化し、これらのインスタンスがインターネットから直接アクセスできないようにするには、次のいずれかの通信方法を使用します。
インターネット アクセスが必要な場合は、同じ VPC で Cloud NAT を使用して、インスタンスからパブリック インターネットへのアウトバウンド トラフィックを処理できます。
ハイブリッド クラウドとマルチクラウドのネットワーキング トポロジに関する一般的なベスト プラクティスを確認します。
一般的なベスト プラクティス
クラウド ID、リソース階層、ランディング ゾーン ネットワークを設計してオンボーディングするときは、 Google Cloudのランディング ゾーンの設計に記載されている設計推奨事項とエンタープライズ基盤のブループリントに記載されている Google Cloud セキュリティのベスト プラクティスを考慮してください。選択したデザインを、次のドキュメントに照らし合わせて検証してください。
- VPC 設計のためのおすすめの方法とリファレンス アーキテクチャ
- Google Cloud ランディング ゾーンのリソース階層を決定する
- Google Cloud Well-Architected Framework: セキュリティ、プライバシー、コンプライアンス
次に示す一般的なベスト プラクティスも考慮してください。
ハイブリッドまたはマルチクラウドのネットワーク接続性オプションを選択するときは、ビジネスとアプリケーションの要件（SLA、パフォーマンス、セキュリティ、コスト、信頼性、帯域幅など）を考慮してください。詳細については、Network Connectivity プロダクトの選択と他のクラウド サービス プロバイダを Google Cloudに接続するためのパターンをご覧ください。
複数の VPC を使用するのではなく Google Cloud での共有 VPC を使用します（このことが実際のリソース階層設計の要件に沿っていて適切である場合）。詳細については、複数の VPC ネットワークを作成するかどうかを決定するをご覧ください。
アカウントと組織の計画に関するベスト プラクティスに従います。
該当する場合は、環境間に共通の ID を確立します。これでシステムが環境の境界を越えて安全に認証を行うことができます。
ハイブリッド セットアップでアプリケーションを社内ユーザーに安全に公開するために、および要件に最も適したアプローチを選択するために、推奨される方法に従って Google Cloud と既存の ID 管理システムを統合する必要があります。
- ハイブリッド環境で従業員ユーザーを認証するパターンもご覧ください。
オンプレミスとクラウドの環境を設計するときは、IPv6 アドレッシングを早くから検討するとともに、どのサービスでサポートされるかを考慮に入れてください。詳細については、 Google Cloudでの IPv6 の概要をご覧ください。この記事では、ブログの執筆時点でサポートされていたサービスがまとめられています。
VPC ファイアウォール ルールを設計、デプロイ、管理するときに、次のことができます。
- ファイアウォール ルールを VM に適用する方法を厳密に制御する必要がある場合は、ネットワーク タグに基づくフィルタリングではなくサービス アカウントに基づくフィルタリングを使用します。
- 複数のファイアウォール ルールをグループ化するときは、ファイアウォール ポリシーを使用します。これで、すべてを一度に更新できます。ポリシーを階層化することもできます。階層型ファイアウォール ポリシーの仕様と詳細については、階層型ファイアウォール ポリシーをご覧ください。
- 外部 IPv4 と外部 IPv6 のトラフィックを特定の地理的位置またはリージョンに基づいてフィルタリングする必要があるときに、ファイアウォール ポリシーの中で位置情報オブジェクトを使用します。
- ファイアウォール ポリシールールの脅威インテリジェンスを使用すると、脅威インテリジェンス データ（既知の悪意のある IP アドレスなど）に基づいて、またはパブリック クラウド IP アドレス範囲に基づいてトラフィックを許可またはブロックするという方法で、ネットワークを保護することができます。たとえば、自分のサービスが特定のパブリック クラウドのみと通信する必要がある場合に、そのパブリック クラウド IP アドレス範囲からのトラフィックを許可できます。詳細については、ファイアウォール ルールのベスト プラクティスをご覧ください。
クラウドとネットワークのセキュリティを設計するときは常に、多層セキュリティのアプローチを使用する必要があります。具体的には、次のような追加のセキュリティ レイヤを検討してください。
- Google Cloud Armor
- Cloud Intrusion Detection System
- Cloud Next Generation Firewall IPS
- ファイアウォール ポリシールールの脅威インテリジェンス
これらの追加レイヤによって、さまざまな脅威のフィルタリング、検査、モニタリングをネットワーク レイヤとアプリケーション レイヤで行い、分析と防止に利用することができます。
ハイブリッド セットアップで DNS 解決をどこで行うかを決定するときは、2 つの権威 DNS システムを使用することをおすすめします。一つはプライベートGoogle Cloud 環境用、もう一つはオンプレミス環境内の既存の DNS サーバーによってホストされるオンプレミス リソース用です。詳細については、DNS 解決を実行する場所を選択するをご覧ください。
可能であれば、アプリケーションの公開は常に API を通して行い、これには API ゲートウェイまたはロードバランサを使用します。Apigee などの API プラットフォームを検討することをおすすめします。Apigee は、バックエンド サービス API の抽象化またはファサードとしての役割を果たすものであり、さらにセキュリティ、レート制限、割り当て、分析の機能も備えています。
API プラットフォーム（ゲートウェイまたはプロキシ）とアプリケーション ロードバランサは相互に排他的ではありません。時には、API ゲートウェイとロードバランサを併用することによって、API トラフィックの管理と分散を大規模に行うための堅牢でセキュリティに優れたソリューションを実現できる可能性があります。Cloud Load Balancing API ゲートウェイを使用すると、次のことを達成できます。
Apigee と Cloud CDN を使用して高パフォーマンス API をデリバリーすることによって、次のことを実現します。
- レイテンシを短縮する
- API をグローバルにホストする
トラフィックのピークシーズンに可用性を高める
詳細については、Apigee と Cloud CDN を使用した高パフォーマンス API のデリバリーについての YouTube の動画をご覧ください。
高度なトラフィック管理を実装します。
Cloud Armor を DDoS 対策、WAF、ネットワーク セキュリティ サービスとして使用して API を保護します。
複数のリージョンにあるゲートウェイ間の効率的なロード バランシングを管理します。詳細については、PSC と Apigee を使用して API を保護し、マルチリージョン フェイルオーバーを実装することについての動画をご覧ください。
使用する Cloud Load Balancing プロダクトを決定するには、まず、ロードバランサが処理するトラフィック タイプを決定する必要があります。詳細については、ロードバランサを選択するをご覧ください。
Cloud Load Balancing を使用するときは、そのアプリケーション処理能力最適化の機能を使用してください（該当する場合）。このようにすると、グローバルに分散したアプリケーションで発生する可能性のある、処理能力の課題にある程度対処できます。
- レイテンシに関する詳しい解説については、ロード バランシングによるアプリケーション レイテンシの最適化をご覧ください。
Cloud VPN では環境間のトラフィックが暗号化されますが、Cloud Interconnect を使用するときは、接続レイヤで転送中のトラフィックを暗号化するために、MACsec を使用するか、Cloud Interconnect を介した HA VPN を使用する必要があります。詳細については、Cloud Interconnect 経由のトラフィックを暗号化するにはどうすればよいですか？をご覧ください。
- TLS を使用するサービスレイヤ暗号化も検討してください。詳細については、転送データの暗号化に関するコンプライアンス要件を満たす方法を決定するをご覧ください。
VPN ハイブリッド接続を通過する必要のあるトラフィックが、単一の VPN トンネルでサポートできる量よりも多い場合は、アクティブ / アクティブの HA VPN ルーティング オプションの使用を検討してください。
- 長期的なハイブリッドまたはマルチクラウド セットアップのアウトバウンド データ転送量が多い場合は、Cloud Interconnect または Cross-Cloud Interconnect を検討してください。これらの接続オプションは、接続パフォーマンスの最適化に役立つとともに、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を縮小できる可能性があります。詳しくは、Cloud Interconnect の料金をご覧ください。
Google Cloudに接続するときに、Cloud Interconnect、ダイレクト ピアリング、キャリア ピアリングのいずれかの選択を考えている場合は、Google Workspace のアプリケーションにアクセスする必要がなければ Cloud Interconnect を使用することをおすすめします。詳細については、ダイレクト ピアリングと Cloud Interconnect の機能比較とキャリア ピアリングと Cloud Interconnect の機能比較をご覧ください。
クラウドでホストされているシステムに対応するために十分な IP アドレス空間を、既存の RFC 1918 IP アドレス空間から確保します。
技術的な制限が理由で現在の IP アドレス範囲を維持する必要がある場合は、次の方法を取ることができます。
オンプレミス ワークロードの内部 IP アドレスは、そのワークロードを Google Cloudに移行する間も同じものを使用します。これにはハイブリッド サブネットを使用します。
Google Cloud リソース用に、お客様が所有するパブリック IPv4 アドレスをプロビジョニングして使用します。これには Google へのお客様所有 IP アドレス持ち込み（BYOIP）を使用します。
ソリューションの設計の要件として、Google Cloudベースのアプリケーションをパブリックのインターネットに公開することが求められている場合は、インターネットに接続するアプリケーションの配信のためのネットワーキングでご紹介している設計推奨事項を検討してください。
該当する場合は、Private Service Connect エンドポイントを使用します。これにより、 Google Cloud、オンプレミス、またはハイブリッド接続を使用する別のクラウド環境のワークロードが、Google API または公開サービスにプライベート アクセスできるようになります。これには内部 IP アドレスが使用され、粒度の高い管理が可能です。
Private Service Connect を使用するときは、次のことを制御する必要があります。
- 誰が Private Service Connect のリソースをデプロイできるか。
- 接続をコンシューマーとプロデューサーの間で確立できるかどうか。
- どのネットワーク トラフィックにその接続へのアクセスを許可するか。
詳細については、Private Service Connect のセキュリティをご覧ください。
ハイブリッドとマルチクラウドのアーキテクチャにおいて堅牢なクラウド セットアップを実現するには:
- さまざまなアプリケーションにどの程度の信頼性が求められるかについての評価を、すべての環境にわたって包括的に実施します。このことは、可用性とレジリエンスの目標達成に役立ちます。
- 利用するクラウド プロバイダの信頼性能力と設計原則を理解します。詳細については、Google Cloud インフラストラクチャの信頼性をご覧ください。
クラウド ネットワークの可視性とモニタリングは、信頼性の高い通信を維持するために不可欠です。Network Intelligence Center を利用すると、単一のコンソールでネットワークの可視性、モニタリング、トラブルシューティングを管理できます。
ハイブリッド クラウドとマルチクラウドの安全なネットワーキング アーキテクチャ パターン: 次のステップ
- このドキュメントで説明したネットワーキング パターンを使用して実現できる一般的なアーキテクチャ パターンの詳細を確認する。
- ハイブリッドとマルチクラウドにアプローチする方法と、適切なワークロードを選択する方法について学びます。
- オンプレミスと他のクラウドにまたがるアプリケーションとユーザー向けに最適化された、オープンで安全なグローバル ネットワーク プラットフォームである Google Cloud Cross-Cloud Network の詳細をご覧ください。
- Google Cloudのワークロードに適した信頼性の高いインフラストラクチャを設計する: リソース、ゾーン、リージョン レベルで障害からアプリケーションを保護するための設計ガイダンス。
- Google Cloudで高可用性アーキテクチャを設計する方法について詳しくは、スケーラブルで復元性の高いアプリのためのパターンをご覧ください。
- オンプレミス環境またはエッジ環境で実行されている GKE Enterprise クラスタを Google Cloud ネットワークに接続するための使用可能な接続オプションと、 Google Cloudからの一時的な接続解除の影響について学習します。