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

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

外部アプリケーション ロードバランサは、プロキシベースのレイヤ 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 つの位置情報のみからコンテンツを配信する場合に使用します（コンプライアンスで規制されている場合など）。

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

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

モードを特定する

Cloud コンソール

  1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。
    [ロード バランシング] に移動
  2. [ロードバランサ] タブに、ロードバランサのタイプ、プロトコル、リージョンが表示されます。リージョンが空の場合、ロードバランサはグローバルです。次の表に、ロードバランサのモードを識別する方法を示します。
ロードバランサ モード >ロードバランサの種類 アクセスタイプ リージョン
グローバル外部アプリケーション ロードバランサ アプリケーション EXTERNAL
従来のアプリケーション ロードバランサ アプリケーション（クラシック） EXTERNAL
リージョン外部アプリケーション ロードバランサ アプリケーション EXTERNAL リージョンを指定

gcloud

  1. ロードバランサのモードを確認するには、次のコマンドを実行します。
   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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ターゲット プロキシ

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

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

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

ロードバランサ モード ターゲット プロキシのタイプ プロキシ追加ヘッダー サポートされるカスタム ヘッダー サポートされる Cloud Trace
グローバル外部アプリケーション ロードバランサ グローバル 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 ヘッダーを参照）（リクエストのみ）

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

  • グローバル外部アプリケーション ロードバランサの場合、リクエスト ヘッダーとレスポンス ヘッダーは常に小文字に変換されます。たとえば、Host は host に、Keep-ALIVE は keep-alive になります。

    唯一の例外は、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>

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 ロードバランサをご覧ください。

相互 TLS

通常、HTTPS 通信では、認証はクライアントがサーバーの ID を検証するという方法でのみ機能します。ロードバランサで接続先のクライアントの ID を認証する必要があるアプリケーションの場合は、グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの両方が相互 TLS（mTLS）をサポートします。

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

Google Cloud は Certificate Manager の TrustConfig リソースを使用して、クライアントから提示された証明書の検証にサーバーが使用する証明書を保存します。従来のアプリケーション ロードバランサ（プレミアム ネットワーク サービス ティアまたはグローバル外部アプリケーション ロードバランサ）を使用している場合は、Certificate Manager を使用して、大規模なロードバランサの複数のインスタンスに SSL 証明書または TrustConfig をプロビジョニングして管理できます。詳細については、Certificate Manager の概要をご覧ください。

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

SSL ポリシー

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

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

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

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

バックエンド サービスとバックエンド バケット

バックエンド サービスは、ロードバランサに構成情報を提供します。ロードバランサは、バックエンド サービスからの情報を使用して、受信トラフィックを接続されている 1 つまたは複数のバックエンドに振り向けます。バックエンド サービスと Compute Engine バックエンドを使用してロードバランサを設定する方法の例については、Compute Engine バックエンドを使用した外部アプリケーション ロードバランサの設定をご覧ください。

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

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


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

* GKE で GCE_VM_IP_PORT タイプのエンドポイントを使用します。スタンドアロン ゾーン NEG を使用するか、Ingress を使用します。

† GKE で GCE_VM_IP_PORT タイプのエンドポイントを使用します。スタンドアロン ゾーン NEG を使用します。

‡ GKE Gateway Controller でのみサポート

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

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

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

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

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

グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、インスタンス グループ バックエンドのすべてのバックエンド インスタンスと NEG バックエンドのすべてのバックエンド エンドポイントは同じプロジェクトに配置する必要があります。ただし、インスタンス グループのバックエンドまたは NEG は、そのプロジェクトの別の VPC ネットワークを使用できます。GFE はそれぞれの VPC ネットワーク内のバックエンドと直接通信するため、異なる VPC ネットワークを 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 ネットワークとリージョンに配置する必要があります。

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

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

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

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

ロードバランサのバックエンド サービスを構成する際には、バックエンド サービスがバックエンドと通信するために使用するプロトコルを設定します。HTTP、HTTPS、HTTP/2 を選択できます。指定したプロトコルのみがロードバランサで使用されます。指定されたプロトコルでバックエンドへの接続をネゴシエートできない場合、ロードバランサは他のプロトコルへのフォールバックを行いません。

HTTP/2 を使用する場合は、TLS を使用する必要があります。暗号化しない HTTP/2 はサポートされません。

サポートされているプロトコルの一覧については、ロード バランシング機能: ロードバランサからバックエンドへのプロトコルをご覧ください。

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

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

Google Cloud アプリケーションで 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 の制限をご覧ください。

ヘルスチェック

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

ヘルスチェック プローブでは、上り（内向き）許可ファイアウォール ルールを作成してヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。通常、ヘルスチェック プローブは 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

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

共有 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 Functions サービスはサーバーレス NEG と同じプロジェクトに存在する必要があります。

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

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

このモデルでは、ロードバランサのフロントエンドと URL マップはホスト プロジェクトまたはサービス プロジェクトに存在します。ロードバランサのバックエンド サービスとバックエンドは、共有 VPC 環境のプロジェクト間で分散できます。プロジェクト間のバックエンド サービスは 1 つの URL マップで参照できます。これは、プロジェクト間のサービス参照と呼ばれます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ
ホスト プロジェクト内のロードバランサのフロントエンドと URL マップ

接続の仕組み

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

グローバル外部アプリケーション ロードバランサは、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 ネットワークで定義されていない特別なルートを使用して、次のタイプのトラフィックのパケットを転送します。

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

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

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

オープンポート

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

GFE ベースのロードバランサ（グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサ）は、ポート 80 と 443 を常にオープンポートとして表示します（ロードバランサの転送ルールで構成した他のポートも一緒に表示されます）。ただし、ポート 80 またはポート 443 に転送ルールを構成していない場合、これらのポートに送信された接続は拒否されます。逆に、リージョン外部アプリケーション ロードバランサは Envoy プロキシを使用して実装されているため、スキャン中に余分なオープンポートは表示されません。

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 終端の方法を示します。

ロードバランサ モード TLS 終端
グローバル外部アプリケーション ロードバランサ TLS は、世界中のあらゆる場所にある GFE で終端されます。
従来のアプリケーション ロードバランサ TLS は、世界中のあらゆる場所にある GFE で終端されます。
リージョン外部アプリケーション ロードバランサ TLS は、ユーザーが選択したリージョンのプロキシ専用サブネットにある Envoy プロキシで終端されます。TLS を終端するリージョンを地理的に制御する必要がある場合は、このロードバランサ モードを使用してください。

タイムアウトと再試行

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

タイムアウトの種類と説明 デフォルト値 カスタム値のサポート
グローバル 従来 リージョン
バックエンド サービスのタイムアウト1

リクエストとレスポンスのタイムアウトロードバランサが HTTP リクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトを返すまでの最長時間を表します。リクエストまたはレスポンスのタイムアウト内に HTTP レスポンス全体がロードバランサに返されなかった場合、残りのレスポンス データは破棄されます。
  • バックエンド サービスのサーバーレス NEG の場合: 60 分
  • バックエンド サービスの他のバックエンド タイプの場合: 30 秒
  • バックエンド バケットの場合: 24 時間（86,400 秒）
クライアント HTTP キープアライブ タイムアウト
クライアントとロードバランサのプロキシの間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。
  • グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、ロードバランサのプロキシは第 1 レイヤの GFE です。
  • リージョン外部アプリケーション ロードバランサの場合、ロードバランサのプロキシは Envoy ソフトウェアです。
  • グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合: 610 秒
  • リージョン外部アプリケーション ロードバランサの場合: 600 秒
バックエンド HTTP キープアライブ タイムアウト
ロードバランサのプロキシとバックエンド間の TCP 接続がアイドル状態である最長時間。（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。
  • グローバル外部アプリケーション ロードバランサと従来のアプリケーション ロードバランサの場合、ロードバランサのプロキシは第 2 レイヤの GFE です。
  • リージョン外部アプリケーション ロードバランサの場合、ロードバランサのプロキシは Envoy ソフトウェアです。
  • バックエンド サービスの場合: 10 分（600 秒）
  • バックエンド バケットの場合: 6 分（360 秒）
QUIC セッションのアイドル タイムアウト
グローバル外部アプリケーションまたは従来のアプリケーション ロードバランサの GFE と（ダウンストリーム）クライアントとの間で QUIC セッションがアイドル状態を継続できる最大時間。

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

QUIC セッションのアイドル タイムアウトは、クライアントのアイドル タイムアウトまたは GFE のアイドル タイムアウト（300 秒）のいずれかの最小値です。

GFE のアイドル タイムアウトは 300 秒に固定されています。クライアントのアイドル タイムアウトは構成できます。

1 サーバーレス NEG バックエンドでは構成できません。バックエンド バケットでは構成できません。

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

構成可能なバックエンド サービス タイムアウトは、バックエンドが 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 接続が維持されるとは限りません。クライアント システムでは、TCP 接続が長時間持続することに依存するのではなく、再試行ロジックを実装する必要があります。

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

  • Google Cloud コンソール: ロードバランサのバックエンド サービスの [タイムアウト] フィールドを変更します。
  • Google Cloud CLI: gcloud compute backend-services update コマンドを使用して、バックエンド サービス リソースの --timeout パラメータを変更します。
  • API: グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合は、グローバル backendServices リソースの timeoutSec パラメータを変更します。
  • API: リージョン外部アプリケーション ロードバランサの場合は、regionBackendServices リソースの timeoutSec パラメータを変更します。
WebSocket 接続のタイムアウトは、バックエンド サービスのタイムアウトと同じとは限りません。WebSocket 接続のタイムアウトは、ロードバランサのタイプによって異なります。

ロードバランサ モード デフォルト値 WebSocket のタイムアウトの説明
グローバル外部アプリケーション ロードバランサ バックエンド サービスのタイムアウト: 30 秒

アクティブな WebSocket 接続は、ロードバランサで構成されたバックエンド サービスのタイムアウトを使用しません。接続は 24 時間（86,400 秒）後に自動的に終了します。この 24 時間の上限は固定されており、24 時間を超えるバックエンド サービスのタイムアウトはオーバーライドされます。

アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud は、ソフトウェアの更新やその他の定期的なメンテナンスのために GFE を定期的に再起動します。このため、バックエンド サービスのタイムアウト値を 24 時間（86,400 秒）より大きくすることはおすすめしません。バックエンド サービスのタイムアウト値によってメンテナンス アクティビティが遅延することはありません。バックエンド サービスのタイムアウト値が長くなるほど、Google Cloud がメンテナンスで TCP 接続を終了する可能性が高くなります。
従来のアプリケーション ロードバランサ バックエンド サービスのタイムアウト: 30 秒

WebSocket 接続は、アイドル状態かアクティブ状態かにかかわらず、バックエンド サービスがタイムアウトすると自動的に終了します。

Google Cloud は、ソフトウェアの更新やその他の定期的なメンテナンスのために GFE を定期的に再起動します。このため、バックエンド サービスのタイムアウト値を 24 時間（86,400 秒）より大きくすることはおすすめしません。バックエンド サービスのタイムアウト値によってメンテナンス アクティビティが遅延することはありません。バックエンド サービスのタイムアウト値が長くなるほど、Google Cloud がメンテナンスで TCP 接続を終了する可能性が高くなります。
リージョン外部アプリケーション ロードバランサ バックエンド サービスのタイムアウト: 30 秒

アクティブな WebSocket 接続は、ロードバランサのバックエンド サービスのタイムアウトを使用しません。

アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud では、サービスを提供する Envoy ソフトウェア タスクを定期的に再起動したり、その数を変更しています。バックエンド サービスのタイムアウト値が長いほど、Envoy タスクが 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 秒に固定されています。
  • リージョン外部アプリケーション ロードバランサの場合、クライアントの HTTP キープアライブ タイムアウトは 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 秒を超えるように、バックエンド ソフトウェアを構成する必要があります。

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

ウェブサーバー ソフトウェア パラメータ デフォルト設定 推奨される設定
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

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

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

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

再試行

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

ロードバランサ モード 再試行ロジック
グローバル外部アプリケーション ロードバランサ

URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（numRetries）は 1 回です。再試行ポリシーを使用して構成できる再試行の最大数は 25 です。構成可能な perTryTimeout の最大値は 24 時間です。

再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 のレスポンス（retryConditions=["gateway-error"]）を返したときに 1 回再試行されます。

HTTP POST リクエストは再試行されません。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。
従来のアプリケーション ロードバランサ

接続の再試行に関する再試行ポリシーは変更できません。

HTTP POST リクエストは再試行されません。

80% 以上のバックエンドが正常である限り、HTTP GET リクエストは常に 1 回再試行されます。グループ内に存在するバックエンド インスタンスが 1 つだけで、そのバックエンド インスタンスへの接続が失敗した場合、正常でないバックエンド インスタンスの割合が 100% になるため、GFE はリクエストを再試行しません。

ロードバランサは、最初のリクエストが失敗した後にバックエンド インスタンスからレスポンス ヘッダーを受け取ると、失敗した GET リクエストを再試行します。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。詳細については、外部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

リクエストが失敗すると、ロードバランサは HTTP 502 レスポンスを合成します。
リージョン外部アプリケーション ロードバランサ

URL マップの再試行ポリシーを使用して構成できます。デフォルトの再試行回数（numRetries）は 1 回です。再試行ポリシーを使用して構成できる再試行の最大数は 25 です。構成可能な perTryTimeout の最大値は 24 時間です。

再試行ポリシーがない場合、HTTP 本文のないリクエスト（GET リクエストなど）が HTTP 502、503、または 504 のレスポンスを返したときに 1 回再試行されます。

HTTP POST リクエストは再試行されません。

再試行されたリクエストに対して生成されるログエントリは、最終的なレスポンスに対応する 1 件だけです。

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

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

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

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

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

リクエスト処理

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

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

ロードバランサの第 1 レベルの GFE は、クライアントが次のリクエスト ヘッダーを送信した場合、受信リクエストから削除します。

  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Content-Length: このヘッダーは、リクエストに Transfer-Encoding: chunked が含まれている場合にのみ削除されます。
  • Transfer-Encoding: HTTP OPTIONS リクエストに本文があり、プロトコルが HTTP または HTTPS の場合、ヘッダー Transfer-Encoding: chunked が追加されます。これは HTTP/1.1 でのみサポートされます。

レスポンス処理

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

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

ロードバランサの第 2 レベルの GFE は、バックエンドから受信したレスポンスから次のレスポンス ヘッダーを削除します。

  • Connection
  • Keep-Alive
  • Proxy-Authenticate
  • Proxy-Authorization
  • Trailer
  • TE
  • Content-Length: このヘッダーは、レスポンスに Transfer-Encoding: chunked が含まれている場合にのみ削除されます。
  • Transfer-Encoding: HTTP OPTIONS リクエストに本文があり、プロトコルが HTTP または HTTPS の場合、ヘッダー Transfer-Encoding: chunked が追加されます。これは 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 システムは、最初のレイヤの 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 は、第 1 レイヤの 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）にトラフィックを転送します。バックエンドが選択されると、ロード バランシングの局所性ポリシーに従って、バックエンド グループ内のインスタンスまたはエンドポイント間でトラフィックが分散されます。

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

セッション アフィニティ

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

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

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

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

ロードバランサ モード セッション アフィニティのオプション
  なし クライアント IP 生成された Cookie ヘッダー フィールド HTTP 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 が有効になっている場合、ロードバランサはこのサポートをクライアントにアドバタイズし、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 のサポートはクライアントにアドバタイズされます。

注: TLS 0-RTT（別名 TLS 早期データ）は、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` (default): allows Google to control when HTTP/3 is
    advertised.

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` (default): Allows Google to control when HTTP/3 is
    advertised.

現在、NONE を選択すると、HTTP/3 はクライアントにアドバタイズされますが、Google QUIC はアドバタイズされません。

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

制限事項

  • 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 ネットワーク管理者ロールなど）を持つプリンシパルだけです。別のプロジェクトのバックエンド サービスのプロビジョニングを管理するサービス管理者は、フロントエンド プロジェクトのロードバランサ管理者と連携して、プロジェクト間のサービスのキャッシュ無効化を実行する必要があります。

次のステップ