☰

構成

tag-icon • tag-icon google-cloud-platform load-balancing google-compute-engine google gcp
構成

私は地域インスタンスグループポート 8000 で 2 つのインスタンスが機能し、自動スケーリングは有効になっていません。

このインスタンスグループは、グローバル外部アプリケーション ロードバランサー。

インスタンス上の Web サーバーは Flask を実行しており、各リクエストの処理には 1 秒かかります。

@app.route("/", methods=["GET"])
def main() -> Response:
    sleep(1)
    response = jsonify(
        success=True,
        hostname=gethostname(),
    )
    response.status_code = 200
    response.headers["Access-Control-Allow-Origin"] = "*"
    return response

グローバル ロード バランサーのパブリック IP にアクセスして動作を確認できます。応答を取得するのに 1 秒かかります。

2 つのリクエストを同時に実行する場合、インスタンスが 2 つあるため、各リクエストが常に同じインスタンスに送信され、そのインスタンスでキューに入れられるのではなく、異なるインスタンスに送信されることを期待しています。

  • 1回のリクエストには1秒かかります
  • 他のリクエストには2秒かかります

を、、Locality load balancing policyに変更しようとしましたが、常に同じ動作になります。Round-RobinLeast-RequestRandom

私が正しく理解しているのは、Locality load balancing policyどのバックエンドが選択されるかについてだけですか? そうであれば、バックエンド (インスタンス グループなど) 内で負荷分散ポリシーをどのように構成しますか?

ありがとう

構成

インスタンスグループ

  • 地域
  • ターゲット分布形状: 均等
  • [x] インスタンスの再配布を許可する
  • 自動スケーリングオン: 最小 2、最大 2
  • 自動スケーリング信号: HTTP 負荷分散 100%
  • 初期化期間: 60秒
  • 健康診断：
    • パス: /health
    • プロトコル: HTTP
    • ポート: 8000
    • 間隔: 30秒
    • タイムアウト: 30 秒
    • 健康閾値: 1
    • 不健康な閾値: 10

ロードバランサー

  • フロントエンド：
    • プロトコル: HTTP
    • IP: xxxx
    • ネットワーク層: プレミアム
    • HTTP キープアライブ タイムアウト: 610 秒
  • ルーティングルール: すべて一致しない
  • バックエンドサービス:
    • エンドポイントプロトコル: HTTP
    • 名前付きポート: web
    • タイムアウト: 300秒
    • クラウド CDN: 無効
    • ログ記録: 有効 (サンプル レート: 1)
    • セッションアフィニティ: なし
    • 接続ドレインタイムアウト: 300 秒
    • トラフィックポリシー:
      • 局所的負荷分散ポリシー: ラウンドロビン
      • 外れ値検出: 無効
    • バックエンドセキュリティポリシー: なし
    • エッジセキュリティポリシー: なし
    • アイデンティティ認識プロキシ: 無効
  • バランスモード: 最大 RPS: 1 (インスタンスあたり)
  • 容量: 100%

テスト

siege \
    --concurrent 1 \
    --time 60s \
    "http://x.x.x.x"

2 つのノードの場合:

  • concurrent=1: 平均 1.02 秒
  • concurrent=2: 平均 1.66 秒
  • concurrent=4: 平均 3.35 秒
  • concurrent=8: 平均 5.54 秒

4 つのノードの場合:

  • concurrent=1: 平均 1.02 秒
  • concurrent=2: 平均 1.18 秒
  • concurrent=4: 平均 2.70 秒
  • concurrent=8: 平均 3.83 秒
  • concurrent=16: 平均 7.26 秒

8 ノードの場合:

  • concurrent=2: 平均 1.20 秒
  • concurrent=4: 平均 1.85 秒
  • concurrent=16: 平均 4.40 秒
  • concurrent=64: 平均 14.06 秒
  • concurrent=128: 平均 19.04 秒

期待される行動

次のような結果になると想定します。

  • 2 ノード:
    • concurrent=1： 1秒
    • concurrent=2： 1秒
    • concurrent=4: 約2秒
    • concurrent=8: 約4秒
  • 4 ノード:
    • concurrent=1： 1秒
    • concurrent=2： 1秒
    • concurrent=4： 1秒
    • concurrent=8: 約2秒
    • concurrent=16: 約4秒

アップデート1

に切り替えてClassic proxy network load balancer100 件のリクエストを送信すると、次のようになります。

  • 56 vm0へ移動
  • 44 VM1へ移動

HTTP LB の代わりに:

  • 99 vm0へ移動
  • 1 vm1へ移動

答え1

に基づくグローバル外部アプリケーション ロード バランサGFE (Google Front End) は、どのバックエンド インスタンスにリクエストを受信する容量があるかを推定します。共有されたリンクをスキャンすると、トラフィックの分布について詳しく知ることができます。

ラウンドロビンがうまく機能しないと思われる場合は、バランスモードここでの概念または構成は、トラフィックを均等に分散することです。

これも見つけたリンクバランスモードの使用に役立つ可能性がある、stackoverflow からの質問。

関連情報