Varyヘッダーが支配するHTTPキャッシュの深淵：CDN最適化とプロトコルレベルの攻防
インターネットのトラフィックの大部分がHTTP/HTTPS、そしてその上に構築されたWeb APIやCDN（Content Delivery Network）のレイヤーで流れている現代において、「キャッシュ」はインフラストラクチャの生死を分ける最重要のファクターだ。
教科書的なREST API設計では「リソースのURIが一意であること」が美徳とされる。しかし、現実のWebアプリケーションは冷酷なまでに多様性に満ちている。同じ /api/v1/users/profile という単一のエンドポイントであっても、クライアントが要求するデータ形式（application/json なのか application/msgpack なのか）、あるいは圧縮アルゴリズム（gzip、br、さらには次世代の zstd）、そして何より認証状態（Authorization ヘッダーの有無）によって、レスポンスのペイロードは劇的に変化する。
ここで登場するのが、HTTPヘッダーの裏番組でありながら、キャッシュの挙動を完全に支配する魔術師 Vary である。この小さなヘッダーの扱いを誤れば、CDNはキャッシュ汚染（Cache Poisoning）の温床となり、最悪の場合、あるユーザーのプライベートなデータが全く関係のない別のユーザーへ爆心地のようにばらまかれるという致命的なセキュリティインシデントを引き起こす。
今回は、パケットレベルの挙動、トランスポート層・TLSハンドシェイクとの相互作用、そして極限のパフォーマンスを引き出すための Vary ヘッダーの設計思想について、インフラアーキテクトの視点から深く掘り下げていこう。
—
1. キャッシュの鍵穴：Vary ヘッダーのメカニズム
HTTP/1.1（RFC 9110）において、キャッシュサーバー（プロキシやCDN、そしてブラウザのローカルキャッシュ）は、原則としてリクエストの メソッド と リクエストURI のみをキャッシュキーの構成要素として扱う。
しかし、コンテンツネゴシエーション（Content Negotiation）の概念が導入されたことで、この単純なルールでは立ち行かなくなった。同じURLであっても、リクエストヘッダーの値によってレスポンスの中身が変わるためである。
ここでCDNやリバースプロキシ（VarnishやNginxなど）が「どのリクエストヘッダーをキャッシュキーの一部として含めるべきか」を判断するために参照するのが、オリジンサーバーから送出されるレスポンスヘッダー内の Vary である。
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Encoding: br
Vary: Accept-Encoding, Authorization
Cache-Control: public, max-age=3600このレスポンスを受け取ったCDNのエッジサーバーは、内部のキャッシュハッシュマップを生成する際、単に GET /api/v1/users/profile というURL文字列だけでなく、ハッシュ計算の入力値に Accept-Encoding と Authorization のヘッダー値を組み込む。
パケットとメモリ上の挙動
TCPコネクションを流れるバイナリ（HTTP/2やHTTP/3の場合はHPACK/QPACKで圧縮されたヘッダーブロック）をデコードし、エッジサーバーがキャッシュルックアップを行う瞬間を想像してほしい。
1. ルックアップキーの生成: エッジサーバーは、受信したリクエストからURIを抽出し、さらに Vary で指定されたヘッダー名に対応するリクエストヘッダーの値を抽出する。
2. ハッシュの衝突回避: 例えば、あるクライアントが Accept-Encoding: gzip でアクセスし、別のクライアントが Accept-Encoding: br（Brotli）でアクセスした場合、Vary: Accept-Encoding が設定されていれば、これらは完全に独立した別のキャッシュエントリとしてメモリ（あるいはSSDストレージ）上に保持される。
3. ミスヒットの連鎖: もし Vary: Authorization が指定されている場合、トークンが1文字でも異なれば、既存のキャッシュはヒットせず（Cache Miss）、オリジンサーバーへのフェッチが発生する。
—
2. 致命的な罠：ワイルドカードと過剰なバリエーション
インフラエンジニアが現場で最も恐れるべきは、Vary の不適切な設定による キャッシュ効率の崩壊（Cache Thrashing） と キャッシュ汚染 だ。
罠その1：Vary: * の呪い
時折、動的な制御が必要なレガシーアプリケーションにおいて、次のようなヘッダーを見かけることがある。
Vary: *これは仕様上、「このレスポンスは、リクエストヘッダーのいかなる組み合わせによっても内容が変わる可能性があるため、いかなるキャッシュも行ってはならない」という強烈な宣言である。CDNやブラウザはこれを解釈すると、該当リソースのキャッシュを完全に無効化（Bypass）する。
結果として、すべてのリクエストがオリジンサーバーへ直撃し、バックエンドのデータベースやアプリケーションサーバーのCPU使用率が跳ね上がり、DDoS攻撃を受けているかのようなトラフィック枯渇を引き起こす。
罠その2：高頻度で変化するヘッダーの指定
Vary: User-Agent や Vary: Cookie を安易に設定することも、インフラストラクチャにとっては自殺行為に近い。
現代のブラウザやデバイス、拡張機能が送信する User-Agent のバリエーションは数千、数万に及ぶ。もし Vary: User-Agent を指定してしまうと、CDNのエッジノードには「全く同じHTML/JSONであるにもかかわらず、ユーザーエージェントの文字列のわずかな違いごとに数万個のキャッシュファイル」が生成されることになる。
これはCDNのキャッシュヒット率（Hit Ratio）を劇的に低下させ、オリジンサーバーへのバックホールトラフィックを爆発的に増大させる原因となる。デバイスごとの出し分けが必要な場合は、サーバーサイドでUAをパースしてレスポンス内容を静的に固定するか、エッジワーカー（Cloudflare WorkersやFastly VCLなど）で必要な最小限のプレフィックス（例: Mobile か Desktop か）に正規化してキャッシュキーを再定義すべきである。
—
3. パフォーマンスとセキュリティの交差点：TLSハンドシェイクとヘッダー圧縮
Vary ヘッダーの制御は、トランスポート層や暗号化レイヤーの最適化とも密接に結びついている。
HTTP/2およびHTTP/3におけるHPACK/QPACKの恩恵
HTTP/1.1の時代、リクエストヘッダーのサイズ（特に長大な Authorization トークンや複雑な User-Agent）は、RMT（Round Trip Time）や初期輻輳ウィンドウ（Initial Congestion Window）の制約下において無視できないオーバーヘッドであった。
HTTP/2以降では、HPACK（HTTP/2）やQPACK（HTTP/3）という動的テーブルを用いたヘッダー圧縮アルゴリズムが採用されている。これにより、頻繁に送信されるリクエストヘッダーはインデックス化され、数バイトの圧縮データとして送信される。
しかし、Vary によってキャッシュキーのバリエーションが肥大化している場合、CDN側は多様なリクエストヘッダーの組み合わせをメモリ上で管理し続ける必要があり、エッジサーバーのメモリフットプリントを確実に圧迫する。
TLSセッション再利用とSNIの最適化
APIリクエストがHTTPSで行われる場合、TLS 1.3のハンドシェイク（1-RTT、あるいはSession Resumptionによる0-RTT）が完了した後にHTTPリクエストが流れる。
もし Vary の設計ミスによりキャッシュミスが頻発し、オリジンへのバックエンド通信が増加すると、バックエンドとの間のTCPコネクション確立およびTLSハンドシェイクのオーバーヘッドが蓄積し、全体のレイテンシ（TTFB: Time to First Byte）が雪だるま式に悪化する。
インフラアーキテクトとしては、「CDNエッジで吸収できるものはエッジで完全に完結させ、オリジンへのリクエストは最小限の共通化されたヘッダーのみでルーティングする」 という鉄則を貫く必要がある。
—
4. 実践：NginxとFastAPIによる堅牢な Vary 制御の実装例
理論はこのあたりにして、実際にプロダクション環境で耐えうる堅牢な実装を見ていこう。
ここでは、モダンな非同期Pythonフレームワークである FastAPI をオリジンサーバーとし、フロントに Nginx（リバースプロキシ/キャッシュサーバー）を配置した構成を想定する。
FastAPI側での適切なヘッダー制御
APIレスポンスにおいて、圧縮（gzip / br）はNginxなどのリバースプロキシやCDN側に任せるのが定石だが、クライアントの権限（Authorization）に応じてレスポンスが変わるエンドポイントでは、明示的に Vary を付与する必要がある。
from fastapi import FastAPI, Header, Response, HTTPException
from typing import Optional
app = FastAPI()
@app.get("/api/v1/user/settings")
async def get_user_settings(
response: Response,
authorization: Optional[str] = Header(None)
):
"""
ユーザー設定を取得するエンドポイント。
Authorizationヘッダーに応じて返却値が異なるため、
Varyヘッダーに明示的に指定し、かつ不正なキャッシュを防ぐ。
"""
if not authorization:
raise HTTPException(status_code=401, detail="Unauthorized")
# セキュリティ上の理由から、認証されたプライベートデータはパブリックキャッシュを拒否する
# プライベートキャッシュ（ブラウザなど）のみ許可し、CDNでの共有キャッシュを防ぐ場合は private を使用
response.headers["Cache-Control"] = "private, no-transform"
# 万が一、プロキシサーバーがキャッシュを試みる場合の保険としてVaryを設定
response.headers["Vary"] = "Authorization, Accept-Encoding"
# モックとしてのレスポンスデータ
return {
"user_id": 42,
"theme": "dark",
"notifications_enabled": True
}Nginx側でのキャッシュキーと Vary のハンドリング設定
Nginxをリバースプロキシとして使用する場合、デフォルトのキャッシュ機構は Vary ヘッダーを完全にネイティブサポートしているわけではない（商用版のNginx Plusや、Varnish、あるいは昨今のCDNプロダクトであれば自動処理されるが、オープンソース版Nginxでは工夫が必要）。
以下の nginx.conf のスニペットは、proxy_cache_key を明示的に定義し、意図しないキャッシュ汚染を防ぎつつ、パフォーマンスを最大化する設定例である。
http {
# キャッシュ領域の定義（10MB、最大1GBのストレージ、非アクティブ時は60分でパージ）
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m use_temp_path=off;
server {
listen 443 ssl http2;
server_name api.example.com;
# SSL/TLS設定（省略）
ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
location /api/ {
proxy_pass http://backend_cluster;
# 【重要】キャッシュキーの明示的定義
# 単純なURLだけでなく、認可トークンのハッシュやAccept-Encodingをキーに含めることで
# Varyヘッダーの挙動をNginxのプロキシキャッシュ側で制御する
# $cookie_session や $http_authorization をそのままキーにすると情報漏洩リスクがあるため、
# 必要に応じて md5 ハッシュ化するなどの配慮が望ましい
proxy_cache api_cache;
proxy_cache_key "$scheme$request_method$host$uri$http_accept_encoding";
# ステータスコードごとのキャッシュ有効期間
proxy_cache_valid 200 10m;
proxy_cache_valid 404 1m;
# クライアントからのキャッシュバイパス要求を許可
proxy_cache_bypass $http_pragma $http_authorization;
# バックエンドからのVaryヘッダーを透過させる
proxy_hide_header Vary;
add_header Vary "Accept-Encoding, Authorization" always;
# マイクロキャッシュや接続最適化のためのバッファチューニング
proxy_buffering on;
proxy_buffer_size 4k;
proxy_buffers 8 32k;
proxy_busy_buffers_size 64k;
# アップストリームへのタイムアウト設定
proxy_connect_timeout 5s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;
}
}
}この設定において特筆すべきは、proxy_cache_key に $http_accept_encoding を明示的に組み込んでいる点だ。これにより、同じURLであってもgzipを好むクライアントとBrotliを好むクライアントの間で、Nginxのエッジ側が適切にキャッシュを分離し、CPU負荷の高い圧縮処理をオリジンに戻すことなくエッジで処理し続けることが可能になる。
—
5. 結び：インフラアーキテクトが持つべき視座
Vary ヘッダーは、HTTPプロトコルの歴史が生んだ「柔軟性と複雑性のトレードオフ」を象徴する機能の一つである。
単なる「おまじない」として適当なヘッダー名を並べるだけの開発スタイルは、スケールした瞬間にシステムを崩壊させる時限爆弾に他ならない。パケットがどのレイヤーを通過し、どのメモリ領域にキャッシュされ、どのような暗号化コンテキストの上で復号されているか。その一連の流れを頭の中で完全にトレースできるインフラエンジニアだけが、極限のパフォーマンスと鉄壁のセキュリティを両立したWeb APIアーキテクチャを構築できる。
仕様書の向こう側にあるパケットの息吹を感じ取りながら、今日も美しく洗練されたプロトコル設計を追求しよう。
コメント