お問い合わせ

info@serverion.com

お電話ください

+1 (302) 380 3902

NGINX Config Rewind: Serverion がプロキシキャッシュチューニングの失われた技術を復活させる

NGINX Config Rewind: Serverion がプロキシキャッシュチューニングの失われた技術を復活させる

ウェブサイトの高速化とサーバー負荷の低減をお望みですか? NGINXプロキシキャッシュが解決策です。頻繁にリクエストされるコンテンツを保存することで、配信速度が向上し、オリジンサーバーの負荷が軽減されます。 Serverion キャッシュ設定を最適化してパフォーマンスと信頼性を向上させるための実用的なヒントを紹介します。

重要なポイント:

  • 古いコンテンツを提供する: サーバーのダウンタイム中にキャッシュされたレスポンスを使用する proxy_cache_use_stale.
  • バックグラウンド更新: ユーザーの邪魔をすることなくキャッシュエントリを更新します プロキシキャッシュのバックグラウンド更新.
  • 過負荷を防ぐ: オリジンサーバーに過負荷をかけないように プロキシキャッシュロック.

設定例:

proxy_cache_path /var/cache/nginx レベル=1:2 キーズゾーン=my_cache:10m 最大サイズ=10g 非アクティブ=60m use_temp_path=オフ; proxy_cache my_cache; proxy_cache_use_stale 更新中; proxy_cache_background_update オン; proxy_cache_lock オン; 

これらの設定により、高速な応答、効率的なリソース使用、そして信頼性の高いコンテンツ配信が保証されます。 小規模VPS またはトラフィック量の多いサーバーの場合、これらのテクニックは NGINX プロキシ キャッシュを最大限に活用するのに役立ちます。

NGINX: リバース プロキシを使用したコンテンツ キャッシュ (超高速…)

NGINX

NGINX プロキシキャッシュの基礎

Serverionのキャッシュチューニング技術は、NGINXプロキシキャッシュの中核原理に基づいています。NGINXプロキシキャッシュは、オリジンコンテンツのコピーを保存・提供するものです。このシステムは、キャッシュパス、共有メモリゾーン、そしてキャッシュが上限に達した際に期限切れまたはLRU(Least-Recently Used)ファイルを削除するキャッシュマネージャーという3つの主要コンポーネントを使用します。

NGINXプロキシキャッシュ操作

NGINXはリクエストを処理する際、まず共有メモリ領域をチェックし、リクエストされたコンテンツが既にキャッシュされているかどうかを確認します。このメモリ内検索により、キャッシュヒットかミスかを迅速に判断できます。参考までに、1MBのキー領域には約8,000個のキャッシュキーを保存できます[1]。

キャッシュプロセスは次のように機能します。

  • NGINX はリクエストをハッシュして一意のキャッシュ キーを作成します。
  • そのキーの共有メモリ領域をチェックします。
  • キーが見つかった場合 (キャッシュ ヒット)、コンテンツはキャッシュから直接提供されます。
  • キーが見つからない場合 (キャッシュ ミス)、コンテンツは元のサーバーから取得され、将来使用するためにキャッシュに保存されます。

Serverion は、効率的なキー検索を保証し、ディレクトリ階層を使用してキャッシュ ストレージを整理することで、パフォーマンスを最適化します。

コアキャッシュ要素

指令 目的 インパクト
プロキシキャッシュパス キャッシュ保存場所を指定します コンテンツがキャッシュされる場所と方法を決定する
プロキシキャッシュ 特定のリクエストのキャッシュを有効にする ロケーションブロック内でのキャッシュを有効にする
キーゾーン キャッシュキー用の共有メモリを割り当てます 高速なメモリ内検索が可能
非アクティブ 未使用のアイテムがキャッシュに保持される期間を定義します キャッシュの鮮度と削除のタイミングを制御する

パフォーマンスを最大化するには、2レベルの レベル ファイルシステムの速度低下を防ぐために階層を設定します。さらに、 use_temp_path=オフ キャッシュされたファイルを最終的な場所に直接書き込むため、I/O オーバーヘッドが削減されます。

NGINXはオリジンサーバーからのキャッシュ指示を尊重します。 期限切れ 将来の日付または キャッシュ制御 ヘッダー付き 最大年齢 ゼロより大きい値。

これで、これらの原則を NGINX プロキシ キャッシュの設定に適用できるようになりました。

[1] NGINXのドキュメント:1MBのキーゾーンには約8,000個のキーのデータが保存されます。

NGINX プロキシキャッシュ設定ガイド

NGINX プロキシ キャッシュを段階的に構成および最適化する方法を学びます。

キャッシュパラメータ設定

NGINXプロキシキャッシュ設定の基礎は プロキシキャッシュパス ディレクティブ。設定例を以下に示します。

proxy_cache_path /var/cache/nginx レベル=1:2 キー_ゾーン=my_cache:10m 最大サイズ=10g 非アクティブ=60m use_temp_path=オフ; 

この設定では2階層のディレクトリ構造が作成され、 キーゾーン (約 80,000 個のキーに十分)、最大キャッシュ サイズを 10 GB に設定し、非アクティブ タイムアウトを 60 分に定義します。

より詳細な制御のために、次のオプションのディレクティブを含めることもできます。

指令 目的
proxy_cache_use_stale オリジンサーバーが利用できない場合は古いコンテンツを提供する
proxy_cache_revalidate 条件付きGETリクエストを使用して、コンテンツがまだ有効かどうかを確認します
プロキシキャッシュのバックグラウンド更新 古くなったコンテンツをバックグラウンドで更新します
プロキシキャッシュロック 複数のリクエストがオリジンサーバーに過負荷をかけるのを防ぎます

これらのパラメータを定義した後、予想されるトラフィックに基づいてメモリとディスク領域を割り当てます。

キャッシュサイズ管理

キャッシュのサイズを効果的に決定するには、メモリとディスク使用量の両方を考慮する必要があります。手順は以下のとおりです。

  • メモリゾーンのサイズ設定 メモリを割り当てる キーゾーン キャッシュのニーズに合わせて:
    keys_zone=enterprise_cache:100m; # 約80万個のキャッシュキーをサポート 
  • ディスク領域の割り当て 調整する プロキシキャッシュパス 最大ディスク容量を指定するには:
    proxy_cache_path /var/cache/nginx レベル=1:2 キー_ゾーン=enterprise_cache:100m 最大サイズ=10g 非アクティブ=24時間 use_temp_path=オフ; 

これらのパラメータを設定すると、キャッシュを初期化して有効にする準備が整います。

キャッシュの初期化

パラメータとサイズを微調整した後、次の手順に従ってキャッシュを有効にします。

  1. 使用 プロキシキャッシュパス 上記の例のディレクティブを削除し、 proxy_cache my_cache 設定に応じて。
  2. 関連する範囲内でキャッシュを有効にする サーバ または ロケーション ブロック:
    proxy_cache my_cache; 
  3. オプションで、パフォーマンスを向上させるために、前述の微調整ディレクティブのいずれかを含めます。
  4. カスタム ヘッダーを追加してキャッシュの状態を監視します。
    add_header X-Cache-Status $upstream_cache_status; 

注記: NGINXのドキュメントによると、1MBの キーゾーン 約8,000個のキーを保存できます。

この設定により、調整の柔軟性を維持しながら、キャッシュがトラフィックを効率的に処理できるようになります。

エンタープライズNGINXキャッシュ管理

キャッシュ パスとパラメータが設定されたら、エンタープライズ レベルのトラフィックを効果的に処理できるようにセットアップを拡張します。

キャッシュヒット率の最適化

キャッシュ効率を向上させるには、条件付きリクエストやバックグラウンド更新などの機能を有効にします。

proxy_cache_revalidate がオン; proxy_cache_background_update がオン; proxy_cache_use_stale が更新中; 

次の設定を構成して、オリジン サーバーの過負荷を防止します。

proxy_cache_lock オン; proxy_cache_lock_timeout 5 秒; proxy_cache_min_uses 2; 

トラフィック量の多い環境では、キャッシュ負荷を複数のストレージ デバイスに分散してパフォーマンスを向上させます。

split_clients "${request_uri}" $disk { 20% "/data/cache1"; 20% "/data/cache2"; 20% "/data/cache3"; 20% "/data/cache4"; * "/data/cache5"; } 

キャッシュのパフォーマンスが最適化されたら、機密コンテンツを処理できるようにキャッシュを保護することに重点を置きます。

キャッシュセキュリティ制御

機密性の高いリクエストを保護するには、キャッシュをバイパスし、必要に応じてキャッシュ キーをカスタマイズします。

proxy_cache_bypass $http_pragma; proxy_cache_bypass $cookie_nocache; proxy_ignore_headers Cache-Control; 

パーソナライズされたコンテンツまたは Cookie ベースのリクエストの場合は、キャッシュ キーとサポートされるメソッドを調整します。

proxy_cache_key "$host$request_uri$cookie_user"; proxy_cache_methods GET HEAD POST; 

キャッシュを保護した後は、そのパフォーマンスを継続的に監視するようにしてください。

キャッシュパフォーマンスの追跡

ステータス定義を使用してキャッシュの動作を監視し、設定を微調整します。

状態 意味
更新中 更新の進行中に古いコンテンツが提供される
再検証済み キャッシュされたコンテンツは元のサーバーで再検証されました

分析する X-キャッシュステータス 定期的にメトリックを確認し、トラフィック パターンに合わせてディレクティブを調整して、最適な結果を実現します。

ServerionNGINXキャッシュ設定

Serverion

Serverionは、各ワークロードの特定のニーズに基づいてNGINXのキャッシュ設定をカスタマイズします。コアディレクティブを使用することで、VPSとオンプレミスで異なるキャッシュ構成を最適化します。 専用サーバー.

ワークロード別のキャッシュパス

VPS ワークロード

VPS セットアップの場合、この構成はメモリ効率と高速な応答時間のバランスを実現します。

proxy_cache_path /data/nginx/cache レベル=1:2 キー_ゾーン=SERVERCACHE:10m 最大サイズ=10g 非アクティブ=60m use_temp_path=オフ; proxy_cache_key "$scheme$request_method$host$request_uri"; proxy_cache_valid 200 302 60m; proxy_cache_valid 404 1m; 

キーゾーン サイズは約 80,000 個のキーを収容できるように設定されています。

専用サーバー

専用サーバー上の高トラフィックアプリケーションの場合、Serverion は複数の SSD にわたる分散キャッシュ システムを使用します。

proxy_cache_path /cache1 レベル=1:2 キー_ゾーン=キャッシュ1:10m; proxy_cache_path /cache2 レベル=1:2 キー_ゾーン=キャッシュ2:10m; proxy_cache_path /cache3 レベル=1:2 キー_ゾーン=キャッシュ3:10m; split_clients "${request_uri}" $cachezone { 33% "キャッシュ1"; 33% "キャッシュ2"; * "キャッシュ3"; } 

この設定では、キャッシュ書き込みを3つのSSDに均等に分散します。 分割クライアント 指令。

これらの構成の具体的な値は、Serverion のキャッシュ パラメータ参照テーブルから取得されます。

インフラストラクチャ設定

パフォーマンスをさらに向上させるために、NGINX ワーカー設定はキャッシュの入力と出力を効率的に処理するように調整されます。

worker_processes auto; worker_connections 1024; worker_cpu_affinity 0-3; # ワーカーをCPUコアに合わせる 

これらの調整により、キャッシュされた応答が最大限の効率で配信されるようになります。

要約: NGINX キャッシュチューニング結果

Serverionは、 ホスティングシステム プロキシキャッシュの詳細な調整により、キャッシュ階層の改良、鮮度設定の管理、ヘッダー処理の最適化を実現し、シームレスなコンテンツ配信を維持しました。リアルタイム Xプロキシキャッシュ メトリクスにより、IT チームはキャッシュ設定を効果的に調整できるようになり、応答時間が短縮され、オリジン サーバーの負荷が軽減され、エンタープライズ運用の可用性が向上しました。

関連ブログ投稿

ja