キャッシュ汚染と戦うための「Vary」戦略：インフラアーキテクトが語る最適化の深淵
HTTP/1.1の時代から、私たちは「キャッシュ効率」と「コンテンツの多様性」という二律背反する命題と戦い続けてきた。フロントエンドのCDNやリバースプロキシで `Vary` ヘッダーを適切に設計できるか否かは、オリジンサーバーの負荷、ひいてはサービス全体のレスポンスタイムを左右する死活問題だ。
今日は、教科書的な説明は脇に置き、パケットがネットワークを駆け巡り、キャッシュサーバーのメモリ空間で何が起きているのか、その深層を紐解いていこう。
—
1. Varyヘッダーの「罪」とキャッシュヒット率のジレンマ
`Vary: User-Agent`。この指定を安易に行っていないだろうか？ 多くのエンジニアが「ブラウザごとに最適化された画像を返したい」という動機でこれを使用するが、これは現代のWebインフラにおいてはキャッシュ戦略の自殺行為に近い。
なぜ `Vary: User-Agent` は危険なのか
現代のUser-Agent文字列は、ブラウザのバージョン、OS、デバイス種別など、無数の断片情報を含んでいる。CDNは `Vary` に指定されたヘッダー値の「ハッシュ」をキャッシュキーの一部として管理する。つまり、User-Agentが少しでも異なれば、オリジンへのリクエスト（Cache Miss）が発生し、キャッシュの断片化が爆発的に進む。
- キャッシュの断片化（Cache Fragmentation）: 同じコンテンツなのに、User-Agentのわずかな差異でキャッシュストレージが溢れ、本来ヒットすべきオブジェクトが追い出される（LRUの強制駆動）。
- オリジンの負荷増大: キャッシュミスが連鎖し、バックエンドのCPUとDBにトドメを刺す。
推奨されるアプローチ
インフラアーキテクトとして推奨するのは、「Varyの正規化」だ。
CDN（FastlyやCloudflare等）の設定で、User-Agentをそのままキーにするのではなく、デバイスタイプ（Mobile/Desktop/Tablet）といった「抽象化された変数」に変換してからキャッシュキーを生成すべきである。
—
2. トランスポート層とヘッダー圧縮の最適化
`Vary` による出し分けが不可避な場合、次に問題となるのは「ヘッダーのオーバーヘッド」だ。HTTP/1.1ではテキストベースのヘッダーがTCPのSlow Start区間を圧迫する。
TCPバッファと初期輻輳ウィンドウ（initcwnd）
RTT（Round Trip Time）を最小化し、最初の10msでいかに多くのデータを流し込むか。Linuxカーネルレベルで `tcp_init_cwnd` を 10 に設定することは、現代の標準的なプラクティスだ。
sysctlによるTCP輻輳ウィンドウのチューニング
初期ウィンドウを10パケットに増大させ、初期ハンドシェイクの効率を上げる
sysctl -w net.ipv4.tcp_slow_start_after_idle=0
sysctl -w net.ipv4.tcp_init_cwnd=10
また、TLS 1.3の導入は必須だ。0-RTTハンドシェイクにより、前回のセッション情報を活用してRTTを削り取る。ここで `Vary` ヘッダーの影響を受けるコンテンツが重複すると、TLSレコードのパディングや圧縮効率に微妙な差が生じ、セキュリティ上のサイドチャネル攻撃（CRIME/BREACH系の亜種）の懸念もゼロではない。
—
3. 実践：Nginx/VarnishでのVary制御
Varnish VCLやNginxでの設定においては、`Vary` を「絞り込む」ことが鉄則だ。以下は、不要なUser-Agentのキャッシュ汚染を防ぎつつ、必要な `Accept-Encoding`（圧縮）のみをキャッシュキーに含めるためのNginx設定例である。
Nginxにおけるキャッシュキーの正規化設定
map $http_accept_encoding $vary_accept_encoding {
“~gzip” “gzip”;
“~br” “br”;
default “”;
}
location / {
# VaryをAccept-Encodingのみに限定し、User-Agentの影響を排除する
proxy_set_header Accept-Encoding $vary_accept_encoding;
proxy_hide_header Vary;
add_header Vary “Accept-Encoding”;
# キャッシュキーの設計（User-Agentを除外する）
proxy_cache_key “$scheme$request_method$host$request_uri”;
}
なぜこれを行うのか？
- `proxy_hide_header Vary`: オリジンが返した過剰な `Vary` ヘッダーを一旦破棄し、CDN側で再定義する。
- `proxy_cache_key` の最適化: `User-Agent` を含めないことで、キャッシュのヒット率を劇的に向上させる。
—
4. 結び：インフラは「状態」を制御するアートである
ネットワークのパフォーマンスとは、結局のところ「パケットをどれだけ無駄に移動させないか」という物理的な制約との戦いに他ならない。`Vary` ヘッダーを正しく理解し、キャッシュキーを戦略的に設計することは、単なる設定変更ではなく、インフラという巨大なシステムの状態管理そのものである。
- User-Agentによるキャッシュの断片化を排除せよ。
- Varyは最小限のヘッダー（Accept-Encoding等）に絞れ。
- TLS 1.3とTCPチューニングでRTTのペナルティを相殺せよ。
次回の運用では、ぜひCDNのキャッシュヒット率のグラフを眺めながら、「このリクエストは本当にオリジンまで到達する必要があったのか？」を自問自答してみてほしい。その問いの先に、真のアーキテクトの視界が広がっているはずだ。
コメント