⚗️ ♍️ 👩🏾‍🤝‍👨🏻 Drupal 8 + Varnish：HTMLを正しくキャッシュする 🎬 ⬆️ 👩🏼‍✈️

Drupal 8は、CMS Drupalの最新リリースです。 Varnishは、Webアプリケーション用のHTTPリバースプロキシキャッシュアドオンで、サーバーのRAMにHTTP応答をキャッシュできます。

VarnishをDrupal（またはその他のWebアプリケーション）の前に配置すると、着信HTTPリクエストの処理スキームは次のように変換されます。

Drupal 6および7の時代、Varnishを使用すると、静的リソース（画像、CSS、JavaScriptファイル）をキャッシュするのが非常に便利でした。しかし、HTMLページのキャッシュには問題がありました-選択的なキャッシュ無効化のための便利なメカニズムがありませんでした。意図的に古いキャッシュを提供するか、Drupalに変更を加えてワニスのキャッシュを完全にクリアするために残っただけです。どちらのアプローチにも欠点がありました。

Drupalの変更時にVarnishのキャッシュを無効にしなかった場合、比較的小さなTTLを設定して、Varnishのキャッシュがすぐに古くなるようにし、VarnishがDrupalの新しいデータでキャッシュを更新しました。

一方、Drupalで「くしゃみをするたびに」ワニスのキャッシュをクリアすると、これらの対策が冗長になることがよくありました。一部のユーザーは、アクセスの少ないページで無害なコメントを書くことができました。これにより、ニスのキャッシュ全体が無効になりました（実際に追加されたコメントにより変更されなかったページを含む）。

Drupal 8キャッシュAPI

幸いなことに、メタ情報を介した柔軟なキャッシングシステムが追加されたDrupal 8の方がはるかに優れています。私は公式ドキュメントを読むことに興味があることを強く勧めます。要するに、このシステムにより、Drupalは生成されたページが依存するもの（ノード、コメント、構成など）を追跡できます。各ページは、キャッシュタグ（キャッシュタグ）のセットに関連付けられています。その後、状態が変更されると、Drupalはどのキャッシュタグを無効にする必要があるかを認識します。これにより、何か（ノード、コメント、構成）が変更されたときにDrupalがキャッシュページの最小限必要なセットのみを無効にすることができます。これは、Drupalのコアが内部キャッシュを無効にするために使用するアプローチです。一対の器用な動きにより、ワニスのキャッシュで同様の「最低限必要な」障害を達成できます。

VarnishでのCache APIの拡張

このチュートリアルでは、静的リソース（グラフィック、CSS、JavaScript）のVarnishが既に正常にインストールおよび構成されていることを前提としています。匿名のHTMLページでキャッシュをカバーするには、3つの手順が必要です。

どのページがどのタグキャッシュに依存するかをVarnishに説明します。 Drupalはすでにこの知識を持っているので、ワニスに渡すだけです。
キャッシュタグがDrupalで無効になった時点で、このタグキャッシュに依存するニスキャッシュ内のすべてのページも無効にする必要があります。
これらすべての革新のためにニスを準備します。

これらはすべて、Drupalエコシステムのモジュールとして既に実装されています。必要なもの：

パージ -外部HTTPキャッシュを無効にするための一種のフレームワーク（ワニス、CDN、Nginx）
Varnish Purgerは、このフレームワークをVarnishで実装したものです。

コンポーザーを使用している場合：

composer require "drupal/purge:^3.0" composer require "drupal/varnish_purge:^1.0"

次のモジュールを含めます。

パージ（パージ）
パージブラシ（purge_drush）
トークンのパージ（purge_tokens）
UIのパージ（purge_ui）
cronプロセッサー（purge_processor_cron）または後期ランタイムプロセッサー（purge_processor_lateruntime）。これら2つのモジュールの違いについては、少し後で説明します。
コアタグキューラー（purge_queuer_coretags）
ワニスパージャー（varnish_purger）
ワニスパージャータグ（varnish_purge_tags）

Drupal 8のセットアップ

DrupalにVarnishの場所とキャッシュを部分的に無効にする方法を説明する必要があります。上記のモジュールをインストールした後、ページ/admin/config/development/performance/purge

ます。 Varnish purgerを追加し、Varnishが配置されているホストへの正しいパスを指定します。

[ タイプ]で、 Tagを指定します。無効化にはDrupalのキャッシュタグを使用します。 Requestメソッドで Banを指定します Varnishの構成の対応する部分は、まさにそのようなHTTPリクエストメソッドを想定しています。

[ ヘッダー ]タブで：

[invalidation：expression]のコンテンツを含むCache-Tagsヘッダーを追加します。このトークン化された式は、トークンモジュールによって無効なタグキャッシュ値に置き換えられます。

残りはあなたの好みや特定の状況に合わせて設定できます（また設定する必要があります）。これで、Drupalはすべての回答にCache-Tagsヘッダーを含め、生成されたページの形成に参加したキャッシュタグのリストを含めます。 Varnishはこれらのヘッダーをキャッシュの一部として保存し、それらを使用してキャッシュを無効にします。

この時点で、直接要求するとき（ワニスをバイパスするとき）のDrupalに実際にCache-Tagsヘッダーが含まれていることを確認してください。私の場合、最初に表示されるページは次のようになります。

ネタバレ

Cache-Tags: block_view config:block.block.seven_breadcrumbs config:block.block.seven_content config:block.block.seven_help config:block.block.seven_local_actions config:block.block.seven_login config:block.block.seven_messages config:block.block.seven_page_title config:block.block.seven_primary_local_tasks config:block.block.seven_secondary_local_tasks config:block_list config:coffee.configuration config:shortcut.set.default config:system.menu.admin config:user.role.administrator config:user.role.authenticated http_response rendered user:1

デフォルトでは、DrupalはCache-Control: private, no-cache

応答しますCache-Control: private, no-cache

生成されるすべてのHTMLリソースに対してCache-Control: private, no-cache

（つまり、キャッシュを無効にします）。これは、ワニスがそれらをキャッシュしないことを意味します。 Drupal設定で外部キャッシュを有効にする必要があります。 /admin/config/development/performance

ページに移動し、 Page cache maximum ageにゼロ以外の値を選択します。

無害な5分のキャッシュから開始することをお勧めします。すべてがデバッグされ、正常に実行された場合にのみ、数時間または数日間のフルスケール値に切り替えます。

もう一度確認してください。匿名ユーザーがDrupalページをリクエストすると、「 Cache-Control: public, max-age=[ ]

」という答えが表示されます。そして、許可ユーザーに代わって尋ねられたとき、 Cache-Control: private, no-cache

fly back。したがって、Varnishは匿名の匿名HTMLページのみをキャッシュできます。

ワニスを構成する

それでは、ワニスの準備に移りましょう。以下をVCLに追加する必要があります。

最初に、DrupalはあなたのニスにHTTP禁止リクエストを送信します。まず、このリクエストの処理へのアクセスを制限する必要があります。そうしないと、誰でもワニスのキャッシュをクリアできます。これを行うには、aclグループを入力します。

 #  ,    Ban . acl purge { "127.0.0.1"; }

禁止リクエスト自体の処理を追加する必要があります。 vcl_recvで最初に記述します。

 if (req.method == "BAN") { #    . if (!client.ip ~ purge) { return (synth(403, "Not allowed.")); } #    “Cache-Tags” . if (req.http.Cache-Tags) { ban("obj.http.Cache-Tags ~ " + req.http.Cache-Tags); } else { return (synth(403, "Cache-Tags header missing.")); } #     . return (synth(200, "Ban added.")); }

また、デフォルトでは、Varnishはエンドクライアント（ブラウザー）への応答でDrupalから受信するCache-TagsおよびCache-Controlヘッダーを変換します。

Cache-Tagsの場合、これは、ネットワークを介して運転するごみであり、インフラストラクチャの内部構造に関する追加の情報源です。 Cache-Control：publicの場合、これはかなり望ましくない動作です。 DrupalはVarnishのキャッシュを許可しましたが、訪問者のブラウザーでのページのキャッシュは正しくありません（更新されたコンテンツの受信が遅れ、キャッシュの無効化に関する巧妙なスキーム全体がスマルカになってしまうため）。したがって、 vcl_deliverに次を追加する必要があります。

 #     . unset resp.http.Cache-Tags; #       . if (resp.http.Content-Type ~ "text/html") { set resp.http.Cache-Control = "private,no-cache"; }

この時点で、稼働中のサーバーでVarnishをクロスして再起動できます。現在、ワニスは、Drupalが送信するHTTP禁止リクエストを使用して、キャッシュを選択的に消去できます。また、HTMLリソース（Drupalが許可するもの）を巧みにキャッシュしますが、ブラウザーはそれらをキャッシュできません。クラスとしての名前-リバースHTTPプロキシキャッシュ-がここから来て、クライアントではなくHTTPプロキシにキャッシュします。

パン、キャンディーラッパー、クッキー

正しい構成を再確認してください。これについて学ぶことは、変更を行った直後よりも午前2時にクライアントから苦痛を感じるでしょう。私の直観~~経験を~~信じてください。

Cronプロセッサおよび後期ランタイムプロセッサモジュール

これらの2つのモジュールのいずれかが必要になると述べました。 Varnishのキャッシュの無効化はキュー単位で行われます。リクエストの処理中に、Drupalは特定のキャッシュタグをキューに挿入し、対応するHTTP禁止リクエストをVarnishに送信して誰かがこのキューを処理する必要があります。両方のモジュールはキュー処理の問題を解決しますが、異なる方法で処理します。

cronプロセッサは、cron Drupalの起動時にキューを処理します。これは、cronが戦略的に重要になっていることを意味します（以前のように考慮する必要があります）。このモデルから、VarnishがキャッシュされたHTMLコンテンツや古いHTMLコンテンツをレンダリングできる場合、 Xまでの遅延（ Xはcronの起動頻度）があることにもなります。場合によってはこれで問題ありません。

代替の（したがって、より積極的な）キュープロセッサは、遅延ランタイムプロセッサです。各着信HTTPリクエストの処理の終わりにタグキャッシュキューを処理します。リアルタイムで。

Webサイトに表示される好みと要件に応じて、2つのハンドラーのいずれかを選択します。ほとんどのDrupal 8 WebサイトはCronプロセッサを使用しているという印象を受けました。ただし、Late Runtime Processorの問題と明白なバグも登録されていません。

通信チャネルDrupal→ワニス

Drupalが配置されているホストから、 curl -X BAN --header 'Cache-Tags: dummy-cache-tag' http://varnish-server.com

Varnishが200 HTTP OKで応答していることを確認してください。これは、ワニスが正しく構成され、Drupalが送信する無効化リクエストを処理する準備ができたことを意味します。

Drupalウォッチドッグのデバッグ情報

ページ/admin/config/development/performance/purge

で、Drupalのウォッチドッグで必要なログレベルを設定できます。問題を特定する必要がある場合に非常に便利です。

無効化のキュー

/admin/config/development/performance/purge

ページに現在のステータスがあります。特に、 Queue sizeカウンターに注意してください。これは、タグキャッシュ無効化キューの現在の長さを示します。これは、Drupalで既に無効になっているが、ワニスではまだ無効になっていないタグキャッシュの数です。

cronを使用して無効化を使用する場合は、cronの起動後にこの数値がゼロになっていることを確認してください。

「遅延ランタイムプロセッサ」を使用する場合、ゼロ以外の値は定期的にのみ期待する必要があります。数値が高すぎる場合、または長期間0にならない場合は、いくつかの問題の兆候です。

ニスのキャッシュヒット

理論を信じる必要はありません。作業が完了したら、Varnishが匿名のHTMLページを正しくキャッシュするという事実を実際に再確認することをお勧めします！ Varnishが最初にキャッシュヒットヘッダーを回答に挿入しない場合は、 vcl_deliverに追加するだけです。

 if (obj.hits > 0) { set resp.http.X-Varnish-Cache = "HIT"; } else { set resp.http.X-Varnish-Cache = "MISS"; }

実際には、匿名ユーザーからページをリクエストするときに、ワニスがそれをキャッシュすることを確認してください（2回目はX-Varnish-Cache: HIT

ヘッダーで応答する必要があります）。この時点で、Drupalの調査済みページの無効化を引き起こします-Drupalのキャッシュをクリアするか、ノードを再保存します（ノードのページを分析している場合）など。 Varnishでキャッシュを無効にする責任がある場合は、cron Drupalを忘れずに実行してください。

調査したページに対してリクエストを繰り返します。最初の回答にはヘッダーX-Varnish-Cache: MISS

が含まれている必要があります。これにより、Drupalが必要なタグキャッシュの無効化についてVarnishに正常に通知し、後者が受信した無効化リクエストを正常に処理したことを確認できます。

HTTP応答ヘッダーの長さ

Drupal 8サイトは面倒な場合があります。特に、これにより、特定のHTMLページに関連付けられたタグキャッシュの長いリストが作成される可能性があります。多くのWebサーバー、および一般的に、異なる実装のWebserver + PHPスタックでは、応答ヘッダーの最大長に制限がある場合があります。本当につまずくことができます。さらに、テスト環境にテスト（切り捨てられた）データセットがある場合、問題は実際の環境でのみ発生します。スタックの展開方法に応じて、問題を処理する必要があります。

更新：応答ヘッダーの長さがそれほど単純ではないことが判明しました。これは、私がパッチをダウンロードしたdrupal.orgの問題です。パッチは、ヘッダーの長さを短くするという非常に良い仕事をしますwww.drupal.org/project/purge/issues/2952277

Drupal 8のCache APIについてもう一度

この記事で説明されているのは、Drupal 8でのキャッシュAPIの使用方法のほんの一部です。私は個人的に、キャッシュAPIがDrupal 7と比較して主要な革新であると考えています。キャッシュAPI; キャッシュとDrupal 8のレンダリングとの関係。

Drupal 8 + Varnish：HTMLを正しくキャッシュする