典型的なウェブスタックにおけるキャッシュレイヤーとは何ですか?

Question

Accepted Answer

リクエストは**複数のキャッシュレイヤー**を通過し、各レイヤーはユーザーに近いほど高速ですが容量は少なくなります。考え方は、できるだけ遠く(クライアントに近く)で応答し、アップストリームのレイヤーが応答を提供できない場合にのみオリジンにフォールスルーすることです。

## レイヤー(外から内へ)

```text
Browser → CDN → Reverse proxy → App/object cache → OPcache → Database
(closest to user, fastest)                            (closest to data)
```

- **ブラウザキャッシュ** — スタティックアセット(JS、CSS、画像)とキャッシュ可能なレスポンスをユーザーのデバイスに保存します。TTLは`Cache-Control`/`ETag`で制御され、アセットはしばしばハッシュ付きファイル名で長いTTL(日~年)を持ちます。
- **CDN** (CloudFront、Cloudflare) — スタティックおよび時々ダイナミックコンテンツをユーザー近くのエッジノードにキャッシュします。TTLは分単位(HTML)から1年(イミュータブルアセット)です。
- **リバースプロキシ** (Varnish、nginx) — アプリの前に完全なページまたはフラグメントをキャッシュします。ホットなページは秒~分のTTL、変更時にパージをサポートします。
- **アプリケーション/オブジェクトキャッシュ** (Redis、Memcached) — 計算結果、DBクエリ結果、セッション、レンダリング済みフラグメントをキャッシュします。秒~時間のTTL、プラス明示的なインバリデーション。
- **OPcache** — **コンパイル済みPHPバイトコード**をメモリにキャッシュしため、スクリプトはリクエストごとに再パースされません。コードデプロイまで実質的に永続的です。
- **DBクエリ/バッファキャッシュ** — データベースはホットなページと(エンジンによっては)クエリ結果をメモリに保持し、ディスク読み取りを回避します。

## これらについて考える方法

```text
for each layer outward → inward:
  if layer has fresh copy → return it (stop here)   // a hit; cheapest possible
  else → ask the next layer in                      // a miss; falls through
origin (app + DB) → does the real work, fills caches on the way back out
```

各レイヤーは**鮮度と速度をトレードオフ**します: 外側のレイヤーは最速ですが最も陳腐化しやすいため、本当にスタティックなものに長いTTL+コンテンツハッシングを配置し、ダイナミックなものに短いTTL+インバリデーションを配置してください。

## なぜ重要なのか

ウェブスタックの大部分のレイテンシとロード削減は、正しいレイヤーでのキャッシングから来ます。各レイヤーが保持するものとその典型的なTTLを知ることで、キャッシュを実際に役立つ場所に配置でき、古いデータの提供を避けることができ、変更が表示されなかった理由(どのレイヤーが古いコピーを提供しているか)を推論できます。