Dev Study
← AWSサービスの内部原理 コース

97. MemcachedとValkey/Redisは速さの出し方が違う — マルチスレッドの単純KVとシングルスレッドのデータ構造サーバー

ElastiCacheがなぜ2系統のエンジンを提供するのか、「同じインメモリkey-valueストア」に見える2つが実は正反対の設計思想でできていることを、公式の選択基準と2つの証拠(リーダーボードとpub/sub)を図で追っていきます。

① 表面は同じ、中身は違う

インメモリKVストアsubmillisecondのkey参照
2エンジン共通の土台
Memcached単純KVストア
値は「文字列とオブジェクト」(databaseのような塊)
Valkey/Redisデータ構造サーバー
文字列+sets・sorted sets・lists・hashes・bitmaps・hyperloglog・geospatial
  • 公式原文「On the surface, the engines look similar. Each of them is an in-memory key-value store. However, in practice there are significant differences.」
  • Memcachedのデータ型は "Simple"、注記では「string, objects (like databases)」。Valkey/Redisは "Complex"、注記(3.2.x以降)では「string, sets, sorted sets, lists, hashes, bitmaps, hyperloglog, geospatial indexes」(2.8.x向け旧注記にgeospatialは含まれないが、現在サポートされるのは4.0.10以降のみ)
  • 「submillisecond」はuse-casesページ冒頭「ultrafast (submillisecond latency) … access to copies of data」より

どちらもkey-valueという入口は同じでも、Memcachedは「値=単純な塊」を出し入れするだけの店、Valkey/Redisは「値そのものが操作できる構造(集合・順序付き集合・ハッシュ…)」を持つ店。この一点がこのあとの全ての違いを生む。

② 公式の選択基準 — 仕事の形で決まる

Memcachedを選ぶ
Valkey/Redisを選ぶ
最もシンプルなモデルthe simplest model possible
複雑なデータ型sorted sets・hashes・bitmaps等
多コアの大ノードmultiple cores or threads
高可用性+自動フェイルオーバーレプリケーション
ノード増減で伸縮scale out and in
pub/sub同報メッセージング
オブジェクトをキャッシュcache objects
バックアップ/リストアスナップショット
  • Memcached側は公式4項目そのまま:「the simplest model possible」「run large nodes with multiple cores or threads」「scale out and in, adding and removing nodes」「cache objects」(SelectEngine.html「Choose Memcached」の箇条書き)
  • Valkey/Redis側の4項目は、現行ドキュメントでは箇条書きではなく比較表(Comparison summary)からの再構成: Data types=Complex、High availability (replication)=Yes、Automatic failover=Optional/Required、Pub/Sub=Yes、Backup and restore=Yes がいずれもValkey/Redis側のみ。現行の「Choose Valkey or Redis OSS」箇条書き自体はバージョン別機能(9.0/8.2/8.1/8.0/7.2/6.2/6.0)の列挙になっている

公式の分かれ道は「シンプルさ・多コアの大ノード・ノード数での伸縮」を求めるならMemcached、「豊かなデータ型・高可用性・pub/sub・バックアップ」を求めるならValkey/Redis。求める道具の数がそのまま選択を決める。

③ 比較表を1行ずつ — マルチスレッドだけがMemcachedの独壇場

機能
Memcached
V/R cluster無効
V/R cluster有効
マルチスレッド
Yes唯一の独壇場
No
No
高可用性レプリケーション
No
Yes
Yes
自動フェイルオーバー
No
Optional
Required
Pub/Sub
No
Yes
Yes
Sorted sets
No
Yes
Yes
バックアップ/リストア
No*node-basedは非対応
Yes
Yes
データ分割sharding
Yes
No
Yes
  • Multi-threaded は Memcached だけ Yes、Valkey/Redis は両モードとも No(=シングルスレッド設計)
  • Automatic failover は cluster mode disabled で "Optional"、enabled で "Required"
  • バックアップ/リストアの No* は node-based クラスタの話。原文「For serverless caches only, not applicable to node-based clusters」— Memcachedのnode-basedクラスタでは非対応
  • データ分割: Memcached=Yes、Valkey/Redis(cluster mode disabled)=No、(cluster mode enabled)=Yes

表を縦に読むと構図が見える。Memcachedが唯一勝つのは「マルチスレッド」、Valkey/Redisが独占するのは「レプリケーション・自動フェイルオーバー・pub/sub・sorted sets・バックアップ」。そしてValkey/Redisはシングルスレッド——この1点が、次のレッスンで見る『重いコマンド1つが全体を止める』話の伏線になる。

④ シングルスレッドはなぜ「弱み」でなく「設計」か

Memcached1つの大ノード(多コア)
対極
Thread 1
Thread 2
Thread 3
Thread 4
共有データにはロックが要る
1本のスレッドが順番に1つずつ実行
Valkey/Redisシングルスレッド+イベントループ
代償
ロック不要実行順序が保証される
豊かな道具を一列で正確に回す
重いコマンド1つ後続を全部待たせる
  • Multi-threaded: Memcached=Yes / Valkey・Redis=No(比較表)
  • シングルスレッドが「なぜ速いか」を公式が直接論じてはいない。比較表の Multi-threaded=No が事実で、ロック不要・順序保証という一般論はCS基礎の解説(公式挙動=sorted setsが挿入のたびに再ランクし順序を保証、と整合)
  • Lambda編・コンテナ編で見た「スレッドを増やして並列にさばく」がMemcached側。その対極が、シングルスレッド+イベントループで「ロックなしに順序を保証する」Valkey/Redis側。同じ製品カテゴリの中に、CS基礎の並行処理の2大設計が並んで実装されている

シングルスレッドは性能の欠陥ではなく選択。1本で回すからロックが要らず、コマンドの実行順序が保証される。その代わり、時間計算量の重いコマンド1つが全体を止める——強みと弱みは同じ設計の裏表。

⑤ 証拠その1:リーダーボード — 計算をアプリからキャッシュへ移す

アプリで順位計算毎回ソートして順位を出す重さ
ZREVRANGEBYSCORE leaderboard +inf -inf
ZADD ×4Robert 132 / Sandra 231 / June 32 / Adam 381
挿入のたびにリアルタイムで再ランク
ZADD leaderboard 232 June(スコアを上書き更新)
Adam→Sandra→Robert→June常に順位が保たれている
ZREVRANK leaderboard June
Adam→June→Sandra→RobertJuneが繰り上がる
1 が返るzero-based なので2位
  • 公式原文「With Valkey or Redis OSS sorted sets you can move the computational complexity of leaderboards from your application to your cluster.」
  • 「each time a new element is added to the sorted set it's reranked in real time」— 挿入のたびに再ランク。コマンドと出力は公式の例をそのまま。ZREVRANK は 0始まり(zero-based)なので2位=1
  • Sorted sets は Valkey/Redis のみ Yes(Memcached=No)
  • DynamoDB編の「クエリに合わせてデータを形作る」思想と同じ。アプリが毎回計算する代わりに、データ構造(sorted set)そのものに順序を持たせ、計算の複雑さをキャッシュ側へ移す。Memcachedの「単純な塊」ではこれはできない

sorted setsは「値が操作できる構造」の代表例。挿入のたびにリアルタイムで並べ替えるので、アプリは順位計算を持たなくていい。これが「データ構造サーバー」であることの証拠その1。

⑥ 証拠その2:pub/sub — チャネルに発行し、購読者だけが受け取る

PUBLISHnews.sports.golf に発行
発行者は「誰が受け取るか」を知らない
購読している人だけに届く
チャネルnews.sports.golf
パターン購読もできる
購読者ASUBSCRIBE
購読者BSUBSCRIBE
購読者CSUBSCRIBE
PSUBSCRIBEnews.sports.* で配下の全チャネルを一括購読
  • 公式原文「you send a message to a specific channel not knowing who, if anyone, receives it. The people who get the message are those who are subscribed to the channel.」
  • SUBSCRIBE(単一/複数)、PSUBSCRIBE(パターン)、PUBLISH(発行)は公式コマンド例。「Pub/sub functionality has no relation to any key space」— key空間とは独立
  • 公式の制約: クライアントは自分が購読中のチャネルへはPUBLISHできない(「A client can't publish to a channel that it is subscribed to.」)
  • PSUBSCRIBE/PUNSUBSCRIBE は ElastiCache Serverless では非対応。Sharded Pub/Sub は Valkey 7.2 / Redis OSS 7.0(Enhanced)以降で利用可。Pub/Sub は Valkey/Redis のみ Yes(Memcached=No)
  • メッセージング編で見たSNSファンアウト(1つの発行を複数の購読者へ)の原理の再登場。ただし今度は独立したメッセージブローカーではなく、キャッシュエンジンの中に同じpub/subが入っている。発行者と購読者が互いを知らずに疎結合になる構図は同じ

pub/subは発行者と購読者を切り離す。発行者はチャネルに投げるだけ、受け取るのは購読者だけ——同報配信の原理がキャッシュの中に組み込まれている。これが「データ構造サーバー」であることの証拠その2。Memcachedにはこの機能はない。

⑦ 締め:Valkeyへ新機能が載っていく流れ、そして結論

Redis OSS
バージョンを追うごとに積み上がる
ValkeyElastiCacheでは新機能がこちらに載っていく
8.0embedded keysで最大20%のメモリ効率改善
8.1Bloomフィルタ+メモリ効率ハッシュテーブル
8.2ベクトル検索(microsecond latency)
9.0全文検索/集約+Multi-AZトランザクションログのdurability
  • ValkeyがRedis OSSからフォークされたオープンソースであることは、この2ページには明記がない(AWSの他の公式発表・ドキュメントで周知)
  • バージョン別機能: memory efficiencies=Valkey 8.0+(embedded keysで最大20%改善)、Bloom filters=Valkey 8.1+(メモリ効率ハッシュテーブルはオーバーヘッド最大20%削減)、Vector search=Valkey 8.2+(microsecond latency・95%+ recall)、Full-text/Hybrid search/Aggregation=Valkey 9.0+
  • Durability(Multi-AZ transactional log)=Valkey 9.0+かつcluster mode enabledのみ(sync/async選択可、原文「zero data loss during failures」)。use-cases側の補強:「durabilityを有効にしsynchronous writesを選べば、データ損失が許されない用途(RAG知識ベース・AIエージェントメモリ・決済トークン化・リアルタイム在庫等)にも使える」
  • バージョンごとの機能対応は現行ドキュメントで確認済み(2026-07時点、ElastiCache for Valkey 9.0 が最新記載)。将来変わりうる

新機能(ベクトル検索・Bloomフィルタ・メモリ効率化・Multi-AZトランザクションログによるdurability)はValkey側に積み上がっていく。結論——「単純な仕事を並列にさばく」か「豊かな道具を一列で正確に回す」か。どちらが速いかは仕事の形が決める。2エンジンが併存する理由はここにある。

公式ドキュメントで詳しく ↗