バックエンド サービスの概要

バックエンド サービスは、Cloud Load Balancing によるトラフィックの分散方法を定義します。バックエンド サービスの構成には、バックエンドへの接続に使用されるプロトコル、さまざまな配信とセッションの設定、ヘルスチェック、タイムアウトなどの値が含まれます。これらの設定により、ロードバランサの動作を細かく制御できます。ほとんどの設定にはデフォルト値が用意されているので、簡単な構成ですぐに使い始めることができます。バックエンド サービスのスコープは グローバルまたはリージョンです。

ロードバランサ、Envoy プロキシ、プロキシレス gRPC クライアントは、バックエンド サービス リソースの構成情報を使用して次のことを行います。

• トラフィックを正しいバックエンド、すなわちインスタンス グループまたはネットワーク エンドポイント グループ（NEG）に転送する。
• 各バックエンドで設定された負荷分散モードに従ってトラフィックを分散する。
• バックエンドの状態をモニタリングしているヘルスチェックを判別する。
• セッション アフィニティを指定する。
• 特定のロードバランサでのみ使用される以下のサービスなど、他のサービスが有効になっているかどうかを確認する。
  • Cloud CDN
  • Google Cloud Armor セキュリティ ポリシー
  • Identity-Aware Proxy
• App Hub（プレビュー版）で、リージョン バックエンド サービスをサービスとして指定します。

これらの値は、バックエンド サービスを作成するとき、またはバックエンド サービスにバックエンドを追加するときに設定します。

次の表は、どのロードバランサがバックエンド サービスを使用しているかをまとめたものです。また、使用しているプロダクトによって、バックエンド サービスの最大数、バックエンド サービスのスコープ、サポートされているバックエンド タイプ、バックエンド サービスのロード バランシング スキームが決まります。ロード バランシング スキームは、Google が転送ルールとバックエンド サービスを分類するために使用する識別子です。各ロード バランシング プロダクトは、転送ルールとバックエンド サービスに 1 つのロード バランシング スキームを使用します。スキームの中には、プロダクト間で共有されるものもあります。

バックエンド

バックエンドは、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 アドレスを指定できます。

• リージョン外部アプリケーション ロードバランサの場合: クライアントは、ロードバランサの外部 IP アドレスをホストする Envoy プロキシと通信します。Envoy プロキシは、バックエンドの VPC ネットワークの識別子をバックエンドの内部 IPv4 アドレスと結合して作成された内部アドレスにパケットを送信することにより、バックエンド VM またはエンドポイントと通信します。

  • インスタンス グループのバックエンドの場合、内部 IPv4 アドレスは常に、VM の nic0 インターフェースに対応するプライマリ内部 IPv4 アドレスになります。nic0 は、ロードバランサと同じネットワークに存在する必要があります。
  • ゾーン NEG 内の GCE_VM_IP_PORT エンドポイントの場合、ネットワーク インターフェースがロードバランサと同じネットワーク内にある限り、VM のネットワーク インターフェースに関連付けられたプライマリ IPv4 アドレス、または VM のネットワーク インターフェースに関連付けられたエイリアス IP アドレス範囲の IPv4 アドレスとして、エンドポイントの IP アドレスを指定できます。

• 外部パススルー ネットワーク ロードバランサの場合: クライアントは、Google の Maglev パススルー ロード バランシング インフラストラクチャを介してバックエンドと直接通信します。パケットは、元の送信元 IP アドレスと宛先 IP アドレスを保持した状態でバックエンドにルーティングされ、配信されます。バックエンドは、ダイレクト サーバー リターンを使用してクライアントに応答します。バックエンドの選択と接続の追跡に使用される方法は構成可能です。

  • インスタンス グループのバックエンドの場合、パケットは常に VM の nic0 インターフェースに配信されます。
  • ゾーン NEG 内の GCE_VM_IP エンドポイントの場合、パケットは NEG に関連付けられたサブネットワーク内にある 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 と CONNECTION
  • RATE と 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 を使用しているかどうかによって異なります。

バックエンド サービスのプロトコルを変更すると、ロードバランサ経由でバックエンドに数分間アクセスできなくなります。

IP アドレス選択ポリシー

このフィールドは、プロキシ ロードバランサで使用できます。IP アドレス選択ポリシーを使用して、バックエンド サービスからバックエンドに送信されるトラフィック タイプを指定する必要があります。

IP アドレス選択ポリシーを選択する場合は、選択したトラフィック タイプがバックエンドでサポートされていることを確認してください。詳細については、表: バックエンド サービスとサポートされているバックエンド タイプをご覧ください。

IP アドレス選択ポリシーは、ロードバランサのバックエンド サービスを別のトラフィック タイプをサポートするように変換する場合に使用します。詳細については、シングルスタックからデュアルスタックに変換するをご覧ください。

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）により、グループ内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。

次の表は、各ロードバランサとバックエンドの組み合わせで使用可能なロード バランシング モードをまとめたものです。

バックエンド サービスに関連付けられているすべての 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 を使用してください。

次の表は、ターゲット容量パラメータで定義される容量を示します。

• バックエンド全体のターゲット容量
• 各インスタンスまたはエンドポイントに想定されるターゲット容量

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 を使用してください。

次の表は、ターゲット容量パラメータで定義される容量を示します。

• バックエンド全体のターゲット容量
• 各インスタンスまたはエンドポイントに想定されるターゲット容量

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 で使用可能なバランシング モードとターゲット容量の組み合わせを示します。

プロキシ ネットワーク ロードバランサ

次の表に、プロキシ ネットワーク ロードバランサで使用可能なバランシング モードとターゲット容量の組み合わせを示します。

パススルー ネットワーク ロードバランサ

次の表に、パススルー ネットワーク ロードバランサで使用可能なバランシング モードとターゲット容量の組み合わせを示します。

容量スケーラー

ターゲット容量を変更せずにターゲット容量（最大使用率、最大レート、または最大接続数）をスケーリングするには、容量スケーラーを使用します。

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 が 80 RPS に設定され、容量スケーラーが 1.0 の場合、使用可能な容量も 80 RPS になります。

• バランシング モードが RATE、max-rate が 80 RPS に設定され、容量スケーラーが 0.5 の場合、使用可能な容量は 40 RPS（0.5 times 80）になります。

• バランシング モードが RATE、max-rate が 80 RPS に設定され、容量スケーラーが 0.0 の場合、使用可能な容量はゼロ（0）になります。

サービス ロード バランシング ポリシー

サービス ロード バランシング ポリシー（serviceLbPolicy）は、ロードバランサのバックエンド サービスに関連付けられたリソースです。これにより、バックエンド サービスに関連付けられたバックエンド内でのトラフィックの分散方法に影響するパラメータをカスタマイズできます。

• リージョンまたはゾーン全体でのトラフィックの分散方法を決めるロード バランシング アルゴリズムをカスタマイズします。
• ロードバランサが正常でないバックエンドからトラフィックを迅速にドレインできるように、自動容量ドレインを有効にします。

特定のバックエンドを優先バックエンドとして指定することもできます。これらのバックエンドが容量（バックエンドのバランシング モードで指定されたターゲット容量）に達するまで使用されると、残りのバックエンドにリクエストが送信されます。

詳細については、サービス ロード バランシング ポリシーを使用した高度なロード バランシング最適化をご覧ください。

ロード バランシングの局所性ポリシー

バックエンド サービスの場合、トラフィック分散は、ロード バランシング モードとロード バランシング局所性ポリシーに基づいて行われます。分散モードでは、各バックエンド（インスタンス グループまたは NEG）に送信するトラフィックの割合を決定します。ロード バランシング局所性ポリシー（LocalityLbPolicy）により、各ゾーン内のインスタンスまたはエンドポイントにトラフィックを分散する方法が決まります。リージョン マネージド インスタンス グループの場合、局所性ポリシーは各構成ゾーンに適用されます。

ロード バランシング局所ポリシーは、バックエンド サービスごとに構成されます。次の設定を使用できます。

• ROUND_ROBIN（デフォルト）: これは、ロードバランサが正常なバックエンドをラウンドロビン順に選択する、デフォルトのロード バランシングの局所性ポリシー設定です。

• LEAST_REQUEST: ロードバランサが正常なホストをランダムに 2 つ選択し、アクティブなリクエストが少ないほうのホストを選択する O(1) アルゴリズム。

• RING_HASH: このアルゴリズムは、バックエンドに整合性ハッシュを実装します。このアルゴリズムには、N 個のホストセットに対して 1 個のホストを追加または削除しても、リクエストの 1/N にしか影響しないという特性があります。

• RANDOM: ロードバランサが正常なホストをランダムに選択します。

• ORIGINAL_DESTINATION: ロードバランサは、クライアント接続メタデータに基づいてバックエンドを選択します。リクエストがロードバランサにリダイレクトされる前に、受信したクライアント リクエストで指定された元の宛先 IP アドレスへの接続が開かれます。

  ORIGINAL_DESTINATION は、グローバル外部アプリケーション ロードバランサとリージョン外部アプリケーション ロードバランサではサポートされていません。

• MAGLEV: バックエンドに整合性ハッシュを実装し、RING_HASH ポリシーの代わりに使用できます。Maglev は RING_HASH ほど安定していませんが、テーブル検索のビルド時間とホスト選択時間が短縮されます。Maglev の詳細については、Maglev ホワイトペーパーをご覧ください。

• WEIGHTED_MAGLEV: ヘルスチェックによって報告された重みを使用して、インスタンスごとの重み付きロード バランシングを実装します。このポリシーを使用する場合、バックエンド サービスはレガシー以外の HTTP ベースのヘルスチェックを構成する必要があります。ヘルスチェック レスポンスには、インスタンスごとの重みを指定する標準外の HTTP レスポンス ヘッダー フィールド X-Load-Balancing-Endpoint-Weight が含まれていることが想定されます。すべてのインスタンスが有効な重みを報告するか、UNAVAILABLE_WEIGHT を報告している限り、ロード バランシング決定は、最後に処理されたヘルスチェック レスポンスで報告されたインスタンスごとの重みに基づいて行われます。それ以外の場合、ロード バランシングは均等な重み付けのままになります。

  WEIGHTED_MAGLEV は、外部パススルー ネットワーク ロードバランサでのみサポートされます。例については、外部パススルー ネットワーク ロードバランサの重み付きロード バランシングを設定するをご覧ください。

ロード バランシング局所性ポリシーの構成は、次のロードバランサで使用されるバックエンド サービスでのみサポートされます。

• グローバル外部アプリケーション ロードバランサ
• リージョン外部アプリケーション ロードバランサ
• クロスリージョン内部アプリケーション ロードバランサ
• リージョン内部アプリケーション ロードバランサ
• 外部パススルー ネットワーク ロードバランサ

ロード バランシングの局所性ポリシー（localityLbPolicy）の有効なデフォルト値は、セッション アフィニティの設定に応じて変わります。セッション アフィニティが構成されていない場合（セッション アフィニティがデフォルト値の NONE のままの場合）、localityLbPolicy のデフォルト値は ROUND_ROBIN です。セッション アフィニティが NONE 以外の値に設定されている場合、localityLbPolicy のデフォルト値は MAGLEV です。

ロード バランシング ローカリティー ポリシーを構成するには、Google Cloud コンソール、gcloud（--locality-lb-policy）、または API（localityLbPolicy）を使用します。

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 またはエンドポイントに送信されます。バランシング モードのターゲット容量により、バックエンドの容量が上限に達するタイミングが判断されます。

次の表に、各プロダクトでサポートされるセッション アフィニティのオプションを示します。

^* この表は、バックエンド サービスベースの外部パススルー ネットワーク ロードバランサでサポートされているセッション アフィニティを示しています。ターゲット プールベースの外部パススルー ネットワーク ロードバランサは、バックエンド サービスを使用しません。代わりに、ターゲット プールの sessionAffinity パラメータを通じて、外部パススルー ネットワーク ロードバランサのセッション アフィニティを設定します。

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

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

• --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 のパス属性は常にスラッシュ（/）になります。他のバックエンド サービスも生成された 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 を使用します。

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

ヘッダー フィールド アフィニティ

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

次のロードバランサは、ヘッダー フィールド アフィニティを使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサのすべてのセッション アフィニティ オプションには、次の要件があります。

• 選択したバックエンド インスタンスまたはエンドポイントは、バックエンドとして構成されたままにする必要があります。セッション アフィニティは、次のいずれかのイベントが発生すると破棄される可能性があります。

  • 選択したインスタンスをインスタンス グループから削除します。

  • マネージド インスタンス グループの自動スケーリングまたは自動修復により、選択したインスタンスがマネージド インスタンス グループから削除されます。

  • 選択したエンドポイントを NEG から削除します。

  • 選択したインスタンスまたはエンドポイントを含むインスタンス グループまたは NEG をバックエンド サービスから削除します。

• 選択したバックエンド インスタンスまたはエンドポイントは正常な状態を維持する必要があります。選択したインスタンスまたはエンドポイントでヘルスチェックが失敗すると、セッション アフィニティが破棄される可能性があります。

• グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、グローバル外部プロキシ ネットワーク ロードバランサ、従来のプロキシ ネットワーク ロードバランサの場合、ルーティング パスの変更後に、後続のリクエストまたは接続に別の第 1 レイヤの Google Front End（GFE）が使用されると、セッション アフィニティが破棄される可能性があります。インターネット上のクライアントから Google へのルーティング パスがリクエストまたは接続によって異なる場合は、別の第 1 レイヤの GFE が選択される可能性があります。

ステートフル Cookie ベースのセッション アフィニティを除き、アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサのすべてのセッション アフィニティ オプションには、次の追加要件があります。

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

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

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

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

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

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

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

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

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

ほとんどの 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 バックエンドを使用してバックエンド サービスを作成する場合は、既存のヘルスチェックを参照する必要があります。必要なヘルスチェックの種類と範囲については、ヘルスチェックの概要のロードバランサ ガイドを参照してください。

詳細については、次のドキュメントをご覧ください。

• ヘルスチェックの概要
• ヘルスチェックの作成
• gcloud ヘルスチェック ページ
• REST API ヘルスチェック ページ

バックエンド サービス リソースで有効な追加機能

一部のバックエンド サービスでは、次のオプション機能がサポートされています。

Cloud CDN

Cloud CDN は、Google のグローバル エッジ ネットワークを使用して、ユーザーの近くからコンテンツを提供します。これにより、ウェブサイトやアプリケーションが高速化されます。Cloud CDN は、グローバル外部アプリケーション ロードバランサで使用されるバックエンド サービスで有効になっています。リクエストを受信するフロントエンド IP アドレスとポート、そしてリクエストに応答するバックエンドは、ロードバランサが提供します。

詳細については、Cloud CDN のドキュメントをご覧ください。

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

Google Cloud Armor

次のいずれかのロードバランサを使用している場合は、ロードバランサの作成時にバックエンド サービスで Google Cloud Armor を有効にすることで、アプリケーションの保護を強化できます。

• グローバル外部アプリケーション ロードバランサ
• 従来のアプリケーション ロードバランサ
• グローバル外部プロキシ ネットワーク ロードバランサ
• 従来のプロキシ ネットワーク ロードバランサ

Google Cloud コンソールを使用する場合は、次のいずれかを行います。

• 既存の Google Cloud Armor セキュリティ ポリシーを選択します。
• カスタマイズ可能な名前、リクエスト数、間隔、key、レート制限パラメータを使用して、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 と互換性がありません。同じバックエンド サービスで有効にすることはできません。

高度なトラフィック管理機能

ロードバランサに関連付けられたバックエンド サービスと URL マップで構成される高度なトラフィック管理機能については、以下をご覧ください。

• 内部アプリケーション ロードバランサのトラフィック管理の概要
• グローバル外部アプリケーション ロードバランサのトラフィック管理の概要
• リージョン外部アプリケーション ロードバランサのトラフィック管理の概要

API と gcloud リファレンス

バックエンド サービス リソースのプロパティの詳細については、次のリファレンスをご覧ください。

• グローバル バックエンド サービスの API リソース

• リージョン バックエンド サービスの API リソース

• gcloud compute backend-services ページ。 グローバルおよび リージョン バックエンド サービスについて記載されています。

次のステップ

ロードバランサでバックエンド サービスを使用する方法については、次のドキュメントをご覧ください。

• カスタム ヘッダーの作成
• 外部アプリケーション ロードバランサを作成する
• 外部アプリケーション ロードバランサの概要
• コネクション ドレインを有効にする
• Google Cloud での転送データの暗号化

関連動画:

• グローバル外部アプリケーション ロードバランサのバックエンド サービスを構成する方法