キャッシュの概要

たとえ話: 机の上のメモ

調べ物をするたびに毎回図書館(=DB、遅い)へ行くのは大変です。そこでよく使う情報を手元のメモ(=キャッシュ、速い)に書き写しておく。次からはメモを見るだけで済み、図書館へ行く回数が激減します。

これがキャッシュの本質。よく使うデータを、近くて速い場所にコピーしておくことで、遅い元データへのアクセスを減らします。

図を描画中...

なぜそんなに速くなるのか

メモリ(RAM)はディスクより圧倒的に速いからです。System Design Primerのレイテンシ数値より:

• メモリから1MB連続読み取り ≒ 250マイクロ秒
• SSDから1MB ≒ 1,000マイクロ秒(メモリの4倍遅い)
• HDDシーク ≒ 10,000マイクロ秒(メモリの40倍遅い)

つまりDBがディスクを叩くところを、メモリのキャッシュで返せれば数倍〜数十倍速くなります。さらにDB自体の負荷も減るので一石二鳥。

トラフィックの波を吸収する

キャッシュはDBの『盾』にもなります。アクセスが急増(スパイク)しても、その大半をキャッシュが受け止めれば、DBには一部しか届きません。これで不均一な負荷を平滑化できます。

最大の難問: キャッシュ無効化

キャッシュの便利さの裏には、永遠の課題があります。

元データ(DB)が変わったとき、コピー(キャッシュ)も更新しないと、古い情報を見せてしまう。

『いつ』『どうやって』古いキャッシュを捨てる/更新するかは難しく、これが次の『キャッシュ更新戦略』の主題です。

つまずきポイント

• キャッシュは『速くなる魔法』だが、整合性という代償がある。古いキャッシュ(stale)を返す事故は典型的なバグ。
• file-basedキャッシュ(ファイルに保存)は、サーバーを複製・オートスケールしづらくするので避け、Redis/Memcachedのような共有メモリストアを使うのが定石。

---

📊 図解

図解: キャッシュヒット / ミスの流れ

まずキャッシュを見て、あれば即返す(hit)。無ければ(miss)DBから取得し、次回のためにキャッシュへ保存する。miss の経路だけがDBに到達する点が、DB負荷軽減の本質。

図を描画中...