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

NGINX | 2014年10月10日

Rick Nelsonソリューションエンジニアリング担当リージョナルバイスプレジデント

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

ほぼすべての設定をチューニングできますが、この記事では、特に多くのユーザーに効果が見込まれるいくつかの設定に焦点を当てます。NGINXとLinuxを深く理解している場合、またはF5のサポートチームやプロフェッショナルサービスチームから指示を受けた場合にのみ変更を推奨する設定については、ここでは取り上げません。プロフェッショナルサービスチームは、世界有数の高トラフィックWebサイトで、NGINXのパフォーマンスを最大限に引き出すためのチューニングに携わってきました。お客さまのNGINXまたはNGINX Plus環境を最大限に活用できるよう支援します。

はじめに

NGINXのアーキテクチャと設定の概念について、基本的な知識があることを前提としています。この記事では、NGINXのドキュメントと同じ内容を繰り返すのではなく、さまざまなオプションの概要と関連ドキュメントへのリンクを紹介します。

チューニングでは、設定を一度に1つずつ変更し、パフォーマンスが向上しない場合はデフォルト値に戻すことをお勧めします。

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

Linux構成のチューニング

最新のLinuxカーネル（2.6以降）の設定は、ほとんどの用途に適していますが、一部を変更すると効果が得られる場合があります。カーネルログを確認し、設定値が低すぎることを示すエラーメッセージがある場合は、その指示に従って調整してください。ここでは、通常のワークロードで調整による効果が最も見込まれる設定のみを取り上げます。これらの設定の調整方法について詳しくは、ご利用のLinuxのドキュメントを参照してください。

バックログキュー

以下の設定は、接続とそのキューイング方法に関するものです。着信接続の頻度が高く、パフォーマンスにばらつきがある場合（たとえば、一部の接続が停止しているように見える場合）は、これらの設定を変更すると改善に役立つことがあります。

net.core.somaxconn – NGINXが受け入れる接続をキューに入れられる最大数です。デフォルト値は非常に小さいことが多いものの、NGINXは接続を非常に迅速に受け入れるため、通常は問題ありません。ただし、Webサイトへのトラフィックが多い場合は、この値を増やすと効果的なことがあります。カーネルログのエラーメッセージで値が小さすぎることが示されている場合は、エラーが発生しなくなるまで値を増やしてください。注：この値を512より大きく設定する場合は、NGINXのbacklogパラメーターをlistenディレクティブの値と一致するように変更してください。
net.core.netdev_max_backlog – パケットがCPUに渡される前にネットワークカードでバッファリングされる速度です。帯域幅が大きいマシンでは、この値を増やすことでパフォーマンスが向上する可能性があります。この設定に関連するエラーがないかカーネルログを確認し、値の変更についてはネットワークカードのドキュメントを参照してください。

ファイルディスクリプター

ファイルディスクリプターは、接続や開いているファイルなどを表すために使用されるオペレーティングシステムのリソースです。NGINXは、接続ごとに最大2つのファイルディスクリプターを使用できます。たとえば、NGINXがプロキシとして動作する場合、通常はクライアント接続に1つ、プロキシ先サーバーへの接続にもう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 – クライアントが1つのキープアライブ接続で送信できるリクエスト数。デフォルトは100ですが、通常は単一のクライアントから大量のリクエストを送信する負荷生成ツールでテストする場合は、はるかに大きな値を設定すると特に効果的です。
keepalive_timeout – アイドル状態のキープアライブ接続を開いたままにする時間。

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

keepalive – 各ワーカープロセスで開いたまま維持される、アップストリームサーバーへのアイドル状態のkeepalive接続数。デフォルト値はありません。

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

proxy_http_version 1.1;proxy_set_header Connection "";

アクセスログ

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

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

Sendfile

オペレーティングシステムのsendfile()システムコールは、あるファイルディスクリプターから別のファイルディスクリプターにデータをコピーします。多くの場合、ゼロコピーを実現できるため、TCPデータ転送を高速化できます。NGINXでこのシステムコールを使用できるようにするには、sendfileディレクティブをhttpコンテキスト、またはserverコンテキストかlocationコンテキストに含めます。これにより、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：serverディレクティブのパラメーター（upstream設定ブロック内）— アップストリームグループ内のサーバーが受け入れる同時接続数の上限を設定します。上限を設けることで、アップストリームサーバーの過負荷を防止できます。値を0（ゼロ、デフォルト）に設定すると、接続数は制限されません。
queue（NGINX Plus）– アップストリームグループ内の使用可能なすべてのサーバーがmax_connsの上限に達した場合に、リクエストを格納するキューを作成します。このディレクティブでは、キュー内のリクエストの最大数と、必要に応じてエラーが返されるまでの最大待機時間（デフォルトは60秒）を設定します。このディレクティブを省略すると、リクエストはキューに格納されません。

キャッシュと圧縮でパフォーマンスを向上

NGINXには、Webアプリケーションのパフォーマンス向上に利用できる追加機能があります。厳密にはチューニングに分類されませんが、大きな効果が見込めるため、ここで取り上げます。これには、キャッシュと圧縮が含まれます。

キャッシュ

一連のWebサーバーまたはアプリケーションサーバーの負荷分散を行うNGINXインスタンスでキャッシュを有効にすると、クライアントへの応答時間を大幅に短縮すると同時に、バックエンドサーバーの負荷も大幅に軽減できます。キャッシュ自体が独立したテーマであるため、ここでは説明しません。詳しくは「NGINX Plus Admin Guide」を参照してください。

圧縮

クライアントに送信するレスポンスを圧縮すると、サイズを大幅に削減できるため、ネットワーク帯域幅の使用量を抑えられます。ただし、データの圧縮にはCPUリソースを消費するため、帯域幅の使用量を削減する効果が十分に見込める場合に最も有用です。JPEGファイルなど、すでに圧縮されているオブジェクトに対しては、圧縮を有効にしないでください。詳細については、「NGINX Plus Admin Guide」を参照してください。

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

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