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

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

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

  • 外部 HTTP(S) 負荷分散
  • 内部 HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • 内部 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 つ以上のゾーン NEG。
  • すべてのサーバーレス NEG: 1 つ以上の App Engine、Cloud Run、Cloud Functions サービス。
  • 1 つのインターネット NEG。
EXTERNAL
内部 HTTP(S) 負荷分散 複数 リージョン 各バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上のゾーン NEG。
INTERNAL_MANAGED
SSL プロキシ負荷分散 1 グローバル1 バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上のゾーン NEG。
  • 1 つのインターネット NEG。
EXTERNAL
TCP プロキシ負荷分散 1 グローバル1 バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上のゾーン NEG。
  • 1 つのインターネット NEG。
EXTERNAL
内部 TCP / UDP 負荷分散 1 リージョン タイプですが、グローバルにアクセスできるように構成可能です。 バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
INTERNAL
Traffic Director 複数 グローバル 各バックエンド サービスは、次のバックエンドの組み合わせをサポートしています。
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージドまたは非マネージド インスタンス グループ バックエンド。あるいは、マネージドと非マネージドの組み合わせ。
  • すべてのゾーン NEG: 1 つ以上のゾーン 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 の機能をご覧ください。

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

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

HTTP(S) 負荷分散、TCP プロキシ負荷分散、SSL プロキシ負荷分散では、Google Front End(GFE)と Google Cloud 内に存在するバックエンドの間でトラフィックが自動的に暗号化されます。

このネットワーク レベルの暗号化に加えて、セキュアなプロトコルをバックエンド サービス プロトコルとして使用できます。セキュアなプロトコルには、SSL、HTTPS、または HTTP/2(TLS を使用)などがあります。GFE ベースのロードバランサ、内部 HTTP(S) 負荷分散および Traffic Director に使用できます。

ロードバランサが、セキュアなバックエンド サービス プロトコルを使用してバックエンドに接続する場合、GFE は SSL または HTTPS クライアントになります。同様に、Traffic Director で構成されたクライアント側のプロキシが、セキュアなバックエンド サービス プロトコルを使用してバックエンドに接続する場合、このプロキシは SSL または HTTPS クライアントになります。

次の場合は、バックエンド インスタンスとの接続にセキュアなプロトコルを使用することをおすすめします。

  • ロードバランサ(または Traffic Director)からバックエンド インスタンスへの接続で、監査可能な暗号化された接続が必要な場合。

  • ロードバランサが、Google Cloud の外部にあるバックエンド インスタンスに接続する場合(インターネット NEG 経由で)。インターネット NEG バックエンドへの通信は、公共のインターネットを通過する可能性があります。ロードバランサがインターネット NEG に接続する場合、公開 CA 署名証明書は検証要件を満たしている必要があります。

ロードバランサとバックエンドの間でセキュアなプロトコルを使用する場合は、次のことに注意してください。

  • ロードバランサのバックエンド サービスは、SSL(TLS)、HTTPS、または HTTP/2 プロトコルを使用する必要があります。

  • バックエンド インスタンス ソフトウェアは、バックエンド サービスと同じプロトコルを使用してトラフィックを処理する必要があります。たとえば、バックエンド サービスが HTTPS を使用する場合は、HTTPS を使用するようにバックエンド インスタンスを構成します。HTTP/2 プロトコルを使用する場合は、バックエンドで TLS を使用する必要があります。構成手順については、バックエンド インスタンスで実行されているソフトウェアのドキュメントをご覧ください。

  • バックエンド インスタンスに秘密鍵と証明書をインストールする必要があります。これらの証明書は、ロードバランサの SSL 証明書と一致する必要はありません。インストール手順については、バックエンド インスタンスで実行されているソフトウェアのドキュメントをご覧ください。

  • バックエンド インスタンスで実行するソフトウェアは、SSL サーバーまたは HTTPS サーバーとして機能する必要があります。構成手順については、バックエンド インスタンスで実行されているソフトウェアのドキュメントをご覧ください。

インスタンス グループまたはゾーン NEG バックエンドを使用する場合は、次の点に注意してください。

  • GFE は、バックエンドへの TLS セッションを開始する際に、Server Name Indication(SNI)拡張機能を使用しません。

  • GFE が Google Cloud 内のバックエンドに接続すると、GFE はバックエンドに存在するすべての証明書を受け入れます。GFE は証明書の検証を行いません。たとえば、次のような状況では証明書は有効として扱われます。

    • 証明書が自己署名されている。
    • 証明書が不明な認証局(CA)によって署名されている。
    • 証明書の有効期限が切れているか、まだ有効になっていない。
    • CN 属性と subjectAlternativeName 属性が Host ヘッダーまたは DNS PTR レコードと一致しない。
Google の暗号化の詳細については、Google Cloud での転送データの暗号化をご覧ください。

インスタンス グループ

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

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

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

  • 外部 HTTP(S) ロードバランサ、SSL プロキシ ロードバランサ、TCP プロキシ ロードバランサの場合: クライアントは、ロードバランサの外部 IP アドレスを使用して Google フロントエンド(GFE)と通信します。GFE は、プライマリ ネットワーク インターフェースの内部 IP アドレスを使用して、バックエンド VM またはエンドポイントと通信します。GFE はプロキシであるため、バックエンド VM 自身は外部 IP アドレスを必要としません。

  • 内部 HTTP(S) ロードバランサ、内部 TCP/UDP ロードバランサ、Traffic Director の場合: 内部ロードバランサと Traffic Director のバックエンド VM は外部 IP アドレスを必要としません。

名前付きポート

ロードバランサは、ロードバランサの転送ルールで指定された 1 つ以上のポート番号でフロントエンドをリッスンできます。バックエンドでは、ロードバランサはトラフィックを同じまたは異なるポート番号に転送できます。バックエンド インスタンス(Compute Engine インスタンス)がこのポート番号でリッスンしています。インスタンス グループでこのポート番号を構成し、バックエンド サービスの構成でその番号を参照します。

バックエンド ポート番号は、名前と値のペアであるため、名前付きポートと呼ばれます。インスタンス グループで、ポートのキー名と値を定義します。その後、バックエンド サービス構成で名前付きポートを参照します。

インスタンス グループの名前付きポートがバックエンド サービス構成の --port-name と一致する場合、バックエンド サービスはインスタンス グループの VM との通信にこのポート番号を使用します。

次の種類のロードバランサでは、各バックエンド Compute Engine インスタンス グループに名前付きポートを設定する必要があります。

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

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

たとえば、インスタンス グループに名前付きポートを次のように設定できます。ここで、サービス名は 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

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

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

  • 各インスタンス グループが同じポート名に異なるポート番号を指定している場合は、バックエンド サービスが異なるインスタンス グループの VM と通信するときに、別のポート番号を使用できます。

  • バックエンド サービスが使用する解決済みのポート番号は、ロードバランサの転送ルールで使用されるポート番号と一致する必要はありません。

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

  • ゾーン 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 指標の場合、このシナリオが機能する可能性がありますが、これはおすすめしません。これらの自動スケーリング指標のいずれかを使用すると、不安定なスケーリングを防止できます。

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

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

ゾーン ネットワーク エンドポイントは、IP アドレスとポートの組み合わせであり、次の 2 つの方法のいずれかで指定されます。

  • IP address:port ペア(例: 10.0.1.1:80)を指定します。
  • ネットワーク エンドポイントの IP アドレスのみを指定します。NEG のデフォルト ポートは、IP address:port ペアのポートとして自動的に使用されます。

ネットワーク エンドポイントは、特定の VM を参照するのではなく、IP アドレスとポートでサービスを表します。ネットワーク エンドポイント グループは、ネットワーク エンドポイントの論理的なグループです。

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

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

インターネット 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 は、Cloud RunApp Engine、または Cloud Functions サービスを指すバックエンドです。

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

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

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

トラフィック分散

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

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

分散モード

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

  • CONNECTION
  • RATE
  • UTILIZATION

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

バックエンド サービスにバックエンドを追加する際に、負荷分散モードを設定します。サーバーレス NEG には分散モードを設定できません。

分散モード サポートされている負荷分散スキーム サポートされているバックエンド サービス プロトコル サポートされているバックエンドの種類 対象製品
CONNECTION EXTERNAL
INTERNAL
SSL、TCP、UDP
プロトコル オプションは、ロードバランサのタイプによって制限されます。たとえば、内部 TCP/UDP 負荷分散では、TCP または UDP プロトコルのみが使用されます。
インスタンス グループまたはゾーン NEG(サポートされている場合)。
たとえば、内部 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、gRPC プロトコルのみ)
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
任意のプロトコル インスタンス グループのみ。ゾーン NEG は使用率モードをサポートしていません。
  • 外部 HTTP(S) 負荷分散
  • 内部 HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • Traffic Director(INTERNAL_SELF_MANAGED、HTTP、gRPC プロトコルのみ)

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

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

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

一部のロードバランサは、バックエンド サービスに使用可能な負荷分散モードが 1 つしかなく、負荷分散モードを変更できません。

  • 内部 TCP/UDP ロードバランサのバックエンド サービスは、CONNECTION 負荷分散モードのみを使用できます。
  • すべてのバックエンドが NEG である外部 HTTP(S) ロードバランサのバックエンド サービスは、RATE 負荷分散モードのみを使用できます。
  • すべてのバックエンドが NEG である内部 HTTP(S) ロードバランサのバックエンド サービスは、RATE 負荷分散モードのみを使用できます。
  • すべてのバックエンドが NEG である SSL プロキシ ロードバランサのバックエンド サービスは、CONNECTION 負荷分散モードのみを使用できます
  • すべてのバックエンドが NEG である TCP プロキシ ロードバランサのバックエンド サービスは、CONNECTION 負荷分散モードのみを使用できます

一部のロードバランサは、バックエンド サービスで複数のモードを使用できるため、負荷分散モードを変更できます。

  • すべてのバックエンドがインスタンス グループである外部 HTTP(S) ロードバランサのバックエンド サービスは、RATE または UTILIZATION の負荷分散モードを使用できます。
  • すべてのバックエンドがインスタンス グループである内部 HTTP(S) ロードバランサのバックエンド サービスは、RATE または UTILIZATION の負荷分散モードを使用できます。
  • すべてのバックエンドがインスタンス グループである SSL プロキシ ロードバランサのバックエンド サービスは、CONNECTION または UTILIZATION の負荷分散モードを使用できます。
  • すべてのバックエンドがインスタンス グループである TCP プロキシ ロードバランサのバックエンド サービスは、CONNECTION または UTILIZATION の負荷分散モードを使用できます。

ターゲット容量

各負荷分散モードには対応するターゲット容量があり、ターゲットの最大接続数、ターゲットの最大レート、またはターゲットの最大 CPU 使用率を定義します。どの負荷分散モードでも、ターゲット容量はサーキット ブレーカーではありません。特定の条件下でロードバランサは最大値を超えます(たとえば、すべてのバックエンド VM またはエンドポイントが最大値に到達した場合)。

  • CONNECTION 負荷分散モードの場合、ターゲット容量は、同時接続のターゲット最大数を定義します。次のいずれかの設定を使用できます。

    • max-connections-per-instance(VM あたり)
    • max-connections-per-endpoint(ゾーン NEG のエンドポイントあたり)
    • max-connections(ゾーン NEG あたり、グループ全体のゾーン非マネージド インスタンス グループごと)

    max-connections-per-instance または max-connections-per-endpoint を指定すると、Google Cloud は VM またはエンドポイントあたりの効果的なターゲットを次のように計算します。

    • (VM あたりの最大接続数 * VM の総数)/ 正常な VM の数
    • (エンドポイントあたりの最大接続数 * エンドポイントの総数)/ 正常なエンドポイントの数

    max-connections を指定すると、Google Cloud は VM またはエンドポイントごとの効果的なターゲットを次のように計算します。

    • 最大接続数 / 正常な VM の数
    • 最大接続数 / 正常なエンドポイントの数
  • RATE 負荷分散モードの場合、ターゲット容量は HTTP リクエストのターゲット最大レートを定義します。次のいずれかの設定を使用できます。

    • max-rate-per-instance(VM ごと)
    • max-rate-per-endpoint(ゾーン NEG 内の各エンドポイントごと)
    • max-rate(ゾーン NEG とグループ全体のゾーン非マネージド インスタンス グループごと)

    max-rate-per-instance または max-rate-per-endpoint を指定すると、Google Cloud は VM またはエンドポイントあたりの効果的なターゲット レートを次のように計算します。

    • VM あたりの最大レート * VM の合計数 / 正常な VM の数
    • エンドポイントあたりの最大レート * エンドポイントの合計数 / 正常なエンドポイントの数

    max-rate を指定すると、Google Cloud は VM またはエンドポイントごとの効果的なターゲット レートを次のように計算します。

    • 最大レート / 正常な VM の数
    • 最大レート / 正常なエンドポイントの数
  • UTILIZATION 負荷分散モードの場合、必須のターゲット容量は存在しません。次の表にまとめられているように、バックエンドの種類に応じていくつかのオプションが用意されています。

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

ロードバランサ バックエンドの種類 分散モード ターゲット容量
内部 TCP / UDP 負荷分散 インスタンス グループ CONNECTION 最大接続数は指定できません。
SSL プロキシ負荷分散、TCP プロキシ負荷分散 インスタンス グループ CONNECTION 次のいずれかを指定する必要があります
1. ゾーン インスタンス グループあたりの最大接続数
2. インスタンスあたりの最大接続数
(ゾーンまたはリージョン インスタンス グループ)
UTILIZATION オプションで、次のいずれかを指定できます。
1. 最大使用率
2. ゾーン インスタンス グループあたりの最大接続数
3. インスタンスあたりの最大接続数
(ゾーンまたはリージョンのインスタンス グループ)
4. 1 と 2 を同時に指定
5. 1 と 3 を同時に指定
ゾーン NEG CONNECTION 次のいずれかを指定する必要があります
1. ゾーン NEG あたりの最大接続数
2. エンドポイントあたりの最大接続数
HTTP(S) 負荷分散、内部 HTTP(S) 負荷分散、Traffic Director インスタンス グループ RATE 次のいずれかを指定する必要があります
1. ゾーン インスタンス グループあたりの最大レート
2. インスタンスあたりの最大レート
(ゾーンまたはリージョンのインスタンス グループ)
UTILIZATION オプションで、次のいずれかを指定できます。
1. 最大使用率
2. ゾーン インスタンス グループあたりの最大レート
3. インスタンスあたりの最大レート
(ゾーンまたはリージョンのインスタンス グループ)
4. 1 と 2 を同時に指定
5. 1 と 3 を同時に指定
ゾーン NEG RATE 次のいずれかを指定する必要があります
1. ゾーン NEG あたりの最大レート
2. エンドポイントあたりの最大レート

容量スケーラー

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

デフォルトでは、容量スケーラーは 1.0(100%)に設定されています。たとえば、バックエンド インスタンスの現在の使用率が 80% で、最大使用率が 80% に設定されている場合、バックエンド サービスはこのインスタンスへのリクエストの送信を停止します。

capacity-scaler: 1 * 0.8

容量スケーラーは、0.0 または 0.1(10%)~1.0(100%)に設定できます。スケーリング ファクタがゼロ(0.0)の場合、新しい接続はすべて禁止されます。バックエンド サービスに接続されているバックエンドが 1 つだけの場合は、0.0 の設定を構成できません。

2 つのバックエンド サービスがインスタンス グループのバックエンドを共有する場合の容量スケーラーの使用

同じインスタンス グループのバックエンドを使用する 2 つのバックエンド サービスがある状況では、2 つのバックエンド サービス間でインスタンス グループの容量を割り当てる必要があります。

たとえば、両方のバックエンド サービスで容量スケーラーを 0.5 に設定すると、各バックエンド サービスはインスタンス グループの容量の 40% を受け取ります。

capacity-scaler: 0.5 * 0.8

各バックエンド サービスがインスタンス グループの容量の 40% を使用すると、リクエストはこのインスタンス グループに送信されなくなります。

Traffic Director とトラフィック分散

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

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

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

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

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

セッション アフィニティ

セッション アフィニティを使用しない場合、ロードバランサは次のように 5 タプルハッシュに基づいて新しいリクエストを分散します。

  • クライアント IP アドレス
  • クライアント ソースポート
  • ロードバランサの転送ルールの IP アドレス
  • ロードバランサの宛先ポート
  • レイヤ 3 プロトコル(バックエンド サービスを使用するすべてのロードバランサの TCP プロトコル)。

バックエンド インスタンス グループまたはゾーン NEG の負荷分散モードは、バックエンドが容量の上限に達するタイミングを決定します。一部のアプリケーションでは、特定のユーザーからの複数のリクエストを同じバックエンドまたはエンドポイントに転送する必要があります。これには、広告配信、ゲーム、または内部キャッシュが頻繁に行われるサービスで使用されるステートフル サーバーが含まれます。

セッション アフィニティは、SSL、HTTP(S)、HTTP/2 プロトコルなどの TCP トラフィックで使用できます。バックエンド インスタンスまたはエンドポイントが正常で、(分散モードに基づいて)容量の上限に達していない場合、後続のリクエストは同じバックエンド VM またはエンドポイントに送信されます。セッション アフィニティを構成する際は、次の点に留意してください。

  • UDP トラフィックにはセッションの概念がないため、このタイプのトラフィックではセッション アフィニティは意味を成しません。

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

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

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

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

製品 セッション アフィニティのオプション
内部 TCP/UDP • なし
• クライアント IP
• クライアント IP、プロトコル
• クライアント IP、プロトコル、ポート
TCP プロキシ
SSL プロキシ
• なし
• クライアント IP
外部 HTTP(S) • なし
• クライアント IP
• 生成された Cookie
内部 HTTP(S) • なし
• クライアント IP
• 生成された Cookie
• ヘッダー フィールド
• HTTP Cookie
ネットワーク ネットワーク負荷分散はバックエンド サービスを使用しません。代わりに、ネットワーク ロードバランサのセッション アフィニティをターゲット プールで設定します。ターゲット プールsessionAffinity パラメータをご覧ください。
Traffic Director • なし
• クライアント IP
• 生成された Cookie
• ヘッダー フィールド
• HTTP Cookie

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

クライアント 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 は 1 つのセッション Cookie のみになります。あるいは、Cookie の存続期間を 1 から 86400 秒(24 時間)までの値に設定できます。

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

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

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

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

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

内部 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 秒です。

  • 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 ロードバランサの場合、バックエンド サービスのタイムアウトは影響しません。

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

ヘルスチェック

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

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

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

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

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

次の Google Cloud のオプション機能は、HTTP(S) 負荷分散で使用されるバックエンド サービスで使用できます。これについては、次のページで説明します。

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

備考

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

  • サーキット ブレーク
  • 外れ値検出
  • 負荷分散ポリシー
  • HTTP Cookie ベースのセッション アフィニティ
  • HTTP ヘッダーベースのセッション アフィニティ

次のステップ

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