8 コアのサーバーをプロビジョニングし、ネットワーク サービスを展開する予定です。リクエストの負荷を分散するために、サービスのインスタンスを 8 つ実行したいと思います。驚くようなことはありません。ハードウェア ロード バランサーにアクセスできません。現在 5 つのパブリック IP アドレスを割り当てていることを述べておきます (ただし、さらに取得できます)。
したがって、ソフトウェア負荷分散ソリューションの構築に関する推奨事項をお聞かせください。
明らかな選択肢は次のいずれかです。
- HAProxyを使用するか、
- アプリケーションを事前にフォークする（Facebook Tornado と Unicorn の両方が行っているように）。
- ここにあなたのアイデアを入力してください。
私の目標は次のとおりです。
- サービスインスタンス間でリクエスト負荷を分散する。
- サービスのローリング再起動（コードアップグレード）を許可します。
なお、これは HTTP ベースのサービスではないため、NGiNX などは利用できません。
HAProxy はメモリ要件が厳しいので好きではありません。クライアント接続ごとに読み取りおよび書き込みバッファが必要なようです。したがって、カーネル レベル、HAProxy、およびアプリケーションにバッファが必要です。これは馬鹿げています。この点で何か見落としているのでしょうか?
ありがとう！
答え1
どのようなソリューションでも、ストリーム データを転送するプロセスをインストールする場合は、接続ごとにバッファーが必要になります。これは、受信したすべてを常に送信できるとは限らないため、バッファーに超過分を保持する必要があるためです。ただし、メモリ使用量は同時接続数によって異なります。ある大規模なサイトでは、150000 同時接続 (4 GB RAM) のデフォルト設定で haproxy を問題なく実行しています。それ以上必要な場合は、バージョン 1.4 では再コンパイルせずにバッファー サイズを調整できます。ただし、ソケットごとのカーネル バッファーは方向ごとおよびソケットごとに 4kB を下回ることはなく、接続ごとに少なくとも 16 kB になることに注意してください。つまり、haproxy をバッファーあたり 8 kB 未満で実行しても意味がありません。これは、すでにカーネルよりも消費量が少ないためです。
また、サービスが純粋な TCP であり、プロキシに付加価値がない場合は、LVS などのネットワークベースのソリューションを検討してください。パケットを処理し、バッファを維持する必要がないため、ソケット バッファがいっぱいになるとパケットがドロップされるため、コストが大幅に削減され、サービスと同じマシンにインストールできます。
編集: Javierさん、OSに負荷分散を頼るプリフォークプロセスは、スケーラビリティが全くありません。OSは毎プロセスが接続を取得すると、そのうちの 1 つのプロセスだけが接続を取得し、他のすべてのプロセスは再びスリープ状態になります。マルチプロセス モードの Haproxy は、プロセスが 4 個程度の場合に最高のパフォーマンスを発揮します。プロセスが 8 個になると、パフォーマンスはすでに低下し始めます。Apache はこれに対して優れたトリックを使用しており、accept() の周りをロックして、受け入れを待つプロセスが 1 つだけになるようにします。ただし、これにより OS の負荷分散機能が無効になり、1000 プロセスと 2000 プロセスの間でスケーリングが停止します。いくつかのプロセスが起動するようにいくつかのロックの配列を使用する必要がありますが、そうしません。
答え2
サービスの詳細がわからないので、何とも言えませんが、一般的には、事前フォークをお勧めします。これは、実証済みのサーバー戦略です (トルネード/ユニコーンのファンサイトを読んで一部の人が考えるような、新しいトリックではありません)。
それ以外にも、いくつかのヒントがあります:
事前にフォークされた各プロセスは、最新の非
select戦略 (主に libevent) を使用して、膨大な数のクライアントを処理できます。コアとプロセス間の 1:1 関係が最適なパフォーマンスをもたらすことは非常にまれであり、通常は負荷に対して動的な適応性を持たせる方がはるかに優れています。