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