【ITニュース解説】Performance Tuning for Nginx: 7 Tips to Slash TTFB and Boost Speed

Webサイトの速さは、ユーザーの満足度に直結する重要な要素だ。特に「Time To First Byte（TTFB）」は、ブラウザがWebサーバーから最初のデータを受け取るまでの時間を指し、この時間が短いほどユーザーはサイトが速いと感じる。HTMLやCSSのファイルサイズを小さくしても、NginxのようなWebサーバーの処理が遅ければ、TTFBは何百ミリ秒も長くなってしまうことがある。この解説では、Nginxのパフォーマンスを向上させ、TTFBを数ミリ秒の範囲に短縮するための7つの具体的な方法を、設定の分かりやすさや管理のしやすさを保ちながら説明する。対象となるサーバーは、広く使われているUbuntu 22.04を想定している。

最初のステップは、Brotli圧縮の導入と有効化だ。Webサイトのコンテンツ、特にHTML、CSS、JavaScriptなどのテキストデータは、圧縮することでファイルサイズを小さくできる。ファイルサイズが小さくなれば、インターネットを通じてユーザーのブラウザに届くまでの時間が短縮され、結果的にWebページの表示速度が向上する。BrotliはGoogleが開発した比較的新しい圧縮アルゴリズムで、既存のGzipよりも高い圧縮率を発揮することが多い。NginxでBrotliを利用するには、まずBrotliモジュールをサーバーにインストールし、Nginxの設定ファイルでその機能を有効にする必要がある。具体的な手順としては、Nginxのコンパイルに必要なツール群を準備し、Brotliモジュールのソースコードをダウンロードする。その後、Nginxを再コンパイルする際にBrotliモジュールを組み込む形でビルドし、生成されたモジュールファイルをNginxが読み込むべきディレクトリに配置する。最後に、Nginxのメイン設定ファイル（nginx.conf）にモジュールをロードする指示と、Brotli圧縮を有効にするための設定ブロックを追記する。この設定ブロックでは、brotli on;で機能を有効にし、brotli_comp_level 5;で圧縮レベルを設定する。レベル5はCPU使用量と圧縮率のバランスが良いとされている。brotli_typesには、圧縮を適用するファイルのMIMEタイプ（例：text/plain, application/javascriptなど）を指定する。設定後は、適切なHTTPリクエストヘッダー（Accept-Encoding: br）を付けてサーバーにリクエストを送り、サーバーからの応答ヘッダーにcontent-encoding: brが含まれていることを確認することで、Brotli圧縮が正しく機能しているかを確認できる。

次に、**Gzip圧縮の最適化（フォールバックとして）**を行う。Brotliは優れた圧縮技術だが、すべてのWebブラウザが対応しているわけではないため、Gzip圧縮を代替（フォールバック）として設定しておくことが重要だ。Gzipは長年使われている標準的な圧縮技術で、ほぼ全てのブラウザでサポートされている。NginxのデフォルトのGzip設定は、安全性を重視して保守的な値になっているため、これを最適化することでさらに効率を上げることができる。gzip on;でGzip圧縮を有効にし、gzip_vary on;でプロキシサーバーが圧縮済みコンテンツと非圧縮コンテンツを適切にキャッシュできるようにする。gzip_proxied any;は、プロキシサーバー経由のリクエストに対しても圧縮を適用する設定だ。gzip_comp_level 4;は圧縮レベルを設定するが、Brotli同様、高すぎるとCPU負荷が増えるため、レベル4は良いバランスだ。gzip_min_length 256;は、非常に小さいファイルは圧縮によるメリットが少ないため、最小サイズを下回るファイルは圧縮しないようにする設定だ。そしてgzip_typesには、Brotliと同様に、Gzipで圧縮するファイルのMIMEタイプを具体的に指定する。これらの設定により、Brotli非対応のブラウザからのアクセスでも、ファイルサイズが小さく圧縮された状態でコンテンツが配信され、表示速度の向上に寄与する。

三つ目は、SSL/TLSハンドシェイクの最適化だ。Webサイトの安全な通信を実現するSSL/TLS暗号化は不可欠だが、この暗号化通信を確立するための最初のやり取りである「TLSハンドシェイク」は、特に初回接続時にTTFBに大きな影響を与えることがある。この時間を短縮するために、最新のTLSプロトコルと効率的な暗号スイート（暗号化方式の組み合わせ）を使用することが重要だ。Nginxの設定では、ssl_protocols TLSv1.3 TLSv1.2;のように、最新のTLSv1.3と、広く使われているTLSv1.2を優先的に使うように指定する。ssl_prefer_server_ciphers on;は、サーバー側が推奨する暗号スイートを優先させる設定だ。ssl_ciphersでは、TLS_AES_256_GCM_SHA384などの最新かつ高性能な暗号スイートを厳選して指定することで、安全性を保ちつつハンドシェイクの処理速度を向上させる。さらに、ssl_session_cache shared:SSL:10m;とssl_session_tickets on;を設定することで、一度確立したSSL/TLSセッションの情報をサーバー側にキャッシュし、ユーザーがサイトを再訪した際などに、ハンドシェイクの一部を省略して通信を高速化できる。TLSv1.3は特に効率的で、ハンドシェイクに必要な通信回数を減らすことで、一般的なクライアントで約30ミリ秒の接続時間短縮が期待できる。

四つ目は、Cache-Controlヘッダーの活用だ。Webサイトのコンテンツには、CSSファイル、JavaScriptファイル、画像ファイルなど、頻繁には更新されない「静的コンテンツ」と、ユーザーによって内容が変わる「動的コンテンツ」がある。これらのコンテンツを適切にキャッシュ（一時保存）させることで、ユーザーがサイトを再訪問した際にサーバーへのリクエスト数を減らし、表示速度を大幅に向上させることができる。Cache-Controlヘッダーは、ブラウザやCDN（コンテンツ配信ネットワーク）に対して、どのコンテンツを、どのくらいの期間キャッシュして良いかを指示するための重要なHTTPヘッダーだ。例えば、.css, .js, .svg, .png, .jpgといった静的コンテンツに対しては、expires 30d;で30日間キャッシュさせる設定と、add_header Cache-Control "public, immutable";というヘッダーを追加する。これは「誰でもキャッシュ可能で、変更されないため永続的にキャッシュできる」という意味だ。これにより、一度ダウンロードされた静的コンテンツは、指定された期間内はサーバーに再リクエストすることなく、ブラウザやプロキシのキャッシュから直接読み込まれるようになる。一方で、常に最新の情報を表示する必要がある動的コンテンツ（例えばサイトのトップページなど）に対しては、expires -1;やadd_header Cache-Control "no-store, no-cache, must-revalidate, proxy-revalidate";のように、「キャッシュしない、または常にサーバーに再検証を求める」という指示を出す。これにより、ユーザーは静的コンテンツは高速に、動的コンテンツは常に最新の状態で閲覧できるようになる。

五つ目は、未使用モジュールの無効化だ。Nginxは、様々な機能を提供する多数の「モジュール」の組み合わせで構成されている。しかし、Nginxをインストールする際に、すべてのモジュールが必要なわけではないのに、デフォルトで多くのモジュールが組み込まれていることがある。使用しないモジュールがNginxの実行ファイルに組み込まれていると、その分だけファイルサイズが大きくなり、サーバーのメモリ消費量が増えたり、Nginxの起動時間がわずかに伸びたり、リクエスト処理のわずかなオーバーヘッドにつながることがある。特に、メールサーバー機能（http_mail_module）、ストリーミング機能（http_stream_module）、地理情報機能（http_geoip_module）など、一般的なWebサーバーとしてはあまり使わないようなモジュールは、無効化することでNginxをより軽量に、効率的に動作させることができる。現在Nginxに組み込まれているモジュールを確認するには、nginx -Vコマンドを実行し、その出力から--add-dynamic-moduleや--with-の記述を探す。もし不要なモジュールが見つかった場合は、Nginxをソースコードから再コンパイルする際に、./configure --without-http_mail_module --without-http_stream_moduleのように--withoutオプションを使って、そのモジュールをNginxに組み込まないように指定する。これにより、Nginxの実行ファイルがスリム化され、メモリ使用量が削減され、ワーカープロセスがより速く起動するなどのメリットが得られる。

六つ目は、ワーカープロセスとコネクション数の調整だ。Nginxは、ユーザーからのリクエストを実際に処理するために「ワーカープロセス」という複数の独立したプロセスを起動する。これらのワーカープロセスが、同時並行で多くのユーザーからの接続を受け付け、Webコンテンツを配信する役割を果たす。worker_processes auto;という設定は、サーバーのCPUコア数に合わせて自動的に最適なワーカープロセス数を設定してくれるため、サーバーのCPUリソースを最大限に活用できる。これにより、多数の同時接続を効率的に処理し、サーバーのスケーラビリティが向上する。また、worker_rlimit_nofile 65535;は、各ワーカープロセスが同時に開けるファイルディスクリプタ（ファイルやネットワーク接続など、OSが管理するリソースの識別子）の最大数を増やす設定で、これにより大量の同時接続に対応できる基盤を強化する。eventsブロック内では、worker_connections 8192;と設定することで、各ワーカープロセスが同時に処理できる接続数の上限を8192に設定している。これは、1つのワーカープロセスが約8000件もの同時接続を処理できることを意味する。multi_accept on;は、ワーカープロセスが一度に複数の新しい接続を受け入れることを許可し、use epoll;はLinux環境で高性能なイベント処理機構であるepollを使用するようNginxに指示することで、多数の同時接続を非常に効率的に管理し、全体のパフォーマンスを向上させる。これらの設定を適切に行うことで、Nginxはサーバーのハードウェアリソースを最大限に活用し、大量のトラフィックにも安定して応答できるようになる。

最後は、継続的な監視と負荷テストだ。Nginxの設定変更を行った後は、その変更が実際にWebサイトのパフォーマンスにどのような影響を与えたのかを客観的に評価することが非常に重要となる。感覚的な判断ではなく、数値に基づいて効果を測定し、問題がないかを確認するために、「継続的な監視」と「負荷テスト」は欠かせない。負荷テストツール（例えばwrkやheyなど）を使用することで、設定変更前と変更後でサーバーがどれくらいのアクセスに耐えられるか、応答速度がどう変化したかを具体的に比較できる。例えば、wrk -t2 -c200 -d10s https://example.com/というコマンドは、2つのスレッドと200の同時接続で10秒間、指定されたURLに負荷をかけるシンプルなテストを実行する。これにより、サーバーの平均応答時間やエラー率などを測定し、パフォーマンスの改善や劣化を把握できる。また、GrafanaやPrometheusといった監視ツールを導入し、NginxのHTTPリクエストの処理時間（http_request_duration_secondsなどのメトリック）を継続的に収集・監視するシステムを構築することも推奨される。この監視システムにより、WebサイトのTTFBやその他の重要なパフォーマンス指標がリアルタイムでどのように変動しているかを常に把握し、設定変更による予期せぬパフォーマンス低下（リグレッション）や、特定の時間帯におけるアクセス増加による負荷増大などを早期に検知できる。例えば、リクエストの95%が100ミリ秒以上かかった場合にアラートを出すように設定すれば、問題が発生した際に迅速に対応できる。このように、常にパフォーマンスを監視し、定期的に負荷テストを実施することで、Nginxの最適な動作状態を維持し、ユーザーに快適なWeb体験を提供し続けることができる。

まとめとして、Nginxのパフォーマンスを向上させるこれらの方法は、Brotliの導入、Gzipの最適化、TLS設定の改善、適切なキャッシュヘッダーの利用、不要なモジュールの削除、ワーカープロセスの調整、そして継続的な監視と負荷テストという多角的なアプローチから構成されている。これらの改善策は、すべてを一度に適用するのではなく、一つずつ慎重に適用し、Webpagetest.orgのようなツールでその効果を検証し、もし予期せぬ問題（リグレッション）が見つかった場合には元の設定に戻す、という段階的なプロセスを踏むことが推奨される。この丁寧なアプローチにより、TTFBを確実に数ミリ秒の低レベルにまで引き下げ、Webサイト全体の速度とユーザーエクスペリエンスを大幅に向上させることが可能となるだろう。