キャッシュ戦略とは？ ― システムを速くする「データの置き場所」の設計
キャッシュ戦略とは、頻繁にアクセスされるデータを高速なストレージ（メモリなど）に一時的に保存し、アプリケーションの応答速度を向上させるための設計方針です。どのデータをキャッシュするか、いつ更新するか、いつ破棄するかを体系的に決めることで、パフォーマンスとデータの鮮度のバランスを最適化します。
冷蔵庫と買い物の関係で例えると、毎食ごとにスーパーへ行くのは非効率です（毎回DBにアクセス）。よく使う食材を冷蔵庫にストックしておけば（キャッシュ）、すぐに料理を始められます。ただし、食材には賞味期限（TTL）があり、古くなったら入れ替える必要があります。キャッシュ戦略とは、この「何をストックし、いつ入れ替えるか」のルールを決めることです。
キャッシュが必要になる場面
すべてのシステムにキャッシュが必要なわけではありません。キャッシュの導入を検討すべき典型的なシーンは以下のとおりです。
データベースクエリが遅い：複雑なJOINや集計処理で応答に数百ミリ秒〜数秒かかる場合、結果をキャッシュすれば数ミリ秒で返せます。
外部APIの呼び出しが多い：為替レートや天気情報など、頻繁に変わらないデータを毎回取得するのは無駄です。適切なTTLでキャッシュすれば、API呼び出し回数とコストを削減できます。
同じデータへの読み取りが集中する：ECサイトのトップページや人気商品の詳細ページなど、同じデータに大量のリクエストが集中する場合に効果的です。
代表的なキャッシュパターンの比較
| パターン | 読み取り時 | 書き込み時 | 特徴 |
|---|---|---|---|
| Cache-Aside（レイジーローディング） | キャッシュになければDBから取得し、キャッシュに保存 | DBに書き込み、キャッシュを無効化 | 最も一般的。必要なデータだけがキャッシュされる |
| Read-Through | キャッシュ層がDB取得を自動的に行う | （別途Write戦略と組み合わせ） | アプリコードがシンプルになる |
| Write-Through | キャッシュから取得 | キャッシュとDBに同時書き込み | データの一貫性が高い。書き込みは遅くなる |
| Write-Behind（Write-Back） | キャッシュから取得 | キャッシュに書き込み、後からDBに非同期書き込み | 書き込みが高速。データロスのリスクあり |
Cache-Asideパターンを深掘りする
最も広く使われているのがCache-Aside（キャッシュアサイド）パターンです。
読み取りの流れ：①アプリがキャッシュにデータを問い合わせる → ②キャッシュにあれば（キャッシュヒット）そのまま返す → ③なければ（キャッシュミス）DBから取得 → ④取得したデータをキャッシュに保存 → ⑤データをアプリに返す
書き込みの流れ：①アプリがDBにデータを書き込む → ②対応するキャッシュエントリを無効化（削除）する
このパターンの利点は、実際にアクセスされたデータだけがキャッシュに載る点です。使われないデータでメモリを浪費しません。一方、キャッシュミス時には「DB取得＋キャッシュ保存」のオーバーヘッドが加わるため、初回アクセスは通常より遅くなります（コールドスタート問題）。
TTL（Time To Live）の設計指針
TTLはキャッシュの「賞味期限」です。適切なTTL設定は、データの鮮度とパフォーマンスのバランスを左右します。
短いTTL（数秒〜数分）：頻繁に更新されるデータ（在庫数、リアルタイム価格など）に適しています。データの鮮度は高いですが、キャッシュミスが多くなりDBへの負荷が増えます。
長いTTL（数時間〜数日）：めったに変わらないデータ（商品カテゴリ一覧、設定値など）に適しています。キャッシュヒット率が高くパフォーマンスは良いですが、データが古くなるリスクがあります。
TTLなし（手動無効化）：データ更新時にアプリケーション側で明示的にキャッシュを削除します。データの一貫性は最も高いですが、無効化の漏れがバグになりやすいです。
キャッシュで起こる3大トラブルと対策
キャッシュスタンピード（Thundering Herd）：人気データのキャッシュが同時に期限切れになると、大量のリクエストが一斉にDBに殺到します。対策として、TTLにランダムなジッターを加えて期限切れを分散させたり、1つのリクエストだけがDBにアクセスし他は待機するロック機構を導入します。
キャッシュペネトレーション：存在しないデータへのリクエストは常にキャッシュミスとなり、毎回DBにアクセスしてしまいます。対策として「存在しない」という結果自体を短いTTLでキャッシュしたり、ブルームフィルターで存在チェックを行います。
データの不整合：DBのデータが更新されたのにキャッシュが古いままの状態です。Write-Throughパターンの採用や、更新時のキャッシュ無効化を確実に行う仕組みで対処します。
キャッシュの配置場所
ブラウザキャッシュ：Cache-Controlヘッダーで制御。画像・CSS・JSなどの静的リソースに効果的。ユーザーに最も近く、サーバー負荷をゼロにできます。
CDN（Content Delivery Network）：世界各地のエッジサーバーにコンテンツを配置。地理的に近いサーバーから配信するため、レイテンシが大幅に低減します。
アプリケーションキャッシュ：Redis、Memcachedなどのインメモリストア。動的コンテンツやAPIレスポンスのキャッシュに最適です。
データベースキャッシュ：DBエンジン内蔵のクエリキャッシュやバッファプール。設定で有効化でき、アプリ側の変更が不要です。
よくある質問（FAQ）
Q. キャッシュヒット率はどのくらいを目指すべきですか？
A. 一般的に80〜95%が目標です。ヒット率が低い場合は、TTLの調整、キャッシュするデータの見直し、プリウォーミング（事前にキャッシュを温める処理）を検討しましょう。
Q. キャッシュの無効化はなぜ難しいのですか？
A. Phil Karltonの名言「コンピュータサイエンスで難しいことは2つだけ。キャッシュの無効化と名前付け」の通り、「いつ・何を・どうやって」無効化するかの判断が複雑です。特に複数サービスがキャッシュを共有する環境では、無効化の伝播が課題になります。
Q. ローカルキャッシュと分散キャッシュはどう使い分けますか？
A. 単一サーバーならローカルキャッシュ（HashMap等）で十分です。複数サーバー環境では、Redisなどの分散キャッシュを使ってサーバー間でキャッシュを共有します。両方を併用する二層キャッシュ（ローカル → Redis → DB）も効果的です。
まとめ
キャッシュ戦略は、アプリケーションのパフォーマンスを左右する重要な設計判断です。Cache-Aside、Write-Through、Write-Behindなどのパターンを理解し、データの特性に応じてTTLと配置場所を適切に選択しましょう。キャッシュスタンピードやペネトレーションといった落とし穴を事前に把握しておくことで、安定した高速なシステムを構築できます。
コメント