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

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

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

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

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

グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを使用していて、バックエンドが静的コンテンツを配信する場合、バックエンド サービスの代わりにバックエンド バケットを使用することを検討してください。

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

表: バックエンド サービスとサポートされているバックエンド タイプ
プロダクト バックエンド サービスの最大数 バックエンド サービスのスコープ サポートされているバックエンドの種類 ロード バランシング スキーム
グローバル外部アプリケーション ロードバランサ 複数 グローバル 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
  • すべてのサーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Functions サービス。
  • Private Service Connect NEG: 複数の NEG が指定されている場合、NEG は異なるリージョンに配置する必要があります。
  • グローバル外部バックエンド用の 1 つのインターネット NEG
 EXTERNAL_MANAGED
従来のアプリケーション ロードバランサ 複数 グローバル1 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
  • すべてのサーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Functions サービス。
  • グローバル外部バックエンド用の 1 つのインターネット NEG
 EXTERNAL
リージョン外部アプリケーション ロードバランサ 複数 リージョン 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
  • 単一のサーバーレス NEG（Cloud Run のみ）
  • 単一の Private Service Connect NEG
  • 外部バックエンドのすべてのリージョン インターネット NEG
 EXTERNAL_MANAGED
クロスリージョン内部アプリケーション ロードバランサ 複数 グローバル 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
  • 単一のサーバーレス NEG（Cloud Run のみ）
  • 単一の Private Service Connect NEG
 INTERNAL_MANAGED
リージョン内部アプリケーション ロードバランサ 複数 リージョン 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
  • 単一のサーバーレス NEG（Cloud Run のみ）
  • 単一の Private Service Connect NEG
  • 外部バックエンドのすべてのリージョン インターネット NEG
 INTERNAL_MANAGED
グローバル外部プロキシ ネットワーク ロードバランサ 1 グローバル バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
 EXTERNAL_MANAGED
従来のプロキシ ネットワーク ロードバランサ 1 グローバル1 バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG 2
 EXTERNAL
リージョン外部プロキシ ネットワーク ロードバランサ 1 リージョン バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • 外部バックエンドのすべてのリージョン インターネット NEG
 EXTERNAL_MANAGED
リージョン内部プロキシ ネットワーク ロードバランサ 1 リージョン バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • 外部バックエンドのすべてのリージョン インターネット NEG
 INTERNAL_MANAGED
クロスリージョン内部プロキシ ネットワーク ロードバランサ 複数 グローバル バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG
  • すべてのハイブリッド接続 NEG: 1 つ以上の NON_GCP_PRIVATE_IP_PORT タイプの NEG
  • ゾーン NEG とハイブリッド NEG の組み合わせ: GCE_VM_IP_PORT タイプと NON_GCP_PRIVATE_IP_PORT タイプの NEG
 INTERNAL_MANAGED
外部パススルー ネットワーク ロードバランサ 1 リージョン バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP タイプのゾーン NEG
 EXTERNAL
内部パススルー ネットワーク ロードバランサ 1 リージョン タイプですが、グローバルにアクセスできるように構成可能です。 バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP タイプのゾーン NEG
 INTERNAL
Traffic Director 複数 グローバル 各バックエンド サービスは、次のいずれかのバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT または NON_GCP_PRIVATE_IP_PORT タイプのゾーン NEG。
  • INTERNET_FQDN_PORT タイプの 1 つのインターネット NEG
  • 1 つ以上のサービス バインディング
 INTERNAL_SELF_MANAGED
1 従来のアプリケーション ロードバランサと従来のプロキシ ネットワーク ロードバランサで使用されるバックエンド サービスは、スタンダードまたはプレミアムのネットワーク・ティアで、スコープがグローバルになります。ただし、スタンダード ティアでは次の制限が適用されます。
2 GKE のデプロイの場合、混合 NEG バックエンドはスタンドアロン NEG でのみサポートされます。

バックエンド

バックエンドは、Google Cloud ロードバランサ、Traffic Director で構成された Envoy プロキシ、 またはプロキシレス gRPC クライアントからトラフィックを受信する 1 つ以上のエンドポイントです。バックエンドにはいくつかの種類があります。

バックエンド サービスに関連付けられているバックエンド インスタンス グループまたは 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 はグローバルとリージョンの 2 つのスコープで使用できます。各スコープでインターネット 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、HTTPS、HTTP/2
プロキシ ネットワーク ロードバランサ

TCP または SSL

リージョン プロキシ ネットワーク ロードバランサは、TCP のみをサポートします。
パススルー ネットワーク ロードバランサ TCP、UDP、または UNSPECIFIED
Traffic Director HTTP、HTTPS、HTTP/2、gRPC、TCP

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

ロードバランサとバックエンド間の暗号化

ロードバランサとバックエンド間の暗号化については、バックエンドへの暗号化をご覧ください。

トラフィック分散

バックエンドの動作は、バックエンド サービス リソースの以下のフィールドの値で決まります。

  • バランシング モードは、ロードバランサが新しいリクエストまたは新しい接続のバックエンドの準備状況を測定する方法を定義します。
  • ターゲット容量は、ターゲットの最大接続数、ターゲットの最大レート、またはターゲットの最大 CPU 使用率を定義します。
  • 容量スケーラーは、ターゲット容量を変更せずに使用可能な容量全体を調整するために使用できます。

バランシング モード

バランシング モードでは、ロードバランサ または Traffic Director のバックエンドが追加のトラフィックを処理できるかどうか、または完全に読み込まれるかどうかを判別します。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（NON_GCP_PRIVATE_IP_PORT エンドポイント）

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

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

  • バックエンド全体のターゲット容量
  • 各インスタンスまたはエンドポイントに想定されるターゲット容量
表: CONNECTION バランシング モードを使用するバックエンドのターゲット容量
バックエンド タイプ ターゲット容量
指定するパラメータ バックエンド全体の容量 インスタンスごと、またはエンドポイントの容量あたり
インスタンス グループ
N インスタンス、
H 正常
 max-connections-per-instance=X X × N (X × N)/H
ゾーン NEG
N エンドポイント、
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 を使用してください。

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

  • バックエンド全体のターゲット容量
  • 各インスタンスまたはエンドポイントに想定されるターゲット容量
表: RATE バランシング モードを使用するバックエンドのターゲット容量
バックエンド タイプ ターゲット容量
指定するパラメータ バックエンド全体の容量 インスタンスごと、またはエンドポイントの容量あたり
インスタンス グループ
N インスタンス、
H 正常
 max-rate-per-instance=X X × N (X × N)/H
ゾーン NEG
N エンドポイント、
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 つしかないため、バランシング モードを変更できません。その他のロードバランサについては、バックエンド サービスに応じて複数のモードを使用できるため、使用するバックエンドに応じてバランシング モードを変更できます。

各ロードバランサでサポートされているバランシング モードを確認するには、表: 各ロードバランサで使用できるバランシング モードをご覧ください。

バランシング モードとターゲット容量の設定

次の表は、特定のロードバランサとバックエンドの種類に対して考えられるすべてのバランシング モードをまとめたものです。また、バランシング モードと併せて指定する必要がある、利用可能な容量設定または必要な容量設定も示しています。

表: バランシング モードのターゲット容量の仕様
ロードバランサ バックエンドの種類 バランシング モード ターゲット容量
  • アプリケーション ロードバランサ
  • Traffic Director
 インスタンス グループ RATE 次のいずれかを指定する必要があります。
  • ゾーン インスタンス グループあたりの max-rate
  • max-rate-per-instance
    （ゾーン インスタンス グループまたはリージョン インスタンス グループ）
UTILIZATION 必要に応じて、次のいずれかを指定できます。
  • (1) max-utilization
  • (2) ゾーン インスタンス グループあたりの max-rate
  • (3) max-rate-per-instance
    （ゾーン インスタンス グループまたはリージョン インスタンス グループ）
  • (1) と (2) を同時に指定
  • (1) と (3) を同時に指定
ゾーン NEG（GCP_VM_IP_PORT） RATE 次のいずれかを指定する必要があります。
  • ゾーン NEG あたりの max-rate
  • max-rate-per-endpoint
ハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT） RATE 次のいずれかを指定する必要があります。
  • ハイブリッド NEG あたりの max-rate
  • max-rate-per-endpoint
  • グローバル外部プロキシ ネットワーク ロードバランサ
  • 従来のプロキシ ネットワーク ロードバランサ
  • リージョン外部プロキシ ネットワーク ロードバランサ
  • リージョン内部プロキシ ネットワーク ロードバランサ
  • クロスリージョン内部プロキシ ネットワーク ロードバランサ
 インスタンス グループ CONNECTION 次のいずれかを指定する必要があります。
  • ゾーン インスタンス グループあたりの max-connections
  • max-connections-per-instance（ゾーン インスタンス グループまたはリージョン インスタンス グループ）
UTILIZATION 必要に応じて、次のいずれかを指定できます。
  • (1) max-utilization
  • (2) ゾーン インスタンス グループあたりの max-connections
  • (3) max-connections-per-instance
    （ゾーン インスタンス グループまたはリージョン インスタンス グループ）
  • (1) と (2) を同時に指定
  • (1) と (3) を同時に指定
ゾーン NEG（GCP_VM_IP_PORT） CONNECTION 次のいずれかを指定する必要があります。
  • ゾーン NEG あたりの max-connections
  • max-connections-per-endpoint

ハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT）

 CONNECTION 次のいずれかを指定する必要があります。
  • ハイブリッド NEG あたりの max-connections
  • max-connections-per-endpoint
パススルー ネットワーク ロードバランサ インスタンス グループ CONNECTION ターゲットの最大接続数は指定できません。
ゾーン NEG（GCP_VM_IP） CONNECTION ターゲットの最大接続数は指定できません。

容量スケーラー

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

Google Cloud リファレンス ドキュメントについては、以下をご覧ください。

容量スケーラーを調整すると、いずれかの --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）は、ロードバランサのバックエンド サービスに関連付けられたリソースです。これにより、バックエンド サービスに関連付けられたバックエンド内でのトラフィックの分散方法に影響するパラメータをカスタマイズできます。

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

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

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

Traffic Director とトラフィック分散

Traffic Director もバックエンド サービス リソースを使用します。具体的には、Traffic Director は、負荷分散スキームが INTERNAL_SELF_MANAGED であるバックエンド サービスを使用します。内部のセルフマネージド バックエンド サービスの場合、トラフィック分散は、ロード バランシング モードとロード バランシング ポリシーの組み合わせに基づいています。バックエンド サービスは、バックエンドの分散モードに従ってバックエンドにトラフィックを転送します。その後、Traffic Director が負荷分散ポリシーに従ってトラフィックを分散します。

内部セルフマネージド バックエンド サービスは、次の分散モードをサポートします。

  • UTILIZATION - バックエンドがすべてインスタンス グループの場合
  • RATE - すべてのバックエンドがインスタンス グループまたはゾーン NEG の場合

RATE 負荷分散モードを選択する場合は、最大レート、インスタンスあたりの最大レート、またはエンドポイントあたりの最大レートを指定する必要があります。

Traffic Director の詳細については、Traffic Director のコンセプトをご覧ください。

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

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

バックエンドのサブセット化は、以下でサポートされています。

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

リージョン内部アプリケーション ロードバランサのバックエンドのサブセット化

クロスリージョン内部アプリケーション ロードバランサはバックエンドのサブセット化をサポートしていません。

リージョン内部アプリケーション ロードバランサの場合、バックエンドのサブセット化は、リージョン バックエンド サービス内のバックエンドのサブセットのみを各プロキシ インスタンスに自動的に割り当てます。デフォルトでは、各プロキシ インスタンスはバックエンド サービス内のすべてのバックエンドとの接続を開始します。プロキシ インスタンスの数とバックエンドの数が両方とも多いときに、すべてのバックエンドと接続を開始すると、パフォーマンスの問題が発生する可能性があります。

サブセット化を有効にすると、各プロキシはバックエンドのサブセットへの接続のみを開始するため、各バックエンドに対して開始する接続の数が少なくなります。各バックエンドに対して同時に開始する接続数を減らすと、バックエンドとプロキシの両方のパフォーマンスが向上します。

次の図は、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 エンドポイントで、同じサブセットが使用されます。リージョンごとに異なるサブセットが使用されます。
  • UNSPECIFIED バックエンド サービス プロトコルは使用できません。

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

バックエンドのサブセット化の使用に料金はかかりません。詳しくは、ネットワーキングのすべての料金をご覧ください。

セッション アフィニティ

セッション アフィニティを使用すると、正常なバックエンドの数が一定である限り、予測可能な方法でロードバランサが新しい接続にバックエンドを選択する方法を制御できます。これは、特定のユーザーからの複数のリクエストを同じバックエンドまたはエンドポイントに転送する必要があるアプリケーションに役立ちます。このようなアプリケーションとしては、広告配信、ゲーム、または内部キャッシュが頻繁に行われるサービスで使用されるステートフル サーバーなどがあります。

Google Cloud ロードバランサは、ベストエフォート ベースでのセッション アフィニティを実現します。バックエンドの追加や削除、バランシング モードで測定されるバックエンド ヘルスチェックに関する状態の変化、バックエンド使用率の変化などの要因により、セッション アフィニティが失われる可能性があります。

セッション アフィニティによるロード バランシングは、一意の接続が適切な規模で分散されている場合にうまく機能します。適切な規模とは、バックエンド数の少なくとも数倍を意味します。接続数が少ない状態でロードバランサをテストしても、バックエンド間でのクライアント接続の分散を正確に表すことはできません。

デフォルトでは、すべての Google Cloud ロードバランサは、次のように 5 タプルハッシュ（--session-affinity=NONE）を使用してバックエンドを選択します。

  • パケットの送信元 IP アドレス
  • パケットの送信元ポート（パケットのヘッダーにある場合）
  • パケットの宛先 IP アドレス
  • パケットの宛先ポート（パケットのヘッダーにある場合）
  • パケットのプロトコル

パススルー ロードバランサの場合、新しい接続は正常なバックエンド インスタンスまたはエンドポイントに分散されます（フェイルオーバー ポリシーが構成されている場合は、アクティブ プール内）。次のことを制御できます。

プロキシベースのロードバランサの場合、正常なバックエンド インスタンスまたはエンドポイントの数が一定であり、以前に選択したバックエンド インスタンスまたはエンドポイントの容量が上限に達していない限り、後続のリクエストまたは接続は、同じバックエンド VM またはエンドポイントに送信されます。バランシング モードのターゲット容量により、バックエンドの容量が上限に達するタイミングが判断されます。

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

表: サポートされているセッション アフィニティの設定
プロダクト セッション アフィニティのオプション
  • なし（NONE）
  • クライアント IP（CLIENT_IP）
  • 生成した Cookie（GENERATED_COOKIE）
  • ヘッダー フィールド（HEADER_FIELD）
  • HTTP Cookie（HTTP_COOKIE）

また、次の点にもご注意ください。

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

また、次の点にもご注意ください。

  • ロード バランシングの局所性ポリシー（localityLbPolicy）の有効なデフォルト値は、セッション アフィニティの設定に応じて変わります。セッション アフィニティが構成されていない場合（セッション アフィニティがデフォルト値の NONE のままの場合）、localityLbPolicy のデフォルト値は ROUND_ROBIN です。セッション アフィニティが NONE 以外の値に設定されている場合、localityLbPolicy のデフォルト値は MAGLEV です。
  • 内部アプリケーション ロードバランサの場合、重み付けによるトラフィック分割を使用する場合は、セッション アフィニティを構成しないでください。セッション アフィニティを構成した場合、重み付けトラフィック分割構成が優先されます。
内部パススルー ネットワーク ロードバランサ
  • なし（NONE）
  • クライアント IP、宛先なし（CLIENT_IP_NO_DESTINATION）
  • クライアント IP、宛先 IP（CLIENT_IP）
  • クライアント IP、宛先 IP、プロトコル（CLIENT_IP_PROTO）
  • クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル（CLIENT_IP_PORT_PROTO）

内部パススルー ネットワーク ロードバランサとセッション アフィニティの具体的な情報については、内部パススルー ネットワーク ロードバランサの概要をご覧ください。
外部パススルー ネットワーク ロードバランサ1
  • なし（NONE）
  • クライアント IP、宛先 IP（CLIENT_IP）
  • クライアント IP、宛先 IP、プロトコル（CLIENT_IP_PROTO）
  • クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル（CLIENT_IP_PORT_PROTO）

外部パススルー ネットワーク ロードバランサとセッション アフィニティの具体的な情報については、外部 TCP / UDP 外部パススルー ネットワーク ロードバランサの概要をご覧ください。
  • グローバル外部プロキシ ネットワーク ロードバランサ
  • 従来のプロキシ ネットワーク ロードバランサ
  • リージョン外部プロキシ ネットワーク ロードバランサ
  • リージョン内部プロキシ ネットワーク ロードバランサ
  • クロスリージョン内部プロキシ ネットワーク ロードバランサ
  • なし（NONE）
  • クライアント IP（CLIENT_IP）
Traffic Director
  • なし（NONE）
  • クライアント IP（CLIENT_IP）
  • 生成された Cookie（GENERATED_COOKIE）（HTTP プロトコルのみ）
  • ヘッダー フィールド（HEADER_FIELD）（HTTP プロトコルのみ）
  • HTTP Cookie（HTTP_COOKIE）（HTTP プロトコルのみ）

プロキシレス 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、宛先なしアフィニティは、内部パススルー ネットワーク ロードバランサの唯一のオプションです。

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

クライアント IP アフィニティ（CLIENT_IP）は、同じクライアント IP アドレスからのリクエストを同じバックエンド インスタンスに転送します。クライアント IP アフィニティは、バックエンド サービスを使用する Google Cloud ロードバランサのオプションです。

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

  • クライアント IP アフィニティは、クライアントの IP アドレスと、クライアントが接続するロードバランサの転送ルールの IP アドレスで構成される 2 タプルのハッシュです。

  • NAT の背後にある場合や、プロキシ経由でリクエストを行っている場合、ロードバランサから見たクライアント IP アドレスが発信元のクライアントではない可能性があります。NAT またはプロキシ経由のリクエストは、NAT ルーターまたはプロキシの IP アドレスをクライアント IP アドレスとして使用します。これにより、トラフィックが同じバックエンド インスタンスに集中することがあります。

  • クライアントが別のネットワークを移動すると、IP アドレスが変更され、アフィニティが失われます。

クライアント IP アフィニティをサポートするプロダクトについては、表: サポートされているセッション アフィニティの設定をご覧ください。

生成された Cookie アフィニティが設定されている場合、ロードバランサは最初のリクエストで Cookie を発行します。同じ Cookie を持つ後続のリクエストは、ロードバランサによって同じバックエンド VM またはエンドポイントに送信されます。

  • グローバル外部アプリケーション ロードバランサの場合、Cookie の名前は GCLB になります。
  • Traffic Director、 リージョン外部アプリケーション ロードバランサ、内部アプリケーション ロードバランサの場合、Cookie の名前は GCILB になります。

Cookie ベースのアフィニティの場合、クライアント IP ベースのアフィニティよりも正確にクライアントを識別できます。例:

  1. Cookie ベースのアフィニティでは、同じソース IP アドレスを共有する 2 つ以上のクライアント システムを一意に識別できます。クライアント IP ベースのアフィニティでは、ロードバランサは、同じソース IP アドレスからのすべての接続を同じクライアント システムからのものとして扱います。

  2. クライアントが IP アドレスを変更すると、Cookie ベースのアフィニティであれば、新しい接続を新しいクライアントとしてではなく、同じクライアントとして認識できます。クライアントが IP アドレスを変更する例は、モバイル デバイスがネットワーク間で移動するときです。

ロードバランサにより、生成された Cookie ベースのアフィニティ用の Cookie が作成されると、Cookie の path 属性が / に設定されます。URL マップのパスマッチャーがホスト名に複数のバックエンド サービスがある場合、すべてのバックエンド サービスは同じセッション Cookie を共有します。

ロードバランサによって生成された HTTP Cookie の存続期間は構成できます。0（デフォルト）に設定すると、Cookie はセッション Cookie になります。また、Cookie の存続期間を 1 から 86400 秒（24 時間）までの値に設定することもできます。

生成された Cookie アフィニティをサポートするプロダクトについては、表: サポートされているセッション アフィニティの設定をご覧ください。

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

次の条件が両方とも満たされている場合、Traffic Director と内部アプリケーション ロードバランサでヘッダー フィールド アフィニティを使用できます。

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

ヘッダー フィールド アフィニティをサポートするサービスについては、表: サポートされているセッション アフィニティの設定をご覧ください。

Traffic Director、グローバル外部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、グローバル外部プロキシ ネットワーク ロードバランサ、リージョン外部プロキシ ネットワーク ロードバランサ、クロスリージョン内部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサは、次の両方に該当する場合は、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 のいずれかのバランシング モードを使用して軽減できます。

外部アプリケーション ロードバランサまたは外部プロキシ ネットワーク ロードバランサを使用する場合は、次の追加ポイントに留意してください。

  • インターネット上のクライアントから 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 を使用してバックエンド サービス タイムアウトの値を設定できますが、値は無視されます。バックエンド サービスのタイムアウトは、これらのパススルー ロードバランサにとって意味がありません。

  • Traffic Director の場合、バックエンド サービスのタイムアウト フィールド（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 の概要をご覧ください。

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 の保護を無効にすることを選択します。

トラフィック管理機能

次の機能は一部のプロダクトでのみサポートされています。

これらの機能は、次のロードバランサでサポートされています。

  • グローバル外部アプリケーション ロードバランサ（サーキット ブレーカーはサポートされていません）
  • リージョン外部アプリケーション ロードバランサ
  • クロスリージョン内部アプリケーション ロードバランサ
  • リージョン内部アプリケーション ロードバランサ
  • Traffic Director（プロキシレス gRPC サービスではサポートされません）

API と gcloud リファレンス

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

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

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

次のステップ

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

関連動画: