キャッシュ系 — Redis / Memcached（速さの一時置き場）
📖 このページのゴール：アプリが「速い」理由のひとつ、キャッシュ（速さのための一時置き場） の正体をつかみます。DBの手前に「よく使う答え」を置いて速くするしくみ、代表の Redis / Memcached、そして 古くなる・個人データを共有キャッシュに置かない といった落とし穴までを、たとえ話で理解します。 ← 目次・はじめにへもどる
🏃 ひとことのたとえ：机の上の付箋・手元の控え
よく使う電話番号を、いちいち分厚い住所録（＝奥の倉庫）で探すのは面倒です。だから机に 付箋 で貼っておく。すると次からは、付箋を見るだけで一瞬で済みます。
キャッシュ（cache ＝ 控え）も、これとまったく同じ発想です。
毎回 奥の倉庫（＝DB）まで取りに行かず、「手元の控え」を見て速くする工夫。
- 🗄 倉庫（DB）…正式な記録がぜんぶ揃っている、奥の本棚。正確だけど、毎回行くと遠い。
- 🏃 キャッシュ（控え）…机の上の付箋。よく使うものだけ、手元に置いた写し。すぐ見られて速い。
ポイントは、付箋はあくまで「写し」だということ。本物（倉庫の中身）が変わっても、付箋は書き換えない限り 古いまま です。ここが、便利さと落とし穴の両方の源になります。
🧩 何者？（しくみ）
キャッシュは、DBの「手前」に置く一時的な置き場です。図にすると、こんな並びになります。
① まず手元を見る
アプリ ───────────────▶ 🏃 キャッシュ（手元の控え・速い）
│ │
│ ② 控えに無ければ… │（あれば即返す＝ヒット）
│ ▼
└────────────────────▶ 🗄 DB（奥の倉庫・正本）
③ 倉庫から取り、ついでに控えにも書いておく
| 用語 | やさしい言い換え |
|---|---|
| キャッシュヒット | 手元の控えに「あった！」（速い） |
| キャッシュミス | 控えに無くて、奥の倉庫まで取りに行く（遅い） |
なぜ速いのかというと、控えを「メモリ（RAM）」の上に置くからです。メモリは、ディスク（倉庫の本棚）より桁違いに高速。だから付箋を見る感覚で一瞬で返せます。
うれしいことが2つ同時に起きます。
- ⚡ 高速化…2回目以降が、待たずにパッと返る。
- 🪶 DB負荷軽減…毎回 倉庫に行かなくなるので、DBがラクになり、混雑しにくくなる。
キャッシュ無し： アプリ → DB → アプリ → DB → アプリ → DB …（毎回 遠出）
キャッシュ有り： アプリ → 控え → 控え → 控え → （たまに）DB …（ほぼ手元で完結）
🛠 代表サービス（実名）
控えを置くための「専用の道具」が、いくつかあります。代表は2つです。
| 道具 | ひとことで | 得意・特徴 |
|---|---|---|
| 🔴 Redis（レディス） | 高機能なキーバリュー置き場 | KV だけでなく、リスト・集合・カウンタなど多機能。永続化（電源が消えても残す設定）や pub/sub（みんなに通知を配る）も。今いちばん人気 |
| ⚪ Memcached（メムキャッシュト） | シンプルなキーバリュー置き場 | 機能をしぼった、純粋な「速い控え」。とにかく軽くて素直。永続化などはしない |
🟢 KV（キーバリュー） ＝「名札（キー）」で「中身（値）」を出し入れする、いちばん素朴な形。 例：
user:42:nameという名札 →"たろう"という中身。付箋に「名前→たろう」と書くのと同じ。
迷ったら Redis で大丈夫です。Memcached は「もっと単純でいい」という割り切った場面で選ばれます。
マネージド（自分で運用しなくていい版）
Redis 等を自分のサーバーに立てるのは手間（姉妹編の「自前(オンプレ)」と同じ苦労）。マネージドを使うと、その手間をクラウドに任せられます。
| サービス | ひとこと |
|---|---|
| ElastiCache（AWS） | AWS の Redis / Memcached マネージド。AWS で組むなら定番 |
| Upstash | サーバーレスRedis。使った分だけ課金・運用ゼロ。個人/スタートアップに人気 |
| Vercel KV | Vercel から手軽に使えるKV（中身はサーバーレスRedis系） |
🔧 運用/メンテ：自前で Redis を立てると、メモリ管理・再起動・冗長化を自分で見る必要があります。最初は Upstash のようなサーバーレス から始めると、ほぼ何もせずに「控え」を持てて安全です。
⚠️ 落とし穴（ここが大事）
キャッシュは速くて便利ですが、初心者がつまずく点がはっきりしています。
① stale（ステイル＝古いデータ）
🟢 控えは、本物が変わっても勝手には新しくなりません。
付箋に書いた電話番号は、相手が引っ越して番号が変わっても、付箋は古い番号のまま。
だから「もう直したはずなのに、古い表示が出続ける」ことが起きます。これはバグではなく、控えが残っているだけのことが多い、という感覚を持っておきましょう。
② TTL（ティーティーエル＝有効期限）
🟢 古さ対策の基本が TTL（Time To Live ＝ 控えの寿命） です。
「この控えは○分（○秒）たったら自動で捨てる」と、最初に期限を決めておく。
たとえば「ニュース一覧を 60秒だけ控える」なら、最大60秒だけ古いかもしれないが、ほぼ最新を保てます。「どれくらい古くても許せるか」を、分・秒で決めるのがコツです。
③ キャッシュ無効化（invalidation）はむずかしい
🔧 「変わった瞬間に、ちょうどその控えだけを正しく捨てる」のは、実はとても難しい問題です（古いプログラマの格言で「キャッシュ無効化は難問の一つ」と言われるほど）。初心者のうちは、まず TTL（期限で自動的に捨てる） から始めるのが安全・簡単です。
④ 個人データを共有キャッシュに置かない（最重要・事故）
🟢 これは「速さ」ではなく「安全」を壊す、いちばん怖い落とし穴です。
控えには、みんなで共有する控え（CDN・共有サーバーの棚）と、その人だけの控え（その人のブラウザの中）があります。みんなで使う共有の棚に、ある人だけの個人データを置いてしまうと、次に来た別の人にそれが見えてしまう のです。
🔑 合言葉：「みんな同じ＝共有OK」「人ごとに違う＝その人だけ」
これは姉妹教材 Twitterクローン入門 第9章「キャッシュ」 で、ホームタイムライン（人ごとに違う個人データ）を共有キャッシュに流して Aさんの画面がBさんに丸見え になる、という具体例で詳しく扱っています。あわせて読むと、なぜ「個人データは共有キャッシュ厳禁」なのかが腹落ちします。
🔑 いちばん大事な原則
┌───────────────────────────────────────────────┐
│ 真実の源（正本）は、いつも DB。 │
│ キャッシュは、消えても困らない「控え」。 │
└───────────────────────────────────────────────┘
キャッシュが全部消えても、もう一度DBから作り直せる——その状態を保つのが鉄則です。「これが無くなったら本当に困る」データを、キャッシュ“だけ”に置いてはいけません。
👍 向いている / 👎 向かない
| 例 | |
|---|---|
| 👍 向いている | ・読み（参照）が多いデータ（何度も同じものを見る） ・重いクエリの結果（計算やJOINが重く、毎回やると遅いもの） ・セッション（ログイン状態など、サッと出し入れしたい一時データ） |
| 👎 向かない | ・正本（マスター）にする（消えたら困るものを控えだけに置く） ・必ず最新が要るもの（残高・在庫の最終確定など、1秒の古さも許されないもの） |
🟢 ざっくり判定：「古くてもちょっとなら平気？ よく読まれる？」→ キャッシュ向き。 「消えたら困る／常に最新が絶対？」→ それは DB（正本）の仕事。
🏢 誰が使う？（ペルソナ一言）
| 立場 | キャッシュの出番 |
|---|---|
| 個人 / スタートアップ | 最初は無くても動く。重い所が出てきたら Upstash（サーバーレスRedis） をちょい足し |
| 中堅ベンチャー | ElastiCache(Redis) を本格導入。重いクエリ・セッションを逃がしてコスト最適化 |
| 大企業 | Redis を冗長構成で常用。マルチリージョンで「近い控え」を配り、DB負荷を恒常的に下げる |
ひとことで言うと、規模が出てきたら、いずれ全員お世話になるのがキャッシュです。最初から頑張る必要はありません。
📝 ことばメモ
- キャッシュ…奥の倉庫（DB）まで毎回行かずに済ませる「手元の控え」。メモリ上に置くので速い。
- Redis / Memcached…代表的なキャッシュの道具。Redis＝高機能、Memcached＝シンプル。
- KV（キーバリュー）…名札（キー）で中身（値）を出し入れする、いちばん素朴なデータの形。
- stale（ステイル）…古くなった控え。本物が変わっても控えは自動で新しくならない。
- TTL（有効期限）…控えを何分・何秒で捨てるかの寿命。古さ対策の基本。
- 無効化（invalidation）…古い控えを捨てる/新しくすること。正確にやるのは難しい。
🟢 ひとことで言うと
キャッシュは「机の上の付箋」。DBの手前に「よく使う答え」を一時的に置いて、速くしてDBもラクにするしくみです。道具は Redis（高機能）/ Memcached（シンプル）。ただし控えは 古くなる(stale) し、個人データを共有キャッシュに置くと他人に丸見え になる事故が起きます。だから——真実の源はいつもDB、キャッシュは消えてOKな控え。