バックエンド サービスについて

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

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

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

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

  • 正しいバックエンド(インスタンス グループまたはネットワーク エンドポイント グループ)にトラフィックを配信する
  • 分散モードに従ってトラフィックを配信する。分散モードは、各バックエンドのバックエンド サービスで定義します。
  • バックエンド サービスで指定されたヘルスチェックを使用して、バックエンドの状態をモニタリングする
  • セッション アフィニティを維持する

アーキテクチャ

ロードバランサあたりのバックエンド サービスの数は、ロードバランサの種類によって異なります。

ロードバランサの種類 バックエンド サービスの数
外部 HTTP(S) 負荷分散 複数
内部 HTTP(S) 負荷分散 複数
SSL プロキシ負荷分散 1
TCP プロキシ負荷分散 1
内部 TCP / UDP 負荷分散 1

各バックエンド サービスには 1 つ以上のバックエンドが含まれます。

1 つのバックエンド サービスのバックエンドは、すべてインスタンス グループまたはネットワーク エンドポイント グループのいずれかでなければなりません。マネージド インスタンス グループと非マネージド インスタンス グループなど、異なる種類のインスタンス グループを同じバックエンド サービスに関連付けることはできますが、インスタンス グループやネットワーク エンドポイント グループを同じバックエンド サービスに関連付けることはできません。

バックエンド サービスの設定

各バックエンド サービスには、次のような構成可能な設定があります。

  • セッション アフィニティ(オプション)。通常、ロードバランサは、ハッシュ アルゴリズムを使用して、使用可能なインスタンス間でリクエストを分散させます。通常の使用では、送信元 IP アドレス、宛先 IP アドレス、送信元ポート、宛先ポート、プロトコルに基づいてハッシュが生成されます(5 タプルハッシュ)。セッション アフィニティは、ハッシュの内容を調整し、同じクライアントからのリクエストをすべて同じ仮想マシン インスタンスに送信しようとします。
  • バックエンド サービスのタイムアウト。この値の解釈方法は、使用するロードバランサとプロトコルの種類によって異なります。
    • HTTP(S) ロードバランサの場合、アップグレードして Websocket プロトコルを使用する接続を除き、バックエンド サービスのタイムアウトはリクエスト / レスポンスのタイムアウトです。
    • WebSocket トラフィックを HTTP(S) ロードバランサに送信する場合、バックエンド サービスのタイムアウトは、WebSocket がアイドル状態またはアクティブ状態を維持できる最大時間として解釈されます。
    • SSL プロキシまたは TCP プロキシのロードバランサの場合、バックエンド サービスのタイムアウトは、すべてのトラフィックのアイドル タイムアウトとして解釈されます。
    • 内部 TCP / UDP ロードバランサの場合、バックエンド サービスのタイムアウト パラメータは無視されます。
  • ヘルスチェック。ヘルス チェッカーは、バックエンド サービスに接続されたインスタンスを所定の間隔でポーリングします。ヘルスチェックに合格したインスタンスは、新しいリクエストを受信できます。インスタンスが異常な場合、再度正常になるまでリクエストは送信されません。

バックエンド サービスを操作するときに使用可能なプロパティの説明については、バックエンド サービスの API リソースまたは gcloud コマンドライン ツールのユーザーガイドをご覧ください。

バックエンド

複数のバックエンドを単一のバックエンド サービスに追加できます。バックエンドは、Google Cloud ロードバランサがトラフィックを分散するためのリソースです。バックエンドとして使用できるリソースには、次の 3 種類があります。

1 つのバックエンド サービスのバックエンドは、すべてインスタンス グループ、または NEG かバックエンド バケット(サポートされている場合)のいずれかでなければなりません。同じバックエンド サービスで複数の種類のバックエンドを使用することはできません。また、次のような制限もあります。

  • 内部 TCP / UDP ロードバランサのバックエンドは、インスタンス グループのバックエンドのみをサポートします。
  • HTTP(S) ロードバランサに 2 つ以上のバックエンド サービスが存在する場合は、1 つのバックエンド サービスのバックエンドとしてインスタンス グループを使用し、別のバックエンド サービスのバックエンドとして NEG を使用することもできます

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

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

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

  • ネットワーク ロードバランサの場合: ネットワーク ロードバランサは、双方向のネットワーク アドレス変換(NAT)を使用してパケットをルーティングします。バックエンド VM がクライアントにレスポンスを送信するときに、ロードバランサの転送ルールの外部 IP アドレスが送信元 IP アドレスとして使用されます。

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

トラフィック分散

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

  • 分散モード。バックエンドを使い切った場合に、それを判別する方法を負荷分散システムに伝達します。あるリージョンのバックエンド サービスのバックエンドをすべて使い切ると、新しいリクエストは、まだリクエストを処理できる最も近いリージョンに自動的にルーティングされます。分散モードは、接続数、バックエンド使用率または 1 秒あたりのリクエスト数(RPS)に基づいて設定できます。
  • 容量設定。容量は、分散モード設定と相互に作用する追加制御機能です。たとえば、通常はインスタンスが最大 80% のバックエンド使用率で動作するようにする場合、分散モードをバックエンド使用率に設定し、容量を 80% に設定します。インスタンスの使用率を半分にする場合は、容量はバックエンド使用率の 80% のままにし、容量スケーラーを 0.5 に設定します。バックエンド サービスをドレインするには、容量スケーラーを 0 に設定し、容量はそのままにします。容量とバックエンド使用率の詳細については、CPU または負荷分散処理能力に基づくスケーリングをご覧ください。

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

  • 同じバックエンド サービスに接続されているバックエンド インスタンス グループのすべてのインスタンスの平均バックエンド使用率が 10% 未満の場合、GCP は特定のゾーンを優先します。これは、マネージド リージョン インスタンス グループ、マネージド ゾーン インスタンス グループまたは非マネージド ゾーン インスタンス グループを使用している場合に発生する可能性があります。ロードバランサに送信されるトラフィックが増えると、このゾーン不均衡は自動的に解消されます。他のリージョンのバックエンド サービスは、この影響を受けません。

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

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

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

分散モードに RATE を選択する場合は、バックエンド、インスタンス、エンドポイントごとに最大レートを指定する必要があります。

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

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

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

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

有効なプロトコルは、作成するロードバランサの種類(負荷分散スキームなど)によって異なります。バックエンド サービスで使用できるプロトコルの詳細については、各ロードバランサのドキュメントをご覧ください。

バックエンドへのプロトコルとしての HTTP/2 は Ingress による負荷分散にも使用できます

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

インスタンス グループ

バックエンド サービスと自動スケーリングされたマネージド インスタンス グループ

多数のマシンをすべて同じ方法で構成する必要があり、必要に応じてインスタンスを自動的に追加または削除する場合、自動スケーリングされたマネージド インスタンス グループを使用すると便利です。

自動スケーリングのパーセンテージは、バックエンド サービスの分散モードと協調して機能します。たとえば、分散モードで [バックエンドの使用率] を 80% に設定し、容量スケーラーは 100% のままにして、オートスケーラーの [ターゲットの負荷分散使用量] を 80% に設定すると、グループのバックエンド使用率が 64%(80% の 80%)を超えるたびに、使用率がおよそ 64% に減少するまでオートスケーラーによってテンプレートから新しいインスタンスがインスタンス化されます。全体的な使用量が 64% を下回ると、使用量が 64% に戻るまでオートスケーラーによってインスタンスが削除されます。

新しいインスタンスがグループの一部と見なされるまでに一定のクールダウン期間があるため、その期間に、トラフィックがバックエンド サービスの 80% バックエンド使用率を超過し、超過したトラフィックが次に使用可能なバックエンド サービスにルーティングされる可能性があります。インスタンスが使用可能になると、新しいトラフィックがそれらにルーティングされます。また、オートスケーラーの設定で許可されているインスタンスの最大数に到達すると、使用率に関係なく、オートスケーラーはインスタンスの追加を停止します。この場合、超過したトラフィックは次に使用可能なリージョンに負荷分散されます。

自動スケーリングされるマネージド インスタンス グループの構成

自動スケーリングされるマネージド インスタンス グループを構成するには、次の手順に従います。

  1. インスタンス グループのインスタンス テンプレートを作成します。
  2. マネージド インスタンス グループを作成し、それにテンプレートを割り当てます。
  3. 負荷分散処理能力に基づいて自動スケーリングをオンにします。

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

Cloud Load Balancing の負荷分散は非常に柔軟な構成が可能であるため、作成した構成によってはうまく機能しないことがあります。負荷分散で使用するインスタンス グループを作成するときは、次の制限とガイダンスに留意してください。

  • 複数のインスタンス グループに同じ仮想マシン インスタンスを設定しないでください。
  • バックエンドで使用されている場合は、インスタンス グループを削除しないでください。
  • 2 つの異なるバックエンドに同じインスタンス グループを追加しないようにすると、構成はよりシンプルになります。2 つのバックエンドに同じインスタンス グループを追加する場合、次のようになります。
    • 両方のバックエンドで UTILIZATION または RATE のいずれかの同じ分散モードを使用する必要があります。
    • maxRatePerInstancemaxRatePerGroup は一緒に使用できます。一方のバックエンドで maxRatePerInstance を使用し、もう一方のバックエンドで maxRatePerGroup を使用することもできます。
    • インスタンス グループが、複数のバックエンドに対してそれぞれ 2 つ以上のポートを提供している場合、インスタンス グループで異なるポート名を指定する必要があります。
  • マネージドおよび非マネージドのインスタンス グループ内にあるすべてのインスタンスは同じ VPC ネットワーク内にある必要があります。また、該当する場合は同じサブネットワーク内にある必要があります。
  • 自動スケーリングが設定されたマネージド インスタンス グループを使用する場合、バックエンド サービスで maxRate 分散モードを使用しないでください。maxUtilization または maxRatePerInstance モードのいずれかを使用できます。
  • 自動スケーリングされたマネージド インスタンス グループを、2 つの異なるロードバランサのターゲットにしないでください。
  • マネージド インスタンス グループのサイズを変更する場合、グループの最大サイズはサブネットのサイズ以下にする必要があります。

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

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

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

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

ネットワーク エンドポイント グループをバックエンドとして使用するバックエンド サービスは、VM インスタンス内で実行されているアプリケーションやコンテナ間でトラフィックを分散します。詳細については、負荷分散でのネットワーク エンドポイント グループのコンセプトをご覧ください。

セッション アフィニティ

セッション アフィニティを設定しない場合、ロードバランサはバックエンド インスタンス グループまたは NEG の分散モードに従って新しいリクエストを分散します。広告サービス、ゲーム、内部キャッシュが頻繁に行われるサービスなどが使用するステートフル サーバーなど、一部のアプリケーションでは、1 人のユーザーが同じインスタンスに対して複数のリクエストを行う必要があります。

セッション アフィニティを使用する場合は、クライアントの IP アドレスや Cookie の値などのパラメータに基づいて、同じクライアントからの TCP トラフィックが識別されます。バックエンドが正常で、容量が十分に残っている場合、これらのリクエストが分散モードに従って同じバックエンド インスタンスに送信されます。

UDP セッションはリクエストとレスポンスが 1 つだけなので、UDP トラフィックにセッション アフィニティを設定しても、あまり効果はありません。

インスタンスが異常または過負荷状態になると、セッション アフィニティが維持されなくなるため、アフィニティが完全であることを前提にしないでください。

HTTP(S) 負荷分散の場合、セッション アフィニティは RATE 分散モードで最も効果的に機能します。

次の表に、ロードバランサの種類と使用可能なセッション アフィニティ オプションを示します。

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

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

クライアント IP アフィニティの使用

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

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

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

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

Console


クライアント IP アフィニティを設定するには:

  1. Google Cloud Console で、[負荷分散] ページの [バックエンドの設定] に移動します。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンド サービス] の [編集] 鉛筆アイコンを選択します。
  5. [バックエンド サービスの編集] ダイアログ ボックスで、[セッション アフィニティ] プルダウン メニューから Client IP を選択します。
    これにより、クライアント IP セッション アフィニティが有効になります。[アフィニティ Cookie の TTL] フィールドはクライアント IP アフィニティでは意味がないため、グレー表示になります。
  6. [バックエンド サービス] の [更新] ボタンをクリックします。
  7. ロードバランサの [更新] ボタンをクリックします。

gcloud


create コマンドを使用して新しいバックエンド サービスのセッション アフィニティを設定するか、update コマンドを使用して既存のバックエンド サービスのセッション アフィニティを設定できます。この例は、update コマンドを使用する場合を示しています。

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity client_ip
    

API


バックエンド サービスの API リファレンスをご覧ください。

生成された 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 時間)までの値に設定することもできます。

Console


生成された Cookie アフィニティを設定するには:

  1. Google Cloud Console で、HTTP(S) 負荷分散ページの [バックエンドの設定] から生成された Cookie アフィニティを変更できます。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンド サービス] の [編集] 鉛筆アイコンを選択します。
  5. [セッション アフィニティ] プルダウン メニューから Generated cookie を選択して、生成された Cookie アフィニティを選択します。
  6. [アフィニティ Cookie の TTL] フィールドで、Cookie の存続時間を秒単位で設定します。
  7. [バックエンド サービス] の [更新] ボタンをクリックします。
  8. ロードバランサの [更新] ボタンをクリックします。

gcloud


--session-affinitygenerated_cookie に設定し、--affinity-cookie-ttl を秒単位の Cookie 存続期間に設定して、生成された Cookie アフィニティを有効にします。create コマンドを使用して新しいバックエンド サービスのセッション アフィニティを設定するか、update コマンドを使用して既存のバックエンド サービスのセッション アフィニティを設定できます。この例は、update コマンドを使用する場合を示しています。

gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
        --session-affinity generated_cookie \
        --affinity-cookie-ttl 86400
    

API


バックエンド サービスの API リファレンスをご覧ください。

セッション アフィニティの無効化

バックエンド サービスを更新し、セッション アフィニティを none に設定してセッション アフィニティを無効にでき、また、バックエンド サービスを編集してテキスト エディタでセッション アフィニティを none に設定できます。いずれかのコマンドを使用して Cookie の存続期間を変更することもできます。

Console


セッション アフィニティを無効にするには:

  1. Google Cloud Console で、[負荷分散] ページの [バックエンドの設定] からセッション アフィニティを無効にできます。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンド サービス] の [編集] 鉛筆アイコンを選択します。
  5. [セッション アフィニティ] プルダウン メニューから None を選択し、セッション アフィニティを無効にします。
  6. [バックエンド サービス] の [更新] ボタンをクリックします。
  7. ロードバランサの [更新] ボタンをクリックします。

gcloud


セッション アフィニティを無効にするには、次のコマンドを実行します。

      gcloud compute backend-services update [BACKEND_SERVICE_NAME] \
      --session-affinity none
    


または

gcloud compute backend-services edit [BACKEND_SERVICE_NAME]

API


バックエンド サービスの API リファレンスをご覧ください。

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

選択したアフィニティのタイプに関係なく、以下の場合、クライアントはインスタンスとのアフィニティを失う可能性があります。

  • インスタンス グループの容量が不足し、トラフィックを別のゾーンにルーティングしなければならない場合。この場合、既存のセッションからのトラフィックは新しいゾーンに送信され、アフィニティが失われる可能性があります。すべてのローカル ユーザーを処理するのに十分な容量をインスタンス グループに確保することで、これに対処できます。
  • 自動スケーリングによって、インスタンス グループに対してインスタンスが追加または削除される場合。いずれの場合も、バックエンド サービスによって負荷が再割り当てされ、ターゲットが移動する可能性があります。自動スケーリングによってプロビジョニングされる最低限の数のインスタンスで予想される負荷を十分に処理できるようにし、負荷が予期せず増加した場合にのみ自動スケーリングを使用することで、これに対処できます。
  • ターゲット インスタンスでヘルスチェックが失敗する場合。セッションが他の正常なインスタンスに移動されると、アフィニティは失われます。
  • 分散モードがバックエンド使用率に設定されている場合。ゾーン全体で計算された容量が変わり、リージョン内の別のゾーンにトラフィックが送信される可能性があります。容量の計算が安定していない場合、トラフィックの量が少ない可能性があります。
  • バックエンドが複数のクラウド リージョンに存在し、接続の最初のリクエストと後続のリクエストが地理的に異なる場所から送信されるようにクライアントのルーティング設計されている場合、セッション アフィニティが失われる可能性があります。これは、追加のリクエストが、新しい下り(外向き)ロケーションによって決まる別のクラウド リージョンにルーティングされる可能性があるためです。

タイムアウト設定の構成

ロードバランサからバックエンド サービスへの接続の存続時間を長くする場合は、タイムアウト設定をデフォルトの 30 秒より長い時間に構成します。

Console


タイムアウト設定を構成するには:

  1. タイムアウト設定は、Google Cloud Console の HTTP(S) 負荷分散ページにある [バックエンドの設定] で変更できます。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンド サービス] の [編集] 鉛筆アイコンを選択します。
  5. [プロトコル、ポート、タイムアウト] 設定の行で [編集] 鉛筆アイコンを選択します。
  6. 新しい [タイムアウト設定] を秒単位で入力します。
  7. [バックエンド サービス] の [更新] ボタンをクリックします。
  8. ロードバランサの [更新] ボタンをクリックします。

gcloud


gcloud コマンドライン ツールでタイムアウト設定を変更するには、「gcloud compute backend-services update」コマンドを使用します。詳しくは、--help フラグを指定してコマンドを実行してください。

gcloud compute backend-services update [BACKEND_SERVICE] [--timeout=TIMEOUT]
    

API


バックエンド サービスの REST API リファレンスをご覧ください。

名前付きポート

内部 HTTP(S)、外部 HTTP(S)、SSL プロキシ、TCP プロキシのロードバランサで、バックエンドがインスタンス グループの場合、バックエンド サービスに名前付きポートを関連付ける必要があります。名前付きポートが使用されていると、ロードバランサはバックエンド インスタンス グループで構成済みの名前付きポートを使用して、それをポート番号に変換します。これは、ロードバランサがバックエンド VM との接続に使用するポートで、クライアントがロードバランサとの接続に使用するポートとは異なります。

名前付きポートは、サービスが実行されているサービス名とポート番号を表す Key-Value ペアです。Key-Value ペアはインスタンス・グループに定義されます。バックエンド サービスがこのインスタンス グループをバックエンドとして使用するときに、名前付きポートに登録できます。

  • 1 つのインスタンス グループには、最大で 5 つまでの名前付きポート(Key-Value ペア)を定義できます。
  • インスタンス グループ バックエンドを使用する HTTP(S)、SSL プロキシ、TCP プロキシのロードバランサの各バックエンド サービスは、1 つの名前付きポートにのみ登録できます。
  • バックエンド サービスに名前付きポートを指定する場合は、すべてのバックエンド インスタンス グループには、同じ名前を使用する 1 つ以上の名前付きポートが定義されている必要があります。

次のような場合は、名前付きポートを使用できません。

  • NEG バックエンド: NEG はエンドポイントごとにポートを定義します。NEG に関連付けられたポートの Key-Value ペアはありません。
  • 内部 TCP / UDP ロードバランサ: 内部 TCP / UDP ロードバランサはパススルー ロードバランサです。バックエンド サービスは名前付きポートの設定をサポートしません。

ヘルスチェック

各バックエンド サービスにはヘルスチェックが関連付けられている必要があります。ヘルスチェックは、バックエンド サービスを作成する前に用意する必要があります。

ヘルスチェックは継続的に実行され、その結果を使用して新しいリクエストを受け取るインスタンスが決定されます。

異常なインスタンスは新しいリクエストを受け取らず、引き続きポーリングされます。異常なインスタンスがヘルスチェックに合格すると、それは正常であると見なされ、新しい接続の受信が開始されます。

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

バックエンド サービスのヘルスチェック結果の表示

ヘルスチェックとバックエンド サービスを作成すると、ヘルスチェックの結果を表示できるようになります。

Console


バックエンド サービスのヘルスチェックの結果を表示するには:

  1. 負荷分散の概要ページに移動します。
    [負荷分散] ページに移動
  2. ロードバランサの名前をクリックします。
  3. [バックエンド サービス] の [バックエンド] で、[インスタンス グループ] テーブルの [正常] 列を確認します。

gcloud


gcloud コマンドライン ツールで最新のヘルスチェックの結果を表示するには、backend-services get-health コマンドを実行します。

gcloud compute backend-services get-health [BACKEND_SERVICE]
    

このコマンドによって、HEALTHY または UNHEALTHY のいずれかの値と、指定されたバックエンド サービスのすべてのインスタンスに関する healthState の値が返されます。

      healthStatus:
        - healthState: UNHEALTHY
          instance: us-central1-b/instances/www-video1
        - healthState: HEALTHY
          instance: us-central1-b/instances/www-video2
      kind: compute#backendServiceGroupHealth
      

API


API コマンドについては、ヘルスチェックのページをご覧ください。

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

バックエンド サービス リソースで有効な以下のオプションの Google Cloud 機能は、このドキュメントで扱いません。

備考

バックエンド サービスに対する変更は即時に行われるわけではありません。変更内容がネットワーク全体に反映されるまでに数分かかることがあります。

Google Cloud ロードバランサでは、次の Traffic Director 機能はサポートされません。

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

次のステップ

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