Varnishの設定と使用
Varnish Cacheは、オープンソースのweb アプリケーションアクセラレータです(HTTP アクセラレータまたは キャッシュ HTTP リバースプロキシ とも呼ばれます)。 Varnishは、ファイルまたはファイルのフラグメントをメモリに保存(またはキャッシュ)します。これにより、Varnishは、将来の同等のリクエストでの応答時間とネットワーク帯域幅の消費を削減できます。 Apacheやnginxのようなウェブサーバーとは異なり、VarnishはHTTP プロトコルでのみ使用できるように設計されています。
必要システム構成には、サポートされているバージョンのVarnishが一覧表示されます。
Varnishについて詳しくは、次を参照してください。
ニス トポロジ ダイアグラム
次の図は、Commerce トポロジでのVarnishの基本的なビューを示しています。
上記の図では、インターネット経由のユーザーのHTTP リクエストは、CSS、HTML、JavaScript、および画像(総称して assets と呼ばれます)に対する多数のリクエストになります。 Varnishはweb サーバーの前に配置され、これらのリクエストをweb サーバーにプロキシします。
Web サーバーがアセットを返す際、キャッシュ可能なアセットはVarnishに保存されます。 これらのアセットに対する後続のリクエストは、Varnishによって処理されます(つまり、リクエストはweb サーバーに到達しません)。 Varnishは、キャッシュされたコンテンツを非常に迅速に返します。 これにより、コンテンツをユーザーに返す応答時間が短縮され、Commerceで処理する必要があるリクエストの数が減りました。
VarnishによってキャッシュされたAssetsは、設定可能な間隔で期限切れになるか、同じアセットの新しいバージョンに置き換えられます。 管理者またはmagento cache:clean コマンドを使用して、キャッシュを手動でクリアすることもできます。
プロセスの概要
このトピックでは、最小限のパラメーターのセットを使用してVarnishを最初にインストールし、それが機能することをテストする方法について説明します。 次に、Commerce管理者からVarnish設定を書き出して、もう一度テストします。
このプロセスは、次のように要約できます。
-
Varnishをインストールし、任意のCommerce ページにアクセスしてテストし、Varnishが動作していることを示すHTTP レスポンスヘッダーを取得しているかどうかを確認します。
-
Commerce ソフトウェアをインストールし、Adminを使用してVarnish設定ファイルを作成します。
-
既存のVarnish設定ファイルを、管理者が生成したVarnish設定ファイルに置き換えます。
-
すべてを再テスト。
<magento_root>/var/page_cacheディレクトリに何も含まれていない場合は、CommerceでVarnishを正常に設定しました。
-
記載されている場合を除き、このトピックで説明されているすべてのコマンドを
root権限を持つユーザーとして入力する必要があります。 -
このトピックは、CentOSおよびApache 2.4でVarnishに対して記述されています。 Varnishを別の環境で設定する場合、一部のコマンドが異なる場合があります。 詳しくは、Varnishのドキュメントを参照してください。
既知の問題
Varnishには次の問題があります。
-
代わりに、SSL ターミネーションまたはSSL ターミネーション プロキシを使用します。
-
<magento_root>/var/cacheディレクトリの内容を手動で削除する場合は、Varnishを再起動する必要があります。 -
Commerceのインストール中に発生する可能性のあるエラー:
code language-text Error 503 Service Unavailable Service Unavailable XID: 303394517 Varnish cache serverこのエラーが発生した場合は、次のように
default.vclを編集し、backendスタンザにタイムアウトを追加します。code language-conf backend default { .host = "127.0.0.1"; .port = "8080"; .first_byte_timeout = 600s; }
Varnish キャッシュの概要
Varnishのキャッシュは、次の機能を使用してCommerceで動作します。
- Magento 2 GitHub リポジトリの
nginx.conf.sample - Commerceで提供されたApache用の
.htaccess分散設定ファイル - 管理者を使用して生成されたVarnishの
default.vcl設定
最初のブラウザーリクエストでは、キャッシュ可能なアセットがVarnishからクライアントブラウザーに配信され、ブラウザーにキャッシュされます。
さらに、Varnishでは、静的アセットにエンティティタグ(ETag)を使用しています。 ETagは、静的ファイルがサーバー上で変更されたかどうかを判断する方法を提供します。 その結果、静的アセットは、ブラウザーからの新しいリクエストまたはクライアントがブラウザーのキャッシュを更新する際(通常はF5またはControl+F5を押す)に、サーバー上で変更されたときにクライアントに送信されます。
詳細については、後の節を参照してください。
ブラウザーリクエストによるキャッシュ
このセクションでは、ブラウザーインスペクターを使用して、最初のリクエストでアセットがブラウザーに配信され、その後ローカルブラウザーキャッシュから読み込まれる方法を示します。
最初のブラウザーリクエスト
nginx.conf.sampleと.htaccessは、クライアント キャッシュ用のオプションを提供します。 キャッシュ可能なオブジェクトに対してブラウザから最初のリクエストが行われると、Varnishはそれをクライアントに配信します。
次の図は、ブラウザーインスペクターを使用した例を示しています。
前述の例は、ストアフロントのメインページ (m2_ce_my)に対するリクエストを示しています。 CSSおよびJavaScript アセットは、クライアントブラウザーにキャッシュされます。
2回目のブラウザーリクエスト
同じブラウザーが同じページを再度要求した場合、これらのアセットはローカルブラウザーキャッシュから配信されます(次の図を参照)。
1回目と2回目のリクエストの応答時間の違いに注意してください。 繰り返しますが、静的アセットは200 (OK)の応答コードを持ちます。これは、ローカルキャッシュから初めて配信されるからです。
CommerceでEtagを使用する方法
次の例は、特定の静的アセットの応答ヘッダーを示しています。
calendar.cssにはETag応答ヘッダーがあります。これは、クライアントブラウザー上のCSS ファイルとサーバー上のCSS ファイルを比較できることを意味します。
さらに、次の図に示すように、静的アセットは304 (未変更) HTTP ステータスコードで返されます。
304 ステータスコードは、ユーザーがローカルキャッシュを無効にし、サーバー上のコンテンツが変更されなかったために発生します。 304 ステータスコードのため、静的アセット contentは転送されません。HTTP ヘッダーのみがブラウザーにダウンロードされます。
コンテンツがサーバー上で変更された場合、クライアントはHTTP 200 (OK)ステータスコードと新しいETagを含む静的アセットをダウンロードします。