Pleskウェブサーバ

NGINX ワーカー接続 – 数千件のリクエストに対応し、ホスティングパフォーマンスを最大化

nginxのワーカーを適切にスケーリングすることで、数千件の同時リクエストを低 レイテンシー を操作する。その鍵となるのは、worker_processes、worker_connections、ファイル記述子、および イベント.

中心点

定員 = worker_processes × worker_connections。リバースプロキシの場合、多くの場合、クライアント接続とアップストリーム接続によって決まる 2倍.
ファイル記述子 (worker_rlimit_nofile、ulimit) を、想定される接続負荷に合わせて設定する リフト.
イベント- epoll、multi_accept、およびカーネルバックログを使用したブロックでの高負荷時 トリミングする.
モニタリング stub_status および反復処理のための負荷テストを通じて カスタマイズ.
スケーリング 縦と横の組み合わせ、構成 デカップリング.

NGINXのアーキテクチャ：マスター、ワーカー、イベント

NGINXは、複数のワーカープロセスを起動し、それらを効率的に イベント を処理します。リクエストごとのスレッドではなく、各ワーカーはイベント駆動型モデルを通じて、低オーバーヘッドで多数の接続をノンブロッキング方式で処理します。 オーバーヘッド. `worker_processes` ディレクティブを `auto` に設定することで、NGINXがCPUコアを有効活用し、各ユニットに専用のワーカーが割り当てられるようにしています。これにより、着信接続をより適切に分散させ、ピーク時の負荷下でもレイテンシを抑えることができます。ロー. プロセスの計画についてさらに詳しく知りたい方は、以下をご参照ください。 Workerプロセスの最適化, 、というのも、適切な並列化によって実現可能な接続容量が決まるからです。重要なのは、各ワーカーに対する `worker_connections` を適切に設定し、プロセス数との乗算によって期待される ピーク負荷 をカバーする。.

処理能力の計算式：worker_processes × worker_connections

おおよその処理能力は、worker_processes × worker_connections で計算しますが、プロキシ経由のリクエストはユーザー1人あたりのアクセスにつき2つの接続を占有することが多いため、実際の数値は半分になります。鑵. 多くの標準的なインストールでは、ワーカー1人あたり512接続で開始されますが、本番環境のワークロードでは、これでは不十分な場合が多い でござる. 実用的な初期値は通常1024～4096の範囲であり、トラフィックの特性やハードウェアによって異なります。私は余裕を持たせるため、測定されたピーク負荷の少なくとも2倍を想定して計画し、バーストを確実に処理できるようにしています 緩和する. 数値が単なる理論上の遊びに終わらないよう、テストや実稼働時のメトリクスによる検証が依然として重要である になる.

シナリオ	ワーカープロセス	ワーカーコネクション	理論上の最大値.	実効（プロキシ）	ワーカー1人あたりのFD
小規模なサイト	2	1024	2048	~1024	1024以上
API 中程度の負荷	4	2048	8192	~4096	2048以上
ショップのピーク時間帯	8	4096	32768	~16384	4096以上

HTTP/1.1、HTTP/2、およびTLS：ワーカーとレイテンシへの影響

プロトコルによって接続のプロファイルが決まります。HTTP/1.1 では、クライアントごとに多数の同時 TCP 接続が見られることがよくありますが、HTTP/2 では、その数は少なくなりますが、その分、各ストリームの負荷が高くなります。 バンドル. 。これによりファイル記述子の使用数を削減できますが、その代わりにバッファや優先順位付けへの負荷が増加します。TLS では、コストのかかるハンドシェイクがリクエストごとに発生しないよう、セッションの再利用に注意を払っています 速度を落とす. 共有セッションキャッシュと適切なタイムアウト設定により、CPU使用率の急上昇を抑えることができます。また、長寿命の接続が持つ利点を十分に活かすため、keepalive_requests の値を低すぎないように設定しています。 遊び出す. HTTP/2 については、接続ごとに高い並行処理能力を見込み、メモリを消費することなく、十分な容量の送受信バッファを確保するようにしています。 無駄にする. トラフィックが混在している場合は、保守的な計画を立て、各プロトコルバリエーションごとの影響を テスト.

ファイルディスクリプタとulimitを正しく設定する

すべての接続には少なくとも1つのファイルディスクリプタが必要であり、リバースプロキシでは多くの場合2つ必要となるため、ulimitの値が低すぎると深刻な バウンダリー を設定する。私は、worker_processes × worker_connections が実現可能となり、ログ、ソケット、キャッシュのための余裕が確保されるように、worker_rlimit_nofile を引き上げます。システム全体では、limits.conf と fs.file-max を調整し、オペレーティングシステムが計画された数のオープンファイルを許可し、早期に ブレーキ. `ulimit -n` および Systemd パラメータ（LimitNOFILE）を用いて、設定が永続化され、NGINX に適合しているかどうかを確認しています。この調整項目を無視すると、`worker_connections` の値が高く設定されていても、突然接続が拒否されたり、 遅延時間.

イベントブロックの微調整：epoll、multi_accept、バックログ

Linuxでは、epollを使用しています。このメカニズムは、非同期処理によって多数の接続を効率的に処理できるためです。 イベント を処理します。multi_accept on を設定すると、1つのイベントにつき1つのワーカーが複数の新規接続を受け入れるようになり、これにより負荷のピークが平準化され、接続受け入れの遅延が下. net.core.somaxconn や net.ipv4.tcp_max_syn_backlog といったカーネルパラメータを適切に増やし、トラフィックが集中した際に Accept キューがオーバーフローしないようにしています。 tcp_tw_reuse などの TIME_WAIT 最適化により、ポートのボトルネックを軽減し、スループット曲線を安定させます。高い. 並行処理やキューに関するより詳細な背景情報については、以下の資料を参照するとよい。スレッドプール最適化, 、たとえNGINXが主にイベント駆動型で動作し、そのおかげで非常にリソース効率が良いとしても 倍率付き.

リストソケットの適切な割り当て：reuseport、backlog、accept_mutex

同時接続数が非常に多い場合、受信パスを動的に拡張しています。 レツレポート 各ワーカーには独自のリスニングソケットが割り当てられるため、Accept時の競合が解消され、負荷がすべてのコアに均等に分散される。短時間のトラフィック急増に対応するため、リスニングバックログを明示的に設定している。この設定では、accept_mutex はもはや必要ありません。一方、reuseport を使用しない場合、accept_mutex は 助ける, 、Accept における群集効果を抑制するため。重要：NGINX およびカーネル（somaxconn）のバックログサイズは、 咬み合う, 、そうしないと効果が失われてしまいます。.

events {
    use epoll;
    worker_connections 4096;
    # accept_mutex on;   # を reuseport と併用する場合、通常は不要
}

server {
    listen 443 ssl http2 reuseport backlog=65535;
    # ...
}

さらに、キャッシュラインやIRQの負荷を安定させるため、必要に応じてワーカーをCPUコアに割り当てています（worker_cpu_affinity）。NUMAの影響が強い環境では、これにより不要な 横断交通 メモリ内。.

リバースプロキシ、アップストリーム、およびキープアライブ

リバースプロキシとして動作するNGINXは、リクエストごとに通常2つの接続を維持します。1つはクライアントへの接続、もう1つはバックエンドへの接続であり、これにより現実的なキャパシティプランニングが可能になります。 ダブル 重要です。アップストリーム接続を再利用可能に保ち、リクエストごとのオーバーヘッドを減少. これにより、PHP-FPM、アプリケーションサーバー、またはマイクロサービスへの負荷を軽減し、新しいユーザーセッション用の空きスロットを確保できます。タイムアウト、アイドル時間、再利用のバランスによって、接続がどれだけスムーズに再利用されるかが決まります になる. これに関する基礎知識を知りたい方は、永続的な接続ネットワークの負荷状況やパフォーマンス向上に関する実践的なヒント使用方法.

アップストリームプール、タイムアウト、再試行

ワーカーが反応の遅いバックエンドを待たされることがないように、私はタイムアウトを短めに設定し、リトライの頻度を適切に調整しています。アップストリームのキープアライブプールは、接続が温存されるように十分な大きさに保ちつつ、非アクティブなファイルディスクリプタ（FD）がメモリやスロットを バインド. リトライは数回に限定し、明らかな転送エラーが発生した場合にのみ切り替えるようにしています。これにより、バックエンドの短時間の停止時に「サンダーリング・ハード」現象を防ぐことができます。.

upstream app_backend {
    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
    keepalive 64;  # の再利用可能なアップストリーム接続
}

server {
    location / {
 proxy_pass http://app_backend;
 proxy_connect_timeout   2s;
        proxy_read_timeout 15s;
 proxy_send_timeout 15s;
 proxy_next_upstream     error timeout http_502 http_503;
 proxy_next_upstream_tries 2;
    }
}

同時に、Keep-Aliveパラメータ（タイムアウト、接続あたりのリクエスト数）を調整し、ほとんどアクティブにならないクライアントのリソースを迅速に解放するようにしています。 公開する.

スケーリングを適切に計画する：垂直と水平の組み合わせ

トラフィック量が多い場合は、垂直スケーリングと水平スケーリングを組み合わせて考察. 垂直スケーリングについては、CPUコア数やRAMの増設、高速SSDの導入、ネットワーク構成の最適化を行い、すべてのワーカーがスムーズに動作するようにしています。 事業所. 水平方向のスケーリングには、ステートレスなNGINXノード、一元管理された設定、分散型ロギングを採用し、総容量が線形に成長. ローカルのキャッシュと、MapsやAPIを通じて明確に定義されたポリシーにより、変更を迅速に展開できます。この分離により、副作用が軽減され、各ノードで再構築を行うことなく、新しいトラフィックパターンを 操作する.

ホスティングの観点：遅延、エラー率、ユーザー体験

worker_connections の値が少なすぎると、接続の拒否、タイムアウト、およびパフォーマンスの低下につながります。 ユーザー・エクスペリエンス. CMSやオンラインショップなどの動的なアプリケーションでは、ページが呼び出されるたびに複数のバックエンドへのリクエストが発生し、スロットがより早く短いとなる。そのため、ワーカー1人あたり1024や2048といった控えめな値から始め、実際の測定値に基づいて段階的に増やしていく。並行して、アップストリームサービスのパフォーマンスを維持し、人為的な限界活用する。ベンチマークの結果から、入念に調整されたプラットフォームがここで真の利点をもたらし、ピーク時のトラフィックにも確実に インターセプト.

メモリ、バッファリング、およびI/Oパス

各接続は、メタデータやバッファ用にメモリを消費します。私は、典型的なリクエストが収まるように、かつ異常値によってRAMを過度に消費することのないよう、proxy_buffers、client_body_buffer_size、large_client_header_buffersのサイズを設定しています。 バインド. 静的コンテンツの場合、sendfile や tcp_nopush が配信を高速化する一方、レイテンシが重要な小さな応答には tcp_nodelay が重要のままです。アセットが低速なストレージ上に保存されている場合、aio threads と thread_pool を使用することで、ブロッキング効果を緩和できます。open_file_cache を使用すると、ファイルアクセスや stat() の呼び出しを減らすことができますが、追加のファイルディスクリプタ（FD）が必要になる点に注意してください。ログはバッファリングして書き込み（access_log … buffer=… flush=…）することで、I/Oのピークが応答時間に影響を与えないようにしています。 影響を与える.

セキュリティとTLSパフォーマンスのバランス

TLSハンドシェイクはCPU負荷が高い。私はセッションの再利用と適度な鍵パラメータを組み合わせ、運用上可能であれば、セッションキャッシュやチケットといった積み重ね可能な最適化機能を有効にしている。 フィット. セキュリティとパフォーマンスの最適なバランスにより、暗号化の品質を損なうことなく、レイテンシを安定させることができます。負荷が高くなった場合、TLSのピーク値が平均値に埋もれてしまうのを防ぐため、95パーセンタイルと99パーセンタイルを個別に監視しています。隠す. HTTP/2は接続数を軽減しますが、CPUやメモリの使用状況を適切に管理するためには、フロー制御やヘッダー圧縮に細心の注意を払う必要があります。 保持する.

過負荷下でのレジリエンス：限界と穏やかな切り捨て

レイテンシを維持するためには、的を絞った シェーピング ピーク負荷時には不可欠です。limit_conn を使用すると、キー（IP やセッションなど）ごとの同時接続数を制限でき、limit_req はバースト負荷を抑制し、バックエンドを同期的な 突進する. 重要なエンドポイントについては、静的アセットよりも厳しいルールで隔離しています。一時的に負荷がかかった場合、すべてのリクエストを一律に処理するのではなく、Retry-After を含む明確に定義された 429/503 レスポンスを返します。 餓死する 。長引く接続（lingering_close）は、リソースを制御的に解放し、Slowlorisパターンを 反駁する. このアクティブなシェディングにより、総需要が一時的に定格容量を上回った場合でも、p95/p99のレイテンシは許容範囲内に維持される嘘.

コンテナおよびシステム統合：制限が生じる場所でその制限を取り除く

コンテナ内では、より厳しい制限が課されることがよくあります。 cgroupのリミット（CPU、RAM）を確認し、コンテナ内でulimit -nを適切に設定し、LimitNOFILEをサービス定義に組み込みます。somaxconnやtcp_max_syn_backlogなどのsysctlパラメータは、 ホスト 有効になります。ただし、ネームスペースによってこれらの設定が常に透過的に隔離されるとは限りません。オーケストレーションされたプラットフォームでは、ポッド／ノードごとの容量を計画し、ワーカーを割り当てられたコアに固定し、安定したネットワークパス（例えば、不要なNATホップがないことなど）を確保することで、レイテンシ曲線が静かのままです。ローリングアップデート時には、既存の接続を正常に終了させるために worker_shutdown_timeout を設定しています。 終了する.

モニタリングと反復的な最適化

目に見えない限り、チューニングの手順は単なる リスク. stub_status またはその代替ツールを有効にして、アクティブな接続、受け入れ率、および拒否状況を継続的に監視しています。負荷テストでは、現実的なアクセスパターンをシミュレートし、Acceptキュー、アップストリームの遅延、あるいはCPUの飽和. 。その後、worker_connections、プロセス数、ファイル制限、TCPパラメータを慎重に調整し、その効果を再度確認します。このサイクルにより、プラットフォームの信頼性が維持され、不都合なタイミングで予期せぬ事態が発生するのを防ぎます。 タイムズ.

設定例と計算手順

ピーク時に2000件の同時インフライトリクエストが見込まれ、リバースプロキシを使用する場合、大まかに4000の接続スロットに加え、 バッファ. NGINXを4つのCPUコアで実行する場合、私は通常、worker_processesをautoに設定し、各ワーカーあたりのworker_connectionsを1000～2000に設定します。ファイルディスクリプタの制限は、各ワーカーごとに、接続、ログ、内部ソケットが十分に処理できるよう、十分に高い値に設定します。場所。イベントブロックをepollに設定し、multi_acceptを有効にし、ピークトラフィックに合わせてカーネルのバックログを増やします。最小限のコード例は以下のようになります。その後、ベンチマークを用いて微調整を行います。投票:

worker_processes  auto;
worker_rlimit_nofile  65535;

events {
    use epoll;
    worker_connections  2048;
    multi_accept on;
}

http {
    keepalive_timeout   65;
    sendfile on;
    # その他のプロキシ／キャッシュオプション ...
}

さらに、負荷がかかった状態での受け入れ処理とバックエンドパスを最適化するため、リストおよびアップストリームの最適化を追加します：

events {
    use epoll;
    worker_connections 4096;
    # worker_cpu_affinity auto;  # 必要に応じてコアを固定割り当て
}

http {
    # TLS／セッションの最適化（例）
    ssl_session_cache    shared:SSL:50m;
    ssl_session_timeout  1h;

 upstream app_backend {
 server 10.0.0.11:8080;
 server 10.0.0.12:8080;
 keepalive 64;
    }

    server {
 listen 443 ssl http2 reuseport backlog=65535;

 location / {
 proxy_pass http://app_backend;
 proxy_connect_timeout     2s;
            proxy_read_timeout 15s;
 proxy_next_upstream error timeout http_502 http_503;
 proxy_next_upstream_tries 2;
 }
    }
}

簡単にまとめると：具体的な目安

worker_processes を CPU コア数に合わせて調整し、worker_connections は通常 1024 から 4096. リバースプロキシでは、リクエストごとに2つの接続を想定しており、測定されたピーク値に対して少なくとも2倍の余裕を確保しています。負荷. worker_rlimit_nofile およびシステム全体の制限値は、nginx.conf に設定した数値が実際に活用できるよう、十分に高い値に設定しています。Events ブロックは epoll と multi_accept に絞り込み、カーネルバックログについては、短時間のトラフィック急増時 和らげる. モニタリングと段階的な調整を通じて、アクセス数の増加をスムーズに処理できる信頼性の高いトラフィックエンジンを構築します。運ぶ.