いつ使用すべきか、いつ使用すべきかについての提案はありroundrobinますleastconnか？

私はroundrobin現在使用しており、バックエンドサーバーの負荷が均等に分散されていないことを確認しました。もちろん他の問題もあるかもしれませんがleastconn、試してみたいと思いますが、ミッションクリティカルなサーバーなので、変更する前に他の経験を参考にしたいと思います。

共有するアイデアはありますか？

leastconnで実験したことはありませんが、理解しているのは、leastconnの一般的な使用例は、存続時間が長い可能性のあるものをロードバランシングする場合です。これは、ロードロビンがよりバランスのとれた到着率を提供するようにバランスの取れた並行性を確保することに最少の焦点が焦点を当てているためです。この区別が明確でない場合は、違いについての私の回答を参照してください。

負荷が均等に分散されていないと言うときは、「負荷」をもう少しよく定義すると役立つ場合があります。サーバーリソースの場合は、負荷の増加（特定の種類の接続）の原因を正確に特定し、そこから逆方向に作業することをお勧めします。

それは、プロトコルとバランスをとるユースケースに依存します。接続の量が負荷/使用量と相関している場合は、を使用することをお勧めしますleastconn。ネットワークとアプリケーションの動作方法のため、ほとんどの場合それは真実でありleastconn、デフォルトで使用する方がよいでしょう。

RDP / X11リモートデスクトップ/ Jump Hosts

たとえば、企業には、従業員が接続するリモートデスクトップのプールがあります。従業員がデスクトップ全体にいくらか均等に分散されるようにします。

そのユースケースでアクティブな接続の数は、おおよそ「現在何人の従業員がそのデスクトップを使用しているか」です。接続数が最も少ないホストは、使用している従業員が最も少なく、おそらく負荷が最も少ないホストです。このような状況では「leastconn」を使用すると、ユーザーの量に応じて負荷が均等に分散されます。

理想的なロードバランサーは、リモートデスクトップの負荷を認識している必要があります。ユーザー数は？アプリケーションの数は？どのくらいのメモリとCPUが消費されましたか？リモートデスクトップ専用の商用ソリューション（Microsoft / Citrixなど）があり、これらは通常、これらのメトリックを測定して使用率を非常によく分散させます。HAProxyはシンプルなネットワークロードバランサーであり、を使用して接続数を数えるよりも優れた方法はありませんleastconn。

HTTP / HTTPS

HTTPでは、アクティブな接続とは、サーバーが要求の処理でビジーであることを意味します。接続は負荷に正比例します。アクティブな接続（進行中の要求）の数が最も少ないサーバーを選択します。leastconnHTTP（S）トラフィックに使用します。

2つのHTTPサーバーがあり、1つのサーバーが要求の処理が遅いシナリオを想像してみてください（おそらく過負荷であるか、古いハードウェアである可能性があります）。

roundrobin2つのサーバー間で要求の半分を分散します。これは非常に非効率的であり、高速なサーバーほど多くの時間がかかります。さらに悪いことに、遅いサーバーは過負荷になる可能性があり、より多くのリクエストが入ってくるとさらに遅くなり、いつでもリクエストをドロップし始める可能性があります。あなたはそれを望まない。

leastconnサーバーが不均一であることを検出します。遅いサーバーは接続を長く保持し、接続数が多くなります。leastconnそのため、他のサーバーを優先します。

私の経験では、中規模から大規模のWebサイトのパフォーマンステストのみを行っていた役割も含まれます。HTTP（S）の場合とleastconn同じように300％効率的roundrobinです。roundrobin接続を公平に分散しないため、高負荷時に不安定になります。

DNSリクエスト

（HAProxyはUDPをサポートしておらず、UDPはコネクションレスであることを無視しましょう）。

最後の例です。DNSは単純なプロトコルです。クライアントは単一のUDPメッセージを送信してドメインを要求し、DNSサーバーは単一のメッセージで応答します。

この場合、実際の接続はありません。あったとしても、それは即座に（理論的には）閉じられます。

このような状況で接続をカウントしても意味がありませんleastconn。には最適ではありません。シンプルでroundrobinメッセージを配信できます。

よくある誤解

人々は時々leastconn、（最後の例と同様に）短期間の接続に使用すべきではないと信じています。HAProxyのドキュメントでさえ誤解を招きます。

leastconn
          Use of this algorithm is recommended where very long sessions are
          expected, such as LDAP, SQL, TSE, etc... but is not very well
          suited for protocols using short sessions such as HTTP.
          [misleading advice, should ignore it]

現実の世界でshort connectionsは、事はありません。

アプリケーションはTCPの上に構築されます。メッセージは配信され、多くの場合、順番に処理されます。サーバーが低速または過負荷の場合、「短い」接続が長くなります。（より多くの）接続がある場合は、おそらく（より多くの）作業が行われています。接続数と接続時間はさまざまであり、意味があります。

基本的なHTTPサーバーについて考えてみましょう。一部のアセットは数ミリ秒かかり、一部のAPI呼び出しは数秒かかります。ページ内の要求の量に応じてページが読み込まれるまでに時間がかかる場合があります。leastconn進行中のアクティビティを理解し、ロードバランサーに必要な分散を調整します。