サイトアイコンmaita tomoya dev io

Redis vs Memcached 徹底比較

databases

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の設計思想は「シンプルさ」である。キーバリューストアとしての基本機能に特化し、余計な機能を持たないことで、高いパフォーマンスと安定性を実現している。

主要なマイルストーン

RedisMemcached
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(完全オープンソース)-

技術的比較

データ構造

データ構造RedisMemcached
String(文字列)対応(最大512MB)対応(最大1MB)
List(リスト)対応非対応
Set(集合)対応非対応
Sorted Set(ソート済み集合)対応非対応
Hash(ハッシュ)対応非対応
Bitmap対応非対応
HyperLogLog対応非対応
Stream対応非対応
Geospatial対応非対応
JSON対応(RedisJSON)非対応

永続化

項目RedisMemcached
データ永続化RDB(定期スナップショット)+ AOF(追記ログ)なし(再起動でデータ消失)
RDB設定した間隔でメモリのスナップショットを保存-
AOF書き込み操作をログとして記録-
ハイブリッドRDB + AOFの併用が可能-

レプリケーションと高可用性

項目RedisMemcached
レプリケーションマスター-レプリカ構成非対応(クライアント側で分散)
自動フェイルオーバーRedis Sentinel非対応
クラスタリングRedis Cluster(自動シャーディング)Consistent Hashing(クライアント側)
Global分散Redis Enterprise Active-Active非対応

メモリ管理

項目RedisMemcached
メモリアロケータjemalloc(デフォルト)slab allocator
エビクション複数ポリシー(LRU、LFU、TTL等)LRUのみ
メモリフラグメンテーションjemalloc利用時は低いslab allocatorで軽減
最大メモリ設定maxmemory-m オプション
メモリ効率データ構造のオーバーヘッドありキーバリューとして効率的

Pub/Subとメッセージング

機能RedisMemcached
Pub/Sub対応(チャンネルベース)非対応
Streams対応(コンシューマグループ)非対応
パターンサブスクリプション対応(パターンマッチ)非対応

ユースケース別比較

Redisのユースケース

ユースケース使用するデータ構造説明
セッション管理String / Hashユーザーセッションの高速読み書き
キャッシュStringAPIレスポンス、DBクエリ結果のキャッシュ
ランキングSorted Setゲームのリーダーボード
レート制限String + INCRAPI呼び出し回数の制限
メッセージキューList / Stream軽量なジョブキュー
リアルタイム通知Pub/Subチャット、通知システム
カウンターString + INCRページビュー、いいね数
地理空間検索Geospatial近くの店舗検索
分散ロックString + NXマイクロサービス間の排他制御
タイムラインList / Sorted SetSNSのフィード

Memcachedのユースケース

ユースケース説明
DBクエリキャッシュ頻繁に実行されるSELECTの結果をキャッシュ
HTMLフラグメントキャッシュレンダリング済みHTMLの断片をキャッシュ
セッションストアシンプルなセッションデータの格納
APIレスポンスキャッシュ外部APIのレスポンスをキャッシュ
オブジェクトキャッシュシリアライズしたオブジェクトの格納

パフォーマンス比較

スループット(概算)

操作RedisMemcached
GET(単純な読み取り)100,000+ ops/s100,000+ ops/s
SET(単純な書き込み)100,000+ ops/s100,000+ ops/s
MGET(バルク読み取り)50,000+ ops/s80,000+ ops/s
MSET(バルク書き込み)50,000+ ops/s80,000+ ops/s

注: Memcachedはマルチスレッドのため、マルチコア環境ではバルク操作で優位になることがある。Redis 7.0以降はI/Oスレッドの改善により差が縮小している。

レイテンシ

操作RedisMemcached
平均レイテンシ<1ms<1ms
p99レイテンシ<2ms<1ms
永続化有効時1-5ms(AOF fsync)N/A

メモリ使用量

1000万のキーバリューペア(100バイトの値)を格納した場合の概算:

項目RedisMemcached
実データ量約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セッション、キャッシュ

クラウドサービスでの対応

クラウドRedisMemcached
AWSElastiCache for Redis, MemoryDBElastiCache for Memcached
GCPMemorystore for RedisMemorystore for Memcached
AzureAzure Cache for Redis非対応
その他Redis Cloud, Upstash-

Valkeyについて

2024年にRedisがライセンスを変更したことを受け、Linux Foundation傘下でValkeyプロジェクトが立ち上がった。ValkeyはRedis 7.2をベースにフォークされ、BSD Licenseで提供される。AWS、Google Cloud、Oracle等の大手クラウドプロバイダーがValkeyを支持している。

項目RedisValkey
ライセンスRSALv2 / SSPLv1BSD 3-Clause
互換性-Redis 7.2互換
支持企業Redis LabsAWS, Google, Oracle等
方向性Redis Labs主導の開発コミュニティ主導

選択の判断フロー

キャッシュ以外の機能が必要?
|
+-- はい → Redis
|   |
|   +-- ライセンスが懸念?
|       +-- はい → Valkey
|       +-- いいえ → Redis
|
+-- いいえ(純粋なキャッシュのみ)
    |
    +-- メモリ効率が最重要?
    |   +-- はい → Memcached
    |   +-- いいえ → Redis(キャッシュとしても優秀)
    |
    +-- 将来的に機能拡張の可能性?
        +-- はい → Redis
        +-- いいえ → Memcached

まとめ

RedisとMemcachedは、どちらもインメモリデータストアとして優れているが、その設計思想と機能セットは大きく異なる。

Redisを選ぶべき場合: キャッシュだけでなく、メッセージング、ランキング、セッション管理、リアルタイム機能など、多様なユースケースに対応したい場合。事実上の業界標準であり、多くの場合Redisを選んでおけば間違いない。

Memcachedを選ぶべき場合: 純粋なキャッシュとしてのみ使用し、メモリ効率とシンプルさを最重視する場合。Facebookのような超大規模なキャッシュ層では、Memcachedのシンプルさが大きなメリットとなる。

2026年現在、新規プロジェクトではRedis(またはValkey)を選択するケースが圧倒的に多い。Memcachedは既存システムでの継続利用や、特殊な要件がある場合に選択される。


参考リンク