Cloud Load Balancing は、Google Cloud の外部にあるバックエンドへのトラフィックのプロキシをサポートしています。ロードバランサの外部バックエンドを定義するには、インターネット ネットワーク エンドポイント グループ（NEG）と呼ばれるリソースを使用します。
このタイプのデプロイは、外部バックエンドからコンテンツを提供し、Google Cloud ロードバランサをフロントエンドにする場合に使用できます。これにより、以下のことが可能になります。
- Google Edge インフラストラクチャを使用してユーザー接続を終了できます。
- 接続を外部バックエンドに転送できます。
- Google のプライベート バックボーンを通じてパブリック エンドポイントへトラフィックを転送することで、信頼性が向上し、クライアントとサーバー間のレイテンシが減少します。
- グローバル ロードバランサでは、Cloud CDN を使用して外部バックエンドのコンテンツをキャッシュに保存できます。
図 1 は、複数の種類のバックエンドを使用する外部アプリケーション ロードバランサを示しています。バックエンドの 1 つは外部バックエンドで、インターネット NEG を使用して構成されています。
インターネット NEG バックエンドは、さまざまなグローバル ロードバランサとリージョン ロードバランサでサポートされています。ロードバランサ（グローバルまたはリージョン）によって、インターネット NEG のサポートは、DNS、ヘルスチェック、使用可能なエンドポイント数、トラフィック ルーティング動作の点で異なります。
以降のセクションでは、Cloud Load Balancing で外部バックエンドを使用する方法について説明します。Cloud Service Mesh で外部バックエンドを使用する場合は、インターネット ネットワーク エンドポイント グループを使用する Cloud Service Mesh をご覧ください。
用語
次の用語は、同じ意味または類似の意味を持つため、区別されずに使われることがよくあります
- 外部バックエンド: Google Cloud の外部にあり、インターネット経由で到達可能なバックエンド。インターネット NEG 内のエンドポイント。
- カスタムの送信元: 外部バックエンドと同じです。CDN では、ウェブ コンテンツを配信するバックエンド インスタンスを表す標準用語として「送信元」が使用されます。
- インターネット ネットワーク エンドポイント グループ（NEG）: 外部バックエンドの指定に使用する Google Cloud API リソース。
- 外部エンドポイント: 外部バックエンドと同じです。
このドキュメントでは、インターネット NEG API リソースを指す場合を除いて、外部バックエンドという用語を使用します。
ロードバランサ コンポーネント
このセクションでは、外部バックエンドを使用するロードバランサの構成に必要なロード バランシング アーキテクチャとリソースについて説明します。ロードバランサには、バックエンド サービス専用の特別な構成が必要です。フロントエンドの構成は他のロードバランサと同じです。
次の図は、外部バックエンドを使用するロードバランサを設定するために必要な Google Cloud リソースを示しています。
グローバル外部
この図は、外部バックエンドを使用するグローバル外部アプリケーション ロードバランサの設定に必要な Google Cloud リソースを示しています。
リージョン外部
この図は、外部バックエンドを使用するリージョン外部アプリケーション ロードバランサの設定に必要な Google Cloud リソースを示しています。
リージョン内部
この図は、外部バックエンドを使用するリージョン内部アプリケーション ロードバランサの設定に必要な Google Cloud リソースを示しています。
次の図は、外部バックエンドを使用するリージョン内部プロキシ ネットワーク ロードバランサの設定に必要な Google Cloud リソースを示しています。
インターネット NEG はプレミアム ネットワーク サービス ティアでのみ使用できます。
フロントエンドの構成
インターネット NEG バックエンドを使用するロードバランサを作成する場合、特別なフロントエンド構成は必要ありません。転送ルールは、IP アドレス、ポート、プロトコルに基づいてトラフィックをターゲット プロキシに転送するために使用されます。ターゲット プロキシはクライアントからの接続を終端します。また、Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。
また、アプリケーション ロードバランサは、URL マップを使用して、適切なバックエンド サービスへのリクエストの URL ベースの転送を設定します。
これらの各コンポーネントの詳細については、各ロードバランサのアーキテクチャ セクションをご覧ください。
インターネット NEG
インターネット NEG は、ロードバランサの外部バックエンドを定義するために使用されるリソースです。インターネット NEG で参照される外部バックエンドは、インターネット経由でアクセス可能である必要があります。エンドポイントには、Cloud VPN または Cloud Interconnect 経由以外でも接続できる必要があります。外部バックエンドが Google API または Google サービスを参照している場合、サービスは HTTP、HTTPS、または HTTP/2 プロトコルを使用して、TCP ポート 80 か 443 経由で接続可能である必要があります。
NEG によって参照される外部エンドポイントを構成する場合、INTERNET_FQDN_PORT と INTERNET_IP_PORT の 2 つの方法があります。 さらに、これらの各エンドポイントは、グローバルまたはリージョンの 2 つの範囲で使用できます。
グローバル インターネット NEG は、Google Front End（GFE）テクノロジーを基盤としています。すべてのクライアントへの下り（外向き）トラフィックに固定 IP アドレスの固定セットを使用します。サポートされるエンドポイントは、NEG ごとに 1 つ、バックエンド サービスごとに 1 つのみです。
次の表に、さまざまなロードバランサがグローバル インターネット NEG をサポートする方法を示します。
| ロードバランサ | エンドポイントのタイプ | エンドポイントの定義 | スコープ | ヘルスチェック |
|---|---|---|---|---|
|
|
公開で解決可能な完全修飾ドメイン名とオプションのポート。例: ドメイン名は、Google のパブリック DNS インフラストラクチャで解決可能である必要があります。 NEG ごとに使用できるエンドポイントは 1 つだけです。 |
グローバル | 非対応 |
|
パブリック ルーティングが可能な IP アドレスとオプションのポート。例: IP アドレスを RFC 1918 アドレスにすることはできません。 NEG ごとに使用できるエンドポイントは 1 つだけです。 |
† エンドポイントを追加するときにポートを指定しないと、NEG のデフォルト ポートが使用されます。NEG のデフォルト ポートが指定されていない場合は、バックエンド プロトコルの既知のポートが使用されます（HTTP の場合は 80、HTTPS と HTTP/2 の場合は 443）。
リージョン インターネット NEG は、マネージド Envoy プロキシと Cloud NAT ゲートウェイを基盤としています。NEG あたりの複数のエンドポイントと、バックエンド サービスあたりの複数のインターネット NEG をサポートします。クライアントへの下り（外向き）トラフィックに使用される IP アドレスは、Cloud NAT ゲートウェイを使用して構成できます。
次の表に、さまざまなロードバランサがリージョン インターネット NEG をサポートする方法を示します。
| ロードバランサ | エンドポイントのタイプ | エンドポイントの定義 | スコープ | ヘルスチェック |
|---|---|---|---|---|
|
|
公開で解決可能な完全修飾ドメイン名とオプションのポート。例: ドメイン名は、Cloud DNS または Google のパブリック DNS インフラストラクチャによって解決可能である必要があります。 NEG あたりの最大エンドポイント数は 256 です。 |
リージョン | Envoy の分散ヘルスチェック |
|
パブリック ルーティングが可能な IP アドレスとオプションのポート。例: IP アドレスを RFC 1918 アドレスにすることはできません。 NEG あたりの最大エンドポイント数は 256 です。 |
* リージョン インターネット NEG では、ポートを指定する必要があります。デフォルト ポートの指定は、NEG の作成時だけでなく、NEG にエンドポイントを追加するたび行うことができます。エンドポイントを追加するときにポートを指定しないと、NEG のデフォルト ポートが使用されます。
リージョン INTERNET_FQDN_PORT エンドポイントの DNS 解決
ドメインがインターネット経由で解決できる場合は、DNS の設定に他の構成は必要ありません。ただし、プライベート FQDN を解決する場合は、DNS の解決が容易になるように Cloud DNS を構成する必要があります。この名前は Cloud DNS でホストされているか、Cloud DNS からオンプレミス DNS への DNS 転送を使用して解決できる必要があります。
まず、プロジェクトで DNS レコードをホストする Cloud DNS ゾーンを作成します。次に、DNS レコードを追加します。具体的な構成手順については、Cloud DNS のドキュメントをご覧ください。
共有 VPC を使用している場合は、具体的なネットワーク要件に注意してください。転送ゾーンなど、Cloud DNS の他の機能を使用して、オンプレミスの DNS サーバーからレコードを取得することもできます。
グローバル INTERNET_FQDN_PORT エンドポイントの IP アドレスの解決
INTERNET_FQDN_PORT エンドポイントが複数の IP アドレスを返す DNS レコードを指す場合、IP アドレスは次のように解決されます。
ロードバランサは、インターネット上のクライアントに最も近い Google Cloud リージョンの DNS リゾルバを使用します。
INTERNET_FQDN_PORTエンドポイントの DNS レコードがクライアントのロケーションに応じて異なる IP アドレスを返す場合は、ロードバランサが各 IP アドレスにアクセスできることを確認します。ロードバランサは、DNS レスポンスの最初の IP アドレスへの接続を試みます。その IP アドレスに到達できない場合、ロードバランサは HTTP
502 (Bad Gateway)レスポンスを返します。これは、DNS レスポンスからの他の IP アドレスに到達できる場合も当てはまります。
Google の DNS リゾルバ インフラストラクチャで使用される IP 範囲とロケーションの詳細については、Google Public DNS のドキュメントをご覧ください。パブリック DNS システムで解決できない名前は、外部バックエンドとして使用できません。
リージョン INTERNET_FQDN_PORT エンドポイントの IP アドレスの解決
リージョン インターネット NEG は、Cloud DNS と Google のパブリック DNS の両方を使用するドメイン名の解決をサポートしています。パブリック DNS サーバーの場合、Cloud DNS はトラフィックをパブリック DNS サーバーに転送します。
DNS サーバーが複数の IP アドレスを返す場合、Envoy は、構成されたロード バランシング アルゴリズム（ラウンドロビン、最小リクエストなど）に基づいて、返された IP アドレス間でトラフィックをロードバランスします。エンドポイントのリストは、DNS TTL に基づいて定期的に更新されます。再試行ポリシーを構成すると、Envoy で IP アドレスへの接続に失敗した場合に別の IP アドレスへの接続を試行させることができます。
バックエンド サービス
バックエンド サービスは、ロードバランサに構成情報を提供します。ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。
外部バックエンドを使用するロードバランサを設定するには、インターネット NEG バックエンドを使用してバックエンド サービスを構成します。インターネット NEG をバックエンド サービスに追加する場合は、NEG の範囲に応じて次の考慮事項が適用されます。
バックエンド サービスは、他のバックエンド タイプ（ゾーン NEG やインスタンス グループなど）をバックエンドとして使用できません。
バックエンド サービスあたりの NEG 数
- グローバル NEG。バックエンド サービスに追加できるインターネット NEG バックエンドは 1 つだけです。
- リージョン NEG。同じバックエンド サービスに最大 50 個のインターネット NEG を追加できます。
NEG あたりのエンドポイント数
グローバル NEG。インターネット NEG に追加できるエンドポイントは 1 つのみです。
各グローバル インターネット NEG では 1 つのエンドポイントしか使用できないため、ロード バランシングは実際には実行されません。ロードバランサはフロントエンドとしてのみ機能し、トラフィックを指定された外部バックエンドにプロキシします。つまり、レート、接続、使用率などのロード バランシング モードは使用できません。
- リージョン NEG。1 つのバックエンド サービスには、NEG ごとに最大 256 個のエンドポイントを追加できます。
リージョン NEG は、レート、接続、使用率などのロード バランシング モードをサポートしていません。バックエンド サービスに接続されているすべての NEG のすべてのエンドポイントが 1 つのグループにプールされます。このエンドポイントのプール間のロード バランシング トラフィックは、Envoy ロード バランシング アルゴリズムを使用して処理されます。サポートされているロード バランシング ポリシー アルゴリズムについては、リージョン バックエンド サービス API ドキュメントの
localityLbPolicyをご覧ください。ヘルスチェック
- グローバル NEG。バックエンド サービスではヘルスチェックを参照できません。
- リージョン NEG。ロードバランサは、分散 Envoy ヘルスチェックを使用します。
バックエンド サービスのロード バランシング方式は、デプロイするロードバランサが必要とする方式と一致する必要があります。完全なリストについては、バックエンド サービスをご覧ください。
バックエンド サービス プロトコルは、
HTTP、HTTPS、HTTP2のいずれかにする必要があります。インターネット NEG を使用してバックエンド サービスを構成する場合は、プロトコルとして HTTPS または HTTP/2 のいずれかを使用することを強くおすすめします。これにより、ロードバランサとバックエンド間の通信が公共のインターネットで転送される際に、暗号化と認証が行われます。
また、バックエンド プロトコルとして HTTPS または HTTP/2 を使用する場合は、必ず
INTERNET_FQDN_PORTエンドポイントを使用して外部バックエンドを作成してください。これには、2 つの利点があります。ロードバランサは、外部バックエンドによって提示された SSL サーバー証明書を検証し、次の情報が正しいことを確認します。
- 証明書が既知の認証局（CA）によって署名されていること。
- 証明書の有効期限が切れていないこと。
- 証明書の署名が有効であること。
- 構成された FQDN が、証明書内のサブジェクト代替名（SAN）のいずれかと一致すること。
INTERNET_IP_PORTエンドポイントを使用して外部バックエンドを作成した場合、SSL サーバー証明書の検証は行われません。SSL Server Name Indication（SNI）拡張機能は、
INTERNET_FQDN_PORTエンドポイントでのみサポートされています。ロードバランサと外部エンドポイント間の SSL handshake 中の client hello 内で、構成された FQDN が SNI に送信されます。IP アドレス リテラルが SNI ペイロードのHostNameフィールドで許可されないため、SNI はINTERNET_IP_PORTエンドポイントの使用時に送信されません。
ヘルスチェック
ヘルスチェックの構成は、ロードバランサの種類によって異なります。
グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサグローバル インターネット NEG を使用するバックエンド サービスは、ヘルスチェックをサポートしていません。
外部バックエンドにアクセスできない場合、または構成されたホスト名（FQDN）を解決できない場合、ロードバランサは HTTP
502 (Bad Gateway)レスポンスをクライアントに返します。
リージョン外部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、リージョン内部プロキシ ネットワーク ロードバランサヘルスチェックは省略可能です。これらのロードバランサのヘルスチェック プローブは、プロキシ専用サブネットから発信され、Cloud NAT を使用して事前予約した IP アドレスまたは自動で割り振られた NAT IP アドレスに NAT 変換されます。詳細については、リージョン NEG: Cloud NAT ゲートウェイを使用するをご覧ください。
分散 Envoy ヘルスチェックは、一元化されたヘルスチェックと同じ Google Cloud コンソール、gcloud CLI、API プロセスを使用して作成されます。その他の構成は不要です。
注意するポイント:
- gRPC ヘルスチェックはサポートされていません。
- PROXY プロトコル v1 が有効になっているヘルスチェックはサポートされていません。
Envoy データプレーンはヘルスチェックを処理するため、Google Cloud コンソール、API、gcloud CLI を使用して、これらの外部エンドポイントのヘルス ステータスを確認することはできません。Envoy ベースのロードバランサを使用するハイブリッド NEG の場合、Google Cloud コンソールでヘルスチェック ステータスが
N/Aと表示されます。この表示は予期されたものです。VPC ネットワークのリージョン内のプロキシ専用サブネットに割り当てられた Envoy プロキシは、それぞれ独立してヘルスチェックを開始します。そのため、ヘルスチェックが原因でネットワーク トラフィックが増加することがあります。その増加量は、リージョン内の VPC ネットワークに割り当てられた Envoy プロキシの数、これらのプロキシが受信するトラフィックの量、各 Envoy プロキシがヘルスチェックを実行するエンドポイントの数によって異なります。最悪の場合、ヘルスチェックによるネットワーク トラフィックが二次関数的に
(O(n^2))の割合で増加します。分散 Envoy ヘルスチェックのヘルスチェック ログには、ヘルスチェックの詳細な状態が記録されません。記録される内容の詳細については、ヘルスチェックのロギングをご覧ください。Envoy プロキシから NEG エンドポイントへの接続をさらにトラブルシューティングするには、対応するロードバランサのログを確認する必要があります。
外部バックエンドでリクエストを受信する
Google Cloud からのトラフィックを許可するように外部バックエンドを構成します。
この手順は、NEG の範囲（グローバルまたはリージョン）によって異なります。
グローバル NEG: デフォルトの Google 下り（外向き）IP アドレスを許可リストに登録する
グローバル インターネット NEG を使用している場合は、外部バックエンドにリクエストを送信するために Google が使用する IP アドレス範囲を許可リストに追加する必要があります。許可リストに追加する IP アドレスを検索するには、dig や nslookup などのツールを使用して _cloud-eoips.googleusercontent.com DNS TXT レコードをクエリします。
例については、外部バックエンドに Google Cloud からのトラフィックの受信を許可するをご覧ください。
リージョン NEG: Cloud NAT ゲートウェイを使用する
リージョン インターネット NEG を使用する場合は、まず Cloud NAT ゲートウェイを設定して、Google Cloud トラフィックの発信元となる IP アドレス範囲のセットを割り振ります。
ゲートウェイ エンドポイントは ENDPOINT_TYPE_MANAGED_PROXY_LB タイプにする必要があります。
Cloud NAT ゲートウェイは、需要に基づいて外部 IP アドレスを動的に割り振るか、手動で事前予約した外部 IP アドレスのセットを使用するように構成できます。
自動的に割り振られた IP アドレス
外部バックエンド環境でトラフィックを外部バックエンドに送信できる特定の Google Cloud IP アドレスを許可リストに追加する必要がない場合は、自動的に割り振られる IP アドレスを使用します。
手動割り振りの IP アドレス
手動で割り振られた IP アドレスは、外部バックエンド環境で特定の Google Cloud IP アドレスを許可リストに追加する必要がある場合にのみ使用します。プロキシ サブネットに割り当てられた各 Envoy は IP アドレス全体を使用するため、予約済み IP アドレスのプールがすべての Envoy に対応できる十分な大きさであることを確認してください。
大規模な接続の問題が発生した場合は、Cloud NAT の上限に達したかどうかを確認します。デフォルトでは、手動割り振りの NAT IP アドレスはゲートウェイごとに 50 個までです。
この Cloud NAT 構成は、プロキシ専用サブネット全体に適用されます。リージョン内のすべてのリージョン Envoy ベースのロードバランサに関連付けられたインターネット トラフィックは、同じ NAT ゲートウェイを共有します。
Cloud NAT を使用すると、ユーザー トラフィックとヘルスチェック トラフィックの両方で料金が発生します。リージョン インターネット NEG の料金の仕組みについては、リージョン インターネット NEG の料金をご覧ください。
プロキシ専用サブネットに構成された NAT ゲートウェイには、次のような制限があります。
- 1 対 1 の NAT 変換のみが実行されます。IP アドレスの共有はサポートされていません。
- ロギングとモニタリングはサポートされていません。つまり、
--enable-loggingフラグと--log-filterフラグはサポートされていません。 - 静的ポートと動的ポートの割り当て、VM あたりの最大ポート数と最小ポートの設定、エンドポイントに依存しないマッピングなどのポート関連機能はサポートされていません。各プロキシは 65,536 個のポートをすべて取得します。
外部バックエンドへのリクエストを認証する
このセクションは、アプリケーション ロードバランサにのみ適用されます。
外部バックエンドに送信されたリクエストを認証するには、次のいずれかを行います。
カスタム リクエスト ヘッダーを使用して、リクエストが Google Cloud ロードバランサから発行されたことを示すカスタム ヘッダーを設定します。たとえば、16 バイト以上の暗号論的乱数を共有キーとして使用できます。
使用しているロードバランサの種類に応じて、カスタム ヘッダー変換を実装します。
グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサカスタム ヘッダー変換は、バックエンド サービスまたは URL マップで構成できます。
たとえば、HTTP リクエストの
Hostヘッダーに特定の値が想定されるように外部バックエンドを構成し、Hostヘッダーをその値に設定するようにロードバランサを構成できます。カスタム リクエスト ヘッダーを構成しない場合、ロードバランサは、クライアントがロードバランサへの接続に使用したヘッダーを保持し、レスポンスに同じヘッダーを含めます。ただし、Hostヘッダーの変更は URL マップでサポートされていません。Hostヘッダーの構成には、追加の制限があります。詳細については、バックエンド サービスでカスタム ヘッダーを作成するをご覧ください。具体的な例については、外部バックエンドを使用するグローバル外部アプリケーション ロードバランサを設定するをご覧ください。
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサカスタム ヘッダー変換は、URL マップでのみ構成できます。
これらの Envoy ベースのロードバランサの場合、
Hostとauthorityは Google Cloud が予約する特殊なキーワードです。これらのヘッダーは、これらのロードバランサでは変更できません。予約されたヘッダー名が干渉しないように、他のカスタム ヘッダー（MyHostなど）を作成することをおすすめします。
IAP を有効にして、リクエスト ヘッダーの署名済み JWT が Google によって署名されており、ロードバランサが定義されるプロジェクト番号が
aud（オーディエンス）クレームに含まれていることを確認することもできます。次の点にご注意ください。
- IAP には Cloud CDN との互換性がありません。
- IAP は、リージョン外部アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサ（内部と外部）ではサポートされていません。
- 非公開送信元の認証を有効にします。これにより、外部アプリケーション ロードバランサは非公開の Amazon Simple Storage Service（Amazon S3）バケットまたは他の互換性のあるオブジェクト ストアに長期間にわたってアクセスできます。Cloud CDN（非公開送信元の認証）は、リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサではサポートされていません。
ログ
外部バックエンドにプロキシされたリクエストは、他のバックエンドのリクエストと同様の方法で Cloud Logging に記録されます。
詳しくは以下をご覧ください。
外部バックエンドを使用する外部アプリケーション ロードバランサで Cloud CDN を有効にすると、キャッシュ ヒットもログに記録されます。外部バックエンドを使用したヘッダー処理
ロードバランサによって、外部バックエンドへのリクエストをプロキシする際のヘッダー処理が異なる場合があります。ロードバランサのタイプによって HTTP ヘッダーがどのように処理されるかについては、以下の情報を確認してください。
グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサ
グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサが外部バックエンドにリクエストをプロキシすると、HTTP ヘッダーは次のように調整されます。
一部のヘッダーは統合されます。同じヘッダーキー（例:
Via）を持つ複数のインスタンスがある場合は、ロードバランサはそれらの値を 1 つのヘッダーキーを持つ、1 つのカンマ区切りのリストにまとめます。値をカンマ区切りのリストで表すことができるヘッダーのみが統合されます。その他のヘッダー（Set-Cookieなど）は統合されません。バックエンド サービスのプロトコルが
HTTPまたはHTTPSの場合、ヘッダーはプロパーケースで表示されます。ヘッダーのキーの最初の文字とハイフン（
-）の後に続くすべての文字は、HTTP/1.1 クライアントとの互換性を維持するために大文字になります。たとえば、user-agentがUser-Agentに変更され、content-encodingがContent-Encodingに変更されます。Accept-CH（クライアントのヒント）などの特定のヘッダーは、標準の混合文字表現に一致するように変換されます。
いくつかのヘッダーが追加されるか、値が追加されます。外部アプリケーション ロードバランサは常に、特定のヘッダー（
ViaやX-Forwarded-Forなど）を追加または変更します。
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサ
インターネット NEG を使用した Envoy ベースのロードバランサには特別なヘッダー処理はありません。Envoy で通常ヘッダーが処理される方法については、HTTP ヘッダー操作をご覧ください。
制限事項
- インターネット NEG をバックエンドとして構成する際の制限事項については、バックエンド サービスのセクションをご覧ください。
- ロードバランサでバックエンドをインターネット NEG から他のバックエンド タイプに変更したり、バックエンドを他のバックエンド タイプからインターネット NEG に変更すると、アプリケーションに一時的にダウンタイムが発生します（約 30～90 秒）。
たとえば、このダウンタイム中に、クライアントがグローバル外部アプリケーション ロードバランサにリクエストを送信すると、エラーコード
failed_to_connect_to_backendを含む502エラーが表示されます。これは想定された動作です。
- 次の高度なトラフィック管理機能は、グローバル インターネット NEG バックエンドではサポートされていません。
- リクエストのミラーリング
- 再試行ポリシー
- トラフィック ポリシー（ロード バランシングの局所性ポリシー、セッション アフィニティ、外れ値検出など）
- プロキシ専用サブネットに構成された NAT ゲートウェイに関する制限については、Cloud NAT ゲートウェイのセクションをご覧ください。
割り当てと上限
割り当てと上限については、NEG バックエンドの割り当ての表と NEG ごとのエンドポイント数をご覧ください。
料金
外部インターネット NEG エンドポイントへの下り（外向き）トラフィックは、プレミアム ティア ネットワークのインターネット下り（外向き）レートで課金されます。送信元はクライアントのロケーションに基づき、宛先は公開エンドポイントのロケーションに基づきます。
リージョン Envoy ベースのロードバランサのプロキシ専用サブネットをマッピングするように Cloud NAT ゲートウェイを構成した場合、Cloud NAT の料金が発生します。ロードバランサに割り振られた Cloud NAT ゲートウェイには、32 個を超える VM インスタンスが存在するネットワークに相当する 1 時間単位の料金が発生します。詳細については、Cloud NAT の料金をご覧ください。
詳細については、Cloud Load Balancing の料金をご覧ください。
次のステップ
- インターネット NEG を使用してグローバル外部アプリケーション ロードバランサを設定する。
- インターネット NEG を使用して従来のアプリケーション ロードバランサを設定する。
- 外部バックエンドを使用する外部アプリケーション ロードバランサに Cloud CDN を設定する。
- インターネット ネットワーク エンドポイント グループを使用する Cloud Service Mesh の概要。