キャッシュ設計の落とし穴8選｜スタンピード・TTL・整合性

RJC Techチーム

キャッシュって、入れれば速くなる魔法に見えるんですよね。

でも計算機科学には、こんな有名な格言があります。「計算機科学で難しいことは2つしかない。キャッシュの無効化と、命名だ」（フィル・カールトン）——半分冗談、半分本気の警告です。

今回は、「キャッシュがあるのに落ちた」の正体から、その「難しい方」を8つ集めました。1つでも知らなかったら儲けものです。

① キャッシュの寿命が揃うと、全滅も揃います

デプロイ直後にキャッシュを一斉投入。TTLは60秒。きれいな設計に見えますよね。

60秒後、すべてのキーが同時に消滅します。その瞬間、全リクエストがキャッシュを素通りしてDBを直撃。キャッシュがあるのに、無いのと同じ負荷が一撃で来ます。

キャッシュスタンピード（殺到）と呼ばれる定番の障害で、対策はシンプルです。

TTLにランダムな揺らぎを足す。60秒±10秒にするだけで、消滅タイミングがばらけて、崖が坂になるんです。

①の親戚で、もっと局所的なやつです。

人気商品のキャッシュが切れた瞬間、待っていた1000リクエストが全員でDBに再生成しに行きます。答えは全員同じなのに、同じ重いクエリが1000本走る。

定石は、最初の1人だけが再生成し、残りは待つか古い値を使う仕組みです。「多重リクエストの排除（request coalescing）」と呼ばれます。

キャッシュが切れる瞬間の振る舞いまで決めて、初めて設計なんですよね。

意外と知られていない防御が、これです。

存在しないIDへのアクセスは、キャッシュに乗らないので毎回DBまで貫通します。攻撃者がランダムなIDを大量に叩けば、キャッシュを完全に素通りしてDBを殴れるわけです。

対策は、「存在しなかった」という事実そのものを短いTTLでキャッシュすること。ネガティブキャッシュと呼ばれ、DNSの世界では昔から標準装備です。

キャッシュは「あるもの」だけでなく「ないもの」も守備範囲なんです。

データを更新するとき、DBとキャッシュのどちらを先に触るか。ここに答えがあります。

定石は、「DBを更新してから、キャッシュを削除する」です。

逆（先にキャッシュ削除）だと、削除とDB更新のわずかな間に他のリクエストが来て、古いDBの値を読んでキャッシュに書き戻してしまう。以後、TTLが切れるまで古い値が生き続けます。

なお、正しい順番でもタイミング次第で極めて稀な競合は残ります。だからTTLは保険として必ず付けておくのがセットです。

「更新したのに画面が変わらない、でもしばらくすると直る」——この症状を見たら、まずこの順番を疑ってください。

視点が変わる話です。

キャッシュヒット率99%のシステムでキャッシュが消えると、DBへの負荷は1%→100%、つまり100倍になります。DBは100倍に耐えられる設計になっていますか？

なっていないなら、そのキャッシュはもう「高速化のおまけ」ではなく、DBを守る防波堤＝落ちてはいけない基盤です。

「キャッシュはいつ消えてもいいもの」という初期の前提が、成長したシステムでは崩れている。キャッシュ障害＝全面障害になっていないか、一度は棚卸ししたい観点です。

各アプリサーバーのメモリ内にキャッシュを持つと、速いんですが副作用があります。

サーバーが10台あれば、10個の別々のキャッシュが存在します。更新を1台が反映しても、残り9台は古いまま。ユーザーはロードバランサ次第で、リロードするたびに新旧の値を行き来します。

「更新が反映されたり戻ったりする」という怪奇現象の正体は、だいたいこれです。

対策は、共有キャッシュに寄せるか、ローカルのTTLを短くして「ズレの上限」を仕様として明言するか。ズレをゼロにするより、ズレの幅を約束する方が現実的なんです。

キャッシュサーバーを何台に増やしても、アクセスが1つのキーに集中していたら、そのキーを持つ1台に全負荷が乗ります。

セール対象の1商品、話題の1投稿。分散の仕組みはキーを台数に散らすので、「1つのキーの中」は散らせないんですよね。

対策は、キーを複製して読み分ける（同じ値をkey#1〜key#Nで持つ）、あるいはアプリ側の超短命ローカルキャッシュで受ける。

負荷分散は「キーの数」に効き、「キーの偏り」には効かない。この区別が設計の分かれ目です。

最後は、判断基準の話です。

キャッシュに入れる価値は、「再計算の重さ × 読まれる頻度 × 鮮度のゆるさ」の掛け算で決まります。