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

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

Google Cloud 内部アプリケーション ロードバランサは、プロキシベースのレイヤ 7 ロードバランサです。これを使用すると、1 つの内部 IP アドレスの背後でサービスを実行し、スケールできます。この内部アプリケーション ロードバランサは、Compute Engine、Google Kubernetes Engine（GKE）、Cloud Run などのさまざまな Google Cloud プラットフォームでホストされているバックエンドに HTTP / HTTPS のトラフィックを分散します。詳しくは、ユースケースをご覧ください。

運用モード

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

• クロスリージョン内部アプリケーション ロードバランサ。これは、オープンソースの Envoy プロキシでマネージド サービスとして実装されるマルチリージョン ロードバランサです。クロスリージョン モードを使用すると、グローバルに分散しているバックエンド サービスにトラフィックをロードバランスできます。たとえば、最も近いバックエンドにトラフィックを転送するようにトラフィックを管理できます。このロードバランサは高可用性も実現します。バックエンドを複数のリージョンに配置すると、単一リージョンにおける障害を回避できます。1 つのリージョンのバックエンドが停止した場合に、トラフィックを別のリージョンにフェイルオーバーできます。

• リージョン内部アプリケーション ロードバランサ。これは、オープンソースの Envoy プロキシをベースにマネージド サービスとして実装されるリージョン ロードバランサです。リージョン モードでは、バックエンドが単一の Google Cloud リージョンに存在する必要があります。クライアントは、転送ルールでグローバル アクセスが無効か有効かに基づいて、そのリージョンに限定することも、任意のリージョンに配置することもできます。このロードバランサを使用すると、HTTP または HTTPS パラメータに基づく豊富なトラフィック制御機能を使用できます。ロードバランサの構成を終えると、トラフィックのニーズに応じて Envoy プロキシが自動的に割り当てられます。

  次の表に、クロスリージョン モードとリージョン モードの重要な違いを示します。

  ロードバランサ モード	機能
  	ロードバランサの仮想 IP アドレス（VIP）	クライアント アクセス	ロードバランスされたバックエンド	高可用性とフェイルオーバー
  クロスリージョン内部アプリケーション ロードバランサ	特定の Google Cloud リージョンのサブネットから割り振られます。 複数のリージョンの VIP アドレスは、同じグローバル バックエンド サービスを共有できます。DNS ベースのグローバル ロード バランシングを構成するには、DNS ルーティング ポリシーを使用して、クライアント リクエストを最も近い VIP アドレスに転送します。	常にグローバルにアクセス可能VPC 内の任意の Google Cloud リージョンのクライアントがロードバランサにトラフィックを送信できます。	グローバル バックエンド。 ロードバランサは、任意のリージョンのバックエンドにトラフィックを送信できます。	同一または異なるリージョンの正常なバックエンドへの自動フェイルオーバー。
  リージョン内部アプリケーション ロードバランサ	特定の Google Cloud リージョンのサブネットから割り振られます。	デフォルトでは、グローバルにアクセス可能ではありません。 必要に応じて、グローバル アクセスを有効にすることができます。	リージョン バックエンド。 ロードバランサは、ロードバランサのプロキシと同じリージョンにあるバックエンドにのみトラフィックを送信できます。	同じリージョン内の正常なバックエンドへの自動フェイルオーバー。

モードを特定する

アーキテクチャとリソース

次の図は、内部アプリケーション ロードバランサに必要な Google Cloud リソースを示しています。

クロスリージョン内部アプリケーション ロードバランサ

次の図は、同じ VPC ネットワーク内のプレミアム ティアにクロスリージョン内部アプリケーション ロードバランサをデプロイした場合のコンポーネントを示しています。各グローバル転送ルールは、クライアントが接続に使用するリージョン IP アドレスを使用します。

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

この図は、プレミアム ティアにリージョン内部アプリケーション ロードバランサをデプロイした場合のコンポーネントを示しています。

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

プロキシ専用サブネット

前の図では、プロキシ専用サブネットには、Google がユーザーに代わって Envoy プロキシを実行する際に使用する一連の IP アドレスが用意されています。内部アプリケーション ロードバランサを使用する VPC ネットワークのリージョンごとにプロキシ専用サブネットを 1 つ作成する必要があります。

次の表に、クロスリージョン モードとリージョン モードでのプロキシ専用サブネット間の違いを示します。クロスリージョン ロードバランサとリージョン ロードバランサで同じサブネットを共有することはできません。

ロードバランサ モード	プロキシ専用サブネットの --purpose フラグの値
クロスリージョン内部アプリケーション ロードバランサ	GLOBAL_MANAGED_PROXY ロードバランサが構成される各リージョンで、クロスリージョンの Envoy ベースのロードバランサにはプロキシ専用サブネットが必要です。同じリージョンとネットワークにあるクロスリージョン ロードバランサ プロキシは、同じプロキシ専用サブネットを共有します。
リージョン内部アプリケーション ロードバランサ	REGIONAL_MANAGED_PROXY リージョンと VPC ネットワーク内のすべてのリージョン Envoy ベースのロードバランサは、同じプロキシ専用サブネットを共有します。

関連情報:

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

転送ルールと IP アドレス

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

IP アドレスの指定。各転送ルールは、アプリケーションの DNS レコードで使用できる単一のリージョン IP アドレスを参照します。使用できる静的 IP アドレスを予約するか、Cloud Load Balancing から割り当てます。推奨されているのは静的 IP アドレスの予約です。静的アドレスを予約しない場合、転送ルールを削除して新しく作り直すたびに DNS レコードを編集して、新しく割り当てられたエフェメラル IP アドレスに直す必要があるからです。

クライアントは IP アドレスとポートを使用してロードバランサの Envoy プロキシに接続します。転送ルールの IP アドレスはロードバランサの IP アドレスです（仮想 IP アドレスまたは VIP と呼ぶこともあります）。ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。サポートされているプロトコルの一覧については、ロードバランサの機能の比較をご覧ください。

転送ルールに関連付けられた内部 IP アドレスは、バックエンドと同じネットワークとリージョンにあるサブネットから取得できます。

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

内部アプリケーション ロードバランサが使用する転送ルール、IP アドレス、ロード バランシング スキームのタイプは、ロードバランサのモードによって異なります。

クロスリージョン内部アプリケーション ロードバランサ
	転送ルール	globalForwardingRules.insert メソッド
	リージョン IP アドレス	addresses.insert メソッド
	ロード バランシング スキーム	INTERNAL_MANAGED
	IP アドレス（省略可）	SHARED_LOADBALANCER_VIP
	クライアントからロードバランサのフロントエンドへのルーティング	グローバル アクセスはデフォルトで有効になっており、VPC 内の任意のリージョンのクライアントがロードバランサにアクセスできます。バックエンドは複数のリージョンに配置できます。
リージョン内部アプリケーション ロードバランサ
	転送ルール	forwardingRules.insert メソッド
	リージョン IP アドレス	addresses.insert メソッド
	ロード バランシング スキーム	INTERNAL_MANAGED
	IP アドレス（省略可）	SHARED_LOADBALANCER_VIP
	クライアントからロードバランサのフロントエンドへのルーティング	グローバル アクセスを有効にして、VPC 内の任意のリージョンのクライアントがロードバランサにアクセス可能にできます。また、バックエンドもロードバランサと同じリージョンに存在する必要があります。

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

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

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

ターゲット プロキシ

ターゲット HTTP または HTTPS プロキシは、クライアントからの HTTP(S) 接続を終端します。HTTP(S) プロキシは、URL マップを参照してトラフィックをバックエンドに転送する方法を決定します。ターゲット HTTPS プロキシは、SSL 証明書を使用してクライアントに対して自身を認証します。

ロードバランサは、元のクライアント リクエストの Host ヘッダーを保持します。また、ロードバランサは X-Forwarded-For ヘッダーに 2 つの IP アドレスを追加します。

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

受信リクエストに X-Forwarded-For ヘッダーがない場合、ヘッダーの値はこの 2 つの IP アドレスだけです。リクエストに X-Forwarded-For ヘッダーがある場合、ロードバランサへのリクエスト中にプロキシによって記録された IP アドレスなどの他の情報は、2 つの IP アドレスの前に保持されます。ロードバランサは、このヘッダーの最後の 2 つの IP アドレスより前の IP アドレスを確認しません。

バックエンド サーバーとしてプロキシを実行している場合、このプロキシは通常、より多くの情報を X-Forwarded-For ヘッダーに追加するため、ソフトウェアでこれを考慮する必要がある場合があります。ロードバランサからプロキシされたリクエストは、プロキシ専用サブネットの IP アドレスから送信されます。バックエンド インスタンスのプロキシでは、このアドレスに加えて、バックエンド インスタンスの独自の IP アドレスを記録する場合があります。

アプリケーションで処理する必要があるトラフィックの種類に応じて、ターゲット HTTP プロキシまたはターゲット HTTPS プロキシを使用して、ロードバランサを構成できます。

次の表は、内部アプリケーション ロードバランサに必要なターゲット プロキシ API を示したものです。

ロードバランサ モード	ターゲット プロキシ
クロスリージョン内部アプリケーション ロードバランサ	targetHttpProxies targetHttpsProxies
リージョン内部アプリケーション ロードバランサ	regionTargetHttpProxies regionTargetHttpsProxies

SSL 証明書

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

次の表に、各モードの内部アプリケーション ロードバランサが必要とする SSL 証明書のタイプを示します。

ロードバランサ モード	SSL 証明書の種類
クロスリージョン内部アプリケーション ロードバランサ	Certificate Manager のセルフマネージド証明書と Google マネージド証明書。 Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。 パブリック DNS による DNS 認証。詳細については、DNS 認証を使用してグローバル Google マネージド証明書をデプロイするをご覧ください。 プライベート Certificate Authority Service。詳細については、CA Service インスタンスによって発行された Google マネージド証明書を作成するをご覧ください。 ロードバランサ認証を使用する Google マネージド証明書はサポートされていません。 Compute Engine SSL 証明書はサポートされていません。
リージョン内部アプリケーション ロードバランサ	Compute Engine リージョン SSL 証明書 Certificate Manager のセルフマネージド証明書と Google マネージド証明書。 Certificate Manager では、次のタイプの Google マネージド証明書がサポートされています。 プロジェクトごとの DNS 認証を使用するリージョン Google マネージド証明書。詳細については、リージョン Google マネージド証明書をデプロイするをご覧ください。 プライベート Certificate Authority Service を使用するリージョン Google マネージド証明書。詳細については、CA Service を使用してリージョン Google マネージド証明書をデプロイするをご覧ください。 ロードバランサ認証を使用する Google マネージド証明書はサポートされていません。

URL マップ

ターゲット HTTP(S) プロキシは、URL マップを使用して、HTTP 属性（リクエストパス、Cookie、ヘッダーなど）に基づいてルーティングを決定します。このルーティングの決定に基づいて、プロキシは特定のバックエンド サービスにクライアントのリクエストを転送します。URL マップには、ヘッダーの書き換え、クライアントへのリダイレクトの送信、タイムアウト ポリシーの構成など、追加のアクションを指定できます。

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

ロードバランサ モード	URL マップのタイプ
クロスリージョン内部アプリケーション ロードバランサ	urlMaps
リージョン内部アプリケーション ロードバランサ	regionUrlMaps

バックエンド サービス

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

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

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

ロードバランサ モード	バックエンド サービス リソース
クロスリージョン内部アプリケーション ロードバランサ	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）を使用してバックエンドと通信できます。

バックエンド

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

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

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

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

バックエンドのサブセット化

バックエンドのサブセット化は、リージョン内部アプリケーション ロードバランサでサポートされている機能で、各プロキシ インスタンスにバックエンドのサブセットを割り当てることでパフォーマンスとスケーラビリティを向上させます。

デフォルトでは、バックエンドのサブセット化は無効になっています。この機能を有効にする方法については、リージョン内部アプリケーション ロードバランサのバックエンドのサブセット化をご覧ください。

ヘルスチェック

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

ヘルスチェック プローブでは、上り（内向き）許可ファイアウォール ルールを作成してヘルスチェック プローブがバックエンド インスタンスに到達できるようにする必要があります。通常、ヘルスチェック プローブは Google の一元化されたヘルスチェックの仕組みにより発信されます。ただし、ハイブリッド NEG の場合、ヘルスチェックはプロキシ専用サブネットから開始します。詳細については、分散 Envoy ヘルスチェックをご覧ください。

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

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

次の表は、内部アプリケーション ロードバランサでサポートされているヘルスチェックのスコープを示したものです。

ロードバランサ モード	ヘルスチェックのタイプ
クロスリージョン内部アプリケーション ロードバランサ	healthChecks
リージョン内部アプリケーション ロードバランサ	regionHealthChecks

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

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

ファイアウォール ルール

内部アプリケーション ロードバランサには、次のファイアウォール ルールが必要です。

• Google の中央のヘルスチェック範囲からのトラフィックを許可する上り（内向き）許可ルール。特定のヘルスチェック プローブの IP アドレス範囲と、プローブからのトラフィックを許可する必要がある理由については、プローブの IP 範囲とファイアウォール ルールをご覧ください。
• プロキシ専用サブネットからのトラフィックを許可するための上り（内向き）許可ルール

これらの範囲については、ファイアウォール ルールの要件にいくつかの例外があります。

• ハイブリッド NEG では、Google のヘルスチェック プローブ範囲からのトラフィックを許可する必要はありません。ただし、1 つのバックエンド サービスでハイブリッド NEG とゾーン NEG の組み合わせを使用している場合は、ゾーン NEG の Google ヘルスチェック プローブ範囲からのトラフィックを許可する必要があります。
• リージョン インターネット NEG の場合、ヘルスチェックは省略可能です。リージョン インターネット NEG を使用するロードバランサからのトラフィックは、プロキシ専用サブネットから発信されます。このトラフィックは、Cloud NAT により、手動または自動的に割り振られた NAT IP アドレスに NAT 変換されます。このトラフィックには、ヘルスチェック プローブと、ロードバランサからバックエンドへのユーザー リクエストの両方が含まれます。詳細については、リージョン NEG: Cloud NAT ゲートウェイを使用するをご覧ください。

クライアント アクセス

クライアントは、同じネットワークまたは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワークに配置できます。

クロスリージョン内部アプリケーション ロードバランサの場合、グローバル アクセスはデフォルトで有効になっています。VPC 内の任意のリージョンのクライアントがロードバランサにアクセスできます。

リージョン内部アプリケーション ロードバランサの場合、クライアントは、デフォルトでロードバランサと同じリージョンに存在しなければなりません。グローバル アクセスを有効にして、VPC 内の任意のリージョンのクライアントがロードバランサにアクセス可能にできます。

次の表に、リージョン内部アプリケーション ロードバランサのクライアント アクセスの概要を示します。

グローバル アクセスが無効な場合	グローバル アクセスが有効な場合
クライアントはロードバランサと同じリージョンになければなりません。また、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。	クライアントはどのリージョンにでも配置できます。ただし、ロードバランサと同じ VPC ネットワーク、または VPC ネットワーク ピアリングを使用してロードバランサの VPC ネットワークに接続されている VPC ネットワークに存在する必要があります。
オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを介してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、ロードバランサと同じリージョンになければなりません。	オンプレミス クライアントは、Cloud VPN トンネルまたは VLAN アタッチメントを使用してロードバランサにアクセスできます。これらのトンネルまたはアタッチメントは、どのリージョンにでも配置できます。

GKE サポート

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

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

• GKE Ingress コントローラを使用して作成された内部 Ingress は、常にリージョン内部アプリケーション ロードバランサです。GKE Ingress コントローラは常に GCE_VM_IP_PORT ゾーン NEG バックエンドを使用します。

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

共有 VPC のアーキテクチャ

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

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

サブネットと IP アドレス	フロントエンド コンポーネント	バックエンド コンポーネント
共有 VPC ホスト プロジェクトで必要なネットワークとサブネット（プロキシ専用サブネットを含む）を作成します。 ロードバランサの内部 IP アドレスは、ホスト プロジェクトまたはサービス プロジェクトのいずれかで定義できますが、ホスト プロジェクト内の目的の共有 VPC ネットワークのサブネットを使用する必要があります。アドレス自体は、参照先サブネットのプライマリ IP 範囲から取得します。	リージョン内部 IP アドレス、転送ルール、ターゲット HTTP(S) プロキシ、関連付けられた URL マップは、同じプロジェクトで定義する必要があります。このプロジェクトは、ホスト プロジェクトまたはサービス プロジェクトにできます。	次のいずれかを行います。 バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を、フロントエンド コンポーネントと同じサービス プロジェクトに作成します。 必要な数のサービス プロジェクトで、バックエンド サービスとバックエンド（インスタンス グループ、サーバーレス NEG、その他のサポートされているバックエンド タイプ）を作成します。1 つの URL マップで複数のプロジェクトのバックエンド サービスを参照できます。このタイプのデプロイは、プロジェクト間のサービス参照と呼ばれます。 各バックエンド サービスは、参照するバックエンドと同じプロジェクトで定義する必要があります。バックエンド サービスに関連するヘルスチェックも、バックエンド サービスと同じプロジェクトで定義する必要があります。

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

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

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

ロードバランサは、ホスト プロジェクトの IP アドレスとサブネットを使用します。クライアントは、ロードバランサと同じ共有 VPC ネットワークとリージョンにある場合、内部アプリケーション ロードバランサにアクセスできます。クライアントは、ホスト プロジェクト、接続されたサービス プロジェクト、または任意の接続されたネットワークに配置できます。

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

サーバーレス NEG バックエンドを使用する内部アプリケーション ロードバランサの場合、バッキング Cloud Run サービス、バックエンド サービス、サーバーレス NEG は同じサービス プロジェクトに存在する必要があります。ロードバランサのフロントエンド コンポーネント（転送ルール、ターゲット プロキシ、URL マップ）は、ホスト プロジェクト、バックエンド コンポーネントと同じサービス プロジェクト、または同じ共有 VPC 環境内のサービス プロジェクトのいずれかに作成できます。

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

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

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

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

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

内部アプリケーション ロードバランサの場合、プロジェクト間のサービス参照は共有 VPC 環境内でのみサポートされます。

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

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

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

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

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

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

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

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

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

タイムアウトと再試行

内部アプリケーション ロードバランサは、次の種類のタイムアウトをサポートします。

タイムアウトの種類と説明	デフォルト値	カスタム値のサポート
		クロスリージョン	リージョン
バックエンド サービスのタイムアウト リクエストとレスポンスのタイムアウトロードバランサがリクエストの最初のバイトをバックエンドに送信してから、バックエンドが HTTP レスポンスの最後のバイトをロードバランサに返すまでの最長時間を表します。バックエンドがこの時間内に HTTP レスポンス全体をロードバランサに返さなかった場合、残りのレスポンス データは破棄されます。	バックエンド サービスのサーバーレス NEG の場合: 60 分 バックエンド サービスの他のバックエンド タイプの場合: 30 秒
クライアント HTTP キープアライブ タイムアウト クライアントとロードバランサのマネージド Envoy プロキシの間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。	610 秒
バックエンド HTTP キープアライブ タイムアウト ロードバランサのマネージド Envoy プロキシとバックエンド間の TCP 接続がアイドル状態である最長時間（同じ TCP 接続が複数の HTTP リクエストに使用される場合があります）。	10 分（600 秒）

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

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

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

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

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

内部アプリケーション ロードバランサで使用される WebSocket 接続の場合、アクティブな WebSocket 接続はバックエンド サービスのタイムアウトに従いません。アイドル状態の WebSocket 接続は、バックエンド サービスのタイムアウト後に終了します。

Google Cloud は、サービスを提供する Envoy ソフトウェア タスクの定期的な再起動、またはその数の変更を行います。バックエンド サービスのタイムアウト値が長いほど、Envoy タスクの再起動または置換によって TCP 接続が終了する可能性が高くなります。

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

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

クライアント HTTP キープアライブ タイムアウトは、TCP 接続が（ダウンストリーム）クライアントと Envoy プロキシ間でアイドル状態になっている最長時間を表します。デフォルトのクライアント HTTP キープアライブ タイムアウト値は 610 秒です。タイムアウトは 5～1,200 秒の値で構成できます。

HTTP キープアライブ タイムアウトは TCP アイドル タイムアウトとも呼ばれています。

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

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

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

内部アプリケーション ロードバランサは、（ダウンストリーム）クライアントと Envoy プロキシ間の最初の TCP 接続と、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 を送信して、接続を正常に終了します。

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

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

再試行

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

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

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

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

詳細については、内部アプリケーション ロードバランサのロギングとモニタリングをご覧ください。

接続ネットワークへのアクセス

クライアントが接続ネットワークから VPC ネットワーク内の内部アプリケーション ロードバランサにアクセスする方法は、次のとおりです。

• VPC ネットワーク ピアリング
• Cloud VPN と Cloud Interconnect

詳細な例については、内部アプリケーション ロードバランサと接続ネットワークをご覧ください。

セッション アフィニティ

アプリケーション ロードバランサのバックエンド サービスで構成されたセッション アフィニティにより、正常なバックエンド インスタンスまたはエンドポイントの数が一定のままであり、以前に選択したバックエンド インスタンスまたはエンドポイントの容量が上限に達していない限り、特定のクライアントからのリクエストが可能な限り同じバックエンドに送信されます。バランシング モードのターゲット容量により、バックエンドの容量が上限に達するタイミングが判断されます。

次の表に、さまざまなアプリケーション ロードバランサでサポートされているさまざまなタイプのセッション アフィニティ オプションの概要を示します。次のセクションのセッション アフィニティのタイプでは、各セッション アフィニティのタイプについて詳しく説明します。

表: サポートされているセッション アフィニティの設定

プロダクト

セッション アフィニティのオプション

クロスリージョン内部アプリケーション ロードバランサ リージョン内部アプリケーション ロードバランサ

なし（NONE） クライアント IP（CLIENT_IP） 生成した Cookie（GENERATED_COOKIE） ヘッダー フィールド（HEADER_FIELD） HTTP Cookie（HTTP_COOKIE） ステートフル Cookie ベース アフィニティ（STRONG_COOKIE_AFFINITY） また、次の点にもご注意ください。 ロード バランシングの局所性ポリシー（localityLbPolicy）の有効なデフォルト値は、セッション アフィニティの設定に応じて変わります。セッション アフィニティが構成されていない場合（セッション アフィニティがデフォルト値の NONE のままの場合）、localityLbPolicy のデフォルト値は ROUND_ROBIN です。セッション アフィニティが NONE 以外の値に設定されている場合、localityLbPolicy のデフォルト値は MAGLEV です。 内部アプリケーション ロードバランサの場合、重み付けによるトラフィック分割を使用する場合は、セッション アフィニティを構成しないでください。セッション アフィニティを構成した場合、重み付けトラフィック分割構成が優先されます。

セッション アフィニティを構成する際は、次の点に留意してください。

• 認証やセキュリティを目的としてセッション アフィニティに依存しないでください。ステートフル Cookie ベースのセッション アフィニティを除き、セッション アフィニティは、サービスの数と正常なバックエンドの数が変わるたびに失われる可能性があります。詳細については、セッション アフィニティの喪失をご覧ください。

• --session-affinity フラグと --subsetting-policy フラグのデフォルト値はどちらも NONE です。異なる値を設定できるのは一度に 1 つだけです。

セッション アフィニティのタイプ

内部アプリケーション ロードバランサのセッション アフィニティは、次のいずれかのカテゴリに分類できます。

• ハッシュベースのセッション アフィニティ（NONE、CLIENT_IP）
• HTTP ヘッダーベースのセッション アフィニティ（HEADER_FIELD）
• Cookie ベースのセッション アフィニティ（GENERATED_COOKIE、HTTP_COOKIE、STRONG_COOKIE_AFFINITY）

ハッシュベースのセッション アフィニティ

ハッシュベースのセッション アフィニティの場合、ロードバランサはコンシステント ハッシュ法のアルゴリズムを使用して、適格なバックエンドを選択します。セッション アフィニティの設定により、ハッシュの計算に使用される IP ヘッダーのフィールドが決まります。

ハッシュベースのセッション アフィニティには、次のタイプがあります。

• なし
• クライアント IP アフィニティ

なし

セッション アフィニティの設定の NONE は、セッション アフィニティがないことを意味するわけではありません。これは、セッション アフィニティ オプションが明示的に構成されていないことを意味します。

ハッシュは、バックエンドを選択するために常に実行されます。セッション アフィニティの設定が NONE の場合、ロードバランサは 5 タプルハッシュを使用してバックエンドを選択します。5 タプルハッシュは、送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成されます。

セッション アフィニティのデフォルト値は NONE です。

クライアント IP アフィニティ

クライアント IP セッション アフィニティ（CLIENT_IP）は、パケットの送信元 IP アドレスと宛先 IP アドレスから作成された 2 タプルハッシュです。クライアント IP アフィニティは、バックエンドに容量があり、正常な状態を維持している限り、同じクライアント IP アドレスからのすべてのリクエストを同じバックエンドに転送します。

クライアント IP アフィニティを使用する場合は、次の点に留意してください。

• パケットがロードバランサに直接送信される場合、パケットの宛先 IP アドレスはロードバランサの転送ルールの IP アドレスと同じになります。
• パケットが Google Cloud ロードバランサに配信される前に中間 NAT またはプロキシ システムによって処理されると、パケットの送信元 IP アドレスが元のクライアントに関連付けられた IP アドレスと一致しないことがあります。多くのクライアントが同じ有効な送信元 IP アドレスを共有する場合、一部のバックエンド VM は他の VM よりも多くの接続またはリクエストを受信する可能性があります。

HTTP ヘッダーベースのセッション アフィニティ

ヘッダー フィールド アフィニティで（HEADER_FIELD）は、バックエンド サービスの consistentHash.httpHeaderName フィールドの HTTP ヘッダーの値に基づいて、リクエストがバックエンドにルーティングされます。使用可能なすべてのバックエンドにリクエストを分散するには、各クライアントで異なる HTTP ヘッダー値を使用する必要があります。

ヘッダー フィールド アフィニティは、次の条件を満たす場合にサポートされます。

• ロード バランシングの局所性ポリシーが RING_HASH または MAGLEV である。
• バックエンド サービスの consistentHash が、HTTP ヘッダーの名前（httpHeaderName）を指定する。

Cookie ベースのセッション アフィニティ

Cookie ベースのセッション アフィニティには次のタイプがあります。

• 生成された Cookie アフィニティ
• HTTP Cookie アフィニティ
• ステートフル Cookie ベース セッション アフィニティ

生成された Cookie アフィニティ

生成された Cookie ベースのアフィニティ（GENERATED_COOKIE）を使用する場合、ロードバランサは最初の HTTP リクエストに応答して Set-Cookie ヘッダーに HTTP Cookie を含めます。

生成される Cookie の名前は、ロードバランサのタイプによって異なります。

プロダクト	Cookie 名
クロスリージョン内部アプリケーション ロードバランサ	GCILB
リージョン内部アプリケーション ロードバランサ	GCILB

生成された Cookie のパス属性は常にスラッシュ（/）になります。他のバックエンド サービスも生成された Cookie アフィニティを使用している場合、同じ URL マップ上のすべてのバックエンド サービスに適用されます。

affinityCookieTtlSec バックエンド サービス パラメータを使用して、Cookie の有効期間（TTL）値を 0～1,209,600 秒の範囲（両端を含む）で構成できます。affinityCookieTtlSec が指定されていない場合、デフォルトの TTL 値は 0 です。

クライアントが、HTTP リクエストの Cookie リクエスト ヘッダーに生成されたセッション アフィニティ Cookie を含めると、ロードバランサは、セッション アフィニティ Cookie が有効である限り、それらのリクエストを同じバックエンド インスタンスまたはエンドポイントに転送します。これを行うには、Cookie 値を、特定のバックエンド インスタンスまたはエンドポイントを参照するインデックスにマッピングし、生成された Cookie のセッション アフィニティ要件を満たすようにします。

生成された Cookie アフィニティを使用するには、次のバランシング モードと localityLbPolicy 設定を構成します。

• バックエンド インスタンス グループの場合は、RATE バランシング モードを使用します。
• バックエンド サービスの localityLbPolicy には、RING_HASH または MAGLEV を使用します。localityLbPolicy を明示的に設定しない場合、ロードバランサは暗黙のデフォルトとして MAGLEV を使用します。

詳細については、セッション アフィニティの喪失をご覧ください。

HTTP Cookie アフィニティ

HTTP Cookie ベースのアフィニティ（HTTP_COOKIE）を使用する場合、ロードバランサは最初の HTTP リクエストに応答して Set-Cookie ヘッダーに HTTP Cookie を含めます。Cookie の名前、パス、有効期間（TTL）を指定します。

すべてのアプリケーション ロードバランサは、HTTP Cookie ベースのアフィニティをサポートしています。

Cookie の TTL 値は、次のバックエンド サービス パラメータと有効な値を使用して、秒、秒未満（ナノ秒単位）、秒と秒未満（ナノ秒単位）のいずれかで構成できます。

• consistentHash.httpCookie.ttl.seconds は、0～315576000000 の値に設定できます（両端を含む）。
• consistentHash.httpCookie.ttl.nanos は、0～999999999 の値に設定できます（両端を含む）。単位はナノ秒であるため、999999999 は .999999999 秒を意味します。

consistentHash.httpCookie.ttl.seconds と consistentHash.httpCookie.ttl.nanos の両方が指定されていない場合は、代わりに affinityCookieTtlSec バックエンド サービス パラメータの値が使用されます。affinityCookieTtlSec が指定されていない場合、デフォルトの TTL 値は 0 です。

クライアントが、HTTP リクエストの Cookie リクエスト ヘッダーに HTTP セッション アフィニティ Cookie を含めると、ロードバランサは、セッション アフィニティ Cookie が有効である限り、それらのリクエストを同じバックエンド インスタンスまたはエンドポイントに転送します。これを行うには、Cookie 値を、特定のバックエンド インスタンスまたはエンドポイントを参照するインデックスにマッピングし、生成された Cookie のセッション アフィニティ要件を満たすようにします。

HTTP Cookie アフィニティを使用するには、次のバランシング モードと localityLbPolicy 設定を構成します。

• バックエンド インスタンス グループの場合は、RATE バランシング モードを使用します。
• バックエンド サービスの localityLbPolicy には、RING_HASH または MAGLEV を使用します。localityLbPolicy を明示的に設定しない場合、ロードバランサは暗黙のデフォルトとして MAGLEV を使用します。

詳細については、セッション アフィニティの喪失をご覧ください。

ステートフル Cookie ベース セッション アフィニティ

ステートフル Cookie ベース アフィニティ（STRONG_COOKIE_AFFINITY）を使用する場合、ロードバランサは最初の HTTP リクエストに応答して Set-Cookie ヘッダーに HTTP Cookie を含めます。Cookie の名前、パス、有効期間（TTL）を指定します。

従来のアプリケーション ロードバランサを除くすべてのアプリケーション ロードバランサは、ステートフル Cookie ベースのアフィニティをサポートしています。

Cookie の TTL 値は、秒、秒未満（ナノ秒単位）、秒と秒未満（ナノ秒単位）のいずれかで構成できます。strongSessionAffinityCookie.ttl で表される期間は、2 週間を超える値（1,209,600 秒）には設定できません。

Cookie の値は、選択したバックエンド インスタンスまたはエンドポイントを値自体にエンコードすることで識別します。Cookie が有効である限り、クライアントが後続の HTTP リクエストの Cookie リクエスト ヘッダーにセッション アフィニティ Cookie を含めると、ロードバランサは、選択したバックエンド インスタンスまたはエンドポイントにリクエストを転送します。

他のセッション アフィニティ方法とは異なり、

• ステートフル Cookie ベース アフィニティには、バランシング モードやロード バランシング局所性ポリシー（localityLbPolicy）に関する特定の要件はありません。

• 自動スケーリングによってマネージド インスタンス グループに新しいインスタンスが追加されても、ステートフル Cookie ベース アフィニティは影響を受けません。

• 選択したインスタンスが削除されない限り、自動スケーリングによってマネージド インスタンス グループからインスタンスが削除されても、ステートフル Cookie ベース アフィニティは影響を受けません。

• 選択したインスタンスが削除されない限り、自動修復によってマネージド インスタンス グループからインスタンスが削除されても、ステートフル Cookie ベース アフィニティは影響を受けません。

詳細については、セッション アフィニティの喪失をご覧ください。

Cookie ベースのアフィニティの TTL がゼロの場合の意味

生成された Cookie アフィニティ、HTTP Cookie アフィニティ、ステートフル Cookie ベースのアフィニティなど、すべての Cookie ベースのセッション アフィニティには TTL 属性があります。

TTL が 0 秒の場合、ロードバランサは Cookie に Expires 属性を割り当てません。この場合、クライアントは Cookie をセッション Cookie として扱います。セッションの定義は、クライアントによって異なります。

• ウェブブラウザなどの一部のクライアントは、ブラウジング セッション全体で Cookie を保持します。つまり、Cookie はアプリケーションが閉じられるまで複数のリクエストにわたって保持されます。

• 他のクライアントは、セッションを単一の HTTP リクエストとして扱い、直後に Cookie を破棄します。

セッション アフィニティの喪失

すべてのセッション アフィニティのオプションには、次の要件があります。

• 選択したバックエンド インスタンスまたはエンドポイントは、バックエンドとして構成されたままにする必要があります。セッション アフィニティは、次のいずれかのイベントが発生すると失われる可能性があります。
  • 選択したインスタンスをインスタンス グループから削除します。
  • マネージド インスタンス グループの自動スケーリングまたは自動修復により、選択したインスタンスがマネージド インスタンス グループから削除されます。
  • 選択したエンドポイントを NEG から削除します。
  • 選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG をバックエンド サービスから削除します。
• 選択したバックエンド インスタンスまたはエンドポイントは正常な状態を維持する必要があります。選択したインスタンスまたはエンドポイントでヘルスチェックが失敗すると、セッション アフィニティが失われる可能性があります。

ステートフル Cookie ベース セッション アフィニティを除き、すべてのセッション アフィニティ オプションには次の追加要件があります。

• 選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG は、ターゲット容量で定義されている容量を満たしてはなりません。（リージョン マネージド インスタンス グループの場合、選択したインスタンスを含むインスタンス グループのゾーン コンポーネントがいっぱいになっていないこと）。インスタンス グループまたは NEG がいっぱいで、他のインスタンス グループまたは NEG がいっぱいでない場合は、セッション アフィニティが破棄される可能性があります。UTILIZATION バランシング モードを使用すると、満杯状態が予測できない方法で変化する可能性があるため、RATE バランシング モードまたは CONNECTION バランシング モードを使用して、セッション アフィニティが破損する可能性のある状況を最小限に抑える必要があります。

• 構成されたバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、構成されたバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。

  • 新しいインスタンスまたはエンドポイントを追加する:

    • バックエンド サービスで、既存のインスタンス グループにインスタンスを追加します。
    • マネージド インスタンス グループの自動スケーリングでは、バックエンド サービスのマネージド インスタンス グループにインスタンスが追加されます。
    • バックエンド サービスで、既存の NEG にエンドポイントを追加します。
    • 空ではないインスタンス グループまたは NEG をバックエンド サービスに追加します。

  • 選択したインスタンスまたはエンドポイントだけでなく、インスタンスまたはエンドポイントを削除する:

    • インスタンス グループのバックエンドからインスタンスを削除した場合。
    • マネージド インスタンス グループの自動スケーリングまたは自動修復により、マネージド インスタンス グループのバックエンドからインスタンスが削除されます。
    • NEG バックエンドからエンドポイントを削除します。
    • 空ではない既存のバックエンド インスタンス グループまたは NEG をバックエンド サービスから削除します。

• 正常なバックエンド インスタンスまたはエンドポイントの合計数は一定にする必要があります。次のいずれかのイベントが 1 つ以上発生すると、正常なバックエンド インスタンスまたはエンドポイントの数が変わり、セッション アフィニティが破損する可能性があります。

  • インスタンスまたはエンドポイントがヘルスチェックに合格し、異常な状態から正常な状態に変わります。
  • インスタンスまたはエンドポイントがヘルスチェックに失敗し、正常な状態から異常な状態に移行するか、タイムアウトします。

フェイルオーバー

バックエンドが異常な状態になると、トラフィックは正常なバックエンドに自動的にリダイレクトされます。

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

ロードバランサ モード	フェイルオーバーの動作	すべてのバックエンドが異常な場合の動作
クロスリージョン内部アプリケーション ロードバランサ	同じリージョンまたは他のリージョン内の正常なバックエンドへの自動フェイルオーバー。 トラフィックは、構成されたトラフィック分散に基づいて、複数のリージョンにまたがる正常なバックエンド間で分散されます。	HTTP 503 を返す
リージョン内部アプリケーション ロードバランサ	同じリージョン内の正常なバックエンドへの自動フェイルオーバー。 Envoy プロキシは、構成されたトラフィック分散に基づいて、リージョン内の正常なバックエンドにトラフィックを送信します。	HTTP 503 を返す

高可用性とクロスリージョン フェイルオーバー

リージョン内部アプリケーション ロードバランサの場合

高可用性を実現するには、アプリケーションのトラフィックを最も適切にサポートするリージョンに、複数のリージョン内部アプリケーション ロードバランサをデプロイします。次に、Cloud DNS の位置情報ルーティング ポリシーを使用して、リージョンの停止中にロードバランサが応答しているかどうかを検出します。位置情報ポリシーは、クライアント リクエストの送信元に基づいて、次に最も近い使用可能なリージョンにトラフィックをルーティングします。ヘルスチェックは、内部アプリケーション ロードバランサでデフォルトで使用できます。

クロスリージョン内部アプリケーション ロードバランサの場合

複数のリージョンにクロスリージョン内部アプリケーション ロードバランサを設定すると、次のメリットが得られます。

1. リージョン内のクロスリージョン内部アプリケーション ロードバランサに障害が発生した場合、DNS ルーティング ポリシーは、別のリージョンのクロスリージョン内部アプリケーション ロードバランサにトラフィックを転送します。

   高可用性のデプロイ例は次のとおりです。

   • VPC ネットワークの RegionA リージョンと RegionB リージョンにフロントエンド仮想 IP アドレス（VIP）を持つクロスリージョン内部アプリケーション ロードバランサ。クライアントは RegionA リージョンに配置されています。
   • 2 つのリージョンのフロントエンド VIP を使用してロードバランサにアクセスできるようにし、DNS ルーティング ポリシーを使用してクライアントに最適な VIP を返すことができます。クライアントが地理的に最も近い VIP を使用するように設定する場合は、位置情報ルーティング ポリシーを使用します。
   • DNS ルーティング ポリシーは、リージョンの停止時に VIP が応答していないかどうかを検出し、次に最適な VIP をクライアントに返して、リージョンの停止中でもアプリケーションを維持できます。

   

2. 特定のリージョンのバックエンドが停止した場合、クロスリージョン内部アプリケーション ロードバランサのトラフィックは別のリージョンのバックエンドに正常にフェイルオーバーされます。

   クロスリージョン フェイルオーバーのデプロイは次のとおりです。

   • VPC ネットワークの RegionA リージョンにフロントエンド VIP アドレスを持つクロスリージョン内部アプリケーション ロードバランサがあります。クライアントも RegionA リージョンにあります。
   • RegionA と RegionB の Google Cloud リージョンのバックエンドを参照するグローバル バックエンド サービス。
   • RegionA リージョンのバックエンドが停止している場合、トラフィックは RegionB リージョンにフェイルオーバーされます。

   

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

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 値（最大値は 100）を受け入れます。リクエスト方向（Google Cloud ロードバランサ → gRPC サーバー）では、ロードバランサは gRPC サーバーからの最初の SETTINGS フレームを使用して、接続ごとに同時に使用できるストリームの数を決定します。サーバーが 100 より大きい値をアドバタイズした場合、ロードバランサは同時ストリームの最大数として 100 を使用します。値 0 がアドバタイズされると、ロードバランサはリクエストをサーバーに転送できないため、エラーが発生する可能性があります。

HTTP/2 動的ヘッダー テーブル サイズ

HTTP/2 は HTTP/1.1 から大幅に改善され、多重化や HPACK ヘッダー圧縮などの機能を備えています。HPACK では、動的テーブルの使用によってヘッダーの圧縮率が強化され、すべての処理が高速化されます。HTTP/2 の動的ヘッダー テーブル サイズの変更による影響、この機能によってパフォーマンスが改善する仕組み、さまざまな HTTP クライアント ライブラリの特定のバグが HPACK ヘッダー圧縮で引き起こす可能性がある問題については、コミュニティ記事をご覧ください。

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 ステータス コードが記録されます。

クリアテキスト TCP 経由の HTTP/2

クリアテキスト TCP 経由の HTTP/2（RFC 7540 の規定により、文字列「h2c」で表されます）を使用すると、TLS 暗号化なしで HTTP/2 を使用できます。次の接続でサポートされています。

• クライアントからロードバランサ: 自動的にサポートされます。特別な構成は必要ありません。

• ロードバランサからバックエンド: バックエンド サービス プロトコルを H2C に設定することでサポートされます。

H2C サポートは、GKE Gateway コントローラと Cloud Service Mesh を使用して作成されたロードバランサでも利用できますが、従来のアプリケーション ロードバランサではサポートされていません。

gRPC のサポート

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

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

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

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

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

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

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

TLS サポート

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

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

相互 TLS のサポート

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

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

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

制限事項

• リージョンの 1 つのゾーン内のクライアントからのリクエストが、クライアントと同じゾーンにあるバックエンドに送信される保証はありません。セッション アフィニティによってゾーン間の通信は減少しません。

• 内部アプリケーション ロードバランサは、次の機能に対応していません。

  • Cloud CDN
  • Compute Engine Google マネージド SSL 証明書（Certificate Manager Google マネージド証明書がサポートされています）

• 内部アプリケーション ロードバランサで Certificate Manager 証明書を使用するには、API または gcloud CLI を使用する必要があります。Google Cloud コンソールでは、Certificate Manager 証明書はサポートされていません。

• 内部アプリケーション ロードバランサは、TLS でのみ HTTP/2 をサポートします。

• 内部アプリケーション ロードバランサに接続するクライアントは、HTTP バージョン 1.1 以降を使用する必要があります。HTTP 1.0 はサポートされていません。

• プロキシ専用サブネットで IP アドレスが不足している場合、Google Cloud から警告は表示されません。

• 内部アプリケーション ロードバランサが使用する内部転送ルールには、ポートを 1 つだけ設定する必要があります。

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

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

• 内部アプリケーション ロードバランサは、Cloud Functions 第 1 世代と App Engine をサポートしていません。詳細については、サーバーレス NEG の概要: サポートされているロードバランサをご覧ください。

• 内部アプリケーション ロードバランサは Cloud Trace をサポートしていません。

次のステップ

• 共有 VPC 設定でロード バランシングを構成する。共有 VPC を使用した内部アプリケーション ロードバランサを設定するをご覧ください。

• GKE Pod で実行するサービスのロード バランシングを構成する。GKE Gateway のデプロイ、スタンドアロン NEG を使用したコンテナ ネイティブのロード バランシング、内部アプリケーション ロードバランサをスタンドアロン NEG に接続するのセクションをご覧ください。

• プロキシ専用サブネットのリソースを管理する。Envoy ベースのロードバランサのプロキシ専用サブネットをご覧ください。

• リージョン内部アプリケーション ロードバランサでバックエンドのサブセット化を構成する。バックエンドのサブセット化をご覧ください。

• Private Service Connect を使用してリージョン内部アプリケーション ロードバランサを構成する。バックエンド経由でリージョン Google API にアクセスするをご覧ください。

• ロード バランシングのデータパスにカスタム ロジックを挿入するために、Cloud Load Balancing 拡張機能を構成する。