このドキュメントは、一連の 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 のワークロードと他の環境のワークロード間の通信モデルをどちら側からでも開始できることです。Service Mesh を使用して、アプリケーション要件とセキュリティ要件に基づいてトラフィックをきめ細かく制御する必要があります。
メッシュ パターンのベスト プラクティス
- 他の操作を行う前に、リソース階層の設計と、プロジェクトおよび 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 をこれらのゲートパターンと統合するには、ネットワーク設計内に複数のセキュリティ ゾーンを導入し、それぞれに異なるアクセス制御レベルを設定する必要があります。
下り（外向き）ゲート型
下り（外向き）ゲート型ネットワーキング パターンのアーキテクチャは、オンプレミス環境または他のクラウド環境の一部の API を、 Google Cloudにデプロイされたワークロードに公開することをベースにしています。オンプレミス環境や他のクラウド環境から公共のインターネットに直接公開することなく、これを行うことができます。この制限された公開は、既存のワークロードのファサードとして機能する 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 側では、ワークロードを Virtual Private Cloud（VPC）にデプロイできます。VPC は単一または複数（共有または非共有）にできます。デプロイは、組織のプロジェクトとリソース階層の設計に沿っている必要があります。
- Google Cloud 環境の VPC ネットワークは、他のコンピューティング環境に拡張されます。環境はオンプレミスでも、別のクラウドでも構いません。内部 IP アドレスを使用して環境間の通信を容易にするには、適切なハイブリッド マルチクラウド ネットワーキング接続を使用します。
特定の VPC IP アドレスから発信され、リモート ゲートウェイまたはロードバランサに宛てられたトラフィックを制限するには、IP アドレス許可リスト フィルタリングを使用します。ステートフル ファイアウォール ルールを使用すると、これらの接続からの戻りトラフィックが許可されます。次の機能の組み合わせを使用して、通信を保護し、許可された送信元 IP アドレスと宛先 IP アドレスに限定できます。
次世代ファイアウォール（NGFW）検査機能を備え、ネットワーク パスに配置されたネットワーク仮想アプライアンス（NVA）。
侵入防止サービス（IPS）を備えた Cloud Next Generation Firewall Enterprise。脅威防止のための詳細なパケット検査を実装します。
すべての環境は、重複のない RFC 1918 IP アドレス空間を共有します。
バリエーション
下り（外向き）ゲート型アーキテクチャ パターンを他のアプローチと組み合わせると、このパターンの通信要件を考慮しながら、さまざまな設計要件を満たすことができます。このパターンには次のオプションがあります。
Google Cloud API Gateway とグローバル フロントエンドを使用する
この設計アプローチでは、API の公開と管理はGoogle Cloud内に存在します。上の図に示すように、Apigee を API プラットフォームとして実装することで、この要件を満たすことができます。リモート環境に API ゲートウェイまたはロードバランサをデプロイするかどうかは、特定のニーズと現在の構成によって異なります。Apigee には、接続をプロビジョニングする 2 つのオプションがあります。
- VPC ピアリングを使用
- VPC ピアリングを使用しない
Google Cloud のグローバル フロントエンド機能（Cloud Load Balancing、Cloud CDN（Cloud Interconnect 経由でアクセスする場合）、Cross-Cloud Interconnect など）により、オンプレミス環境や他のクラウド環境でホストされているバックエンドを備えたアプリケーションにユーザーがアクセスする速度が向上します。
コンテンツ配信速度を最適化するには、 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 ネットワーク エンドポイント グループ（NEG）を使用して、プロデューサー サービス アタッチメントに関連付けられた Private Service Connect 接続を介して、公開サービス（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 エンドポイントにアクセスする場合、グローバル アクセスが有効なエンドポイントに宛てられたトラフィックにリージョン間アウトバウンド料金が適用されます。
ベスト プラクティス
- API プラットフォーム ソリューションとして Apigee と Apigee ハイブリッドを検討すると、いくつかのメリットがあります。Apigee は、バックエンド サービス API のプロキシレイヤと抽象化またはファサードを提供し、セキュリティ機能、レート制限、割り当て、分析を組み合わせて提供します。
- 要件とアーキテクチャに該当する場合は、Kubernetes を使用した Apigee Hybrid のデプロイ アーキテクチャで Apigee Adapter for Envoy を使用します。
- Google Cloud の VPC とプロジェクトの設計は、リソース階層と安全な通信モデルの要件に基づく必要があります。
- API Gateway を使用する 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 で Apigee on Google Cloud を使用できます。詳細については、分散 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 呼び出し監査を提供できます。
このパターンとメッシュ パターンの主な違いは、特定の IP アドレスの送信元と宛先との双方向 API の使用または通信のみを必要とするシナリオに適用されることです。たとえば、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 で次世代ファイアウォール（NGFW）を備えた Cloud Next Generation Firewall またはネットワーク仮想アプライアンス（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（ハイブリッド接続が接続されている 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 ゲートウェイが使用されていない、または使用が予定されていない安全なアプリケーションを統合するなど、さまざまな通信要件を満たすことができます。
次の図に示すように、Cloud Load Balancing で Private Service Connect を使用すると、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 Service 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 ゲートウェイ、ロードバランサ、または仮想ネットワーク アプライアンスを使用して、VM インスタンスでホストされている一般公開されたデータ分析ワークロードと通信します。セキュリティを強化し、これらのインスタンスにインターネットから直接アクセスできないようにするには、次のいずれかの通信方法を使用します。
インターネット アクセスが必要な場合は、同じ VPC で Cloud NAT を使用して、インスタンスからパブリック インターネットへのアウトバウンド トラフィックを処理できます。
ハイブリッド クラウドとマルチクラウドのネットワーク トポロジに関する一般的なベスト プラクティスを確認します。
一般的なベスト プラクティス
クラウド ID、リソース階層、ランディング ゾーン ネットワークを設計してオンボーディングするときは、 Google Cloudのランディング ゾーンの設計に記載されている設計推奨事項と、エンタープライズ基盤のブループリントに記載されている Google Cloud セキュリティのベスト プラクティスを考慮してください。選択したデザインを、次のドキュメントに照らし合わせて検証してください。
- VPC 設計のためのおすすめの方法とリファレンス アーキテクチャ
- Google Cloud ランディング ゾーンのリソース階層を決定する
- Google Cloud アーキテクチャ フレームワーク: セキュリティ、プライバシー、コンプライアンス
次に示す一般的なベスト プラクティスも考慮してください。
ハイブリッドまたはマルチクラウドのネットワーク接続性オプションを選択するときは、ビジネスとアプリケーションの要件（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 の動画をご覧ください。
高度なトラフィック管理を実装します。
Google 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からの一時的な切断の影響について学びます。