DevOpsナレッジハブ
DevOpsナレッジハブ

Nginxワーカープロセスを最適化し、最大パフォーマンスを実現するための実践ガイド

コアパフォーマンスディレクティブの設定に関するこの実践ガイドを利用して、高負荷トラフィック向けにNginxサーバーを最適化しましょう。CPUコア数に合わせて`worker_processes`を設定し、`worker_connections`で同時接続数を最大化し、基盤となるOSのファイルディスクリプタ制限（`ulimit`）に準拠させるためのベストプラクティスを学びましょう。この記事では、遅延を最小限に抑え、サーバーのスループットを劇的に向上させるための、実践的な設定例と重要なチューニングのヒントを提供します。

38 ビュー

Nginxワーカプロセスを最適化して最高のパフォーマンスを引き出す：実践ガイド

Nginxは、イベント駆動型で非同期のアーキテクチャにより、高いパフォーマンスと低いメモリフットプリントで広く知られています。しかし、その真の力を最大限に引き出し、大量のトラフィック負荷を効率的に処理するには、そのコアとなるリソース利用パラメータ、特にworker_processesとworker_connectionsの正しい設定が不可欠です。

このガイドでは、Nginxがどのようにワーカプロセスとコネクションを使用するかについて包括的な概要を提供し、スループットを最大化し、レイテンシを最小限に抑え、Nginxサーバーがピーク負荷時でも最適なパフォーマンスを発揮するためのこれらのディレクティブのベストプラクティスを詳述します。これらの設定を理解することが、高性能Nginxチューニングの基礎となります。

Nginxワーカアーキテクチャの理解

Nginxはマスター・ワーカモデルを使用して動作します。マスタープロセスは、設定の読み込みと検証、ポートへのバインド、およびワーカプロセスの管理を担当します。システムリソースの監視や必要に応じたワーカの再起動など、重要度の低いタスクを実行します。

ワーカプロセスは、実際の重い処理が行われる場所です。これらのプロセスはシングルスレッド（標準Nginxコンパイルの場合）であり、ノンブロッキングシステムコールを使用します。各ワーカはイベントループを使用して数千の同時接続を効率的に処理し、1つのプロセスがブロックすることなく複数のリクエストを管理できるようにします。これがNginxのパフォーマンスの鍵です。

適切な最適化には、ワーカの数（CPUリソースに紐付ける）と、各ワーカが処理できる最大接続数の設定のバランスをとることが含まれます。

worker_processesの設定：CPUコアファクタ

worker_processesディレクティブは、Nginxが生成すべきワーカプロセスの数を決定します。この設定は、NginxがサーバーのCPUリソースをどのように利用するかに直接影響します。

ベストプラクティス：ワーカ数をコア数に合わせる

最も一般的で強く推奨されるベストプラクティスは、ワーカプロセスの数をサーバーで利用可能なCPUコア数と等しく設定することです。これにより、すべてのコアが効率的に利用され、コンテキストスイッチングによる過剰なオーバーヘッドが発生しないようにします。

ワーカの数がコア数を超えると、オペレーティングシステムは競合するNginxプロセス間でCPUのフォーカスを頻繁に切り替える（コンテキストスイッチング）必要があり、これがレイテンシを発生させ、全体的なパフォーマンスを低下させます。

autoディレクティブの使用

Nginxの最新バージョン（1.3.8以降）では、autoパラメータを使用することが最もシンプルで効果的な設定です。Nginxは利用可能なCPUコア数を自動的に検出し、それに応じてワーカプロセスを設定します。

# ほとんどのデプロイメントで推奨される設定
worker_processes auto;

手動設定

手動制御が必要な場合や、古いバージョンを使用している場合は、正確なワーカ数を指定できます。システムユーティリティを使用してコア数を検索できます。

# CPUコア数を検索
grep processor /proc/cpuinfo | wc -l

システムに8コアある場合、設定は次のようになります。

# ワーカプロセスを8に手動設定
worker_processes 8;

ヒント: コア数に合わせることが標準的ですが、Nginxサーバーが主に静的コンテンツを提供している場合（I/Oバウンドなタスク）、worker_processesをコア数の1.5倍または2倍に設定することで、わずかなパフォーマンス向上を見込めることがあります。ただし、一般的なウェブサービス、プロキシ、SSLターミネーション（CPUバウンドなタスク）の場合、コア数（auto）にこだわる方が、一般的に安全で安定しています。

worker_connectionsの設定：同時接続ファクタ

worker_connectionsディレクティブはeventsブロック内で設定され、単一のワーカプロセスが処理できる同時接続の最大数を定義します。これには、クライアントへの接続、アップストリームプロキシサーバーへの接続、および内部ヘルスチェック接続が含まれます。

最大クライアント数の計算

Nginxサーバーが処理できる理論上の最大同時クライアント接続数は、次のように計算されます。

$$\text{Max Clients} = \text{worker_processes} \times \text{worker_connections}$$

4つのワーカプロセスと、プロセスあたり10,000のワーカコネクションがある場合、Nginxは理論上40,000の同時接続を処理できます。

接続制限の設定

システムリソース（メモリ、ファイルディスクリプタ）がそれをサポートできると仮定して、トラフィックの急増に対応するために、worker_connectionsを高い値（例：10240、20480、またはそれ以上）に設定するのが一般的です。

# eventsブロックの設定例

events {
    # ワーカプロセスあたりの最大同時接続数
    worker_connections 16384;

    # 強く推奨：ワーカが新しい接続を一つずつ処理するのではなく、
    # すべて同時に受け入れることを可能にします。
    multi_accept on;
}

システム制限（ulimit）の制約

決定的に重要なのは、worker_connectionsの設定は、オペレーティングシステムがプロセスごとに許可するオープンファイルディスクリプタ（FD）の数に制約されることであり、多くの場合、これはulimit -nの設定によって制御されます。

Nginxは、OSが許可するファイルディスクリプタ数以上に接続を開くことはできません。すべての接続（クライアントソケット、ログファイル、プロキシソケット）はファイルディスクリプタを必要とするため、システム制限が十分に高く設定されていることが極めて重要です。

ファイルディスクリプタ制限の確認と引き上げ

  1. 現在の制限を確認する：

    bash ulimit -n

  2. 制限を一時的に引き上げる（現在のセッションの場合）：

    bash ulimit -n 65536

  3. 制限を永続的に引き上げる（/etc/security/limits.confを介して）：

    次の行を追加し、nginx_userをNginxが実行されるユーザー（多くの場合www-dataまたはnginx）に置き換えてください。

    ```bash

    /etc/security/limits.conf

    nginx_user soft nofile 65536
    nginx_user hard nofile 65536
    ```

警告: Nginxの設定におけるworker_connectionsの値が、システム全体のファイルディスクリプタ制限（ulimit -n）よりも著しく低くなるように常に確認してください。一般的な推奨事項は、安全のためにworker_connections * worker_processesがOS制限よりも小さくなるようにすることですが、Nginxが要求するのは、プロセスごとの制限（ulimit -n）がworker_connectionsよりも高いことだけです。

高度なチューニングと監視

コアディレクティブ以外にも、パフォーマンスを微調整するのに役立ついくつかの追加事項があります。

1. ワーカプロセスのピン留め

高性能環境、特に複数のCPUソケット（NUMAアーキテクチャ）を持つシステムでは、worker_cpu_affinityディレクティブを使用したい場合があります。これは、OSに特定のワーカプロセスを特定のCPUに制限するように指示するもので、CPUキャッシュをホットに保ち、メモリ局所性の問題を回避することでパフォーマンスを向上させることができます。

8コアシステムの例：

worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

この設定は複雑であり、通常は極端な高負荷状況でのみ有益です。ほとんどのデプロイメントではworker_processes autoで十分です。

2. パフォーマンスメトリクスの監視

最適化を適用した後、その影響を監視することが重要です。Nginx Stub Statusモジュール（またはPrometheus/Grafanaのようなツール）を使用して、主要なメトリクスを追跡します。

メトリクス 説明 最適化チェック
アクティブな接続 現在処理されている合計接続数。 理論上の最大値よりも低い必要があります。
読み込み中/書き込み中/待機中 異なる状態の接続。 高い「待機中」の数は、長寿命のHTTPキープアライブ（良い）または処理リソースの不足（悪い）を示すことが多いです。
リクエストレート 1秒あたりのリクエスト数。 設定変更後の実際のパフォーマンス改善を測定するために使用されます。

すべてのコアで高いCPU使用率と高いリクエストレートを観測した場合、worker_processesは正しく設定されている可能性が高いです。ピークトラフィック時にアイドル状態のCPUコアがある場合は、設定を見直すか、Nginx外部でのブロッキングI/O操作をチェックすることを検討してください。

3. 接続オーバーフロー戦略

サーバーが最大接続制限（worker_processes * worker_connections）に達すると、新しいリクエストは破棄されます。worker_connectionsを増やすことは役立ちますが、慎重なmulti_acceptの使用（上記参照）と組み合わせることで、高負荷時でもワーカが常に新しい接続を受け入れる準備ができていることを保証します。

ベストプラクティスの概要

ディレクティブ 推奨値 理由
worker_processes auto（またはコア数） 最適なCPU利用率を確保し、コンテキストスイッチングのオーバーヘッドを最小限に抑えます。
worker_connections 10240以上 ワーカあたりの同時接続数を最大化し、サーバーが高トラフィックの急増を処理できるようにします。
OS制限（ulimit -n） worker_connectionsよりも著しく高く すべてのアクティブな接続と内部リソースに必要なファイルディスクリプタを提供します。
multi_accept on ロードスパイク時にワーカが接続キューを迅速に処理できるようにします。

CPUリソースに合わせてワーカプロセスの数を慎重に調整し、システム制限内で各ワーカが処理できる接続数を最大化することで、Nginxのデプロイメントが最高の安定性とパフォーマンスを発揮し、数千の同時ユーザーを効率的に処理できるようにすることができます。