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

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

外部アプリケーション ロードバランサは、プロキシベースのレイヤ 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 プロキシでマネージド サービスとして実装されるリージョン ロードバランサです。これには、トラフィックのミラーリング、重み付けベースのトラフィック分割、リクエスト ベースまたはレスポンス ベースのヘッダー変換など、高度なトラフィック管理機能が含まれています。
ロードバランサ モード おすすめのユースケース 機能
グローバル外部アプリケーション ロードバランサ このロードバランサは、複数のリージョンにグローバルに分散したユーザーまたはバックエンド サービスがある外部 HTTP(S) ワークロードに使用します。
従来のアプリケーション ロードバランサ

このロードバランサは、プレミアム ティアでグローバルです。プレミアム ネットワーク サービス ティアでは、このロードバランサがマルチリージョン ロード バランシングを行い、容量のある最も近い正常なバックエンドにトラフィックを導き、HTTP(S) トラフィックを可能な限りユーザーの近くで終了させます。リクエスト分散プロセスの詳細については、トラフィック分散をご覧ください。

スタンダード ネットワーク サービス ティアでは、このロードバランサは単一リージョン内のバックエンドにのみトラフィックを分散できます。
  • Gateway（完全なオーケストレーション）、Ingress（完全なオーケストレーション）、またはスタンドアロン NEG（手動オーケストレーション）を使用する GKE と互換性あり
  • Google Cloud Armor のサポート
  • トラフィック ルーティング機能は限定されます。
機能の完全なリストについては、ロード バランシング機能のページをご覧ください。
リージョン外部アプリケーション ロードバランサ

このロードバランサには、既存の従来のアプリケーション ロードバランサの機能の多くに加え、高度なトラフィック管理機能が含まれています。

このロードバランサは、1 つの位置情報のみからコンテンツを配信する場合に使用します（コンプライアンスで規制されている場合など）。

このロードバランサは、プレミアム ティアまたはスタンダード ティアのいずれかで構成できます。

 詳細については、ロード バランシング機能をご覧ください。

モードを特定する

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはグローバルです。次の表に、ロードバランサのモードを識別する方法を示します。

ロードバランサのモード ロードバランサの種類 アクセスタイプ リージョン
グローバル外部アプリケーション ロードバランサ アプリケーション EXTERNAL
従来のアプリケーション ロードバランサ アプリケーション（クラシック） EXTERNAL
リージョン外部アプリケーション ロードバランサ アプリケーション EXTERNAL リージョンを指定

gcloud

ロードバランサのモードを確認するには、次のコマンドを実行します。

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

コマンドの出力で、ロード バランシング スキーム、リージョン、ネットワーク ティアを確認します。次の表に、ロードバランサのモードを識別する方法を示します。

ロードバランサのモード ロード バランシング スキーム 転送ルール ネットワーク ティア
グローバル外部アプリケーション ロードバランサ EXTERNAL_MANAGED グローバル プレミアム
従来のアプリケーション ロードバランサ EXTERNAL グローバル スタンダードまたはプレミアム
リージョン外部アプリケーション ロードバランサ EXTERNAL_MANAGED リージョンを指定 スタンダードまたはプレミアム

アーキテクチャ

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

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

  • 外部転送ルールでは、外部 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 アドレス、ロード バランシング スキームのタイプは、ロードバランサのモードやロードバランサがどのネットワーク サービス ティアに属しているかによって異なります。

ロードバランサのモード ネットワーク サービス ティア 転送ルール、IP アドレス、ロード バランシング スキーム インターネットからロードバランサのフロントエンドへの転送
グローバル外部アプリケーション ロードバランサ プレミアム ティア

グローバル外部転送ルール

グローバル外部 IP アドレス

ロード バランシング スキーム:
EXTERNAL_MANAGED

 インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。
従来のアプリケーション ロードバランサ プレミアム ティア

グローバル外部転送ルール

グローバル外部 IP アドレス

ロード バランシング スキーム:
EXTERNAL 1

 インターネット上のクライアントに最も近い GFE にルーティングされるリクエスト。
スタンダード ティア

リージョン外部転送ルール

リージョン外部 IP アドレス

ロード バランシング スキーム:
EXTERNAL1

 ロードバランサのリージョン内の GFE に転送されるリクエスト。
リージョン外部アプリケーション ロードバランサ プレミアム ティア またはスタンダード ティア

リージョン外部転送ルール

リージョン外部 IP アドレス

ロード バランシング スキーム:
EXTERNAL_MANAGED

 リクエストは、クライアントに最も近い PoP で Google Cloud に到達します。リクエストは、ロードバランサと同じリージョン内の Envoy プロキシに到達するまで、 Google Cloudのプレミアム バックボーン経由で転送されます。
1 EXTERNAL_MANAGED バックエンド サービスに EXTERNAL 転送ルールを適用できます。ただし、EXTERNAL バックエンド サービスに EXTERNAL_MANAGED 転送ルールを適用することはできません。グローバル外部アプリケーション ロードバランサでのみ利用可能な新機能を活用するには、従来のアプリケーション ロードバランサからグローバル外部アプリケーション ロードバランサにリソースを移行するで説明されている移行プロセスに従って、既存の EXTERNAL リソースを EXTERNAL_MANAGED に移行することをおすすめします。

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

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

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

ロードバランサのモード VPC ネットワークの関連付け
グローバル外部アプリケーション ロードバランサ

従来のアプリケーション ロードバランサ

関連付けられた VPC ネットワークはありません。

転送ルールでは、常に VPC ネットワーク外の IP アドレスが使用されます。したがって、転送ルールには VPC ネットワークが関連付けられていません。
リージョン外部アプリケーション ロードバランサ

転送ルールの VPC ネットワークは、プロキシ専用サブネットが作成されたネットワークです。ネットワークは、転送ルールを作成するときに指定します。

IPv4 アドレスと IPv6 アドレス範囲のどちらを使用するかに応じて、転送ルールには明示的または暗黙的な VPC ネットワークが常に関連付けられます。

  • リージョン外部 IPv4 アドレスは常に VPC ネットワークの外部に存在します。ただし、転送ルールを作成するときに、プロキシ専用サブネットが作成された VPC ネットワークを指定する必要があります。したがって、転送ルールには明示的なネットワークの関連付けがあります。
  • リージョン外部 IPv6 アドレス範囲は常に VPC ネットワーク内に存在します。転送ルールを作成するときに、IP アドレスを取得するサブネットを指定する必要があります。このサブネットは、プロキシ専用サブネットが作成されたリージョンと VPC ネットワークに存在する必要があります。このため、暗黙的なネットワークの関連付けが存在します。

ターゲット プロキシ

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

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

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

ロードバランサのモード ターゲット プロキシのタイプ プロキシ追加ヘッダー サポートされるカスタム ヘッダー
グローバル外部アプリケーション ロードバランサ グローバル HTTP、
グローバル HTTPS		 プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。
  • Via: 1.1 google（リクエストとレスポンス）
  • X-Forwarded-Proto: [http | https]（リクエストのみ）
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip>（X-Forwarded-For ヘッダー）（リクエストのみ）

また、X-Cloud-Trace-Context ヘッダーがまだ存在しない場合、プロキシはそのヘッダーを設定します。

 バックエンド サービスまたはバックエンド バケットで構成されている

Cloud CDN ではサポートされていない
従来のアプリケーション ロードバランサ グローバル HTTP、
グローバル HTTPS		 プロキシは、次のように HTTP リクエスト ヘッダー / レスポンス ヘッダーを設定します。
  • Via: 1.1 google（リクエストとレスポンス）
  • X-Forwarded-Proto: [http | https]（リクエストのみ）
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip>（X-Forwarded-For ヘッダー）（リクエストのみ）

また、X-Cloud-Trace-Context ヘッダーがまだ存在しない場合、プロキシはそのヘッダーを設定します。

 バックエンド サービスまたはバックエンド バケットで構成されている
リージョン外部アプリケーション ロードバランサ リージョン HTTP、
リージョン HTTPS
  • X-Forwarded-Proto: [http | https]（リクエストのみ）
  • Via: 1.1 google（リクエストとレスポンス）
  • X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip>（X-Forwarded-For ヘッダー）（リクエストのみ）
 URL マップで構成されている

ロードバランサは、ターゲット プロキシによって追加されたヘッダーに加えて、次の方法で他の 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 ヘッダーに追加します。

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

受信リクエストに X-Forwarded-For ヘッダーが含まれていない場合、結果のヘッダーは次のようになります。

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

受信リクエストにすでに X-Forwarded-For ヘッダーが含まれている場合、ロードバランサはその値を既存のヘッダーに追加します。

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

カスタム リクエスト ヘッダーを使用して既存のヘッダー値を削除する

バックエンド サービスでカスタム リクエスト ヘッダーを使用すると、既存のヘッダー値を削除できます。次の例では、--custom-request-header フラグで変数 client_ip_address と server_ip_address を使用して、X-Forwarded-For ヘッダーを再作成します。この構成では、受信した X-Forwarded-For ヘッダーをクライアントとロードバランサの IP アドレスで置き換えます。

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

バックエンド リバース プロキシ ソフトウェアが X-Forwarded-For ヘッダーを変更する仕組み

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

  1. バックエンドに接続されている GFE の IP アドレス。GFE IP アドレスの範囲は 130.211.0.0/22 と 35.191.0.0/16 です。

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

結果として、次のような構造の X-Forwarded-For ヘッダーがアップストリーム システムに表示される場合があります。

<existing-value>,<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 マップのタイプを示します。

ロードバランサのモード 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 ポリシーのサポートを示します。

ロードバランサのモード サポートされる SSL ポリシー
グローバル外部アプリケーション ロードバランサ
従来のアプリケーション ロードバランサ
リージョン外部アプリケーション ロードバランサ

バックエンド サービス

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

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

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

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

ロードバランサのモード バックエンド サービス リソース
グローバル外部アプリケーション ロードバランサ backendServices（グローバル）
従来のアプリケーション ロードバランサ backendServices（グローバル）
リージョン外部アプリケーション ロードバランサ regionBackendServices（リージョン）

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

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

  • HTTP。HTTP/1.1 を使用し、TLS は使用しません。
  • HTTPS。HTTP/1.1 と TLS を使用します。
  • HTTP/2。HTTP/2 と TLS を使用します（暗号化なしの HTTP/2 はサポートされていません）。
  • H2C。HTTP/2 over TCP を使用します。TLS は不要です。H2C は、従来のアプリケーション ロードバランサではサポートされていません。

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

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

バックエンド バケット

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

バックエンド

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


ロードバランサのモード		 バックエンド サービスでサポートされるバックエンド1 バックエンド バケットのサポート Cloud Armor のサポート Cloud CDN のサポート2 IAP のサポート2 Service Extensions のサポート
インスタンス グループ3 ゾーン NEG4 インターネット NEG サーバーレス NEG ハイブリッド NEG Private Service Connect NEG
グローバル外部アプリケーション ロードバランサ
従来のアプリケーション ロードバランサ
プレミアム ティア
リージョン外部アプリケーション ロードバランサ

1 バックエンド サービス上のバックエンドは、同じタイプ（すべてインスタンス グループまたはすべて同じタイプの NEG）である必要があります。このルールの例外は、GCE_VM_IP_PORT ゾーン NEG とハイブリッド NEG の両方を同じバックエンド サービスで使用して、ハイブリッド アーキテクチャをサポートできることです。

2 IAP と Cloud CDN には互換性がありません。同じバックエンド サービスで両方を有効にすることはできません。

3 ゾーン非マネージド インスタンス グループ、ゾーン マネージド インスタンス グループ、リージョン マネージド インスタンス グループの組み合わせは、同じバックエンド サービスでサポートされます。2 つ以上のバックエンド サービスのバックエンドであるマネージド インスタンス グループで自動スケーリングを使用する場合は、複数のシグナルを使用するようにインスタンス グループの自動スケーリング ポリシーを構成します。

4 ゾーン NEG では GCE_VM_IP_PORT エンドポイントを使用する必要があります。

バックエンドと 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 に配信されます。nic0 以外のインターフェース（vNIC または Dynamic Network Interface）にパケットを送信するには、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 アドレス範囲をまとめたものです。

ロードバランサのモード ヘルスチェックのソース範囲 リクエストのソース範囲
グローバル外部アプリケーション ロードバランサ
  • 35.191.0.0/16
  • 130.211.0.0/22

バックエンドへの IPv6 トラフィックの場合:

  • 2600:2d00:1:b029::/64
 GFE トラフィックのソースはバックエンド タイプによって異なります。
  • インスタンス グループとゾーン NEG（GCE_VM_IP_PORT）:
    • 130.211.0.0/22
    • 35.191.0.0/16

    バックエンドへの IPv6 トラフィックの場合:

    • 2600:2d00:1:1::/64
  • ハイブリッド接続 NEG（NON_GCP_PRIVATE_IP_PORT）:
    • 130.211.0.0/22
    • 35.191.0.0/16
  • インターネット NEG（INTERNET_FQDN_PORT と INTERNET_IP_PORT）:
    • 34.96.0.0/20
    • 34.127.192.0/18
  • SERVERLESS NEG とバックエンド バケット: Google の本番環境ネットワークがパケット ルーティングを処理します。
従来のアプリケーション ロードバランサ
  • 35.191.0.0/16
  • 130.211.0.0/22
 GFE トラフィックのソースはバックエンド タイプによって異なります。
  • インスタンス グループ、ゾーン NEG（GCE_VM_IP_PORT）、ハイブリッド接続 NEG（NON_GCP_PRIVATE_IP_PORT）:
    • 35.191.0.0/16
    • 130.211.0.0/22
  • インターネット NEG（INTERNET_FQDN_PORT と INTERNET_IP_PORT）:
    • 34.96.0.0/20
    • 34.127.192.0/18
  • SERVERLESS NEG とバックエンド バケット: Google の本番環境ネットワークがパケット ルーティングを処理します。
リージョン外部アプリケーション ロードバランサ
  • 35.191.0.0/16
  • 130.211.0.0/22

バックエンドへの IPv6 トラフィックの場合:

  • 2600:2d00:1:b029::/64
ハイブリッド NEG では、Google のヘルスチェック プローブ範囲からのトラフィックを許可する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲からのトラフィックを許可する必要があります。		 構成するプロキシ専用サブネット。

GKE サポート

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

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

共有 VPC アーキテクチャ

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

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

ロードバランサ フロントエンド コンポーネント バックエンド コンポーネント
グローバル外部アプリケーション ロードバランサ

バックエンドに共有 VPC ネットワークを使用している場合は、共有 VPC ホスト プロジェクトで必要なネットワークを作成します。

グローバル外部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。

 次のいずれかを行います。
  • バックエンド サービス、バックエンド バケット、バックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を、フロントエンド コンポーネントと同じサービス プロジェクトに作成します。
  • サービス プロジェクトでバックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を作成します。1 つの URL マップで複数のプロジェクトのバックエンド サービスを参照できます。このタイプのデプロイは、プロジェクト間のサービス参照と呼ばれます。

各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックもまた、バックエンド サービスと同じプロジェクトで定義する必要があります。

バックエンドは、ホスト プロジェクトの共有 VPC ネットワークか、スタンドアロンの VPC ネットワーク（サービス プロジェクトの非共有 VPC ネットワーク）のいずれかの一部になります。
従来のアプリケーション ロードバランサ グローバル外部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連する URL マップは、バックエンドと同じホストまたはサービス プロジェクトで定義する必要があります。 グローバル バックエンド サービスは、バックエンド（インスタンス グループまたは NEG）と同じホストまたはサービス プロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。
リージョン外部アプリケーション ロードバランサ

共有 VPC ホスト プロジェクトで、必要なネットワークとプロキシ専用サブネットを作成します。

リージョン外部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。

 次のいずれかを行います。
  • バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を、フロントエンド コンポーネントと同じサービス プロジェクトに作成します。
  • 必要な数のサービス プロジェクトで、バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を作成します。1 つの URL マップで複数のプロジェクトのバックエンド サービスを参照できます。このタイプのデプロイは、プロジェクト間のサービス参照と呼ばれます。

各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。

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

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

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

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

共有 VPC ネットワーク上のリージョン外部アプリケーション ロードバランサ
共有 VPC ネットワーク上のリージョン外部アプリケーション ロードバランサ（クリックして拡大）

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

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

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

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

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

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

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

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

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

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

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

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

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

プロジェクト間のサービス参照の使用に関する注意事項

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

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

    • 外部リージョン アプリケーション ロードバランサの場合、バックエンド サービスがリージョン インターネット NEG バックエンドを使用していると、プロジェクト間のバックエンド サービスを参照することはできません。
  • 従来のアプリケーション ロードバランサでは、プロジェクト間のサービス参照はサポートされていません。
  • Google Cloud では、複数のプロジェクト間で同じ名前を使用するリソース（バックエンド サービスなど）は区別されません。したがって、プロジェクト間のサービス参照を使用する場合は、組織内のプロジェクト間で一意のバックエンド サービス名を使用することをおすすめします。
  • 「このリソースのプロジェクト間の参照が許可されない」などのエラーが表示された場合は、そのリソースを使用する権限があることを確認してください。リソースを所有するプロジェクトの管理者が、Compute ロードバランサ サービス ユーザーのロール（roles/compute.loadBalancerServiceUser）を付与する必要があります。このロールは、プロジェクト レベルまたはリソースレベルで付与できます。例については、バックエンド サービスまたはバックエンド バケットを使用する権限を Compute ロードバランサ管理者に付与するをご覧ください。

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

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

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

サービス プロジェクト内のロードバランサのフロントエンドと URL マップ
ロードバランサのフロントエンドとバックエンドが別のサービス プロジェクトに存在する（クリックして拡大）。

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

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

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

ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ
ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ（クリックして拡大）。

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

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

異なるプロジェクト内のロードバランサのフロントエンドとバックエンド
異なるプロジェクト内のロードバランサのフロントエンドとバックエンド（クリックして拡大）。

この設定の詳細については、バックエンド サービスとバックエンド バケットを使用してプロジェクト間のサービス参照を設定するをご覧ください。

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

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

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

ロードバランサのモード フェイルオーバー方法
グローバル外部アプリケーション ロードバランサ

従来のアプリケーション ロードバランサ

トラフィックがバックアップ リージョン外部アプリケーション ロードバランサにフェイルオーバーするアクティブ / パッシブ　フェイルオーバー構成を構成できます。ヘルスチェックを使用して停止を検出し、Cloud DNS ルーティング ポリシーを使用して、フェイルオーバーがトリガーされたときにトラフィックを転送します。
リージョン外部アプリケーション ロードバランサ

高可用性デプロイを確保するには、次のいずれかの方法を使用します。

HTTP/2 サポート

HTTP/2 は、HTTP/1 プロトコルのメジャー リビジョンです。HTTP/2 のサポートには、次の 2 つのモードがあります。

  • HTTP/2 over TLS
  • Cleartext HTTP/2 over TCP

HTTP/2 over TLS

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

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

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

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

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

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

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

HTTP/2 の制限事項

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

Cleartext HTTP/2 over TCP（H2C）

Cleartext HTTP/2 over TCP（H2C）を使用すると、TLS なしで HTTP/2 を使用できます。H2C は、次の両方の接続でサポートされています。

  • クライアントとロードバランサ間の接続。特別な構成は必要ありません。

  • ロードバランサとバックエンド間の接続。

    ロードバランサとそのバックエンド間の接続に H2C を構成するには、バックエンド サービス プロトコルを H2C に設定します。

H2C サポートは、GKE Gateway コントローラと Cloud Service Mesh を使用して作成されたロードバランサでも利用できます。

H2C は、従来のアプリケーション ロードバランサではサポートされていません。

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 が有効になっている場合、ロードバランサはこのサポートをクライアントにアドバタイズし、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 つあります。

quicOverride 値 動作
NONE

HTTP/3 のサポートはクライアントにアドバタイズされます。
ENABLE

HTTP/3 のサポートはクライアントにアドバタイズされます。
DISABLE クライアントへの HTTP/3 と Google QUIC のアドバタイジングを明示的に無効にします。

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

コンソール: HTTPS

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

[ロード バランシング] に移動

  1. 編集するロードバランサを選択します。
  2. [フロントエンドの構成] をクリックします。
  3. 編集するフロントエンドの IP アドレスとポートを選択します。HTTP/3 構成を編集するには、プロトコルを HTTPS にする必要があります。

HTTP/3 を有効にする

  1. [QUIC ネゴシエーション] メニューを選択します。
  2. このフロントエンドで HTTP/3 を明示的に有効にするには、[有効] を選択します。
  3. IPv4 と IPv6 を表す複数のフロントエンド ルールが存在する場合は、各ルールで HTTP/3 を有効にします。

HTTP/3 を無効にする

  1. [QUIC ネゴシエーション] メニューを選択します。
  2. このフロントエンドの HTTP/3 を明示的に無効にするには、[無効] を選択します。
  3. IPv4 と IPv6 を表す複数のフロントエンド ルールが存在する場合は、ルールごとに HTTP/3 を無効にします。

gcloud: HTTPS

次のコマンドを実行する前に、SSL 証明書ごとにそのリソースを作成する必要があります。

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

QUIC_SETTING を次のいずれかに置き換えます。

  • NONE（デフォルト）: HTTP/3 がアドバタイズされるタイミングを Google が制御できるようにします。

    NONE を選択すると、HTTP/3 はクライアントにアドバタイズされますが、Google QUIC はアドバタイズされません。 Google Cloud コンソールで、このオプションは自動（デフォルト）と表示されます。

  • ENABLE: HTTP/3 をクライアントにアドバタイズします。

  • DISABLE: HTTP/3 をクライアントにアドバタイズしません。

API: HTTPS

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

{
  "quicOverride": QUIC_SETTING
}

QUIC_SETTING を次のいずれかに置き換えます。

  • NONE（デフォルト）: HTTP/3 がアドバタイズされるタイミングを Google が制御できるようにします。

    NONE を選択すると、HTTP/3 はクライアントにアドバタイズされますが、Google QUIC はアドバタイズされません。 Google Cloud コンソールで、このオプションは自動（デフォルト）と表示されます。

  • ENABLE: HTTP/3 と Google QUIC をクライアントにアドバタイズします。

  • DISABLE: HTTP/3 または Google QUIC をクライアントにアドバタイズしません。

WebSocket のサポート

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

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

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

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

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

WebSocket の接続タイムアウトは、ロードバランサの種類（グローバル、リージョン、従来）によって異なります。詳細については、バックエンド サービスのタイムアウトをご覧ください。

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

gRPC のサポート

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

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

Google Cloud アプリケーションで gRPC を使用するには、HTTP/2 経由のエンドツーエンドでリクエストをプロキシする必要があります。これを行うには、次のいずれかの構成でアプリケーション ロードバランサを作成します。

  • エンドツーエンドの暗号化されていないトラフィック（TLS なし）の場合: HTTP ロードバランサ（ターゲット HTTP プロキシで構成）を作成します。また、バックエンド サービス プロトコルを H2C に設定して、ロードバランサとそのバックエンド間の暗号化されていない接続に HTTP/2 を使用するようにロードバランサを構成します。

  • エンドツーエンドの暗号化されたトラフィック（TLS あり）の場合: HTTPS ロードバランサ（ターゲット HTTPS プロキシと SSL 証明書で構成）を作成します。ロードバランサは、ALPN TLS 拡張を使用して SSL handshake の一部としてクライアントと HTTP/2 をネゴシエートします。

    また、バックエンドが TLS トラフィックを処理できることを確認する必要があります。さらに、バックエンド サービス プロトコルを HTTP2 に設定して、ロードバランサとそのバックエンド間の暗号化された接続に HTTP/2 を使用するようにロードバランサを構成する必要があります。

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

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

Cloud Run で HTTP/2 を使用して外部アプリケーション ロードバランサを構成する場合は、ロードバランサの背後で 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.2 または 1.3 をバックエンドにネゴシエートできます。

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

相互 TLS のサポート

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

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

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

TLS 1.3 早期データのサポート

TLS 1.3 早期データは、TCP 経由の HTTPS（HTTP/1.1、HTTP/2）と QUIC 経由の HTTP/3 の両方について、次の外部アプリケーション ロードバランサのターゲット HTTPS プロキシでサポートされています。

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

TLS 1.3 は RFC 8446 で定義されており、初期データ（ゼロ ラウンドトリップ時間（0-RTT）データ）のコンセプトを導入しています。これにより、再開された接続のアプリケーション パフォーマンスを 30～50% 向上させることができます。

TLS 1.2 では、データを安全に送信する前に 2 つのラウンド トリップが必要です。TLS 1.3 では、新しい接続でこれを 1 回のラウンドトリップ（1-RTT）に短縮し、クライアントが最初のサーバー レスポンスの直後にアプリケーション データを送信できるようにします。さらに、TLS 1.3 では、再開されたセッションの早期データのコンセプトが導入され、クライアントは最初の ClientHello でアプリケーション データを送信できるため、有効なラウンドトリップ時間がゼロ（0-RTT）に短縮されます。TLS 1.3 の早期データを使用すると、バックエンド サーバーはクライアントとの handshake プロセスが完了する前にクライアント データの処理を開始できるため、レイテンシを短縮できます。ただし、リプレイリスクを軽減するために注意が必要です。

早期データは handshake が完了する前に送信されるため、攻撃者はリクエストをキャプチャしてリプレイしようとする可能性があります。これを軽減するには、バックエンド サーバーで早期データの使用を慎重に制御し、その使用をべき等リクエストに制限する必要があります。べき等であるが、非べき等の変更をトリガーする可能性がある HTTP メソッド（データベースを変更する GET リクエストなど）は、早期データを受け入れてはなりません。このような場合、バックエンド サーバーは HTTP 425 Too Early ステータス コードを返すことで、HTTP Early-Data: 1 ヘッダーを含むリクエストを拒否する必要があります。

早期データを含むリクエストでは、HTTP 早期データヘッダーが 1 の値に設定されます。これは、リクエストが TLS 早期データで伝送されたことをバックエンド サーバーに示します。また、クライアントが HTTP 425 Too Early ステータス コードを認識していることも示します。

TLS 早期データ（0-RTT）モード

TLS 早期データを構成するには、ロードバランサのターゲット HTTPS プロキシ リソースで次のいずれかのモードを使用します。

  • STRICT。安全な HTTP メソッド（GET、HEAD、OPTIONS、TRACE）を使用するリクエストと、クエリ パラメータのない HTTP リクエストに対して TLS 1.3 早期データを有効にします。非べき等の HTTP メソッド（POST や PUT など）を含む早期データまたはクエリ パラメータを含むリクエストは、HTTP 425 ステータス コードで拒否されます。

  • PERMISSIVE。安全な HTTP メソッド（GET、HEAD、OPTIONS、TRACE）を使用するリクエストに対して TLS 1.3 早期データを有効にします。このモードでは、クエリ パラメータを含むリクエストは拒否されません。アプリケーション オーナーは、リクエストの早期データが各リクエストパスで安全に使用できることを確認する必要があります。特に、GET リクエストによってトリガーされるロギングやデータベースの更新などの意図しない副作用が、リクエストのリプレイにより発生する可能性があるエンドポイントでは、確認が必要です。

  • DISABLED。TLS 1.3 早期データはアドバタイズされず、早期データを送信する（無効な）試みは拒否されます。アプリケーションが早期データ リクエストを安全に処理できない場合は、早期データを無効にする必要があります。TLS 1.3 早期データはデフォルトで無効になっています。

  • UNRESTRICTED（ほとんどのワークロードには推奨されません）。これにより、非べき等メソッド（POST など）を含む任意の HTTP メソッドを使用したリクエストの TLS 1.3 早期データを有効にできます。このモードでは、他の制限は適用されません。このモードは、gRPC のユースケースに役立ちます。ただし、セキュリティ ポスチャーを評価し、他のメカニズムを使用してリプレイ攻撃のリスクを軽減していない限り、この方法はおすすめしません。

TLS 早期データを構成する

TLS 早期データを明示的に有効または無効にする手順は次のとおりです。

コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

    [ロード バランシング] に移動

  2. 早期データを有効にするロードバランサを選択します。

  3. [編集] をクリックします。

  4. [フロントエンドの構成] をクリックします。

  5. 編集するフロントエンドの IP アドレスとポートを選択します。TLS 早期データを有効にするには、プロトコルを HTTPS にする必要があります。

  6. [早期データ（0-RTT）] リストで、TLS 早期データモードを選択します。

  7. [完了] をクリックします。

  8. ロードバランサを更新するには、[更新] をクリックします。

gcloud

  1. アプリケーション ロードバランサのターゲット HTTPS プロキシで TLS 早期データモードを構成します。

    gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
  --tls-early-data=TLS_EARLY_DATA_MODE

    次のように置き換えます。

    • TARGET_HTTPS_PROXY: ロードバランサのターゲット HTTPS プロキシ
    • TLS_EARLY_DATA_MODE: STRICT、PERMISSIVE、DISABLED または UNRESTRICTED

API

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

次のように置き換えます。

  • TARGET_HTTPS_PROXY: ロードバランサのターゲット HTTPS プロキシ
  • TLS_EARLY_DATA_MODE: STRICT、PERMISSIVE、DISABLED または UNRESTRICTED
  • FINGERPRINT: Base64 でエンコードされた文字列。ターゲット HTTPS プロキシにパッチを適用するには、最新のフィンガープリントを指定する必要があります。指定しない場合、リクエストは HTTP 412 Precondition Failed ステータス コードで失敗します。

TLS 早期データを構成したら、TLS 早期データをサポートする HTTP クライアントからリクエストを発行できます。再開されたリクエストのレイテンシが短縮されます。

RFC に準拠していないクライアントが、べき等でないメソッドまたはクエリ パラメータを使用してリクエストを送信した場合、リクエストは拒否されます。ロードバランサのログに HTTP 425 Early ステータス コードと次の HTTP レスポンスが表示されます。

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>

制限事項

  • HTTPS ロードバランサは、SSL 接続を終了する際に close_notify 終了アラートを送信しません。つまり、ロードバランサは SSL シャットダウンを実行する代わりに、TCP 接続を閉じます。

  • HTTPS ロードバランサでは、証明書の共通名（CN）属性またはサブジェクト代替名（SAN）属性に含まれるドメインで小文字のみがサポートされます。ドメイン名に大文字を含む証明書は、ターゲット プロキシでプライマリ証明書として設定されている場合にのみ返されます。

  • HTTPS ロードバランサは、インターネット NEG バックエンド対応のロードバランサを除き、バックエンドへの接続時に Server Name Indication（SNI）拡張機能を使用しません。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

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

  • Google Cloud コンソールを使用してプレミアム ティアでリージョン外部アプリケーション ロードバランサを作成する場合、 Google Cloud コンソールで使用できるのはスタンダード ティアをサポートするリージョンのみです。他のリージョンにアクセスするには、gcloud CLI または API を使用します。

  • グローバル アプリケーション ロードバランサと従来のアプリケーション ロードバランサで使用される GFE プロキシは、リクエストの POST ペイロードがバックエンドに完全にプロキシされる前に送信される早期の 200 OK レスポンスをサポートしていません。早期の 200 OK レスポンスを送信すると、GFE はバックエンドとの接続を閉じます。

    バックエンドは、リクエスト ヘッダーを受信した後に 100 Continue レスポンスで応答し、リクエストの POST ペイロードが完全にプロキシされるまで待機してから、最終的な 200 OK レスポンス コードで応答する必要があります。

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

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

次のステップ