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

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

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

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

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

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

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

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

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

始める前に

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

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

サービスロードバランシングポリシーと優先バックエンドは、次の表に示すように、サポートされているバックエンドを使用するロードバランサでのみ構成できます。

バックエンド	サポート対象
インスタンスグループ非マネージドゾーン管理
リージョン MIG
ゾーン NEG（`GCE_VM_IP_PORT` エンドポイント）
ハイブリッド 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_ZONE アルゴリズムは、次の点を考慮しながらレイテンシを最小限に抑えます。

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

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

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

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

自動容量ドレイン

通常、正常でないバックエンドは、できるだけ早くロードバランシングの判断から除外する必要があります。正常でないバックエンドを除外すると、正常なバックエンドにのみトラフィックが送信されるため、全体的なレイテンシが最適化されます。

自動容量ドレイン機能を有効にすると、ヘルスチェックに合格したバックエンドのインスタンスまたはエンドポイントが 25% 未満の場合、ロードバランサはバックエンドの容量を自動的にゼロにスケーリングします。これにより、正常でないバックエンドがグローバルロードバランシングプールから削除されます。このアクションは、バックエンドにトラフィックを転送しないようにするために、バックエンドの backendService.capacityScaler を 0 に設定するのと機能的に同等です。

以前に自動ドレインされたバックエンドのインスタンスまたはエンドポイントの 35%（しきい値の 10% 超）が 60 秒間ヘルスチェックに合格すると、バックエンドのドレインが自動的に解除され、ロードバランシングプールに再び追加されます。これにより、正常なバックエンドでドレイン状態のフリップフロップが発生しなくなります。

自動容量ドレインを有効にしても、ロードバランサは、バックエンドのヘルスステータスに関係なく、バックエンドサービスに接続されているバックエンドの 50% を超えてドレインすることはありません。バックエンドの 50% を接続したままにすることで、正常なバックエンドが過負荷になるリスクが軽減されます。

自動容量ドレインのユースケースの 1 つは、優先バックエンドの過負荷リスクを最小限に抑えることです。たとえば、バックエンドが優先とマークされていて、そのインスタンスやエンドポイントのほとんどが異常である場合、自動容量ドレインにより、ロードバランシングプールからバックエンドが削除されます。自動容量ドレインでは、優先バックエンドの残りの正常なインスタンスまたはエンドポイントの負荷を高めるのではなく、別のバックエンドにトラフィックをシフトします。

自動容量ドレインは、サービスロードバランシングポリシーの一部として有効にできます。詳細については、サービスロードバランシングポリシーを構成するをご覧ください。

自動容量は、バランシングモードを使用しないバックエンドではサポートされません。これには、インターネット NEG、サーバーレス NEG、PSC NEG などのバックエンドが含まれます。

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

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

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

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

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

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

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

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

優先バックエンド

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

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

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

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

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

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

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

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

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

ポリシーを作成する

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

サービスロードバランシングポリシーリソースを作成します。これは、YAML ファイルを使用して行うことも、gcloud パラメータを使用して直接行うこともできます。
- YAML ファイルを使用する場合。YAML ファイルにサービスロードバランシングポリシーを指定します。次の YAML ファイルの例では、ロードバランシングアルゴリズムの構成方法、自動容量ドレインの有効化方法、カスタムフェイルオーバーしきい値の設定方法を示しています。
```
name: projects/PROJECT_ID/locations/global/serviceLbPolicies/SERVICE_LB_POLICY_NAME
- autoCapacityDrain:
    enable: True
- loadBalancingAlgorithm: LOAD_BALANCING_ALGORITHM
- failoverConfig:
    failoverHealthThreshold: FAILOVER_THRESHOLD_VALUE
```
  次のように置き換えます。
  - PROJECT_ID: プロジェクト ID。
  - SERVICE_LB_POLICY_NAME: サービスロードバランシングポリシーの名前。
  - LOAD_BALANCING_ALGORITHM: 使用するロードバランシングアルゴリズム。SPRAY_TO_REGION、WATERFALL_BY_REGION、または WATERFALL_BY_ZONE のいずれかになります。
  - FAILOVER_THRESHOLD_VALUE: フェイルオーバーのしきい値。1～99 の数値で指定してください。
  YAML ファイルを作成したら、そのファイルを新しいサービスロードバランシングポリシーにインポートします。
```
gcloud beta network-services service-lb-policies import SERVICE_LB_POLICY_NAME \
 --source=PATH_TO_POLICY_FILE \
 --location=global
```
- YAML ファイルを使用しない場合。YAML ファイルを使用せずにサービスロードバランシングポリシー機能を構成することもできます。
  
  ロードバランシングアルゴリズムを設定して自動ドレインを有効にするには、次のパラメータを使用します。
```
gcloud beta 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 の数値で指定してください。
--service-lb-policy フィールドが新しく作成したサービスロードバランシングポリシーリソースを参照するように、バックエンドサービスを更新します。バックエンドサービスは、1 つのサービスロードバランシングポリシーリソースにのみ関連付けることができます。
```
gcloud beta compute backend-services update BACKEND_SERVICE_NAME \
  --service-lb-policy=SERVICE_LB_POLICY_NAME \
  --global
```
バックエンドサービスを作成する際に、サービスロードバランシングポリシーをバックエンドサービスに関連付けることができます。
```
gcloud beta 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 beta compute backend-services update BACKEND_SERVICE_NAME \
    --no-service-lb-policy \
    --global

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

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

gcloud

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

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

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

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

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

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

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

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

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

gcloud beta 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 つのサービスロードバランシングポリシーリソースにのみ関連付けることができます。