この間、職場でキャッシュが原因でデータ取得エラーが発生したことがありました。
そこでふと、
「そもそもキャッシュって何だろう？」
という疑問が浮かびました。
それまでは、
「データをより早く取得するために、一時的に保存しておくもの」
という程度の理解しかありませんでした。
しかし、
- キャッシュはどこに保存されるのか
- どのような流れでデータを取得するのか
- なぜキャッシュが古いとエラーになるのか
- なぜDBを更新した後にキャッシュを再生成する必要があるのか
といった仕組みについては、ほとんど理解できていませんでした。
調べてみると、キャッシュは単に「処理を速くする仕組み」ではなく、システムのパフォーマンスやデータの整合性を維持するために欠かせない重要な技術だということが分かりました。
この記事では、実際に業務で疑問に感じたことをきっかけに学んだ内容をもとに初心者向けにまとめていきます。
- キャッシュとは
- キャッシュの動作フロー
- TTLの役割
- キャッシュ関連用語
キャッシュとは
「一度取得・計算したデータを、より高速にアクセスできる場所に一時的に保存しておく仕組み」 のことです。
例えば、毎日使う参考書が本棚にあるとします。
勉強するたびに本棚まで取りに行くよりも、机の上に置いておけばすぐに開けますよね。
- 本棚 = データベース
- 机の上 = キャッシュ
キャッシュは、この「机の上」のように、よく使うものをすぐ取り出せる場所だと考えるとイメージしやすいです。
ただし、机の上の本が古い版のままだと、最新の情報を見ることはできません。
キャッシュも同じで、保存されているデータが古くなると、実際のデータベースとは異なる情報を返してしまうことがあります。
そのため、TTL（有効期限）を設定したり、データ更新時にキャッシュを削除・再生成したりして、常に適切な状態を保つ仕組みが必要になります。
なぜキャッシュが必要なのか？
主な理由は次の 3つ です。
1. データの読み込み・処理速度を劇的に上げるため
データベースや外部APIなどの元データは、取得するまでに時間がかかります。
よく使うデータをキャッシュに保存しておけば、次回からはすぐに取り出せるため、ページの表示や処理が速くなります。
2. 処理負荷（サーバーやDBの負荷）を減らすため
同じデータを毎回データベースから取得すると、その分サーバーやDBに負荷がかかります。
キャッシュを利用すれば、一度取得したデータを使い回せるため、データベースへのアクセス回数を減らし、システム全体の負荷を軽減できます。
3. ネットワーク通信量・コストを削減するため
ブラウザやCDNでは画像やCSSなどをキャッシュすることで、毎回ダウンロードする必要がなくなり、通信量を削減できます。
主なキャッシュの種類（身近な例）
| 種類 | 保存場所 | 用途 |
|---|---|---|
| ブラウザキャッシュ | ユーザーのPC・スマホ | Webサイトの画像やCSSなどを保存 |
| Web API / DBキャッシュ | サーバー側（Redisなど） | DB検索結果を保存しレスポンスを高速化 |
| CPUキャッシュ | CPU内部（L1/L2/L3） | CPU処理を高速化 |
データが更新された場合に「キャッシュ側の古いデータ」が残ってしまう問題が発生するため、保持期間（TTL）を設定したり、更新時にキャッシュを破棄（インバリデーション）する設計が必要です。
キャッシュの動作フロー
[ Client / User ]
│
① Request
│
▼
┌──────────────┐ ② HIT ┌─────────────────┐
│ Cache Server │ ─────────► │ Return Data │ ──► ⑤ Response
│ (e.g. Redis) │ └─────────────────┘
└──────────────┘
│
② MISS
│
▼
┌──────────────┐ ┌─────────────────┐
│ Database │ ─────────► │ ③ Cache Save │
└──────────────┘ └─────────────────┘
│
▼
④ Return Data ──► ⑤ Responseユーザーやアプリケーションからデータ要求（Request）があった際、システムは以下のステップで動作します。
1. リクエスト（Request）
クライアント（Webブラウザやアプリ）が「データをちょうだい」とサーバーに要求を送ります。
2. キャッシュの確認（Cache Hit / Cache Miss）
最初にデータベースではなく、手前にあるキャッシュにデータが存在するかを確認します。
- Cache Hit（キャッシュヒット）
- 状態: キャッシュ内に目的のデータがあった場合。
- 動作: DBまで見に行かず、キャッシュから即座にデータを取得して返します（Hit → キャッシュ返す）。
- Cache Miss（キャッシュミス）
- 状態: キャッシュ内に目的のデータがなかった（または有効期限が切れていた）場合。
- 動作: キャッシュからデータを返せないため、次の処理（DBアクセス）へ進みます。
3. DB問い合わせ & 4. キャッシュへの保存
Cache Miss が起きた場合のみ、以下のリカバリー処理を行います。
- DB問い合わせ（Miss → DB）
- データベース（DB）へアクセスして最新データを検索・取得します。
- キャッシュ保存（DB → Cache保存）
- 取得したデータを「次回以降リクエストが来たときのため」に、TTLをセットしてキャッシュへ書き込みます。
次回からはどうなる？
- 1回目のアクセス（Cache Miss）
Request➔Cache Miss➔DB検索➔Cache保存➔Response- ※初回はDBまで行くため少し時間がかかります。
- 2回目以降のアクセス（Cache Hit）
Request➔Cache Hit➔Response- ※2回目以降はCacheだけで完結するため、爆速になります！
5. レスポンス（Response）
最終的に取得できたデータをクライアントへ返します。
TTL（Time To Live）とは？
TTL（Time To Live）とは、「キャッシュされたデータが自動で破棄されるまでの有効期限（寿命）」のことです。
TTLのフロー
指定した時間（例: 30分）が過ぎたら、システムが自動的にキャッシュを破棄する方法です。
- 動作: 30分経過 ➔ キャッシュ消滅 ➔ 次のアクセスでCache Miss ➔ DBから最新取得して再生成
- メリット: 実装が圧倒的に楽。DB更新処理に手を入れる必要がない。
- デメリット: DBのデータが変更されてからTTLが切れるまでの間、古いデータが表示され続ける（データ不整合）。
TTLを設定しないとどうなる？
TTLを設定しないと、システムに以下のような問題が発生してしまいます。
1. データが古いまんまになる（データ不整合）
DB側のデータが更新されても、キャッシュに昔のデータが永遠に残り続けてしまいます。 TTLを設定しておけば、「最長でも30分後には必ずDBの最新データに更新される」という保証を作ることができます。
例：
DB価格：500円
↓
キャッシュ：450円
↓
画面：450円
2. メモリ（キャッシュストレージ）がパンクする
キャッシュを保存するメモリ（Redisなど）の容量は有限です。古いデータや一度しかアクセスされないデータをTTLで消していかないと、あっという間にメモリが一杯になってシステムがダウンしてしまいます。
データの性質によってTTLの長さ（30分、5分、1日など）を調整します。
- 短いTTL（数秒〜数分）: リアルタイム性が大事なデータ（ニュースの最新記事一覧、商品の在庫数など）
- 長いTTL（数時間〜数日）: めったに更新されないデータ（都道府県マスター、ユーザーのプロフィール基本情報など）
「古いデータが表示されても許容できる時間」 を基準にTTLの長さを設定するのが一般的な設計手法です！
その他のキャッシュの代表的な更新パターン
TTLの他にもキャッシュを更新する方法です。
手動削除（管理者によるマニュアル削除）
管理者が必要に応じてキャッシュを削除する方法です。緊急時や障害対応などで利用されます。
DB更新時（プログラムによる即時削除・書き換え）
データの追加・更新・削除が発生した瞬間に、プログラムが連動してキャッシュも削除・更新する方法です。
主なやり方は以下の2種類があります。
- Cache Eviction（キャッシュ破棄）
- DB更新時に既存のキャッシュを消すだけにする。
- 次回アクセス時にCache Missとなり、最新データで再生成される。
- Write-Through（書き込み同期）
- DB更新と同時に、新しいデータをそのままキャッシュにも書き込む。
キャッシュ関連用語一覧
キャッシュ関連の用語をまとめました。
いきなりWarmUPなど出てきますが、ご参考までにどうぞ。
| 用語 | 意味 | 現場での使われ方・会話例 |
| Cache | 一時保存 | 「重い処理だからキャッシュ入れようか」 |
| Cache Hit | キャッシュから取得（高速） | 「Hit率90%超えてるからDB負荷かなり下がってるね」 |
| Cache Miss | DBから取得（低速） | 「初回リクエストはCache Missするから遅く見えるね」 |
| TTL | キャッシュの有効期限 | 「このデータのTTL、5分と1時間どっちにする？」 |
| Invalidate | キャッシュを無効化（削除）すること | 「商品情報を更新したら、該当のキャッシュをInvalidate（インバリデート）して」 |
| Refresh | キャッシュを最新に更新すること | 「TTLが切れる前にバックグラウンドでRefreshしておこう」 |
| Warm Up | あらかじめキャッシュを作っておくこと | 「明日のセール開始前に、トップページのデータをWarm Up（ウォームアップ）しておいて」 |
| Redis | 代表的なインメモリキャッシュサーバー | 「セッション管理とAPIのキャッシュにRedis使おう」 |
| Memcached | 単純構造で超高速なメモリ型キャッシュ | 「複雑な機能いらないからシンプルにMemcachedでいこう」 |
| CDN Cache | エッジサーバーでの静的ファイルキャッシュ | 「画像やJSはCloudflare / CloudFront（CDNでキャッシュしよう」 |
終わりに
今回は、他のチームのテストを行う中で発生したキャッシュの問題をきっかけに、「コメントや作業内容をもっと理解できるようになりたい」と思い、初心者向けにキャッシュの仕組みをまとめてみました。
実務では「キャッシュを生成してください」「キャッシュを削除してください」といったやり取りが当たり前のように行われますが、その意味を理解しているかどうかで、システム全体の見え方が大きく変わると感じました。
まだ学ぶことはたくさんありますが、いつかはキャッシュの生成や無効化（Invalidate）といった運用・実装にも携われるようになりたいと思っています。
同じように「キャッシュって結局何？」と疑問を持った方の参考になれば嬉しいです。
