Nginxキャッシュ：すべてが新しい-忘れられていた古い

すべてのプロジェクトの寿命の中で、サーバーがSLA要件を満たすのをやめ、文字通り着信トラフィックの量を抑制し始めるときが来ます。 その後、ボトルネック、重いクエリ、誤って作成されたインデックス、キャッシュされていないデータ、またはその逆、キャッシュ内の頻繁に更新されるデータ、およびプロジェクトの他のダークサイドを見つける長いプロセスが始まります。



しかし、コードが「完璧」で、大量のリクエストがすべてバックグラウンドに配置され、可能なすべてがキャッシュされ、必要なSLAインジケーターにサーバーがまだ到達していない場合はどうすればよいでしょうか。 可能であれば、もちろん、新しい車を購入し、トラフィックの一部を分配し、しばらくの間問題を忘れることができます。



しかし、サーバーがより多くの能力を持っていると感じている場合、またはサイトを100倍高速化するマジックパラメーターがある場合は、バックエンドからの応答をキャッシュできる組み込みのnginx機能を思い出すことができます。 それが何であるか、そしてそれがサーバーによって処理されるリクエストの数を増やすのにどのように役立つかを見てみましょう。

Nginxキャッシュとは何ですか？

Nginxキャッシュは、バックエンドのリクエスト数を大幅に削減できます。 これは、一定時間HTTP応答を保存し、リソースに再度アクセスするときに、バックエンドのリクエストをプロキシせずにキャッシュからリソースを返すことで実現されます。 キャッシングは、たとえ短期間であっても、サーバーによって処理されるリクエストの数を大幅に増加させます。



nginxの構成に進む前に、「ngx_http_proxy_module」モジュールで構成されていることを確認する必要があります。このモジュールで構成するためです。



便宜上、構成を別のファイル、たとえば「/etc/nginx/conf.d/cache.conf」に転送できます。 キャッシュストレージ設定を構成できるproxy_cache_pathディレクティブを見てみましょう。

proxy_cache_path /var/lib/nginx/proxy_cache levels=1:2 keys_zone=proxy_cache:15m max_size=1G;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「/ Var / lib / nginx / proxy_cache」は、サーバー上のキャッシュストレージパスを指定します。 nginxがバックエンドからの応答とともにファイルを保存するのはこのディレクトリです。 同時に、nginxはキャッシュ用のディレクトリを個別に作成しません。これを自分で処理する必要があります。



「レベル= 1：2」-キャッシュを使用してディレクトリのネストのレベルを設定します。 ネストレベルは「：」で示されます。この場合、2つのディレクトリが作成され、合計3つのネストレベルが許可されます。 ネストレベルごとに、ディレクトリ名の作成方法を示す1〜2の値を使用できます。



重要な点は、ディレクトリ名がランダムに選択されるのではなく、ファイル名に基づいて作成されることです。 ファイル名は、キャッシュキーのmd5関数の結果であり、キャッシュキーについては後で検討します。



実際にキャッシュファイルへのパスがどのように構築されるかを見てみましょう。

 /var/lib/nginx/proxy_cache/2/49/07edcfe6974569ab4da6634ad4e5d492
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

「Keys_zone = proxy_cache：15m」パラメーターは、共有メモリ内のゾーンの名前を設定します。ここには、すべてのアクティブなキーとキーに関する情報が格納されます。 「：」は、割り当てられたメモリのサイズをMB単位で示します。 nginxによると、8 MBのキーを保存するには1 MBで十分です。



「Max_size = 1G」は、すべてのページの最大キャッシュサイズを定義します。これを超えると、nginxは必要のないデータを削除します。



キャッシュ内のデータのライフタイムを制御することもできます。このため、デフォルトで10分である「proxy_cache_path」ディレクティブの「inactive」パラメーターを定義するだけで十分です。 「非アクティブ」パラメータで指定された時間内にキャッシュデータへの呼び出しがなかった場合、キャッシュがまだ「サワー」ではない場合でも、このデータは削除されます。



このキャッシュはどのようなものですか？ これは実際にはサーバー上の通常のファイルであり、その内容が書き込まれます。



•キャッシュキー。

•キャッシュヘッダー。

•バックエンドからのコンテンツ応答。



ヘッダーとバックエンドからの応答がすべて明確な場合は、「キャッシュキー」に対するいくつかの質問があります。 どのように構築され、どのように管理されますか？



nginxでキャッシュキーを構築するためのテンプレートを記述するために、proxy_cache_keyディレクティブがあります。このディレクティブでは、文字列がパラメーターとして指定されます。 文字列は、nginxで使用可能な変数で構成できます。



例：

 proxy_cache_key $request_method$host$orig_uri:$cookie_some_cookie:$arg_some_arg;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

cookieパラメーターとgetパラメーターの間の「：」記号は、キャッシュキー間の衝突を防ぐために使用されます。他の任意の記号を選択できます。 デフォルトでは、nginxは次の行を使用してキーを生成します。

 proxy_cache_key $scheme$proxy_host$request_uri;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

キャッシングをより柔軟に管理するのに役立つ次のディレクティブに注意する必要があります。



proxy_cache_valid-応答のキャッシュ時間を指定します。 応答の特定のステータス、たとえば200、302、404などを示すことも、「any」構造を使用してすべてを一度に示すこともできます。 キャッシュ時間のみを指定すると、nginxはデフォルトで200、301、および302ステータスのみをキャッシュします。



例：

 proxy_cache_valid 15m; proxy_cache_valid 404 15s;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、ステータス200、301、302のキャッシュライフタイムを15分に設定します（特定のステータスを指定しなかったため、nginxはデフォルトでこれらを使用します）。 次の行では、ステータスが404の応答に対してのみ、キャッシュ時間を15秒に設定します。



proxy_cache_lock-このディレクティブは、キャッシュのセットの直後にバックエンドへの複数のパスを回避するのに役立ちます。「オン」の位置に値を設定するだけです。 他のすべての要求は、キャッシュ内の応答、またはページへの要求をブロックするためのタイムアウトを待ちます。 したがって、すべてのタイムアウトを構成できます。



proxy_cache_lock_age-サーバーからの応答にタイムアウト制限を設定できます。その後、キャッシュが設定された後、次のリクエストがサーバーに送信されます。 デフォルトは5秒です。



proxy_cache_lock_timeout-ロックを待機する時間を指定します。その後、リクエストはバックエンドに送信されますが、レスポンスはキャッシュされません。 デフォルトは5秒です。



proxy_cache_use_stale-廃止されたキャッシュを使用できる場合に設定できる別の便利なディレクティブ。



例：

 proxy_cache_use_stale error timeout updating;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、接続エラー、要求の送信、サーバーからの応答の読み取り、要求の送信の待機制限の超過、サーバーからの応答の読み取り、またはキャッシュ内のデータが要求時に更新された場合に、古いキャッシュを使用します。



proxy_cache_bypass -nginxがキャッシュからの応答を受け取らず、すぐにリクエストをバックエンドにリダイレクトする条件を指定します。 パラメータの少なくとも1つが空ではなく、「0」に等しくない場合。 例：

 proxy_cache_bypass $cookie_nocache $arg_nocache;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

proxy_no_cache -nginxがバックエンドからの応答をキャッシュに保存しない条件を指定します。 操作の原則は、proxy_cache_bypassディレクティブの原則と同じです。

ページキャッシュで起こりうる問題

前述のとおり、nginxはHTTP応答のキャッシュとともに、バックエンドから受信したヘッダーを保存します。 サイトでセッションを使用している場合、セッションCookieもキャッシュされます。 キャッシュしてラッキーだったページにアクセスしたすべてのユーザーは、セッションに保存された個人データを受け取ります。



次に直面する課題は、キャッシュ管理です。 もちろん、2〜5分のマイナーキャッシュ時間を設定できます。ほとんどの場合、これで十分です。 しかし、これはすべての状況に適用できるわけではないため、自転車を再発明します。 さあ、まず最初に。



Cookieストレージ管理



nginx側でのキャッシュには、設計上の制限がいくつかあります。 たとえば、ユーザーがバックエンドに到達しないため、キャッシュされたページでセッションを使用することはできません。別の制限は、バックエンドによるCookieの配信です。 nginxはすべてのヘッダーをキャッシュするため、他のユーザーのセッションをキャッシュに保存しないように、キャッシュされたページのCookieの配信を禁止する必要があります。 proxy_ignore_headersディレクティブはこれに役立ちます。 引数には、バックエンドから無視する必要があるヘッダーがリストされます。



例：

 proxy_ignore_headers "Set-Cookie";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この行では、プロキシサーバーからのCookieのインストールは無視されます。つまり、ユーザーは「Set-Cookies」ヘッダーのない応答を受け取ります。 したがって、バックエンドがCookieに書き込もうとしたものはすべて、クライアント側では無視されます。これは、それが何かを目的としていることすら知らないためです。 このCookieの制限は、アプリケーションを開発するときに考慮する必要があります。 たとえば、認証を要求するために、ユーザーがセッションCookieを受信できるように、ヘッダーの無視を無効にすることができます。



セッションの存続時間も考慮する必要があります。これは、php.ini構成の「 session.gc_maxlifetime 」パラメーターで確認できます。 ユーザーがサイトにログインしてニュースフィードの表示を開始したと想像してください。すべてのデータは既にnginxキャッシュにあります。 しばらくすると、ユーザーは自分の承認が消えたことに気付き、再び承認プロセスを実行する必要がありますが、この間ずっとニュースを見ていました。 これは、nginxがリクエストをバックエンドに送信せずにキャッシュからすべてのリクエストに結果を返したために発生しました。 そのため、バックエンドはユーザーが非アクティブであると判断し、「 session.gc_maxlifetime 」で指定された時間が経過するとセッションファイルを削除しました。



これを防ぐために、バックエンドリクエストをエミュレートできます。 たとえば、ajaxを介してバックエンドに渡されることが保証されるリクエストを送信します。 nginxキャッシュを通過してバックエンドに到達するには、POSTリクエストを送信するだけです。「proxy_cache_bypass」ディレクティブのルールを使用するか、このページのキャッシュを無効にすることもできます。 リクエストは何かを返す必要はありません。セッションを開始する1行のファイルでもかまいません。 このようなリクエストの目的は、ユーザーがサイトにいる間のセッションの寿命を延ばすことであり、nginxはキャッシュされたデータをすべてのリクエストに慎重に提供します。



キャッシュフラッシュ管理



最初に、要件、私たちが達成しようとしている目標を決定する必要があります。 私たちのサイトに、人気のあるスポーツイベントのテキストブロードキャストを含むセクションがあるとします。 キャッシュからページを読み込むと、すべての新しいメッセージがソケットに届きます。 15分前ではなく、ユーザーが現在のメッセージを最初のブート時の現在の時刻に表示できるようにするには、nginxキャッシュをいつでも独立してクリアできる必要があります。 同時に、nginxはアプリケーションと同じマシン上にない場合があります。 また、リセットの要件の1つは、複数のページのキャッシュを一度に削除できることです。



ソリューションの記述を開始する前に、nginxがすぐに使用できるものを見てみましょう。 キャッシュをリセットするために、nginxには「proxy_cache_purge」と呼ばれる特別なディレクティブがあり、キャッシュをリセットする条件を記録します。 条件は実際には通常の文字列で、空ではなく「0」ではない場合、渡されたキーによってキャッシュを削除します。 小さな例を考えてみましょう。

 proxy_cache_path /data/nginx/cache keys_zone=cache_zone:10m; map $request_method $purge_method { PURGE 1; default 0; } server { ... location / { proxy_pass http://backend; proxy_cache cache_zone; proxy_cache_key $uri; proxy_cache_purge $purge_method; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例は、nginxの公式Webサイトから取られています。



$ purge_method変数は、キャッシュをフラッシュします。これは、proxy_cache_purgeディレクティブの条件であり、デフォルトで0に設定されています。 これは、nginxが「通常」モードで動作することを意味します（バックエンドからの応答を保存します）。 ただし、リクエストメソッドを「PURGE」に変更すると、応答を保存してバックエンドのリクエストをプロキシする代わりに、対応するキャッシュキーを使用してキャッシュエントリが削除されます。 キャッシュキーの最後に「*」記号を指定して、削除マスクを指定することもできます。 したがって、ディスク上のキャッシュの場所とキー形成の原理を知る必要はありません。nginxはこれらの責任を引き受けます。 しかし、このアプローチには欠点もあります。

• proxy_cache_purgeディレクティブは、商用サブスクリプションの一部として利用できます。
• キャッシュをポイントごとに削除するか、{cache key}“ *”の形式のマスクによってのみ削除できます。

キャッシュされたページのアドレスは、共通部分がなくても完全に異なる可能性があるため、マスク「*」とディレクティブ「proxy_cache_purge」を使用したアプローチは適していません。 少しの理論を思い出して、あなたの好きなアイデアを発見することは残っています。



nginxキャッシュはサーバー上の通常のファイルであることを知っています。 「proxy_cache_path」ディレクティブでキャッシュファイルを保存するディレクトリを個別に指定し、「levels」を使用してこのディレクトリからファイルへのパスを形成するロジックも指定しました。 不足しているのは、キャッシュキーの正しい構成だけです。 しかし、「proxy_cache_key」ディレクティブでも確認できます。 今やるべきことは、次のとおりです。

• proxy_cache_keyディレクティブに示されているとおりに、ページへのフルパスを形成します。
• 結果の文字列をmd5でエンコードします。
• 「levels」パラメーターのルールを使用して、ネストされたディレクトリを作成します。
• そして、サーバー上のキャッシュファイルへの完全なパスが既にあります。 あとは、このファイルを削除するだけです。 導入部から、nginxがアプリケーションマシン上にない可能性があることがわかっているため、複数のアドレスを一度に削除できるようにする必要があります。 ここでも、アルゴリズムについて説明します。
• ファイルに書き込むキャッシュファイルへの生成されたパス。
• アプリケーションと一緒にマシンに置く簡単なbashスクリプトを書きましょう。 彼のタスクは、sgin経由でnginxをキャッシュしているサーバーに接続し、ステップ1で生成されたファイルで指定されたすべてのキャッシュファイルを削除することです。

理論から実践に移り、作業のアルゴリズムを示す小さな例を作成しましょう。



手順1.キャッシュへのパスを含むファイルを生成します。

 $urls = [ 'httpGETdomain.ru/news/111/1:2', 'httpGETdomain.ru/news/112/3:4', ]; function to_nginx_cache_path(url) { $nginxHash = md5($url); $firstDir = substr($nginxHash, -1, 1); $secondDir = substr($nginxHash, -3, 2); return "/var/lib/nginx/proxy_cache/$firstDir/$secondDir/$nginxHash"; } //        tmp $filePath = tempnam('tmp', 'nginx_cache_'); //      $fileStream = fopen($filePath, 'a'); foreach ($urls as $url) { //      $cachePath = to_nginx_cache_path($url); //       fwrite($fileStream, $cachePath . PHP_EOL); } //     fclose($fileStream); //  bash       exec("/usr/local/bin/cache_remover $filePath");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変数$ urlsには、キャッシュされたページのURLが含まれており、nginx構成で指定されたproxy_cache_keyの形式に既になっていることに注意してください。 URLは、ページに表示されるエンティティのタグとして機能します。 たとえば、データベースに通常のテーブルを作成し、各エンティティが表示される特定のページにマッピングされるようにすることができます。 次に、データを変更するときに、テーブルで選択を行い、必要なすべてのページのキャッシュを削除できます。



手順2.キャッシュサーバーに接続し、キャッシュファイルを削除します。

 #      ,      FILE_LIST=`cat $1 | tr "\n" " "` #   ssh  SSH=`which ssh` USER="root" #         nginx HOST="10.10.1.0" #   KEY="/var/keys/id_rsa" # SSH ,          $SSH -i ${KEY} ${USER}@${HOST} "rm -f ${FILE_LIST}" #       rm -rf rm -f $1 #  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例はガイダンスのみであり、本番環境では使用しないでください。 例では、入力パラメーターのチェックとコマンドの制限は省略されています。 発生する可能性のある問題の1つは、rmコマンドの引数の長さを制限することです。 少量の開発環境でテストする場合、これは簡単に見落とされる可能性があり、実稼働環境では、「rm：Argument list too long」というエラーが表示されます。

カスタムブロックキャッシング

なんとかしてやろう：

• バックエンドの負荷を軽減しました。
• キャッシングを管理する方法を学ぶ
• 常にキャッシュをフラッシュすることを学びました。

しかし、すべてが一見すると思えるかもしれません。 おそらく、最初ではないにしても、正確には2番目のサイトすべてに登録/承認機能があり、通過後、ヘッダーのどこかにユーザー名を表示することになります。 名前の付いたブロックは一意であり、承認されたユーザー名を表示する必要があります。 nginxはバックエンドからの応答を保存するため、ページの場合はページのhtmlコンテンツであるため、個人データを含むブロックもキャッシュされます。 サイトへのすべての訪問者には、キャッシュセットのバックエンドに渡された最初のユーザーの名前が表示されます。

したがって、バックエンドは、個人情報がnginxキャッシュに該当しないように、個人情報が配置されているブロックを提供しないでください。



ページのこのような部分の代替ロードを検討する必要があります。 いつものように、これは多くの方法で行うことができます。たとえば、ページをロードした後、ajaxリクエストを送信し、個人コンテンツの代わりにローダーを表示します。 今日検討する別の方法は、ssiタグを使用することです。 最初にSSIとは何かを理解してから、それをnginxキャッシュと組み合わせて使用​​する方法を理解しましょう。

SSIとは何ですか？

SSI（サーバー側インクルード、サーバー側インクルード）は、サーバーに何をするかを指示するHTMLページに埋め込まれたコマンドのセットです。



そのようなコマンド（ディレクティブ）のリストは次のとおりです。



•if / elif / else / endif-分岐演算子。

•echo-変数の値を表示します。

•include-別のファイルの内容をドキュメントに挿入できます。

最後の指令についてのみ説明します。 includeディレクティブには2つのパラメーターがあります。

•file-サーバー上のファイルへのパスを指定します。 現在のディレクトリについて。

•virtual-サーバー上のドキュメントへの仮想パスを示します。



サーバー上のファイルへのフルパスを指定することは必ずしも便利ではないため、「仮想」パラメーターに関心があります。分散アーキテクチャーの場合、サーバー上のファイルは単に存在しません。 ディレクティブの例：

 <!--#include virtual="/user/personal_news/"-->
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nginxがssi挿入の処理を開始するには、次のように場所を変更する必要があります。

 location / { ssi on; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、ロケーション「/」で処理されたすべてのリクエストがssi挿入を実行できます。



私たちのリクエストはこのスキーム全体をどのように通り抜けますか？

• クライアントがページを要求します。
• Nginxはバックエンドのリクエストをプロキシします。
• バックエンドは、ページにssi挿入を提供します。
• 結果はキャッシュに保存されます。
• Nginxは、欠落しているブロックを「照会」します。
• 結果のページがクライアントに送信されます。

手順からわかるように、ssiコンストラクトはnginxキャッシュに入ります。これにより、個人ブロックはキャッシュされず、クライアントにはすべての挿入を含む既製のhtmlページが送信されます。 ここでロードが機能し、nginxは欠落しているページブロックを個別に要求します。 しかし、他のソリューションと同様に、このアプローチには長所と短所があります。 ユーザーによって表示が異なる複数のブロックがページにあり、そのような各ブロックがssi挿入に置き換えられることを想像してください。 Nginxは、予想どおり、このような各ブロックをバックエンドから要求します。つまり、ユーザーからの1つの要求は、バックエンドに対していくつかの要求をすぐに生成しますが、これはまったく必要ありません。

ssiを介した永続的なバックエンドリクエストの削除

この問題を解決するには、nginxモジュール「ngx_http_memcached_module」が役立ちます。 このモジュールでは、memcachedサーバーから値を受け取ることができます。 モジュールを介した書き込みは機能しません。アプリケーションサーバーがこれを処理する必要があります。 モジュールと組み合わせてnginxを設定する小さな例を考えてみましょう：

 server { location /page { set $memcached_key "$uri"; memcached_pass 127.0.0.1:11211; error_page 404 502 504 = @fallback; } location @fallback { proxy_pass http://backend; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

変数$ memcache_keyで、nginxがmemcacheからデータを取得しようとするキーを指定しました。 memcacheサーバーに接続するためのパラメーターは、memcached_pa​​ssディレクティブで設定されます。 接続はいくつかの方法で指定できます。



•ドメイン名。

 memcached_pass cache.domain.ru;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

•IPアドレスとポート。

 memcached_pass localhost:11211;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

•UNIXソケット。

 memcached_pass unix:/tmp/memcached.socket;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

•アップストリームディレクティブ。

 upstream cachestream { hash $request_uri consistent; server 10.10.1.1:11211; server 10.10.1.2:11211; } location / { ... memcached_pass cachestream; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

nginxがキャッシュサーバーから応答を得ることができた場合、クライアントにそれを提供します。 キャッシュにデータがない場合、リクエストは「@fallback」を介してバックエンドに送信されます。 nginxの下でのmemcachedモジュールのこの小さな構成は、ssi挿入からのバックエンドのリクエストの受け渡し回数を減らすのに役立ちます。



この記事がお役に立てば幸いです。サーバーの負荷を最適化する方法の1つを示し、nginxキャッシングを設定する基本原則を検討し、使用時に発生する問題を解決できました。