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

バックエンド サービスは、次の Google Cloud 負荷分散サービスの構成値を含むフィールドを持つリソースです。

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

Traffic Director もバックエンド サービス リソースを使用します。ネットワーク負荷分散はバックエンド サービスを使用しません。

ロードバランサは、バックエンド サービス リソースの構成情報を以下の目的で使用します。

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

バックエンド サービスを作成する際に、いくつかの値を設定します。バックエンド サービスにバックエンドを追加する際に、その他の値を設定します。

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

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

ロードバランサあたりのバックエンド サービスの最大数、バックエンド サービスのスコープ、各バックエンド サービスが使用できるバックエンドの種類、バックエンド サービスの負荷分散スキームは、ロードバランサの種類によって異なります。

ロードバランサの種類 バックエンド サービスの最大数 バックエンド サービスのスコープ サポートされているバックエンドの種類 負荷分散スキーム
外部 HTTP(S) 負荷分散 複数 グローバル 1 各バックエンド サービスは、次のバックエンドの組み合わせをサポートしています:
  • すべてのインスタンス グループ バックエンド: 1 つ以上のマネージド、非マネージド、またはマネージドと非マネージドの各インスタンス グループ バックエンドの組み合わせ、または
  • すべてのゾーン NEG: 1 つ以上のゾーン NEG、または
  • 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 ロードバランサによるトラフィックの分散先リソースです。各バックエンド サービスは、1 つ以上の互換性のあるバックエンドに関連付けられています。バックエンドには 3 つのタイプがあります。

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

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

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

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

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

  • HTTP
  • HTTPS
  • HTTP/2
  • SSL
  • TCP
  • UDP

有効なプロトコルは、ロードバランサの種類によって異なります。詳細については、ロードバランサの機能をご覧ください。

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

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

HTTP(S) 負荷分散、TCP プロキシ負荷分散、SSL プロキシ負荷分散の場合、Google は本番ネットワーク内の Google フロントエンド(GFE)とバックエンド間のトラフィックを自動的に暗号化します。

この自動暗号化に加えて、SSL、HTTPS、HTTP/2(TLS を使用)などの安全なプロトコルをバックエンド サービス プロトコルとして使用することを選択できます。このプロトコル レベルの暗号化は、GFE からバックエンドへの Google の自動暗号化に追加されます。

SSL、HTTPS、または HTTP/2 をバックエンド サービス プロトコルとして使用する場合は、秘密鍵と証明書をインストールし、SSL または HTTPS サーバーとして動作するようにバックエンドで実行されるソフトウェアを構成する必要があります。GFE がバックエンドに接続する際に使用する安全なバックエンド サービス プロトコルは、SSL または HTTPS クライアントです。GFE は、自己署名または認証局によって署名されている場合のいずれであっても、バックエンドが提示する任意の証明書を受け入れます。ただし、安全なバックエンド サービス プロトコルを使用してバックエンドに接続する場合、GFE は証明書の検証を実行しません。

Google の暗号化の詳細については、Google Cloud での転送データの暗号化をご覧ください。

インスタンス グループ

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

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

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

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

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

名前付きポート

これらのタイプのロードバランサのいずれかに接続されているバックエンド インスタンス グループには、ロードバランサのバックエンド サービスがサブスクライブする名前付きポートと一致する名前付きポートが必要です。

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

各インスタンス グループは、複数の名前付きポートを持つことができます。名前付きポートは、サービス名からポート番号へのマッピングを作成します。インスタンス グループの名前付きポートが、バックエンド サービスがサブスクライブする名前付きポートと一致する場合は、インスタンス グループの名前付きポート マッピングを使用して、バックエンド サービスがグループのメンバー VM との通信に使用するポート番号を定義します。

たとえば、インスタンス グループに名前付きポートを次のように設定できます。ここで、サービス名は my-service-name、ポートは 8888 です。

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

次に、バックエンド サービスの名前付きポートを my-service-name に設定します。

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

次のことに注意してください。

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

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

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

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

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

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

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

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

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

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

  • 同じインスタンス グループを複数のバックエンド サービスのバックエンドとして使用できます。この状況では、これらのバックエンド サービスはすべて同じ負荷分散モードを使用する必要があります。

    これは複雑な設定であり、常に可能であるとは限りません。たとえば、同じインスタンス グループを、同時に内部 TCP/UDP ロードバランサと外部 HTTP(S) ロードバランサのバックエンド サービスのバックエンドにすることはできません。内部 TCP/UDP ロードバランサは、バックエンドが CONNECTION 負荷分散モードを使用する必要があるバックエンド サービスを使用し、HTTP(S) ロードバランサは、バックエンドが RATE または UTILIZATION モードのいずれかをサポートできるバックエンド サービスを使用します。両方に共通する負荷分散モードは存在しないため、両方の種類のロードバランサのバックエンドとして同じインスタンス グループを使用することはできません。

    • インスタンス グループが複数のバックエンド サービスに関連付けられている場合、各バックエンド サービスは、インスタンス グループの同じ名前付きポートまたは異なる名前付きポートを参照できます。
  • 自動スケーリングされたマネージド インスタンス グループを複数のバックエンド サービスに追加しないことをおすすめします。これを行うと、特に HTTP 負荷分散使用率の自動スケーリング指標を使用する場合に、グループ内のインスタンスが予測不能かつ不必要にスケーリングされる可能性があります。

    • 推奨されていませんが、このシナリオは、マネージド インスタンス グループの自動スケーリング指標が CPU 使用率またはロードバランサの処理能力に関係のない Cloud Monitoring 指標の場合に機能する可能性があります。これらの自動スケーリング指標のいずれかを使用すると、HTTP 負荷分散使用率の自動スケーリング指標で発生する不安定なスケーリングを回避することができます。

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

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

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

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

ネットワーク エンドポイントは、特定の VM を参照するのではなく、IP アドレスとポートでサービスを表します。ネットワーク エンドポイント グループ(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 の外部の宛先にトラフィックを分散します。

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

トラフィック分散

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

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

分散モード

負荷分散モードは、ロードバランサのバックエンドが完全にロードされているかどうかを判別します。Google Cloud には次の 3 つの負荷分散モードがあります。

  • CONNECTION
  • RATE
  • UTILIZATION

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

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

分散モード サポートされている負荷分散スキーム サポートされているバックエンド サービス プロトコル サポートされているバックエンドの種類 対象プロダクト
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 インスタンス グループまたはゾーン NEG
  • 外部 HTTP(S) 負荷分散
  • 内部 HTTP(S) 負荷分散
  • Traffic Director
UTILIZATION EXTERNAL
INTERNAL_MANAGED
INTERNAL_SELF_MANAGED
任意のプロトコル インスタンス グループのみ。ゾーン NEG は使用モードをサポートしていません。
  • 外部 HTTP(S) 負荷分散
  • 内部 HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • Traffic Director

バックエンド サービスに関連付けられているすべての 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 の負荷分散モードを使用できます。

同じインスタンス グループが複数のバックエンド サービスのバックエンドである場合は、各バックエンド サービスに同じ負荷分散モードを使用する必要があります。複数のバックエンド サービスのバックエンドとして機能するインスタンス グループの負荷分散モードを変更するには:

  • 1 つを除くすべてのバックエンド サービスからインスタンス グループを削除します。
  • 残り 1 つのバックエンド サービスのバックエンドの負荷分散モードを変更します。
  • 残りのバックエンド サービスが新しい負荷分散モードをサポートしている場合は、インスタンス グループをバックエンドとして再度バックエンド サービスに追加します。

さらに、いくつかの異なるバックエンド サービスの組み合わせのバックエンドとして同じインスタンス グループを使用することはできません。たとえば、同じインスタンス グループを、CONNECTION 負荷分散モードのみをサポートする内部 TCP/UDP ロードバランサと、RATE または UTILIZATION のいずれかの負荷分散モードをサポートする外部 HTTP(S) ロードバランサのバックエンドとして同時に使用することはできません。

ターゲット容量

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

  • CONNECTION 負荷分散モードの場合、ターゲット容量は、同時接続のターゲット最大数を定義します。内部 TCP/UDP ロードバランサを除いて、3 つの方法のいずれかを使用して、ターゲットの最大接続数を指定する必要があります。最大接続数は、max-connections-per-instance を使用して各 VM に対して、または max-connections-per-endpoint を使用してゾーン NEG の各エンドポイントに対して指定できます。ゾーン NEG とゾーン非マネージド インスタンス グループの場合は、グループ全体に max-connections を指定できます。

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

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

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

    • 最大接続数 / 正常な VM の数
    • 最大接続数 / 正常なエンドポイントの数
  • RATE 負荷分散モードの場合、ターゲット容量は HTTP リクエストのターゲット最大レートを定義します。次の 3 つの方法のいずれかを使用して、ターゲット レートを指定する必要があります。max-rate-per-instance を使用して VM ごとに、または max-rate-per-endpoint を使用してゾーン NEG のエンドポイントごとに、ターゲットの最大レートを指定できます。ゾーン NEG とゾーン非マネージド インスタンス グループの場合は、グループ全体に max-rate を指定できます。

    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(100%)です。つまり、たとえば、バックエンド インスタンスの現在の使用率が 80% で、最大使用率が 80% に設定されている場合、バックエンド サービスはこのインスタンスへのリクエストの送信を停止します。

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

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

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

capacity-scaler: 0.5 * 0.8

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

容量スケーラーは 0 から 1 までの任意の値に設定できます。0 より大きく 1 より小さいスケール係数は、バックエンドのターゲット容量を縮小します。ゼロのスケール係数は、すべての新しい接続を阻止し、既存の接続をドレインします。

Traffic Director とトラフィック分配

Traffic Director もバックエンド サービス リソースを使用します。具体的には、Traffic Director は、負荷分散スキームが INTERNAL_SELF_MANAGED であるバックエンド サービスを使用します。内部の自己管理バックエンド サービスの場合、トラフィック分散は、負荷分散モードと負荷分散ポリシーの組み合わせに基づいています。バックエンド サービスは、バックエンドの分散モードに従ってバックエンド(インスタンス グループまたは NEG)にトラフィックを転送します。バックエンドが選択されると、Traffic Director が負荷分散ポリシーに従ってトラフィックを分散します。

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

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

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

Traffic Director の詳細については、Traffic Director の概念をご覧ください。

セッション アフィニティ

セッション アフィニティがない場合、ロードバランサは、クライアントの IP アドレスと送信元ポート、ロードバランサの転送ルールの IP アドレスと宛先ポート、および L3 プロトコル(バックエンド サービスを使用するすべてのロードバランサの TCP プロトコル)で構成される 5 タプルハッシュに基づいて新しいリクエストを分散します。バックエンド インスタンス グループまたはゾーン NEG の負荷分散モードは、バックエンドが容量の上限に達するタイミングを決定します。広告配信、ゲーム、または内部キャッシュが頻繁に行われるサービスが使用するステートフル サーバーなどの一部のアプリケーションでは、特定ユーザーからの複数のリクエストを同じバックエンドまたはエンドポイントに送信する必要があります。

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

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

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

  • 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 ベースのアフィニティであれば、新しい接続を新しいクライアントとしてではなく、同じクライアントとして認識できます。

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

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

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

内部 HTTP(S) ロードバランサは、負荷分散ローカリティ ポリシーが RING_HASH または MAGLEV であり、バックエンド サービスの一貫したハッシュが HTTP ヘッダーの名前を指定している場合、ヘッダー フィールド アフィニティを使用できます。ヘッダー フィールド アフィニティは、--custom-request-header フラグで指定された HTTP ヘッダーの値に基づいて、ゾーン NEG のバックエンド VM またはエンドポイントにリクエストをルーティングします。

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

負荷分散のローカリティ ポリシーが RING_HASH または MAGLEV であり、バックエンド サービスの一貫したハッシュが HTTP Cookie の名前を指定している場合、内部 TCP/UDP ロードバランサは 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 フロントエンド(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(S) ロードバランサの場合は、HTTP 接続が WebSocket にアップグレードされると、バックエンド サービスのタイムアウトにより、アイドル状態であるかどうかに関係なく、WebSocket を開くことができる最大時間が定義されます。

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

  • 内部 TCP/UDP ロードバランサは、バックエンド サービスのタイムアウトの値を無視します。

ヘルスチェック

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

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

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

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

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

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

  • Google Cloud Armor は、セキュリティ ポリシーで DDoS などの攻撃から保護します。
  • Cloud CDN は、低レイテンシのコンテンツ配信システムです。
  • ユーザー定義リクエスト ヘッダーは、ロードバランサがリクエストに追加する追加のヘッダーです。
  • IAP では、OAuth 2.0 ログイン ワークフローを使用して Google アカウントでの認証を要求し、IAM 権限を使用してアクセスを制御できます。

備考

次の機能は、内部 HTTP(S) ロードバランサと Traffic Director でのみサポートされています。

  • 回路遮断
  • 外れ値検出
  • 負荷分散ポリシー
  • HTTP Cookie ベースのセッション アフィニティ
  • HTTP ヘッダーベースのセッション アフィニティ

次のステップ

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