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

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

  • HTTP(S) 負荷分散
  • SSL プロキシ負荷分散
  • TCP プロキシ負荷分散
  • 内部 TCP / UDP 負荷分散
  • 内部 HTTP(S) 負荷分散(ベータ版)

バックエンド サービスは、バックエンド(インスタンス グループまたはネットワーク エンドポイント グループ)にトラフィックを転送します。

バックエンド サービスは、次のようなさまざまな機能を実行します。

  • 分散モードに従ってトラフィックを転送します。分散モードは、各バックエンドのバックエンド サービスで定義します。
  • ヘルスチェックに基づいてバックエンドの状態をモニタリングします。
  • セッション アフィニティを維持します。

アーキテクチャ

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

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

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

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

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

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

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

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

バックエンド

バックエンドは、GCP ロードバランサがトラフィックを分散するためのリソースです。バックエンドとして使用できるリソースには、次の 2 種類があります。

1 つのバックエンド サービスのバックエンドは、すべてインスタンス グループまたは NEG(サポートされている場合)のいずれかでなければなりません。同じバックエンド サービスのバックエンドとして、インスタンス グループと 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 アドレスは必要ありません。

トラフィック分散

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

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

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

  • 同じバックエンド サービスに接続されているバックエンド インスタンス グループのすべてのインスタンスの平均 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 による負荷分散にも使用できます

バックエンド サービスとリージョン

HTTP(S) 負荷分散はグローバル サービスです。リージョン内に複数のバックエンド サービスを設定し、それらのバックエンド サービスを複数のリージョンに割り当てて、すべてを同じグローバル ロードバランサで管理できます。トラフィックは、次のようにバックエンド サービスに割り当てられます。

  1. ユーザー リクエストを受信すると、負荷分散サービスによってソース IP アドレスからリクエストの大まかな送信元が判別されます。
  2. 負荷分散サービスは、バックエンド サービスが所有しているインスタンスの場所、それらの総容量、現在の総使用量を認識します。
  3. ユーザーに最も近いインスタンスに使用可能な容量がある場合、リクエストはその最も近いインスタンスのセットに転送されます。
  4. 指定されたリージョンに着信したリクエストは、そのリージョン内の使用可能なすべてのバックエンド サービスとインスタンスに、均等に分散されます。ただし、負荷が非常に小さい場合は分散が不均等に見える場合もあります。
  5. 指定されたリージョン内に使用可能な容量を持つ正常なインスタンスがない場合、ロードバランサは代替手段として、使用可能な容量を持つ次に近いリージョンにリクエストを送信します。

インスタンス グループ

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

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

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

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

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

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

  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 アフィニティは、バックエンド サービスを使用する GCP ロードバランサのオプションです。

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

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

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

Console


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

  1. Google Cloud Platform 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 アフィニティが設定されている場合、ロードバランサは最初のリクエストで GCLB という名前の Cookie を発行し、後続の同じ Cookie を持つ各リクエストを同じインスタンスに送信します。Cookie ベースのアフィニティでは、ロードバランサは同じ IP アドレスを使用する異なるクライアントを識別できるため、インスタンス間でより均等にクライアントを分散できます。Cookie ベースのアフィニティにより、クライアントの IP アドレスが変わった場合でもロードバランサはインスタンス アフィニティを維持できます。

Cookie のパスは常に / であるため、同じホスト名の 2 つバックエンド サービスで Cookie ベースのアフィニティが有効になっている場合、この 2 つのサービスは同じ Cookie で負荷分散されます。

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

Console


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

  1. 生成された Cookie アフィニティは、Google Cloud Platform Console の HTTP(S) 負荷分散ページにある [バックエンドの設定] で変更できます。
    [負荷分散] ページに移動
  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 Platform 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 リファレンスをご覧ください。

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

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

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

タイムアウト設定の構成

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

Console


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

  1. タイムアウト設定は、Google Cloud Platform 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 ロードバランサはパススルー ロードバランサです。バックエンド サービスは名前付きポートの設定をサポートしません。

ヘルスチェック

各バックエンド サービスにはヘルスチェックが関連付けられている必要があります。ヘルスチェックは継続的に実行され、その結果を使用して新しいリクエストを受け取るインスタンスが決定されます。

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

ヘルスチェックに関するベスト プラクティス

ヘルスチェックを構成する際はヘルスチェックとトラフィックの処理を同じポートで行うことをおすすめしますが、ヘルスチェックとトラフィックの処理を別々のポートで処理することも可能です。2 つの異なるポートを使用する場合は、インスタンスで実行しているファイアウォール ルールとサービスが適切に構成されていることを確認してください。ヘルスチェックとトラフィックの処理を同じポートで行った後、ある時点でポートを切り替える場合は、必ずバックエンド サービスとヘルスチェックの両方を更新してください。

有効な転送ルールを参照していないバックエンド サービスにはヘルスチェックが実行されないため、正常性ステータスはありません。

ヘルスチェックの作成

バックエンド サービスを作成する前にヘルスチェックを作成する必要があります。負荷分散するトラフィックと同じプロトコルでヘルスチェックを作成することをおすすめします。

Console

Console では、バックエンド サービスを作成するときにヘルスチェックを作成できます。

gcloud

gcloud コマンドを使用してヘルスチェックを作成する場合は、ヘルスチェックのページをご覧ください。

API

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

バックエンド サービスの作成

Console


新しいバックエンド サービスを作成するには:

  1. バックエンド サービスは、Google Cloud Platform Console の HTTP(S) 負荷分散ページにある [バックエンドの設定] で作成できます。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンド サービスとバックエンド バケットの作成または選択] プルダウン メニューで、[バックエンド サービス]、[バックエンド サービスを作成] の順に選択します。
  5. バックエンド サービスの [名前] を入力します。
  6. 必要に応じて、説明を入力します。
  7. [プロトコル、ポート、タイムアウト] 設定の行で [編集] 鉛筆アイコンを選択します。
    • [プロトコル] で httphttps または http2 を選択します。
    • [名前付きポート] で「port name」と入力します。
    • 必要に応じて、デフォルトのタイムアウト設定を変更します。
  8. [BackendType] で [インスタンス グループ] ラジオボタンを選択します。
  9. [バックエンド] ダイアログ ボックスでは 1 つ以上のバックエンドを作成できます。
    1. [新しいバックエンド] ダイアログ ボックスで、プルダウン メニューから既存の [インスタンス グループ] を選択します。
    2. バックエンドがリクエストを受け取る 1 つ以上のポート番号をカンマ区切りで入力します。
      • [プロトコル] が http の場合、このフィールドは 80 に設定されます。
      • [プロトコル] が https の場合、このフィールドは 443 に設定されます。
      • [プロトコル] が http2 の場合、このフィールドは 443 に設定されます。
    3. [最大 CPU 使用率] のパーセンテージを設定します。
    4. 必要に応じて、最大 RPS を設定します。unlimited. の場合、このフィールドは空白のままにします。 [インスタンスあたりの RPS] または [グループあたりの RPS] を設定します。
    5. [容量] のパーセンテージを設定します。
    6. [完了] ボタンをクリックします。
  10. [Cloud CDN を有効にする] チェックボックスをオンまたはオフにします。
  11. [ヘルスチェック] メニューで既存のヘルスチェックを選択するか、次の手順に従って別のヘルスチェックを作成します。
    1. [名前] を設定します。
    2. 必要に応じて、説明を設定します。
    3. [プロトコル] と [ポート] を設定します。ベスト プラクティスについては、ヘルスチェックをご覧ください。
    4. [プロキシのプロトコル] を設定します。
    5. 必要に応じて、リクエストレスポンスの値を設定します。
    6. [ヘルス条件] で次の項目を設定します。
      1. [チェック間隔] を秒単位で設定します。
      2. [タイムアウト] を秒単位で設定します。
      3. [正常しきい値] に number of consecutive successes を設定します。
      4. [異常しきい値] に number of consecutive failures を設定します。
      5. [保存して次へ] をクリックします。
    7. [詳細設定] をクリックして、セッション アフィニティ接続のタイムアウトカスタム リクエスト ヘッダーセキュリティ ポリシーを変更します。
      1. セッション アフィニティを設定するには、[クライアント IP] または [生成した Cookie] を選択します。[*生成した Cookie] を選択した場合は、アフィニティ Cookie の TTL を秒単位で設定します。
      2. 接続ドレインのタイムアウトを設定するには、インスタンスが実行中の接続の完了を待つ時間を秒数で入力します。
      3. カスタム リクエスト ヘッダーを作成するには、[+ ヘッダーを追加] をクリックし、ヘッダーにヘッダー名ヘッダー値を追加します。
      4. セキュリティ ポリシーを有効にするには、プルダウン メニューからセキュリティ ポリシーを選択します。
    8. [バックエンド サービス] の [更新] ボタンをクリックします。
    9. ロードバランサの [更新] ボタンをクリックします。

gcloud


gcloud コマンドライン ツールを使用してバックエンド サービスを作成する方法については、Cloud SDK ドキュメントをご覧ください。

API


API コマンドでバックエンド サービスを作成する方法については、バックエンド サービスページをご覧ください。

バックエンド サービスの変更

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

Console


既存のバックエンド サービスを変更するには:

  1. バックエンド サービスは、Google Cloud Platform Console の HTTP(S) 負荷分散ページにある [バックエンドの設定] で編集できます。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンド サービス] で、バックエンド サービスの [編集] 鉛筆アイコンを選択します。次のフィールドを変更できます。
    1. [バックエンド] で新しい [バックエンド] を追加するか、既存のバックエンドの [編集] 鉛筆アイコンを選択します。
    2. [プロトコル、ポート、タイムアウト] 設定の行で [編集] 鉛筆アイコンを選択します。
    3. 既存の [ヘルスチェック] を選択するか、前述のヘルスチェック作成手順に従って新しいヘルスチェックを作成します。
    4. [セッション アフィニティ] を変更し、必要に応じて [アフィニティ Cookie の TTL] を変更します。
    5. [詳細設定] をクリックして、接続ドレインのタイムアウトを変更します。
    6. [Cloud CDN を有効にする] チェックボックスをオンまたはオフにします。
  5. [詳細設定] をクリックして、セッション アフィニティ接続のタイムアウトカスタム リクエスト ヘッダーセキュリティ ポリシーを変更します。
    1. セッション アフィニティを設定するには、[クライアント IP] または [生成した Cookie] を選択します。[*生成した Cookie] を選択した場合は、アフィニティ Cookie の TTL を秒単位で設定します。
    2. 接続ドレインのタイムアウトを設定するには、インスタンスが実行中の接続の完了を待つ時間を秒数で入力します。
    3. カスタム リクエスト ヘッダーを作成するには、[+ ヘッダーを追加] をクリックし、ヘッダーにヘッダー名ヘッダー値を追加します。
    4. セキュリティ ポリシーを有効にするには、プルダウン メニューからセキュリティ ポリシーを選択します。
    5. [バックエンド サービス] の [更新] ボタンをクリックします。
    6. ロードバランサの [更新] ボタンをクリックします。

gcloud


gcloud コマンドライン ツールを使用してバックエンド サービスを変更する方法については、Cloud SDK ドキュメントをご覧ください。

API


API を使用してバックエンド サービスを変更する方法については、API ドキュメントをご覧ください。

バックエンド サービスへのインスタンス グループの追加

バックエンド サービスに含まれているインスタンスを定義するには、バックエンドを追加し、それにインスタンス グループを割り当てる必要があります。先にインスタンス グループを作成してから、バックエンドに追加する必要があります。

バックエンドにインスタンス グループを追加するときは、特定のパラメータを定義する必要もあります。

Console


バックエンド サービスにインスタンス グループを追加するには:

  1. インスタンス グループは、Google Cloud Platform Console の HTTP(S) 負荷分散ページにある [バックエンドの設定] でバックエンドに追加できます。
    [負荷分散] ページに移動
  2. ロードバランサの [編集] 鉛筆アイコンを選択します。
  3. [バックエンドの設定] を選択します。
  4. [バックエンドの設定] の [編集] 鉛筆アイコンを選択します。
  5. [バックエンド] の [編集] 鉛筆アイコンを選択します。
  6. [バックエンドの編集] ダイアログ ボックスで、[インスタンス グループ] プルダウン メニューから Instance group を選択します。
  7. [バックエンドの編集] の [完了] ボタンをクリックします。
  8. [バックエンド サービス] の [更新] ボタンをクリックします。
  9. ロードバランサの [更新] ボタンをクリックします。

gcloud


gcloud コマンドライン ツールを使用してバックエンド サービスにインスタンス グループを追加する方法については、Cloud SDK をご覧ください。

API


API を使用してバックエンド サービスにインスタンス グループを追加する方法については、API のドキュメントをご覧ください。

バックエンド サービスへのネットワーク エンドポイント グループの追加

バックエンド サービスにネットワーク エンドポイント グループを追加する方法については、バックエンド サービスへのネットワーク エンドポイント グループの追加をご覧ください。

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

ヘルスチェックとバックエンド サービスを作成したら、ヘルスチェックの結果を表示できます。

Console


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

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

gcloud


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

gcloud compute backend-services get-health [BACKEND_SERVICE]

このコマンドは、指定したバックエンド サービスのすべてのインスタンスの healthState の値(HEALTHY または UNHEALTHY)を返します。

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

API


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

備考

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

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

次のステップ

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