NGINX Plusの機能: キャッシュ

最もよく利用されているNGINX Plusのユースケースとして、ローカル オリジン サーバの処理速度を高め、コンテンツ デリバリ ネットワーク(CDN)のエッジ サーバを作成するためのコンテンツ キャッシュがあります。キャッシングにより、コンテンツのキャッシュ可能性とユーザ トラフィックのプロファイルに応じてオリジン サーバの負荷を大幅に軽減できます。

NGINX PlusではアップストリームのHTTPサーバから取得したコンテンツと、FastCGI、SCGI、およびuwsgiサービスから返された応答をキャッシュできます。

NGINX Plusでは、キャッシュ削除のサポートを追加し、ライブ アクティビティ監視ダッシュボードでのキャッシュ ステータスの可視化を強化することで、NGINX Open Sourceのコンテンツ キャッシュ機能を拡張しました。

cache-state-R7

コンテンツ キャッシュを使用する理由

コンテンツ キャッシュにより、Webページの読み込み時間が改善され、アップストリーム サーバでの読み込み回数が減り、オリジン サーバで障害が発生した場合にバックアップとしてキャッシュされたコンテンツを使用することで可用性が向上します。

  • サイト パフォーマンスの向上 – NGINX Plusは、あらゆる種類のキャッシュされたコンテンツを、静的なコンテンツの場合と同じ速度で提供します。つまり、レイテンシが低下し、Webサイトの応答性が向上します。
  • キャパシティの増加 – NGINX Plusによりオリジン サーバの反復作業がオフロードされ、キャパシティが解放されるため、より多くのユーザに対してサービスを提供し、より多くのアプリケーションを実行できるようになります。
  • 可用性の向上 – NGINX Plusは、オリジン サーバがダウンするとキャッシュされたコンテンツ(古くなったコンテンツを含む)を提供して、ユーザを致命的なエラーから保護します。

NGINX PlusとNGINXは、Webインフラストラクチャのための統合ソリューションであり、オリジン コンテンツのHTTPサーバ、FastCGIやその他のプロトコルのアプリケーション ゲートウェイ、アップストリーム サーバのHTTPプロキシを提供します。NGINX Plusはそれらに加えてエンタープライズグレードのロード バランシングを提供し、Webインフラストラクチャにフロントエンドのロード バランサを統合します。

NGINX Plusでのコンテンツ キャッシュの詳細

キャッシュされたコンテンツはディスクの永続キャッシュに格納され、オリジン コンテンツと全く同じ方法でNGINX PlusおよびNGINXにより処理されます。

コンテンツ キャッシュを有効にするには、設定でproxy_cache_pathディレクティブとproxy_cacheディレクティブを指定します。

# Define a content cache location on disk
proxy_cache_path /tmp/cache keys_zone=mycache:10m inactive=60m;

server {
    listen 80;
    server_name localhost;
 
    location / {
        proxy_pass http://localhost:8080;
 
       # reference the cache in a location that uses proxy_pass
       proxy_cache mycache;
    }
}

デフォルトでは、NGINX PlusとNGINXは安全で慎重なコンテンツ キャッシング アプローチを取ります。GETリクエストまたはHEADリクエストで取得したコンテンツをキャッシュし、Set-Cookie応答を使用しません。キャッシュ時間はオリジンサーバ ヘッダ(X-Accel-Expires、Cache-Control、Expires)により定義されます。NGINX PlusはRFC 5861で定義されているCache-Control拡張、stale-while-revalidate、およびstale-if-errorに準拠します。

それぞれの動作は、さまざまなディレクティブを使用して拡張、細かく調整できます。詳しいい概要については、NGINX Plus Admin Guideをご覧ください。

キャッシュのインストルメンテーション

NGINX Plusのライブ アクティビティ監視APIでは、コンテンツ キャッシュの使用状況と効果性の測定に使用できるさまざまな統計情報が報告されます。

ライブ アクティビティ監視APIからのJSONデータの例

このJSONデータには、キャッシュ アクティビティに関する詳細な情報が含まれています。

古くなったコンテンツの管理

デフォルトでは、NGINX PlusとNGINXはキャッシュされたコンテンツをその有効期間にわたって提供します。有効性は設定可能であり、またオリジン サーバにより設定されたCache-Controlヘッダで制御できます。有効期間の経過後は、キャッシュされたコンテンツは古くなったと見なされ、再検証が必要になります。再検証では、そのコンテンツがオリジン サーバのコンテンツと同じであるかどうかが確認されます。

古くなったコンテンツがクライアントからリクエストされる可能性はほぼありません。このため、NGINX PlusとNGINXは、古くなったコンテンツがクライアントからリクエストされた場合にのみ、そのコンテンツを再検証します。この処理はバックグラウンドで実行されるため、古くなったコンテンツを即時に提供することで、中断やクライアント リクエストの遅延が発生することはありません。オリジン サーバが使用できない場合にも古くなったコンテンツが提供され、ピークロード時やオリジン サーバが長期停止している場合などに高い可用性を実現します。

NGINXとNGINX Plusが古くなったコンテンツを提供する条件を設定できます。この条件を設定するには、ディレクティブを使用するか、またはオリジン サーバのCache-Controlヘッダ、stale-while-revalidate、stale-if-errorの値に従います。

キャッシュからのコンテンツの削除

コンテンツ キャッシュの副作用の1つに、オリジン サーバでのコンテンツ更新が、必ずしもキャッシュに即時に伝搬されないことがあります。つまり、一定期間にわたってクライアントに古いコンテンツが提供される可能性があります。更新操作によって多数のリソースが一度に変更される場合(CSSファイルと参照画像の変更など)、古くなったコンテンツと最新のコンテンツの両方がクライアントに提供され、整合性のない表示内容になる可能性があります。

この問題は、NGINX Plusのキャッシュ削除機能により簡単に解決できます。proxy_cache_purgeディレクティブを使用して、設定されている値に一致するエントリをNGINX Plusのコンテンツ キャッシュから即時に削除できます。このメソッドは、カスタムHTTPヘッダまたはメソッドを含むリクエストからとても簡単にトリガーできます。

たとえば以下の設定では、PURGE HTTPメソッドを使用するリクエストが特定され、一致するURLが削除されます。

proxy_cache_path /tmp/cache keys_zone=mycache:10m levels=1:2 inactive=60s;

map $request_method $purge_method {
    PURGE 1;
    default 0;
}

server {
    listen 80;
    server_name www.example.com;

    location / {
        proxy_pass http://localhost:8002;
        proxy_cache mycache;

        proxy_cache_purge $purge_method;
    }
}

削除リクエストはさまざまなツールを使用して発行できます。次にcurlコマンドを使用する例を示します。

$ curl -X PURGE -D – "http://www.example.com/*"
HTTP/1.1 204 No Content
Server: nginx/1.5.12
Date: Sat, 03 May 2014 16:33:04 GMT
Connection: keep-alive

この例に示すように、URLにアスタリスク(*)ワイルドカードを付加することで、共通のURLステムを持つすべてのリソースを削除できます。

詳細情報

NGINX Plusは、NGINXのすべてのキャッシュ機能を継承しています。詳しくは、NGINX Plus Admin Guideおよび参照ドキュメントをご覧ください。

次のステップ