CodeFlow

キャッシングとは何ですか？

キャッシュは、一般的に要求されるコンテンツをより高速なアクセスを可能にする方法で一時的に保存できるようにすることで、サーバーのパフォーマンスを向上させる方法です。これにより、リソースを大量に消費する操作が排除されるため、処理と配信が高速化されます。

効果的なキャッシュルールを作成することにより、キャッシュに適したコンテンツが保存され、応答時間が改善され、リソースが節約され、負荷が最小限に抑えられます。 Apacheは、さまざまな種類の操作を高速化するのに適したさまざまなキャッシュを提供します。このガイドでは、さまざまなキャッシュモジュールを使用してCentOS 7上でApache 2.4を構成する方法について説明します。

一般的なキャッシュ戦略の開発の詳細については、https：//www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies [この記事]をご覧ください。

Apacheのキャッシュの概要

Apacheは、さまざまなレベルの高度さとスケーラビリティでコンテンツをキャッシュできます。プロジェクトは、コンテンツをキャッシュする方法に従ってこれらを3つのグループに分割します。一般的な内訳は次のとおりです。

ファイルキャッシュ：最も基本的なキャッシュ戦略。これは、サーバーの起動時にファイルまたはファイル記述子を単に開き、アクセスを高速化するためにそれらを使用可能に保ちます。
キーと値のキャッシュ：主にSSLと認証のキャッシュに使用されますが、キーと値のキャッシュは共有オブジェクトモデルを使用し、繰り返し計算するのにコストのかかるアイテムを保存できます。
標準HTTPキャッシング：最も柔軟で一般的に有用なキャッシングメカニズムであるこの3状態システムは、応答を保存し、有効期限が切れたときにそれらを検証できます。これは、特定のニーズに応じて、パフォーマンスまたは柔軟性のために構成できます。

上記の説明をざっと見てみると、上記の方法にはいくつかの重複があることがわかりますが、同時に複数の戦略を使用することが役立つ場合もあります。たとえば、SSLセッションにキーと値のストアを使用し、応答用の標準HTTPキャッシュを有効にすると、データソースの負荷を大幅に軽減し、クライアントの多くのコンテンツ配信操作を高速化できます。

これで、Apacheの各キャッシュメカニズムを幅広く理解できたので、これらのシステムをさらに詳しく見てみましょう。

ファイルキャッシング

総括

関連するプライマリモジュール： + mod_file_cache +
主な使用例：サーバーの起動時にファイルの内容またはファイル記述子を保存します。これらは、サーバーが再起動されるまで確実に変更できない静的な表現です。
機能：シンプル、低速ファイルシステムのパフォーマンスを向上
欠点：実験的機能。ファイルシステムの更新に応答せず、オペレーティングシステムの制限内に収まるように控えめに使用する必要があり、静的ファイルでのみ使用できます。

詳細

`+ mod_file_cache +`モジュールは主に、ファイルシステムが遅いサーバーでのファイルアクセスを高速化するために使用されます。 2つの構成ディレクティブを選択できます。どちらも、ファイルが要求されたときではなく、サーバーが起動されたときに作業の一部を実行することにより、静的ファイルを提供するプロセスを加速します。

`+ CacheFile +`ディレクティブは、アクセスを加速したいディスク上のファイルへのパスを指定するために使用されます。 Apacheが開始されると、Apacheは指定された静的ファイルを開き、ファイルハンドルをキャッシュします。これにより、要求されたときにファイルを開く必要がなくなります。この方法で開くことができるファイルの数は、オペレーティングシステムによって設定された制限に従います。

`+ MMapFile `ディレクティブは、Apacheが最初に起動されたときにファイルも開きます。ただし、 ` MMapFile +`は、ファイルハンドラーだけでなく、ファイルのコンテンツをメモリにキャッシュします。これにより、これらのページのパフォーマンスが向上しますが、いくつかの重大な制限があります。使用したメモリ量の記録は保持されないため、メモリが不足する可能性があります。また、子プロセスは割り当てられたメモリをコピーするため、最初に予想されるよりも速くリソースが枯渇する可能性があることに注意してください。このディレクティブは慎重に使用してください。

これらのディレクティブは、Apacheの起動時にのみ評価されます。これは、Apacheが起動後に行われた変更を取得するのに信頼できないことを意味します。これらは、Apacheセッションの存続期間中は変更されない静的ファイルでのみ使用してください。ファイルの変更方法によっては、サーバーに変更が通知される場合がありますが、これは予期された動作ではなく、常に正常に動作するとは限りません。これらのディレクティブに渡されたファイルに変更を加える必要がある場合は、変更が行われた後にApacheを再起動してください。

ファイルキャッシュを有効にする方法

ファイルのキャッシュは、 `+ mod_file_cache +`モジュールによって提供されます。この機能を使用するには、モジュールを有効にする必要があります。

CentOS 7を実行すると、Apacheのインストール時にモジュールがインストールされますが、デフォルトの構成ではモジュールがロードされません。モジュールをロードするには、 `+ / etc / httpd / conf.modules.d `ディレクトリに単純なファイルを作成してモジュールをロードします。このファイルを ` 00-cache.conf +`と呼びます：

sudo nano /etc/httpd/conf.modules.d/00-cache.conf

内部では、必要な機能を有効にするために `+ LoadModule +`ディレクティブを使用する必要があります。ファイルに次の行を追加します。

/etc/httpd/conf.modules.d/00-cache.conf

LoadModule file_cache_module modules/mod_file_cache.so

完了したら、ファイルを保存して閉じます。

その後、メイン構成ファイルを編集して、ファイルキャッシュディレクティブを設定する必要があります。次を入力してファイルを開きます。

sudo nano /etc/httpd/conf/httpd.conf

ファイルハンドルのキャッシュを設定するには、 `+ CacheFile +`ディレクティブを使用します。このディレクティブは、次のように、スペースで区切られたファイルパスのリストを取ります。

/etc/httpd/conf/httpd.conf

CacheFile /var/www/html/index.html /var/www/html/somefile.index

サーバーを再起動すると、Apacheはリストされたファイルを開き、アクセスを高速化するためにファイルハンドルをキャッシュに保存します。

代わりに、いくつかのファイルをメモリに直接マップしたい場合、 `+ MMapFile +`ディレクティブを使用できます。構文は基本的に最後のディレクティブと同じです。ファイルパスのリストを取得するだけです。

/etc/httpd/conf/httpd.conf

MMapFile /var/www/html/index.html /var/www/html/somefile.index

実際には、同じファイルセットに対して_both_ `+ CacheFile `と ` MMapFile +`を設定する理由はありませんが、異なるファイルセットで両方を使用できます。

終了したら、ファイルを保存して閉じることができます。次を入力して、構成ファイルの構文を確認します。

sudo apachectl configtest

最後の行に「+ Syntax OK +」と表示されている場合、Apacheインスタンスを安全に再起動できます。

sudo systemctl restart httpd

Apacheは再起動し、使用したディレクティブに応じてファイルの内容またはハンドラーをキャッシュします。

Key-Valueキャッシング

総括

関連するプライマリモジュール： + mod_socache_dbm +、 + mod_socache_dc +、 + mod_socache_memcache +、 + mod_socache_shmcb +
関連するサポートモジュール： + mod_authn_socache +、 + mod_ssl +
主な使用例：SSLセッションまたは認証詳細の保存、SSLホチキス留め
機能：複雑なリソースを保存するための共有オブジェクトキャッシュ、SSLセッションのキャッシングとステープリング、柔軟なバックエンドを支援できます。
欠点：検証メカニズムがなく、よりパフォーマンスの高い/柔軟なバックエンドのために個別のソフトウェアを構成する必要がある、コードのバグ

詳細

キーと値のキャッシュはファイルのキャッシュよりも複雑で、より焦点を絞った利点があります。共有オブジェクトキャッシュとも呼ばれるApacheのキーバリューキャッシュは、主に、コンテンツ自体ではなく、コンテンツへのクライアントアクセスの設定に伴う高価な操作を繰り返すことを避けるために使用されます。特に、認証の詳細、SSLセッションをキャッシュし、SSLステープルを提供するために使用できます。

Note

実際のキャッシングは、共有オブジェクトキャッシングプロバイダーモジュールの1つを使用して実現されます。これらは：

* + mod_socache_dbm + *：このバックエンドは単純な `+ dbm `データベースエンジンを使用します。これは、ハッシュと固定サイズのバケットを利用するファイルベースのキーと値のストアです。このプロバイダーにはメモリリークが発生するため、ほとんどの場合、代わりに ` mod_socache_shmcb +`を使用することをお勧めします。
* + mod_socache_dc + *：このプロバイダーは、distcacheセッションキャッシングソフトウェアを使用します。このプロジェクトは2004年以降更新されておらず、一部のディストリビューションではパッケージ化されていないため、十分な注意を払って使用してください。
* + mod_socache_memcache + *：これは、アイテムの保存にmemcache分散メモリオブジェクトキャッシュを使用します。これは、複数のサーバー間の分散キャッシュに最適なオプションです。現在、エントリは適切に期限切れになりませんが、問題を修正するhttps://bz.apache.org/bugzilla/show_bug.cgi?id=55445[patch]がApacheのバージョン管理のトランクにコミットされました。
* + mod_socache_shmcb + *：現在、これはキーと値のキャッシュに最適なオプションです。これは共有メモリ内の循環バッファにキャッシュされ、いっぱいになるとエントリが削除されます。現在、https：//bz.apache.org/bugzilla/show_bug.cgi？id = 57023 [11kを超えるエントリ]で停止しています。

上記のプロバイダーモジュールに加えて、キャッシュされるオブジェクトに応じて追加のモジュールが必要になります。たとえば、SSLセッションをキャッシュするか、SSLステープルを設定するには、 + mod_ssl +`を有効にする必要があります。これにより、それぞれ `+ SSLSessionCache +`と `+ SSLStaplingCache +`ディレクティブが提供されます。同様に、認証キャッシュを設定するには、 `+ Auth_CachenCache`ディレクティブを設定できるように、 + mod_authn_socache + `モジュールを有効にする必要があります。

キーと値のキャッシュを有効にする方法

上記のバグと警告を念頭に置いて、Apacheでこのタイプのキャッシングを設定したい場合は、以下に従ってください。

キーと値のキャッシュを設定するために使用される方法は、それが何に使用され、どのプロバイダーを使用しているかによって異なります。以下では、認証キャッシュとSSLセッションキャッシュの両方の基本について説明します。

現在、https：//bz.apache.org/bugzilla/show_bug.cgi？id = 54342 [認証キャッシュのバグ]があり、キャッシュプロバイダーに引数を渡すことができません。そのため、フォールバックするデフォルト設定を提供しないプロバイダーには問題があります。

認証キャッシュ

認証キャッシュは、LDAP認証やデータベース認証などの高価な認証方法を使用している場合に役立ちます。これらのタイプの操作は、認証要求が行われるたびにバックエンドにヒットする必要がある場合、パフォーマンスに大きな影響を与える可能性があります。

キャッシュの設定には、既存の認証設定の変更が含まれます（このガイドでは認証の設定方法については説明しません）。変更自体は、バックエンドの認証方法に関係なくほぼ同じです。デモンストレーションには `+ mod_socache_shmcb`を使用します。このモジュールは、 `+ / etc / httpd / conf.modules.d / 00-base.conf +`ファイルですでに有効になっています。

メインのApache構成ファイルを開いて、認証で使用するこの共有キャッシュバックエンドを指定できるようにします。

sudo nano /etc/httpd/conf/httpd.conf

内部で、ファイルの上部に、 `+ AuthnCacheSOCache `ディレクティブを追加します。プロバイダーとして「 shmcb +」を使用することを指定します。オプションの受け渡しを妨げる前述のバグがこれを読むまでに修正されている場合、キャッシュの場所とサイズを指定できます。数値はバイト単位であるため、コメント付きの例では512キロバイトのキャッシュが生成されます。

/etc/httpd/conf/httpd.conf

AuthnCacheSOCache shmcb

# If the bug preventing passed arguments to the provider gets fixed,
# you can customize the location and size like this
#AuthnCacheSOCache shmcb:${APACHE_RUN_DIR}/auth_cache(512000)

完了したら、ファイルを保存して閉じます。

次に、認証が構成されている仮想ホスト構成ページを開きます。 `+ / etc / httpd / conf.d `ディレクトリ内にある ` site.conf +`という仮想ホスト設定を使用していると仮定しますが、環境を反映するように変更する必要があります。

sudo nano /etc/httpd/conf.d/site.conf

認証を使用してセットアップされた基本的な仮想ホストは、次のようになります。

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   <Directory /var/www/html/private>
       AuthType Basic
       AuthName "Restricted Files"
       AuthUserFile /etc/httpd/.htpasswd
       AuthBasicProvider file
       Require valid-user
   </Directory>
</VirtualHost>

認証を構成した場所で、ブロックを変更してキャッシュを追加します。具体的には、キャッシュする認証ソースを伝えるために `+ AuthnCacheProvideFor `を追加し、 ` AuthnCacheTimeout `でキャッシュタイムアウトを追加し、従来の認証方法の前に ` AuthBasicProvider `リストに ` socache +`を追加する必要があります。結果は次のようになります。

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   <Directory /var/www/html/private>
       AuthType Basic
       AuthName "Restricted Files"
       AuthUserFile /etc/apache/.htpasswd
       AuthBasicProvider  file


       Require valid-user
   </Directory>
</VirtualHost>

上記の例はファイル認証のためのものであり、おそらくキャッシュによるメリットはあまりありません。ただし、他の認証方法を使用する場合、実装は非常に似ている必要があります。唯一の実質的な違いは、上記の例の「ファイル」仕様がどこにあるかであり、代わりに他の認証方法が使用されます。

ファイルを保存して閉じます。次を入力して、構文エラーの変更を確認します。

sudo apachectl configtest

構文エラーが見つからない場合は、Apacheを再起動してキャッシュの変更を実装します。

sudo systemctl restart httpd

SSLセッションキャッシング

SSL接続を確立するために実行する必要があるハンドシェイクには、大きなオーバーヘッドが伴います。したがって、セッションデータをキャッシュして以降のリクエストの初期化手順を回避すると、このペナルティを回避できる可能性があります。共有オブジェクトキャッシュは、これに最適な場所です。

Apacheサーバー用にSSLがすでに設定されている場合、 `+ mod_ssl `が有効になります（有効でない場合は、 ` yum `を使用して ` mod_ssl `モジュールをインストールします）。 CentOS 7では、これは ` ssl.conf `ファイルが ` / etc / httpd / conf.d +`ディレクトリで利用できることを意味します。これは実際にすでにキャッシュを設定しています。内部には、次のような行が表示されます。

/etc/httpd/conf.d/ssl.conf

. . .

SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

. . .

これは実際にセッションキャッシングを設定するのに十分です。これをテストするには、OpenSSLの接続クライアントを使用できます。タイプ：

openssl s_client -connect 127.0.0.1:443 -reconnect -no_ticket | grep Session-ID

セッションIDがすべての結果で同じ場合、セッションキャッシュは正しく機能しています。 CTRL-Cを押して終了し、ターミナルに戻ります。

標準HTTPキャッシング

総括

関連するプライマリモジュール： + mod_cache +
関連するサポートモジュール： + mod_cache_disk +、 + mod_cache_socache +
主な使用例：一般的なコンテンツのキャッシュ
機能：HTTPキャッシングヘッダーを正しく解釈でき、古いエントリを再検証でき、ニーズに応じて最大速度または柔軟性で展開できます。
欠点：設定が間違っていると機密データが漏れる可能性があるため、追加のモジュールを使用してキャッシュポリシーを正しく設定する必要がある

詳細

HTTPプロトコルは、コンテンツ配信パス全体で応答をキャッシュするメカニズムを推奨し、提供します。コンテンツに触れるコンピューターは、コンテンツの発信元で設定されているキャッシュポリシーとコンピューターの独自のキャッシュルールに応じて、一定期間、各アイテムをキャッシュできます。

Apache HTTPキャッシングメカニズムは、表示されるHTTPキャッシングポリシーに従って応答をキャッシュします。これは、配信に関与する中間サーバーが従うのと同じルールを順守する汎用キャッシングシステムです。これにより、このシステムは非常に柔軟で強力になり、コンテンツに既に設定しているヘッダーを活用できます（これを行う方法については後述します）。

ApacheのHTTPキャッシュは「3状態」キャッシュとも呼ばれます。これは、保存されているコンテンツが3つの状態のいずれかにある可能性があるためです。それは新鮮である可能性があり、それ以上のチェックなしでクライアントへの提供が許可されることを意味します。。

次のリクエストでコンテンツが古くなった場合、キャッシュはオリジンのコンテンツをチェックすることでコンテンツを再検証できます。変更されていない場合は、鮮度の日付をリセットし、現在のコンテンツを配信できます。それ以外の場合、変更されたコンテンツを取得し、キャッシュポリシーで許可されている期間保存します。

モジュールの概要

HTTPキャッシングロジックは、 `+ mod_cache `モジュールを介して利用できます。実際のキャッシングは、キャッシングプロバイダーの1つを使用して行われます。通常、キャッシュは ` mod_cache_disk `モジュールを使用してディスクに保存されますが、共有オブジェクトのキャッシュは ` mod_cache_socache +`モジュールからも利用できます。

`+ mod_cache_disk `モジュールはディスクにキャッシュするので、リモートロケーションからコンテンツをプロキシする場合、動的プロセスからコンテンツを生成する場合、またはコンテンツが通常存在するよりも高速なディスクにキャッシュすることで速度を上げようとする場合に役立ちますオン。これは最もよくテストされたプロバイダーであり、ほとんどの場合、おそらく最初の選択肢です。キャッシュは自動的に消去されないため、キャッシュをスリム化するために、 ` htcacheclean `というツールを時々実行する必要があります。これは手動で実行するか、通常の「 cron +」ジョブとして設定するか、デーモンとして実行できます。

`+ mod_cache_socache `モジュールは、共有オブジェクトプロバイダーの1つ（最後のセクションで説明したものと同じもの）にキャッシュします。これにより、（ mod_cache_disk + `よりもパフォーマンスが向上する可能性があります（選択されている共有キャッシュプロバイダーによって異なります）。ただし、はるかに新しく、前述のバグがある共有オブジェクトプロバイダーに依存しています。 `+ mod_cache_socache +`オプションを実装する前に、包括的なテストが推奨されます。

HTTPキャッシュの配置

ApacheのHTTPキャッシュは、ニーズに応じて2つの異なる構成で展開できます。

`+ CacheQuickHandler `が“ on”に設定されている場合、キャッシュはリクエスト処理プロセスの非常に早い段階でチェックされます。コンテンツが見つかった場合、それ以上の処理なしで直接配信されます。これは、非常に高速であることを意味しますが、コンテンツの認証などのプロセスを許可しないことも意味します。通常、認証またはアクセス制御を必要とするコンテンツがキャッシュにある場合、 ` CacheQuickHandler +`が“ on”に設定されていると、認証なしで誰でもアクセスできます。

基本的に、これはWebサーバーの前にある個別のキャッシュをエミュレートします。 Webサーバーが何らかの条件付きチェック、認証、または承認を行う必要がある場合、これは起こりません。 Apacheは、 `+ <Location> `または ` <Directory> `ブロック内のディレクティブも評価しません。 ` CacheQuickHandler +`は* default *によって「オン」に設定されていることに注意してください。

`+ CacheQuickHandler +`が“ off”に設定されている場合、キャッシュはリクエスト処理シーケンスのかなり後にチェックされます。この構成は、Apache処理ロジックと実際のコンテンツの間にキャッシュを配置すると考えてください。これにより、キャッシュからコンテンツを取得する前に、従来の処理ディレクティブを実行できます。これを「オフ」に設定すると、要求をより深く処理する機能と少し速度が低下します。

標準HTTPキャッシュを構成する方法

キャッシュを有効にするには、 `+ mod_cache `モジュールとそのキャッシュプロバイダーのいずれかを有効にする必要があります。上で述べたように、 ` mod_cache_disk +`は十分にテストされているため、それに依存します。

キャッシュを自動的に管理するためのhtcachecleanのセットアップ

CentOS 7システムでは、 `+ httpd `のインストール中に、キャッシュの成長に合わせてキャッシュを削減するために使用される ` htcacheclean `ユーティリティがインストールされます。デフォルトでは、「 htcacheclean.service」という「+ systemd」ユニットファイルが含まれています。

キャッシングのセットアップを計画している場合、このサービスが自動的に実行されるように構成することをお勧めします。サービスファイルは実際にサービスをデーモン化し、設定可能な間隔でクリーニング操作を実行します。ただし、デフォルトでは、Apacheの起動時に起動するメカニズムはありません。

これを設定するには、 `+ / etc / systemd / system `ディレクトリ内に ` httpd.service.requires `というディレクトリを作成します。これは、Apacheを起動する ` httpd.service`ユニットファイルの依存関係を指定するために使用できます。

sudo mkdir -p /etc/systemd/system/httpd.service.requires

その後、 `+ htcacheclean.service`ユニットファイルをこのディレクトリにリンクできます。これにより、Apacheの起動時に、定期的に `+ htcacheclean +`サービスが開始され、キャッシュが消去されます。

sudo ln -s /usr/lib/systemd/system/htcacheclean.service /etc/systemd/system/httpd.service.requires

`+ / etc / sysconfig `ディレクトリの ` htcacheclean `ファイルを編集することで、クリーニング間隔を含む ` htcacheclean +`オプションを設定できます：

sudo nano /etc/sysconfig/htcacheclean

ここでは、ユーティリティのクリーニング間隔、キャッシュルート、最大キャッシュサイズ、およびその他のオプションを変更できます。

/ etc / sysconfig / htcacheclean

INTERVAL=15
CACHE_ROOT=/var/cache/httpd/proxy
LIMIT=100M
OPTIONS=

Note

終了したら、ファイルを保存して閉じます。

Apacheを再起動して `+ htcacheclean`を起動し、キャッシュを自動的にクリアします。

sudo systemctl restart httpd

グローバル構成の変更

キャッシングの設定のほとんどは、個々の仮想ホスト定義またはロケーションブロック内で行われます。ただし、いくつかの一般的な属性を設定するために使用する必要があるいくつかのグローバル構成アイテムもあります。メインのApache構成ファイルを開いて、これらの項目を構成します。

sudo nano /etc/httpd/conf/httpd.conf

キャッシュされたアイテムを保存するために使用されるパスを指すように、 `+ CacheRoot `ディレクトリを追加する必要があります。これは、キャッシュを正しく管理できるように、 ` / etc / sysconfig / htcacheclean `ファイルにある ` CACHE_ROOT `の値と常に一致する必要があります。また、 ` CacheDirLevels `および ` CacheDirLength +`ディレクティブも設定します。どちらもキャッシュディレクトリ構造の構築方法の定義に貢献します。

/etc/httpd/conf/httpd.conf

CacheRoot /var/cache/httpd/proxy
CacheDirLevels 2
CacheDirLength 1

`+ CacheDirLevels `と ` CacheDirLength `はどちらもキャッシュディレクトリ構造の構築方法の定義に貢献します。提供されているURLの ` md5 `ハッシュが、データの保存に使用されるキーとして作成されます。データは、各ハッシュの先頭文字から派生したディレクトリに編成されます。 ` CacheDirLevels `は作成するサブディレクトリの数を指定し、 ` CacheDirLength `は各ディレクトリの名前として使用する文字数を指定します。したがって、上記のデフォルト値を持つ「 b1946ac92492d2347c6235b4d2611184 」のハッシュは、「 b / 1 / 946ac92492d2347c6235b4d2611184 +」のディレクトリ構造に格納されます。通常、これらの値を変更する必要はありませんが、それらが何に使用されているかを知っておくと便利です。

このファイルで設定できる他の値には、Apacheがキャッシュにコミットするファイルサイズの範囲をバイト単位で設定する `+ CacheMaxFileSize `と ` CacheMinFileSize `のほか、 ` CacheReadSize `と ` CacheReadTime +`があります。クライアントに送信する前にコンテンツを待機してバッファリングできます。これは、コンテンツがこのサーバー以外の場所にある場合に役立ちます。

仮想サーバーの変更

キャッシングの構成のほとんどは、仮想ホスト定義または特定のロケーションブロックのいずれかで、より詳細なレベルで行われます。

仮想ホストファイルの1つを開いて、フォローします。このガイドの「+ / etc / httpd / conf.d 」ディレクトリ内で「 site.conf +」というファイルを使用していると仮定します。

sudo nano /etc/httpd/conf.d/site.conf

ロケーションブロックの外側の仮想ホストブロックで、いくつかのキャッシュプロパティの構成を開始できます。このガイドでは、より多くの処理が行われるように、 `+ CacheQuickHandler +`をオフにすることを想定しています。これにより、より完全なキャッシュルールを作成できます。

また、この機会にキャッシュロックを構成します。これは、コンテンツがまだ有効であるかどうかを確認するためにコンテンツオリジンでチェックインするときにApacheが使用するファイルロックのシステムです。このクエリが満たされている間に、同じコンテンツに対する追加のリクエストが入ると、バックエンドリソースへの追加のリクエストが発生し、負荷が急増する可能性があります。

検証中にリソースのキャッシュロックを設定すると、リソースが現在更新されていることがApacheに通知されます。この間、失効したリソースには、その状態を示す警告ヘッダーが表示されます。 `+ / tmp +`フォルダーにキャッシュロックディレクトリを設定します。ロックが有効と見なされるまでに最大5秒かかります。これらの例は、Apacheのドキュメントから直接取られたものであるため、私たちの目的に適しています。

また、 `+ Set-Cookie `ヘッダーを無視し、キャッシュに保存しないようにApacheに指示します。そうすることで、Apacheが誤ってユーザー固有のCookieを他の関係者に漏らすことを防ぎます。 ` Set-Cookie +`ヘッダーは、ヘッダーがキャッシュされる前に削除されます。

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html








</VirtualHost>

この仮想ホストのキャッシングを実際に有効にする必要があります。 + CacheEnable +`ディレクティブでこれを行うことができます。これが仮想ホストブロックで設定されている場合、キャッシュするメソッド（ `+ disk +`または `+ socache +）およびキャッシュする必要があるURIを提供する必要があります。たとえば、すべての応答をキャッシュするには、これを + CacheEnable disk / +`に設定できますが、応答を `+ / public + URIでのみキャッシュする場合は、これを `+ CacheEnable disk / public +`に設定できます。

特定のロケーションブロック内でキャッシュを有効にすることにより、別のアプローチを取ります。そうすることで、 `+ CacheEnable `コマンドにURIパスを提供する必要がなくなります。その場所から提供されるURIはすべてキャッシュされます。また、リクエストの処理にキャッシュが使用されたかどうかをレスポンスヘッダーが示すように、 ` CacheHeader +`ディレクティブをオンにします。

設定する別のディレクティブは `+ CacheDefaultExpire `です。これにより、コンテンツに ` Expires `ヘッダーも ` Last-Modified `ヘッダーも設定されていない場合に有効期限（秒単位）を設定できます。同様に、アイテムが保存される時間を制限するために、 ` CacheMaxExpire `を設定します。 ` Last-Modified `日付があるが有効期限がない場合、Apacheが有効期限を作成できるように、 ` CacheLastModifiedFactor +`を設定します。この係数には、妥当な有効期限を設定するために変更してからの時間が乗算されます。

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   CacheQuickHandler off

   CacheLock on
   CacheLockPath /tmp/mod_cache-lock
   CacheLockMaxAge 5

   CacheIgnoreHeaders Set-Cookie









</VirtualHost>

必要なものをすべて設定したら、ファイルを保存して閉じます。

次のように入力して、構成全体の構文エラーを確認します。

sudo apachectl configtest

エラーが報告されない場合は、次を入力してサービスを再起動します。

sudo systemctl restart httpd

コンテンツの有効期限とキャッシュヘッダーの設定

上記の構成では、HTTPヘッダーに依存するHTTPキャッシュを構成しました。ただし、提供しているコンテンツには、インテリジェントなキャッシュの決定に必要な + Expires`または + Cache-Control`ヘッダーが実際にはありません。これらのヘッダーを設定するには、さらにいくつかのモジュールを利用する必要があります。

+ mod_expires +`モジュールは `+ Expires +`ヘッダーと `+ Cache-Control +`ヘッダーの `+ max-age +`オプションの両方を設定できます。 `+ mod_headers`モジュールを使用して、より具体的な + Cache-Control`オプションを追加し、キャッシュポリシーをさらに調整できます。これらのモジュールは両方とも、CentOS 7 Apacheパッケージでデフォルトで有効になっています。

これらの項目の構成を開始するために、仮想ホストファイルを再び変更することに直行できます。

sudo nano /etc/httpd/conf.d/site.conf

+ mod_expires +`モジュールは3つのディレクティブのみを提供します。 `+ ExpiresActive +`は、「on」に設定することにより、特定のコンテキストで有効期限処理をオンにします。他の2つのディレクティブは互いに非常に似ています。 `+ ExpiresDefault +`ディレクティブはデフォルトの有効期限を設定し、 `+ ExpiresByType +`はコンテンツのMIMEタイプに従って有効期限を設定します。これらは両方とも、 `+ Expires`と + Cache-Control`の“ max-age”を正しい値に設定します。

これらの2つの設定は、2つの異なる構文を取ることができます。最初は単に「A」または「M」で、その後に秒数が続きます。これにより、コンテンツがそれぞれ「アクセス」または「変更」された最後の時間に関連して有効期限が設定されます。たとえば、これらの両方は、アクセスされてから30秒後にコンテンツを期限切れにします。

ExpiresDefault A30
ExpireByType text/html A30

他の構文では、より詳細な構成が可能です。これにより、人間が計算しやすい秒以外の単位を使用できます。また、「アクセス」または「変更」というフルワードも使用します。有効期限設定全体は、次のように引用符で囲む必要があります。

ExpiresDefault "modification plus 2 weeks 3 days 1 hour"
ExpiresByType text/html "modification plus 2 weeks 3 days 1 hour"

ここでは、デフォルトの有効期限を設定します。 5分に設定することから始めて、慣れて間違えた場合にクライアントのコンピューターに非常に長い間保存されないようにします。コンテンツに適したポリシーを選択する自信がついたら、これをより積極的なものに調整できます。

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   CacheQuickHandler off

   CacheLock on
   CacheLockPath /tmp/mod_cache-lock
   CacheLockMaxAge 5

   CacheIgnoreHeaders Set-Cookie

   <Location />
       CacheEnable disk
       CacheHeader on

       CacheDefaultExpire 600
       CacheMaxExpire 86400
       CacheLastModifiedFactor 0.5



   </Location>
</VirtualHost>

これにより、 + Expires`ヘッダーが将来5分に設定され、 + Cache-Control max-age = 300 + が設定されます。キャッシングポリシーをさらに改良するために、 `+ Header +`ディレクティブを使用できます。 `+ merge`オプションを使用して、追加の + Cache-Control`オプションを追加できます。これを複数回呼び出して、必要なポリシーを追加できます。 https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies [このガイド]をチェックして、希望するキャッシングポリシーについてのアイデアを得てください。コンテンツに設定します。この例では、他のキャッシュがコピーの保存を許可されていることを確認できるように、「パブリック」を設定します。

サイトの静的コンテンツに（+ ETags + を設定する（検証に使用する）には、 + FileETag + `ディレクティブを使用できます。これは、静的コンテンツに対して機能します。動的に生成されたコンテンツの場合、アプリケーションは `+ ETags +`を正しく生成する責任があります。

ディレクティブを使用して、Apacheが `+ Etag `の計算に使用する属性を設定できます。これは、ファイルの「 inode 」が変更され、その変更時刻が変更され、「 ETag 」サイズの変更、または上記のすべて。複数の値を指定できます。また、新しい設定の前に「+」または「-+」を付けることで、子コンテキストの継承された設定を変更できます。この目的のために、「すべて」を使用して、すべての変更が登録されるようにします。

/etc/httpd/conf.d/site.conf

<VirtualHost *:80>
   ServerName
   DocumentRoot /var/www/html

   CacheQuickHandler off

   CacheLock on
   CacheLockPath /tmp/mod_cache-lock
   CacheLockMaxAge 5

   CacheIgnoreHeaders Set-Cookie

   <Location />
       CacheEnable disk
       CacheHeader on

       CacheDefaultExpire 600
       CacheMaxExpire 86400
       CacheLastModifiedFactor 0.5

       ExpiresActive on
       ExpiresDefault "access plus 5 minutes"


        All
   </Location>
</VirtualHost>

これにより、 + Cache-Control`がすでに持っている値に“ public”（コンマで区切られた）が追加され、静的コンテンツの + ETag`が含まれます。

終了したら、ファイルを保存して閉じます。次のように入力して、変更の構文を確認します。

sudo apachectl configtest

エラーが見つからなかった場合は、サービスを再起動してキャッシュポリシーを実装します。

sudo systemctl restart httpd

結論

Apacheでキャッシュを構成することは、オプションの数が多いため困難な作業のように思えます。幸いなことに、単純に始めてから、複雑さが増すにつれて成長するのは簡単です。ほとんどの管理者は、各キャッシュタイプを必要としません。

キャッシュを設定するときは、さまざまな実装の選択肢で迷子にならないように、解決しようとしている特定の問題に留意してください。ほとんどのユーザーは、少なくともヘッダーを設定することで恩恵を受けます。コンテンツをプロキシまたは生成している場合は、HTTPキャッシュを設定すると役立つ場合があります。共有オブジェクトキャッシングは、バックエンドプロバイダーを使用している場合、SSLセッションや認証詳細の保存などの特定のタスクに役立ちます。ファイルキャッシュは、おそらく低速なシステムのキャッシュに限定されます。

CentOS 7でApacheコンテンツキャッシングを構成する方法

キャッシングとは何ですか？

Apacheのキャッシュの概要

ファイルキャッシング

総括

詳細

ファイルキャッシュを有効にする方法

Key-Valueキャッシング

総括

詳細

キーと値のキャッシュを有効にする方法

認証キャッシュ

SSLセッションキャッシング

標準HTTPキャッシング

総括

詳細

モジュールの概要

HTTPキャッシュの配置

標準HTTPキャッシュを構成する方法

キャッシュを自動的に管理するためのhtcachecleanのセットアップ

グローバル構成の変更

仮想サーバーの変更

コンテンツの有効期限とキャッシュヘッダーの設定

結論