Redis と Memcached の使い分け ベストプラクティス

作成日: 2026-10-29

---

目次

1. 結論（TL;DR）
2. 機能比較
3. Memcached を選ぶべきケース
4. Redis を選ぶべきケース
5. 判断フローチャート
6. 運用上のベストプラクティス
7. ライセンスとフォーク事情（2026年時点）
8. マネージドサービス対応表（主要クラウド）
9. よくあるアンチパターン
10. まとめ

---

1. 結論（TL;DR）

原則: Memcached は「純粋なキャッシュ」、Redis は「インメモリのデータストア（キャッシュにも使える）」。 キャッシュ以外の用途が1つでもあるなら Redis に寄せて、ミドルウェアの種類を増やさないのが運用上の正解。

---

2. 機能比較

---

3. Memcached を選ぶべきケース

• 用途が純粋な read-through / look-aside キャッシュだけ（DBクエリ結果、レンダリング済みHTML断片など）
• キャッシュが消えても困らない（ソース・オブ・トゥルースは常にDB）
• 1ノードで多コアを使い切って高スループットを出したい（マルチスレッドの恩恵）
• 値が小〜中サイズで均一、大量のキーを省メモリで持ちたい
• 既存システム（例: 大規模 PHP/Rails 資産）が Memcached 前提で、移行コストに見合うメリットがない
• 運用をとにかくシンプルにしたい（設定項目がほぼない）

4. Redis を選ぶべきケース

• データ構造を活かす処理
  • ランキング / リーダーボード → Sorted Set
  • レートリミット → INCR + EXPIRE、またはスライディングウィンドウを Sorted Set で
  • セッションストア → Hash + TTL
  • ジョブキュー / イベント処理 → List / Streams（コンシューマーグループ）
  • ユニークカウント → HyperLogLog
  • 位置情報検索 → Geo
• キャッシュが消えると困る（ウォームアップに時間がかかる、セッションが飛ぶと UX が壊れる）→ 永続化＋レプリカ
• 分散ロック（SET key val NX PX ttl）
• Pub/Sub やリアルタイム通知
• アトミックな複合操作（Lua / Functions）
• ベクター検索・JSON 検索（Redis 8 以降はコアに統合）
• フェイルオーバーを含む高可用性が必要

---

5. 判断フローチャート

キャッシュ以外の用途（キュー/ロック/ランキング/セッション/PubSub）がある？
 ├─ Yes → Redis（Valkey）
 └─ No
     │
     キャッシュが消えたときの影響は許容できる？
      ├─ No → Redis（永続化 + レプリカ）
      └─ Yes
          │
          値は単純な文字列/シリアライズ済みオブジェクトだけ？
           ├─ No（部分更新したい・フィールド単位で読みたい）→ Redis（Hash など）
           └─ Yes
               │
               超高スループット & 多コア活用 & 運用最小化が最優先？
                ├─ Yes → Memcached
                └─ No  → どちらでも可（チームの習熟度・既存資産で決める。迷えば Redis）

---

6. 運用上のベストプラクティス

共通

• TTL を必ず設定する。無期限キーはメモリリークと同義。
• TTL にジッター（ランダム幅）を入れる。同時失効による DB への雪崩（cache stampede）を防ぐ。
• キャッシュスタンピード対策: ロック付き再生成、早期再計算（probabilistic early expiration）、stale-while-revalidate。
• キー命名規則を統一: app:entity:id:field（例: shop:user:123:profile）。バージョンを含めると一斉無効化が楽（v2:user:123）。
• シリアライズ形式は言語非依存なもの（JSON / MessagePack / Protobuf）を選ぶ。
• ヒット率・eviction 数・メモリ使用率・レイテンシを必ず監視する。
• キャッシュはソース・オブ・トゥルースにしない（Redis を DB として使う場合は別設計として明示的に扱う）。

Redis 固有

• maxmemory と maxmemory-policy を必ず設定
  • 純キャッシュ: allkeys-lru または allkeys-lfu
  • キャッシュ＋重要データ混在: volatile-lru（TTL 付きのみ追い出し）※ただし用途ごとにインスタンス分離が望ましい
• O(N) コマンドを本番で使わない: KEYS * → SCAN、巨大 HGETALL / SMEMBERS / LRANGE 0 -1 に注意。
• ビッグキー・ホットキーを避ける（redis-cli --bigkeys / --hotkeys で定期検査）。シングルスレッドなので1コマンドの遅延が全体に波及する。
• キャッシュ用途とキュー/セッション用途はインスタンスを分ける（eviction ポリシーと永続化要件が異なるため）。
• 永続化: キャッシュ専用なら RDB のみ or 無効化、データ用途なら AOF（everysec）＋RDB。
• パイプライン / MGET / MSET で RTT を削減。
• Cluster 利用時はマルチキー操作に hash tag（{user:123}:cart）を使う。
• bind / protected-mode / ACL / TLS を設定し、インターネットに直接晒さない。

Memcached 固有

• -m（メモリ上限）と -t（スレッド数＝コア数程度）を調整。
• Slab のクラス偏り（slab calcification）に注意: 値サイズ分布が変わると特定 slab だけ溢れる。1.4.25 以降の slab_reassign / slab_automove を有効化。
• ノード追加/削除時はコンシステントハッシュ（ketama）を使い、再配置によるミスを最小化。
• 1MB 超の値は分割するか、そもそもキャッシュ対象を見直す。
• 認証は SASL か、ネットワークレベルで隔離（UDP は無効化推奨：反射攻撃対策 -U 0）。

---

7. ライセンスとフォーク事情（2026年時点）

• 2024年3月、Redis 7.4 以降が BSD から RSALv2 / SSPLv1 のデュアルライセンスへ変更。
• これを受けて Linux Foundation 主導で Valkey（Redis 7.2.4 からのフォーク、BSD-3-Clause）が誕生。AWS・Google Cloud・Oracle 等が支援。
• 2025年の Redis 8 で AGPLv3 が選択肢に追加され、再び OSI 承認ライセンスに。
• Memcached は BSD のまま。

実務上の指針

• 社内で未改変のまま使うだけなら、どのライセンスでもほぼ制約はない。
• 影響が出るのは「Redis 互換サービスを外部提供する」「製品に組み込んで配布する」「社内ポリシーで AGPL / 非 OSI を禁止している」場合。
• その場合は Valkey（Redis 7.2 互換＋独自拡張、ElastiCache / Memorystore でも提供）を検討。
• マネージドサービス利用時は、提供されているエンジン（Redis OSS / Valkey / Memcached）とバージョンを確認する。

---

8. マネージドサービス対応表（主要クラウド）

※ 提供状況・名称は変わりやすいので、採用時に各クラウドの最新ドキュメントで確認すること。

---

9. よくあるアンチパターン

---

10. まとめ

1. デフォルトは Redis（ライセンス要件次第で Valkey）。機能・エコシステム・マネージド対応の幅が広い。
2. Memcached は「シンプルな大規模キャッシュ」に特化して強い。用途が明確に限定されるなら今でも合理的な選択。
3. どちらを使うにせよ TTL・eviction 設定・監視・スタンピード対策が品質を決める。
4. 用途（キャッシュ / 永続データ / キュー）が違うものは インスタンスを分ける。