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

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

次の 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。
  • すべてのサーバーレス 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 ロードバランサがトラフィックを分散するリソースです。各バックエンド サービスは、互換性のある 1 つ以上のバックエンドに関連付けられています。バックエンドにはいくつかの種類があります。

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

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

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

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

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

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

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

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

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

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

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

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

ロードバランサが、セキュアなバックエンド サービス プロトコルを使用してバックエンドに接続する場合、ロードバランサは 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 サーバーとして動作するように、バックエンド インスタンスで実行されているソフトウェアを構成する必要があります。構成手順については、バックエンド インスタンスで実行されているソフトウェアのドキュメントをご覧ください。

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

  • ロードバランサがバックエンドとの TLS セッションを開始するとき、GFE は Server Name Indication(SNI)拡張機能を使用しません。

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

    • 証明書が自己署名されている。
    • 証明書が不明な認証局(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 ロードバランサの場合: 内部ロードバランサのバックエンド 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 は異なるメカニズムで(つまりエンドポイント自体で)ポートを定義するため。
  • サーバーレス 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 つのインスタンス グループに必要な名前付きポートを作成し、各バックエンド サービスが一意の名前付きポートをサブスクライブするように設定します。

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

    これは複雑な設定であり、常に可能とは限りません。たとえば、同じインスタンス グループを内部 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 は、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 は次のものを表すことができます。

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

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

トラフィック分散

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

  • ロードバランサが新しいリクエストまたは接続の候補となるバックエンドの決定に使用する負荷分散モード
  • ターゲット容量。ターゲットの最大接続数、ターゲットの最大レート、またはターゲットの最大 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 つの方法のいずれかを使用して、ターゲット レートを指定する必要があります。VM ごとにターゲットの最大レートを指定する場合は max-rate-per-instance を使用します。ゾーン NEG のエンドポイントごとにしている場合は max-rate-per-endpoint を使用します。ゾーン 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.0(100%)に設定されています。たとえば、バックエンド インスタンスの現在の使用率が 80% で、最大使用率が 80% に設定されている場合、バックエンド サービスはこのインスタンスへのリクエストの送信を停止します。

capacity-scaler: 1 * 0.8

容量スケーラーは、0.0 または 0.1(10%)~1.0(100%)に設定できます。0.0 より大きく、0.1 より小さい設定は構成できません。スケーリング ファクタがゼロ(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 であるバックエンド サービスを使用します。内部のセルフ マネージド バックエンド サービスの場合、トラフィック分散は、負荷分散モードと負荷分散ポリシーの組み合わせに基づいています。バックエンド サービスは、バックエンドの分散モードに従ってバックエンド(インスタンス グループまたは 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 時間)までの値に設定することもできます。

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

負荷分散ローカリティ ポリシーが RING_HASH または MAGLEV であり、バックエンド サービスの一貫したハッシュが HTTP ヘッダーの名前を指定している場合、内部 HTTP(S) ロードバランサでヘッダー フィールド アフィニティを使用できます。ヘッダー フィールド アフィニティは、--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 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(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 ヘッダーベースのセッション アフィニティ

次のステップ

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