外部アプリケーション ロードバランサの概要

このドキュメントでは、外部アプリケーション ロードバランサの構成方法を理解するために必要なコンセプトについて説明します。

外部アプリケーション ロードバランサは、プロキシベースのレイヤ 7 ロードバランサで、これを使用すると単一の外部 IP アドレスの背後でサービスを実行し、スケーリングできるようになります。外部アプリケーション ロードバランサは、さまざまな Google Cloud プラットフォーム（Compute Engine、Google Kubernetes Engine（GKE）、Cloud Storage など）でホストされているバックエンドや、インターネットまたはハイブリッド接続を介して接続された外部バックエンドに、HTTP / HTTPS のトラフィックを分散します。詳細については、アプリケーション ロードバランサの概要: ユースケースをご覧ください。

運用モード

外部アプリケーション ロードバランサは、次のモードで構成できます。

• グローバル外部アプリケーション ロードバランサ。これは、Google Front End（GFE）でマネージド サービスとして実装されるグローバル ロードバランサです。オープンソースの Envoy プロキシを使用して、トラフィックのミラーリング、重み付けに基づくトラフィック分割、リクエスト/レスポンス ベースのヘッダー変換など、高度なトラフィック管理機能をサポートします。
• 従来のアプリケーション ロードバランサ。これは、従来の外部アプリケーション ロードバランサで、プレミアム ティアではグローバルですが、スタンダード ティアではリージョンとして構成できます。このロードバランサは、Google Front End（GFE）に実装されます。GFE はグローバルに分散しており、Google のグローバル ネットワークとコントロール プレーンを使用して連携します。
• リージョン外部アプリケーション ロードバランサ。これは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるリージョン ロードバランサです。これには、トラフィックのミラーリング、重み付けベースのトラフィック分割、リクエスト / レスポンス ベースのヘッダー変換など、高度なトラフィック管理機能が含まれています。

モードを特定する

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

アーキテクチャ

外部アプリケーション ロードバランサのデプロイには、次のリソースが必要です。

• リージョン外部アプリケーション ロードバランサに関してのみ、プロキシ専用サブネットは、ロードバランサからバックエンドに接続を伝えるために使用されます。

• 外部転送ルールでは、外部 IP アドレス、ポート、ターゲット HTTP(S) プロキシを指定します。クライアントは、IP アドレスとポートを使用してロードバランサに接続します。

• ターゲット HTTP(S) プロキシでは、クライアントからのリクエストを受信します。HTTP(S) プロキシは、URL マップを使用してリクエストを評価し、トラフィックの転送を決定します。プロキシは、SSL 証明書を使用して通信の認証を行うこともできます。

  • HTTPS ロード バランシングの場合は、ターゲット HTTPS プロキシが SSL 証明書を使用して、クライアントに ID を提供します。ターゲット HTTP(S) プロキシは、最大でドキュメントに記載されている数の SSL 証明書をサポートします。

• HTTP(S) プロキシは、URL マップを使用し、HTTP 属性（リクエストパス、Cookie、ヘッダーなど）に基づいて転送を判断します。この転送の判断に基づいて、プロキシは特定のバックエンド サービスやバックエンド バケットにクライアントのリクエストを転送します。URL マップでは、クライアントにリダイレクトを送信するなど、追加のアクションを指定できます。

• バックエンド サービスは、正常なバックエンドにリクエストを分散します。 グローバル外部アプリケーション ロードバランサは、バックエンド バケットもサポートしています。1 つ以上のバックエンドをバックエンド サービスまたはバックエンド バケットに接続する必要があります。

• バックエンドの準備状況は、ヘルスチェックで、定期的に監視されます。これにより、処理不能なバックエンドにリクエストが送信されるリスクを軽減できます。

• バックエンドがヘルスチェック プローブを受け入れるためのファイアウォール ルール。リージョン外部アプリケーション ロードバランサには、プロキシ専用サブネットからのトラフィックがバックエンドに到達できるように、追加のファイアウォール ルールが必要です。

グローバル

この図は、グローバル外部アプリケーション ロードバランサのデプロイのコンポーネントを示しています。このアーキテクチャは、グローバル外部アプリケーション ロードバランサと、プレミアム ティアの従来のアプリケーション ロードバランサの両方に適用されます。

リージョン

この図は、リージョン外部アプリケーション ロードバランサのデプロイのコンポーネントを示しています。

プロキシ専用サブネット

プロキシ専用サブネットは、リージョン外部アプリケーション ロードバランサにのみ必要です。

プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。リージョン外部アプリケーション ロードバランサを使用する VPC ネットワークの各リージョンに、プロキシ専用サブネットを 1 つ作成する必要があります。このプロキシ専用サブネットの --purpose フラグは REGIONAL_MANAGED_PROXY に設定されています。同じリージョンと VPC ネットワーク内にあるすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットの Envoy プロキシのプールを共有します。さらに、

• プロキシ専用サブネットは Envoy プロキシにのみ使用され、バックエンドには使用されません。
• リージョンと VPC ネットワーク内のすべてのリージョン外部アプリケーション ロードバランサのバックエンド VM またはエンドポイントは、プロキシ専用サブネットからの接続を受信します。
• リージョン外部アプリケーション ロードバランサの IP アドレスは、プロキシ専用サブネットにはありません。ロードバランサの IP アドレスは、後述する外部マネージド転送ルールで定義します。

以前に --purpose=INTERNAL_HTTPS_LOAD_BALANCER でプロキシ専用サブネットを作成した場合は、VPC ネットワークと同じリージョンに他の Envoy ベースのロードバランサを作成する前に、REGIONAL_MANAGED_PROXY にサブネットの目的を移行する必要があります。

転送ルールと IP アドレス

転送ルールは、IP アドレス、ポート、プロトコルに基づいて、ターゲット プロキシ、URL マップ、1 つ以上のバックエンド サービスからなるロード バランシング構成にトラフィックを転送します。

IP アドレスの指定。各転送ルールでは、アプリケーションの DNS レコードで使用できる単一の IP アドレスを指定します。DNS ベースのロード バランシングは必要ありません。使用する IP アドレスを自分で指定することも、Cloud Load Balancing で割り当てられる IP アドレスを使用することもできます。

ポートの指定。アプリケーション ロードバランサの転送ルールでは、1～65535 の単一ポートを参照できます。複数のポートをサポートするには、複数の転送ルールを構成する必要があります。IP アドレス、ポート、プロトコルの組み合わせが各転送ルールで一意である限り、複数の転送ルールを構成して、同じ外部 IP アドレス（VIP）を使用し、同じターゲット HTTP(S) プロキシを参照できます。これにより、共有 URL マップを持つ単一のロードバランサを複数のアプリケーションのプロキシとして使用できます。

外部アプリケーション ロードバランサが使用する転送ルール、IP アドレス、ロード バランシング スキームのタイプは、ロードバランサのモードやロードバランサがどのネットワーク サービス ティアに属しているかによって異なります。

各モードの外部アプリケーション ロードバランサ転送ルールでサポートされるプロトコルの完全な一覧については、ロードバランサの機能をご覧ください。

転送ルールと VPC ネットワーク

このセクションでは、外部アプリケーション ロードバランサで使用される転送ルールを VPC ネットワークに関連付ける方法について説明します。

ターゲット プロキシ

ターゲット プロキシは、クライアントからの HTTP(S) 接続を終端します。1 つ以上の転送ルールがトラフィックをターゲット プロキシに転送し、ターゲット プロキシが URL マップを参照してバックエンドにトラフィックを転送する方法を決定します。

プロキシでは、リクエストまたはレスポンスのヘッダー名の大文字と小文字の区別の保持が保証されません。たとえば、Server: Apache/1.0 レスポンス ヘッダーはクライアントで server: Apache/1.0 として表示される場合があります。

次の表に、外部アプリケーション ロードバランサが必要とするターゲット プロキシのタイプを示します。

ロードバランサは、ターゲット プロキシによって追加されたヘッダーに加えて、次の方法で他の HTTP ヘッダーを調整します。

• グローバル外部アプリケーション ロードバランサの場合、リクエスト ヘッダーとレスポンス ヘッダーの両方が小文字に変換されることがあります。

  唯一の例外は、HTTP/1.1 でグローバル インターネット NEG バックエンドを使用する場合です。グローバル インターネット NEG による HTTP/1.1 ヘッダーの処理方法の詳細については、インターネット NEG の概要をご覧ください。

• 従来のアプリケーション ロードバランサの場合、HTTP/1.1 を使用する場合を除き、リクエスト ヘッダーとレスポンス ヘッダーは小文字に変換されます。それに対し、HTTP/1.1 では、ヘッダーの大文字と小文字は適切に変換されます。ヘッダーのキーの最初の文字とハイフン（-）の後に続くすべての文字は、HTTP/1.1 クライアントとの互換性を維持するため大文字になります。たとえば、user-agent が User-Agent に変更され、content-encoding が Content-Encoding に変更されます。

• 一部のヘッダーは統合されます。同じヘッダーキー（例: Via）を持つ複数のインスタンスがある場合は、ロードバランサはそれらの値を 1 つのヘッダーキーを持つ、1 つのカンマ区切りのリストにまとめます。値をカンマ区切りのリストで表すことができるヘッダーのみが統合されます。 その他のヘッダー（Set-Cookie など）が結合されることはありません。

Host ヘッダー

ロードバランサが HTTP リクエストを行うと、ロードバランサは元のリクエストの Host ヘッダーを保持します。

X-Forwarded-For ヘッダー

ロードバランサは、1 つのカンマで区切られた 2 つの IP アドレスを次の順序で X-Forwarded-For ヘッダーに追加します。

• ロードバランサに接続するクライアントの IP アドレス
• ロードバランサの転送ルールの IP アドレス

受信リクエストに X-Forwarded-For ヘッダーがない場合は、この 2 つの IP アドレスがヘッダー全体の値になります。

X-Forwarded-For: <client-ip>,<load-balancer-ip>

リクエストに X-Forwarded-For ヘッダーが含まれている場合、ロードバランサは、指定された値を <client-ip>,<load-balancer-ip> の前に置きます。

X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>

ロードバランサのバックエンドで HTTP リバース プロキシ ソフトウェアを実行すると、ソフトウェアが X-Forwarded-For ヘッダーの末尾に次の IP アドレスのいずれかまたは両方を追加します。

• バックエンドに接続されている Google Front End（GFE）の IP アドレス。これらの IP アドレスの範囲は 130.211.0.0/22 と 35.191.0.0/16 です。

• バックエンド システム自体の IP アドレス

したがって、ロードバランサのバックエンドの後のアップストリーム プロセスは、次の形式の X-Forwarded-For ヘッダーを受け取る可能性があります。

<existing-values>,<client-ip>,<load-balancer-ip>,<GFE-IP>,<backend-IP>

Cloud Trace のサポート

トレース機能は、アプリケーション ロードバランサではサポートされていません。グローバル アプリケーション ロードバランサと従来のアプリケーション ロードバランサは、X-Cloud-Trace-Context ヘッダーが存在しない場合、そのヘッダーを追加します。リージョン外部アプリケーション ロードバランサは、このヘッダーを追加しません。X-Cloud-Trace-Context ヘッダーがすでに存在する場合、変更されていない状態でロードバランサを通過します。ただし、ロードバランサによってトレースまたはスパンはエクスポートされません。

URL マップ

URL マップは、URL に基づいてリクエストが適切なバックエンド サービスにルーティングされる際に使用される一致パターンを定義します。URL マップを使用すると、URL コンポーネントを調べてトラフィックを分割し、リクエストを一連のさまざまなバックエンドに送信できます。デフォルトのバックエンド サービスは、指定されたホストルールまたはパスのマッチング ルールに一致しないリクエストを処理するように定義されています。

マルチリージョン ロード バランシングの例など、URL ルールを定義せず、デフォルトのサービスのみに依存する場合があります。

URL マップは、ヘッダーベースのトラフィック ステアリング、重み付けベースのトラフィック分割、リクエスト ミラーリングなどの高度なトラフィック管理機能をサポートしています。詳しくは以下をご覧ください。

• グローバル外部アプリケーション ロードバランサのトラフィック管理の概要

• リージョン外部アプリケーション ロードバランサのトラフィック管理の概要

次の表では、各モードで外部アプリケーション ロードバランサが必要とする URL マップのタイプを示します。

SSL 証明書

ターゲット HTTPS プロキシを使用する外部アプリケーション ロードバランサには、ロードバランサの構成の一部として秘密鍵と SSL 証明書が必要です。

• Google Cloud には、秘密鍵と SSL 証明書をターゲット HTTPS プロキシに割り当てるための構成方法が 2 つあります。1 つは Compute Engine SSL 証明書、もう 1 つは証明書マネージャーです。各構成の詳細については、SSL 証明書の概要で証明書の構成方法をご覧ください。

• Google Cloud では、セルフマネージドと Google マネージドの 2 種類の証明書タイプが用意されています。各タイプの詳細については、SSL 証明書の概要で証明書のタイプをご覧ください。

外部アプリケーション ロードバランサのタイプ（グローバル、リージョン、従来）により、サポートされている構成方法と証明書タイプが決まります。詳細については、SSL 証明書の概要で証明書と Google Cloud ロードバランサをご覧ください。

SSL ポリシー

SSL ポリシーでは、Google Cloud ロードバランサがクライアントと SSL のネゴシエートするときに使用する一連の SSL 機能を指定します。

デフォルトでは、HTTPS ロード バランシングは、優れたセキュリティと幅広い互換性を提供する一連の SSL 機能を使用します。アプリケーションの中には、HTTPS または SSL 接続に使用される SSL のバージョンおよび暗号をより詳細に管理しなければならないものがあります。SSL ポリシーを定義して、ロードバランサがクライアントと SSL をネゴシエートする際に使用する一連の SSL 機能を指定できます。また、その SSL ポリシーをターゲット HTTPS プロキシに適用できます。

次の表では、各モードでのロードバランサに対する SSL ポリシーのサポートを示します。

バックエンド サービス

バックエンド サービスは、ロードバランサに構成情報を提供して、Compute Engine インスタンス グループやネットワーク エンドポイント グループ（NEG）などのバックエンドにリクエストを転送できるようにします。バックエンド サービスの詳細については、バックエンド サービスの概要をご覧ください。

バックエンド サービスと Compute Engine バックエンドを使用してロードバランサを設定する方法の例については、Compute Engine バックエンドを使用した外部アプリケーション ロードバランサの設定をご覧ください。

バックエンド サービスのスコープ

次の表に、外部アプリケーション ロードバランサで使用されるバックエンド サービス リソースとスコープを示します。

バックエンドへのプロトコル

アプリケーション ロードバランサのバックエンド サービスは、次のいずれかのプロトコルを使用してバックエンドにリクエストを送信する必要があります。

• HTTP: HTTP/1.1 を使用し、TLS は使用しません。
• HTTPS: HTTP/1.1 と TLS を使用
• HTTP/2: HTTP/2 と TLS を使用します（暗号化なしの HTTP/2 はサポートされていません）。

ロードバランサは、バックエンドとの通信に指定したバックエンド サービス プロトコルのみを使用します。指定されたバックエンド サービス プロトコルを使用してバックエンドと通信できない場合、ロードバランサは別のプロトコルにフォールバックしません。

バックエンド サービス プロトコルは、クライアントがロードバランサとの通信に使用するプロトコルと一致する必要はありません。たとえば、クライアントは HTTP/2 を使用してロードバランサにリクエストを送信できますが、ロードバランサは HTTP/1.1（HTTP または HTTPS）を使用してバックエンドと通信できます。

バックエンド バケット

バックエンド バケットは、Cloud Storage バケットに着信トラフィックを振り向けます。バケットを外部アプリケーション ロードバランサに追加する方法の例については、バックエンド バケットを使用したロードバランサの設定をご覧ください。Cloud Storage の一般的な情報については、Cloud Storage とはをご覧ください。

バックエンド

次の表に、各モードで外部アプリケーション ロードバランサがサポートするバックエンドと関連機能を示します。

バックエンドと VPC ネットワーク

バックエンドを配置するロケーションの制限は、ロードバランサの種類によって異なります。

グローバル外部アプリケーション ロードバランサのバックエンドの場合、次のことが適用されます。

• バックエンド インスタンス（インスタンス グループ バックエンドの場合）とバックエンド エンドポイント（NEG バックエンドの場合）は、同じ組織内の任意の VPC ネットワークに配置できます。GFE はそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを VPC ネットワーク ピアリングで接続する必要はありません。

• Cloud Storage バケットは VPC ネットワークに関連付けられていません。これらのリソースは、同じ組織内の任意のプロジェクトに配置できます。

  グローバル外部アプリケーション ロードバランサは、共有 VPC 環境もサポートしています。この環境では、VPC ネットワークとその関連リソースをプロジェクト間で共有できます。ただし、グローバル外部アプリケーション ロードバランサの場合、組織内の他のプロジェクトのバックエンド サービスまたはバックエンド バケットを参照できるように共有 VPC を構成する必要はありません。

従来のアプリケーション ロードバランサのバックエンドの場合は、次のようになります。

• インスタンス グループ バックエンドのすべてのバックエンド インスタンスと NEG バックエンドのすべてのバックエンド エンドポイントは、同じプロジェクトに配置する必要があります。ただし、インスタンス グループのバックエンドまたは NEG は、そのプロジェクトの別の VPC ネットワークを使用できます。GFE はそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを VPC ネットワーク ピアリングで接続する必要はありません。

• Cloud Storage バケットは VPC ネットワークに関連付けられていません。ただし、ロードバランサと同じプロジェクトに配置する必要があります。

リージョン外部アプリケーション ロードバランサのバックエンドの場合、次のようになります。

• インスタンス グループ、ゾーン NEG、ハイブリッド接続 NEG の場合、すべてのバックエンドはバックエンド サービスと同じプロジェクトとリージョンに配置する必要があります。ただし、ロードバランサは、バックエンド サービスと同じプロジェクトで別の VPC ネットワークを使用するバックエンドを参照できます（この機能はプレビュー版です）。 ロードバランサの VPC ネットワークとバックエンド VPC ネットワーク間の接続は、VPC ネットワーク ピアリング、Cloud VPN トンネル、Cloud Interconnect VLAN アタッチメント、または Network Connectivity Center フレームワークを使用して構成できます。

  バックエンド ネットワークの定義

  • ゾーン NEG とハイブリッド NEG の場合、NEG の作成時に VPC ネットワークを明示的に指定します。
  • マネージド インスタンス グループの場合、VPC ネットワークはインスタンス テンプレートで定義されます。
  • 非マネージド インスタンス グループの場合、インスタンス グループの VPC ネットワークは、インスタンス グループに追加された最初の VM の nic0 インターフェースの VPC ネットワークと一致するように設定されます。

  バックエンド ネットワークの要件

  バックエンド ネットワークは、次のいずれかのネットワーク要件を満たしている必要があります。

  • バックエンドの VPC ネットワークは、転送ルールの VPC ネットワークと完全に一致する必要があります。

  • バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの VPC ネットワークに接続する必要があります。転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可するには、サブネット ルート交換を構成する必要があります。

• バックエンドの VPC ネットワークと転送ルールの VPC ネットワークは、同じ Network Connectivity Center ハブの VPC スポークである必要があります。インポート フィルタとエクスポート フィルタでは、転送ルールの VPC ネットワークのプロキシ専用サブネットと、バックエンド インスタンスまたはエンドポイントで使用されるサブネットとの通信を許可する必要があります。

• 他のすべてのバックエンド タイプの場合、すべてのバックエンドを同じ VPC ネットワークとリージョンに配置する必要があります。

  リージョン外部アプリケーション ロードバランサは、VPC ネットワークとその関連リソースをプロジェクト間で共有できる共有 VPC 環境もサポートしています。リージョン外部アプリケーション ロードバランサのバックエンド サービスとバックエンドを転送ルールとは異なるプロジェクトに配置する場合は、プロジェクト間のサービス参照を使用した共有 VPC 環境でロードバランサを構成する必要があります。

バックエンドとネットワーク インターフェース

インスタンス グループのバックエンドを使用する場合、パケットは常に nic0 に配信されます。別の NIC にパケットを送信する場合は、NEG バックエンドを使用します。

ゾーン NEG バックエンドを使用する場合、パケットは NEG のエンドポイントで表されるネットワーク インターフェースに送信されます。NEG エンドポイントは、NEG に明示的に定義された VPC ネットワークと同じ VPC ネットワークに存在する必要があります。

ヘルスチェック

各バックエンド サービスは、ロードバランサからの接続を受信するバックエンドの稼働状況を定期的に監視するヘルスチェックを指定します。これにより、処理不能なバックエンドにリクエストを送信するリスクが軽減されます。ヘルスチェックでは、アプリケーション自体が動作するかどうかはチェックされません。

ヘルスチェック プローブでは、上り（内向き）許可ファイアウォール ルールを作成してヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。通常、ヘルスチェック プローブは Google の一元化されたヘルスチェックの仕組みにより発信されます。

このルールの 1 つの例外は、ハイブリッド NEG バックエンドを使用するリージョン外部アプリケーション ロードバランサです。これは、ヘルスチェックがプロキシ専用サブネットから発信されるためです。詳しくは、ハイブリッド NEG の概要をご覧ください。

ヘルスチェック プロトコル

必須ではなく、常に可能というわけでもありませんが、バックエンド サービスのプロトコルに一致するプロトコルでのヘルスチェックを使用することをおすすめします。たとえば、バックエンドに対する HTTP/2 の接続性を最も正確にテストできるのは HTTP/2 ヘルスチェックです。一方、ハイブリッド NEG バックエンドを使用するリージョン外部アプリケーション ロードバランサは、gRPC ヘルスチェックをサポートしていません。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。

次の表に、各モードで外部アプリケーション ロードバランサによってサポートされているヘルスチェックのスコープを示します。

ヘルスチェックの詳細については、以下をご覧ください。

• ヘルスチェックの概要
• ヘルスチェックの作成

ファイアウォール ルール

ロードバランサには、次のファイアウォール ルールが必要です。

• グローバル外部アプリケーション ロードバランサの場合、上り（内向き）許可ルールによって、バックエンドに到達するように Google Front End（GFE）からのトラフィックが許可されます。 リージョン外部アプリケーション ロードバランサの場合、上り（内向き）許可ルールによって、バックエンドに到達するようにプロキシ専用サブネットからのトラフィックが許可されます。
• ヘルスチェック プローブ範囲からのトラフィックを許可する上り（内向き）許可ルール。ヘルスチェック プローブの詳細と、プローブからのトラフィックを許可する必要がある理由については、プローブ IP 範囲とファイアウォール ルールをご覧ください。

ファイアウォール ルールは GFE プロキシではなく、VM インスタンス レベルで実装されます。Google Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。 グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、Google Cloud Armor を使用してこれを実現できます。

これらのファイアウォール ルールのポートは、次のように構成する必要があります。

• 各バックエンド サービスのヘルスチェックのための宛先ポートへのトラフィックを許可する。

• インスタンス グループのバックエンドの場合: バックエンド サービスの名前付きポートと、各インスタンス グループの名前付きポートに関連付けられたポート番号とのマッピングによって、構成するポートを決定します。同じバックエンド サービスに割り当てられたインスタンス グループ間でポート番号が異なる可能性があります。

• GCE_VM_IP_PORT NEG バックエンドの場合: エンドポイントのポート番号へのトラフィックを許可します。

次の表は、ファイアウォール ルールに必要な送信元 IP アドレス範囲をまとめたものです。

GKE サポート

GKE は、外部アプリケーション ロードバランサを次のように使用します。

• GKE Gateway コントローラを使用して作成された外部 Gateway は、外部アプリケーション ロードバランサの任意のモードを使用できます。ロードバランサのモードは、GatewayClass を選択して制御します。GKE Gateway コントローラは常に GCE_VM_IP_PORT ゾーン NEG バックエンドを使用します。

• GKE Ingress コントローラを使用して作成された外部 Ingress は、常に従来のアプリケーション ロードバランサです。GKE Ingress コントローラは、GCE_VM_IP_PORT ゾーン NEG バックエンドを使用することを優先しますが、インスタンス グループ バックエンドもサポートされています。

• GKE Services によって作成および管理される GCE_VM_IP_PORT ゾーン NEG を、アプリケーション ロードバランサまたはプロキシ ネットワーク ロードバランサのバックエンドとして使用できます。詳細については、スタンドアロン ゾーン NEG によるコンテナ ネイティブのロード バランシングをご覧ください。

共有 VPC アーキテクチャ

外部アプリケーション ロードバランサは、共有 VPC を使用するネットワークをサポートします。組織は、共有 VPC を使用して複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるため、そのネットワークの内部 IP アドレスを使用して、安全で効率的な相互通信を行うことができます。共有 VPC についてまだよく理解していない場合は、共有 VPC の概要をご覧ください。

共有 VPC ネットワーク内で外部アプリケーション ロードバランサを構成するには、多くの方法があります。デプロイの種類に関係なく、ロードバランサのすべてのコンポーネントを同じ組織に配置する必要があります。

共有 VPC ホスト プロジェクトですべてのロード バランシング コンポーネントとバックエンドを作成できますが、このタイプのデプロイではネットワーク管理とサービス開発の責任が分離されません。

サービス プロジェクト内のすべてのロードバランサ コンポーネントとバックエンド

次のアーキテクチャ図は、すべてのロードバランサのコンポーネントとバックエンドがサービス プロジェクト内にある標準の共有 VPC デプロイを示しています。このデプロイタイプは、すべてのアプリケーション ロードバランサでサポートされています。

ロードバランサのコンポーネントとバックエンドは同じ VPC ネットワークを使用する必要があります。

共有 VPC 環境におけるサーバーレス バックエンド

サーバーレス NEG バックエンドを使用しているロードバランサの場合、バックエンドの Cloud Run または Cloud Run 関数サービスはサーバーレス NEG と同じプロジェクトに存在する必要があります。

また、プロジェクト間のサービス参照をサポートするリージョン外部アプリケーション ロードバランサの場合、バックエンド サービス、サーバーレス NEG、Cloud Run サービスは常に同じサービス プロジェクトに存在する必要があります。

プロジェクト間のサービス参照

プロジェクト間サービス参照は、ロードバランサのフロントエンドと URL マップが 1 つのプロジェクトにあり、ロードバランサのバックエンド サービスとバックエンドが別のプロジェクトにあるデプロイモデルです。

プロジェクト間のサービス参照を使用すると、組織は 1 つの一元的なロードバランサを構成し、複数の異なるプロジェクトに分散された数百のサービスにトラフィックをルーティングできます。トラフィック ルーティングのルールおよびポリシーはすべて、1 つの URL マップで集中管理できます。ロードバランサをホスト名と SSL 証明書の組み合わせの 1 つと関連付けることもできます。このため、アプリケーションのデプロイに必要なロードバランサの数を最適化することで、管理性の向上や、運用費および必要な割り当て量の削減につながります。

さらに、プロジェクトを部門ごとに分けて、組織内のロールを分離することもできます。サービス オーナーはサービス プロジェクト内のサービス構築に、ネットワーク チームは別のプロジェクト内のロードバランサのプロビジョニングおよび維持に専念できます。これらのプロジェクトは、プロジェクト間のサービス参照によって接続できます。

サービス オーナーは、サービスの公開に対する自律性を維持し、ロードバランサを介してサービスにアクセスできるユーザーを制御できます。この仕組みは、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）という特別な IAM ロールによって実現されます。

プロジェクト間のサービス参照のサポートは、ロードバランサのタイプによって異なります。

• グローバル外部アプリケーション ロードバランサの場合、ロードバランサのフロントエンドと URL マップは、同じ組織内の任意のプロジェクトのバックエンド サービスまたはバックエンド バケットを参照できます。VPC ネットワークの制限は適用されません。この例に示すように、共有 VPC 環境を使用してプロジェクト間のデプロイを構成できますが、これは必須ではありません。

• リージョン外部アプリケーション ロードバランサの場合は、共有 VPC 環境でロードバランサを作成する必要があります。ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに配置する必要があります。ロードバランサのバックエンド サービスとバックエンドは、同じ共有 VPC 環境内のホスト プロジェクトまたはサービス プロジェクトに分散できます。

リージョン外部アプリケーション ロードバランサの共有 VPC を構成する方法については（プロジェクト間のサービス参照の有無にかかわらず）、共有 VPC を使用したリージョン外部アプリケーション ロードバランサを設定するをご覧ください。

プロジェクト間のサービス参照に関する既知の制限事項

• プロジェクト間のサービス参照は、インスタンス グループ、サーバーレス NEG、サポートされている他のほとんどのバックエンド タイプで使用できます。ただし、次の制限が適用されます。

  • グローバル外部アプリケーション ロードバランサでは、バックエンド サービスに App Engine のサーバーレス NEG バックエンドがある場合、プロジェクト間のバックエンド サービスを参照できません。

  • 外部リージョン アプリケーション ロードバランサの場合、バックエンド サービスがリージョン インターネット NEG バックエンドを使用していると、プロジェクト間のバックエンド サービスを参照することはできません。
• 従来のアプリケーション ロードバランサでは、プロジェクト間のサービス参照はサポートされていません。
• Google Cloud では、複数のプロジェクトで同じ名前を使用するリソース（バックエンド サービスなど）は区別されません。したがって、プロジェクト間のサービス参照を使用する場合は、組織内のプロジェクト間で一意のバックエンド サービス名を使用することをおすすめします。

例 1: ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する

次の共有 VPC デプロイの例では、ロードバランサのフロントエンドと URL マップがサービス プロジェクト A に作成され、URL マップはサービス プロジェクト B のバックエンド サービスを参照しています。

この場合、サービス プロジェクト A のネットワーク管理者またはロードバランサ管理者は、サービス プロジェクト B のバックエンド サービスにアクセスする必要があります。サービス プロジェクト B の管理者は、サービス プロジェクト B のバックエンド サービスを参照するサービス プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。

例 2: ホスト プロジェクト内のロードバランサのフロントエンドと、サービス プロジェクトのバックエンド

次の例は、ロードバランサのフロントエンドと URL マップがホスト プロジェクトに作成され、バックエンド サービス（とバックエンド）がサービス プロジェクトに作成される共有 VPC デプロイの例です。

この場合、ホスト プロジェクトのネットワーク管理者またはロードバランサ管理者は、サービス プロジェクトのバックエンド サービスにアクセスする必要があります。サービス プロジェクトの管理者は、サービス プロジェクトのバックエンド サービスを参照するホスト プロジェクト A のロードバランサ管理者に compute.loadBalancerServiceUser IAM ロールを付与します。

例 3: ロードバランサのフロントエンドとバックエンドが異なるプロジェクトにある

次のデプロイの例では、グローバル外部アプリケーション ロードバランサのフロントエンドと URL マップが、ロードバランサのバックエンド サービスとバックエンドとは異なるプロジェクトに作成されています。このタイプのデプロイは共有 VPC を使用しません。グローバル外部アプリケーション ロードバランサでのみサポートされます。

接続の仕組み

グローバル外部アプリケーション ロードバランサの接続

グローバル外部アプリケーション ロードバランサは、Google Front End（GFE）と呼ばれる多くのプロキシによって実装されます。プロキシは 1 つではありません。プレミアム ティアでは、同じグローバル外部 IP アドレスがさまざまな拠点からアドバタイズされ、クライアントのリクエストは、クライアントの最も近い GFE に送信されます。

クライアントがいる場所に応じて、複数の GFE がバックエンドへの HTTP(S) 接続を開始できます。GFE から送信されたパケットには、ヘルスチェック プローバーが使用するものと同じ範囲（35.191.0.0/16 と 130.211.0.0/22）の送信元 IP アドレスがあります。

バックエンド サービスの構成に応じて、各 GFE がバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP または HTTPS 接続の場合、使用される HTTP バージョンは HTTP 1.1 です。

HTTP キープアライブは、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。HTTP キープアライブは、同じ TCP セッションを効率的に使用しようとしますが、保証はありません。GFE は、クライアント HTTP キープアライブ タイムアウト（610 秒）とデフォルトのバックエンド キープアライブ タイムアウト値（600 秒）を使用します。クライアント HTTP キープアライブ タイムアウトは更新できますが、バックエンド キープアライブ タイムアウト値は固定されています。バックエンド サービスのタイムアウトを設定することで、リクエスト / レスポンスのタイムアウトを構成できます。HTTP キープアライブと TCP アイドル タイムアウトは密接に関連していますが、同じではありません。詳しくは、タイムアウトと再試行をご覧ください。

トラフィックのロード バランシングを均等に行うために、ロードバランサは、Connection: close ヘッダーを含むレスポンスの完了後に FIN ACK パケットを送信して TCP 接続を完全に閉じるか、レスポンスの完了後に HTTP/2 GOAWAY フレームを発行する場合があります。この動作により、アクティブなリクエストやレスポンスが妨げられることはありません。

HTTP 接続と TCP セッションの数は、GFE の接続数、GFE に接続するクライアントの数、バックエンドへのプロトコル、バックエンドのデプロイ場所によって異なります。

詳細については、ソリューション ガイドの外部アプリケーション ロードバランサの仕組みでグローバル ロード バランシングによるアプリケーション容量の最適化をご覧ください。

リージョン外部アプリケーション ロードバランサの接続

リージョン外部アプリケーション ロードバランサは、Envoy プロキシに実装されたマネージド サービスです。リージョン外部アプリケーション ロードバランサは、プロキシ専用サブネットという共有サブネットを使用して、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスをプロビジョニングします。このプロキシ専用サブネットの --purpose フラグは REGIONAL_MANAGED_PROXY に設定されています。特定のネットワークとリージョン内のリージョン Envoy ベースのロードバランサはすべて、このサブネットを共有します。

クライアントは、ロードバランサの IP アドレスとポートを使用してロードバランサに接続します。クライアント リクエストは、クライアントと同じリージョン内のプロキシ専用サブネットに転送されます。ロードバランサは、クライアント リクエストを終了して、プロキシ専用サブネットからバックエンドへの新しい接続を開きます。したがって、ロードバランサから送信されたパケットには、プロキシ専用サブネットからの送信元 IP アドレスがあります。

バックエンド サービスの構成に応じて、Envoy プロキシがバックエンドに接続するために使用するプロトコルは HTTP、HTTPS、HTTP/2 のいずれかになります。HTTP または HTTPS の場合の HTTP バージョンは HTTP 1.1 です。HTTP キープアライブは、HTTP 1.1 仕様で指定されているように、デフォルトで有効になっています。Envoy プロキシは、クライアント HTTP キープアライブ タイムアウトとバックエンド キープアライブ タイムアウトの両方をデフォルト値の 600 秒に設定します。クライアント HTTP キープアライブ タイムアウトは更新できますが、バックエンド キープアライブ タイムアウト値は固定されています。バックエンド サービスのタイムアウトを設定することで、リクエスト / レスポンスのタイムアウトを構成できます。詳しくは、タイムアウトと再試行をご覧ください。

ロードバランサとのクライアント通信

• クライアントは HTTP 1.1 または HTTP/2 プロトコルを使用してロードバランサと通信できます。
• 最近のクライアントは、HTTPS を使用するとデフォルトで HTTP/2 になります。この制御は HTTPS ロードバランサではなくクライアント上で行われます。
• ロードバランサで構成を変更することで、HTTP/2 を無効にすることはできません。ただし、一部のクライアントは、HTTP/2 ではなく HTTP 1.1 を使用するように構成できます。たとえば、curl では、--http1.1 パラメータを使用します。
• 外部アプリケーション ロードバランサは HTTP/1.1 100 Continue レスポンスをサポートします。

各モードの外部アプリケーション ロードバランサ転送ルールでサポートされるプロトコルの完全な一覧については、ロードバランサの機能をご覧ください。

クライアント パケットの送信元 IP アドレス

バックエンドから見たパケットの送信元 IP アドレスは、ロードバランサの Google Cloud の外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。

• 接続 1: 元のクライアントからロードバランサ（GFE）への接続。

  • 送信元 IP アドレス: オリジナルのクライアント（クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス）。
  • 宛先 IP アドレス: ロードバランサの IP アドレス。

• 接続 2: ロードバランサ（GFE）からバックエンド VM またはエンドポイントへの接続。

  • 送信元 IP アドレス: ファイアウォール ルールで指定された範囲の IP アドレス。

  • 宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

• 接続 1: 元のクライアントからロードバランサ（プロキシ専用サブネット）への接続。

  • 送信元 IP アドレス: オリジナルのクライアント（クライアントが NAT の背後にある場合や外部プロキシの場合は外部 IP アドレス）。
  • 宛先 IP アドレス: ロードバランサの IP アドレス。

• 接続 2: ロードバランサ（プロキシ専用サブネット）からバックエンド VM またはエンドポイントへの接続。

  • 送信元 IP アドレス: ロードバランサと同じリージョン、同じネットワークにデプロイされたすべての Envoy ベースのロードバランサ間で共有されるプロキシ専用サブネットの IP アドレス。

  • 宛先 IP アドレス: VPC ネットワーク内のバックエンド VM またはコンテナの内部 IP アドレス。

特別なルーティング パス

Google Cloud は、VPC ネットワークで定義されていない特別なルートを使用して、次のタイプのトラフィックのパケットを転送します。

• ヘルスチェックの場合（分散 Envoy ヘルスチェックを除く）。詳細については、ヘルスチェックのパスをご覧ください。

• グローバル外部アプリケーション ロードバランサおよび従来のアプリケーション ロードバランサのバックエンドと GFE との間。詳細については、Google Front End とバックエンド間のパスをご覧ください。

Google Cloud は、プロキシ専用サブネットのサブネット ルートを使用して、次の種類のトラフィックのパケットを転送します。

• 分散 Envoy ヘルスチェックを使用する場合。

リージョン外部アプリケーション ロードバランサの場合、Google Cloud はオープンソースの Envoy プロキシを使用してロードバランサへのクライアント リクエストを終了します。ロードバランサは TCP セッションを終了し、リージョンのプロキシ専用サブネットからバックエンドへの新しい TCP セッションを開きます。VPC ネットワーク内で定義されたルートによって、Envoy プロキシからバックエンドへの通信と、バックエンドから Envoy プロキシへの通信が容易になります。

オープンポート

GFE には、同じアーキテクチャで実行される他の Google サービスをサポートするための複数のオープンポートがあります。ポートスキャンを実行すると、GFE で実行されている他の Google サービスのオープンポートが表示される場合があります。

GFE ベースのロードバランサの IP アドレスに対してポートスキャンを実行することは、次の理由により、監査の観点からは役立ちません。

• 通常、ポートスキャン（たとえば nmap を使用）では、TCP SYN プローブを実行するときにレスポンス パケットや TCP RST パケットは想定されません。GFE は、転送ルールを構成したポートに対してのみ、SYN プローブへのレスポンスとして SYN-ACK パケットを送信します。GFE は、ロードバランサの IP アドレスと、転送ルールで構成されている宛先ポートにパケットが送信された場合にのみ、パケットをバックエンドに送信します。別の IP アドレスまたはポートに送信されたパケットはバックエンドに送信されません。

  GFE は、Google Cloud Armor などのセキュリティ機能を実装しています。Google Cloud Armor Standard を使用すると、GFE は、ボリューム型およびプロトコル ベースの DDoS 攻撃と SYN フラッドを常に阻止します。この保護は、Google Cloud Armor を明示的に構成していない場合でも使用できます。セキュリティ ポリシーを構成した場合または Managed Protection Plus に登録した場合にのみ、課金されます。

• ロードバランサの IP アドレスに送信されたパケットには、Google のフリート内の任意の GFE が応答可能ですが、ロードバランサの IP アドレスと宛先ポートの組み合わせをスキャンすると、TCP 接続ごとに 1 つの GFE のみが検査されます。ロードバランサの IP アドレスは、単一のデバイスまたはシステムに割り当てられていません。したがって、GFE ベースのロードバランサの IP アドレスをスキャンしても、Google のフリート内のすべての GFE がスキャンされるわけではありません。

以下では、この点を考慮し、バックエンド インスタンスのセキュリティをより効果的に監査する方法を説明します。

• セキュリティ監査担当者は、ロードバランサの構成で転送ルールの構成を検査する必要があります。転送ルールは、ロードバランサがパケットを受け入れてバックエンドに転送する宛先ポートを定義しています。GFE ベースのロードバランサの場合、1 つの外部転送ルールで参照できる宛先 TCP ポートは 1 つだけです。TCP ポート 443 を使用するロードバランサの場合、接続を QUIC（HTTP/3）にアップグレードすると、UDP ポート 443 が使用されます。

• セキュリティ監査担当者は、バックエンド VM に適用されるファイアウォール ルールの構成を検査する必要があります。設定したファイアウォール ルールでは、GFE からバックエンド VM へのトラフィックはブロックされますが、GFE への受信トラフィックはブロックされません。ベスト プラクティスについては、ファイアウォール ルールのセクションをご覧ください。

TLS 終端

次の表に、外部アプリケーション ロードバランサによる TLS 終端の処理方法を示します。

タイムアウトと再試行

外部アプリケーション ロードバランサは、HTTP / HTTPS トラフィックに対して次の種類のタイムアウトをサポートします。

バックエンド サービスのタイムアウト

構成可能なバックエンド サービス タイムアウトは、バックエンドが HTTP リクエストを処理し、対応する HTTP レスポンスを返すまでロードバランサが待機する最長時間を表します。サーバーレス NEG を除き、バックエンド サービスのタイムアウトのデフォルト値は 30 秒です。

たとえば、500 MB のファイルをダウンロードする場合、バックエンド サービスのタイムアウトの値が 90 秒であれば、ロードバランサはバックエンドが 500 MB ファイル全体を 90 秒以内で配信すると想定します。バックエンド サービスのタイムアウトには、バックエンドが完全な HTTP レスポンスを送信するのに十分でない時間を構成することもできます。この状況では、少なくともロードバランサがバックエンドから HTTP レスポンス ヘッダーを受け取った場合、ロードバランサは完全なレスポンス ヘッダーと、バックエンド サービスのタイムアウト内で取得できる可能な限り多くのレスポンス本文を返します。

バックエンド サービスのタイムアウトは、HTTP レスポンスを処理するためにバックエンドが待機する必要のある最長時間に設定する必要があります。バックエンドで実行されているソフトウェアが HTTP リクエストを処理し、レスポンス全体を返すためにさらに時間が必要な場合は、バックエンド サービスのタイムアウト値を増やす必要があります。たとえば、HTTP 408 レスポンスに jsonPayload.statusDetail client_timed_out が表示される場合は、タイムアウトの値を大きくする必要があります。

バックエンド サービスのタイムアウトは、1～2,147,483,647 秒の値を受け入れます。ただし、あまりに大きい値は実用的な構成オプションではありません。 また、バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。 グローバル アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、GFE はバックエンド サービスの有効な最大タイムアウトを 86,400 秒（1 日）に設定します。 クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。

バックエンド サービスのタイムアウトを構成するには、次のいずれかの方法を使用します。

リージョン外部アプリケーション ロードバランサは、URL マップの構成済みの routeActions.timeout パラメータを使用し、バックエンド サービスのタイムアウトを無視します。routeActions.timeout が構成されていない場合、バックエンド サービスのタイムアウトの値が使用されます。routeActions.timeout が指定されている場合、バックエンド サービスのタイムアウトは無視され、代わりに、リクエストとレスポンスのタイムアウトとして routeActions.timeout が使用されます。

クライアント HTTP キープアライブ タイムアウト

クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと次のいずれかのタイプのプロキシ間でアイドル状態になる最長時間を表します。

• グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合: 最初のレイヤの Google Front End

• リージョン外部アプリケーション ロードバランサの場合: Envoy プロキシ

HTTP キープアライブ タイムアウトは、基盤となる TCP 接続の TCP アイドル タイムアウトを表します。クライアント HTTP キープアライブ タイムアウトは WebSocket に適用されません。

• グローバル外部アプリケーション ロードバランサの場合、デフォルト値は 610 秒です。クライアント HTTP キープアライブ タイムアウトは 5～1,200 秒で構成できます。
• 従来のアプリケーション ロードバランサの場合、クライアントの HTTP キープアライブ タイムアウトは 610 秒に固定されています。
• リージョン外部アプリケーション ロードバランサの場合、デフォルト値は 600 秒です。クライアント HTTP キープアライブ タイムアウトは 5 ～ 600 秒で構成できます。

キープアライブ タイムアウト パラメータを構成するには、次のいずれかの方法を使用します。

ロードバランサのクライアント HTTP キープアライブ タイムアウトは、ダウンストリーム クライアントまたはプロキシで使用される HTTP キープアライブ（TCP アイドル）タイムアウトよりも大きくする必要があります。ダウンストリーム クライアントの HTTP キープアライブ（TCP アイドル）タイムアウトがロードバランサのクライアント HTTP キープアライブ タイムアウトよりも大きい場合、競合状態が発生する可能性があります。ダウンストリーム クライアントから見ると、確立済みの TCP 接続が、ロードバランサで許可されている時間よりも長くアイドル状態になる可能性があります。つまり、ロードバランサが TCP 接続が閉じられたとみなすと、ダウンストリーム クライアントはパケットを送信できます。その場合、ロードバランサは TCP reset（RST）パケットで応答します。

バックエンド HTTP キープアライブ タイムアウト

外部アプリケーション ロードバランサは、少なくとも 2 つの TCP 接続を使用するプロキシです。

• グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合、（ダウンストリームの）クライアントと最初のレイヤの GFE の間に最初の TCP 接続が存在します。最初のレイヤの GFE が 2 番目のレイヤの GFE に接続し、次に 2 番目のレイヤの GFE がバックエンドへの 2 番目の TCP 接続を開きます。

• リージョン外部アプリケーション ロードバランサの場合、最初の TCP 接続は（ダウンストリーム）クライアントと Envoy プロキシの間に存在します。次に、Envoy プロキシがバックエンドへの 2 番目の TCP 接続を開きます。

ロードバランサの 2 番目の TCP 接続は、リクエストごとに終了せず、複数の HTTP リクエストとレスポンスを処理できるように、開いている状態を維持する場合があります。バックエンド HTTP キープアライブ タイムアウトは、ロードバランサとバックエンド間の TCP アイドル タイムアウトを定義します。バックエンド HTTP キープアライブ タイムアウトは WebSocket には適用されません。

バックエンド キープアライブ タイムアウトは 10 分（600 秒）に固定されており、変更できません。ロードバランサのバックエンド キープアライブ タイムアウトは、バックエンドで実行されているソフトウェアで使用されるキープアライブ タイムアウトよりも短くする必要があります。これにより、バックエンドのオペレーティング システムが TCP reset（RST）で TCP 接続を終了する可能性のある競合状態を回避できます。ロードバランサのバックエンド キープアライブ タイムアウトは構成できないため、HTTP キープアライブ（TCP アイドル）タイムアウト値が 600 秒を超えるようにバックエンド ソフトウェアを構成する必要があります。

次の表は、一般的なウェブサーバー ソフトウェアの、キープアライブ タイムアウト値を変更するために必要な変更を示します。

QUIC セッションのアイドル タイムアウト

QUIC セッションのアイドル タイムアウトは、グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの GFE とクライアントとの間で QUIC セッションがアイドル状態を継続できる最大時間を表します。

QUIC セッションのアイドル タイムアウト値は、クライアントのアイドル タイムアウトまたは GFE アイドル タイムアウト（300 秒）のいずれかの最小値として定義されます。GFE のアイドル タイムアウトは 300 秒に固定されています。クライアントのアイドル タイムアウトは構成できます。

再試行数

再試行ロジックのサポートは、外部アプリケーション ロードバランサのモードによって異なります。

WebSocket プロトコルは GKE Ingress でもサポートされています。

不正なリクエストとレスポンスの処理

ロードバランサは、いくつかの理由により、クライアント リクエストとバックエンド レスポンスのいずれについても、相手方のバックエンドまたはクライアントに到達しないようにブロックすることがあります。厳密に HTTP/1.1 を遵守するためという理由もあれば、バックエンド間での予期しないデータのやり取りを避けるという理由もあります。無効にできるチェックはありません。

ロードバランサは、HTTP/1.1 への適合のために以下のリクエストをブロックします。

• 要求の最初の行を解析できない。
• ヘッダーにコロン（:）区切り文字がない。
• ヘッダーまたは最初の行に無効な文字が含まれている。
• コンテンツの長さが有効な数値でない、または、複数のコンテンツ長ヘッダーがある。
• 複数の転送エンコーディング キーがある、または、認識されない転送エンコーティング値がある。
• チャンク化されていない本文があり、コンテンツの長さが指定されていない。
• 本文のチャンクが解析できない。なんらかのデータがバックエンドに到達するのはこの場合のみです。ロードバランサは、解析不能なチャンクを受信すると、クライアントとバックエンドへの接続を閉じます。

リクエスト処理

次のいずれかが該当する場合、ロードバランサはリクエストをブロックします。

• リクエスト ヘッダーとリクエスト URL の合計サイズが、外部アプリケーション ロードバランサのリクエストのヘッダーサイズの上限を超えている。
• リクエスト メソッドが本文を許可していないにもかかわらず、リクエストに本文がある。
• リクエストに Upgrade ヘッダーが含まれており、WebSocket 接続の有効化に Upgrade ヘッダーが使用されない。
• HTTP のバージョンが不明。

レスポンス処理

ロードバランサは、次のいずれかに該当する場合、バックエンドからのレスポンスをブロックします。

• レスポンス ヘッダーの合計サイズが、外部アプリケーション ロードバランサの最大レスポンス ヘッダーのサイズの上限を超えている。
• HTTP のバージョンが不明。

リクエストとレスポンスの両方を処理するときに、ロードバランサは HTTP/1.1 のホップバイホップ ヘッダーを削除または上書きしてから、目的の宛先に転送することがあります。

トラフィック分散

バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する場合は、バックエンドの負荷とターゲット容量を測定する方法を定義するバランシング モードを指定します。外部アプリケーション ロードバランサは、次の 2 つのバランシング モードをサポートします。

• インスタンス グループまたは NEG の場合、RATE は 1 秒あたりのリクエスト（クエリ）の最大数（RPS、QPS）の目標です。すべてのバックエンドが容量を超えると、目標最大 RPS / QPS を超過する場合があります。

• UTILIZATION はインスタンス グループ内の VM のバックエンド使用率です。

バックエンド間でのトラフィックの分散方法は、ロードバランサのモードによって異なります。

グローバル外部アプリケーション ロードバランサ

Google Front End（GFE）はバックエンド インスタンスにリクエストを送信する前に、どのバックエンド インスタンスがリクエストを受信できるかを推定します。この容量の見積もりは、リクエストの到着と同時に行われるのではなく、事前に行われます。GFE は、利用可能な容量に関する情報を定期的に受け取り、それに応じて受信リクエストを分散します。

容量の意味は、分散モードによって異なります。RATE モードの場合は比較的単純です。GFE は 1 秒あたりに割り当てることができるリクエスト数を正確に決定します。UTILIZATION ベースの負荷分散はより複雑です。ロードバランサはインスタンスの現在の使用率をチェックし、各インスタンスが処理できるクエリ負荷を見積もります。この推定値は、インスタンスの使用率とトラフィック パターンの変化に応じて変化します。

容量の見積もりと事前の割り当ての両方の要素が、インスタンス間の分散に影響します。そのため、Cloud Load Balancing の動作は、2 つのインスタンス間でリクエストを正確に 50:50 に分散する単純なラウンドロビン ロードバランサとは異なります。Google Cloud Load Balancing は、リクエストごとにバックエンド インスタンスの選択を最適化します。

グローバル外部アプリケーション ロードバランサの場合、ロード バランシングは 2 層になります。分散モードでは、各バックエンド（インスタンス グループまたは NEG）に送信するトラフィックの重みまたは割合を決定します。さらに、ロード バランシング ポリシー（LocalityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。詳細については、ロード バランシングの局所性ポリシー（リージョン バックエンド サービスの API ドキュメント）をご覧ください。

従来のアプリケーション ロードバランサの場合、バランシング モードを使用して、最も優先するバックエンド（インスタンス グループまたは NEG）を選択します。トラフィックは、ラウンドロビン方式によりバックエンド内のインスタンスまたはエンドポイント間で分散されます。

リクエストの分散方法

GFE ベースの外部アプリケーション ロードバランサは、受信リクエストを分散するために次のプロセスを使用します。

1. クライアントから第 1 レイヤの GFE へ。エッジルーターは、Google ネットワークの境界にある転送ルールの外部 IP アドレスをアドバタイズします。各アドバタイズは、レイヤ 3/4 ロード バランシング システム（Maglev）へのネクストホップを一覧表示します。Maglev システムは、第 1 レイヤの Google Front End（GFE）にトラフィックを転送します。
   • プレミアム ティアを使用する場合、Google は、全世界のあらゆるポイント オブ プレゼンスからロードバランサの IP アドレスをアドバタイズします。各ロードバランサの IP アドレスはグローバル エニーキャストです。
   • スタンダード ティアを使用する場合、Google は転送ルールのリージョンに関連付けられたポイント オブ プレゼンスからロードバランサの IP アドレスをアドバタイズします。ロードバランサは、リージョン外部 IP アドレスを使用します。スタンダード ティアの転送ルールを使用する場合、インスタンス グループとゾーン NEG バックエンドはロードバランサの転送ルールと同じリージョンに制限されます。
2. 第 1 レイヤの GFE から第 2 レイヤの GFE へ。第 1 レイヤの GFE は、必要に応じて TLS を終端し、以下のプロセスでトラフィックを 2 番目のレイヤの GFE にルーティングします。
   • 第 1 レイヤの GFE が URL マップを解析し、バックエンド サービスまたはバックエンド バケットを選択します。
   • インターネット NEG を使用するバックエンド サービスの場合、第 1 レイヤの GFE は、第 1 レイヤの GFE と同じ場所に配置された第 2 レイヤの外部転送ゲートウェイを選択します。転送ゲートウェイは、インターネット NEG エンドポイントにリクエストを送信します。これで、インターネット NEG のリクエスト分散プロセスは完了です。
   • サーバーレス NEG、Private Service Connect（PSC）NEG、単一リージョンのバックエンド バケットを使用するバックエンド サービスの場合、第 1 レイヤの GFE は NEG またはバケットのリージョンと一致するリージョン内にある第 2 レイヤの GFE を選択します。マルチリージョンの Cloud Storage バケットの場合、第 1 レイヤの GFE は、バケットのリージョンにある第 2 レイヤの GFE を選択します。または、マルチリージョン バケットに可能な限り近いリージョンにある第 2 レイヤの GFE を選択します（ネットワーク ラウンド トリップ時間により定義されます）。
   • インスタンス グループ、GCE_VM_IP_PORT エンドポイントを含むゾーン NEG、ハイブリッド NEG を使用するバックエンド サービスの場合、Google の容量管理システムは、各バックエンドで使用および構成した容量について第 1 レイヤの GFE に通知を行います。バックエンドに構成された容量は、バランシング モード、バランシング モードのターゲット容量、容量スケーラーにより定義されます。
     • スタンダード ティア: 第 1 レイヤの GFE は、バックエンドを含むリージョンにある第 2 レイヤの GFE を選択します。
     • プレミアム ティア: 第 1 レイヤの GFE は、該当リージョンのセットから第 2 レイヤの GFE を選択します。該当リージョンは、バックエンドが構成されているすべてのリージョンです。ただし、バックエンド容量がゼロで構成されるリージョンは除きます。第 1 レイヤの GFE は、該当リージョンで最も近い第 2 レイヤの GFE を選択します（ネットワーク ラウンド トリップ時間により定義されます）。バックエンドが 2 つ以上のリージョンで構成されている場合、第 1 レイヤの GFE は、最初に選択したリージョンがフルになると、他の該当リージョンにリクエストをスピルできます。最初に選択したリージョン内にあるすべてのバックエンドが容量の上限に達した場合、他のリージョンにスピルオーバーできます。
3. 第 2 レイヤの GFE がバックエンドを選択します。第 2 レイヤの GFE はリージョンのゾーンに配置されます。次のプロセスを使用してバックエンドを選択します。
   • サーバーレス NEG、Private Service Connect NEG、バックエンド バケットを使用するバックエンド サービスの場合、第 2 レイヤの GFE が Google の本番環境システムにリクエストを転送します。これで、これらのバックエンドのリクエスト分散プロセスは完了です。

   • インスタンス グループ、GCE_VM_IP_PORT エンドポイントを含むゾーン NEG、ハイブリッド NEG を使用するバックエンド サービスの場合、Google のヘルスチェック プローブ システムは、バックエンド インスタンスまたはエンドポイントのヘルスチェック ステータスについて第 2 レイヤの GFE に通知を行います。

     プレミアム ティアのみ: 第 2 レイヤの GFE がリージョンに正常なバックエンド インスタンスまたはエンドポイントを持たない場合、バックエンドが構成された別の該当リージョン内にあるもう 1 つの第 2 レイヤの GFE にリクエストを送信することがあります。別のリージョンにある第 2 レイヤの GFE 間におけるスピルオーバーは、リージョン間で可能なすべての組み合わせを使い切るわけではありません。特定のリージョンでバックエンドからトラフィックを転送する必要がある場合は、ヘルスチェックに失敗するようバックエンドを構成するのではなく、バックエンドの容量スケーラーをゼロに設定して、第 1 レイヤの GFE が、前のステップでリージョンを除外するようにします。

   それから、第 2 レイヤの GFE は、次のステップで説明するように、リージョン内のゾーンにあるバックエンド インスタンスまたはエンドポイントにリクエストを転送します。

4. 第 2 レイヤの GFE がゾーンを選択します。デフォルトでは、第 2 レイヤの GFE は WATERFALL_BY_REGION アルゴリズムを使用します。第 2 レイヤの各 GFE は、第 2 レイヤの GFE を含むゾーンと同じゾーン内のバックエンド インスタンスまたはエンドポイントを選択します。WATERFALL_BY_REGION ではゾーン間のトラフィックが最小限になるため、リクエスト率が低い場合は第 2 レイヤの各 GFE が第 2 レイヤの GFE と同じゾーンにあるバックエンドにのみリクエストを送信する可能性があります。

   グローバル外部アプリケーション ロードバランサの場合のみ、serviceLbPolicy を使用して次のいずれかの代替アルゴリズムを使用するように第 2 レイヤの GFE を構成できます。

   • SPRAY_TO_REGION: 第 2 レイヤの GFE は、第 2 レイヤの GFE と同じゾーンのバックエンド インスタンスまたはエンドポイントを選択しません。第 2 レイヤの GFE は、リージョン内のすべてのゾーンにある全バックエンド インスタンスまたはエンドポイントにトラフィックを分散しようとします。これにより、ゾーン間のトラフィックが増加することで負荷の均等な分散につながります。
   • WATERFALL_BY_ZONE: 第 2 レイヤの GFE には、第 2 レイヤの GFE と同じゾーンのバックエンド インスタンスまたはエンドポイントを選択することを強くおすすめします。第 2 レイヤの GFE は、現在のゾーン内のすべてのバックエンドが構成済みの容量に達した後にのみ、別のゾーンのバックエンドにリクエストを転送します。
5. 第 2 レイヤの GFE がゾーン内のインスタンスまたはエンドポイントを選択します。デフォルトでは、第 2 レイヤの GFE はラウンドロビン方式によりバックエンド間でリクエストを分散します。グローバル外部アプリケーション ロードバランサの場合のみ、ロード バランシングの局所性ポリシー（localityLbPolicy）を使用してこの設定を変更できます。ロード バランシングの局所性ポリシーは、前の手順で説明した選択済みゾーン内のバックエンドにのみ適用されます。

リージョン外部アプリケーション ロードバランサ

リージョン外部アプリケーション ロードバランサの場合、トラフィック分散はロード バランシング モードとロード バランシングの局所性ポリシーに基づきます。

分散モードでは、各グループ（インスタンス グループまたは NEG）に送信するトラフィックの重みと割合を決定します。ロード バランシングの局所性ポリシー（LocalityLbPolicy）により、グループ内のバックエンドのロード バランシング方法が決まります。

トラフィックを受信すると、バックエンド サービスはバックエンドの分散モードに従ってバックエンド（インスタンス グループまたは NEG）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。

詳しくは以下をご覧ください。

• バランシング モード
• ロード バランシングの局所性ポリシー（リージョン バックエンド サービスの API ドキュメント）。

セッション アフィニティ

セッション アフィニティでは、構成した分散モードに基づいてバックエンドが良好な状態で容量があれば、特定のクライアントから同じバックエンドにリクエストを送信するための、ベストエフォート型の試行を行います。

セッション アフィニティを使用する場合は、UTILIZATION よりも RATE 分散モードを推奨します。セッション アフィニティは、分散モードを [リクエスト数/秒]（RPS）に設定すると最も効果的です。

外部アプリケーション ロードバランサには、次のタイプのセッション アフィニティがあります。

• なし。ロードバランサにセッション アフィニティが設定されていません。
• クライアント IP アフィニティ
• 生成された Cookie アフィニティ
• ヘッダー フィールド アフィニティ
• HTTP Cookie アフィニティ
• ステートフル Cookie ベースのセッション アフィニティ

次の表に、外部アプリケーション ロードバランサでサポートされるセッション アフィニティのオプションを示します。

高可用性とフェイルオーバー

外部アプリケーション ロードバランサの高可用性とフェイルオーバーは、ロードバランサ レベルで構成できます。これは、バックアップが必要なリージョンにバックアップ リージョン外部アプリケーション ロードバランサを作成することで処理されます。

次の表に、フェイルオーバーの動作を示します。

HTTP/2 サポート

HTTP/2 は、HTTP/1 プロトコルのメジャー リビジョンです。HTTP/2 は、クライアントと外部アプリケーション ロードバランサ間の接続と、ロードバランサとそのバックエンド間の接続でサポートされています。

ロードバランサは、TLS handshake の一環として ALPN TLS 拡張を使用し、クライアントとの HTTP/2 ネゴシエーションを自動的に行います。ロードバランサが HTTPS を使用するように構成されていても、最新のクライアントはデフォルトで HTTP/2 になります。この制御はロードバランサではなく、クライアント側で行われます。

クライアントが HTTP/2 をサポートしておらず、ロードバランサとバックエンド インスタンスの間で HTTP/2 を使用するようにロードバランサが構成されている場合、ロードバランサは HTTPS 接続のネゴシエーションを行うか、安全でない HTTP リクエストを受け入れます。これらの HTTPS または HTTP リクエストはロードバランサによって変換され、HTTP/2 経由でバックエンド インスタンスにプロキシされます。

HTTP/2 を使用するには、バックエンドで TLS を有効にする必要があります。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

HTTP/2 最大同時ストリーム数

HTTP/2 の SETTINGS_MAX_CONCURRENT_STREAMS 設定は、ピアが開始し、エンドポイントが受け入れるストリームの最大数を表します。Google Cloud ロードバランサはクライアントへのストリームを開始しないため、HTTP/2 クライアントにより Google Cloud ロードバランサにアドバタイズされた値は、事実上無意味になります。

ロードバランサが HTTP/2 を使用して、VM で実行されているサーバーと通信する場合、ロードバランサはサーバーがアドバタイズする SETTINGS_MAX_CONCURRENT_STREAMS 値を受け入れます。値ゼロがアドバタイズされると、ロードバランサはリクエストをサーバーに転送できないため、エラーが発生する可能性があります。

HTTP/2 の制限事項

• ロードバランサとインスタンスの間の接続に HTTP/2 を使用する場合は、HTTP(S) の場合よりもインスタンスへの TCP 接続数を大幅に増やす必要があります。HTTP/2 では、HTTP(S) による接続数を減らす最適化の接続プールは現在使用できません。その結果、バックエンド接続がより頻繁に行われるため、バックエンドのレイテンシが高くなる可能性があります。
• ロードバランサとバックエンドの間の HTTP/2 では、HTTP/2 接続の単一ストリームを介した WebSocket プロトコルの実行（RFC 8441）はサポートされていません。
• ロードバランサとバックエンドの間の HTTP/2 では、サーバー push がサポートされていません。
• gRPC エラー率とリクエスト数は Google Cloud API または Google Cloud コンソールで確認できません。gRPC エンドポイントがエラーを返した場合、ロードバランサ ログとモニタリング データに OK 200 という HTTP レスポンス コードが記録されます。

HTTP/3 サポート

HTTP/3 は次世代のインターネット プロトコルです。これは、元の Google QUIC プロトコルから開発され、IETF QUIC プロトコル上に構築されます。HTTP/3 は、外部アプリケーション ロードバランサ、Cloud CDN、クライアントの間でサポートされます。

詳細は以下のとおりです。

• IETF QUIC は、TCP と同等の輻輳制御および信頼性を提供するトランスポート レイヤ プロトコルであり、セキュリティのために TLS 1.3 を使用し、パフォーマンスが向上しています。
• HTTP/3 は IETF QUIC の上に構築されたアプリケーション レイヤで、QUIC を使用して多重化、輻輳制御、損失検出、再送を処理します。
• HTTP/3 では、クライアント接続の開始が迅速になり、多重化されたストリームにおけるヘッドオブライン ブロッキングがなくなるとともに、クライアントの IP アドレスが変更されたときの接続の移行がサポートされます。
• HTTP/3 はクライアントとロードバランサ間の接続ではサポートされますが、ロードバランサとバックエンド間の接続ではサポートされません。
• HTTP/3 接続は、BBR 輻輳制御アルゴリズムを使用します。

ロードバランサで HTTP/3 を使用すると、ウェブページの読み込み時間の改善、動画の再バッファリングの低減、レイテンシが高い接続スループットの改善が可能です。

次の表では、各モードでの外部アプリケーション ロードバランサの HTTP/3 サポートを示します。

HTTP/3 のネゴシエート方法

HTTP/3 が有効になっている場合、ロードバランサはこのサポートをクライアントにアドバタイズし、HTTP/3 をサポートするクライアントは HTTPS ロードバランサとの HTTP/3 接続の確立を試行できるようにします。

• 適切に実装されたクライアントは、HTTP/3 接続を確立できない場合は常に HTTPS または HTTP/2 にフォールバックします。
• HTTP/3 をサポートするクライアントは、HTTP/3 サポートのキャッシュに保存された以前の情報を使用して、将来的に不要なラウンドトリップを節約します。
• このフォールバックにより、ロードバランサで HTTP/3 を有効または無効にしても、ロードバランサのクライアントへの接続機能は中断されません。

サポートは Alt-Svc HTTP レスポンス ヘッダーでアドバタイズされます。HTTP/3 が有効になっている場合、ロードバランサからのレスポンスには、次の alt-svc ヘッダー値が含まれます。

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

HTTP/3 が明示的に DISABLE に設定されている場合、レスポンスに alt-svc レスポンス ヘッダーは含まれません。

HTTPS ロードバランサで HTTP/3 が有効になっているときに、クライアントが HTTP/3 をネゴシエートせずに HTTPS または HTTP/2 にフォールバックすることがあります。次に例を示します。

• HTTPS ロードバランサによってサポートされている HTTP/3 バージョンと互換性のないバージョンの HTTP/3 をクライアントがサポートしている場合
• HTTP/3 が機能できない方法で UDP トラフィックがブロックされているか、レート制限されていることがロードバランサで検出された場合
• クライアントは HTTP/3 をまったくサポートしていないため、HTTP/3 接続のネゴシエーションを試行しません。

接続が HTTPS または HTTP/2 にフォールバックした場合は、ロードバランサの障害としてカウントされません。

HTTP/3 を有効にする前に、前述の動作がワークロードに対して許容できることを確認してください。

HTTP/3 を構成する

NONE（デフォルト）と ENABLE は、どちらもロードバランサで HTTP/3 サポートを有効にします。

HTTP/3 が有効になっている場合、ロードバランサはそれをクライアントにアドバタイズします。HTTP/3 をサポートするクライアントは、HTTP/3 バージョンでロードバランサとネゴシエートできるようになります。HTTP/3 をサポートしていないクライアントは、HTTP/3 接続のネゴシエートを行いません。破損しているクライアント実装が特定されている場合を除き、HTTP/3 を明示的に無効にする必要はありません。

外部アプリケーション ロードバランサには、次の表に示すように HTTP/3 を構成する方法が 3 つあります。

HTTP/3 を明示的に有効または無効にする手順は次のとおりです。

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

WebSocket のサポート

Google Cloud の HTTP(S) ベースのロードバランサは、HTTP または HTTPS をバックエンドへのプロトコルとして使用する場合に、WebSocket プロトコルをサポートします。ロードバランサに、WebSocket 接続のプロキシを構成する必要はありません。

WebSocket プロトコルは、クライアントとロードバランサ間に全二重通信チャネルを提供します。詳細については、RFC 6455 をご覧ください。

WebSocket プロトコルは次のように機能します。

1. ロードバランサが、HTTP(S) クライアントからの WebSocket Upgrade リクエストを認識します。リクエストには Connection: Upgrade、Upgrade: websocket ヘッダーが含まれ、その後に他の WebSocket 関連のリクエスト ヘッダーが続きます。
2. バックエンドが WebSocket Upgrade レスポンスを送信します。バックエンド インスタンスが、Connection: Upgrade ヘッダー、Upgrade: websocket ヘッダー、その他の WebSocket 関連レスポンス ヘッダーを含む 101 switching protocol レスポンスを送信します。
3. ロードバランサが、現在の接続期間中、双方向のトラフィックをプロキシします。

バックエンド インスタンスがレスポンス コード 426 または 502 でエラー レスポンスを返した場合、ロードバランサは接続を終了します。

WebSocket のセッション アフィニティは、他のリクエストの場合と同じように機能します。詳細については、セッション アフィニティをご覧ください。

gRPC のサポート

gRPC は、リモート プロシージャ コール用のオープンソース フレームワークです。これは HTTP/2 標準に基づいています。gRPC のユースケースには次のものがあります。

• 低レイテンシでスケーラビリティの高い分散システム
• クラウド サーバーと通信するモバイル クライアントの開発
• 正確かつ効率的で言語に依存しない新しいプロトコルの設計
• 拡張、認証、ロギングを可能にする階層型の設計

Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由でエンドツーエンドでリクエストをプロキシする必要があります。手順は次のとおりです。

1. HTTPS ロードバランサを構成します。
2. ロードバランサからバックエンドへのプロトコルとして HTTP/2 を有効にします。

ロードバランサは、ALPN TLS 拡張を使用して SSL handshake の一部としてクライアントと HTTP/2 をネゴシエートします。

ロードバランサは、ロードバランサとバックエンド インスタンスの間で HTTP/2 を使用するように構成されたロードバランサで、一部のクライアントと HTTPS をネゴシエートしたり安全でない HTTP リクエストを受け入れたりすることもあります。これらの HTTP または HTTPS リクエストはロードバランサによって変換され、リクエストは HTTP/2 経由でバックエンド インスタンスにプロキシされます。

バックエンドで TLS を有効にする必要があります。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

Google Kubernetes Engine Ingress で HTTP/2 を使用するか、Ingress で gRPC と HTTP/2 を使用して、外部アプリケーション ロードバランサを構成する場合は、Ingress による HTTP/2 を使用したロード バランシングをご覧ください。

HTTP/2 の問題のトラブルシューティングについては、バックエンドへの HTTP/2 の問題のトラブルシューティングをご覧ください。

HTTP/2 の制限の詳細については、HTTP/2 の制限をご覧ください。

TLS サポート

デフォルトでは、HTTPS ターゲット プロキシは、クライアントの SSL リクエストを終端するときに TLS 1.0、1.1、1.2、1.3 のみを受け入れます。

ロードバランサが HTTPS をバックエンド サービス プロトコルとして使用する場合は、TLS 1.0、1.1、1.2、1.3 をバックエンドにネゴシエートできます。

相互 TLS のサポート

相互 TLS（mTLS）は、クライアントとサーバーの間の相互認証のための業界標準プロトコルです。これにより、クライアントとサーバーの両方が、信頼できる認証局（CA）によって発行された有効な証明書を保持していることを確認することで、相互に認証されます。サーバーのみが認証される標準の TLS とは異なり、mTLS では、クライアントとサーバーの両方が証明書を提示し、通信を確立する前に両方の ID を確認する必要があります。

すべてのアプリケーション ロードバランサは mTLS をサポートしています。mTLS では、ロードバランサはクライアントに対し、TLS handshake 中にクライアント ID を認証する証明書を送信するようリクエストします。Certificate Manager トラストストアを構成して、ロードバランサがクライアント証明書の信頼チェーンの検証に使用できます。

mTLS の詳細については、相互 TLS 認証をご覧ください。

制限事項

• HTTPS ロードバランサは、SSL 接続を終了する際に close_notify 終了アラートを送信しません。つまり、ロードバランサは SSL シャットダウンを実行する代わりに、TCP 接続を閉じます。
• HTTPS ロードバランサでは、証明書の共通名（CN）属性またはサブジェクト代替名（SAN）属性に含まれるドメインで小文字のみがサポートされます。ドメイン名に大文字を含む証明書は、ターゲット プロキシでプライマリ証明書として設定されている場合にのみ返されます。
• HTTPS ロードバランサは、インターネット NEG バックエンド対応のロードバランサを除き、バックエンドへの接続時に Server Name Indication（SNI）拡張機能を使用しません。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

• 共有 VPC 環境の Cloud Run でリージョン外部アプリケーション ロードバランサを使用する場合、サービス プロジェクトのスタンドアロン VPC ネットワークは、同じ共有 VPC 環境内の他のサービス プロジェクトにデプロイされた他の Cloud Run サービスにトラフィックを送信できます。これは既知の問題であり、この形式のアクセスは今後ブロックされます。

• バックエンド サービスがタイムアウトになるまで基盤となる TCP 接続が維持されるとは限りません。クライアント システムでは、TCP 接続の持続時間に依存するのではなく、再試行ロジックを実装する必要があります。

• Google Cloud コンソールを使用してプレミアム ティアでリージョン外部アプリケーション ロードバランサを作成することはできません。 また、Google Cloud コンソールでこれらのロードバランサを使用できるのは、スタンダード ティアをサポートするリージョンだけです。 代わりに、gcloud CLI または API を使用します。代わりに gcloud CLI または API を使用してください。

• Cloud CDN では、キャッシュの無効化をリクエストすることで、キャッシュ内の 1 つ以上のオブジェクトを無効にできます。デフォルトでは、共有 VPC のプロジェクト間のサービス参照でグローバル外部アプリケーション ロードバランサを使用している場合、サービス プロジェクト管理者にキャッシュの無効化をリクエストする権限は必要ありません。これは、フロントエンド プロジェクト（つまり、ロードバランサの転送ルール、ターゲット プロキシ、URL マップがあるプロジェクト）でキャッシュの無効化が構成されているためです。キャッシュの無効化を実行できるのは、フロントエンド プロジェクトでロードバランサ関連のリソースを構成する IAM ロール（Compute ネットワーク管理者ロールなど）を持つプリンシパルだけです。別のプロジェクトのバックエンド サービスのプロビジョニングを管理するサービス管理者は、フロントエンド プロジェクトのロードバランサ管理者と連携して、プロジェクト間のサービスのキャッシュ無効化を実行する必要があります。

次のステップ

• グローバル外部アプリケーション ロードバランサをデプロイする方法については、Compute Engine バックエンドを使用した外部アプリケーション ロードバランサの設定をご覧ください。

• リージョン外部アプリケーション ロードバランサをデプロイする方法については、Compute Engine バックエンドを使用したリージョン外部アプリケーション ロードバランサの設定をご覧ください。

• 従来のアプリケーション ロードバランサの既存のユーザーで、グローバル外部アプリケーション ロードバランサで新しいデプロイを計画する場合は、移行の概要をご覧ください。

• Terraform を使用して外部アプリケーション ロードバランサの設定を自動化する方法については、外部アプリケーション ロードバランサの Terraform モジュールの例をご覧ください。

• グローバル外部アプリケーション ロードバランサの高度なトラフィック管理機能を構成する方法については、グローバル外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。

• リージョン外部アプリケーション ロードバランサで高度なトラフィック管理機能を構成する方法については、リージョン外部アプリケーション ロードバランサのトラフィック管理の概要をご覧ください。

• ウェブサイトの提供について詳しくは、ウェブサイトの提供をご覧ください。

• Google PoP のロケーションを確認するには、GFE のロケーションをご覧ください。

• 容量管理については、ロード バランシングによる処理能力の管理チュートリアルと、グローバル ロード バランシングによるアプリケーションの処理能力の改善をご覧ください。

• Certificate Manager を使用して SSL 証明書をプロビジョニングして管理する方法については、Certificate Manager の概要をご覧ください。

• ロード バランシング データパスにカスタム ロジックを挿入するには、Service Extensions プラグインまたはコールアウトを構成します。

• リージョン外部アプリケーション ロードバランサの場合のみ、Apigee シャドー API 検出を使用して、既存の Google Cloud インフラストラクチャ内のシャドー API（ドキュメント化されていない API とも呼ばれます）を見つけることができます。シャドー API 検出を有効にする前に、関連する制限事項を確認してください。