このドキュメントは、Cross-Cloud Network の設計ガイドシリーズの一部です。
このシリーズは、次のパートで構成されています。
- 分散型アプリケーション向けの Cross-Cloud Network
- クロスクラウド ネットワークにおける分散型アプリケーションのネットワーク セグメンテーションと接続
- クロスクラウド ネットワークにおける分散型アプリケーションのサービス ネットワーキング（このドキュメント）
- クロスクラウド ネットワークの分散アプリケーションのネットワーク セキュリティ
このドキュメントでは、選択または作成したコンポーネント サービスのセットからアプリケーションを組み立てる方法について説明します。手順に進む前に、ドキュメント全体を一度読んでおくことをおすすめします。
このドキュメントでは、次のことを判断する方法について説明します。
- 個々のサービスを自身で作成するか、サードパーティ サービスを利用するか
- サービスがグローバルに利用可能か、リージョンで利用可能か
- サービスがオンプレミスか他のクラウド、あるいはそのどちらでもないサービスか
- 共有サービス VPC を介してサービス エンドポイントにアクセスするか、関連するすべてのアプリケーション VPC を介してエンドポイントを配布するか
このドキュメントでは、次の手順について説明します。
- アプリケーションがグローバルかリージョンかを判断する
- サードパーティのマネージド サービスを選択するか、独自のサービスを作成して公開する
- 共有モードまたは専用モードを使用して、サービス エンドポイントへのプライベート アクセスを設定する
- グローバルまたはリージョンのアーキタイプに一致するように、サービスからアプリケーションに組み立てる
デベロッパーは、クロスクラウド ネットワークのサービス ネットワーキング レイヤを定義します。ここまでの段階で、管理者は、このドキュメントで説明するサービス ネットワーキング オプションの柔軟性を利用しながら、クロスクラウド ネットワークの接続レイヤを設計します。場合によっては、制限された VPC 間に推移性の制約が存在することもあります。設計上の決定に影響を与える可能性がある場合は、これらの制約についても説明します。
アプリをリージョン アプリとするかグローバル アプリとするかを決める
作成するアプリケーションのユーザーがリージョン デプロイ アーキタイプとグローバル デプロイ アーキタイプのどちらを必要とするかを判断します。リージョンのゾーンに負荷を分散すると、リージョンの復元性を実現できます。リージョン間でロードバランスすると、グローバルな復元性を実現できます。
アーキタイプを選択する際は、次の要素を考慮してください。
- アプリケーションの可用性要件
- アプリケーションが使用されるロケーション
- 費用
詳細については、Google Cloud のデプロイ アーキタイプをご覧ください。
この設計ガイドでは、次のデプロイ アーキタイプをサポートする方法について説明します。
クロスクラウド分散アプリケーションでは、そのアプリケーションのさまざまなサービスを、異なるクラウド サービス プロバイダ（CSP）またはプライベート データセンターから配信できます。一貫性のある耐障性構造を維持するため、異なる CSP でホストされているサービスを地理的に近い CSP データセンターに配置します。
次の図は、クラウドに分散され、異なる CSP にデプロイされたアプリケーション サービスを示しています。各グローバル アプリケーション サービスには、同じ CSP の異なるリージョンにワークロード インスタンスが配置されています。
アプリケーション サービスの定義とアクセス
アプリケーションを組み立てるには、既存のサードパーティのマネージド サービスを使用するか、独自のアプリケーション サービスを作成してホストします。または、その両方を組み合わせて使用します。
既存のサードパーティ マネージド サービスを使用する
アプリケーションで使用できるサードパーティのマネージド サービスを決定します。リージョン サービスまたはグローバル サービスとして構築するものを決定します。また、各サービスでサポートされているプライベート アクセス オプションを確認します。
使用できるマネージド サービスを特定したら、作成する必要のあるサービスを決定します。
アプリケーション サービスの作成とアクセス
各サービスは、単一のエンドポイントまたはエンドポイント グループとしてアクセスできる 1 つ以上のワークロード インスタンスにホストされます。
アプリケーション サービスの一般的なパターンを次の図に示します。アプリケーション サービスは、ワークロード インスタンスのコレクションにデプロイされます。この場合、ワークロード インスタンスは、Compute Engine VM、Google Kubernetes Engine（GKE）クラスタ、またはコードを実行する他のバックエンドです。ワークロード インスタンスは、ロードバランサに関連付けられたバックエンドのセットとして編成されます。
次の図は、一連のバックエンドを持つ汎用ロードバランサを示しています。
選択したロード バランシングを実現し、フェイルオーバーを自動化するために、これらのエンドポイント グループはフロントエンド ロードバランサを使用します。マネージド インスタンス グループ（MIG）を使用すると、ロードバランサのバックエンドを構成するエンドポイントを自動スケーリングすることで、サービスの容量を柔軟に増減できます。さらに、アプリケーション サービスの要件に応じて、ロードバランサは認証、TLS 終端、その他の接続固有のサービスも提供できます。
サービスの範囲（リージョンまたはグローバル）を決める
サービスがリージョンまたはグローバルの復元性を必要とし、サポートできるかどうかを判断します。リージョン ソフトウェア サービスは、リージョンのレイテンシ バジェット内で同期するように設計できます。グローバル アプリケーション サービスは、リージョン間で分散されているノード間の同期フェイルオーバーをサポートできます。アプリケーションがグローバルである場合、それをサポートするサービスもグローバルにすることをおすすめします。ただし、サービスがフェイルオーバーのサポートでインスタンス間の同期を必要とする場合は、リージョン間のレイテンシを考慮する必要があります。状況によっては、同じリージョンまたは近隣のリージョンで冗長性のあるリージョン サービスに依存し、フェイルオーバーの低レイテンシ同期をサポートする必要があります。
Cloud Load Balancing は、単一リージョン内またはリージョン間でホストされるエンドポイントをサポートします。そのため、グローバル、リージョン、またはハイブリッド サービスレイヤと通信するグローバルな顧客に対応するレイヤを作成できます。動的ネットワーク フェイルオーバー（またはリージョン間のロード バランシング）がアプリケーション ロジックの復元性の状態と機能と一致するように、サービス デプロイを選択します。
次の図は、リージョン ロードバランサから構築されたグローバル サービスが他のリージョンのバックエンドに到達し、リージョン間の自動フェイルオーバーを実現する方法を示しています。この例では、アプリケーション ロジックはグローバルであり、選択したバックエンドはリージョン間の同期をサポートしています。各ロードバランサは主にローカル リージョンにリクエストを送信しますが、リモート リージョンにフェイルオーバーすることもできます。
- グローバル バックエンドは、複数のロードバランサによってアクセスされるリージョン バックエンドのコレクションです。
- バックエンドはグローバルですが、各ロードバランサのフロントエンドはリージョンです。
- このアーキテクチャ パターンでは、ロードバランサは主にリージョン内のトラフィックを分散しますが、ローカル リージョンのリソースが使用できない場合は、他のリージョンにもトラフィックを分散できます。
- リージョン ロードバランサのフロントエンドのセットは、それぞれが他のリージョンからアクセス可能で、他のリージョンのバックエンドに到達できるため、集約されたグローバル サービスを形成します。
- グローバル アプリケーション スタックの設計で説明したように、グローバル アプリケーション スタックを組み立てるには、DNS ルーティングとヘルスチェックを使用して、フロントエンドのリージョン間フェイルオーバーを実現します。
- ロードバランサのフロントエンド自体は、グローバル アクセス（図には示されていません）を使用して他のリージョンからアクセスできます。
この同じパターンを使用して、グローバル フェイルオーバーで公開されたサービスを含めることができます。次の図は、グローバル バックエンドを使用する公開サービスを示しています。
この図では、公開されたサービスのグローバル フェイルオーバーがプロデューサー環境に実装されていることに注意してください。コンシューマー環境にグローバル フェイルオーバーを追加すると、コンシューマーのロード バランシング インフラストラクチャのリージョン障害に対する耐障害性が向上します。サービスのリージョン間フェイルオーバーは、サービス アプリケーション ロジックとサービス プロデューサーのロード バランシング設計の両方で実装する必要があります。他のメカニズムは、サービス プロデューサーによって実装できます。
使用する Cloud Load Balancing プロダクトを決定するには、まず、ロードバランサが処理するトラフィック タイプを決定する必要があります。次の一般的なルールを考慮してください。
- HTTP(S) トラフィックにアプリケーション ロードバランサを使用します。
- HTTP(S) 以外の TCP トラフィックには、プロキシ ネットワーク ロードバランサを使用します。このプロキシ ロードバランサは TLS オフロードもサポートしています。
- パススルー ネットワーク ロードバランサを使用して、ヘッダー内のクライアント送信元 IP アドレスを保持するか、UDP、ESP、ICMP などの追加のプロトコルをサポートします。
ユースケースに最適なロードバランサを選択する方法の詳細については、ロードバランサの選択をご覧ください。
サーバーレス バックエンドを使用するサービス
サービスは、サーバーレス バックエンドを使用して定義できます。プロデューサー環境のバックエンドは、ロードバランサのバックエンドとしてサーバーレス NEG に編成できます。このサービスを公開するには、プロデューサー ロードバランサのフロントエンドに関連付けられたサービス アタッチメントを作成して、Private Service Connect を使用します。公開されたサービスは、Private Service Connect エンドポイントまたは Private Service Connect バックエンドから使用できます。サービスでプロデューサーから開始する接続が必要な場合は、サーバーレス VPC アクセス コネクタを使用して、Cloud Run、App Engine スタンダード環境、Cloud Functions 環境から VPC ネットワーク内のリソースの内部 IPv4 アドレスにパケットを送信できます。サーバーレス VPC アクセスでは、選択した VPC ネットワークに接続している他のネットワークへのパケット送信もサポートされています。
サービスに非公開でアクセスする方法
アプリケーションは、Google が提供するマネージド サービス、組織内の外部ベンダーまたはピアグループが提供するサードパーティ サービス、チームが開発するサービスで構成できます。一部のサービスは、パブリック IP アドレスを使用してインターネット経由でアクセスできます。このセクションでは、これらのサービスにプライベート ネットワークを使用してアクセスする方法について説明します。次のサービスタイプがあります。
- Google の公開 API
- Google サーバーレス API
- Google から公開されたマネージド サービス
- ベンダーとピアから公開されたマネージド サービス
- ユーザーが公開したサービス
以降のセクションを読む際は、これらのオプションを念頭に置いてください。サービスの割り当て方法に応じて、前述のプライベート アクセス オプションの 1 つ以上を使用できます。
サービスを組み立て、公開し、管理する組織（または組織内のグループ）は、サービス プロデューサーと呼ばれます。お客様とお客様のアプリケーションは、サービス コンシューマーと呼ばれます。
一部のマネージド サービスは、限定公開サービス アクセスのみを使用して公開されます。内部接続と VPC ネットワークで推奨されるネットワーク設計は、限定公開サービス アクセスと Private Service Connect で公開されるサービスをサポートします。
サービスに非公開でアクセスするオプションの概要については、サービスのプライベート アクセス オプションをご覧ください。
可能な限り、Private Service Connect を使用してマネージド サービスに接続することをおすすめします。Private Service Connect のデプロイ パターンの詳細については、Private Service Connect のデプロイ パターンをご覧ください。
Private Service Connect には 2 つのタイプがあり、異なるサービスを次のいずれかのタイプとして公開できます。
Private Service Connect エンドポイントとして公開されたサービスは、他のワークロードで直接使用できます。サービスは、サービス プロデューサーによってプロビジョニングされた認証と復元力に依存します。サービスの認証と復元力をさらに制御する場合は、Private Service Connect バックエンドを使用して、コンシューマー ネットワークの認証と復元性のためにロード バランシングのレイヤを追加できます。
次の図は、Private Service Connect エンドポイントを介してアクセスされるサービスを示しています。
次の図は、次のパターンを示しています。
- Private Service Connect エンドポイントがコンシューマー VPC にデプロイされ、VM と GKE ノードでプロデューサー サービスを利用できるようになります。
- コンシューマー ネットワークとプロデューサー ネットワークの両方を同じリージョンにデプロイする必要があります。
上記の図は、エンドポイントをリージョン リソースとして示しています。エンドポイントは、グローバル アクセスにより、他のリージョンから到達可能です。
デプロイ パターンの詳細については、Private Service Connect のデプロイ パターンをご覧ください。
Private Service Connect バックエンドは、Private Service Connect ネットワーク エンドポイント グループ（NEG）バックエンドで構成されたロードバランサを使用します。サポートされているロードバランサの一覧については、Private Service Connect バックエンドについてをご覧ください。
Private Service Connect バックエンドを使用すると、次のバックエンド構成を作成できます。
- マネージド サービスのフロントで処理されるお客様所有のドメインと証明書
- 異なるリージョンのマネージド サービス間でコンシューマーが制御するフェイルオーバー
- マネージド サービスの一元化されたセキュリティ構成とアクセス制御
次の図では、グローバル ロードバランサが Private Service Connect NEG をバックエンドとして使用し、サービス プロバイダとの通信を確立しています。ネットワーク構成の追加は不要で、データは Google の SDN ファブリックを介して転送されます。
ほとんどのサービスは、コンシューマーが開始する接続用に設計されています。サービスがプロデューサーから接続を開始する必要がある場合は、Private Service Connect インターフェースを使用します。
限定公開サービス アクセスまたは Private Service Connect をデプロイする際の重要な考慮事項には推移性があります。通常、公開サービスは VPC ネットワーク ピアリング接続または Network Connectivity Center 経由では到達できません。VPC トポロジ内のサービス アクセス サブネットまたはエンドポイントの場所によって、共有サービスまたは専用サービスのデプロイ用にネットワークを設計するかどうかが決まります。
HA VPN やカスタマー管理プロキシなどのオプションを使用すると、VPC 間の推移的通信が可能になります。
Private Service Connect エンドポイントは、VPC ネットワーク ピアリング経由でアクセスできません。このタイプの接続が必要な場合は、次の図に示すように、内部ロードバランサと Private Service Connect NEG をバックエンドとしてデプロイします。
Private Service Connect エンドポイントとバックエンドを使用すると、Google API に非公開でアクセスできます。Google API プロデューサーは復元力と証明書ベースの認証を提供するため、通常はエンドポイントの使用をおすすめします。
サービスにアクセスする必要のあるすべての VPC に Private Service Connect エンドポイントを作成します。次の図に示すように、コンシューマー IP アドレスはプライベート グローバル IP アドレスであるため、複数の VPC にエンドポイント インスタンスが存在する場合でも、サービスごとに単一の DNS マッピングが必要です。
サービスの使用パターンを定義する
サービスは、VPC ネットワーク、別の VPC ネットワーク、オンプレミス データセンター、クラウドなど、さまざまな場所で実行できます。サービス ワークロードの実行場所に関係なく、アプリケーションは次のいずれかのアクセス ポイントを使用して、これらのサービスを使用します。
- 限定公開サービス アクセスのサブネット内の IP アドレス
- Private Service Connect エンドポイント
- Private Service Connect NEG を使用するロードバランサの VIP
コンシューマー アクセス ポイントは、ネットワーク間で共有することも、単一のネットワークに専用にすることもできます。組織がコンシューマー サービス アクセス ポイントの作成タスクを各アプリケーション グループに委任するのか、サービスへのアクセスを統合的に管理するのかによって、共有コンシューマー アクセス ポイントと専用コンシューマー アクセス ポイントのどちらを作成するのかが決定します。
サービス アクセスの管理には、次のアクティビティが含まれます。
- アクセス ポイントを作成する
- VPC 内に、適切なタイプのネットワーク到達性を持つアクセス ポイントをデプロイする
- コンシューマー アクセス ポイントの IP アドレスと URL を DNS に登録する
- コンシューマー アクセス ポイントの前にロード バランシングを追加する場合、コンシューマー スペースでサービスのセキュリティ証明書と復元力を管理する
サービスのアクセス管理を中央チームに割り当てる組織もあれば、各コンシューマーまたはアプリケーション チームに独立性を付与するように構成されている組織もあります。専用モードで動作すると、一部の要素が複製されます。たとえば、サービスは各アプリケーション グループによって複数の DNS 名に登録され、複数の TLS 証明書セットを管理します。
クロスクラウド ネットワークの分散アプリケーションのネットワーク セグメンテーションと接続で説明されている VPC 設計では、共有モードまたは専用モードでサービス アクセス ポイントをデプロイするためのネットワーク到達性が実現されます。共有コンシューマー アクセス ポイントはサービス VPC にデプロイされます。サービス VPC は、他の VPC または外部ネットワークからアクセスできます。専用コンシューマー アクセス ポイントはアプリケーション VPC にデプロイされます。アクセス ポイントには、そのアプリケーション VPC 内のリソースからのみアクセスできます。
サービス VPC とアプリケーション VPC の主な違いは、サービス VPC が有効にするサービス アクセス ポイントの推移的接続です。サービス VPC は、コンシューマー アクセス ポイントのホストに限定されません。VPC は、アプリケーション リソースと共有コンシューマー アクセス ポイントをホストできます。その場合、VPC をサービス VPC として構成し、処理する必要があります。
共有マネージド サービスのアクセス
どのサービス使用方法でも（Private Service Connect を含む）、次のタスクを実行します。
- サービス コンシューマー アクセス ポイントをサービス VPC にデプロイします。サービス VPC は、他の VPC に推移的に到達可能です。
- HA-VPN 経由で他のネットワークにピアリングする Cloud Router から、カスタムルート アドバタイズとしてコンシューマー アクセス ポイントのサブネットをアドバタイズします。Google API の場合は、API のホスト IP アドレスをアドバタイズします。
- 限定公開サービス アクセス サブネットを許可するようにマルチクラウド ファイアウォール ルールを更新します。
特に限定公開サービス アクセスについては、次の追加要件を満たしていることを確認してください。
- カスタムルートをサービス プロデューサーのネットワークにエクスポートします。詳細については、オンプレミス ホストがサービス プロデューサーのネットワークと通信できないをご覧ください。
- 限定公開サービスがアプリケーション VPC のサブネットにアクセスできるように、上り（内向き）ファイアウォール ルールを作成します。
- 限定公開サービスがサービス VPC のサブネットにアクセスできるように、上り（内向き）ファイアウォール ルールを作成します。
サーバーレス サービス アクセスの場合は、次の要件を満たしていることを確認してください。
- アクセス コネクタには、/28 の通常のサブネットを専用として割り当てる必要があります。
- Cloud Router はデフォルトで通常のサブネットをアドバタイズします。
- VPC 内の VPC アクセス サブネットをすべて許可する上り（内向き）ファイアウォール ルールを作成します。
- VPC アクセス コネクタのサブネットを許可するようにマルチクラウド ファイアウォール ルールを更新します。
- 限定公開サービスがアプリケーション VPC のサブネットにアクセスできるように、上り（内向き）ファイアウォール ルールを作成します。
専用マネージド サービスのアクセス
次のタスクを完了していることを確認してください。
- アクセスが必要な各アプリケーション VPC で、サービスの転送ルールをデプロイしてアクセス ポイントを作成します。
- 限定公開サービス アクセスの場合は、上り（内向き）ファイアウォール ルールを作成して、限定公開サービスがアプリケーション VPC のサブネットにアクセスできるようにします。
サーバーレス サービス アクセスの場合は、次の要件を満たしていることを確認してください。
- アクセス コネクタには、/28 の通常のサブネットを専用として割り当てる必要があります。
- アプリケーション VPC 内の VPC アクセス コネクタ サブネットを許可する上り（内向き）ファイアウォール ルールを作成します。
アプリケーション スタックを組み立てる
このセクションでは、リージョンまたはグローバル アプリケーション スタックの組み立てについて説明します。
リージョン アプリケーション スタックを設計する
アプリケーションがリージョンまたはマルチリージョンのデプロイ アーキタイプの場合は、リージョン アプリケーション スタックを使用します。リージョン アプリケーション スタックは、リージョン アプリケーション サービスレイヤの連結と考えることができます。たとえば、同じリージョン内のアプリケーション レイヤと通信し、そのアプリケーション レイヤが同じリージョン内のデータベース レイヤと通信するリージョン ウェブサービス レイヤがリージョン アプリケーション スタックになります。
各リージョン アプリケーション サービスレイヤは、ロードバランサを使用して、そのリージョンのレイヤのエンドポイントにトラフィックを分散します。バックエンド リソースをリージョン内の 3 つ以上のゾーンに分散することで信頼性が実現されています。
他の CSP またはオンプレミス データセンターのアプリケーション サービスレイヤは、外部ネットワークの同等のリージョンにデプロイする必要があります。また、公開サービスをスタックのリージョンで利用できるようにします。リージョン内のアプリケーション スタックを調整するには、アプリケーション サービスレイヤの URL を特定のロードバランサ フロントエンドのリージョン IP アドレスに解決する必要があります。これらの DNS マッピングは、アプリケーション サービスごとに関連する DNS ゾーンに登録されます。
次の図は、アクティブ スタンバイ レジリエンスのリージョン スタックを示しています。
アプリケーション スタックの完全なインスタンスが、さまざまなクラウド データセンターの各リージョンにデプロイされます。いずれかのアプリケーション サービスレイヤでリージョン障害が発生すると、他リージョンのスタックがアプリケーション全体の配信を引き継ぎます。このフェイルオーバーは、さまざまなアプリケーション サービスレイヤの帯域外モニタリングに応じて行われます。
いずれかのサービスレイヤで障害が報告されると、アプリケーションのフロントエンドはバックアップ スタックに再びアンカーされます。アプリケーションは、DNS のリージョン IP アドレス スタックを反映する一連のリージョン名レコードを参照するように記述されています。これにより、アプリケーションの各レイヤは同じリージョン内の接続を維持しています。
グローバル アプリケーション スタックを設計する
アプリケーションがグローバル アプリケーションのデプロイ アーキタイプの場合、各アプリケーション サービスレイヤには複数のリージョンのバックエンドが含まれています。複数のリージョンにバックエンドを追加すると、アプリケーション サービスレイヤのレジリエンス プールが単一リージョンを超えて拡張され、フェイルオーバーの検出と再収束が自動的に行われます。
次の図は、グローバル アプリケーション スタックを示しています。
次の図は、以下のコンポーネントから構成されたグローバル アプリケーションを示しています。
- ロードバランサ フロントエンドを使用してオンプレミス データセンターで実行されているサービス。ロードバランサのアクセス ポイントは、トランジット VPC から Cloud Interconnect 経由で到達可能です。
- トランジット VPC は、外部データセンターとアプリケーション VPC 間のハイブリッド接続をホストします。
- ワークロード インスタンスで実行されているコア アプリケーションをホストするアプリケーション VPC。これらのワークロード インスタンスはロードバランサの背後に存在します。ロードバランサは、ネットワーク内の任意のリージョンから到達可能であり、ネットワーク内の任意のリージョンにあるバックエンドに到達できます。
- サードパーティの VPC など、他のロケーションで実行されているサービスのアクセス ポイントをホストするサービス VPC。これらのサービス アクセス ポイントは、サービス VPC とトランジット VPC 間の HA VPN 接続を介して到達可能です。
- 他の組織またはプライマリ組織によってホストされているサービス プロデューサーの VPC と、他の場所で実行されるアプリケーション。関連するサービスは、サービス VPC でホストされているリージョン ロードバランサにグローバル バックエンドとしてデプロイされた Private Service Connect バックエンドによって到達可能になります。リージョン ロードバランサは、他のリージョンから到達可能です。
作成したアプリケーションをインターネットからアクセスできるようにするには、アプリケーション VPC 内のアプリケーション ワークロードを指すグローバル外部アプリケーション ロードバランサを追加します（図には示されていません）。
グローバル アプリケーション スタックをサポートするために、各アプリケーション レイヤにグローバル バックエンドを使用しました。これにより、1 つのリージョン内のすべてのバックエンド エンドポイントの障害から回復できます。各リージョンには、アプリケーション サービスレイヤごとにリージョン ロードバランサ フロントエンドがあります。リージョン フェイルオーバーが発生した場合、内部リージョン ロードバランサのフロントエンドはグローバル アクセスを使用するため、リージョンをまたいでアクセスできます。アプリケーション スタックはグローバルであるため、DNS 位置情報ルーティング ポリシーを使用して、特定のリクエストまたはフローに最適なリージョン フロントエンドを選択します。フロントエンド障害が発生した場合は、DNS ヘルスチェックを使用して、フロントエンド間のフェイルオーバーを自動化できます。
Private Service Connect バックエンドを使用して公開されたサービスでは、Private Service Connect グローバル アクセスのメリットを利用できます。この機能により、Private Service Connect バックエンドはどのリージョンからもアクセス可能になり、アプリケーション サービスレイヤの障害による中断が軽減されます。つまり、サービスのスコープ（リージョンまたはグローバル）を決定するで説明されているように、Private Service Connect バックエンドをグローバル バックエンドとして利用できます。
外部ネットワークでホストされているサービスへのプライベート アクセスを提供する
別のネットワークでホストされているサービスのローカル アクセス ポイントを公開したい場合もあります。このような場合は、ハイブリッド NEG を使用して内部リージョン TCP プロキシ ロードバランサを使用できます。次の図に示すように、オンプレミスまたは他のクラウド環境でホストされているサービスを作成し、VPC ネットワーク内のクライアントが利用できるようにできます。
ロードバランサをホストする VPC ネットワーク以外の VPC ネットワークでハイブリッド サービスを利用できるようにするには、Private Service Connect を使用してサービスを公開します。サービス アタッチメントを内部リージョン TCP プロキシ ロードバランサの前に配置することで、他の VPC ネットワーク内のクライアントが、オンプレミスまたは他のクラウド環境で実行されているハイブリッド サービスに到達できるようになります。
クロスクラウド環境では、ハイブリッド NEG を使用すると、アプリケーション間の通信を安全に行うことができます。
別の組織がアプリケーション サービスを公開する場合は、ハイブリッド NEG を使用して、そのサービスのプライベート アクセスの抽象化を拡張します。以下の図は、このシナリオを示しています。
上の図では、アプリケーション サービスレイヤが隣接する CSP で完全に構成されています。この部分は灰色ではない部分で、ハイライト表示されています。ハイブリッド ロードバランサは、Google Cloud 内で限定公開の外部アプリケーション サービスを公開するメカニズムとして、Private Service Connect サービス アタッチメントと組み合わせて使用されます。ハイブリッド NEG と Private Service Connect サービス アタッチメントを含むハイブリッド ロードバランサは、サービス プロデューサー プロジェクトの一部である VPC に存在します。このサービス プロデューサー プロジェクトは通常、プロデューサー組織またはプロジェクトの管理範囲内にあるため、トランジット VPC とは異なる VPC になり、共通のトランジット サービスから分離されます。プロデューサー VPC は、コンシューマー VPC（図の Services 共有 VPC）と VPC ピアリングまたは HA VPN で接続する必要はありません。
サービス アクセスを一元管理する
サービス アクセスを VPC ネットワークに集約し、他のアプリケーション ネットワークからアクセスできるようにします。次の図は、アクセス ポイントを集中管理するための一般的なパターンを示しています。
次の図は、専用サービス VPC からアクセスされるすべてのサービスを示しています。
サービスがアプリケーション ロードバランサでフロントエンド処理されている場合、サービスごとに異なるロードバランサを使用する代わりに、URL マップを使用して異なるサービス バックエンドのトラフィックを誘導することで、ロードバランサの数を減らすことができます。原則として、アプリケーション スタックは、単一のアプリケーション ロードバランサとサービス バックエンド、適切な URL マッピングを使用して完全に構成できます。
この実装の大半のバックエンド タイプの場合、VPC 全体でハイブリッド NEG を使用する必要があります。例外は、Private Service Connect を使用した Google Cloud L7 ロードバランサの明示的なチェーンで説明されている Private Service Connect NEG またはバックエンドです。
VPC 間でハイブリッド NEG を使用すると、バックエンドの自動修復と自動スケーリングが失われます。公開サービスには、自動スケーリングを提供するプロデューサー テナントにロードバランサがすでにあります。したがって、公開から使用されるのではなく、ネイティブに作成されるサービスレイヤのロード バランシング機能を一元化した場合にのみ、ハイブリッド NEG が制限されます。
このサービス ネットワーキング パターンを使用する場合、サービスは追加のロード バランシング レイヤを介して使用されることに注意してください。
プロキシ ロード バランシングを使用して、VPC 間の Network Connectivity Center スポーク VPC 接続のスケーリングのメリットを利用し、プロキシ ロードバランサを介して公開サービスに転送接続を提供します。
Private Service Connect サービス エンドポイントと、限定公開サービス アクセスの転送ルールは、Network Connectivity Center スポーク VPC 経由でアクセスできません。同様に、ハイブリッド接続（Cloud Interconnect または HA-VPN）の背後にあるネットワークは、Network Connectivity Center を介して伝播されないため、Network Connectivity Center スポーク VPC を介して到達できません。
この推移の欠如は、非推移リソースをハイブリッド NEG として処理するプロキシ ロードバランサをデプロイすることで回避できます。したがって、プロキシ ロードバランサはサービス フロントエンドの前と、ハイブリッド接続を介して到達可能なワークロードの前にデプロイできます。
ロードバランサ プロキシ フロントエンドは、Network Connectivity Center スポーク VPC 全体に伝播される VPC サブネットにデプロイされます。この伝播により、プロキシ ロードバランサを介して、非推移的リソースの Network Connectivity Center でのネットワーク到達性が実現されます。
集中モードでは、サービスのコンシューマー側にロード バランシング レイヤが追加されます。このモードを使用する場合は、コンシューマー プロジェクトで証明書、復元力、追加の DNS マッピングも管理する必要があります。
その他の考慮事項
このセクションでは、このドキュメントで明示的に説明されていない一般的なプロダクトとサービスの考慮事項について説明します。
GKE コントロール プレーンの考慮事項
GKE コントロール プレーンは、VPC ネットワーク ピアリングを使用してコンシューマーの VPC に接続されている Google マネージド テナント プロジェクトにデプロイされます。VPC ネットワーク ピアリングは推移的ではないため、ハブとスポークの VPC ピアリング ネットワーク トポロジを介してコントロール プレーンに直接通信することはできません。
集中型または分散型などの GKE 設計オプションを検討する場合、マルチクラウド ソースからコントロール プレーンに直接アクセスすることが重要な考慮事項となります。GKE が中央の VPC にデプロイされている場合、コントロール プレーンへのアクセスは、クラウド全体と Google Cloud 内で利用できます。ただし、GKE が分散 VPC にデプロイされている場合、コントロール プレーンへの直接通信はできません。組織の要件で、分散設計パターンの採用に加えて GKE コントロール プレーンへのアクセスが必要な場合、ネットワーク管理者はプロキシとして機能する接続エージェントをデプロイできます。これにより、GKE コントロール プレーンへの非推移型ピアリングの制限を克服できます。
セキュリティ - VPC Service Controls
機密データを含むワークロードの場合は、VPC Service Controls を使用して、VPC リソースと Google 管理サービスの周囲にサービス境界を構成し、境界を越えるデータの移動を制御します。VPC Service Controls を使用すると、プロジェクトとオンプレミス ネットワークを 1 つの境界にグループ化し、この境界により Google 管理サービスを介したデータアクセスを防止できます。VPC Service Controls の上り（内向き）ルールと下り（外向き）ルールを使用すると、異なるサービス境界内のプロジェクトとサービス（境界内にない VPC ネットワークを含む）の通信を許可できます。
推奨されるデプロイ アーキテクチャ、包括的なオンボーディング プロセス、運用のベスト プラクティスについては、エンタープライズ向けの VPC Service Controls のベスト プラクティスと Security Foundation ブループリントをご覧ください。
API / サービスの DNS
サービス プロデューサーは、Private Service Connect を使用してサービスを公開できます。サービス プロデューサーは、必要に応じてサービスに関連付ける DNS ドメイン名を構成できます。ドメイン名が構成され、サービス ユーザーがそのサービスを対象とするエンドポイントを作成すると、Private Service Connect と Service Directory によって、自動的にサービス ユーザーの VPC ネットワーク内の限定公開 DNS ゾーンにあるサービスに対して DNS エントリが作成されます。
次のステップ
- クロスクラウド ネットワーク アプリケーションのネットワーク セキュリティを設計する。
- この設計ガイドで使用する Google Cloud プロダクトの詳細を確認する。
- ファイアウォール NVA のデプロイについて、Google Cloud で一元化されたネットワーク アプライアンスを確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
作成者:
- Victor Moreno | プロダクト マネージャー、クラウド ネットワーキング
- Ghaleb Al-habian | ネットワーク スペシャリスト
- Deepak Michael | ネットワーキング スペシャリスト カスタマー エンジニア
- Osvaldo Costa | ネットワーキング スペシャリスト カスタマー エンジニア
- Jonathan Almaleh | スタッフ テクニカル ソリューション コンサルタント
その他の寄稿者:
- Zach Seils | ネットワーキング スペシャリスト
- Christopher Abraham | ネットワーキング スペシャリスト カスタマー エンジニア
- Emanuele Mazza | ネットワーキング プロダクト スペシャリスト
- Aurélien Legrand | 戦略的クラウド エンジニア
- Eric Yu | ネットワーキング スペシャリスト カスタマー エンジニア
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Marwan Al Shawi | パートナー カスタマー エンジニア
- Ammett Williams | デベロッパー リレーションズ エンジニア