キャッシュの場所と対象

どこに置けるか: ユーザーに近いほど速い

キャッシュはリクエストの経路上、いろいろな場所に置けます。ユーザーに近いほど速いが、制御は難しくなります。

図を描画中...

場所	内容	特徴
①Client	ブラウザ・OSのキャッシュ	最速だが制御しづらい
②CDN	エッジサーバーのキャッシュ	静的配信に強い
③Web server	リバースプロキシ(Varnish)	静的/動的を直接返す
④Database	DBが内蔵するキャッシュ	設定で調整
⑤Application	Redis/Memcached	制御しやすく高速

アプリキャッシュ(Redis / Memcached)が主役

設計で『キャッシュを入れる』と言うとき、多くはこのアプリケーションキャッシュを指します。インメモリのキー・バリューストアで、RAM上なのでDB(ディスク)より高速。

ただしRAMは有限。入りきらなくなったら**LRU(Least Recently Used = 最近使われていない順)**などで古いものを追い出します。

RedisはMemcachedの上位互換的な高機能版で、**永続化(再起動でも消えない)**や、sorted set・listといった便利なデータ構造を持ちます。ランキングやキューにも使えます。

何をキャッシュするか(粒度)

クエリレベル

SQLクエリ文字列をハッシュ化してキーにし、結果を保存。

• 長所: 作るのが簡単。
• 短所(つまずき所): 無効化が難しい。元データの1セルが変わっただけで、そのセルを含むあらゆるクエリのキャッシュを消さないと古い結果が残る。どのクエリが影響を受けるか特定しづらい。

オブジェクトレベル

データを『オブジェクト』(例: ユーザーオブジェクト、レンダリング済みページ)として丸ごとキャッシュ。

• 長所: 無効化しやすい(そのオブジェクトを消せばよい)。非同期処理とも相性が良い。
• 対象例: ユーザーセッション、完全レンダリング済みページ、アクティビティストリーム、ユーザーのグラフデータ。

図を描画中...

つまずきポイント

• クエリレベルキャッシュの無効化の難しさは実務で本当に厄介。基本はオブジェクトレベルで考える方が管理しやすい。
• file-basedキャッシュ(各サーバーのローカルファイル)は、サーバーをクローン・オートスケールしづらくするので避ける。共有のRedis/Memcachedへ。