高度なロード バランシング最適化

このページでは、サービス ロード バランシング ポリシーを使用して、次のロードバランサの費用、レイテンシ、復元力を最適化する高度機能をサポートする方法について説明します。

• グローバル外部アプリケーション ロードバランサ
• クロスリージョン内部アプリケーション ロードバランサ
• グローバル外部プロキシ ネットワーク ロードバランサ
• クロスリージョン内部プロキシ ネットワーク ロードバランサ

Cloud Service Mesh は、高度なロード バランシング最適化もサポートしています。詳細については、Cloud Service Mesh のドキュメントで高度なロード バランシングの概要をご覧ください。

サービス ロード バランシング ポリシー（serviceLbPolicy）は、ロードバランサのバックエンド サービスに関連付けられたリソースです。サービス ロード バランシング ポリシーを使用すると、バックエンド サービスに関連付けられたバックエンド内でのトラフィックの分散方法に影響するパラメータをカスタマイズできます。

• 特定のリージョンまたはゾーン内でのトラフィックの分散方法を決めるロード バランシング アルゴリズムをカスタマイズします。
• ロードバランサが正常でないバックエンドからトラフィックを迅速にドレインできるように、自動容量ドレインを有効にします。
• フェイルオーバーのしきい値を設定して、バックエンドが正常でないと判断するタイミングを決定します。これにより、トラフィックを別のバックエンドにフェイルオーバーして、異常なバックエンドを回避できます。

特定のバックエンドを優先バックエンドとして指定することもできます。これらのバックエンドがキャパシティに達すると、残りのバックエンドにリクエストが送信されます。

次の図は、Cloud Load Balancing がルーティング、ロード バランシング、トラフィック分散を評価する方法を示しています。

Cloud Load Balancing がルーティングとトラフィック分散を決定する仕組み。

始める前に

このページの内容を確認する前に、外部アプリケーション ロードバランサの概要ページにあるリクエストの分散プロセスをよく確認してください。常にプレミアム ティアに存在するロードバランサで、第 1 候補のリージョンがすでにいっぱいになっている場合、このページで説明するすべてのロード バランシング アルゴリズムでリージョン間のスピルオーバーがサポートされます。

サポートされているバックエンド

サービス ロード バランシング ポリシーと、このページで説明するすべての機能には、バランシング モードをサポートする互換性のあるバックエンドが必要です。サポートされているバックエンドを次の表にまとめます。

バックエンド	サポート対象
インスタンス グループ	ゾーン非マネージド インスタンス グループとゾーン マネージド インスタンス グループはサポートされていますが、リージョン マネージド インスタンス グループはサポートされていません。
ゾーン NEG（GCE_VM_IP_PORT エンドポイント）
ゾーン NEG（GCE_VM_IP エンドポイント）	このタイプの NEG は、アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサではサポートされていません。
ハイブリッド NEG（NON_GCP_PRIVATE_IP_PORT エンドポイント）
サーバーレス NEG
インターネット NEG
Private Service Connect NEG

ロード バランシング アルゴリズム

このセクションでは、サービス ロード バランシング ポリシーで構成できるロード バランシング アルゴリズムについて説明します。アルゴリズムを構成しない場合や、サービスのロード バランシング ポリシーをまったく構成しない場合、ロードバランサはデフォルトの WATERFALL_BY_REGION を使用します。

リージョンごとのウォーターフォール

WATERFALL_BY_REGION は、デフォルトのロード バランシング アルゴリズムです。このアルゴリズムを使用すると、ユーザーに最も近いリージョン内のすべての Google Front End（GFE）が、構成されたターゲット容量（容量スケーラーによって変更可能）に比例してバックエンドの選択を試みます。

2 番目のレイヤの GFE は、2 番目のレイヤの GFE に可能な限り近いゾーン（ネットワークのラウンドトリップ時間で定義）のバックエンド インスタンスまたはエンドポイントを優先的に選択します。WATERFALL_BY_REGION はゾーン間のレイテンシを最小限に抑え、リクエスト率が低いため、2 番目のレイヤの GFE は、2 番目のレイヤの GFE 優先ゾーンのバックエンドにリクエストを排他的に送信する可能性があります。

最も近いリージョンのすべてのバックエンドが構成された容量の上限で実行されている場合、トラフィックはネットワーク レイテンシを最適化しながら、次に最も近いリージョンにオーバーフローし始めます。

リージョンへのスプレー

SPRAY_TO_REGION アルゴリズムは、2 番目のレイヤの GFE が 2 番目のレイヤの GFE に可能な限り近いゾーンにあるバックエンド インスタンスまたはエンドポイントを優先的に選択しないように、2 番目のレイヤの GFE の動作を変更します。SPRAY_TO_REGION を使用すると、2 番目のレイヤの GFE は、リージョン内のすべてのゾーンのすべてのバックエンド インスタンスまたはエンドポイントにリクエストを送信します。2 番目のレイヤの GFE とバックエンド インスタンスまたはエンドポイント間のラウンドトリップ時間が短いほうが優先されることはありません。

WATERFALL_BY_REGION と同様に、リージョン内の 2 番目のレイヤのすべての GFE が、構成されたターゲット容量（容量スケーラーによって変更可能）に比例してバックエンドの選択を行います。

SPRAY_TO_REGION は、特にリクエスト率が低い場合、リージョン内のすべてのゾーンのバックエンド間でより均一な分散を行いますが、この均一な分散には次の考慮事項があります。

• バックエンドが停止しても、ヘルスチェックに引き続き合格している場合、2 番目のレイヤで影響を受ける GFE は多くなりますが、個々の影響はそれほど深刻ではありません。
• 2 番目のレイヤの各 GFE に優先ゾーンがないため、2 番目のレイヤの GFE は、より多くのゾーン間トラフィックを生成します。処理されるリクエスト数によっては、2 番目のレイヤの GFE がそれぞれバックエンドへの TCP 接続を確立する場合があります。

ゾーンごとのウォーターフォール

WATERFALL_BY_ZONE アルゴリズムは、2 番目のレイヤの GFE が 2 番目のレイヤの GFE に可能な限り近いゾーンにあるバックエンド インスタンスまたはエンドポイントを優先的に選択するように、2 番目のレイヤの GFE の動作を変更します。WATERFALL_BY_ZONE を使用すると、2 番目のレイヤの GFE が最も優先されるゾーンのバックエンド インスタンスまたはエンドポイントをすべて選択した場合（または比較的過剰に選択した場合）、2 番目のレイヤの GFE は、リージョン内の他のゾーンのバックエンド インスタンスまたはエンドポイントにのみリクエストを送信します。

WATERFALL_BY_REGION と同様に、リージョン内の 2 番目のレイヤのすべての GFE が、構成されたターゲット容量（容量スケーラーによって変更可能）に比例してバックエンドの選択を行います。

WATERFALL_BY_ZONE アルゴリズムは、次の点を考慮しながらレイテンシを最小限に抑えます。

• WATERFALL_BY_ZONE は、本質的にゾーン間の接続を最小化しません。このアルゴリズムはレイテンシのみによってステアリングされます。
• WATERFALL_BY_ZONE では、2 番目のレイヤの GFE が最優先のゾーンを充填してから他のゾーンを充填するとは限りません。メンテナンス イベントにより、2 番目のレイヤの GFE からのすべてのトラフィックが、別のゾーンのバックエンド インスタンスまたはエンドポイントに一時的に送信される可能性があります。
• WATERFALL_BY_ZONE では、リージョン内のすべてのバックエンド インスタンスまたはエンドポイント間でリクエストが均一に分散されない可能性があります。たとえば、2 番目のレイヤの GFE の最優先ゾーンのバックエンド インスタンスまたはエンドポイントが容量に達したときに、他のゾーンのバックエンドが容量に達していない能性があります。

ロード バランシング アルゴリズムを比較する

次の表に、ロード バランシング アルゴリズムの比較を示します。

動作	リージョンごとのウォーターフォール	リージョンへのスプレー	ゾーンごとのウォーターフォール
単一リージョン内で容量使用量を均一化	はい	○	いいえ
複数のリージョンで使用量を均一化	いいえ	いいえ	いいえ
ロードバランサからのトラフィック分割を均一化	いいえ	○	いいえ
ゾーン間のトラフィック分散	はい。トラフィックは、ネットワーク レイテンシを最適化しながら、リージョン内のゾーンに均等に分散されます。必要に応じて、トラフィックがゾーン間で送信されることがあります。	はい	はい。トラフィックは、容量に達するまで最も近いゾーンに送信されます。その後、次に近いゾーンに送信されます。
ローカルゾーンでのトラフィック急増に対する感度	平均的。ゾーン間のバランスをとるために、すでに行われたトラフィック シフトの量によって異なります。	低め。単一ゾーンでの急増がリージョン内のすべてのゾーンに広がります。	高め。ロードバランサが対応できるようになるまで、単一ゾーンでの急増は同じゾーンで処理される可能性が高くなります。

自動容量ドレインと自動容量ドレイン解除

自動容量ドレインとドレイン解除は、ヘルスチェックとバックエンド容量のコンセプトを組み合わせたものです。自動容量ドレインでは、ヘルスチェックが追加のシグナルとして使用され、有効なバックエンド容量がゼロに設定されます。自動容量ドレインでは、有効なバックエンド容量を以前の値に戻すための追加のシグナルとして、ヘルスチェックが使用されます。

自動容量ドレインとドレイン解除を行わずに、特定のリージョン内のすべてのバックエンドからリクエストを転送する場合は、そのリージョン内の各バックエンドの有効な容量を手動でゼロに設定する必要があります。たとえば、容量スケーリングを使用してこれを行うことができます。

自動容量ドレインとドレイン解除では、ドレインまたはドレイン解除によってバックエンドの容量を調整するシグナルとしてヘルスチェックを使用できます。

自動容量ドレインとドレイン解除を有効にするには、サービス ロード バランシング ポリシーを構成するをご覧ください。

自動容量ドレイン

自動容量ドレインは、次の両方の条件が満たされると、バックエンドの容量をゼロに設定します。

• バックエンドのインスタンスまたはエンドポイントの 25% 未満がヘルスチェックに合格しています。
• 自動的にドレインされるバックエンド インスタンス グループまたは NEG の合計数が、バックエンド インスタンス グループまたは NEG の合計数の 50% を超えていない。50% の比率を計算する場合、容量がゼロのバックエンドは分母に含まれません。ただし、分母にはすべてのバックエンドが含まれます。

容量がゼロのバックエンドには、次のようなものがあります。

• メンバー インスタンスのないバックエンド インスタンス グループ。インスタンス グループの容量はインスタンスごとに定義されます。
• メンバー エンドポイントのないバックエンド NEG（NEG 容量はエンドポイントごとに定義されます）
• 容量スケーラーがゼロに設定されたバックエンド インスタンス グループまたは NEG

自動的にドレインされるバックエンド容量は、容量スケーリング値を設定せずに、バックエンドの backendService.backends[].capacityScaler を手動で 0 に設定するのと同じ機能です。

自動容量ドレイン解除

自動容量ドレイン解除は、バックエンドのインスタンスまたはエンドポイントの 35% 以上が 60 秒間ヘルスチェックに合格すると、バックエンドの容量をバックエンドの容量スケーラーによって制御される値に戻します。60 秒の要件により、ヘルスチェックが連続して失敗してから合格した場合に、連続したドレインとドレインの解除が発生する可能性が低くなります。

フェイルオーバーのしきい値

ロードバランサは、バックエンド間のトラフィックの分散をマルチレベルで決定します。安定状態では、前述のロード バランシング アルゴリズムのいずれかに基づいて選択されたバックエンドにトラフィックを送信します。このようなバックエンドは、プライマリ バックエンドと呼ばれ、レイテンシと容量の観点から最適と見なされます。

ロードバランサは、プライマリ バックエンドが異常でトラフィックを処理できなくなった場合に使用できる他のバックエンドも追跡します。これらのバックエンドは、フェイルオーバー バックエンドと呼ばれます。これらのバックエンドは通常、残り容量のある近くのバックエンドです。

プライマリ バックエンドのインスタンスまたはエンドポイントが異常な状態になっても、ロードバランサはトラフィックを他のバックエンドにすぐには移行しません。代わりに、ロードバランサはまず同じバックエンド内の他の正常なインスタンスまたはエンドポイントにトラフィックをシフトして、トラフィックの負荷を安定させます。プライマリ バックエンドの多くのエンドポイントが異常な状態で、同じバックエンド内の残りのエンドポイントが追加のトラフィックを処理できない場合、ロードバランサはフェイルオーバーしきい値を使用して、フェイルオーバー バックエンドへのトラフィック送信を開始するタイミングを決定します。ロードバランサは、フェイルオーバーしきい値までプライマリ バックエンドの異常を許容します。その後、トラフィックはプライマリ バックエンドからシフトされます。

フェイルオーバーのしきい値は 1～99 の値で、正常である必要のあるバックエンドのエンドポイントの割合で表します。正常なエンドポイントの割合がフェイルオーバーしきい値を下回ると、ロードバランサはフェイルオーバー バックエンドにトラフィックを送信しようとします。デフォルトのフェイルオーバーしきい値は 70 です。

フェイルオーバーしきい値の設定が高すぎると、一時的な健全性の変化で不要なトラフィック流出が発生する可能性があります。フェイルオーバーしきい値の設定が低すぎると、異常なエンドポイントが多数あっても、ロードバランサはプライマリ バックエンドにトラフィックを送信し続けます。

フェイルオーバーの決定はローカライズされています。ローカルの Google Front End（GFE）が互いに独立して動作します。フェイルオーバー バックエンドが追加のトラフィックを処理できるようにする責任はユーザー側にあります。

フェイルオーバー トラフィックにより、バックエンドが過負荷になる可能性があります。バックエンドが正常でない場合でも、ロードバランサがトラフィックを送信することがあります。使用可能なバックエンドのプールから異常なバックエンドを除外するには、自動容量ドレイン機能を有効にします。

優先バックエンド

優先バックエンドとは、トラフィックを他のバックエンドにスピルオーバーする前に容量を完全に使用するバックエンドです。優先バックエンドで構成された容量を超えるトラフィックは、残りの非優先バックエンドに転送されます。ロード バランシング アルゴリズムは、バックエンド サービスの非優先バックエンド間でトラフィックを分散します。

後続のリクエストを残りのバックエンドに転送する前に、バックエンド サービスに接続されているバックエンドを完全に使用するように、ロードバランサを構成できます。

優先バックエンドを使用する場合は、次の制限事項を考慮してください。

• 優先バックエンドとして構成されたバックエンドがクライアントから遠く離れている場合、クライアント リクエストの平均レイテンシが高くなる可能性があります。より低いレイテンシでクライアントにサービスを提供していた可能性のあるバックエンドが他にあっても、この状況が発生します。
• 特定のロード バランシング アルゴリズム（WATERFALL_BY_REGION、SPRAY_TO_REGION、WATERFALL_BY_ZONE）は、優先バックエンドとして構成されたバックエンドに適用されません。

優先バックエンドを設定する方法については、優先バックエンドを設定するをご覧ください。

サービス ロード バランシング ポリシーを構成する

注: このセクションは、Cloud Load Balancing について中級から上級レベルの知識があることを前提としています。ここでは、バックエンド サービスの作成やロードバランサのその他の基本的な構成については説明しません。基本的な設定を行う場合は、それぞれのロードバランサのドキュメントをご覧ください。

サービス ロード バランシング ポリシー リソースでは、次のフィールドを構成できます。

• ロード バランシング アルゴリズム
• 自動容量ドレイン
• フェイルオーバーのしきい値

優先バックエンドを設定するには、優先バックエンドを設定するをご覧ください。

ポリシーを作成する

サービス ロード バランシング ポリシーを作成して構成するには、次の手順を完了します。

1. サービス ロード バランシング ポリシー リソースを作成します。これは、YAML ファイルを使用して行うことも、gcloud パラメータを使用して直接行うこともできます。

   • YAML ファイルを使用する場合。YAML ファイルにサービス ロード バランシング ポリシーを指定します。次の YAML ファイルの例では、ロード バランシング アルゴリズムの構成方法、自動容量ドレインの有効化方法、カスタム フェイルオーバーしきい値の設定方法を示しています。

     name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
     autoCapacityDrain:
         enable: True
     failoverConfig:
         failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
     loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
     

     次のように置き換えます。

     • PROJECT_ID: プロジェクト ID。
     • SERVICE_LB_POLICY_NAME: サービス ロード バランシング ポリシーの名前。
     • FAILOVER_THRESHOLD_VALUE: フェイルオーバーのしきい値。1～99 の数値で指定してください。
     • LOAD_BALANCING_ALGORITHM: 使用するロード バランシング アルゴリズム。SPRAY_TO_REGION、WATERFALL_BY_REGION、または WATERFALL_BY_ZONE のいずれかになります。

     YAML ファイルを作成したら、そのファイルを新しいサービス ロード バランシング ポリシーにインポートします。

     gcloud network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
      --source=PATH_TO_POLICY_FILE \
      --location=global
     

   • YAML ファイルを使用しない場合。YAML ファイルを使用せずにサービス ロード バランシング ポリシー機能を構成することもできます。

     ロード バランシング アルゴリズムを設定して自動ドレインを有効にするには、次のパラメータを使用します。

     gcloud network-services service-lb-policies create SERVICE_LB_POLICY_NAME \
      --load-balancing-algorithm=LOAD_BALANCING_ALGORITHM \
      --auto-capacity-drain \
      --failover-health-threshold=FAILOVER_THRESHOLD_VALUE \
      --location=global
     

     次のように置き換えます。

     • SERVICE_LB_POLICY_NAME: サービス ロード バランシング ポリシーの名前。
     • LOAD_BALANCING_ALGORITHM: 使用するロード バランシング アルゴリズム。SPRAY_TO_REGION、WATERFALL_BY_REGION、または WATERFALL_BY_ZONE のいずれかになります。
     • FAILOVER_THRESHOLD_VALUE: フェイルオーバーのしきい値。1～99 の数値で指定してください。

2. --service-lb-policy フィールドが新しく作成したサービス ロード バランシング ポリシー リソースを参照するように、バックエンド サービスを更新します。バックエンド サービスは、1 つのサービス ロード バランシング ポリシー リソースにのみ関連付けることができます。

   gcloud compute backend-services update BACKEND_SERVICE_NAME \
     --service-lb-policy=SERVICE_LB_POLICY_NAME \
     --global
   

   バックエンド サービスを作成する際に、サービス ロード バランシング ポリシーをバックエンド サービスに関連付けることができます。

   gcloud compute backend-services create BACKEND_SERVICE_NAME \
       --protocol=PROTOCOL \
       --port-name=NAMED_PORT_NAME \
       --health-checks=HEALTH_CHECK_NAME \
       --load-balancing-scheme=LOAD_BALANCING_SCHEME \
       --service-lb-policy=SERVICE_LB_POLICY_NAME \
       --global
   

ポリシーを削除する

バックエンド サービスからサービス ロード バランシング ポリシーを削除するには、次のコマンドを使用します。

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

優先バックエンドを設定する

優先バックエンドを構成するには、Google Cloud CLI または API を使用します。

gcloud

優先バックエンドを追加する

優先バックエンドを設定するには、バックエンド サービスにバックエンドを追加するときに、gcloud compute backend-services add-backend コマンドを使用して --preference フラグを設定します。

gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

PREFERENCE は、バックエンドに割り当てる優先レベルに置き換えます。PREFERRED または DEFAULT になります。

コマンドの残りの部分は、使用しているバックエンドのタイプ（インスタンス グループまたは NEG）によって異なります。必須パラメータについては、gcloud compute backend-services add-backend コマンドをご覧ください。

バックエンドの優先設定を更新する

バックエンドの --preference パラメータを更新するには、gcloud compute backend-services update-backend コマンドを使用します。

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    ...
    --preference=PREFERENCE \
    --global

コマンドの残りの部分は、使用しているバックエンドのタイプ（インスタンス グループまたは NEG）によって異なります。次のコマンドの例では、バックエンド インスタンス グループの優先設定を更新し、PREFERRED に設定しています。

gcloud compute backend-services update-backend BACKEND_SERVICE_NAME \
    --instance-group=INSTANCE_GROUP_NAME \
    --instance-group-zone=INSTANCE_GROUP_ZONE \
    --preference=PREFERRED \
    --global

API

優先バックエンドを設定するには、グローバル backendServices リソースを使用して、各バックエンドに preference フラグを設定します。

以下の例では、バックエンドの優先設定を構成しています。

  name: projects/PROJECT_ID/locations/global/backendServices/BACKEND_SERVICE_NAME
  ...
  - backends
      name: BACKEND_1_NAME
      preference: PREFERRED
      ...
  - backends
      name: BACKEND_2_NAME
      preference: DEFAULT
      ...

次のように置き換えます。

• PROJECT_ID: プロジェクト ID
• BACKEND_SERVICE_NAME: バックエンド サービスの名前
• BACKEND_1_NAME: 優先バックエンドの名前
• BACKEND_2_NAME: デフォルトのバックエンドの名前

トラブルシューティング

新しいサービス ロード バランシング ポリシーをバックエンド サービスに接続すると、トラフィック分散パターンが変わる可能性があります。

トラフィックの問題をデバッグするには、Cloud Monitoring を使用して、ロードバランサとバックエンドの間のトラフィック フローを確認します。Cloud Load Balancing のログと指標は、ロード バランシングの動作の理解にも役立ちます。

このセクションでは、新しく公開された構成でよく見られるいくつかのシナリオについて説明します。

1 つの送信元からのトラフィックが非常に多くのバックエンドに送信されている

SPRAY_TO_REGION アルゴリズムの場合、これは想定内の動作です。ただし、トラフィックをより広い範囲に分散すると、問題が発生する可能性があります。たとえば、バックエンドはさまざまなクライアントからのトラフィックを認識するため、キャッシュ ヒット率が低下する可能性があります。この場合は、WATERFALL_BY_REGION など、他のアルゴリズムの使用を検討してください。

正常でないエンドポイントの数が多いバックエンドにトラフィックが送信されていない

autoCapacityDrain が有効になっている場合、これは想定内の動作です。正常でないエンドポイントの数が多いバックエンドはドレインされ、ロード バランシング プールから削除されます。この動作が望ましくない場合は、自動容量ドレインを無効にできます。ただし、正常でないエンドポイントの数が多いバックエンドにトラフィックが送信され、リクエストが失敗する可能性があります。

トラフィックが近くのバックエンドではなく、遠く離れたバックエンドに送信されている

優先バックエンドがデフォルトのバックエンドよりも遠くにある場合、これは想定内の動作です。この動作が望ましくない場合は、それに応じて各バックエンドの優先設定を更新します。

優先バックエンドを使用している場合に、一部のバックエンドにトラフィックが送信されない

優先バックエンドがまだ容量に達していない場合、これは想定内の動作です。優先バックエンドは、これらのバックエンドへのラウンドトリップ時間のレイテンシに基づいて割り当てられます。

トラフィックを他のバックエンドに送信する場合は、次のいずれかを行います。

• 他のバックエンドの優先設定を更新します。
• 優先バックエンドのターゲット容量を低く設定します。ターゲット容量は、バックエンド サービスのバランシング モードに応じて max-rate フィールドまたは max-utilization フィールドを使用して構成されます。

一時的な健全性の変化でリモート バックエンドにトラフィックが送信される

これは、フェイルオーバーのしきい値が大きな値に設定されている場合の動作です。一時的な健全性の変化が発生したときにトラフィックをプライマリ バックエンドに送信し続ける場合は、このフィールドに小さい値を設定します。

他のエンドポイントが異常な場合、正常なエンドポイントが過負荷になる

これは、フェイルオーバーのしきい値が低い値に設定されている場合の動作です。エンドポイントが異常な場合、これらの異常なエンドポイント宛てのトラフィックは同じバックエンドの残りのエンドポイントに分散されます。フェイルオーバー動作をより早くトリガーする場合は、このフィールドにより大きな値を設定します。

制限事項

• 各バックエンド サービスは、1 つのサービス ロード バランシング ポリシー リソースにのみ関連付けることができます。