キャッシュ戦略
キャッシュとは
キャッシュは、一度取得・計算した結果を保存しておき、次回は保存済みのものを返すことで応答を速くする仕組みです。データベースへの問い合わせや外部 API 呼び出しは時間がかかるため、同じ結果を何度も作り直すのは無駄 — これを省くのがキャッシュの役割です。
その代わり、元データが変わってもキャッシュは古いままという宿命を背負います。「キャッシュの無効化は計算機科学の二大難問の一つ」と言われるほど、消しどきの設計が本質です。
キャッシュはどこに置けるか
リクエストがユーザーからデータベースに届くまでの各層に、キャッシュを置く場所があります。
| 置き場所 | 例 | 特徴 |
|---|---|---|
| ブラウザ | [[HTTPキャッシュ]] | サーバーに届く前に解決。最速 |
| 配信網 | [[CDN]] | 世界中の拠点から静的ファイルを配信 |
| アプリサーバー | プロセス内メモリ | 手軽だがサーバー間で共有できない |
| 共有キャッシュ | [[Redis]] など | 複数サーバーで共有できる定番の置き場所 |
| データベース | クエリ結果キャッシュ | [[リレーショナルデータベース]] の負荷を軽減 |
代表的な戦略
キャッシュアサイド(Cache-Aside)が最もよく使われるパターンです。
- まずキャッシュを見る — あれば返す(ヒット)
- 無ければ(ミス)データベースから取得する
- 取得した結果をキャッシュに保存してから返す
更新時の整合性を保つ基本は「更新したらキャッシュを消す」ことです。また、保存時に TTL(Time To Live — 有効期限)を設定し、期限が切れたら自動で消えるようにするのが安全側の基本策です。
初学者向けポイント
- 「表示がおかしい→キャッシュ削除で直った」は実務の日常茶飯事です。障害調査ではまずどの層のキャッシュが効いているかを疑いましょう
- キャッシュヒット率は監視すべき代表的な指標です。ヒット率が低いキャッシュはコストだけ払っている状態です
- 期限切れの瞬間にアクセスが殺到して裏のDBに負荷が集中するサンダリングハード問題(cache stampede)という現象も知っておくと役立ちます
関連技術とのつながり
- [[Redis]] — 共有キャッシュの定番。インメモリで高速
- [[CDN]] — 静的コンテンツのキャッシュを世界規模で行う
- [[HTTPキャッシュ]] — ブラウザ側のキャッシュを制御するヘッダーの仕組み
- [[リレーショナルデータベース]] — キャッシュが守る対象。DB負荷軽減が主目的の一つ
Q: キャッシュの基本的な目的はどれ?
- [ ] データを暗号化して安全に保管する
- [x] 取得・計算済みの結果を再利用して応答を速くする
- [ ] データベースの容量を増やす
解説: キャッシュは同じ結果を作り直す無駄を省き、応答速度を上げるための仕組みです。
Q: キャッシュアサイド方式でキャッシュミスした場合の動きはどれ?
- [ ] エラーを返して処理を終了する
- [ ] キャッシュが作られるまで待機する
- [x] データベースから取得し、結果をキャッシュに保存してから返す
解説: ミス時はデータ源から取得してキャッシュに書き戻すのがキャッシュアサイドの基本形です。
Q: TTLを設定する目的はどれ?
- [x] 期限が切れたキャッシュを自動で消し、古いデータが残り続けるのを防ぐ
- [ ] キャッシュの読み取りを高速化する
- [ ] キャッシュへのアクセス権限を管理する
解説: TTL は有効期限です。消し忘れても期限で自動的に消えるため、古いデータが残るリスクを抑えられます。