キャッシュ戦略 とは？

よく使われる基本のパターンだよ。①アプリがキャッシュを確認、②あればそれを返す（ヒット）、③なければDBから取得してキャッシュに入れてから返す（ミス）。必要なデータだけがキャッシュに入るのが利点で、DBを更新してもキャッシュはそのままだから、古いデータが残る点に注意が必要だね。

①TTL（有効期限）を付けて期限切れで取り直す、②データ更新時にキャッシュを削除する、③Write-ThroughでDBに書くたびにキャッシュも更新する、などを組み合わせるよ。ただ、複数のサーバーが同時に更新するとずれが残ることもある。「キャッシュの無効化と命名はコンピューター科学の2大難問」という有名な言葉があるくらい、難しいところなんだ。

決まった正解はなくて、データがどれくらいの頻度で変わるか、古い値をどれくらい許せるかで決めるよ。たとえば変更の少ない商品カテゴリは長め、在庫数のように正確さが大事なものは短くするかキャッシュしない、という考え方だね。AWSも、値は実際の動きを測って決めるよう勧めているよ。

代表的なのは、新しいサーバーの起動直後などでキャッシュが空のときに、大量のリクエストが一斉にDBへ向かう問題だよ。Thundering HerdやCache Stampedeと呼ばれるね。AWSの資料では、まだキャッシュにないデータの取得を1件だけにまとめて、ほかのリクエストはその結果を待たせる「リクエスト合体」という対策が紹介されているんだ。

AWSの資料では、TTLを「ここで更新を試みる期限」と「ここまでは古くても返してよい期限」の2段階にして、元のDBやサービスが落ちている間は少し古い値で応答を続ける方法が紹介されているよ。エラー応答を短いTTLでキャッシュして、落ちている相手へ何度も問い合わせない工夫もあるんだ。どこまで古い値を許すかは、データの性質で決めよう。