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

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

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

運用モード

このロードバランサはリージョン モードで使用できます。以降は、リージョン内部アプリケーション ロードバランサと呼びます。このロードバランサは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されています。これには、トラフィックのミラーリング、重み付けベースのトラフィック分割、リクエストまたはレスポンス ベースのヘッダー変換など、高度なトラフィック管理機能が含まれています。リージョン モードでは、すべてのクライアントとバックエンドが指定されたリージョンに配置されます。このロードバランサは、1 つの位置情報のみからコンテンツを配信する場合に使用します（コンプライアンスで規制されている場合など）。

アーキテクチャ

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

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

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

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

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

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

• バックエンド サービスは、正常なバックエンドにリクエストを分散します。

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

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

リージョン

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

プロキシ専用サブネット

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

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

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

転送ルールと IP アドレス

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

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

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

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

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

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

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

ターゲット プロキシ

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

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

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

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

• 一部のヘッダーは統合されます。同じヘッダーキー（例: 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 マップのタイプを示します。

SSL 証明書

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

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

リージョン外部アプリケーション ロードバランサは、セルフマネージド Compute Engine SSL 証明書をサポートしています。

SSL ポリシー

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

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

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

バックエンド サービス

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

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

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

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

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

• 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）を使用してバックエンドと通信できます。

バックエンド

リージョン外部アプリケーション ロードバランサは、次のタイプのバックエンドをサポートしています。

• インスタンス グループ
• ゾーン NEG
• インターネット NEG

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

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

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

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

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

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

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

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

  • バックエンドの VPC ネットワークは、VPC ネットワーク ピアリングを使用して転送ルールの 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 ヘルスチェックをサポートしていません。サポートされているヘルスチェック プロトコルの一覧については、ロード バランシング機能をご覧ください。

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

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

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

ファイアウォール ルール

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

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

ファイアウォール ルールは GFE プロキシではなく、VM インスタンス レベルで実装されます。 Trusted Cloud ファイアウォール ルールを使用して、トラフィックがロードバランサに到達しないようにすることはできません。

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

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

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

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

GKE サポート

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

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

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

共有 VPC アーキテクチャ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

接続の仕組み

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

リージョン外部アプリケーション ロードバランサは、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 アドレスは、ロードバランサのTrusted Cloud 外部 IP アドレスではありません。つまり、2 つの TCP 接続があります。

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

  • 送信元 IP アドレス: 元のクライアント（クライアントが NAT ゲートウェイまたは転送プロキシの背後にある場合は外部 IP アドレス）。
  • 宛先 IP アドレス: ロードバランサの IP アドレス。

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

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

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

特別なルーティング パス

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

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

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

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

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

TLS 終端

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

タイムアウトと再試行

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

クライアントの HTTP キープアライブ タイムアウトが切れると、GFE または Envoy プロキシがクライアントに TCP FIN を送信して、接続を正常に終了します。

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

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

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

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

バックエンド キープアライブ タイムアウトは 10 分（600 秒）に固定されており、変更できません。これにより、ロードバランサはアイドル状態の接続を少なくとも 10 分間維持します。この期間が経過すると、ロードバランサはいつでもバックエンドに終了パケットを送信できます。

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

バックエンド HTTP キープアライブ タイムアウトが切れると、GFE または Envoy プロキシがバックエンド VM に TCP FIN を送信して、接続を正常に終了します。

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

再試行数

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

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

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

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

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

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

リクエスト処理

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

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

レスポンス処理

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

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

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

トラフィック分散

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

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

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

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

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

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

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

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

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

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

セッション アフィニティ

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

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

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

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

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

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

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

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

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 設定は、ピアが開始し、エンドポイントが受け入れるストリームの最大数を表します。Trusted 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 エラー率とリクエスト数はTrusted Cloud API または Trusted 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 は、従来のアプリケーション ロードバランサではサポートされていません。

WebSocket のサポート

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

gRPC のサポート

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

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

Trusted 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.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 早期データを明示的に有効または無効にする手順は次のとおりです。

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

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）拡張機能を使用しません。詳細については、ロードバランサからバックエンドへの暗号化をご覧ください。

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

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

次のステップ

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

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