Redis vs Memcached 徹底比較
概要と歴史
キャッシュとは
キャッシュ(Cache)とは、頻繁にアクセスされるデータを高速なストレージ(通常はメモリ)に一時的に保存し、アクセス速度を向上させる技術である。Webアプリケーションでは、データベースへのクエリ結果やAPIレスポンスをキャッシュすることで、レスポンスタイムを大幅に短縮できる。
Redisとは
Redis(Remote Dictionary Server)は、2009年にSalvatore Sanfilippoが開発したオープンソースのインメモリデータストアである。単純なキャッシュを超え、データ構造サーバー、メッセージブローカー、ストリーム処理エンジンとしても機能する多機能なツールだ。
2024年にRedis Labsがライセンスを変更し(Redis Source Available License v2/Server Side Public License v1)、純粋なオープンソースではなくなった。これに対し、コミュニティからValkeyというフォークが生まれている。
Memcachedとは
Memcachedは、2003年にBrad Fitzpatrickが開発した高性能な分散メモリキャッシュシステムである。LiveJournal(ブログプラットフォーム)のデータベース負荷を軽減するために作られた。
Memcachedの設計思想は「シンプルさ」である。キーバリューストアとしての基本機能に特化し、余計な機能を持たないことで、高いパフォーマンスと安定性を実現している。
主要なマイルストーン
| 年 | Redis | Memcached |
|---|
| 2003年 | - | Memcached v1.0リリース |
| 2009年 | Redis v1.0リリース | - |
| 2012年 | v2.6(Luaスクリプト) | - |
| 2014年 | Redis Clusterリリース(v3.0) | - |
| 2015年 | v3.2(GEO機能) | - |
| 2018年 | v5.0(Redis Streams) | - |
| 2020年 | v6.0(ACL、クライアントキャッシュ) | - |
| 2022年 | v7.0(Functions、パフォーマンス改善) | v1.6(TLS、認証対応) |
| 2024年 | ライセンス変更、Valkeyフォーク | 安定運用継続 |
強みと弱み
Redisの強みと弱み
| 観点 | 強み | 弱み |
|---|
| データ構造 | String、List、Set、Hash、Sorted Set等 | メモリ使用量がMemcachedより多い |
| 永続化 | RDB(スナップショット)、AOF(追記ログ) | 永続化はパフォーマンスに影響 |
| Pub/Sub | メッセージブローカーとして機能 | 大規模では専用MQ(Kafka等)が必要 |
| Streams | ログ構造のストリームデータ | 複雑な設定が必要 |
| Lua Scripting | サーバーサイドでのアトミック処理 | Luaの学習が必要 |
| Cluster | シャーディングによるスケールアウト | クラスター設計の複雑さ |
| Sentinel | 高可用性のための自動フェイルオーバー | 追加の運用コンポーネント |
| トランザクション | MULTI/EXEC、楽観的ロック(WATCH) | 本格的なトランザクションではない |
| ライセンス | 2024年にライセンス変更 | 商用利用で制約の可能性 |
Memcachedの強みと弱み
| 観点 | 強み | 弱み |
|---|
| シンプルさ | 設計がシンプルで理解しやすい | 機能が限定的 |
| パフォーマンス | 純粋なキャッシュとして最高速 | 複雑なデータ操作は不可 |
| メモリ効率 | メタデータのオーバーヘッドが小さい | 大きな値の格納に制限(1MB) |
| マルチスレッド | マルチスレッドで水平スケール | マルチスレッドの複雑さ |
| 運用 | 設定項目が少なく運用が容易 | 監視・管理ツールが限定的 |
| 安定性 | 枯れた技術で非常に安定 | 新機能の追加が少ない |
| ライセンス | BSD License(完全オープンソース) | - |
技術的比較
データ構造
| データ構造 | Redis | Memcached |
|---|
| String(文字列) | 対応(最大512MB) | 対応(最大1MB) |
| List(リスト) | 対応 | 非対応 |
| Set(集合) | 対応 | 非対応 |
| Sorted Set(ソート済み集合) | 対応 | 非対応 |
| Hash(ハッシュ) | 対応 | 非対応 |
| Bitmap | 対応 | 非対応 |
| HyperLogLog | 対応 | 非対応 |
| Stream | 対応 | 非対応 |
| Geospatial | 対応 | 非対応 |
| JSON | 対応(RedisJSON) | 非対応 |
永続化
| 項目 | Redis | Memcached |
|---|
| データ永続化 | RDB(定期スナップショット)+ AOF(追記ログ) | なし(再起動でデータ消失) |
| RDB | 設定した間隔でメモリのスナップショットを保存 | - |
| AOF | 書き込み操作をログとして記録 | - |
| ハイブリッド | RDB + AOFの併用が可能 | - |
レプリケーションと高可用性
| 項目 | Redis | Memcached |
|---|
| レプリケーション | マスター-レプリカ構成 | 非対応(クライアント側で分散) |
| 自動フェイルオーバー | Redis Sentinel | 非対応 |
| クラスタリング | Redis Cluster(自動シャーディング) | Consistent Hashing(クライアント側) |
| Global分散 | Redis Enterprise Active-Active | 非対応 |
メモリ管理
| 項目 | Redis | Memcached |
|---|
| メモリアロケータ | jemalloc(デフォルト) | slab allocator |
| エビクション | 複数ポリシー(LRU、LFU、TTL等) | LRUのみ |
| メモリフラグメンテーション | jemalloc利用時は低い | slab allocatorで軽減 |
| 最大メモリ設定 | maxmemory | -m オプション |
| メモリ効率 | データ構造のオーバーヘッドあり | キーバリューとして効率的 |
Pub/Subとメッセージング
| 機能 | Redis | Memcached |
|---|
| Pub/Sub | 対応(チャンネルベース) | 非対応 |
| Streams | 対応(コンシューマグループ) | 非対応 |
| パターンサブスクリプション | 対応(パターンマッチ) | 非対応 |
ユースケース別比較
Redisのユースケース
| ユースケース | 使用するデータ構造 | 説明 |
|---|
| セッション管理 | String / Hash | ユーザーセッションの高速読み書き |
| キャッシュ | String | APIレスポンス、DBクエリ結果のキャッシュ |
| ランキング | Sorted Set | ゲームのリーダーボード |
| レート制限 | String + INCR | API呼び出し回数の制限 |
| メッセージキュー | List / Stream | 軽量なジョブキュー |
| リアルタイム通知 | Pub/Sub | チャット、通知システム |
| カウンター | String + INCR | ページビュー、いいね数 |
| 地理空間検索 | Geospatial | 近くの店舗検索 |
| 分散ロック | String + NX | マイクロサービス間の排他制御 |
| タイムライン | List / Sorted Set | SNSのフィード |
Memcachedのユースケース
| ユースケース | 説明 |
|---|
| DBクエリキャッシュ | 頻繁に実行されるSELECTの結果をキャッシュ |
| HTMLフラグメントキャッシュ | レンダリング済みHTMLの断片をキャッシュ |
| セッションストア | シンプルなセッションデータの格納 |
| APIレスポンスキャッシュ | 外部APIのレスポンスをキャッシュ |
| オブジェクトキャッシュ | シリアライズしたオブジェクトの格納 |
パフォーマンス比較
スループット(概算)
| 操作 | Redis | Memcached |
|---|
| GET(単純な読み取り) | 100,000+ ops/s | 100,000+ ops/s |
| SET(単純な書き込み) | 100,000+ ops/s | 100,000+ ops/s |
| MGET(バルク読み取り) | 50,000+ ops/s | 80,000+ ops/s |
| MSET(バルク書き込み) | 50,000+ ops/s | 80,000+ ops/s |
注: Memcachedはマルチスレッドのため、マルチコア環境ではバルク操作で優位になることがある。Redis 7.0以降はI/Oスレッドの改善により差が縮小している。
レイテンシ
| 操作 | Redis | Memcached |
|---|
| 平均レイテンシ | <1ms | <1ms |
| p99レイテンシ | <2ms | <1ms |
| 永続化有効時 | 1-5ms(AOF fsync) | N/A |
メモリ使用量
1000万のキーバリューペア(100バイトの値)を格納した場合の概算:
| 項目 | Redis | Memcached |
|---|
| 実データ量 | 約1GB | 約1GB |
| メタデータオーバーヘッド | 約0.5-1GB | 約0.2-0.3GB |
| 合計メモリ使用量 | 約1.5-2GB | 約1.2-1.3GB |
Memcachedの方がメモリ効率が良い。Redisはデータ構造のメタデータ(ポインタ、型情報等)が追加のメモリを消費する。
適しているケース
Redisを選ぶべき場合
- キャッシュ以外の機能も必要: Pub/Sub、ランキング、キューなど
- データの永続化が必要: キャッシュデータの消失を防ぎたい
- 複雑なデータ構造: リスト、セット、ソート済みセットなど
- 高可用性: Redis Sentinel/Clusterによる自動フェイルオーバー
- リアルタイム機能: Pub/SubやStreamsによるリアルタイム通信
Memcachedを選ぶべき場合
- 純粋なキャッシュのみ: 追加機能は不要
- メモリ効率が最重要: 大量のキャッシュデータ
- マルチスレッド性能: CPUコアを最大限活用したい
- シンプルな運用: 設定・監視を最小化したい
- 完全なオープンソース: ライセンスの制約を避けたい
採用企業の実例
Redis
| 企業 | 用途 |
|---|
| Twitter/X | タイムライン、セッション |
| GitHub | キャッシュ、ジョブキュー |
| Stack Overflow | キャッシュ |
| Pinterest | フィード、推薦システム |
| Snapchat | セッション管理 |
| Discord | メッセージキュー |
Memcached
| 企業 | 用途 |
|---|
| Facebook/Meta | 世界最大のMemcachedデプロイ |
| Wikipedia | ページキャッシュ |
| YouTube | メタデータキャッシュ |
| Reddit | オブジェクトキャッシュ |
| Slack | セッション、キャッシュ |
クラウドサービスでの対応
| クラウド | Redis | Memcached |
|---|
| AWS | ElastiCache for Redis, MemoryDB | ElastiCache for Memcached |
| GCP | Memorystore for Redis | Memorystore for Memcached |
| Azure | Azure Cache for Redis | 非対応 |
| その他 | Redis Cloud, Upstash | - |
Valkeyについて
2024年にRedisがライセンスを変更したことを受け、Linux Foundation傘下でValkeyプロジェクトが立ち上がった。ValkeyはRedis 7.2をベースにフォークされ、BSD Licenseで提供される。AWS、Google Cloud、Oracle等の大手クラウドプロバイダーがValkeyを支持している。
| 項目 | Redis | Valkey |
|---|
| ライセンス | RSALv2 / SSPLv1 | BSD 3-Clause |
| 互換性 | - | Redis 7.2互換 |
| 支持企業 | Redis Labs | AWS, Google, Oracle等 |
| 方向性 | Redis Labs主導の開発 | コミュニティ主導 |
選択の判断フロー
キャッシュ以外の機能が必要?
|
+-- はい → Redis
| |
| +-- ライセンスが懸念?
| +-- はい → Valkey
| +-- いいえ → Redis
|
+-- いいえ(純粋なキャッシュのみ)
|
+-- メモリ効率が最重要?
| +-- はい → Memcached
| +-- いいえ → Redis(キャッシュとしても優秀)
|
+-- 将来的に機能拡張の可能性?
+-- はい → Redis
+-- いいえ → Memcached
まとめ
RedisとMemcachedは、どちらもインメモリデータストアとして優れているが、その設計思想と機能セットは大きく異なる。
Redisを選ぶべき場合: キャッシュだけでなく、メッセージング、ランキング、セッション管理、リアルタイム機能など、多様なユースケースに対応したい場合。事実上の業界標準であり、多くの場合Redisを選んでおけば間違いない。
Memcachedを選ぶべき場合: 純粋なキャッシュとしてのみ使用し、メモリ効率とシンプルさを最重視する場合。Facebookのような超大規模なキャッシュ層では、Memcachedのシンプルさが大きなメリットとなる。
2026年現在、新規プロジェクトではRedis(またはValkey)を選択するケースが圧倒的に多い。Memcachedは既存システムでの継続利用や、特殊な要件がある場合に選択される。
参考リンク