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

Nginxの速度を向上させる：バッファ、圧縮、キャッシュの必須ヒント

バッファ最適化、Gzip圧縮、スマートキャッシュ戦略に関するこの必須ガイドで、Nginxのピークパフォーマンスを解き放ちましょう。効率的なデータ処理のためのクライアントバッファとプロキシバッファの設定方法、帯域幅を削減するための堅牢なコンテンツ圧縮の実装方法、そして超高速な応答時間のためのブラウザキャッシュとNginxプロキシキャッシュの両方の活用方法を学びます。実践的なNginx設定例とベストプラクティスを豊富に含んだこの記事は、Webサーバーの速度と効率を大幅に向上させるための実用的な洞察を提供します。

35 ビュー

Nginxの速度をブースト：必須バッファ、圧縮、キャッシュのヒント

Nginxは、Webサーバーおよびリバースプロキシとしてのパフォーマンスと効率性で知られています。しかし、その潜在能力を最大限に引き出すためには、慎重なチューニングと最適化が不可欠です。基本的な設定で開始できますが、バッファ管理、コンテンツ圧縮、インテリジェントなキャッシュ戦略を伴う高度なテクニックにより、サーバーの応答時間、帯域幅の使用量、ユーザーエクスペリエンスを劇的に改善できます。

この記事では、これらの重要なパフォーマンス最適化領域を深く掘り下げます。Nginxバッファを効果的に設定してクライアントリクエストとバックエンドレスポンスを処理する方法、堅牢なGzip圧縮を実装してコンテンツをより速く配信する方法、ブラウザ側とNginx側の両方のキャッシュを活用して冗長なデータ転送と処理を最小限に抑える方法を探ります。最終的に、Nginxサーバーの速度と効率を大幅に向上させるための実用的な洞察と構成を得ることができます。

効率的なデータ処理のためのNginxバッファの最適化

Nginxは、リクエストおよびレスポンス処理中にデータを一時的に格納するためにさまざまなバッファを使用します。これらのバッファのサイズを適切に設定することは、パフォーマンスにとって重要です。バッファのサイズ設定が不適切だと、メモリ消費量が過剰になったり、ディスクへの書き込み（スプーリング）が頻繁に発生したりする可能性があり、どちらもパフォーマンスを低下させます。クライアント関連バッファとプロキシ/FastCGIバッファを見ていきます。

クライアント関連バッファ

これらのバッファは、クライアントからNginxへのデータフローを管理します。

  • client_body_buffer_size: クライアントリクエストボディの読み取り用バッファサイズを設定します。リクエストボディがこのサイズを超えた場合、ディスク上のテンポラリファイルに書き込まれます。これにより、大きなアップロードでのメモリ不足を防ぐことができますが、ディスクへの頻繁な書き込みはパフォーマンスを低下させる可能性があります。

    • ヒント: POSTリクエスト経由で非常に大きなファイルをアップロードしない典型的なWebアプリケーションでは、8kまたは16kで十分な場合が多いです。より大きなフォームや小さなファイルをNginx経由で直接アップロードする場合は、この値を増やしてください。

    nginx http { client_body_buffer_size 16k; # ... }

  • client_header_buffer_size: クライアントリクエストヘッダーの読み取り用バッファサイズを定義します。各接続に1つのバッファが割り当てられます。

    • ヒント: 1kがデフォルトであり、ほとんどのヘッダーで十分です。多くのCookieや複雑な認証ヘッダーが原因で「client sent too large header」エラーが発生した場合にのみ増やしてください。

    nginx http { client_header_buffer_size 1k; # ... }

  • large_client_header_buffers: 大きなクライアントリクエストヘッダーの読み取りに使用されるバッファの最大数とサイズを設定します。ヘッダーがclient_header_buffer_sizeを超えた場合、Nginxはこのディレクティブを使用してバッファを割り当てようとします。

    • ヒント: 4 8k（各8KBのバッファ4つ）は一般的な設定です。client_header_buffer_sizeを増やしてもヘッダーエラーが頻繁に発生する場合は調整してください。

    nginx http { large_client_header_buffers 4 8k; # ... }

プロキシおよびFastCGIバッファ

これらのバッファは、Nginxがリバースプロキシとして機能する場合や、FastCGIバックエンド（PHP-FPMなど）と通信する場合のデータフローを管理します。

Nginxがリクエストをプロキシする場合、バックエンドサーバーからのレスポンスをチャンクで受信し、クライアントに送信する前にバッファリングします。これにより、Nginxは遅いバックエンドレスポンスをクライアント接続をブロックすることなく処理できます。

  • proxy_buffer_size: プロキシサーバーから受信したレスポンスの最初の部分用のバッファサイズ。通常、これにはレスポンスヘッダーが含まれます。
  • proxy_buffers: プロキシサーバーからのレスポンスの読み取りに使用されるバッファの数とサイズを定義します。

  • proxy_busy_buffers_size: 同時にアクティブ（ビジー）状態になれるバッファの最大サイズを設定します。これは、クライアントへのデータ送信中またはバックエンドからの読み取り中に行われます。これにより、Nginxがバッファを長時間保持することによるメモリ過剰消費を防ぐのに役立ちます。

    • プロキシパスの例: 典型的なWebアプリケーションでは、proxy_buffer_sizeは期待されるヘッダーサイズに一致させ、proxy_buffersはディスクへの書き込みなしで平均的なコンテンツサイズを処理できるように設定できます。

    nginx http { proxy_buffer_size 128k; proxy_buffers 4 256k; # 各256KBのバッファ4つ proxy_busy_buffers_size 256k; # ... }

  • fastcgi_buffer_size, fastcgi_buffers, fastcgi_busy_buffers_size: これらのディレクティブは、proxy_ディレクティブと機能的には同じですが、FastCGIサーバーからのレスポンスに特化して適用されます。

    • FastCGIの例: ここでも同様のロジックが適用されます。PHP/FastCGIアプリケーションのレスポンスサイズに合わせて調整してください。

    nginx http { fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; # ... }

警告: バッファサイズを大きくしすぎると、接続あたりのRAM使用量が増加し、ビジーサーバーではメモリがすぐに枯渇する可能性があります。小さすぎると、Nginxがテンポラリファイルをディスクに書き込むことになり、I/Oオーバーヘッドが発生します。最適なバランスを見つけるために、サーバーのメモリとディスクI/Oを監視してください。

効果的なGzip圧縮の有効化

コンテンツ圧縮（主にGzipを使用）は、転送されるデータサイズを大幅に削減でき、ページロードの高速化と帯域幅使用量の削減につながります。Nginxのgzipモジュールは高度に設定可能です。

必須Gzipディレクティブ

これらのディレクティブをhttpブロック、または特定のserverまたはlocationブロックに追加します。

  • gzip on;: Gzip圧縮を有効にします。

  • gzip_types: 圧縮すべきMIMEタイプを指定します。テキストベースのタイプのみが圧縮から大きく利益を得ます。

    • ベストプラクティス: 一般的なWebタイプを含めますが、画像（image/*）、動画（video/*）、および既に圧縮されているファイル（.zip, .rar, .gz）は、CPUサイクルを無駄にするだけなので避けてください。

    nginx gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml;

  • gzip_proxied: Viaヘッダーに基づいてプロキシされたリクエストの圧縮を有効にします。これは、バックエンドサーバーから来ている場合でもNginxにレスポンスを圧縮するように指示します。

    • any: すべてのプロキシされたリクエストを圧縮します。
    • no-cache, no-store, private: キャッシュ不可としてマークされたレスポンスの圧縮を防ぐために一般的に使用されます。

    nginx gzip_proxied any;

  • gzip_min_length: Nginxが圧縮するレスポンスボディの最小長を設定します。小さなファイルは圧縮からあまり利益を得られず、圧縮オーバーヘッドのために大きくなることさえあります。

    • ヒント: 1000バイト（1KB）または256バイトのような値は、良い出発点です。

    nginx gzip_min_length 1000;

  • gzip_comp_level: 圧縮レベル（1-9）を設定します。レベルが高いほど圧縮率は良くなりますが、CPUリソースの消費も多くなります。レベルが低いほど高速ですが、圧縮効果は低くなります。

    • ヒント: ほとんどのサーバーでは、圧縮率とCPU使用率のバランスが良い4-6が適しています。

    nginx gzip_comp_level 5;

  • gzip_vary on;: プロキシに、クライアントによって送信されるAccept-Encodingヘッダーに応じて、ファイルの圧縮バージョンと非圧縮バージョンの両方をキャッシュするように指示します。これは、適切なキャッシュと配信に不可欠です。

    nginx gzip_vary on;

  • gzip_disable: Gzipに問題がある可能性のある特定のブラウザやユーザーエージェントに対して圧縮を無効にします。

    nginx gzip_disable "MSIE [1-6]\."; # 例：古いInternet Explorer向けに無効化

考慮事項: Gzipは非常に有益ですが、圧縮はCPUサイクルを消費します。ディスクから直接提供される静的ファイル（例：事前に圧縮された.gzファイル）の場合、Nginxは再圧縮なしで直接提供でき、これはさらに効率的です。動的コンテンツの場合、Gzipは通常、正味の利益となります。

スマートなキャッシュ戦略の実装

キャッシュは、コンテンツの再生成や再取得の必要性を減らすことで、Webサーバーのパフォーマンスを向上させる最も効果的な方法と言えます。Nginxは、ブラウザ側（クライアント側）とサーバー側（プロキシ）の両方のキャッシュをサポートしています。

ブラウザキャッシュ（HTTPヘッダー）

ブラウザキャッシュは、HTTPヘッダーを使用して、静的アセットを保存する期間をクライアントブラウザに指示します。これにより、画像、CSS、JavaScriptファイルなどの変更されないリソースの繰り返しダウンロードを防ぎます。

  • expires: ExpiresおよびCache-Control: max-ageヘッダーを設定する簡単なディレクティブ。

    nginx location ~* \.(jpg|jpeg|gif|png|webp|ico|css|js|woff|woff2|ttf|otf|eot)$ { expires 365d; # 1年間キャッシュ add_header Cache-Control "public, no-transform"; # オプション：静的ファイルログを無効化 access_log off; log_not_found off; }

  • add_header Cache-Control: キャッシュポリシーをより細かく制御できます。一般的な値は次のとおりです。

    • public: 任意のキャッシュ（ブラウザ、プロキシ）でキャッシュ可能。
    • private: クライアントのプライベートキャッシュ（例：ブラウザ）でのみキャッシュ可能。
    • no-cache: 使用前にサーバーと再検証する必要があるが、コピーは保存できる。
    • no-store: 全くキャッシュしない。
    • max-age=<秒>: リソースが有効と見なされる期間を指定します。

  • 条件付きリクエスト（EtagおよびIf-Modified-Since）: Nginxは、静的ファイルに対してEtagおよびLast-Modifiedヘッダーを自動的に処理し、ブラウザが条件付きリクエスト（If-None-MatchまたはIf-Modified-Since）を送信できるようにします。コンテンツが変更されていない場合、Nginxは304 Not Modifiedで応答し、帯域幅を節約します。

Nginxプロキシキャッシュ

Nginxは、強力なキャッシュリバースプロキシとして機能できます。有効にすると、Nginxはバックエンドサーバーからのレスポンスのコピーを保存し、それを直接クライアントに提供することで、バックエンドの負荷を大幅に削減します。

1. キャッシュゾーンの定義

これはhttpブロックで行う必要があります。proxy_cache_pathは、キャッシュのディレクトリ、メモリゾーンのパラメータ、およびその他の設定を定義します。

http {
    proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m inactive=60m max_size=1g;
    # levels=1:2: キャッシュファイル用の2レベルディレクトリ階層を作成します（例：/var/cache/nginx/c/29/...）。ファイルの分散に役立ちます。
    # keys_zone=my_cache:10m: キャッシュキーとメタデータを格納するための10MBの共有メモリゾーン'my_cache'を定義します。これは高速なルックアップに不可欠です。
    # inactive=60m: 60分間アクセスされなかったキャッシュアイテムはディスクから削除されます。
    # max_size=1g: ディスク上のキャッシュの最大サイズを設定します。超過した場合、Nginxは最も最近使用されなかったデータを削除します。
    # ...
}

2. Locationでのキャッシュの有効化

serverまたはlocationブロック内で、キャッシュを有効にし、その動作を定義します。

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend_upstream; # または http://127.0.0.1:8000;
        proxy_cache my_cache; # 上記で定義したキャッシュゾーンを使用
        proxy_cache_valid 200 302 10m; # 成功したレスポンス（200, 302）を10分間キャッシュ
        proxy_cache_valid 404 1m;      # 404レスポンスを1分間キャッシュ
        proxy_cache_revalidate on;     # 再検証のためにIf-Modified-SinceおよびIf-None-Matchヘッダーを使用
        proxy_cache_min_uses 1;       # アイテムが少なくとも1回要求された場合にのみキャッシュ
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
                                       # バックエンドがダウンまたは更新中の場合は古いコンテンツを提供する

        # レスポンスがキャッシュされたかどうかを確認するためのヘッダーを追加
        add_header X-Cache-Status $upstream_cache_status;

        # オプション：特定の条件でキャッシュをバイパス
        # proxy_cache_bypass $http_pragma $http_authorization;
        # proxy_no_cache $http_pragma $http_authorization;
    }
}

重要なキャッシュディレクティブ

  • proxy_cache_valid: HTTPステータスコードと期間に基づいてキャッシュルールを定義します。複数のルールを指定できます。
  • proxy_cache_revalidate on;: キャッシュされたコンテンツがまだ最新かどうかを確認する際に、NginxがIf-Modified-SinceおよびIf-None-Matchヘッダーを使用できるようにします。これは、単にキャッシュを期限切れにするよりも効率的です。
  • proxy_cache_use_stale: バックエンドが利用できないか遅い場合に、Nginxにキャッシュから古い（期限切れの）コンテンツを提供するように指示する強力なディレクティブです。これは、バックエンドの問題発生時のユーザーエクスペリエンスを大幅に向上させます。

  • proxy_cache_bypass / proxy_no_cache: これらは、キャッシュがバイパスされる条件（例：認証されたリクエストや特定のクエリパラメータの場合）を定義するために使用します。

    ```nginx

    特定のクエリパラメータやCookieを持つリクエストをキャッシュしない例

    if ($request_uri ~* "(\?|&)nocache")

    if ($http_cookie ~* "SESSIONID")

    proxy_cache_bypass $no_cache;

    proxy_no_cache $no_cache;

    ```

キャッシュのクリア

Nginxキャッシュを手動でクリアするには、proxy_cache_pathディレクトリ内のファイルを削除するだけです。より制御された無効化については、ngx_cache_purgeのようなモジュールを使用するか、キャッシュ無効化リクエストを処理する特定のlocationを設定することを検討してください。

警告: プロキシキャッシュの設定ミスは、ユーザーに古いコンテンツが表示される原因となる可能性があります。本番環境にデプロイする前に、必ずステージング環境でキャッシュ戦略を徹底的にテストしてください。動的に頻繁に変更されるコンテンツやユーザー固有のコンテンツが積極的にキャッシュされないようにしてください。

まとめ

Nginxのパフォーマンス最適化は、リソース管理とコンテンツ配信に対する戦略的なアプローチを伴います。バッファサイズを慎重にチューニングすることで、Nginxは不要なディスクI/Oやメモリオーバーヘッドなしでデータフローを効率的に処理できます。堅牢なGzip圧縮を実装することで、帯域幅が大幅に削減され、特にテキストベースのアセットのコンテンツ配信が高速化されます。

最後に、ブラウザレベルとNginxがリバースプロキシキャッシュとして機能する両方でのインテリジェントなキャッシュは、バックエンドの負荷を削減し、最小限のレイテンシでコンテンツを提供する上で最も重要です。これらの各テクニックは、慎重に適用されることで、より応答性が高く、効率的で、スケーラブルなWebサーバーエクスペリエンスをユーザーに提供することに貢献します。サーバーのパフォーマンスメトリクスを継続的に監視し、トラフィックパターンとアプリケーションのニーズの変化に合わせてこれらの設定を調整してください。