この記事は以下の記事を参考にして書かれています。英文のブログですが内容をより詳しく理解したい場合はこちらのブログもご参照下さい。
https://www.fastly.com/blog/best-practices-using-vary-header
https://www.fastly.com/blog/getting-most-out-vary-fastly
特に記載がない限り本記事の記載内容は Fastly のデフォルト設定での挙動となります。
Fastly の正式なサポート内容ついては以下のドキュメントをご参照下さい。
サポートページ: https://docs.fastly.com/
日本語(一部のみ): https://docs.fastly.com/ja/
この記事の内容について
HTTP の Vary ヘッダーは正しく利用すると非常に便利な HTTP ヘッダーですが、間違った使い方をするとサーバーに無駄な負荷を発生させてしまったり、場合によっては正しくないコンテンツを配信してしまう結果にもなりえます。この記事ではFastlyを利用して Vary ヘッダーを効果的に利用する手順についてまとめてみたいと思います。
Varyヘッダーについて
そもそも Vary ヘッダーとはどういったものでしょうか?
Vary ヘッダーとは簡単にいうと Fastly サーバーなどのキャッシュサーバーに「同じ URL でも Vary ヘッダーに指定されているヘッダーの内容が異なれば別オブジェクトとして取り扱いなさい」というオリジンサーバーからの命令となります。
Vary ヘッダーが原因で生じる問題
Vary ヘッダーが正しく設定されないことが理由で起きうる代表的な問題について考えてみたいと思います。
Accept-Encoding
例えば Chrome などのブラウザから Web ページをリクエストする HTTP リクエストには accept-encoding: gzip
といったようなリクエストヘッダーがついています。
簡単に言うとこれはブラウザからサーバーへ「コンテンツを gzip で圧縮して送ってくれてもいいよ」というメッセージになります。
このヘッダーがリクエストについていてサーバー側が gzip 圧縮に対応している場合、 通信の効率をあげるため、例えば html などテキストベースのコンテンツを gzip 圧縮してブラウザに返却します。
gzip 圧縮に対応していないブラウザがあった場合、そのブラウザは同じオブジェクトをリクエストした場合でも accept-encoding
ヘッダーはリクエストに付与しません。
この場合、サーバーとしては「このブラウザは gzip したら解凍できないのか。であれば圧縮せずにそのままでコンテンツを送ってあげよう」という挙動となります。
ブラウザが直接 Web サーバーと通信している場合、これは特に問題にはなりません。ですが次のように中間に Fastly などのキャッシュするレイヤーがある場合に問題となる場合があります。Fastly を利用しているサイトに2つのクライアントがリクエストを送るケースを考えてみます。
- クライアントA が
accept-encoding: gzip
ヘッダーを付けてコンテンツ(index.html)をリクエスト - Fastly サーバーはリクエストをそのままオリジンサーバーに転送
- オリジンサーバーは index.html を gzip 圧縮して返却
- Fastly サーバーは返却されたレスポンスを index.html として(圧縮されたまま)キャッシュしてクライアントAに配信
- gzip 圧縮に対応していないクライアントB が index.html をリクエスト
- Fastly サーバーは index.html のキャッシュを持っているので、4のステップでキャッシュした(圧縮された)オブジェクトをクライアントBに返却
- クライアントB は圧縮されたレスポンスを解凍することが出来ないので正常に表示することが出来ない。。
といったように Vary が正しく設定されていないとクライアントが理解できないコンテンツを配信してしまう問題が発生してしまう可能性があります。
この問題を避けるために Vary を利用します。サーバーからのレスポンスに Vary: accept-encoding
というヘッダーがついていることで、Fastly サーバーは同じ index.html でもリクエストの accept-encoding
ヘッダーが異なる(もしくは存在しない)場合、別のオブジェクトとしてキャッシュします。
それでは Vary ヘッダーが存在する場合のフローを考えてみます。
- クライアントA が
accept-encoding: gzip
ヘッダーを付けてコンテンツ(index.html)をリクエスト - Fastly サーバーはリクエストをそのままオリジンサーバーに転送
- オリジンサーバーは
Vary: accept-encoding
ヘッダーを付与して index.html を gzip 圧縮して返却。 - Fastly サーバーは返却されたレスポンスを
accept-encoding
の値がgzip
の場合の index.html として(圧縮されたまま)キャッシュしてクライアントAに配信 - gzip 圧縮に対応していないクライアントB が index.html をリクエスト
- Fastly サーバーは index.html のキャッシュを持っているが、クライアントBのリクエストには
accept-encoding
ヘッダーがついていないのでキャッシュを利用できないと判断 - Fastly サーバーが
accept-encoding
ヘッダーがついていないリクエストをそのままオリジンサーバーに転送 - オリジンサーバーは index.html を gzip 圧縮せずに返却
- Fastly サーバー返却されたレスポンスを
accept-encoding
がついていない場合の index.html としてキャッシュしてクライアントBに配信
つまり、同じURLの index.html でも 複数のバリエーション、つまり gzip 圧縮されているものと、そうでないもの2種類を正しく使い分けることが出来ます。
であれば異なるコンテンツを返却する可能性がある場合、関連するヘッダーをすべて Vary にいれてしまえばいいのではないか、と思いたいところなのですがそうでもありません。なぜなのかを次のケースで考えてみたいと思います。
User-Agent
同じ URL でのコンテンツの出し分ける場合、一番よくあるケースが User-Agent
によるコンテンツの出しわけです。例えばデスクトップ向けのサイトとモバイル向けのサイトを同じドメインで運用したいといったケースはよくあると思います。この場合オリジンからのレスポンスに Vary: User-Agent
を設定すれば良いでしょうか?こうすることで確かにデスクトップ向けのコンテンツがモバイルで表示されることはなくなります。
ただし、ここで注意が必要なのは Fastly を含む Vary に対応している CDN やキャッシュサーバーは User-Agent の文字列が一文字でも異なれば別のオブジェクトとしてキャッシュを別に保持するということです。
Chrome, Firefox, Safari, Edge などはそれぞれ User-Agent が異なります。さらに同じブラウザであってもバージョンや適用されているパッチ、OSのバージョンが違えば User-Agent の値は異なります。一例として Fastly がサンプルした 100,000 リクエストでは 8,000 種類の異なる User-Agent が確認されました。
つまり本来はデスクトップとスマホ向けの2種類のキャッシュを保持すればいいだけなのに、不用意に Vary を利用すると大量の種類のキャッシュが発生しキャッシュヒット率の低下、オリジンオフロード率の低下と CDN サービスを適用するメリットが低下してしまいます。
Vary を利用する場合は、最小限のパターンを持つリクエストヘッダーを Vary に含めることがポイントとなります。
Vary の正規化
繰り返しになりますが Vary を効果的に使うためには、コンテンツのバリエーションの数と同じだけの種類を持つヘッダーを Vary に設定することが必要です。Fastly では VCL を利用して コンテンツの種類の数だけのバリエーションを持つヘッダーを作成し、最低限必要な数だけをキャッシュさせることが可能です。
例えば上記のデスクトップ向けとモバイル向けでコンテンツを出し分けたい場合は mobile/desktop という2種類の値を含むヘッダーを Vary に設定すればいいわけです。これは以下のようなシンプルなコードで実現出来ます。
まず、リクエストがモバイルかデスクトップなのかを User-Agent から判断し、X-device-type
というヘッダーにそれぞれ mobileまたはdesktop という値を設定します。
if(req.http.User-Agent ~ "(?i)(Mobile|Android|iPhone|Phone)") {
set req.http.X-device-type = "mobile";
} else {
set req.http.X-device-type = "desktop";
}
続いてオリジンから返却された Vary ヘッダーに先程設定した X-device-type
を追加します。
if (beresp.http.Vary) {
set beresp.http.Vary = beresp.http.Vary ", X-device-type";
} else {
set beresp.http.Vary = "X-device-type";
}
もしくは以下の1行のコードでも上記と同じ動作になります。
set beresp.http.Vary:X-device-type = "";
こうすることで、一つの URL に対して X-device-type
の種類だけ(つまりここではmobileとdesktopの2種類)をキャッシュとして保持します。
上記の例ではサンプルですので User-Agent からデバイス種別を判断するのにかなりシンプルなロジックを利用していますが、Fastly では client.platform.hwtype
という変数を利用することでデバイスタイプを取得することも可能です。
その他、以下のコードなどを参照して独自のデバイス判別ロジックを実装することも可能です。
注意事項
上記のようなコンテンツの出し分け時の注意事項としては、Fastly 側で設定している X-device-type
の判断と、オリジン側でモバイル向け、デスクトップ向けのコンテンツを生成する際の判断を完全に一致させる必要があります。
この判断ロジックがずれてしまっていると、オリジン側がモバイル用に作成したコンテンツを Fastly サーバー側がデスクトップ用コンテンツとしてキャッシュし、デスクトップに配信してしまう、もしくはその逆のパターンが発生してしまう恐れがあります。
オリジン側でのコンテンツ出し分けのためのデバイス判断ロジックを User-Agent
の値から行うのではなく、Fastly がリクエストに付与した x-device-type
ヘッダーの値を利用して行うで、この判断ロジックの不一致の問題は避けることが出来ます。
Vary コンテンツの Purge
Vary ヘッダーを利用して同一 URL に対して複数のバリエーションのコンテンツがある場合の Purge (キャッシュ削除)ですが、Vary によって異なるバージョンのコンテンツでも Fastly 内でキャッシュを識別するための Cache Key は同じになります。
例えば、index.html にモバイル向け、デスクトップ向けのバリエーションが存在したとしても、index.html が対象となるPurge リクエストを送るとすべてのバリエーションが一度に削除されます。
余談
上でも説明したように、Vary に設定しているヘッダーの値が一文字でも異なると Fastly サーバーは異なるバージョンのキャッシュを保持します。Vary に Accept-Encoding
が設定されている(Vary: Accept-Encoding
)場合、以下の3種類はすべて gzip 圧縮された同じコンテンツにも関わらずそれぞれ別のキャッシュオブジェクトとして保持されてしまうことになります。
Accept-Encoding: gzip
Accept-Encoding: gzip, br, deflate
Accept-Encoding: gzip,br,deflate
実は Fastly では無駄なキャッシュのバリエーションを増やさないように、上記の3種類を同じ Accept-encoding として正規化する処理がデフォルトで実装されています。これは通常の設定画面からは見ることが出来ない Fastly の Master VCL との中で実装されています。どのようなコードで実装されているか興味がある人は以下のブログをご参照下さい。
https://www.fastly.com/blog/best-practices-using-vary-header