HAプロキシ-ラウンドロビンと最小接続
roundrobinをいつ使用すべきか、leastconnをいつ使用すべきかについての提案はありますか？
現在roundrobinを使用していますが、バックエンドサーバーの負荷が均等に分散されていないことがわかりました。もちろん他の問題があるかもしれませんが、leastconnを試してみたいと思いますが、これはミッションクリティカルなサーバーなので、変更を加える前に他の経験を参考にしたいと思います。
共有するアイデアはありますか？
Leastconnを使った実験はしていませんが、理解しているのは、leastconnの一般的な使用例は、存続期間の長い接続をロードバランシングする場合です。この理由は、ロードロビンがよりバランスの取れた到着率を提供するように、バランスの取れた並行性を確保することにleastconnが焦点を当てているためです。この区別が明確でない場合は、 違いについての私の答えを参照してください 。
負荷が均等に分散されていないと言うときは、「負荷」をもう少しよく定義すると役立つ場合があります。サーバーリソースの場合は、負荷の増加（特定の種類の接続など）の原因を正確に特定し、そこから逆方向に作業することをお勧めします。
それは、プロトコルと、バランスを取るユースケースによって異なります。接続の量が負荷/使用量と相関している場合は、leastconnを使用することをお勧めします。ネットワークとアプリケーションの動作方法により、ほとんどの場合それは真実であり、デフォルトでleastconnを使用する方がよいでしょう。
RDP/X11リモートデスクトップ/ Jump Hosts
たとえば、企業には、従業員が接続するリモートデスクトップのプールがあります。従業員がデスクトップ全体にいくらか均等に分散されるようにします。
そのユースケースでのアクティブな接続の数は、おおよそ「現在何人の従業員がそのデスクトップを使用しているか」です。接続数が最も少ないホストは、それを使用している従業員が最も少なく、おそらく負荷が最小です。このような状況では「leastconn」を使用すると、ユーザーの量に応じて負荷が均等に分散されます。
理想的なロードバランサーは、リモートデスクトップの負荷を認識している必要があります。ユーザー数は？アプリケーションの数は？どのくらいのメモリとCPUが消費されましたか？リモートデスクトップ専用の商用ソリューション（Microsoft/Citrix/etc ...など）があり、これらは通常、これらのメトリックを測定して使用率を非常によく分散させます。 HAProxyはシンプルなネットワークロードバランサーであり、leastconnを使用して接続をカウントするよりも優れた方法はありません。
HTTP/HTTPS
HTTPでは、アクティブな接続は、サーバーが要求の処理でビジーであることを意味します。接続は負荷に正比例します。アクティブな接続（進行中の要求）の数が最も少ないサーバーを選択します。 HTTP（S）トラフィックにはleastconnを使用します。
2つのHTTPサーバーがあり、1つのサーバーが要求の処理が遅いシナリオを想像してみてください（過負荷になっている、古いハードウェアが含まれている可能性があります）。
roundrobinは、2つのサーバー間で要求を半分ずつ分散します。それは非常に非効率的であり、より高速なサーバーではより多くの時間がかかるはずです。さらに悪いことに、遅いサーバーは過負荷になる可能性があり、より多くのリクエストが入ってくるとさらに遅くなり、いつでもリクエストをドロップし始める可能性があります。あなたはそれを望まない。
leastconnは、サーバーが不均一であることを検出します。低速のサーバーは接続を長く保持し、接続数が多くなります。 leastconnはそれを考慮し、他のサーバーを優先します。
私の経験では、中規模から大規模のWebサイトのパフォーマンステストのみを行っていた役割も含まれます。 leastconnは、HTTP（S）のroundrobinと比べて300％効率的です。 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は進行中のアクティビティを理解し、ロードバランサーに必要な分散を調整します。