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

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

次の Google Cloud 負荷分散サービスにバックエンド サービスを構成できます。

  • 外部 HTTP(S) 負荷分散
  • 内部 HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • 内部 TCP / UDP 負荷分散
  • 外部 TCP / UDP ネットワーク負荷分散

Traffic Director もバックエンド サービスを使用します。

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

  • トラフィックを正しいバックエンド、すなわちインスタンス グループまたはネットワーク エンドポイント グループ(NEG)に転送する。バックエンド サービスの代わりにバックエンド バケットを使用するように外部 HTTP(S) ロードバランサを構成できます。外部 HTTP(S) ロードバランサでバックエンド バケットを使用する方法については、バックエンド バケットを使用したロードバランサの設定をご覧ください。
  • 各バックエンドで設定された負荷分散モードに従ってトラフィックを分散する。
  • バックエンドの状態をモニタリングしているヘルスチェックを判別する。
  • セッション アフィニティを指定する。
  • 以下を含む、他のサービスが有効になっていることを確認する。
    • Cloud CDN(外部 HTTP(S) ロードバランサのみ)
    • Google Cloud Armor セキュリティ ポリシー(外部 HTTP(S) ロードバランサのみ)
    • Identity-Aware Proxy(外部 HTTP(S) ロードバランサのみ)

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

バックエンド サービスのスコープはグローバルまたはリージョンです。

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

使用しているプロダクト(ロードバランサまたは Traffic Director)。次のことを確認します。

  • バックエンド サービスの最大数
  • バックエンド サービスのスコープ
  • 各バックエンド サービスで使用できるバックエンドのタイプ
  • バックエンド サービスの負荷分散スキーム
プロダクト バックエンド サービスの最大数 バックエンド サービスのスコープ サポートされているバックエンドの種類 負荷分散スキーム
外部 HTTP(S) 負荷分散 複数 グローバル1 各バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT のゾーン NEG。
  • すべてのサーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Functions サービス。
  • 1 つのインターネット NEG。
EXTERNAL
内部 HTTP(S) 負荷分散 複数 リージョン 各バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT のゾーン NEG。
INTERNAL_MANAGED
SSL プロキシ負荷分散 1 グローバル1 バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG。
  • 1 つのインターネット NEG。
EXTERNAL
TCP プロキシ負荷分散 1 グローバル1 バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT タイプのゾーン NEG。
  • 1 つのインターネット NEG。
EXTERNAL
ネットワーク負荷分散 1 リージョン バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
EXTERNAL
内部 TCP / UDP 負荷分散 1 リージョン タイプですが、グローバルにアクセスできるように構成可能です。 バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP のゾーン NEG。
INTERNAL
Traffic Director 複数 グローバル 各バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上の GCE_VM_IP_PORT のゾーン NEG。
INTERNAL_SELF_MANAGED

1 HTTP(S) 負荷分散、SSL プロキシ負荷分散、TCP プロキシ負荷分散で使用されるバックエンド サービスについて、スタンダードまたはプレミアムのネットワーク階層におけるスコープは常にグローバルです。ただし、スタンダード ティアでは次の制限が適用されます。

バックエンド

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

また、バックエンド サービスの代わりにバックエンド バケットを使用すると、Cloud Storage バケット バックエンドを使用できます。

同じバックエンド サービスで複数の種類のバックエンドを使用することはできません。たとえば、1 つのバックエンド サービスは、インスタンス グループとゾーン NEG の組み合わせを参照できません。ただし、同じバックエンド サービスで異なる種類のインスタンス グループを組み合わせて使用できます。たとえば、1 つのバックエンド サービスは、マネージド インスタンス グループと非マネージド インスタンス グループの両方の組み合わせを参照できます。互換性があるバックエンドとバックエンド サービスの組み合わせについては、前のセクションの表をご覧ください。

バックエンド サービスに関連付けられているバックエンド インスタンス グループまたは NEG は削除できません。インスタンス グループまたは NEG を削除する前に、参照元であるすべてのバックエンド サービスからバックエンドとして削除する必要があります。

バックエンドへのプロトコル

バックエンド サービスを作成する場合は、バックエンドとの通信に使用するプロトコルを指定する必要があります。指定できるプロトコルはバックエンド サービスごとに 1 つのみです。フォールバックとして使用するセカンダリ プロトコルを指定することはできません。

使用可能なプロトコルは次のとおりです。

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP
  • gRPC(Traffic Director のみ)

どのプロトコルが有効かは、ロードバランサの種類と Traffic Director を使用しているかどうかによって異なります。詳細については、ロードバランサの機能Traffic Director の機能をご覧ください。

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

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

このトピックの詳細については、バックエンドへの暗号化をご覧ください。

インスタンス グループ

このセクションでは、インスタンス グループがバックエンド サービスでどのように機能するのかについて説明します。

バックエンド VM と外部 IP アドレス

バックエンド サービスのバックエンド VM には外部 IP アドレスは必要ありません。

  • 外部 HTTP(S) ロードバランサ、SSL プロキシ ロードバランサ、TCP プロキシ ロードバランサの場合: クライアントは、ロードバランサの外部 IP アドレスを使用して Google Front End(GFE)と通信します。GFE は、バックエンドの VPC ネットワークの識別子と VM またはエンドポイントの内部 IP アドレスの組み合わせを使用して、バックエンド VM またはエンドポイントと通信します。内部 IP アドレスは、バックエンドのプライマリ ネットワーク インターフェース(nic0)に関連付けられている必要があります。特別なルートですが、GFE とバックエンド VM またはエンドポイント間の通信は容易です。
  • ネットワーク ロードバランサの場合、パケットはネットワーク ロードバランサの外部 IP アドレスにルーティングされます。その後、ロードバランサは同じハッシュを使用してバックエンド VM にルーティングします。
  • 内部 HTTP(S) ロードバランサ、内部 TCP/UDP ロードバランサ、Traffic Director の場合: バックエンド VM に外部 IP アドレスは必要ありません。

名前付きポート

バックエンドで、ロードバランサは、バックエンド インスタンス(Compute Engine インスタンス)がリッスンしているポート番号にトラフィックを転送します。インスタンス グループでそのポート番号を構成し、バックエンド サービスの構成でその番号を参照します。

インスタンス グループの名前付きポートがバックエンド サービス構成の --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-namemy-service-name に設定して、バックエンド サービス構成の名前付きポートを参照します。

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

名前付きポート(http:80,http:8080 など)に複数のポート番号を使用する場合は、それらがすべて同じアプリケーション用である必要があります。これは、同じポート名のすべてのポート間でトラフィックが分散されるためです。たとえば、80443 の値で名前付きポートを作成することはできません。通常、ポート 80 は TLS をサポートしていないため、うまくいきません。

名前付きポートの作成方法については、次の手順をご覧ください。

次の点にご注意ください。

  • 各バックエンド サービスは、1 つのポート名をサブスクライブします。各バックエンド インスタンス グループには、その名前に対して少なくとも 1 つの名前付きポートが必要です。

  • 各インスタンス グループが同じポート名に異なるポート番号を指定している場合は、バックエンド サービスが異なるインスタンス グループの VM と通信するときに、別のポート番号を使用できます。ただし、すべてのポートが同じアプリケーションを表す必要があります。たとえば、http:80,http:8080 は機能しますが、http:80,http:443 は機能しません。

  • バックエンド サービスが使用する解決済みのポート番号は、ロードバランサの転送ルールで使用されるポート番号と一致する必要はありません。ロードバランサは、ロードバランサの転送ルールで構成された 1 つ以上のポート番号でフロントエンドをリッスンします。バックエンド インスタンスは異なるポート番号でリッスンできます。

次の状況では名前付きポートは使用されません。

  • ゾーン NEG またはインターネット NEG バックエンドの場合。これらの NEG は異なるメカニズムで(つまりエンドポイント自体で)ポートを定義するため。
  • サーバーレス NEG バックエンドの場合。これらの NEG にはエンドポイントがありません。
  • 内部 TCP / UDP ロードバランサの場合。内部 TCP / UDP ロードバランサはプロキシではなくパススルー ロードバランサであり、そのバックエンド サービスは名前付きポートをサブスクライブしないため。
  • ネットワーク ロードバランサの場合、ネットワーク ロードバランサはプロキシではなくパススルー ロードバランサであるため、バックエンド サービスは名前付きポートに登録されません。

名前付きポートの詳細については、SDK ドキュメントの gcloud compute instance-groups managed set-named-portsgcloud compute instance-groups unmanaged set-named-ports をご覧ください。

インスタンス グループに関する制限とガイダンス

ロードバランサのインスタンス グループを作成する際は、次の制限とガイダンスに留意してください。

  • 複数の負荷分散されたインスタンス グループに VM を配置しないでください。VM が 2 つ以上の非マネージド インスタンス グループのメンバー、または 1 つのマネージド インスタンス グループと 1 つ以上の非マネージド インスタンス グループのメンバーである場合、Google Cloud では、一度に特定のバックエンド サービスのバックエンドとして使用できるのは、これらのインスタンス グループの 1 つに制限されます。

    VM が複数のロードバランサに参加する必要がある場合は、同じインスタンス グループを各バックエンド サービスのバックエンドとして使用する必要があります。トラフィックを異なるポートに分散するには、1 つのインスタンス グループに必要な名前付きポートを作成し、各バックエンド サービスが一意の名前付きポートをサブスクライブするように設定します。

  • 同じインスタンス グループを複数のバックエンド サービスのバックエンドとして使用できます。この場合、バックエンドで互換性のある分散モードを使用する必要があります。互換性とはつまり、分散モードが同じか、CONNECTIONRATE の組み合わせでなければなりません。互換性のない組み合わせは次のとおりです。

    • CONNECTIONUTILIZATION
    • RATEUTILIZATION

    次に例を示します。

    • 外部 HTTP(S) ロードバランサの external-https-backend-service と内部 TCP / UDP ロードバランサの internal-tcp-backend-service の 2 つのバックエンド サービスがあります。
    • internal-tcp-backend-serviceinstance-group-a というインスタンス グループを使用しています。
    • 内部 TCP / UDP ロードバランサは CONNECTION 分散モードのみをサポートしているため、internal-tcp-backend-service では、CONNECTION 分散モードを適用する必要があります。
    • external-https-backend-serviceRATE 分散モードを適用する場合は、external-https-backend-serviceinstance-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 で使用できるネットワーク エンドポイントには次の 2 種類があります。

  • GCE_VM_IP エンドポイント。
  • GCE_VM_IP_PORT エンドポイント。

詳細については、ゾーン NEG の概要をご覧ください。

ゾーン NEG をバックエンドとして使用するバックエンド サービスは、VM 内で実行されているアプリケーションやコンテナ間でトラフィックを分散します。

GCE_VM_IP_PORT エンドポイントを使用するゾーン ネットワーク エンドポイント グループ(NEG)は、次のロードバランサ タイプのバックエンドとして使用できます。

  • 内部 HTTP(S) 負荷分散
  • HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散

Traffic Director は、GCE_VM_IP_PORT エンドポイントを使用したゾーン NEG バックエンドもサポートしています。

GCE_VM_IP エンドポイントを使用するゾーン ネットワーク エンドポイント グループ(NEG)は、内部 TCP / UDP 負荷分散のバックエンドとしてのみ使用できます。

ゾーン NEG はネットワーク負荷分散ではサポートされていません。

詳細については、負荷分散におけるネットワーク エンドポイント グループの概要をご覧ください。

インターネット ネットワーク エンドポイント グループ

インターネット NEG は、オンプレミス インフラストラクチャ内またはサードパーティによって提供されるインフラストラクチャ内でホストされるグローバル リソースです。

インターネット NEG は、IP アドレスまたはホスト名とポート(オプション)の組み合わせです。

  • 一般公開で解決可能な完全修飾ドメイン名とオプションのポート、backend.example.com:443 など(デフォルト ポート: HTTP の場合 80、HTTPS の場合 443
  • 公開アクセス可能な IP アドレスとオプションのポート、203.0.113.8:80203.0.113.8:443 など(デフォルト ポート: HTTP の場合 80、HTTPS の場合 443

バックエンドとしてインターネット ネットワーク エンドポイント グループを使用する外部 HTTP(S) ロードバランサのバックエンド サービスは、Google Cloud の外部の宛先にトラフィックを分散します。

インターネット NEG をサポートするロードバランサなどの詳細については、インターネット ネットワーク エンドポイント グループの概要をご覧ください。

サーバーレス ネットワーク エンドポイント グループ

ネットワーク エンドポイント グループ(NEG)は、ロードバランサのバックエンド エンドポイントのグループを指定します。サーバーレス NEG は、Cloud RunApp Engine、または Cloud Functions サービスを指すバックエンドです。

サーバーレス NEG は次のいずれかに相当します。

  • Cloud Run サービス、または同じ URL パターンを共有する複数のサービス。
  • Cloud Functions の関数、または同じ URL パターンを共有する関数のグループ。
  • App Engine アプリ(スタンダードまたはフレキシブル)、アプリ内の特定のサービス、またはアプリの特定のバージョン。

サーバーレス NEG をサポートするロードバランサなどの詳細については、サーバーレス ネットワーク エンドポイント グループの概要をご覧ください。

トラフィック分散

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

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

分散モード

分散モードでは、ロードバランサのバックエンドが追加のトラフィックを処理できるかどうか、または完全に読み込まれるかどうかを判別します。Google Cloud には次の 3 つの負荷分散モードがあります。

  • CONNECTION
  • RATE
  • UTILIZATION

負荷分散モードのオプションは、バックエンド サービスの負荷分散スキーム、バックエンド サービスのプロトコル、バックエンド サービスに接続されているバックエンドの種類によって異なります。

バックエンド サービスにバックエンドを追加する際に、負荷分散モードを設定します。サーバーレス NEG またはインターネット NEG をロードバランサのバックエンドとして使用する場合、分散モードを指定することはできません。

分散モード サポートされている負荷分散スキーム 互換性のあるバックエンド サービス プロトコル1 互換性のあるバックエンド2 対象プロダクト
CONNECTION EXTERNAL
INTERNAL
SSL、TCP、UDP
インスタンス グループまたはゾーン NEG(サポートされている場合)。
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • 内部 TCP / UDP 負荷分散
  • ネットワーク負荷分散
RATE EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
HTTP、HTTPS、HTTP2、gRPC インスタンス グループまたはゾーン NEG
  • 外部 HTTP(S) 負荷分散
  • 内部 HTTP(S) 負荷分散
  • Traffic Director(INTERNAL_SELF_MANAGED、HTTP、TCP、gRPC プロトコルのみ)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
特に制限なし インスタンス グループのみ。ゾーン NEG は使用率モードをサポートしていません。
  • 外部 HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • 内部 HTTP(S) 負荷分散
  • Traffic Director(INTERNAL_SELF_MANAGED、HTTP、TCP、gRPC プロトコルのみ)

1 プロトコルは、ロードバランサの種類に基づいてさらに制限されます。

2 サポートされているバックエンド タイプ(インスタンス グループやゾーン NEG など)については、ロードバランサの機能ページのバックエンドをご覧ください。

バックエンド サービスに関連付けられているすべての VM の平均使用率が 10% 未満の場合、Google Cloud は特定のゾーンを優先する場合があります。マネージド リージョン インスタンス グループ、異なるゾーンのマネージド ゾーン インスタンス グループ、非マネージド ゾーン インスタンス グループを使用すると、この状況が発生する可能性があります。このゾーン間の不均衡は、ロードバランサに送信されるトラフィックが増加するにつれて自動的に解決されます。

詳細については、gcloud beta compute backend-services add-backend をご覧ください。

ロードバランサの負荷分散モードの変更

一部のロードバランサは、バックエンド サービスに使用可能な負荷分散モードが 1 つしかなく、負荷分散モードを変更できません。その他のロードバランサについては、バックエンド サービスに応じて複数のモードを使用できるため、使用するバックエンドに応じて分散モードを変更できます。

ロードバランサ バックエンド 使用可能な分散モード
HTTP(S) 負荷分散 インスタンス グループ RATE または UTILIZATION
ゾーン NEG(GCE_VM_IP_PORT エンドポイント) RATE
内部 HTTP(S) 負荷分散 インスタンス グループ RATE または UTILIZATION
ゾーン NEG(GCE_VM_IP_PORT エンドポイント) RATE
TCP プロキシ負荷分散 インスタンス グループ CONNECTION または UTILIZATION
ゾーン NEG(GCE_VM_IP_PORT エンドポイント) CONNECTION
SSL プロキシ負荷分散 インスタンス グループ CONNECTION または UTILIZATION
ゾーン NEG(GCE_VM_IP_PORT エンドポイント) CONNECTION
ネットワーク負荷分散 インスタンス グループ CONNECTION
内部 TCP / UDP 負荷分散 インスタンス グループ CONNECTION
ゾーン NEG(GCE_VM_IP エンドポイント) CONNECTION

ターゲット容量

各分散モードには、対応するターゲット容量があり、次のターゲット上限のいずれかを定義します。

  • 接続の数
  • 料金
  • 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
ゾーン NEG
N エンドポイント、
H 正常
max-connections-per-endpoint=X X × N (X × N)/H
インスタンス グループ
(リージョン マネージド インスタンス グループを除く)

H 正常なインスタンス
max-connections=Y Y Y/H

max-connections-per-instancemax-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
ゾーン NEG
N エンドポイント、
H 正常
max-rate-per-endpoint=X X × N (X × N)/H
インスタンス グループ
(リージョン マネージド インスタンス グループを除く)

H 正常なインスタンス
max-rate=Y Y Y/H

max-rate-per-instancemax-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 分散モードでは、ターゲット容量を定義する必要はありません。次のセクションの表で説明するように、バックエンドのタイプに依存するオプションを使用できます。

分散モードの組み合わせ

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

ロードバランサ バックエンドの種類 分散モード ターゲット容量
内部 TCP / UDP 負荷分散 インスタンス グループ CONNECTION ターゲットの最大接続数は指定できません。
ゾーン NEG(GCP_VM_IP CONNECTION ターゲットの最大接続数は指定できません。
外部 TCP / UDP ネットワーク負荷分散 インスタンス グループ CONNECTION ターゲットの最大接続数は指定できません。
SSL プロキシ負荷分散、TCP プロキシ負荷分散 インスタンス グループ CONNECTION 次のいずれかを指定する必要があります。
  • ゾーン インスタンス グループあたりの max-connections
  • max-connections-per-instance(ゾーン インスタンス グループまたはリージョン インスタンス グループ)
UTILIZATION 必要に応じて、次のいずれかを指定できます。
  • max-utilization
  • ゾーン インスタンス グループあたりの max-connections
  • max-connections-per-instance
    (ゾーン インスタンス グループまたはリージョン インスタンス グループ)
  • 1 と 2 を同時に指定
  • 1 と 3 を同時に指定
ゾーン NEG(GCP_VM_IP_PORT CONNECTION 次のいずれかを指定する必要があります。
  • ゾーン NEG あたりの max-connections
  • max-connections-per-endpoint
HTTP(S) 負荷分散、内部 HTTP(S) 負荷分散、Traffic Director インスタンス グループ RATE 次のいずれかを指定する必要があります。
  • ゾーン インスタンス グループあたりの max-rate
  • max-rate-per-instance
    (ゾーン インスタンス グループまたはリージョン インスタンス グループ)
UTILIZATION 必要に応じて、次のいずれかを指定できます。
  • max-utilization
  • ゾーン インスタンス グループあたりの max-rate
  • max-rate-per-instance
    (ゾーン インスタンス グループまたはリージョン インスタンス グループ)
  • 1 と 2 を同時に指定
  • 1 と 3 を同時に指定
ゾーン NEG(GCP_VM_IP_PORT RATE 次のいずれかを指定する必要があります。
  • ゾーン NEG あたりの max-rate
  • max-rate-per-endpoint

容量スケーラー

容量スケーラーを調整して、ターゲット容量を変更せずにターゲット容量(最大使用率、最大レート、または最大接続数)をスケールダウンすることもできます。容量スケーラーは、ターゲット容量をサポートするすべてのロードバランサでサポートされています。唯一の例外は、ネットワーク ロードバランサと内部 TCP / UDP ロードバランサです。

デフォルトでは、容量スケールの値は 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 のコンセプトをご覧ください。

セッション アフィニティ

一部のアプリケーションでは、特定のユーザーからの複数のリクエストを同じバックエンドまたはエンドポイントに転送する必要があります。これには、広告配信、ゲーム、または内部キャッシュが頻繁に行われるサービスで使用されるステートフル サーバーが含まれます。セッション アフィニティのデメリットは、負荷が均等に分散されない可能性があることです。

セッション アフィニティは、最初のリクエストを処理した同じバックエンドにリクエストを配信するため、ベスト エフォート方式で動作します。デフォルトでは、セッション アフィニティは無効になっています(--session-affinity=NONE)。セッション アフィニティが有効でない場合、ロードバランサは以下の 5 タプルハッシュに基づいて新しいリクエストを分散します。

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

パススルー ロードバランサの場合、バックエンド インスタンスまたはエンドポイントが正常であれば、後続のリクエストは同じバックエンド VM またはエンドポイントに送信されます。

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

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

  • 認証やセキュリティを目的としてセッション アフィニティに依存しないでください。セッション アフィニティは、バックエンドが容量の上限に達したか、上限を超えた場合、あるいはバックエンドが異常な状態になった場合に失われるように設計されています。

  • Google Cloud ロードバランサは、ベストエフォート ベースでのセッション アフィニティを実現します。負荷分散モードで測定されるバックエンド ヘルスチェックに関する状態の変化やバックエンド使用率の変化などの要因により、セッション アフィニティが失われる可能性があります。None 以外のセッション アフィニティを UTILIZATION 負荷分散モードで使用することはおすすめしません。これは、インスタンス使用率の変化によって、負荷分散サービスが容量の上限に達していないバックエンド VM に新しいリクエストや新しい接続を転送する場合があるためです。これにより、セッション アフィニティが中断されます。代わりに、RATE または CONNECTION 負荷分散モードを使用して、セッション アフィニティの中断を回避します。

  • ネットワーク負荷分散とセッション アフィニティの詳細については、外部 TCP/UDP ネットワーク負荷分散の概要をご覧ください。

  • 内部 TCP/UDP 負荷分散とセッション アフィニティの詳細については、内部 TCP/UDP 負荷分散の概要をご覧ください。

  • プロキシレス gRPC サービスが構成されている場合、Traffic Director はセッション アフィニティをサポートしていません。

次の表は、セッション アフィニティのオプションを示しています。

プロダクト セッション アフィニティのオプション
内部 TCP/UDP 負荷分散 • なし
• クライアント IP
• クライアント IP、プロトコル
• クライアント IP、プロトコル、ポート
TCP プロキシ負荷分散
SSL プロキシ負荷分散
• なし
• クライアント IP
外部 HTTP(S) 負荷分散 • なし
• クライアント IP
• 生成された Cookie
内部 HTTP(S) 負荷分散 • なし
• クライアント IP
• 生成された Cookie
• ヘッダー フィールド
• HTTP Cookie
ネットワーク負荷分散 • なし
• クライアント IP
• クライアント IP、プロトコル
• クライアント IP、プロトコル、ポート
Traffic Director • なし
• クライアント IP
• 生成された Cookie(HTTP プロトコルのみ)
• ヘッダー フィールド(HTTP プロトコルのみ)
• HTTP Cookie(HTTP プロトコルのみ)

次のセクションでは、さまざまなタイプのセッション アフィニティについて説明します。

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

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

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

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

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

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

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

  • 外部 HTTP(S) ロードバランサの場合、Cookie の名前は GCLB になります。
  • 内部 HTTP(S) ロードバランサおよび 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 時間)までの値に設定することもできます。

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

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

  • 負荷分散の局所性ポリシーは RING_HASH または MAGLEV である。
  • バックエンド サービスのコンシステント ハッシュで、HTTP ヘッダーの名前を指定している。

ヘッダー フィールド アフィニティは、--custom-request-header フラグで指定された HTTP ヘッダーの値に基づいて、ゾーン NEG のバックエンド VM またはエンドポイントにリクエストをルーティングします。

ヘッダー フィールド アフィニティが使用される内部 HTTP(S) 負荷分散の詳細については、内部 HTTP(S) 負荷分散の概要をご覧ください。

次の条件が両方とも満たされている場合、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 アフィニティが使用される内部 HTTP(S) 負荷分散の詳細については、内部 HTTP(S) 負荷分散の概要をご覧ください。

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

選択したアフィニティのタイプに関係なく、クライアントは次の状況でバックエンドとのアフィニティを失う可能性があります。

  • バックエンド インスタンス グループまたはゾーン 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) トラフィックのリクエスト / レスポンス タイムアウトになります。これは、バックエンドがリクエストに対して完全なレスポンスを返すのをロードバランサが待機する時間です。たとえば、バックエンド サービスのタイムアウトの値がデフォルト値の 30 秒である場合、バックエンドにはリクエストへの完全なレスポンスを配信するための時間が 30 秒あります。ロードバランサは、バックエンドが接続を閉じるか、レスポンス ヘッダーをロードバランサに送信する前にタイムアウトになると、HTTP GET リクエストを 1 回再試行します。バックエンドがレスポンス ヘッダーを送信する場合(レスポンス本文が不完全な場合でも)、またはバックエンドに送信されたリクエストが HTTP GET リクエストではない場合、ロードバランサは再試行しません。バックエンドがまったく応答しない場合、ロードバランサは HTTP 5xx レスポンスをクライアントに返します。バックエンドがリクエストに応答するまでの時間を変更するには、タイムアウト値を変更します。

  • HTTP トラフィックの場合、クライアントがリクエストの送信を完了できる最大時間は、バックエンド サービスのタイムアウトと同じです。HTTP 408 レスポンスが jsonPayload.statusDetail client_timed_out で表示されている場合は、クライアントからのリクエストがプロキシされている間、またはバックエンドからのレスポンスがプロキシされた間に、進捗がなかったことを意味します。問題の原因がクライアントのパフォーマンスの問題である場合は、バックエンド サービスのタイムアウトを増やすことでこの問題を解決できます。

  • 外部 HTTP(S) ロードバランサと内部 HTTP(S) ロードバランサの場合は、HTTP 接続が WebSocket にアップグレードされると、バックエンド サービスのタイムアウトにより、アイドル状態であるかどうかに関係なく WebSocket を開くことができる最大時間が定義されます。

  • SSL プロキシ ロードバランサと TCP プロキシ ロードバランサの場合、タイムアウトはアイドル タイムアウトです。接続が削除されるまでの時間を変更するには、タイムアウト値を変更します。このアイドル タイムアウトは WebSocket 接続にも使用されます。

  • 内部 TCP / UDP ロードバランサとネットワーク ロードバランサの場合、gcloud または API を使用してバックエンド サービス タイムアウトの値を設定できますが、この値は無視されます。バックエンド サービスのタイムアウトは、これらのパススルー ロードバランサにとって意味がありません。

  • プロキシレス gRPC サービスが構成されている場合、Traffic Director はバックエンド サービスのタイムアウトをサポートしていません。

ヘルスチェック

バックエンドがインスタンス グループまたはゾーン NEG である各バックエンド サービスには、ヘルスチェックを関連付ける必要があります。サーバーレス NEG またはインターネット NEG をバックエンドとして使用するバックエンド サービスは、ヘルスチェックを参照しないでください

Google Cloud Console を使用してロードバランサを作成する場合は、必要に応じて、ロードバランサの作成時にヘルスチェックを作成するか、既存のヘルスチェックを参照できます。

gcloud コマンドライン ツールまたは API を使用してインスタンス グループまたはゾーン NEG バックエンドを使用してバックエンド サービスを作成する場合は、既存のヘルスチェックを参照する必要があります。必要なヘルスチェックの種類と範囲については、ヘルスチェックの概要ロードバランサ ガイドを参照してください。

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

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

外部 HTTP(S) ロードバランサが使用するバックエンド サービスには、以下のオプションの Google Cloud 機能を使用できます。これについては、次のページで説明します。

  • Google Cloud Armor は、セキュリティ ポリシーで DDoS などの攻撃から保護します。
  • Cloud CDN は、低レイテンシのコンテンツ配信システムです。
  • カスタム ヘッダーの作成は、追加のヘッダーで、ロードバランサによりリクエストに追加されます。
  • IAP を使用すると、次のことが可能になります。
    • OAuth 2.0 ログインでの Google アカウントの認証を必須にする
    • Identity and Access Management 権限を使用してアクセスを制御する

備考

次の機能は、内部 HTTP(S) ロードバランサと Traffic Director でのみサポートされています。ただし、Traffic Director でプロキシレス gRPC サービスを使用する場合はサポートされていません。

  • サーキット ブレーク
  • 外れ値検出
  • 負荷分散ポリシー

次のステップ

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