バックエンド サービスは、Cloud Load Balancing によるトラフィックの分散方法を定義します。バックエンド サービスの構成には、バックエンドへの接続に使用されるプロトコル、さまざまな配信とセッションの設定、ヘルスチェック、タイムアウトなどの値が含まれます。これらの設定により、ロードバランサの動作を細かく制御できます。ほとんどの設定にはデフォルト値が用意されているので、簡単な構成ですぐに使い始めることができます。バックエンド サービスのスコープは グローバルまたはリージョンです。
ロードバランサ、Envoy プロキシ、プロキシレス gRPC クライアントは、バックエンド サービス リソースの構成情報を使用して次のことを行います。
- トラフィックを正しいバックエンド、すなわちインスタンス グループまたはネットワーク エンドポイント グループ（NEG）に転送する。
- 各バックエンドで設定されたバランシング モードに従ってトラフィックを分散する。
- バックエンドの状態をモニタリングしているヘルスチェックを判別する。
- セッション アフィニティを指定する。
- 特定のロードバランサでのみ使用される以下のサービスなど、他のサービスが有効になっているかどうかを確認する。
- Cloud CDN
- Google Cloud Armor セキュリティ ポリシー
- Identity-Aware Proxy
- App Hub（プレビュー版）で、リージョン バックエンド サービスをサービスとして指定します。
これらの値は、バックエンド サービスを作成するとき、またはバックエンド サービスにバックエンドを追加するときに設定します。
グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを使用していて、バックエンドが静的コンテンツを配信する場合、バックエンド サービスの代わりにバックエンド バケットを使用することを検討してください。次の表は、どのロードバランサがバックエンド サービスを使用しているかをまとめたものです。また、使用しているプロダクトによって、バックエンド サービスの最大数、バックエンド サービスのスコープ、サポートされているバックエンド タイプ、バックエンド サービスのロード バランシング スキームが決まります。ロード バランシング スキームは、Google が転送ルールとバックエンド サービスを分類するために使用する識別子です。各ロード バランシング プロダクトは、転送ルールとバックエンド サービスに 1 つのロード バランシング スキームを使用します。スキームの中には、プロダクト間で共有されるものもあります。
| プロダクト | バックエンド サービスの最大数 | バックエンド サービスのスコープ | サポートされているバックエンドの種類 | ロード バランシング スキーム |
|---|---|---|---|---|
| グローバル外部アプリケーション ロードバランサ | 複数 | グローバル | 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL_MANAGED |
| 従来のアプリケーション ロードバランサ | 複数 | グローバル* | 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL |
| リージョン外部アプリケーション ロードバランサ | 複数 | リージョン | 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL_MANAGED |
| クロスリージョン内部アプリケーション ロードバランサ | 複数 | グローバル | 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
INTERNAL_MANAGED |
| リージョン内部アプリケーション ロードバランサ | 複数 | リージョン | 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
INTERNAL_MANAGED |
| グローバル外部プロキシ ネットワーク ロードバランサ | 1 | グローバル | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL_MANAGED |
| 従来のプロキシ ネットワーク ロードバランサ | 1 | グローバル* | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL |
| リージョン外部プロキシ ネットワーク ロードバランサ | 1 | リージョン | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL_MANAGED |
| リージョン内部プロキシ ネットワーク ロードバランサ | 1 | リージョン | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
INTERNAL_MANAGED |
| クロスリージョン内部プロキシ ネットワーク ロードバランサ | 複数 | グローバル | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
INTERNAL_MANAGED |
| 外部パススルー ネットワーク ロードバランサ | 1 | リージョン | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
EXTERNAL |
| 内部パススルー ネットワーク ロードバランサ | 1 | リージョン タイプですが、グローバルにアクセスできるように構成可能です。 | バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
INTERNAL |
| Cloud Service Mesh | 複数 | グローバル | 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
|
INTERNAL_SELF_MANAGED |
- 転送ルールとその外部 IP アドレスはリージョン単位です。
- バックエンド サービスに接続されているすべてのバックエンドは、転送ルールと同じリージョンに配置する必要があります。
GCE_VM_IP_PORT タイプのエンドポイントでのみデュアルスタックをサポートします。
バックエンド
バックエンドは、Google Cloud ロードバランサ、Cloud Service Mesh で構成された Envoy プロキシ、 またはプロキシレス gRPC クライアントからトラフィックを受信する 1 つ以上のエンドポイントです。バックエンドにはいくつかの種類があります。
- 仮想マシン（VM）インスタンスを含むインスタンス グループ。インスタンス グループは、自動スケーリングの適用の有無にかかわらず、マネージド インスタンス グループ（MIG）または非マネージド インスタンス グループとして設定できます。複数のバックエンド サービスからインスタンス グループを参照できますが、そのインスタンス グループを参照するすべてのバックエンド サービスが同じ負荷分散モードを使用することが必須となります。
- ゾーン NEG
- サーバーレス NEG
- インターネット NEG
- ハイブリッド接続 NEG
- Private Service Connect NEG
- ポート マッピング NEG（プレビュー）
- Service Directory サービス バインディング
バックエンド サービスに関連付けられているバックエンド インスタンス グループまたは NEG は削除できません。インスタンス グループまたは NEG を削除する前に、参照元であるすべてのバックエンド サービスからバックエンドとして削除する必要があります。
インスタンス グループ
このセクションでは、インスタンス グループがバックエンド サービスでどのように機能するのかについて説明します。
バックエンド VM と外部 IP アドレス
バックエンド サービスのバックエンド VM には外部 IP アドレスは必要ありません。
- グローバル外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサの場合: クライアントは、ロードバランサの外部 IP アドレスをホストする Google Front End（GFE）と通信します。GFE は、バックエンドの VPC ネットワークの識別子をバックエンドの内部 IPv4 アドレスと結合して作成された内部アドレスにパケットを送信することにより、バックエンド VM またはエンドポイントと通信します。特別なルートですが、GFE とバックエンド VM またはエンドポイント間の通信は容易です。
- インスタンス グループのバックエンドの場合、内部 IPv4 アドレスは常に、VM の
nic0インターフェースに対応するプライマリ内部 IPv4 アドレスになります。 - ゾーン NEG 内の
GCE_VM_IP_PORTエンドポイントの場合、VM のネットワーク インターフェースに関連付けられたプライマリ IPv4 アドレス、または VM のネットワーク インターフェースに関連付けられたエイリアス IP アドレス範囲の IPv4 アドレスとして、エンドポイントの IP アドレスを指定できます。
- インスタンス グループのバックエンドの場合、内部 IPv4 アドレスは常に、VM の
リージョン外部アプリケーション ロードバランサの場合: クライアントは、ロードバランサの外部 IP アドレスをホストする Envoy プロキシと通信します。Envoy プロキシは、バックエンドの VPC ネットワークの識別子をバックエンドの内部 IPv4 アドレスと結合して作成された内部アドレスにパケットを送信することにより、バックエンド VM またはエンドポイントと通信します。
- インスタンス グループのバックエンドの場合、内部 IPv4 アドレスは常に、VM の
nic0インターフェースに対応するプライマリ内部 IPv4 アドレスになります。nic0は、ロードバランサと同じネットワークに存在する必要があります。 - ゾーン NEG 内の
GCE_VM_IP_PORTエンドポイントの場合、ネットワーク インターフェースがロードバランサと同じネットワーク内にある限り、VM のネットワーク インターフェースに関連付けられたプライマリ IPv4 アドレス、または VM のネットワーク インターフェースに関連付けられたエイリアス IP アドレス範囲の IPv4 アドレスとして、エンドポイントの IP アドレスを指定できます。
- インスタンス グループのバックエンドの場合、内部 IPv4 アドレスは常に、VM の
外部パススルー ネットワーク ロードバランサの場合: クライアントは、Google の Maglev パススルー ロード バランシング インフラストラクチャを介してバックエンドと直接通信します。パケットは、元の送信元 IP アドレスと宛先 IP アドレスを保持した状態でバックエンドにルーティングされ、配信されます。バックエンドは、ダイレクト サーバー リターンを使用してクライアントに応答します。バックエンドの選択と接続の追跡に使用される方法は構成可能です。
- インスタンス グループのバックエンドの場合、パケットは常に VM の
nic0インターフェースに配信されます。 - ゾーン NEG 内の
GCE_VM_IPエンドポイントの場合、パケットは NEG に関連付けられたサブネットワーク内にある VM のネットワーク インターフェースに配信されます。
- インスタンス グループのバックエンドの場合、パケットは常に VM の
名前付きポート
バックエンド サービスの名前付きポート属性は、インスタンス グループ バックエンドを使用するプロキシ ロードバランサにのみ適用されます。名前付きポートは、プロキシ（GFE または Envoy）とバックエンド インスタンス間の TCP 接続に使用される宛先ポートを定義します。
名前付きポートは次のように構成されます。
インスタンス グループのバックエンドごとに、Key-Value ペアを使用して 1 つ以上の名前付きポートを構成する必要があります。キーには、わかりやすいポート名を選択します。値は、ポート名に割り当てるポート番号です。名前と番号のマッピングは、インスタンス グループのバックエンドごとに個別に行われます。
バックエンド サービスで、ポート名（
--port-name）のみを使用して単一の名前付きポートを指定します。
インスタンス グループのバックエンドごとに、バックエンド サービスはポート名をポート番号に変換します。インスタンス グループの名前付きポートがバックエンド サービスの --port-name と一致すると、バックエンド サービスは、このポート番号をインスタンス グループの VM との通信に使用します。
たとえば、インスタンス グループに my-service-name という名前の名前付きポートとポート 8888 を設定できます。
gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
--named-ports=my-service-name:8888
次に、バックエンド サービスの --port-name を my-service-name に設定して、バックエンド サービス構成の名前付きポートを参照します。
gcloud compute backend-services update my-backend-service \
--port-name=my-service-name
各インスタンス グループが同じポート名に異なるポート番号を指定している場合は、バックエンド サービスが異なるインスタンス グループの VM と通信するときに、別のポート番号を使用できます。
プロキシ ロードバランサのバックエンド サービスが使用する解決済みのポート番号は、ロードバランサの転送ルールで使用されるポート番号と一致する必要はありません。プロキシ ロードバランサは、転送ルールの IP アドレスと宛先ポートに送信された TCP 接続をリッスンします。プロキシはバックエンドへの 2 つ目の TCP 接続を開くため、2 つ目の TCP 接続の宛先ポートは異なる場合があります。
名前付きポートは、インスタンス グループのバックエンドにのみ適用されます。GCE_VM_IP_PORT エンドポイントを持つゾーン NEG、NON_GCP_PRIVATE_IP_PORT エンドポイントを持つハイブリッド NEG、インターネット NEG は異なるメカニズムを使用してポートを定義します（つまりエンドポイント自体にポートを定義します）。 サーバーレス NEG は Google サービスを参照し、PSC NEG は宛先ポートの指定を含まない抽象化を使用してサービス アタッチメントを参照します。
内部パススルー ネットワーク ロードバランサと外部パススルー ネットワーク ロードバランサは、名前付きポートを使用しません。これは、新しい接続を作成するのではなく、接続をバックエンドに直接ルーティングするパススルー ロードバランサであるためです。パケットはバックエンドに配信され、ロードバランサの転送ルールの宛先 IP アドレスとポートが保持されます。
名前付きポートの作成方法については、次の手順をご覧ください。
- 非マネージド インスタンス グループ: 名前付きポートの操作
- マネージド インスタンス グループ: マネージド インスタンス グループへの名前付きポートの割り当て
インスタンス グループに関する制限とガイダンス
ロードバランサのインスタンス グループを作成する際は、次の制限とガイダンスに留意してください。
ロードバランスされた複数のインスタンス グループに VM を配置しないでください。VM が 2 つ以上の非マネージド インスタンス グループのメンバー、または 1 つのマネージド インスタンス グループと 1 つ以上の非マネージド インスタンス グループのメンバーである場合、Google Cloud では、一度に特定のバックエンド サービスのバックエンドとして使用できるのは、これらのインスタンス グループの 1 つに制限されます。
VM が複数のロードバランサに参加する必要がある場合は、同じインスタンス グループを各バックエンド サービスのバックエンドとして使用する必要があります。
プロキシ ロードバランサの場合、トラフィックを異なるポートに分散するときには、1 つのインスタンス グループに必要な名前付きポートを指定し、各バックエンド サービスが一意の名前付きポートをサブスクライブするように設定します。
同じインスタンス グループを複数のバックエンド サービスのバックエンドとして使用できます。この場合、バックエンドで互換性のあるバランシング モードを使用する必要があります。互換性とはつまり、バランシング モードが同じか、
CONNECTIONとRATEの組み合わせでなければなりません。互換性のないバランシング モードの組み合わせは次のとおりです。
UTILIZATIONとCONNECTIONRATEとUTILIZATION
次の例を考えてみます。
- 2 つのバックエンド サービスがあります。
external-https-backend-serviceは外部アプリケーション ロードバランサ用、internal-tcp-backend-serviceは内部パススルー ネットワーク ロードバランサ用です。 internal-tcp-backend-serviceでinstance-group-aというインスタンス グループを使用しています。- 内部パススルー ネットワーク ロードバランサは
CONNECTIONバランシング モードのみをサポートするため、internal-tcp-backend-serviceではCONNECTIONバランシング モードを適用する必要があります。 external-https-backend-serviceでRATEバランシング モードを適用する場合は、external-https-backend-serviceでinstance-group-aを使用することもできます。UTILIZATION分散モードを使用するexternal-https-backend-serviceの場合は、instance-group-aを使用できません。
複数のバックエンド サービスのバックエンドとして機能するインスタンス グループの負荷分散モードを変更するには:
- 1 つを除くすべてのバックエンド サービスからインスタンス グループを削除します。
- 残り 1 つのバックエンド サービスのバックエンドの負荷分散モードを変更します。
- 残りのバックエンド サービスが新しい負荷分散モードをサポートしている場合は、インスタンス グループをバックエンドとして再度バックエンド サービスに追加します。
インスタンス グループが複数のバックエンド サービスに関連付けられている場合、各バックエンド サービスは、インスタンス グループの同じ名前付きポートまたは異なる名前付きポートを参照できます。
自動スケーリングされたマネージド インスタンス グループを複数のバックエンド サービスに追加しないことをおすすめします。これを行うと、特に HTTP 負荷分散使用率の自動スケーリング指標を使用する場合に、グループ内のインスタンスが予測不能かつ不必要にスケーリングされる可能性があります。
- 自動スケーリング指標が CPU 使用率またはロードバランサの処理能力に関係のない Cloud Monitoring 指標の場合、このシナリオが機能する可能性がありますが、これはおすすめしません。これらの自動スケーリング指標のいずれかを使用すると、不安定なスケーリングを防止できます。
ゾーン ネットワーク エンドポイント グループ
ネットワーク エンドポイントは、インスタンス グループ内の VM を参照するのではなく、IP アドレスまたは IP アドレスとポートの組み合わせによってサービスを表します。ネットワーク エンドポイント グループ（NEG）は、ネットワーク エンドポイントの論理的なグループです。
ゾーン ネットワーク エンドポイント グループ（NEG）は、1 つのサブネット内の Google Cloud リソースの IP アドレスまたは IP アドレスとポートの組み合わせのコレクションに相当するゾーンのリソースです。
ゾーン NEG をバックエンドとして使用するバックエンド サービスは、VM 内で実行されているアプリケーションやコンテナ間でトラフィックを分散します。
ゾーン NEG で使用できるネットワーク エンドポイントには次の 2 種類があります。
GCE_VM_IPエンドポイント（内部パススルー ネットワーク ロードバランサとバックエンド サービスベースの外部パススルー ネットワーク ロードバランサでのみサポートされます）。GCE_VM_IP_PORTエンドポイント。
ゾーン NEG バックエンドをサポートするプロダクトを確認するには、表: バックエンド サービスとサポートされているバックエンド タイプをご覧ください。
詳細については、ゾーン NEG の概要をご覧ください。
インターネット ネットワーク エンドポイント グループ
インターネット NEG は、グローバル外部バックエンドを定義するグローバル リソースです。外部バックエンドは、オンプレミス インフラストラクチャ内またはサードパーティによって提供されるインフラストラクチャ内でホストされるバックエンドです。
インターネット NEG は、ホスト名または IP アドレスとポート（オプション）の組み合わせです。インターネット NEG で使用できるネットワーク エンドポイントには、INTERNET_FQDN_PORT と INTERNET_IP_PORT の 2 種類があります。
詳細については、インターネット ネットワーク エンドポイント グループの概要をご覧ください。
サーバーレス ネットワーク エンドポイント グループ
ネットワーク エンドポイント グループ（NEG）は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、Cloud Run、App Engine、Cloud Run 関数、または API Gateway を指すバックエンドです。
サーバーレス NEG は次のいずれかを表します。
- Cloud Run サービスまたはサービスのグループ。
- Cloud Run 関数の関数または関数のグループ。
- App Engine アプリ（スタンダードまたはフレキシブル）、アプリ内の特定のサービス、アプリの特定のバージョン、またはサービスのグループ。
- API Gateway。サービスの実装に関係なく、すべてのサービスで一貫した REST API を介してサービスへのアクセスを提供します。この機能はプレビュー版です。
URL パターンを共有するサーバーレス アプリケーションにサーバーレス NEG を設定するには、URL マスクを使用します。URL マスクは、URL スキーマ（example.com/<service> など）のテンプレートです。サーバーレス NEG はこのテンプレートを使用して、受信リクエストの URL から <service> 名を抽出し、一致する Cloud Run、Cloud Run 関数、または App Engine サービスに同じ名前でリクエストを転送します。
サーバーレス NEG バックエンドをサポートするロードバランサを確認するには、表: バックエンド サービスとサポートされているバックエンド タイプをご覧ください。
サーバーレス NEG の詳細については、サーバーレス ネットワーク エンドポイント グループの概要をご覧ください。
サービス バインディング
サービス バインディングは、Cloud Service Mesh のバックエンド サービスと Service Directory に登録されたサービスとの間に接続を確立するバックエンドです。バックエンド サービスでは複数のサービス バインディングを参照できます。サービス バインディングがあるバックエンド サービスでは、他のタイプのバックエンドを参照できません。
バックエンドの混在
1 つのバックエンド サービスに異なるタイプのバックエンドを追加する場合、次の使用上の考慮事項が適用されます。
- 1 つのバックエンド サービスで、インスタンス グループとゾーン NEG の両方を同時に使用することはできません。
- 同じバックエンド サービスで異なる種類のインスタンス グループを組み合わせて使用できます。たとえば、1 つのバックエンド サービスは、マネージド インスタンス グループと非マネージド インスタンス グループの両方の組み合わせを参照できます。互換性があるバックエンドとバックエンド サービスの組み合わせについては、前のセクションの表をご覧ください。
- 特定のプロキシ ロードバランサでは、ゾーン NEG（
GCE_VM_IP_PORTエンドポイントを含む）とハイブリッド接続 NEG（NON_GCP_PRIVATE_IP_PORTエンドポイントを含む）の組み合わせを使用して、ハイブリッド ロード バランシングを構成できます。この機能を持つロードバランサを確認するには、表: バックエンド サービスとサポートされているバックエンド タイプをご覧ください。
バックエンドへのプロトコル
バックエンド サービスを作成する場合は、バックエンドとの通信に使用するプロトコルを指定する必要があります。指定できるプロトコルはバックエンド サービスごとに 1 つのみです。フォールバックとして使用するセカンダリ プロトコルを指定することはできません。
有効なプロトコルは、ロードバランサの種類 と Cloud Service Mesh を使用しているかどうかによって異なります。
| プロダクト | バックエンド サービスのプロトコル オプション |
|---|---|
| アプリケーション ロードバランサ | HTTP、HTTPS、HTTP/2 |
| プロキシ ネットワーク ロードバランサ | TCP または SSL リージョン プロキシ ネットワーク ロードバランサは、TCP のみをサポートします。 |
| パススルー ネットワーク ロードバランサ | TCP、UDP、または UNSPECIFIED |
| Cloud Service Mesh | HTTP、HTTPS、HTTP/2、gRPC、TCP |
バックエンド サービスのプロトコルを変更すると、ロードバランサ経由でバックエンドに数分間アクセスできなくなります。
IP アドレス選択ポリシー
このフィールドは、プロキシ ロードバランサで使用できます。IP アドレス選択ポリシーを使用して、バックエンド サービスからバックエンドに送信されるトラフィック タイプを指定する必要があります。
IP アドレス選択ポリシーを選択する場合は、選択したトラフィック タイプがバックエンドでサポートされていることを確認してください。詳細については、表: バックエンド サービスとサポートされているバックエンド タイプをご覧ください。
IP アドレス選択ポリシーは、ロードバランサのバックエンド サービスを別のトラフィック タイプをサポートするように変換する場合に使用します。詳細については、シングルスタックからデュアルスタックに変換するをご覧ください。
IP アドレス選択ポリシーには、次の値を指定できます。
| IP アドレス選択ポリシー | 説明 |
|---|---|
| IPv4 のみ | クライアントから GFE へのトラフィックに関係なく、バックエンド サービスのバックエンドに IPv4 トラフィックのみを送信します。バックエンドのヘルスチェックには、IPv4 ヘルスチェックのみが使用されます。 |
| IPv6 優先 | バックエンドで IPv4 接続よりも IPv6 接続を優先します（IPv6 アドレスを持つ正常なバックエンドがある場合）。 ヘルスチェックは、バックエンドの IPv6 接続と IPv4 接続を定期的にモニタリングします。GFE は最初に IPv6 接続を試みます。IPv6 接続が切断された場合や遅い場合、GFE は Happy Eyeballs を使用してフォールバックし、IPv4 に接続します。 IPv6 接続または IPv4 接続のいずれかが正常でない場合でも、バックエンドは正常と見なされ、GFE は両方の接続を試行できます。最終的に、使用する接続が Happy Eyeballs によって選択されます。 |
| IPv6 のみ | クライアントからプロキシへのトラフィックに関係なく、バックエンド サービスのバックエンドに IPv6 トラフィックのみを送信します。バックエンドのヘルスチェックには、IPv6 ヘルスチェックのみが使用されます。 バックエンド トラフィック タイプが IP アドレス選択ポリシーと一致しているかどうかを確認するために特別な検証操作を行う必要はありません。たとえば、IPV4 バックエンドがあり、IP アドレス選択ポリシーとして |
ロードバランサとバックエンド間の暗号化
ロードバランサとバックエンド間の暗号化については、バックエンドへの暗号化をご覧ください。
トラフィック分散
バックエンドの動作は、バックエンド サービス リソースの以下のフィールドの値で決まります。
- バランシング モードは、ロードバランサが新しいリクエストまたは新しい接続のバックエンドの準備状況を測定する方法を定義します。
- ターゲット容量は、ターゲットの最大接続数、ターゲットの最大レート、またはターゲットの最大 CPU 使用率を定義します。
- 容量スケーラーは、ターゲット容量を変更せずに使用可能な容量全体を調整するために使用できます。
バランシング モード
バランシング モードでは、ロードバランサ または Cloud Service Mesh のバックエンドが追加のトラフィックを処理できるかどうか、または完全に読み込まれるかどうかを判別します。Google Cloud には次の 3 つのバランシング モードがあります。
CONNECTION: バックエンドが処理できる接続の合計数に基づいて負荷をどのように分散するかを決定します。RATE: 1 秒あたりのリクエスト（クエリ）の目標最大数（RPS、QPS）。すべてのバックエンドが容量を超えると、目標最大 RPS / QPS を超過する場合があります。UTILIZATION: インスタンス グループ内のインスタンスの使用率に基づいてロード バランシングの方法を決定します。
各ロードバランサで使用できるバランシング モード
バックエンド サービスにバックエンドを追加する際に、バランシング モードを設定します。ロードバランサで使用できるバランシング モードは、ロードバランサの種類とバックエンドの種類によって異なります。
パススルー ネットワーク ロードバランサには CONNECTION バランシング モードが必要ですが、ターゲット容量の設定はサポートされていません。
アプリケーション ロードバランサは、インスタンス グループ バックエンドに対して RATE または UTILIZATION バランシング モードをサポートします。GCE_VM_IP_PORT エンドポイントを含むゾーン NEG には RATE バランシング モードを、ハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT エンドポイント）に対しては RATE バランシング モードをサポートします。サポートされている他の種類のバックエンドの場合は、バランシング モードを省略する必要があります。
従来のアプリケーション ロードバランサの場合、クライアントのロケーションに基づいてリージョンが選択さ、ロード バランシング モードのターゲット容量に基づいて、リージョンに使用可能な容量があるかどうかが決まります。リージョン内では、バランシング モードのターゲット容量を使用して、リージョン内の各バックエンドに送信するリクエスト数の比率が計算されます。リクエストまたは接続は、ラウンドロビン方式によりバックエンド内のインスタンスまたはエンドポイント間で分散されます。
グローバル外部アプリケーション ロードバランサの場合、クライアントのロケーションに基づいてリージョンが選択さ、ロード バランシング モードのターゲット容量に基づいて、リージョンに使用可能な容量があるかどうかが決まります。リージョン内では、バランシング モードのターゲット容量を使用して、リージョン内の各バックエンド（インスタンス グループまたは NEG）に送信するリクエスト数の比率が計算されます。サービス ロード バランシング ポリシー（
serviceLbPolicy）と優先バックエンドの設定を使用して、リージョン内の特定のバックエンドの選択に影響を与えることができます。各インスタンス グループまたは NEG 内では、ロード バランシング ポリシー（LocalityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。
- クロスリージョン内部アプリケーション ロードバランサ、 リージョン外部アプリケーション ロードバランサ、 リージョン内部アプリケーション ロードバランサの場合、バランシング モードのターゲット容量はリージョン内の各バックエンド（インスタンスグループまたは NEG）に送信するリクエスト数の比率を計算するために使用されます。各インスタンス グループまたは NEG 内では、ロード バランシング ポリシー（
LocalityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。 サービスロードバランシングポリシー（serviceLbPolicy）と優先バックエンドの設定を使用してリージョン内の特定のバックエンドの選択を制御できるのは、クロスリージョン内部アプリケーション ロードバランサだけです。
プロキシ ネットワーク ロードバランサは、VM インスタンス グループ バックエンドに対して CONNECTION または UTILIZATION バランシング モードをサポートします。GCE_VM_IP_PORT エンドポイントを含むゾーン NEG には CONNECTION バランシング モードを、ハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT エンドポイント）に対しては CONNECTION バランシング モードをサポートします。サポートされている他の種類のバックエンドの場合は、バランシング モードを省略する必要があります。
グローバル外部プロキシ ネットワーク ロードバランサの場合、クライアントのロケーションに基づいてリージョンが選択さ、ロード バランシング モードのターゲット容量に基づいて、リージョンに使用可能な容量があるかどうかが決まります。リージョン内では、バランシング モードのターゲット容量を使用して、リージョン内の各バックエンド（インスタンス グループまたは NEG）に送信するリクエスト数の比率が計算されます。サービス ロード バランシング ポリシー（
serviceLbPolicy）と優先バックエンドの設定を使用して、リージョン内の特定のバックエンドの選択に影響を与えることができます。各インスタンス グループまたは NEG 内では、ロード バランシング ポリシー（LocalityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。クロスリージョン内部プロキシ ネットワーク ロードバランサの場合、構成済みのリージョンが最初に選択されます。リージョン内では、バランシング モードのターゲット容量を使用して、リージョン内の各バックエンド（インスタンス グループまたは NEG）に送信するリクエスト数の比率が計算されます。サービス ロード バランシング ポリシー（
serviceLbPolicy）と優先バックエンドの設定を使用して、リージョン内の特定のバックエンドの選択に影響を与えることができます。各インスタンス グループまたは NEG 内では、ロード バランシング ポリシー（LocalityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。従来のプロキシ ネットワーク ロードバランサの場合、クライアントのロケーションに基づいてリージョンが選択さ、ロード バランシング モードのターゲット容量に基づいて、リージョンに使用可能な容量があるかどうかが決まります。次に、リージョン内でロード バランシング モードのターゲット容量を使用して、リージョン内の各バックエンド（インスタンス グループや NEG）に送信されるリクエストまたは接続数の割合が計算されます。ロードバランサがバックエンドを選択すると、各バックエンド内の VM インスタンスまたはネットワーク エンドポイントにラウンドロビン方式でリクエストや接続が分散されます。
- リージョン外部プロキシ ネットワーク ロードバランサとリージョン内部プロキシ ネットワーク ロードバランサの場合、ロード バランシング モードのターゲット容量を使用して、各バックエンド（インスタンス グループまたは NEG）に送信するリクエスト数の比率が計算されます。各インスタンス グループまたは NEG 内では、ロード バランシング ポリシー（
localityLbPolicy）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。
次の表は、各ロードバランサとバックエンドの組み合わせで使用可能なロード バランシング モードをまとめたものです。
| ロードバランサ | バックエンド | 使用可能なバランシング モード |
|---|---|---|
| アプリケーション ロードバランサ | インスタンス グループ | RATE または UTILIZATION |
ゾーン NEG（GCE_VM_IP_PORT エンドポイント） |
RATE |
|
ハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT エンドポイント） |
RATE |
|
|
インスタンス グループ | CONNECTION または UTILIZATION |
ゾーン NEG（GCE_VM_IP_PORT エンドポイント） |
CONNECTION |
|
ハイブリッド NEG（ |
CONNECTION |
|
| パススルー ネットワーク ロードバランサ | インスタンス グループ | CONNECTION |
ゾーン NEG（GCE_VM_IP エンドポイント） |
CONNECTION |
バックエンド サービスに関連付けられているすべての VM の平均使用率が 10% 未満の場合、Google Cloud は特定のゾーンを優先する場合があります。リージョン マネージド インスタンス グループ、異なるゾーンのゾーン マネージド インスタンス グループ、ゾーン非マネージド インスタンス グループを使用すると、この状況が発生することがあります。このゾーン間の不均衡は、ロードバランサに送信されるトラフィックが増加するにつれて自動的に解決されます。
詳細については、gcloud compute backend-services add-backend をご覧ください。
ターゲット容量
各分散モードには、対応するターゲット容量があり、次のターゲット上限のいずれかを定義します。
- 接続の数
- 料金
- CPU 使用率
どの負荷分散モードでも、ターゲット容量はサーキット ブレーカーではありません。ロードバランサは、特定の条件下で最大値を超えることがあります（たとえば、すべてのバックエンド VM またはエンドポイントが上限に達した場合）。
接続バランシング モード
CONNECTION バランシング モードの場合、ターゲット容量によって、開いているターゲット接続の最大数を定義します。内部パススルー ネットワーク ロードバランサと外部パススルー ネットワーク ロードバランサを除き、次のいずれかの設定を使用して、ターゲットの最大接続数を指定する必要があります。
max-connections-per-instance（VM あたり）: VM ごとの接続の目標平均数。max-connections-per-endpoint（ゾーン NEG のエンドポイントごと）: エンドポイントごとの接続の目標平均数。max-connections（ゾーン NEG ごと、ゾーン インスタンス グループの場合）: NEG またはインスタンス グループ全体の接続の目標平均数。リージョン マネージド インスタンス グループの場合は、代わりにmax-connections-per-instanceを使用してください。
次の表は、ターゲット容量パラメータで定義される容量を示します。
- バックエンド全体のターゲット容量
- 各インスタンスまたはエンドポイントに想定されるターゲット容量
| バックエンド タイプ | ターゲット容量 | ||
|---|---|---|---|
| 指定するパラメータ | バックエンド全体の容量 | インスタンスごと、またはエンドポイントの容量あたり | |
インスタンス グループN インスタンス、H 正常 |
max-connections-per-instance=X
|
X × N
|
(X × N)/H
|
ゾーン NEGN エンドポイント、H 正常 |
max-connections-per-endpoint=X
|
X × N
|
(X × N)/H
|
| インスタンス グループ （リージョン マネージド インスタンス グループを除く） H 正常なインスタンス |
max-connections=Y
|
Y
|
Y/H
|
max-connections-per-instance と max-connections-per-endpoint の設定は、VM インスタンス グループ全体またはゾーン NEG 全体の接続の目標最大数を計算するためのプロキシです。
Nインスタンスのある VM インスタンス グループでは、max-connections-per-instance=Xの設定は、max-connections=X × Nを設定する場合と同じになります。Nエンドポイントを含むゾーン NEG では、max-connections-per-endpoint=Xの設定は、max-connections=X × Nを設定する場合と同じになります。
レート分散モード
RATE 分散モードでは、次のいずれかのパラメータを使用して、ターゲット容量を定義する必要があります。
max-rate-per-instance（VM あたり）: VM ごとの HTTP リクエストの目標平均レートを指定します。max-rate-per-endpoint（ゾーン NEG 内のエンドポイントごと）: エンドポイントごとの HTTP リクエストの目標平均レートを指定します。max-rate（ゾーン NEG ごと、ゾーン インスタンス グループ）: NEG またはインスタンス グループ全体の HTTP リクエストの平均目標レートを指定します。リージョン マネージド インスタンス グループの場合は、代わりにmax-rate-per-instanceを使用してください。
次の表は、ターゲット容量パラメータで定義される容量を示します。
- バックエンド全体のターゲット容量
- 各インスタンスまたはエンドポイントに想定されるターゲット容量
| バックエンド タイプ | ターゲット容量 | ||
|---|---|---|---|
| 指定するパラメータ | バックエンド全体の容量 | インスタンスごと、またはエンドポイントの容量あたり | |
インスタンス グループN インスタンス、H 正常 |
max-rate-per-instance=X
|
X × N
|
(X × N)/H
|
ゾーン NEGN エンドポイント、H 正常 |
max-rate-per-endpoint=X
|
X × N
|
(X × N)/H
|
| インスタンス グループ （リージョン マネージド インスタンス グループを除く） H 正常なインスタンス |
max-rate=Y
|
Y
|
Y/H
|
max-rate-per-instance と max-rate-per-endpoint の設定は、インスタンス グループ全体またはゾーン NEG 全体の HTTP リクエストの目標最大レートを計算するプロキシです。
Nインスタンスのあるインスタンス グループでは、max-rate-per-instance=Xの設定は、max-rate=X × Nを設定する場合と同じになります。Nエンドポイントを含むゾーン NEG では、max-rate-per-endpoint=Xの設定は、max-rate=X × Nを設定する場合と同じになります。
使用率分散モード
UTILIZATION バランシング モードでは、ターゲット容量を定義する必要はありません。次のセクションの表で説明するように、バックエンドのタイプに依存するオプションを使用できます。
max-utilization ターゲット容量はインスタンス グループ単位でのみ指定できます。グループ内の特定の VM に適用することはできません。
UTILIZATION バランシング モードでは、ターゲット容量を定義する必要はありません。Google Cloud コンソールでバックエンド インスタンス グループをバックエンド サービスに追加するときに、UTILIZATION 分散モードが選択されていると、Google Cloud コンソールでは max-utilization の値が 0.8（80%）に設定されます。次のセクションの表に示すように、UTILIZATION バランシング モードでは、max-utilization に加えてより複雑なターゲット容量もサポートされます。
ロードバランサのバランシング モードの変更
一部のロードバランサまたはロードバランサの構成では、バックエンド サービスに使用可能なバランシング モードが 1 つしかないため、バランシング モードを変更できません。その他のロードバランサについては、バックエンド サービスに応じて複数のモードを使用できるため、使用するバックエンドに応じてバランシング モードを変更できます。
各ロードバランサでサポートされているバランシング モードを確認するには、表: 各ロードバランサで使用できるバランシング モードをご覧ください。
バランシング モードとターゲット容量の設定
ターゲット容量の仕様をサポートするプロダクトの場合、ターゲット容量はサーキット ブレーカーではありません。特定のゾーンで構成されたターゲット容量の最大値に達すると、新しいリクエストまたは接続は、ターゲット容量でリクエストまたは接続を処理していない他のゾーンに分散されます。すべてのゾーンが目標容量に達した場合、新しいリクエストまたは接続はオーバーフローによって分散されます。
アプリケーション ロードバランサと Cloud Service Mesh
次の表に、アプリケーション ロードバランサと Cloud Service Mesh で使用可能なバランシング モードとターゲット容量の組み合わせを示します。
| バックエンド タイプ | バランシング モード | ターゲット容量の仕様 |
|---|---|---|
インスタンス グループ
|
RATE |
次のいずれかを指定する必要があります。
|
UTILIZATION |
必要に応じて、次のいずれかを指定できます。
|
|
ゾーン NEG
|
RATE |
次のいずれかを指定する必要があります。
|
プロキシ ネットワーク ロードバランサ
次の表に、プロキシ ネットワーク ロードバランサで使用可能なバランシング モードとターゲット容量の組み合わせを示します。
| バックエンド タイプ | バランシング モード | ターゲット容量の仕様 |
|---|---|---|
インスタンス グループ
|
CONNECTION |
次のいずれかを指定する必要があります。
|
UTILIZATION |
必要に応じて、次のいずれかを指定できます。
|
|
ゾーン NEG
|
CONNECTION |
次のいずれかを指定する必要があります。
|
パススルー ネットワーク ロードバランサ
次の表に、パススルー ネットワーク ロードバランサで使用可能なバランシング モードとターゲット容量の組み合わせを示します。
| バックエンド タイプ | バランシング モード | ターゲット容量の仕様 |
|---|---|---|
インスタンス グループ
|
CONNECTION |
ターゲットの最大接続数は指定できません。 |
ゾーン NEG
|
CONNECTION |
ターゲットの最大接続数は指定できません。 |
容量スケーラー
ターゲット容量を変更せずにターゲット容量（最大使用率、最大レート、または最大接続数）をスケーリングするには、容量スケーラーを使用します。
Google Cloud リファレンス ドキュメントについては、以下をご覧ください。
- Google Cloud CLI: capacity-scaler
- API:
容量スケーラーを調整すると、いずれかの --max-* パラメータを明示的に変更しなくても、有効なターゲット容量をスケーリングできます。
容量スケーラーは、次のいずれかの値に設定できます。
- デフォルト値は
1です。これは、構成した容量の最大 100%（balancingModeによって異なります）がグループによって処理されることを意味します。 - 値
0は、グループが完全にドレインされていて、使用可能な容量の 0% を提供していることを意味します。バックエンド サービスに接続されているバックエンドが 1 つだけの場合は、0の設定を構成できません。 0.1（10%）～1.0（100%）の値です。
次に、容量スケーラーとターゲット容量設定の関係を示します。
バランシング モードが
RATE、max-rateが80RPS に設定され、容量スケーラーが1.0の場合、使用可能な容量も80RPS になります。バランシング モードが
RATE、max-rateが80RPS に設定され、容量スケーラーが0.5の場合、使用可能な容量は40RPS（0.5 times 80）になります。バランシング モードが
RATE、max-rateが80RPS に設定され、容量スケーラーが0.0の場合、使用可能な容量はゼロ（0）になります。
サービス ロード バランシング ポリシー
サービス ロード バランシング ポリシー（serviceLbPolicy）は、ロードバランサのバックエンド サービスに関連付けられたリソースです。これにより、バックエンド サービスに関連付けられたバックエンド内でのトラフィックの分散方法に影響するパラメータをカスタマイズできます。
- リージョンまたはゾーン全体でのトラフィックの分散方法を決めるロード バランシング アルゴリズムをカスタマイズします。
- ロードバランサが正常でないバックエンドからトラフィックを迅速にドレインできるように、自動容量ドレインを有効にします。
特定のバックエンドを優先バックエンドとして指定することもできます。これらのバックエンドが容量（バックエンドのバランシング モードで指定されたターゲット容量）に達するまで使用されると、残りのバックエンドにリクエストが送信されます。
詳細については、サービス ロード バランシング ポリシーを使用した高度なロード バランシング最適化をご覧ください。
Cloud Service Mesh とトラフィック分散
Cloud Service Mesh もバックエンド サービス リソースを使用します。具体的には、Cloud Service Mesh は、ロード バランシング スキームが INTERNAL_SELF_MANAGED であるバックエンド サービスを使用します。内部のセルフ マネージド バックエンド サービスの場合、トラフィック分散は、ロード バランシング モードとロード バランシング ポリシーの組み合わせに基づいています。バックエンド サービスは、バックエンドのバランシング モードに従ってバックエンドにトラフィックを転送します。その後、Cloud Service Mesh がロード バランシング ポリシーに従ってトラフィックを分散します。
内部セルフマネージド バックエンド サービスは、次のバランシング モードをサポートします。
UTILIZATION- バックエンドがすべてインスタンス グループの場合RATE- すべてのバックエンドがインスタンス グループまたはゾーン NEG の場合
RATE バランシング モードを選択する場合は、最大レート、インスタンスあたりの最大レート、またはエンドポイントあたりの最大レートを指定する必要があります。
Cloud Service Mesh の詳細については、Cloud Service Mesh のコンセプトをご覧ください。
バックエンドのサブセット化
バックエンドのサブセット化は、各プロキシ インスタンスにバックエンドのサブセットを割り当てることで、パフォーマンスとスケーラビリティを向上させるオプションの機能です。
バックエンドのサブセット化は、以下でサポートされています。
- リージョン内部アプリケーション ロードバランサ
- 内部パススルー ネットワーク ロードバランサ
リージョン内部アプリケーション ロードバランサのバックエンドのサブセット化
クロスリージョン内部アプリケーション ロードバランサはバックエンドのサブセット化をサポートしていません。リージョン内部アプリケーション ロードバランサの場合、バックエンドのサブセット化は、リージョン バックエンド サービス内のバックエンドのサブセットのみを各プロキシ インスタンスに自動的に割り当てます。デフォルトでは、各プロキシ インスタンスはバックエンド サービス内のすべてのバックエンドとの接続を開始します。プロキシ インスタンスの数とバックエンドの数が両方とも多いときに、すべてのバックエンドと接続を開始すると、パフォーマンスの問題が発生する可能性があります。
サブセット化を有効にすると、各プロキシはバックエンドのサブセットへの接続のみを開始するため、各バックエンドに対して開始する接続の数が少なくなります。各バックエンドに対して同時に開始する接続数を減らすと、バックエンドとプロキシの両方のパフォーマンスが向上します。
次の図は、2 つのプロキシがあるロードバランサを示しています。バックエンドのサブセット化がない場合、両方のプロキシからのトラフィックがバックエンド サービス 1 のすべてのバックエンドに分散されます。バックエンドのサブセット化を有効にすると、各プロキシからのトラフィックがバックエンドのサブセットに分散されます。プロキシ 1 からのトラフィックはバックエンド 1 と 2 に分散され、プロキシ 2 からのトラフィックはバックエンド 3 と 4 に分散されます。
localityLbPolicy ポリシーを設定すると、バックエンドへのロード バランシング トラフィックを細かく調整できます。詳細については、トラフィック ポリシーをご覧ください。
内部アプリケーション ロードバランサのバックエンドのサブセット化の設定については、バックエンド サブセットの構成をご覧ください。
内部アプリケーション ロードバランサのバックエンドのサブセット化に関連する注意事項
- バックエンドのサブセット化は、すべてのバックエンド インスタンスが適切に利用されるように設計されていますが、各バックエンドが受信するトラフィック量にある程度のバイアスが生じる可能性があります。バックエンドの負荷のバランスが重要となるバックエンド サービスには、
localityLbPolicyをLEAST_REQUESTに設定することをおすすめします。 - 設定を有効にしてから無効にすると、既存の接続が切断されます。
- バックエンドのサブセット化では、セッション アフィニティが
NONE（5-tuple ハッシュ）である必要があります。他のセッション アフィニティ オプションは、バックエンドのサブセット化が無効になっている場合にのみ使用できます。--subsetting-policyフラグと--session-affinityフラグのデフォルト値はどちらもNONEです。異なる値を設定できるのは一度に 1 つだけです。
内部パススルー ネットワーク ロードバランサのバックエンドのサブセット化
内部パススルー ネットワーク ロードバランサのバックエンドのサブセット化を使用すると、内部パススルー ネットワーク ロードバランサをスケーリングし、内部バックエンド サービスごとに多数のバックエンド VM インスタンスをサポートできます。
サブセット化がこの制限に与える影響については、ロード バランシング リソースの割り当てと上限の「バックエンド サービス」をご覧ください。
デフォルトではサブセット化が無効になるため、バックエンド サービスは最大で 250 のバックエンド インスタンスまたはエンドポイントに制限されます。バックエンド サービスが 250 を超えるバックエンドをサポートする必要がある場合は、サブセット化を有効にできます。サブセットが有効になっている場合、クライアント接続ごとにバックエンド インスタンスのサブセットが選択されます。
次の図は、この 2 つの動作モードの違いを簡単なモデルで示しています。
サブセット化しないと、正常なバックエンドの完全なセットの使用率が上がり、新しいクライアント接続はトラフィック分散に従ってすべての正常なバックエンド間で分散されます。サブセット化すると、負荷分散の制限は生じませんが、ロードバランサは 250 以上のバックエンドをサポートできます。
構成手順については、サブセット化の設定をご覧ください。
内部パススルー ネットワーク ロードバランサのバックエンドのサブセット化に関連する注意事項
- サブセット化が有効になっている場合、バックエンドの数が少ない場合でも、すべてのバックエンドが特定の送信者からトラフィックを受信するわけではありません。
- サブセット化が有効な場合のバックエンド インスタンスの最大数については、[割り当て] ページをご覧ください。
- サブセットをサポートしているのは、5 タプルのセッション アフィニティのみです。
- サブセット化で Packet Mirroring はサポートされていません。
- 設定を有効にしてから無効にすると、既存の接続が切断されます。
- オンプレミス クライアントが内部パススルー ネットワーク ロードバランサにアクセスする必要がある場合、サブセット化により、オンプレミス クライアントからの接続を受信するバックエンドの数を大幅に削減できます。これは、Cloud VPN トンネルまたは Cloud Interconnect VLAN アタッチメントのリージョンによってロードバランサのバックエンドのサブセットが決まるためです。特定のリージョンのすべての Cloud VPN エンドポイントと Cloud Interconnect エンドポイントで、同じサブセットが使用されます。リージョンごとに異なるサブセットが使用されます。
バックエンドのサブセット化の料金
バックエンドのサブセット化の使用に料金はかかりません。詳しくは、ネットワーキングのすべての料金をご覧ください。
セッション アフィニティ
セッション アフィニティを使用すると、正常なバックエンドの数が一定である限り、予測可能な方法でロードバランサが新しい接続にバックエンドを選択する方法を制御できます。これは、特定のユーザーからの複数のリクエストを同じバックエンドまたはエンドポイントに転送する必要があるアプリケーションに役立ちます。このようなアプリケーションとしては、広告配信、ゲーム、または内部キャッシュが頻繁に行われるサービスで使用されるステートフル サーバーなどがあります。
Google Cloud ロードバランサは、ベストエフォート ベースでのセッション アフィニティを実現します。バックエンドの追加や削除、バックエンド ウェイトの変更（重み付きバランシングを有効または無効にすることを含む）、バランシング モードで測定されるバックエンド使用率の変化などの要因により、セッション アフィニティが失われる可能性があります。
セッション アフィニティによるロード バランシングは、一意の接続が適切な規模で分散されている場合にうまく機能します。適切な規模とは、バックエンド数の少なくとも数倍を意味します。接続数が少ない状態でロードバランサをテストしても、バックエンド間でのクライアント接続の分散を正確に表すことはできません。
デフォルトでは、すべての Google Cloud ロードバランサは、次のように 5 タプルハッシュ（--session-affinity=NONE）を使用してバックエンドを選択します。
- パケットの送信元 IP アドレス
- パケットの送信元ポート（パケットのヘッダーにある場合）
- パケットの宛先 IP アドレス
- パケットの宛先ポート（パケットのヘッダーにある場合）
- パケットのプロトコル
パススルー ロードバランサの場合、新しい接続は正常なバックエンド インスタンスまたはエンドポイントに分散されます（フェイルオーバー ポリシーが構成されている場合は、アクティブ プール内）。次のことを制御できます。
- 確立された接続が異常なバックエンドで維持されるかどうか。詳しくは、内部パススルー ネットワーク ロードバランサの異常なバックエンドでの接続の永続性とバックエンド サービスベースの外部パススルー ネットワーク ロードバランサの異常なバックエンドでの接続の永続性をご覧ください。
- フェイルオーバー ポリシーが構成されている場合に、確立済みの接続がフェイルオーバーとフェイルバック中に保持されるかどうか。詳しくは、内部パススルー ネットワーク ロードバランサのフェイルオーバーとフェイルバックでのコネクション ドレインとバックエンド サービスベースの外部パススルー ネットワーク ロードバランサのフェイルオーバーとフェイルバックでのコネクション ドレインをご覧ください。
- ロードバランサからバックエンドを削除する際に、確立済みの接続を維持する期間。詳細については、コネクション ドレインの有効化をご覧ください。
プロキシベースのロードバランサの場合、正常なバックエンド インスタンスまたはエンドポイントの数が一定であり、以前に選択したバックエンド インスタンスまたはエンドポイントの容量が上限に達していない限り、後続のリクエストまたは接続は、同じバックエンド VM またはエンドポイントに送信されます。バランシング モードのターゲット容量により、バックエンドの容量が上限に達するタイミングが判断されます。
次の表に、各プロダクトでサポートされるセッション アフィニティのオプションを示します。
| プロダクト | セッション アフィニティのオプション |
|---|---|
また、次の点にもご注意ください。
|
|
| 従来のアプリケーション ロードバランサ |
|
また、次の点にもご注意ください。
|
|
| 内部パススルー ネットワーク ロードバランサ |
内部パススルー ネットワーク ロードバランサとセッション アフィニティの具体的な情報については、内部パススルー ネットワーク ロードバランサの概要をご覧ください。 |
| 外部パススルー ネットワーク ロードバランサ* |
外部パススルー ネットワーク ロードバランサとセッション アフィニティの具体的な情報については、外部 TCP / UDP 外部パススルー ネットワーク ロードバランサの概要をご覧ください。 |
|
|
| Cloud Service Mesh |
|
* この表は、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサでサポートされているセッション アフィニティを示しています。ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、バックエンド サービスを使用しません。代わりに、ターゲット プールの sessionAffinity パラメータを通じて、外部パススルー ネットワーク ロードバランサのセッション アフィニティを設定します。
セッション アフィニティを構成する際は、次の点に留意してください。
認証やセキュリティを目的としてセッション アフィニティに依存しないでください。セッション アフィニティは、サービスの数と正常なバックエンドの数が変わるたびに失われるように設計されています。セッション アフィニティが失われるアクティビティは次のとおりです。
- バックエンド インスタンス グループまたは NEG をバックエンド サービスに追加する
- バックエンド サービスからバックエンド インスタンス グループまたは NEG を削除する
- 既存のバックエンド インスタンス グループにインスタンスを追加する（これは、マネージド インスタンス グループによる自動スケーリングを有効にすると自動的に発生します）
- 既存のバックエンド インスタンス グループからインスタンスを削除する（これは、マネージド インスタンス グループによる自動スケーリングを有効にすると自動的に発生します）
- 既存のバックエンド NEG にエンドポイントを追加する
- 既存のバックエンド NEG からエンドポイントを削除する
- 正常なバックエンドのヘルスチェックが失敗して異常になった場合
- 正常でないバックエンドがヘルスチェックの条件を満たして正常な状態になった場合
- パススルー ロードバランサの場合: フェイルオーバーとフェイルバック（フェイルオーバー ポリシーが構成されている場合）
- プロキシ ロードバランサの場合: バックエンドが容量の上限に達したか、上限を超えた場合
None以外のセッション アフィニティをUTILIZATIONバランシング モードで使用することはおすすめしません。これは、インスタンス使用率の変化によって、負荷分散サービスが容量の上限に達していないバックエンド VM に新しいリクエストや新しい接続を転送する場合があるためです。これにより、セッション アフィニティが失われます。代わりに、RATEまたはCONNECTIONバランシング モードを使用して、セッション アフィニティの喪失を防ぎます。詳細については、セッション アフィニティの喪失をご覧ください。外部および内部 HTTP(S) ロードバランサの場合、目的のエンドポイントまたはインスタンスがバランシング モードのターゲット最大値を超えると、セッション アフィニティが失われる可能性があります。次に例を示します。
- ロードバランサに 1 つの NEG と 3 つのエンドポイントが存在します。
- 各エンドポイントには、1 RPS のターゲット容量があります。
- 分散モードは
RATEです。 - 現時点では、各エンドポイントはそれぞれ 1.1、0.8、1.6 RPS を処理しています。
- 最後のエンドポイントのアフィニティを使用した HTTP リクエストがロードバランサに到達すると、セッション アフィニティは 1.6 RPS で処理しているエンドポイントをクレームします。
- RPS が 0.8 の中間エンドポイントに新しいリクエストが送信される場合があります。
--session-affinityフラグと--subsetting-policyフラグのデフォルト値はどちらもNONEです。異なる値を設定できるのは一度に 1 つだけです。
次のセクションでは、さまざまなタイプのセッション アフィニティについて説明します。
クライアント IP、宛先なしアフィニティ
「クライアント IP、宛先なしセッション アフィニティ（CLIENT_IP_NO_DESTINATION）」は、受信した各パケットの送信元 IP アドレスのみに基づく 1 タプルハッシュです。このセッション アフィニティは、内部パススルー ネットワーク ロードバランサでのみ使用できます。
このオプションは、パケットの宛先 IP アドレスに関係なく、パケットの送信元 IP アドレスのみに基づいて、クライアントからのすべてのパケットを同じバックエンド VM で処理する必要がある場合に便利です。このような状況は通常、内部パススルー ネットワーク ロードバランサが静的ルートのネクストホップである場合に発生します。詳細については、セッション アフィニティとネクストホップの内部パススルー ネットワーク ロードバランサをご覧ください。
クライアント IP アフィニティ
「クライアント IP セッション アフィニティ（CLIENT_IP）」は、パケットの送信元 IP アドレスと宛先 IP アドレスから作成された 2 タプルハッシュです。クライアント IP セッション アフィニティは、バックエンド サービスを使用するすべての Google Cloud ロードバランサで使用できます。外部パススルー ネットワーク ロードバランサでは、このセッション アフィニティ オプションは「クライアント IP、宛先 IP」になります。
クライアント IP アフィニティを使用する場合は、次の点に留意してください。
パケットがロードバランサに直接送信される場合、パケットの宛先 IP アドレスはロードバランサの転送ルールの IP アドレスと同じになります。
静的ルートによってネクストホップの内部パススルー ネットワーク ロードバランサに転送されるパケットの宛先 IP アドレスは、ロードバランサの転送ルールの IP アドレスと一致しません。重要な情報については、セッション アフィニティとネクストホップの内部パススルー ネットワーク ロードバランサをご覧ください。
パケットが Google Cloud ロードバランサに配信される前に中間 NAT またはプロキシ システムによって処理されると、パケットの送信元 IP アドレスが元のクライアントに関連付けられた IP アドレスと一致しないことがあります。多くのクライアントが同じ有効な送信元 IP アドレスを共有する場合、一部のバックエンド VM は他の VM よりも多くの接続またはリクエストを受信する可能性があります。
生成された Cookie アフィニティ
生成された Cookie ベースのアフィニティを使用する場合、ロードバランサは最初の HTTP リクエストの Set-Cookie レスポンス ヘッダーに HTTP Cookie を含めます。
生成される Cookie の名前は、ロードバランサのタイプによって異なります。生成された Cookie は、次のプロダクトでサポートされています。
| プロダクト | Cookie 名 |
|---|---|
| グローバル外部アプリケーション ロードバランサ | GCLB |
| 従来のアプリケーション ロードバランサ | GCLB |
| リージョン外部アプリケーション ロードバランサ | GCILB |
| クロスリージョン内部アプリケーション ロードバランサ | GCILB |
| リージョン内部アプリケーション ロードバランサ | GCILB |
| Cloud Service Mesh | GCILB |
生成された Cookie のパス属性は常にスラッシュ（/）になります。他のバックエンド サービスも生成された Cookie アフィニティを使用している場合、同じ URL マップ上のすべてのバックエンド サービスに適用されます。
Cookie の有効期間（TTL）は、0 から 86400 秒の範囲（両端を含む）で構成できます。TTL が 0 秒の生成 Cookie はすぐに期限切れになるため、この Cookie は一意のセッション ID としてのみ使用できます。後続の HTTP リクエストのアフィニティは提供されません。
クライアントが、後続の HTTP リクエストの Cookie リクエスト ヘッダーに生成されたセッション アフィニティ Cookie を含めると、ロードバランサは、セッション アフィニティ Cookie が有効である限り、それらのリクエストを同じバックエンド インスタンスまたはエンドポイントに転送します。これを行うには、Cookie 値を、特定のバックエンド インスタンスまたはエンドポイントを参照するインデックスにマッピングし、生成された Cookie のセッション アフィニティ要件を満たすようにします。
生成された Cookie アフィニティを使用するには、次のバランシング モードと localityLbPolicy 設定を構成します。
- バックエンド インスタンス グループの場合は、
RATEバランシング モードを使用します。 - バックエンド サービスの
localityLbPolicyには、RING_HASHまたはMAGLEVを使用します。localityLbPolicyを明示的に設定しない場合、ロードバランサは暗黙のデフォルトとしてMAGLEVを使用します。
また、生成された Cookie アフィニティでは、バックエンド サービスで構成され、正常なバックエンド インスタンスまたはエンドポイントの数を一定にする必要があります。
一部のクライアントのセッション アフィニティは、次の理由で中断されます。
構成済みの正常なバックエンド インスタンスまたはエンドポイントの数が変更された。バックエンド インスタンスまたはエンドポイントを追加または削除すると、インデックス値の計算に影響します。インデックス値の数が変わると、ハッシュが別のインデックスにマッピングされるか、インデックスが別のバックエンドを参照するため（またはその両方のため）、セッション アフィニティが破棄される可能性があります。
構成された正常なバックエンド インスタンスまたはエンドポイントの数は、次の場合に変動します。
- 空ではないバックエンド インスタンス グループまたは NEG をバックエンド サービスに追加します。
- バックエンド サービスから既存のバックエンド インスタンス グループまたは NEG を削除します。
- バックエンド サービスで、既存のバックエンド インスタンス グループにインスタンスを追加または削除します。
- バックエンド サービスで、既存のバックエンド NEG にエンドポイントを追加するか、既存のバックエンド NEG からエンドポイントを削除します。
- 既存のインスタンスまたはエンドポイントがヘルスチェックに失敗し、正常な状態から異常な状態に変わります。
- 既存のインスタンスまたはエンドポイントがヘルスチェックに合格し、異常な状態から正常な状態に変わります。
- 上記の 2 つ以上の組み合わせ。
以前に選択したバックエンド インスタンスまたはエンドポイントが、ターゲット容量に達していっぱいになった。
ヘッダー フィールド アフィニティ
次のロードバランサは、ヘッダー フィールド アフィニティを使用します。
- Cloud Service Mesh
- クロスリージョン内部アプリケーション ロードバランサ
- グローバル外部アプリケーション ロードバランサ
- リージョン外部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
ヘッダー フィールド アフィニティは、次の条件を満たす場合にサポートされます。
- ロード バランシングの局所性ポリシーが RING_HASH または MAGLEV である。
- バックエンド サービスの
consistentHashが、HTTP ヘッダーの名前（httpHeaderName）を指定する。
ヘッダー フィールド アフィニティをサポートするサービスについては、表: サポートされているセッション アフィニティの設定をご覧ください。
HTTP Cookie アフィニティ
HTTP Cookie ベースのアフィニティを使用する場合、ロードバランサは最初の HTTP リクエストの Set-Cookie レスポンス ヘッダーに HTTP Cookie を含めます。Cookie の名前、パス、有効期間（TTL）を指定します。
HTTP Cookie ベースのアフィニティをサポートするプロダクトは次のとおりです。
- グローバル外部アプリケーション ロードバランサ
- 従来のアプリケーション ロードバランサ
- リージョン外部アプリケーション ロードバランサ
- クロスリージョン内部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
- Cloud Service Mesh
Cookie の TTL 値を構成できます。有効な TTL 値は次の範囲です。
0～315576000000（秒単位で指定した場合）。0～999999999（ナノ秒単位で指定した場合）。
TTL が 0 秒の HTTP Cookie はすぐに期限切れになるため、この Cookie は一意のセッション ID としてのみ使用できます。後続の HTTP リクエストのアフィニティは提供されません。
クライアントが、後続の HTTP リクエストの Cookie リクエスト ヘッダーに HTTP セッション アフィニティ Cookie を含めると、ロードバランサは、セッション アフィニティ Cookie が有効である限り、それらのリクエストを同じバックエンド インスタンスまたはエンドポイントに転送します。これを行うには、Cookie 値を、特定のバックエンド インスタンスまたはエンドポイントを参照するインデックスにマッピングし、生成された Cookie のセッション アフィニティ要件を満たすようにします。
HTTP Cookie アフィニティを使用するには、次のバランシング モードと localityLbPolicy 設定を構成します。
- バックエンド インスタンス グループの場合は、
RATEバランシング モードを使用します。 - バックエンド サービスの
localityLbPolicyには、RING_HASHまたはMAGLEVを使用します。localityLbPolicyを明示的に設定しない場合、ロードバランサは暗黙のデフォルトとしてMAGLEVを使用します。
また、HTTP Cookie アフィニティでは、バックエンド サービスで構成され、正常なバックエンド インスタンスまたはエンドポイントの数を一定にする必要があります。一部のクライアントのセッション アフィニティは、次の理由で中断されます。
構成済みの正常なバックエンド インスタンスまたはエンドポイントの数が変更された。バックエンド インスタンスまたはエンドポイントを追加または削除すると、インデックス値の計算に影響します。インデックス値の数が変わると、ハッシュが別のインデックスにマッピングされるか、インデックスが別のバックエンドを参照するため（またはその両方のため）、セッション アフィニティが破棄される可能性があります。
構成された正常なバックエンド インスタンスまたはエンドポイントの数は、次の場合に変動します。
- 空ではないバックエンド インスタンス グループまたは NEG をバックエンド サービスに追加します。
- バックエンド サービスから既存のバックエンド インスタンス グループまたは NEG を削除します。
- バックエンド サービスで、既存のバックエンド インスタンス グループにインスタンスを追加または削除します。
- バックエンド サービスで、既存のバックエンド NEG にエンドポイントを追加するか、既存のバックエンド NEG からエンドポイントを削除します。
- 既存のインスタンスまたはエンドポイントがヘルスチェックに失敗し、正常な状態から異常な状態に変わります。
- 既存のインスタンスまたはエンドポイントがヘルスチェックに合格し、異常な状態から正常な状態に変わります。
- 上記の 2 つ以上の組み合わせ。
以前に選択したバックエンド インスタンスまたはエンドポイントが、ターゲット容量に達していっぱいになった。
ステートフル Cookie ベース セッション アフィニティ
ステートフル Cookie ベース アフィニティを使用する場合、ロードバランサは最初の HTTP リクエストの Set-Cookie レスポンス ヘッダーに HTTP Cookie を含めます。Cookie の名前、パス、有効期間（TTL）を指定します。
次のロードバランサは、ステートフル Cookie ベース アフィニティをサポートしています。
- グローバル外部アプリケーション ロードバランサ
- リージョン外部アプリケーション ロードバランサ
- クロスリージョン内部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
Cookie の TTL 値を構成できます。有効な TTL 値は次の範囲です。
0～315576000000（秒単位で指定した場合）。0～999999999（ナノ秒単位で指定した場合）。
TTL が 0 秒の Cookie はすぐに期限切れになるため、この Cookie は一意のセッション ID としてのみ使用できます。後続の HTTP リクエストのアフィニティは提供されません。
Cookie の値は、選択したバックエンド インスタンスまたはエンドポイントを値自体にエンコードすることで識別します。Cookie が有効である限り、クライアントが後続の HTTP リクエストの Cookie リクエスト ヘッダーにセッション アフィニティ Cookie を含めると、ロードバランサは、選択したバックエンド インスタンスまたはエンドポイントにリクエストを転送します。
ステートフル Cookie ベース アフィニティには、バランシング モードや localityLbPolicy に関する特定の要件はありません。
ステートフル Cookie ベース アフィニティでは、選択したバックエンド インスタンスまたはエンドポイントが構成され、正常な状態を維持する必要があります。一部のクライアントのセッション アフィニティは、次の理由で中断されます。
- 選択したインスタンスまたはエンドポイントを含むバックエンド インスタンス グループまたは NEG がバックエンド サービスから削除されます。
- 選択したインスタンスまたはエンドポイントが、バックエンド インスタンス グループまたは NEG から削除されます。
- 選択したインスタンスまたはエンドポイントでヘルスチェックが失敗します。
セッション アフィニティの喪失
選択したアフィニティのタイプに関係なく、クライアントは次の状況でバックエンドとのアフィニティを失う可能性があります。
- バックエンド インスタンス グループまたはゾーン NEG の容量が不足している場合。これは、分散モードのターゲット容量によって定義されます。この場合、Google Cloud は別のゾーンにあるバックエンド インスタンス グループまたはゾーン NEG にトラフィックを転送します。このリスクを軽減するには、独自のテストを行い、各バックエンドに正しいターゲット容量を指定します。
- 自動スケーリングでは、マネージド インスタンス グループへのインスタンスの追加や、マネージド インスタンス グループからのインスタンスの削除が行われます。この場合、インスタンス グループ内のインスタンスの数が変わるため、バックエンド サービスはセッション アフィニティのハッシュを再計算します。このリスクを軽減するには、マネージド インスタンス グループの最小サイズで標準的な負荷を処理できるようにします。負荷が想定を超えて増加した場合にのみ、自動スケーリングが行われます。
- NEG のバックエンド VM またはエンドポイントがヘルスチェックに失敗した場合、ロードバランサはトラフィックを正常な別のバックエンドに転送します。すべてのバックエンドがヘルスチェックに失敗した場合のロードバランサの動作の詳細については、各 Google Cloud ロードバランサのドキュメントを参照してください。
UTILIZATION負荷分散モードがバックエンド インスタンス グループに対して有効になっている場合、バックエンドの使用率が変化するため、セッション アフィニティが失われます。これは、ロードバランサの種類でサポートされているRATEまたはCONNECTIONのいずれかのバランシング モードを使用して軽減できます。
外部アプリケーション ロードバランサまたは外部プロキシ ネットワーク ロードバランサを使用する場合は、次の追加ポイントに留意してください。
- インターネット上のクライアントから Google へのルーティング パスがリクエストまたは接続によって異なる場合は、別の Google Front End（GFE）がプロキシとして選択される可能性があります。これにより、セッション アフィニティが失われる可能性があります。
UTILIZATIONバランシング モードを使用する場合（特にターゲットの最大ターゲット容量が定義されていない場合）、ロードバランサへのトラフィックが少ないと、セッション アフィニティが失われる可能性があります。選択したロードバランサでサポートされている分散モード（RATEまたはCONNECTION）に切り替えます。
バックエンド サービスのタイムアウト
ほとんどの Google Cloud ロードバランサには、バックエンド サービスのタイムアウトがあります。デフォルト値は 30 秒です。指定できるタイムアウト値の範囲は 1～2,147,483,647 秒です。
HTTP、HTTPS、または HTTP/2 プロトコルを使用する外部アプリケーション ロードバランサと内部アプリケーション ロードバランサの場合、バックエンド サービスのタイムアウトは、HTTP(S) トラフィックのリクエストとレスポンスのタイムアウトになります。
各ロードバランサのバックエンド サービスのタイムアウトの詳細については、以下をご覧ください。
- グローバル外部アプリケーション ロードバランサと リージョン外部アプリケーション ロードバランサについては、タイムアウトと再試行をご覧ください。
- 内部アプリケーション ロードバランサについては、タイムアウトと再試行をご覧ください。
外部プロキシ ネットワーク ロードバランサの場合、タイムアウトはアイドル タイムアウトです。接続が削除されるまでの時間を変更するには、タイムアウト値を変更します。このアイドル タイムアウトは WebSocket 接続にも使用されます。
内部パススルー ネットワーク ロードバランサと外部パススルー ネットワーク ロードバランサの場合、
gcloudまたは API を使用してバックエンド サービス タイムアウトの値を設定できますが、値は無視されます。バックエンド サービスのタイムアウトは、これらのパススルー ロードバランサにとって意味がありません。
- Cloud Service Mesh の場合、バックエンド サービスのタイムアウト フィールド（
timeoutSecを使用して指定される）は、プロキシレス gRPC サービスではサポートされていません。このようなサービスでは、maxStreamDurationフィールドを使用してバックエンド サービスのタイムアウトを構成します。gRPC は、リクエストの送信後にバックエンドからの完全なレスポンスを待機する時間を指定するtimeoutSecのセマンティクスをサポートしていません。gRPC のタイムアウトは、ストリームの開始からレスポンスが完全に処理されるまでの待ち時間（すべての再試行を含む）を指定します。
ヘルスチェック
バックエンドがインスタンス グループまたはゾーン NEG である各バックエンド サービスには、ヘルスチェックを関連付ける必要があります。 サーバーレス NEG またはグローバル インターネット NEG をバックエンドとして使用するバックエンド サービスでは、ヘルスチェックを参照しないでください。
Google Cloud コンソールを使用してロードバランサを作成する場合は、必要に応じて、ロードバランサの作成時にヘルスチェックを作成するか、既存のヘルスチェックを参照できます。
Google Cloud CLI または API で、インスタンス グループまたはゾーン NEG バックエンドを使用してバックエンド サービスを作成する場合は、既存のヘルスチェックを参照する必要があります。必要なヘルスチェックの種類と範囲については、ヘルスチェックの概要のロードバランサ ガイドを参照してください。
詳細については、次のドキュメントをご覧ください。
バックエンド サービス リソースで有効な追加機能
一部のバックエンド サービスでは、次のオプション機能がサポートされています。
Cloud CDN
Cloud CDN は、Google のグローバル エッジ ネットワークを使用して、ユーザーの近くからコンテンツを提供します。これにより、ウェブサイトやアプリケーションが高速化されます。Cloud CDN は、グローバル外部アプリケーション ロードバランサで使用されるバックエンド サービスで有効になっています。リクエストを受信するフロントエンド IP アドレスとポート、そしてリクエストに応答するバックエンドは、ロードバランサが提供します。
詳細については、Cloud CDN のドキュメントをご覧ください。
Cloud CDN は IAP と互換性がありません。同じバックエンド サービスで有効にすることはできません。
Google Cloud Armor
次のいずれかのロードバランサを使用している場合は、ロードバランサの作成時にバックエンド サービスで Google Cloud Armor を有効にすることで、アプリケーションの保護を強化できます。
Google Cloud コンソールを使用する場合は、次のいずれかを行います。
- 既存の Google Cloud Armor セキュリティ ポリシーを選択します。
- カスタマイズ可能な名前、リクエスト数、間隔、キー、レート制限のパラメータを使用して、Google Cloud Armor のレート制限セキュリティ ポリシーのデフォルト構成を受け入れます。上流のプロキシ サービス（CDN プロバイダなど）とともに Google Cloud Armor を使用する場合は、
Enforce_on_keyを XFF の IP アドレスとして設定する必要があります。 - [なし] を選択して、Google Cloud Armor の保護を無効にすることを選択します。
IAP
IAP を使用すると、HTTPS によってアクセスされるアプリケーションの一元的な認可レイヤを確立できるため、ネットワーク レベルのファイアウォールに依存せずにアプリケーション レベルのアクセス制御モデルを使用できます。IAP は、特定の Application Load Balancer でサポートされています。
IAP は Cloud CDN と互換性がありません。同じバックエンド サービスで有効にすることはできません。
トラフィック管理機能
次の機能は一部のプロダクトでのみサポートされています。
- ROUND_ROBIN を除くロード バランシング ポリシー（
localityLbPolicy）。 maxRequestsフィールド以外のサーキット ブレーク- 外れ値検出
これらの機能は、次のロードバランサでサポートされています。
- グローバル外部アプリケーション ロードバランサ（サーキット ブレーカーはサポートされていません）
- リージョン外部アプリケーション ロードバランサ
- クロスリージョン内部アプリケーション ロードバランサ
- リージョン内部アプリケーション ロードバランサ
- Cloud Service Mesh（プロキシレス gRPC サービスではサポートされません）
API と gcloud リファレンス
バックエンド サービス リソースのプロパティの詳細については、次のリファレンスをご覧ください。
次のステップ
ロードバランサでバックエンド サービスを使用する方法については、次のドキュメントをご覧ください。
- カスタム ヘッダーの作成
- 外部アプリケーション ロードバランサを作成する
- 外部アプリケーション ロードバランサの概要
- コネクション ドレインを有効にする
- Google Cloud での転送データの暗号化