パフォーマンス向上のための NGINX のチューニング

NGINX は、高性能なロードバランサー、キャッシュ、 Web サーバーとしてよく知られており、世界で最もアクセスの多い Web サイトの 40% 以上を支えています。 ほとんどのユースケースでは、デフォルトの NGINX および Linux 設定で問題なく動作しますが、最適なパフォーマンスを実現するには、多少の調整が必要になる場合があります。 このブログ記事では、システムを調整する際に考慮すべき NGINX と Linux の設定について説明します。

ほぼすべての設定を調整できますが、この投稿では、調整によって最も多くのユーザーにメリットがもたらされるいくつかの設定に焦点を当てています。 NGINX と Linux を深く理解している場合、またはサポートチームやプロフェッショナル サービスチームの指示がある場合にのみ変更することをお勧めする設定がありますが、ここではそれらについては説明しません。 プロフェッショナル サービス チームは、世界で最もアクセス数の多い Web サイトのいくつかと協力して、NGINX のパフォーマンスを最高レベルに調整しており、NGINX または NGINX Plus の導入を最大限に活用できるようお客様と協力します。

導入

NGINX アーキテクチャと構成の概念に関する基本的な理解が前提となります。 この投稿では、NGINX ドキュメントを複製するつもりはありませんが、さまざまなオプションの概要と関連するドキュメントへのリンクを提供します。

チューニングする際の良いルールは、一度に 1 つの設定を変更し、変更によってパフォーマンスが向上しない場合はデフォルト値に戻すことです。

いくつかのオペレーティング システム設定の値によって NGINX 構成のチューニング方法が決まるため、まず Linux のチューニングについて説明します。

Linux 構成の調整

最新の Linux カーネル (2.6 以降) の設定はほとんどの目的には適していますが、いくつかを変更すると有益な場合があります。 カーネル ログで設定が低すぎることを示すエラー メッセージを確認し、アドバイスに従って調整します。 ここでは、通常のワークロードでのチューニングによって最もメリットが得られる可能性が高い設定についてのみ説明します。 これらの設定を調整する方法の詳細については、Linux のドキュメントを参照してください。

バックログキュー

次の設定は、接続とそれらがキューに入れられる方法に関係します。 着信接続率が高く、パフォーマンスのレベルが不均一な場合 (たとえば、一部の接続が停止しているように見える場合)、これらの設定を変更すると役立つ場合があります。

• net.core. somaxconn – NGINX が受け入れるためにキューに入れることができる接続の最大数。デフォルトは非常に低い場合が多く、NGINX は接続を非常に速く受け入れるため通常は問題ありませんが、Web サイトのトラフィックが大量に発生する場合は、値を増やす価値があります。 カーネル ログのエラー メッセージで値が小さすぎることが示されている場合は、エラーがなくなるまで値を増やします。

  注記： これを 512 より大きい値に設定する場合は、一致するようにバックログパラメータを NGINX listenディレクティブに変更します。

• net.core. netdev_max_backlog – パケットが CPU に渡される前にネットワーク カードによってバッファリングされる速度。 値を大きくすると、帯域幅が大きいマシンのパフォーマンスが向上します。 この設定に関連するエラーがないかカーネル ログを確認し、変更方法についてはネットワーク カードのドキュメントを参照してください。

ファイル記述子

ファイル記述子は、接続や開いているファイルなどを表すために使用されるオペレーティング システム リソースです。 NGINX は、接続ごとに最大 2 つのファイル記述子を使用できます。 たとえば、NGINX がプロキシしている場合、通常はクライアント接続に 1 つのファイル記述子を使用し、プロキシされたサーバーへの接続に別のファイル記述子を使用しますが、HTTP キープアライブが使用されている場合はこの比率ははるかに低くなります。 多数の接続を処理するシステムでは、次の設定を調整する必要がある場合があります。

• sys.fs. file-max – システム全体のファイル記述子の制限
• nofile – /etc/security/limits.confファイルで設定されるユーザーファイル記述子の制限

一時ポート

NGINX がプロキシとして動作している場合、アップストリーム サーバーへの各接続では一時ポート、つまりエフェメラルポートが使用されます。 この設定を変更する必要がある場合があります:

• net.ipv4. ip_local_port_range – ポート値の範囲の開始と終了。 ポートが不足している場合は、範囲を広げてください。 一般的な設定はポート 1024 ～ 65000 です。

NGINX 設定の調整

以下は、パフォーマンスに影響を与える可能性のある NGINX ディレクティブの一部です。 前述のとおり、ここでは、自分で調整しても安全な指示についてのみ説明します。 NGINX チームからの指示がない限り、他のディレクティブの設定を変更しないことをお勧めします。

ワーカープロセス

NGINX は複数のワーカー プロセスを実行でき、それぞれが多数の同時接続を処理できます。 次のディレクティブを使用して、ワーカー プロセスの数と接続の処理方法を制御できます。

• worker_processes – NGINX ワーカープロセスの数 (デフォルトは 1)。 ほとんどの場合、CPU コアごとに 1 つのワーカー プロセスを実行するとうまく機能するため、これを実現するにはこのディレクティブをautoに設定することをお勧めします。 ワーカー プロセスが大量のディスク I/O を実行する必要がある場合など、この数値を増やす必要がある場合があります。
• worker_connections – 各ワーカープロセスが同時に処理できる接続の最大数。 デフォルトは 512 ですが、ほとんどのシステムには、より大きな数値をサポートできる十分なリソースがあります。 適切な設定はサーバーのサイズとトラフィックの性質によって異なり、テストを通じて見つけることができます。

キープアライブ接続

キープアライブ接続は、接続の開閉に必要な CPU とネットワークのオーバーヘッドを削減することで、パフォーマンスに大きな影響を与える可能性があります。 NGINX はすべてのクライアント接続を終了し、アップストリーム サーバーへの個別の独立した接続を作成します。 NGINX は、クライアントとアップストリーム サーバーの両方に対してキープアライブをサポートします。 次のディレクティブはクライアント キープアライブに関連しています。

• keepalive_requests – クライアントが単一のキープアライブ接続を介して実行できるリクエストの数。 デフォルトは 100 ですが、通常単一のクライアントから大量のリクエストを送信する負荷生成ツールを使用したテストでは、より高い値が特に役立ちます。
• keepalive_timeout – アイドル状態のキープアライブ接続が開いたままになる時間。

次のディレクティブはアップストリーム キープアライブに関係します。

• keepalive – 各ワーカー プロセスに対して開いたままになっているアップストリーム サーバーへのアイドル キープアライブ接続の数。 デフォルト値はありません。

アップストリーム サーバーへのキープアライブ接続を有効にするには、構成に次のディレクティブも含める必要があります。

proxy_http_version 1.1; proxy_set_header接続 "";

アクセスログ

すべてのリクエストをログに記録すると、CPU と I/O サイクルの両方が消費されます。この影響を軽減する 1 つの方法は、アクセス ログのバッファリングを有効にすることです。 バッファリングを使用すると、NGINX はログ エントリごとに個別の書き込み操作を実行する代わりに、一連のエントリをバッファリングし、単一の操作でまとめてファイルに書き込みます。

アクセス ログのバッファリングを有効にするには、 access_logディレクティブにbuffer= sizeパラメータを含めます。バッファがサイズ値に達すると、NGINX はバッファの内容をログに書き込みます。 指定された時間後に NGINX がバッファを書き込むようにするには、 flush= timeパラメータを含めます。 両方のパラメータが設定されている場合、NGINX は、次のログ エントリがバッファに収まらない場合、またはバッファ内のエントリが指定された時間よりも古い場合に、エントリをログ ファイルに書き込みます。 ログ エントリは、ワーカー プロセスがログ ファイルを再度開いたり、シャットダウンしたりするときにも書き込まれます。 アクセス ログを完全に無効にするには、 access_logディレクティブにoffパラメータを含めます。

ファイルを送信

オペレーティング システムのsendfile()システム コールは、あるファイル記述子から別のファイル記述子にデータをコピーします。多くの場合、ゼロ コピーが実現されるため、TCP データ転送が高速化されます。 NGINX がこれを使用できるようにするには、 httpコンテキストまたはサーバーまたはロケーションコンテキストにsendfileディレクティブを含めます。 NGINX は、コンテキストをユーザー空間に切り替えることなく、キャッシュされたコンテンツまたはディスク上のコンテンツをソケットに書き込むことができるため、書き込みが非常に高速になり、CPU サイクルの消費が少なくなります。 ただし、 sendfile()でコピーされたデータはユーザー空間をバイパスするため、通常の NGINX 処理チェーンやgzipなどのコンテンツを変更するフィルターの対象にならないことに注意してください。 設定コンテキストにsendfileディレクティブとコンテンツ変更フィルターをアクティブ化するディレクティブの両方が含まれている場合、NGINX はそのコンテキストに対してsendfileを自動的に無効にします。

制限

さまざまな制限を設定することで、クライアントがリソースを過剰に消費して、システムのパフォーマンス、セキュリティ、ユーザー エクスペリエンスに悪影響を与えるのを防ぐことができます。 関連する指令の一部を以下に示します。

• limit_connとlimit_conn_zone – たとえば単一の IP アドレスからの NGINX が受け入れるクライアント接続の数を制限します。 これらを設定すると、個々のクライアントが接続を過剰に開き、割り当て以上のリソースを消費するのを防ぐことができます。
• limit_rate – 接続ごとにクライアントに応答が送信される速度を制限します (複数の接続を開くクライアントは、接続ごとにこの量の帯域幅を消費できます)。 制限を設定すると、特定のクライアントによってシステムが過負荷になるのを防ぎ、すべてのクライアントに対してより均一なサービス品質を確保できます。
• limit_reqとlimit_req_zone – NGINX によって処理されるリクエストのレートを制限します。これには、 limit_rate を設定するのと同じ利点があります。 また、リクエスト レートを、人間のユーザーにとっては妥当な値であるものの、リクエストでアプリケーションを圧倒しようとするプログラム ( DDoS 攻撃のボットなど) にとっては遅すぎる値に制限することで、特にログイン ページのセキュリティを向上させることもできます。
• アップストリーム構成ブロック内のサーバーディレクティブへのmax_connsパラメーター - アップストリーム グループ内のサーバーが受け入れる同時接続の最大数を設定します。 制限を課すことで、アップストリーム サーバーの過負荷を防ぐことができます。 値を 0 (ゼロ、デフォルト) に設定すると、制限がなくなります。
• キュー(NGINX Plus) – アップストリーム グループ内のすべての利用可能なサーバーがmax_conns制限に達したときにリクエストが配置されるキューを作成します。 このディレクティブは、キュー内のリクエストの最大数を設定し、オプションで、エラーが返されるまでの最大待機時間 (デフォルトでは 60 秒) を設定します。 このディレクティブを省略すると、リクエストはキューに入れられません。

キャッシュと圧縮によりパフォーマンスが向上する

Web アプリケーションのパフォーマンスを向上させるために使用できる NGINX の追加機能の中には、チューニングという範疇には入らないものもありますが、その影響はかなり大きい可能性があるため、言及する価値があります。 キャッシュと圧縮が含まれます。

キャッシング

一連の Web サーバーまたはアプリケーション サーバーの負荷を分散している NGINX インスタンスでキャッシュを有効にすると、クライアントへの応答時間を大幅に改善できると同時に、バックエンド サーバーの負荷を大幅に軽減できます。 キャッシュはそれ自体がトピックなので、ここでは取り上げません。 NGINX Plus 管理者ガイドを参照してください。

圧縮

クライアントに送信される応答を圧縮すると、応答のサイズが大幅に削減されるため、ネットワーク帯域幅の使用量が少なくなります。 ただし、データの圧縮は CPU リソースを消費するため、帯域幅の使用量を削減することが本当に価値がある場合に最も役立ちます。 JPEG ファイルなど、すでに圧縮されているオブジェクトに対しては圧縮を有効にしないことが重要です。 詳細については、 NGINX Plus 管理者ガイドを参照してください。

詳細については、以下を参照してください。

• NGINXのベンチマーク: 精度の向上と有意義な結果（オンデマンド ウェビナー）
• nginx.org のNGINX リファレンス ドキュメント
• NGINX モデルの比較
• NGINX Plus 技術仕様

NGINX Plus をお試しいただくには、今すぐ30 日間の無料トライアルを開始するか、デモについてお問い合わせください。