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

このページでは、アプリケーション ロードバランサとプロキシ ネットワーク ロードバランサの費用、レイテンシ、復元性を高度に最適化する構成方法について説明します。

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

Cloud Load Balancing には、次の高度な機能が備わっています。

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

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

• 優先バックエンド: 特定のバックエンドを優先バックエンドとして指定できます。この優先バックエンドが容量に達すると、残りのバックエンドにリクエストが送信されます。

次の図は、Cloud Load Balancing がルーティング、ロード バランシング、トラフィック分散を判断する仕組みを示しています。

始める前に

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

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

次のロードバランサは、サービス ロード バランシング ポリシーと優先バックエンドをサポートしています。

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

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

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

このセクションでは、サービス ロード バランシング ポリシーで構成できるロード バランシング アルゴリズムについて説明します。アルゴリズムを構成しない場合や、サービスのロード バランシング ポリシーをまったく構成しない場合、ロードバランサはデフォルトの 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）が互いに独立して動作します。フェイルオーバー バックエンドが追加のトラフィックを処理できるようにする責任はユーザー側にあります。

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

トラフィック分離

デフォルトでは、Cloud Load Balancing は WATERFALL_BY_REGION アルゴリズムを使用して、ユーザー トラフィックのルーティング先を決定します。WATERFALL_BY_REGION では、ユーザーに最も近いリージョンのバックエンドがフルまたは異常な状態の場合、トラフィックは他のリージョンにオーバーフローします。トラフィック分離を有効にすると、ロードバランサはそのリージョン内のすべてのバックエンドが構成された容量の最大上限で実行されている場合でも、ユーザーに最も近いリージョンにのみトラフィックを転送できます。トラフィック分離を有効にすると、リージョンでの連鎖的な障害を防ぎ、サービス停止が発生する可能性を 1 つのリージョン内に限定できます。

トラフィック分離は、サービス ロード バランシング ポリシーの一部として構成されます。使用できる分離モードは次の 2 種類があります。

• NEAREST（デフォルト）: ロードバランサ（接続を処理する第 2 レイヤの GFE または Envoy プロキシ）は、ユーザーに最も近いリージョンのバックエンドにトラフィックを送信します。最も近いリージョンにバックエンドが構成されていない場合、または最も近いリージョンのバックエンドが異常な状態の場合、ネットワーク レイテンシを最適化しつつ、次に最も近いリージョンにトラフィックをルーティングします。これは各リージョンで処理容量がなくなるまで継続されます。

  NEAREST 分離モードは、サポートされているロードバランサすべてで使用できます。

• STRICT: ロードバランサ（接続を処理する Envoy プロキシ）は、ユーザーに最も近いリージョンのバックエンドにのみトラフィックを送信します。最も近いリージョンにバックエンドが構成されていない場合、または最も近いリージョンのバックエンドが異常な状態でリクエストを処理できない場合、トラフィックが破棄され、リクエストが失敗するようになります。

  STRICT 分離モードは、クロスリージョン内部アプリケーション ロードバランサとクロスリージョン内部プロキシ ネットワーク ロードバランサでのみ使用できます。

分離なし

次の図は、トラフィック分離が有効になっていない場合のクロスリージョン ロードバランサの動作を示しています。

Nearest

次の図は、トラフィック分離が NEAREST モードで有効になっている場合のクロスリージョン ロードバランサの動作を示しています。

Strict

次の図は、トラフィック分離が STRICT モードで有効になっている場合のクロスリージョン ロードバランサの動作を示しています。

次の点に注意したうえで、この機能を有効にしてください。

• あるリージョン内のバックエンドが過負荷になっている場合、他のリージョンのバックエンドがトラフィックを処理できる場合でも、ロードバランサはそのリージョン内のバックエンドに追加のトラフィックを送信することがあります。つまり、各個別のリージョンのバックエンドが追加のトラフィックにより過負荷になる可能性が高くなるため、それに応じた計画が必要になります。

• 分離を有効にしても、トラフィックは引き続きグローバル コントロール プレーンでルーティングされます。つまり、複数のリージョンでグローバルな障害が発生する可能性は残ります。インフラストラクチャ レベルでの分離を強化するには、リージョン ロードバランサを選択してください。

トラフィック分離モードを構成する際には、REGION に分離の粒度も設定する必要があります。これにより、リージョン間トラフィックのオーバーフローを防止できます。粒度が構成されていない場合、トラフィック分離は行われません。トラフィック分離を有効にする方法については、サービス ロード バランシング ポリシーを構成するをご覧ください。

優先バックエンド

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

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

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

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

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

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

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

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

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

ポリシーを作成する

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

ポリシーで構成した機能を無効にする

このセクションでは、サービス ロード バランシング ポリシーで構成した機能をリセットまたは無効にする方法について説明します。

ロード バランシング アルゴリズムをリセットする

ロード バランシング アルゴリズムをリセットするには、次のコマンドを使用して、ロード バランシング アルゴリズムをデフォルトの WATERFALL_BY_REGION に戻します。

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --load-balancing-algorithm=WATERFALL_BY_REGION \
    --location=global

フェイルオーバーのしきい値をリセットする

フェイルオーバーのしきい値をリセットするには、次のコマンドを使用して、フェイルオーバーのしきい値をデフォルトの 70 秒に戻します。

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --failover-health-threshold=70 \
    --location=global

自動容量ドレインを無効にする

自動容量ドレインを無効にするには、次のコマンドを使用します。

gcloud network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --no-auto-capacity-drain \
    --location=global

トラフィック分離を無効にする

トラフィック分離（プレビュー）を無効にするには、以下のコマンドのとおり、両方の分離構成パラメータを UNSPECIFIED に設定します。

gcloud beta network-services service-lb-policies update SERVICE_LB_POLICY_NAME \
    --isolation-config-granularity=UNSPECIFIED \
    --isolation-config-mode=UNSPECIFIED \
    --location=global

ポリシーを削除する

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

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

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

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

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

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

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

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

トラブルシューティング

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

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

このセクションでは、このような機能をオンにしたときに発生する可能性のある、一般的なシナリオをいくつか説明します。

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

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

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

自動容量ドレイン

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

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

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

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

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

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

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

優先バックエンド

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

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

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

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

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

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

トラフィック分離

クロスリージョン内部ロードバランサに送信されたリクエストが失敗する

STRICT 分離モードが有効になっており、ロードバランサと同じリージョンにバックエンドが構成されていない場合、トラフィックは失敗します。これが意図した動作でない場合は、トラフィックが送信されるリージョンにバックエンドを構成するようにします。または、分離モードを NEAREST に設定して、トラフィックを次に近いリージョンにルーティングする方法もあります。

トラフィックがリモート リージョンから近いリージョンにルーティングされる

リクエストの分離は容量ベースのトラフィック オーバーフローを防止します。そのため、この機能を有効にする前にバックエンドがすでに過負荷になっていた場合、トラフィックはすでにリモート リージョンに送信されていた可能性があります。このような場合にこの機能をオンにすると、このトラフィックが最も近いリージョンに再度ルーティングされることがあります。

トラフィック分離を有効にした後、トラフィックが再度ルーティングされなかった

リクエストの分離は容量ベースのトラフィック オーバーフローを防止します。そのため、この機能を有効にする前に最も近くのリージョンのバックエンドが過負荷になっていなかった場合、最も近くのリージョンがすべてのトラフィックを処理できる可能性は高いです。その場合、短期的にはトラフィックのルーティングは変更されないと想定されます。これはトラフィック量の変化に伴い変わる可能性があります。

リージョンにバックエンドを追加または削除するとトラフィックが移動する

ロードバランサがトラフィックをルーティングしてネットワークの全体的なレイテンシを最適化しようとすることによる、想定内の動作です。新しいバックエンドが近くのリージョンにデプロイされると、ロードバランサはそのリージョンにより多くのトラフィックを送信する可能性があります。同様に、バックエンドが削除されると、リクエストの分離設定に応じて、ロードバランサはオーバーフロー トラフィックを遠く離れたリージョンに送信するようになります。

制限事項

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