高度なロード バランシングの概要
高度なロード バランシングは、可用性、パフォーマンス、コスト効率の目標を達成するために、グローバル ロード バランシングとトラフィック分散を微調整できる機能で構成されています。このドキュメントは、Cloud Service Mesh とロード バランシングのコンセプトをある程度理解している中級のユーザーを対象としています。
高度なロード バランシングを実装するには、バックエンドの選択に影響を与える値を含むサービス ロード バランシング ポリシー（serviceLbPolicies リソース）を作成します。次に、サービス ロード バランシング ポリシーをバックエンド サービスに接続します。サービス ロード バランシング ポリシーでは、バックエンドとトラフィックの分散方法を決定するアルゴリズムを指定します。
高度なロード バランシングのアルゴリズムは、次のオプションから選択できます。
- リージョンごとのウォーターフォール（デフォルトのアルゴリズム）
- リージョンへのスプレー
- 世界中へのスプレー
- ゾーンごとのウォーターフォール
次の追加オプションが利用可能です。
- 優先バックエンドを指定する。Cloud Service Mesh は、他のバックエンドにトラフィックを送信する前に、これらの MIG または NEG にトラフィックを送信します。
- 自動容量ドレインを設定する。
- フェイルオーバーの動作をカスタマイズする。
高度なロード バランシング オプションを構成する前に、バックエンド サービス リソースのドキュメントをお読みください。
Cloud Service Mesh によるトラフィックのルーティングとロード バランシングの方法
次の図は、Cloud Service Mesh がトラフィックのルーティングを決定する方法を示しています。
まず、Cloud Service Mesh は、デプロイで使用する API に応じて、リクエストの特性、Route リソースまたは URL マップのルーティング ルールに基づいて、バックエンド サービスを選択します。
次に、Cloud Service Mesh は、クライアントのロケーション、MIG または NEG のロケーション、健全性、容量およびバックエンド サービスに関連付けられたサービス ロード バランシング ポリシーの情報に基づいて、バックエンド サービスに関連付けられたバックエンド MIG または NEG を選択します。
最後に、Cloud Service Mesh は、MIG または NEG 内のインスタンスまたはエンドポイントを選択します。この選択は、バックエンド サービスの地域によるロード バランシング ポリシーの情報に基づいています。
サポートされているバックエンドとサポートされていないバックエンド
高度なロード バランシングでは、次のバックエンド タイプがサポートされています。
- 非マネージド インスタンス グループ
- マネージド インスタンス グループ（MIG）
- ゾーン ネットワーク エンドポイント グループ（GCE_VM_IP_PORT NEG）
- ハイブリッド接続ネットワーク エンドポイント グループ（NON_GCP_PRIVATE_IP_PORT NEG）
次のバックエンド タイプは、高度なロード バランシングではサポートされていません。
- リージョン マネージド インスタンス グループ
- インターネット ネットワーク エンドポイント グループ（INTERNET_FQDN_PORT NEG）
ユースケース
以降のセクションでは、各アルゴリズムの仕組みと、特定のビジネスニーズに合わせて選択するアルゴリズムについて説明します。
リージョン内のバックエンド間でトラフィックを分散する
デフォルトのロード バランシング アルゴリズム（リージョンごとのウォーターフォール）では、リージョンのゾーン内のすべての MIG または NEG にトラフィックが均等に分散されます。特別な要件がない限り、デフォルトのアルゴリズムを使用することをおすすめします。
リージョンごとのウォーターフォールでは、バックエンドは容量に比例してトラフィックを受信し、バックエンドを過負荷から保護します。リージョン内のバックエンドが均等に読み込まれるように、必要に応じてゾーン境界を越えてトラフィックが送信されます。クライアントのローカルゾーンに残りの容量があっても、ゾーン間トラフィックが発生します。各クライアントのリクエストは、リージョン内の複数のゾーン MIG または NEG に分散できます。これにより、クライアントからのトラフィックの負荷が均一でないときに、MIG または NEG の負荷を均一に保つことができます。
クライアントからのトラフィックを複数のゾーンに分散して復元性を向上
リージョンごとのデフォルトのウォーターフォール アルゴリズムでは、複数のゾーン MIG または NEG 間で容量使用量のバランスがとれるようになっています。ただし、そのアルゴリズムでは、単一のクライアントから送信されるリクエストがすべてのゾーンに一貫して送信されるわけではありません。1 つのクライアントからのリクエストは通常、単一のゾーンの MIG または NEG に転送されます。
クライアントがリージョン内のすべての MIG または NEG にリクエストを分散させる場合は、スプレー リージョン アルゴリズムを使用します。これにより、トラフィック量が局所的に急激に増加した場合に、単一のゾーンに MIG または NEG が過負荷になるリスクが軽減されます。
「リージョンへのスプレー」アルゴリズムでは、A と B の 2 つのゾーンがあり、ゾーン B でトラフィックが急増した場合、トラフィックは 2 つのゾーンに分割されます。デフォルトのアルゴリズムでは、ゾーン B の急増に応じて Cloud Service Mesh が変更に対応する前にゾーンの過負荷がトリガーされる可能性があります。
「リージョンへのスプレー」アルゴリズムを使用する場合、各クライアントのトラフィックは常にリージョン内のバックエンド ゾーンに分散されます。その結果、ローカルゾーンに容量が残っていても、ゾーン間のトラフィックが一貫して増加します。また、2 つの Cloud Service Mesh クライアントが送信している場合は、Cloud Service Mesh からのトラフィックの影響を受ける領域が広がる可能性があります。
クライアントからのトラフィックを複数のリージョンのすべてのバックエンドに分散
前のセクションで説明したように、「リージョンへのスプレー」アルゴリズムは、各クライアントからのトラフィックをリージョン内のすべてのゾーンに分散します。複数のリージョンに MIG または NEG があるサービスでも、Cloud Service Mesh は最も近いリージョンにトラフィックを送信して、全体的なレイテンシを最適化します。
スプレーの半径を大きくしたい場合は、「世界中へのスプレー」アルゴリズムを使用します。このアルゴリズムでは、クライアントは複数のリージョンにまたがるすべての MIG または NEG にリクエストを分散します。
このアルゴリズムでは、すべてのトラフィックがすべてのバックエンドにグローバルに分散されることに注意してください。クエリに欠陥があると、デプロイ内のすべてのバックエンドが損傷する可能性があります。また、このアルゴリズムによりリージョン間のトラフィックが増えるため、リクエストのレイテンシが増加し、費用が増加する可能性があります。
ゾーン間のトラフィックを最小限に抑える
ゾーンごとのウォーターフォール設定を使用すると、全体的なレイテンシを最適化し、ゾーン間のトラフィックを減らすことができます。ゾーンに複数の MIG または NEG が構成されている場合、クライアント トラフィックはゾーン内の最も近い MIG または NEG にルーティングされ、ゾーン内のすべての MIG または NEG の容量が使用されるまで、ゾーン内の次の MIG または NEG にトラフィックが送信されます。この場合にのみ、トラフィックは次に最も近いゾーンにオーバーフローします。
このアルゴリズムでは、不要なゾーン間のトラフィックを最小限に抑えることができます。最も近いローカル バックエンドが優先されるため、全体的なレイテンシが若干改善される場合があります。ただし、リージョン内の MIG または NEG 間で不均一なトラフィックが作成される可能性もあります。
ロード バランシング アルゴリズムの比較
次の表に、4 つの Cloud Service Mesh ロード バランシング アルゴリズムの詳細な比較を示します。
| 動作 | リージョンごとのウォーターフォール | リージョンへのスプレー | 世界中へのスプレー | ゾーンごとのウォーターフォール |
|---|---|---|---|---|
| 安定した状態にあるリージョン内での容量使用量を均一にする | はい | はい | はい | いいえ |
| 安定した状態の複数のリージョンで容量使用量を均一にする | いいえ | いいえ | はい | いいえ |
| 安定した状態のリージョン内で均一なトラフィック分割 | いいえ | はい | はい | いいえ |
| ゾーン間トラフィック | はい。このアルゴリズムは、ネットワーク レイテンシを最適化しながら、リージョン内のゾーンにトラフィックを均等に分散します。トラフィックは、必要に応じてゾーン間で送信されます。 | はい | はい | はい。トラフィックは最も近いゾーンに送信され、その容量に達すると次のゾーンに進みます。 |
| ローカルゾーン トラフィックの急増に対する感度 | 平均的（ゾーン間で分散されているトラフィックの量によって変わるため）。 | 低い。単一ゾーンの急増がリージョン内のすべてのゾーンに分散されるためです。 | 低め（単一ゾーンでの急増により、すべてのリージョンに分散するため）。 | 高め（単一ゾーンの急増により、Cloud Service Mesh が対応できるようになるまで、そのゾーンですべて処理される可能性が高いため）。 |
その他の高度なロード バランシング オプション
以降のセクションでは、Cloud Service Mesh のロード バランシングを変更するオプションについて説明します。
優先バックエンド
バックエンド サービスのバックエンド グループを優先するようにロード バランシングを構成できます。これらのバックエンドが完全に使用されてから、残りのバックエンドにリクエストがルーティングされます。Cloud Service Mesh は、クライアント トラフィックをまず優先バックエンドに分散し、クライアントのリクエストのレイテンシを最小限に抑えます。
優先バックエンドの構成容量を超えるトラフィックは、優先以外のバックエンドにルーティングされます。ロード バランシング アルゴリズムは、優先以外のバックエンド間でトラフィックを分散します。
ユースケースの 1 つとして Google Cloud へのオーバーフローがあります。この場合、ハイブリッド接続 NEG で表されるオンプレミス コンピューティング リソースが完全に使用しようされてから、自動スケーリングされた Google Cloud バックエンド MIG または NEG にリクエストがルーティングされます。この構成により、Google Cloud のコンピューティング リソースの消費を最小限に抑えながら、必要に応じて徐々に Google Cloud にオーバーフローまたはフェイルオーバーすることで復元性を維持できます。
自動容量ドレイン
通常、正常でないバックエンドは、できるだけ早くロード バランシングの対象から除外する必要があります。バックエンドを除外すると、正常でないバックエンドにはリクエストが送信されなくなります。トラフィックは正常なバックエンド間で分散されるため、バックエンドの過負荷を防ぎ、全体的なレイテンシを最適化できます。
このオプションは、capacityscalar を 0 に設定する場合と同様です。この場合、ヘルスチェックに合格した個々のインスタンスまたはエンドポイントが 25% 未満のときに、Cloud Service Mesh はバックエンド容量を自動的にゼロにスケールダウンします。このオプションを使用すると、正常でないバックエンドがグローバル ロード バランシングから除外されます。
自動ドレインされたバックエンドが正常な状態に戻った場合、エンドポイントまたはインスタンスの 35% 以上が 60 秒間正常な状態であれば、ドレインが解除されます。バックエンドのヘルス ステータスに関係なく、Cloud Service Mesh は、バックエンド サービスのエンドポイントの 50% を超えてドレインすることはありません。
ユースケースの 1 つとして、優先バックエンドで自動容量ドレインを使用することもできます。優先されるバックエンド MIG または NEG に含まれるエンドポイントの多くが正常でない場合、この設定により、トラフィックを MIG または NEG からシフトし、MIG または NEG の残りのエンドポイントを保護することができます。
フェイルオーバーの動作をカスタマイズする
通常、Cloud Service Mesh は、いくつかの要素を考慮してトラフィックをバックエンドに送信します。安定状態では、Cloud Service Mesh は前述のアルゴリズムに基づいて選択されたバックエンドにトラフィックを送信します。選択したバックエンドは、レイテンシと容量使用率の観点から最適と見なされます。これらは、プライマリ バックエンドと呼ばれます。
Cloud Service Mesh では、プライマリ バックエンドが正常でなく、トラフィックを受信できない場合に使用するバックエンドも追跡します。これらのバックエンドは、フェイルオーバー バックエンドと呼ばれます。通常、これは、容量が残っている近くのバックエンドです。
バックエンドが異常な状態の場合、Cloud Service Mesh はそのバックエンドへのトラフィックの送信を避け、正常なバックエンドにトラフィックを転送します。
serviceLbPolicy リソースには、failoverHealthThreshold というフィールドがあり、その値をカスタマイズしてフェイルオーバーの動作を制御できます。設定したしきい値によって、プライマリ バックエンドからフェイルオーバー バックエンドにトラフィックが切り替わるタイミングが決まります。
プライマリ バックエンドの一部のエンドポイントが異常な状態である場合、Cloud Service Mesh は必ずしもトラフィックを直ちに切り替えるとは限りません。代わりに、Cloud Service Mesh はトラフィックを安定させるため、プライマリ バックエンドの正常なエンドポイントにトラフィックを切り替えることがあります。
バックエンドで多くのエンドポイントが異常な状態になると、残りのエンドポイントで追加のトラフィックを処理できなくなります。この場合、障害しきい値を使用して、フェイルオーバーをトリガーするかどうかが決定されます。Cloud Service Mesh は、しきい値まで異常な状態を許容し、その後、トラフィックの一部をプライマリ バックエンドからフェイルオーバー バックエンドに切り替えます。
フェイルオーバーの健全性のしきい値は、パーセンテージ値です。設定した値によって、Cloud Service Mesh がフェイルオーバー バックエンドにトラフィックを転送するタイミングが決まります。値は 1～99 の整数を設定できます。Cloud Service Mesh のデフォルト値は、Envoy の場合は 70、プロキシレス gRPC の場合は 50 です。値が大きいほど、トラフィック フェイルオーバーが開始されるタイミングが早くなります。
トラブルシューティング
トラフィック分散パターンは、バックエンド サービスで新しい serviceLbPolicy を設定する方法に応じて変わる可能性があります。
トラフィックの問題をデバッグするには、既存のモニタリング システムを使用して、バックエンドへのトラフィックのフローを調べます。Cloud Service Mesh とネットワークの追加の指標は、ロード バランシングの決定方法の把握に役立ちます。このセクションでは、一般的なトラブルシューティングと緩和策について説明します。
Cloud Service Mesh は、構成した容量未満でバックエンドの実行を継続できるようにトラフィックの割り当てを行いますが、この動作は保証されるものではありません。詳しくは、バックエンド サービスのドキュメントをご覧ください。
その後、使用するアルゴリズムに基づいてトラフィックを割り当てます。たとえば、WATERFALL_BY_ZONE のアルゴリズムでは、Cloud Service Mesh は最も近いゾーンにトラフィックを転送しようとします。ネットワーク指標を確認すると、Cloud Service Mesh は、リクエストの送信時に RTT レイテンシが最も小さいバックエンドを優先し、RTT レイテンシ全体の最適化を行っていることがわかります。
以降のセクションでは、サービス ロード バランシング ポリシーと優先バックエンドの設定で発生する可能性のある問題について説明します。
トラフィックが近くのバックエンドではなく、遠く離れた MIG または NEG に送信されている
優先バックエンドがより遠く離れた MIG または NEG で構成されている場合、これは想定内の動作です。この動作が望ましくない場合は、優先バックエンドのフィールド値を変更します。
正常でないエンドポイントが多い MIG または NEG にトラフィックが送信されていない
autoCapacityDrain が構成されているために MIG または NEG がドレインされている場合、これは想定内の動作です。この設定を使用すると、正常でないエンドポイントが多い MIG または NEG がロード バランシングの対象から除外されます。この動作が望ましくない場合は、autoCapacityDrain 設定を無効にできます。ただし、正常でないエンドポイントが多い MIG または NEG にトラフィックが送信されると、リクエストがエラーで失敗する可能性があります。
MIG または NEG が優先されているときに、一部の MIG または NEG にトラフィックが送信されない
優先として構成された MIG または NEG が容量に達していない場合、これは想定内の動作です。
優先バックエンドが構成されていて、容量の上限に達していない場合、トラフィックは他の MIG または NEG に送信されません。これらのバックエンドへの RTT レイテンシに基づいて、優先 MIG または NEG が最初に割り当てられます。
トラフィックを別の場所に送信する場合は、優先バックエンドなしでバックエンド サービスを構成するか、優先 MIG または NEG の容量の設定を控えめに構成します。
1 つの送信元から多くの MIG または NEG にトラフィックが送信されている
スプレー ツー リージョンまたはスプレー ツー ワールドを使用した場合の動作です。ただし、トラフィックを広範囲に分散させることで問題が発生する可能性があります。たとえば、バックエンドが広範囲のクライアントからトラフィックを認識すると、キャッシュ ヒット率が低下することがあります。この場合は、リージョンごとのウォーターフォールなど、他のアルゴリズムの使用を検討してください。
バックエンドの健全性が変化すると、トラフィックがリモート クラスタに送信される
failoverHealthThreshold を高い値に設定している場合、これは想定された動作です。健全性が一時的に変化するときにトラフィックをプライマリ バックエンドにとどまらせる場合は、failoverHealthThreshold を低い値に設定します。
一部のエンドポイントが異常な場合、正常なエンドポイントが過負荷になる
failoverHealthThreshold を低い値に設定している場合、これは想定された動作です。一部のエンドポイントが異常な場合、それらの正常でないエンドポイントのトラフィックが同じ MIG または NEG の残りのエンドポイントに分散されることがあります。フェイルオーバー動作を早期にトリガーするには、failoverHealthThreshold を高い値に設定します。
制限事項と考慮事項
高度なロード バランシングを構成する際に注意すべき制限事項と考慮事項は次のとおりです。
ゾーンごとのウォーターフォール
透過的なメンテナンス イベントの進行中に、ローカルゾーン外でトラフィックが一時的に分散される可能性があります。
これは、一部の MIG または NEG が容量に達していて、同じリージョン内の他の MIG または NEG が十分に活用されていないケースを想定しています。
サービスに対するトラフィックの送信元がエンドポイントと同じゾーンにある場合は、ゾーン間のトラフィックが減少します。
ゾーン仮想化などで、1 つのゾーンが Google データセンター内にある物理ハードウェアの異なるクラスタにマッピングされることがあります。この場合、同じゾーン内の VM は均等に読み込まれない可能性があります。一般に、全体的なレイテンシは最適化されます。
リージョンへのスプレー
通常、1 つの MIG または NEG のエンドポイントが停止すると、影響を受けるクライアントの数は多くなります。影響を受けるメッシュ クライアントの数は多くなりますが、影響はそれほど大きくありません。
クライアントがリージョン内のすべての MIG または NEG にリクエストを送信すると、ゾーン間のトラフィックの量が増加することがあります。
エンドポイントに対して開かれている接続数が増えると、リソース使用量が増加する可能性があります。
優先バックエンド
優先バックエンドとして構成された MIG または NEG がクライアントから遠く離れており、クライアントの平均レイテンシが高くなる可能性があります。これは、低レイテンシでクライアントにサービスを提供できる他の MIG または NEG がある場合にも発生することがあります。
グローバル ロード バランシング アルゴリズム（リージョンごとのウォーターフォール、リージョン間のウォーターフォール、ゾーンごとのウォーターフォール）は、優先バックエンドとして構成された MIG または NEG には適用されません。
自動容量ドレイン
ドレインされない MIG の最小数は、
serviceLbPoliciesを使用して構成した際の設定値とは異なります。デフォルトでは、ドレインされない MIG の最小数は 1 です。
serviceLbPoliciesが設定されている場合、ドレインされない MIG または NEG の最小割合は 50% です。どちらの構成でも、MIG または NEG で正常なインスタンスまたはエンドポイントの割合が 25% を下回っている場合、MIG または NEG は「異常」とマークされます。MIG または NEG のドレインを解除するには、インスタンスまたはエンドポイントの少なくとも 35% が正常な状態である必要があります。MIG または NEG でドレイン状態と非ドレイン状態の切り替えが頻繁に発生しないようにするため、このような設定が行われています。
ここにも、バランシング モードを使用しないバックエンドの容量スケーラーに対する同じ制限が適用されます。
次のステップ
- 設定手順については、高度なロード バランシングを設定するをご覧ください。