サーバー構成 / 500Req/Second の重要なパラメータ

サーバー構成 / 500Req/Second の重要なパラメータ

非常にトラフィックの多い Web サイトの nginx サーバーとして使用するサーバーを設定しています。多数の IP アドレスから同時にトラフィックを受信することが予想されます。少なくとも 2,000 万の一意の IP が接続し、500 リクエスト/秒を取得することが予想されます。

以前のサーバーで気づいた問題の 1 つは、iptables / ipconntrack に関連するものでした。私はこの動作については知りませんでしたが、サーバーから最大のパフォーマンスを引き出すために、ubuntu / debian (32/64) ビット マシンのどのパラメーターを調整すればよいかがわかれば幸いです。サーバーに大量の RAM を搭載することはできますが、ミッション クリティカルなタスクは応答時間です。理想的には、接続がハングしたり、タイムアウトしたり、待機したりしないようにし、全体的な応答時間をできるだけ短くしたいのです。

答え1

iptables は本当に必要ですか? 1 つのボックスからそれほどのパフォーマンスを得たい場合は、iptables を完全に削除することをお勧めします。nginx 以外のすべてのサービスを削除し、SSH を非公開インターフェイス (VPN、LAN など) でリッスンするように構成してマシンを慎重に構成すると、ファイアウォールなしでも済む可能性があります。そうすれば、少なくとも 1 つの問題は解消されます。

これをやろうとしていますか?1つウェブサーバーは 1 台、または複数台必要ですか? 単純な DNS ラウンドロビンでも、負荷を複数のマシンに分散できます。信頼性を確保するには、複数のサーバーが必要になります。

答え2

この質問はかなり広範囲にわたります。私からの最良のアドバイスは、一歩下がって、アプリケーションをどのように拡張するかについて考えることです。スケールアップ (いくつかの大きなサーバー) またはスケールアウト (多数の小さなサーバー)、あるいはその両方を行います。スケーリング戦略がわかれば、それに基づいて HA 戦略も設計できます。

サイトが立ち上がった瞬間にユニーク訪問者数が 2,000 万人に達するとは到底考えられません (参考までに言うと、そうなれば少なくともトップ 200 の Web サイトに入ることになります)。

トラフィックに合わせて拡張するための適切な計画を立て、サーバーの能力の限界まで稼働させず、スパイクに余裕を持たせ、トラフィックの増加に合わせて新しい機器を導入してください。

私たちは時々このような質問を受けます。将来のことを考えるのは良いことですが、最初から 2,000 万、6,000 万、1 億のユニーク ユーザーを処理できるインフラストラクチャを計画しないでください。そうすると、お金が無駄になり、インフラストラクチャの大部分がアイドル状態のままになります。

さて、あなたの質問にお答えすると、Stack Overflow では (現在) iptable を使用しており、フロントエンド ルーターで conntrack モジュールを問題なく実行しています。負荷がかかった状態で iptables/*conntrack* を実行するときに発生する問題の詳細を記載した新しい質問を投稿することをお勧めします。

そして最後に良い読書

S[OFU]/Stack Exchangeの運営方法
高いスケーラビリティのブログ

答え3

比較的小さな静的ファイルを提供するだけであれば、1 秒あたり 500 件のリクエストはそれほど多くありません。一方、ファイルが大きい場合や複雑な場合 (たとえば、セッションベースまたは DB 依存) は、かなりのワークロードになります。

このソリューションの前に Varnish のようなリバース プロキシを立ち上げ、malloc プールをキャッシュとして使用するように設定することを検討してください。適切に調整された VCL を使用すると、サイトのほとんどをメモリにバッファリングできるため、nginx は選択したいくつかのビットのみを提供するだけで済みます。また、ファイルシステムに noatime を設定することも忘れないでください。

関連情報