増加するクライアントをサポートするために Web アプリケーション サーバーを追加し、負荷分散と高可用性のために HAproxy と Keepalived を導入する予定です。
私のサーバーの使用状況には次のような特徴があります。
- ジョブは CPU を集中的に使用しません。メッセージは 100 文字未満の JSON テキストです。
- ユーザーはクライアントデバイスYを介してサーバーにメッセージを送信します。通常、1日あたり4〜5件のメッセージです。
- クライアント デバイス X はサーバーからのメッセージを待機し続けます。メッセージがサーバーで利用可能な場合、クライアント デバイス X は 2 秒以内にそれを取得できる必要があります。それ以外の場合、このメッセージは古くなっています。
このため、
- Xが使用しているクライアントデバイスロングポーリングHTTP接続応答できるようにするためです。各接続は 5 秒間続き、再接続されます。
- クライアントデバイスXとクライアントデバイスYは同じサーバーに接続されているため、XとYは簡単にメッセージを送信できます。
質問
サーバーに接続するクライアント デバイス X が 60,000 台を超える場合、ロード バランサーまたはルーターの TCP ポートが不足します。たとえば、20,000 人のユーザーにスケールアップする最適な方法は何ですか?
私のサーバーは、Tomcat と Java Servlet を使用して Ubuntu サーバー上で実行されています。
答え1
60,000 のクライアントが実際の問題だとは思いません。ファイル記述子が足りないことが問題である可能性が高いですが、これは OS 構成の一部として簡単に修正できるはずです。
接続が問題にならない理由は次のとおりです。各接続は、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、および宛先ポートによって特徴付けられます。ネットワーク スタック内では、この 4 つの要素を使用してパケットをファイル記述子に一致させます (各ファイル記述子は接続を表します)。サーバーの宛先 IP アドレスと宛先ポートは固定されています (サーバーはクライアントの宛先です) が、送信元 IP アドレスと送信元ポートは可変です。ポートは 16 ビットの数値であるため、1 つのクライアントからの最大接続数は 64K です。IPv4 アドレスは 32 ビットの数値であるため、4,294,967,296 個の送信元アドレスが可能です。基本的な計算を行うと、サーバーには 64K * 4,294,967,296 個の接続が 1 つの送信元 IP とポートにマップされている可能性があります。
このため、クライアント数よりも、開いているファイル記述子の最大数で問題が発生する可能性が高くなります。
答え2
最も単純なアプローチは、DNS レベルで負荷分散を実装することです。
意味: 2 つ、3 つ、またはそれ以上の物理ロードバランサーにバランスをとるラウンドロビン DNS エントリを用意します。