1. 2026年のキャッシュ地図 — Redis vs Valkey 分裂時代

2026年のインメモリキャッシュ市場はもはや「Redis があれば十分」という単純な市場ではありません。2024年3月、Redis Ltd. が BSD ライセンスを捨てて RSALv2 / SSPL のデュアルライセンスに移行したことで、クラウドベンダーが Redis をマネージドサービスとして自由に販売できなくなり、その反発として Linux Foundation が Valkey というフォークを受け入れました。結果として、わずか1年半でキャッシュ市場は5つに分かれました。

- Redis 8 — RSALv2 / SSPL のもとで生き残った本家

- Valkey — Linux Foundation 配下のオープンソースフォーク（AWS / GCP / Oracle / Snap / Alibaba が後援）

- Dragonfly — マルチスレッド RESP 互換の新興（Roman Gershman 創業）

- KeyDB — マルチスレッド Redis フォーク、Snap が買収

- Garnet — Microsoft Research が2024年3月に公開した .NET ベース RESP 互換サーバ

ここに Memcached（いまも単純）、Apache Ignite / Hazelcast / Infinispan（JVM 陣営）、Aerospike（ハイブリッドメモリ/ディスク）、Tarantool（ロシア発）、Skytable（Rust）、そして RocksDB フォークの Speedb まで合わせると — 2026年のキャッシュ選択肢は「何を選ばないか」を決めるほうが難しくなりました。

本記事は、それらのキャッシュ／KV ストアを2026年5月時点で一気に概観するガイドです。シンプルなサイドキャッシュが必要な小さなチームから、マルチリージョンのグローバルシステムを設計する大きなチームまで、自分にあったツールを選ぶための地図を描くのが目的です。

2. Redis 8 — RSALv2/SSPL ライセンス変更後

Redis Ltd. は2024年3月20日、Redis 7.4 から BSD 3-Clause を捨てて、Redis Source Available License v2 (RSALv2) と Server Side Public License v1 (SSPLv1) のデュアルライセンスに移行すると発表しました。そして2025年5月、Valkey フォークの台頭を意識してか Redis 8 では BSD ではなく AGPLv3 のオプションを加えてリリース — 非クラウド利用者はふたたび「オープンソース」として受け取れるようになりましたが、クラウドベンダーがマネージドとして販売するには依然として RSALv2 / SSPL / 商用ライセンスが必要、という構図です。

Redis 8 の主な変更点を素早く整理すると。

- マルチスレッド I/O の強化 — シングルスレッドコアはそのまま、ネットワーク I/O とディスク I/O は別スレッドプールへ

- Vector Sets の正式導入 — 埋め込みベクトルをコアの一級市民として扱う（RediSearch HNSW より軽量）

- Streams の Consumer Group 自動フェイルオーバー改善

- HyperLogLog、Bitfield、Geo コマンドの RESP3 レスポンス整備

- Cluster モードの自動スロットリバランスアルゴリズム改善

- RedisJSON、RediSearch、RedisTimeSeries、RedisBloom をコアに統合（AGPL オプション時はモジュール分離）

Redis 8 のライセンスポリシーは、ようするに「AWS / GCP / Azure などのハイパースケーラーが Redis をマネージドとして売れないようにする」のが本質です。一般開発者はそのまま Docker で立てて使えますが、EKS 上の Redis を「公式マネージド」のように SaaS として再販する行為は SSPL 違反になります。

Redis 8 を Docker で起動（個人／社内利用は自由）

docker run -d --name redis8 \

-p 6379:6379 \

-v redis8-data:/data \

redis:8

新しい Vector Sets 型を使う

redis-cli VSET.ADD myset:vectors "doc-1" 0.1 0.2 0.3 0.4

redis-cli VSET.SEARCH myset:vectors VECTOR 0.1 0.2 0.3 0.4 COUNT 10

韓国／日本の運用現場で最も大きな変化は Sentinel の deprecate です。Redis Ltd. は7.x の頃から Sentinel ではなく Cluster モードを推奨しており、8 からは Sentinel コードそのものが「maintenance only」状態になります。カカオやトスのように Sentinel ベースの HA を運用していた現場では、Cluster モードへの移行が2026年で最大級のインフラ作業になりました。

3. Valkey — Linux Foundation Redis fork (2024.3)

Valkey は Redis のライセンス変更発表から、わずか8日後に立ち上がった Linux Foundation 配下のフォークです。AWS、Google Cloud、Oracle、Snap、Alibaba、Verizon、Ericsson などが主要スポンサーとして参加し、事実上「ハイパースケーラー連合の Redis バックアップ」として地位を確立しました。

Valkey のコア約束。

- BSD 3-Clause ライセンス — 永続的かつ変更不可

- Redis 7.2.4 のコードベースから分岐（RESP2 / RESP3 互換）

- ガバナンスは LF の Technical Steering Committee (TSC) が決定

- AWS、Google、Oracle のコアエンジニアがメインコントリビューター

2025年4月に Valkey 8.0 が発表され、2026年5月時点では Valkey 8.1 が stable です。差別化ポイント。

- マルチスレッド I/O がデフォルト — Redis 8 より早く導入

- Per-key ロック（key-level locking）でホットキー分散を改善

- RDMA（リモート直接メモリアクセス）ベースのクラスタ通信オプション

- 非同期レプリケーションの信頼性向上

- VKEYS という新データ構造（ベクトル検索、Redis Vector Sets とは別実装）

AWS は2024年末から Elasticache for Valkey を正式提供し、「既存の Elasticache for Redis より33％安い」という価格を打ち出しました。GCP MemoryStore も2025年中盤から Valkey オプションを提供しています。

Valkey を Docker で起動

docker run -d --name valkey \

-p 6379:6379 \

-v valkey-data:/data \

valkey/valkey:8.1

redis-cli がそのまま動作（RESP 互換）

redis-cli -h localhost SET key1 "Valkey value"

redis-cli -h localhost GET key1

→ "Valkey value"

既存の Redis クライアント（redis-py、ioredis、lettuce、jedis、go-redis）はコード変更なしで Valkey に接続できます。マイグレーションコストの低さが Valkey の最大の強みです。

4. KeyDB — Snap 買収

KeyDB は2019年に EQ Alpha Technology が作ったマルチスレッド Redis フォークです。コア自体は Redis と同じデータ構造／コマンドをサポートしますが、マルチスレッドイベントループにより単一ホストで複数コアを使えるのが差別点でした。

2022年1月に Snap（Snapchat の親会社）が EQ Alpha を買収し、KeyDB は Snap の社内キャッシュインフラに吸収されました。一時は「もう死んだのでは」と言われましたが、2024年に Snap が KeyDB コードベースの一部を Valkey に貢献し、ふたたび活気を取り戻しました。

KeyDB の差別化。

- マルチスレッディング — 単一インスタンスで複数コアを利用

- アクティブ-アクティブレプリケーション — 双方向同期（マルチマスター）

- FLASH モード — RocksDB バックエンドでメモリの一部を SSD にオフロード

- Subkey 期限 — Hash のフィールド単位で TTL を指定可能

KeyDB を Docker で

docker run -d --name keydb \

-p 6379:6379 \

-e KEYDB_THREADS=4 \

eqalpha/keydb

アクティブ-アクティブ双方向同期（概念）

keydb-cli REPLICAOF 192.168.1.10 6379

keydb-cli REPLICAOF 192.168.1.11 6379

互いに replica になり、双方向で同期

2026年時点での KeyDB の立ち位置は微妙です。単一ホストのマルチスレッドは Dragonfly のほうが速く、アクティブ-アクティブは Redis Enterprise の CRDT のほうが安定しており、Snap の積極的なマーケティングも止まっています。それでも既存の KeyDB ユーザーが「ライセンス気にせずマルチスレッド Redis を使いたい」のであれば、KeyDB 7.x はいまも妥当な選択肢です。

5. Dragonfly — マルチスレッドの競合

Dragonfly は2022年5月に Roman Gershman（元 Google のエンジニア）が公開した RESP 互換インメモリデータストアです。「Redis より25倍速い」というベンチマークで話題になり、2026年時点でキャッシュ陣営でもっとも急速に成長している新興です。

Dragonfly のコア差別化は本物のマルチスレッドアーキテクチャです。Redis はシングルスレッドのイベントループ、KeyDB / Valkey は「マルチスレッド I/O ＋ シングルスレッドコア」ですが、Dragonfly はコア自体が shard-per-thread 構造です。すなわち8コアマシンでは、独立した8シャードが同じプロセス内で動作します。

技術的な差別化。

- Shard-per-thread — 1コアが1シャードのすべてのキーを所有

- Threadsafe IO — io_uring ベースの非同期 I/O

- メモリ効率 — Redis 比でメモリ使用量を30〜50％削減（LRU ＋ 圧縮）

- Snapshot — fork-less BGSAVE（Redis の fork() ボムを回避）

- BulSearch / ベクトル検索を内蔵

Dragonfly を Docker で

docker run -d --name dragonfly \

--ulimit memlock=-1 \

-p 6379:6379 \

docker.dragonflydb.io/dragonflydb/dragonfly

クライアントは Redis と同じ

redis-cli SET large_key "value"

redis-cli MEMORY USAGE large_key

→ Dragonfly は Redis より小さく表示する

Dragonfly のライセンスは BSL 1.1（Business Source License）です。4年後には Apache 2.0 へ自動的に変わりますが、その前は「Dragonfly と競合する SaaS」としては利用できません。一般開発者／社内運用者は無償で使えます。

Dragonfly Inc. は Dragonfly Cloud（マネージド）と Dragonfly Swarm（マルチノードクラスタ）を商用展開し、2024〜2025年にシリーズ B 資金調達を済ませています。

6. Memcached — いまも単純

Memcached は2003年に Brad Fitzpatrick が LiveJournal のために作った、最初の分散インメモリキャッシュです。23年経った2026年でも生きており、一部の領域ではいまも第一選択です。

Memcached が生き残った理由は単純さ。

- キー／値のみを保存（データ構造なし — Hash / List / Set はすべてクライアント側でシリアライズ）

- LRU ポリシーで自動 eviction

- マルチスレッドがデフォルト（Redis より早かった）

- 永続化なし — 再起動でデータ消失（意図された設計）

- Slab アロケータでメモリ断片化を回避

Memcached を Docker で起動（純粋なキャッシュ）

docker run -d --name memcached \

-p 11211:11211 \

memcached:1.6 \

-m 512 \

-t 4

telnet で直接アクセス（プレーンテキストプロトコル）

telnet localhost 11211

> set hello 0 60 5

> world

> STORED

> get hello

> VALUE hello 0 5

> world

> END

Facebook、Twitter（旧）、Pinterest のような巨大 Web サービスが Memcached を「純粋なキャッシュ」として使っています。Redis のデータ構造／永続化／トランザクションが不要な場面では、Memcached のほうが軽くて速いのです。

2026年の韓国事例では、Naver 検索のキャッシュ層の一部（検索キーワード → 結果 ID）が依然として Memcached の上で動いています。日本では LINE メッセンジャーの一部バックエンド、Yahoo Japan 検索が Memcached を使っています。

7. Garnet (Microsoft, 2024.3) — .NET ベースの RESP 互換

Garnet は Microsoft Research が2024年3月18日にサプライズ公開した .NET ベースの RESP 互換インメモリデータストアです。もっとも衝撃的だったのは「Redis 比で単一ノードのスループット100〜900％向上」というベンチマークでした。

Garnet の要点。

- .NET 8 / 9 ベース — C# で実装（ガベージコレクタ上で動作）

- RESP2 / RESP3 互換 — Redis クライアントがそのまま使える

- Tsavorite KV store — Microsoft 独自の KV エンジン（FASTER の後継）

- Pub/Sub、Streams、Cluster モード対応

- マルチスレッド ＋ ロックフリーデータ構造

Garnet を Docker で

docker run -d --name garnet \

-p 6379:6379 \

ghcr.io/microsoft/garnet

redis-cli がそのまま動く

redis-cli PING

→ PONG

redis-cli SET hello "Garnet"

redis-cli GET hello

→ "Garnet"

Garnet の特異な点は「GC 上で動く .NET キャッシュが、C で書かれた Redis より速い場合がある」という証明です。Microsoft が Tsavorite KV（旧 FASTER）を長年磨いてきた結果として、マルチコア環境での lock-free キュー／ハッシュが大きな差をつくります。

ライセンスは MIT — Apache 2.0 / BSD 陣営でもっとも自由なモデルです。つまりクラウドベンダーが Garnet をマネージドで売っても問題ありません。Azure は2025年末に「Garnet for Azure Cache」のプレビューを公開しました。

弱点は .NET 依存です。運用者が .NET ランタイムに詳しくないと GC チューニング／メモリプロファイリングが難しくなります。そのため「Garnet は .NET ショップ向き」が現在の市場一般論です。

8. Apache Ignite / Hazelcast / Infinispan — JVM 陣営

JVM 陣営にはインメモリ「データグリッド」という別カテゴリがあります。Redis のような単純な KV ではなく、SQL クエリ／トランザクション／コンピュート／機械学習推論まで合わせて処理する大きな統合プラットフォームです。

Apache Ignite

Apache Foundation のインメモリデータグリッド ＋ コンピューティングプラットフォーム。SQL ANSI-99 互換、分散トランザクション、機械学習モジュール、そしてディスク永続化（Native Persistence）まで対応します。

// Java から Ignite クラスタへアクセス

Ignite ignite = Ignition.start();

IgniteCache cache = ignite.cache("orders");

cache.put("order:1", new Order(...));

// SQL もそのまま

SqlFieldsQuery query = new SqlFieldsQuery(

"SELECT id, amount FROM Order WHERE customerId = ? LIMIT 100");

List rows = cache.query(query.setArgs(42)).getAll();

Apache Ignite は2026年時点で GridGain の商用ディストリビューションがメインチャネル。米国の航空／金融／ヘルスケアといった規制産業でインメモリ SQL グリッドとして活発に使われています。

Hazelcast

商用インメモリデータグリッドの代表格。Java / Node / Python / C++ クライアント、Jet（ストリーム処理）、Hazelcast IMDG / Hazelcast Platform などフルスタックを提供します。

- 分散 Map / Queue / Set / Lock / Semaphore

- Compute Grid — 分散タスク実行

- Jet — Stream Processing（Apache Flink に類似）

- Hazelcast Mancenter — クラスタ監視／管理

Infinispan (Red Hat)

Red Hat のオープンソースインメモリデータグリッド。JBoss / Quarkus / WildFly との統合が強く、JCache (JSR 107) 標準実装です。

JVM 陣営のツールは「単純なキャッシュ」ではなく「インメモリデータプラットフォーム」です。JVM 上で働く大エンタープライズ（銀行、保険、通信、公共）が主要顧客です。

9. Aerospike — ハイブリッドメモリ/ディスク

Aerospike は「インデックスは RAM、データは SSD」というハイブリッドモデルで有名な分散 KV ストアです。Redis のようにすべてのデータを RAM に乗せず、NVMe SSD のランダムアクセス性能に頼って非常に大きなデータセットを扱います。

差別化ポイント。

- ハイブリッドメモリアーキテクチャ — インデックスのみ RAM、値は SSD から直接アクセス

- Strong consistency オプション（Aerospike SC）

- データセンター間レプリケーション（XDR）

- Aerospike Vector Search — 2024年追加

- TPS — 単一クラスタで100万 TPS 以上を検証済み

Aerospike を Docker で

docker run -d --name aerospike \

-p 3000-3002:3000-3002 \

aerospike/aerospike-server

Python クライアント

python3 << EOF

client = aerospike.client({'hosts': [('localhost', 3000)]}).connect()

key = ('test', 'demo', 'foo')

client.put(key, {'name': 'Alice', 'age': 30})

(key, meta, bins) = client.get(key)

print(bins)

EOF

Aerospike の主な顧客はアドテック（AppLovin、Criteo、Trade Desk）、金融（PayPal、Wells Fargo）、ゲーム（King、Riot Games）です。「単一クラスタで100億キー、1ms 応答」というシナリオで強みを発揮します。

2026年現在 Aerospike 8.0 が stable で、ベクトル検索／グラフ／時系列を統合した「マルチモデルデータベース」としてポジショニングしています。

10. Tarantool — ロシア発のインメモリ DB

Tarantool は2010年にロシアの Mail.ru（現在の VK）が作ったインメモリデータベースです。単純なキャッシュではなく、Lua ベースのストアドプロシージャ、SQL、永続化、クラスタリングまで統合したフルスタック DB です。

- インメモリ ＋ WAL — メモリに保持しつつディスクに永続化

- Lua ベースのストアドプロシージャ — バックエンドのビジネスロジックを埋め込み

- SQL（Tarantool SQL）＋ NoSQL（tuples）

- Vinyl エンジン — LSM ツリーベースのディスクエンジン（大容量向け）

- Cluster — Cartridge フレームワークでクラスタ運用

-- Tarantool で Space を定義してデータを挿入（Lua）

box.cfg{ listen = 3301 }

s = box.schema.space.create('users', {

format = { {name='id', type='unsigned'}, {name='name', type='string'} }

})

s:create_index('primary', { parts = {'id'} })

s:insert{1, 'Alice'}

s:insert{2, 'Bob'}

print(s:get{1})

-- → [1, 'Alice']

ロシア／東欧では Tarantool が Redis の代替として活発に使われ、日本では NTT が5G コアネットワークのセッションストアとして Tarantool を採用した事例が有名です。通信会社特有の安定性要件のために Redis よりも Tarantool が好まれたケースです。韓国ではほぼ見かけませんが、グローバル市場（特に通信／ゲーム）には深いユーザー基盤があります。

2022年以降、ロシア IT への国際制裁の影響で中核開発チームが分かれ、「Picodata」という新プロジェクトとして分岐し、2系統で発展中です。

11. AWS Elasticache vs MemoryDB vs Valkey の選択肢

AWS のインメモリキャッシュ／KV サービスは、2026年時点で3つに分かれています。何を選ぶかは下記の表で。

| サービス | ライセンス | 永続化 | 価格 | 用途 |

|----------|------------|---------|------|------|

| Elasticache for Redis | RSALv2/SSPL | オプション（バックアップ） | 標準 | Redis 互換性を最優先 |

| Elasticache for Valkey | BSD | オプション（バックアップ） | Redis 比33％安い | 新規ワークロード、ライセンス回避 |

| Elasticache for Memcached | BSD | なし | 最安 | 純粋キャッシュ |

| MemoryDB for Redis | RSALv2/SSPL | 強制（Multi-AZ WAL） | 最高 | プライマリ DB として利用 |

| MemoryDB for Valkey | BSD | 強制（Multi-AZ WAL） | MemoryDB Redis よりやや安い | プライマリ DB、ライセンス自由 |

MemoryDB は「Redis 互換インターフェースを持つ永続 KV DB」です。Multi-AZ WAL でデータ損失ゼロを保証しますが、その代償として価格が Elasticache の3〜4倍です。すなわち Elasticache は「DB の前のキャッシュ」、MemoryDB は「DB そのもの」というポジションです。

AWS CLI で Elasticache for Valkey クラスタを作成

aws elasticache create-cache-cluster \

--cache-cluster-id my-valkey \

--engine valkey \

--engine-version 8.1 \

--cache-node-type cache.t4g.small \

--num-cache-nodes 1

MemoryDB for Valkey クラスタ（永続 ＋ Multi-AZ）

aws memorydb create-cluster \

--cluster-name my-memorydb \

--engine valkey \

--node-type db.t4g.small \

--num-shards 1 \

--num-replicas-per-shard 2

2026年5月時点の AWS の推奨は「新規プロジェクトは Valkey から始め、既存 Redis 互換が必要なら Elasticache for Valkey、Multi-AZ 永続化が必要なら MemoryDB for Valkey」です。ライセンス変更のインパクトがそのまま価格表に反映された形です。

12. Skytable / Speedb — Rust ＋ RocksDB フォーク

「次世代候補」に分類される2つのプロジェクトが2026年に注目されています。

Skytable

Skytable は Rust で書かれた BSL ライセンスの NoSQL データベースです。RESP / Skyhash の2プロトコル対応、SQL に似た BlueQL クエリ言語、そして「行ベース ＋ キー-値ハイブリッド」モデルが特徴です。

Skytable を Docker で

docker run -d --name skytable -p 2003:2003 skytable/sky:latest

Skytable CLI (skysh)

skysh -p 2003

> create model app.users(username: string, password: string)

> insert into app.users('alice', 'secret123')

> select * from app.users where username = 'alice'

Skytable の強みは Rust の安全性 ＋ マルチスレッド ＋ シングルバイナリです。「Redis の代替で SQL っぽいクエリができたら嬉しい」という小規模チームから少しずつ採用が広がっています。

Speedb

Speedb は Meta の RocksDB をフォークして作られた「速い RocksDB」です。RocksDB の API はそのままに、コンパクション／Bloom Filter／メモリ管理を作り直し、同じワークロードで2〜5倍のスループットを出します。

- API 完全互換 — RocksDB のコード変更なしでライブラリ差し替えだけで適用可能

- Apache 2.0 ライセンス

- 圧縮後のメモリ使用量を約40％削減

// C++ で Speedb を使う（RocksDB と同じインターフェース）

#include <rocksdb/db.h>

rocksdb::Options options;

options.create_if_missing = true;

rocksdb::DB* db;

rocksdb::DB::Open(options, "/tmp/speedb_test", &db);

db->Put(rocksdb::WriteOptions(), "hello", "world");

std::string value;

db->Get(rocksdb::ReadOptions(), "hello", &value);

// → "world"

Speedb は単独 KV サーバではなく組み込みライブラリなので、Redis 代替というより「RocksDB を使うすべてのシステム（Kafka、MyRocks、TiKV）の性能アップグレード」という位置づけになっています。

13. インプロセスライブラリ — node-cache / lru-cache / cachetools / Caffeine

分散キャッシュサーバ以外に、アプリケーションプロセス内部のインメモリキャッシュも別に見るべきです。「DB の前に Redis」ではなく「アプリ内 Map に5分の TTL」のケースが、実はとても多いのです。

Node.js — lru-cache, node-cache, keyv

- lru-cache（Isaac Schlueter、npm の作者） — 事実上の標準。LRU ＋ TTL ＋ max size

- node-cache — 単純な TTL ベース（LRU なし）

- keyv — マルチアダプタ（Redis、SQLite、Memory）抽象化ライブラリ

// lru-cache の利用例

const cache = new LRUCache({

max: 500,

ttl: 1000 * 60 * 5, // 5分

updateAgeOnGet: true,

})

cache.set('user:42', { name: 'Alice' })

console.log(cache.get('user:42'))

Python — cachetools, functools.lru_cache, diskcache

- functools.lru_cache — 標準ライブラリ、デコレータベース

- cachetools — LRU、LFU、TTL、RR（ランダムリプレースメント）など多様なポリシー

- diskcache — ディスクバックエンドキャッシュ（単一プロセス組み込み）

cachetools の利用

from cachetools import TTLCache, cached

cache = TTLCache(maxsize=100, ttl=300) # 5分

@cached(cache)

def expensive_query(user_id):

return db.query("SELECT * FROM users WHERE id = ?", user_id)

Java — Caffeine, Guava Cache, EHCache

- Caffeine（Ben Manes） — 事実上の標準。W-TinyLFU ポリシー、async loader、非常に高速

- Guava Cache — 古い標準。いまは Caffeine への置き換え推奨

- EHCache — Terracotta / Ehcache 3、JCache 標準実装

// Caffeine の利用

LoadingCache cache = Caffeine.newBuilder()

.maximumSize(10_000)

.expireAfterWrite(Duration.ofMinutes(5))

.recordStats()

.build(key -> loadFromDb(key));

User user = cache.get("user-42");

Go — bigcache, ristretto, groupcache

- ristretto（Dgraph） — 並行性最適化、W-TinyLFU

- bigcache（Allegro） — GC 最適化（ポインタなし byte slice）

- groupcache（Brad Fitzpatrick、Memcached の作者） — singleflight 内蔵

インプロセスキャッシュは分散キャッシュよりずっと速い（1ns vs 1ms 程度の差）。なので「L1 ＝ プロセス内ライブラリ、L2 ＝ Redis/Valkey」という多段キャッシュが定番パターンです。

14. 分散キャッシュパターン — cache-aside / read-through / write-through / write-back / write-around

分散キャッシュを使うとき、キャッシュとバックエンド DB の同期方式をどう設計するかが、正確性／性能／整合性のトレードオフを決めます。

Cache-aside（Lazy loading）

もっとも一般的なパターン。アプリケーションがキャッシュと DB を直接扱います。

def get_user(user_id):

1. キャッシュ参照

user = cache.get(f"user:{user_id}")

if user:

return user

2. キャッシュミス → DB 参照

user = db.query("SELECT * FROM users WHERE id = ?", user_id)

3. キャッシュ更新

cache.set(f"user:{user_id}", user, ttl=300)

return user

長所は単純さと、キャッシュ障害時の DB フォールバック。短所はキャッシュミス時の応答遅延。

Read-through

キャッシュサーバが自身で DB を参照。アプリケーションはキャッシュだけを見ます。

キャッシュライブラリが loader を受け取る

@cached_loader(loader=lambda k: db.query(f"SELECT * FROM users WHERE id = '{k}'"))

def get_user(user_id):

return cache.get(f"user:{user_id}")

Caffeine の LoadingCache、Hazelcast の MapStore がこのパターンです。

Write-through

書き込み時、キャッシュ → DB の順で同期書き込み。整合性は保たれますが、書き込みが遅くなります。

Write-back（Write-behind）

書き込み時はキャッシュだけ更新、DB は非同期で後で更新。速いが、キャッシュ障害でデータ損失リスクあり。

Write-around

書き込みは DB のみ、読み出し時にキャッシュを埋める。あまり読まれない書き込みが多いワークロード（ログ、イベント）に向いています。

| パターン | 読み性能 | 書き性能 | 整合性 | 複雑度 |

|----------|----------|----------|---------|--------|

| Cache-aside | ミス時に遅い | 速い（キャッシュ無関係） | 中（レースコンディションあり） | 低 |

| Read-through | ミス時に自動 | 速い | 中 | 中 |

| Write-through | 速い | 遅い（2回書き込み） | 強 | 中 |

| Write-back | 速い | 非常に速い | 弱（損失リスク） | 高 |

| Write-around | ミス時に遅い | 速い | 強 | 低 |

ほとんどの Web サービスは Cache-aside から始めます。書き込みパターンが定まれば Write-around または Read-through に進化し、整合性が重要なトランザクションシステムは Write-through を選びます。

15. ホットキー + キャッシュスタンピード問題 — singleflight + dogpile の回避

分散キャッシュ運用でもっともよく出会う2大障害が「ホットキー」と「キャッシュスタンピード」です。

ホットキー問題

特定のキー（例：「トップページ人気商品 TOP10」「今日のレート」）がすべてのトラフィックを単一シャードに集中させる現象。Redis Cluster モードでも単一キーは単一シャードに固定なので、そのシャードの CPU が100％になります。

対策。

- キーシャーディング — 「top10:1」「top10:2」など意図的に分散、クライアントがランダム選択

- クライアントサイドキャッシュ — Redis 6.0+ の client-side caching、もしくは lru-cache を L1 として

- リードレプリカ — Redis Cluster ＋ replica read

キャッシュスタンピード（Thundering herd / Dogpile）

キャッシュが期限切れになる瞬間、全リクエストが DB に殺到する現象。1000 RPS のトラフィックがいきなり1000の DB クエリに化けます。

対応パターン。

singleflight パターン — Go groupcache から拝借した概念

_locks = {}

_lock_lock = threading.Lock()

def get_or_load(key, loader):

cached = cache.get(key)

if cached:

return cached

同じキーに対してロードは1つだけ

with _lock_lock:

if key not in _locks:

_locks[key] = threading.Lock()

key_lock = _locks[key]

with key_lock:

もう一度キャッシュを確認（先行リクエストが埋めたかも）

cached = cache.get(key)

if cached:

return cached

本当に loader を実行

value = loader()

cache.set(key, value, ttl=300)

return value

その他のパターン。

- Probabilistic early expiration — 期限直前で一部のリクエストだけ更新（XFetch アルゴリズム）

- Stale-while-revalidate — 期限切れの値をいったん返し、バックグラウンドで更新

- Refresh-ahead — 期限前にバックグラウンドで自動リフレッシュ（Caffeine の refreshAfterWrite）

XFetch（Probabilistic early expiration）— Redis 7+ の CLIENT NO-EVICT と組み合わせ可能

def xfetch(key, ttl, beta=1.0):

val, delta, expiry = cache.get_with_meta(key)

if val is None:

キャッシュミス → 常に更新

return refresh(key)

if time.time() - delta * beta * math.log(random.random()) >= expiry:

期限前だが一部のリクエストだけ更新

return refresh(key)

return val

トス／カカオの運用事例では「singleflight ＋ Refresh-ahead」の組み合わせが頻繁に登場します。すなわち、1キーに対してローダーは1つだけ走り、期限直前にバックグラウンドで自動更新するパターンです。

16. Redis モジュールの分裂 — RedisJSON、RediSearch、RedisGraph (sunset)、RedisTimeSeries、RedisBloom

Redis Ltd. のライセンス変更はモジュールエコシステムにも大きな衝撃を与えました。2026年時点で Redis の主要モジュールは次の状況です。

- RedisJSON — Redis 8 コアに統合（ただし AGPL/RSAL/SSPL ライセンス）

- RediSearch — Redis 8 コアに統合、Vector search と Full-text search

- RedisGraph — 2023年7月に sunset 発表、2025年に EOL

- RedisTimeSeries — Redis 8 コアに統合

- RedisBloom — Redis 8 コアに統合（Bloom、Cuckoo、Count-Min Sketch）

Valkey 陣営は独自の代替を開発中です。

- VKEYS Vector Search — Valkey 自身のベクトル検索（Redis の Vector Sets とは別）

- Valkey JSON — Cocoa というモジュールとして開発中

- Valkey Search — RediSearch の代替として開発中

- Valkey Bloom — Bloom Filter モジュールを別途開発

RedisGraph の EOL はグラフ DB ユーザーに衝撃でした。代替として Memgraph（インメモリグラフ DB）、Neo4j、ArangoDB が挙げられます。

Redis 8 コアで JSON データ構造を使う（モジュール別ロード不要）

redis-cli JSON.SET user:1 $ '{"name":"Alice","age":30}'

redis-cli JSON.GET user:1 $.name

→ "Alice"

Vector Search（RediSearch 統合）

redis-cli FT.CREATE products ON HASH PREFIX 1 product: \

SCHEMA name TEXT embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

モジュールの統合／分裂は、結局のところ「誰の Redis が標準か」という政治的問題です。大企業は Valkey 陣営のモジュールの進捗を見ながら、ゆっくりとマイグレーション計画を立てています。

17. 韓国 / 日本 — カカオ、トス、メルカリ、NTT

各地域のキャッシュ運用事例を素早く整理します。

韓国 — カカオ、トス、ナバー、クーパン

- カカオ — Redis Cluster ＋ Sentinel ベース、2024年のライセンス変更後に Valkey マイグレーション開始。カカオトークのメッセージキュー／友達リスト／チャットルームキャッシュ

- トス — Redis 7.x ＋ 自社運用、MSA アーキテクチャでサービス別に独立した Redis クラスタ。「Redis が落ちるとトスが止まる」という表現が社内にあるほど

- ナバー — Memcached ＋ Redis ミックス。検索結果のキャッシュは依然 Memcached、レコメンドシステムは Redis Cluster

- クーパン — AWS Elasticache for Redis を大量利用。ライセンス変更後に Valkey 移行を進行中

- ライン（LY Corp） — Redis Sentinel ＋ 独自ソリューション、グローバルデータセンター別に独立クラスタ

日本 — メルカリ、NTT、ヤフージャパン、LINE

- メルカリ — GCP MemoryStore for Redis、商品検索キャッシュ／ユーザーセッション。2025年から一部 Valkey 移行 PoC

- NTT — Tarantool を5G コアのセッションストアとして採用した事例が有名。通信会社特有の安定性要求から Redis より Tarantool を選好

- ヤフージャパン — Memcached ＋ 自社 KV。検索／広告キャッシュは Memcached、ユーザーデータは独自分散 KV

- LINE — Redis Cluster を大量利用、日本 LINE と台湾 LINE で別運用

- サイゲームス — Redis Cluster ＋ Aerospike ミックス、モバイルゲームのリアルタイムランキング／インベントリ

日韓両国の共通点は「Redis ライセンス変更後、Valkey 移行を検討中」です。違いは日本のほうが保守的で「検討だけ長め」、韓国は「PoC を素早く → 本番適用」が多い点です。

18. 誰が何を選ぶべきか — シンプル / 複雑データ構造 / 分散 / エンタープライズ

最後に、「誰に何を勧めるか」を整理します。

シンプルなキャッシュ（TTL があれば十分）

→ Memcached。単一ノードなら Docker 1行、クラスタならクライアントサイド sharding。「Redis のデータ構造は要らない」と確信できるなら、Memcached がもっとも軽快です。

複雑なデータ構造（Hash / List / Set / Sorted Set / Stream）

→ Redis 8（ライセンス OK なら）または Valkey 8.1（オープンソース優先）。事実上の標準なので、クライアント／ツール／ドキュメントがもっとも豊富。

マルチスレッドの単一ノードスループット

→ Dragonfly。単一マシン上で最大スループット／最小メモリ。Redis の1対1代替。

.NET / Azure 環境

→ Garnet。MIT ライセンス ＋ C# 運用フレンドリー。Azure では Cache for Garnet プレビューを活用。

SQL ＋ インメモリグリッド ＋ トランザクション

→ Apache Ignite（OSS）または Hazelcast（商用サポート）。金融／通信／ヘルスケアといった大型エンタープライズワークロード。

メモリより大きいデータセット（Hybrid）

→ Aerospike。RAM インデックス ＋ SSD データのモデルで100億キーも可能。

Lua 埋め込みのビジネスロジック ＋ インメモリ DB

→ Tarantool。通信／ゲームに特に向く。

AWS マネージド

→ 新規ワークロードは Elasticache for Valkey もしくは MemoryDB for Valkey。既存 Redis 互換だけが必要なら Elasticache for Redis を維持。

Rust / 安全性優先

→ Skytable（または Dragonfly。後者は C++）。シングルバイナリ、メモリ安全。

RocksDB ベースの組み込み KV

→ Speedb。コード変更なしで性能アップグレード。

プロセス内キャッシュ（アプリケーションライブラリ）

→ Java：Caffeine。Node：lru-cache。Python：cachetools。Go：ristretto。

パターンガイド

- 読み中心 ＋ 弱い整合性 → Cache-aside ＋ lru-cache（L1）＋ Redis（L2）

- 書き中心 ＋ 強い整合性 → Write-through ＋ Caffeine ＋ MemoryDB

- 非常に大きなデータ → Aerospike または Ignite Native Persistence

- グローバルマルチリージョン → Redis Enterprise CRDT または KeyDB Active-Active

- シンプル LRU → Memcached ＋ クライアント lru-cache

2026年のキャッシュ決定は「Redis でいい」ではなく、「Redis のどのバージョン／フォークをどのパターンでどのライブラリと組み合わせるか」という多層的な決定です。ライセンス変更のうねりは結局のところ市場の多様性を増やし、私たちはその多様性をうまく選ばなければならない立場になりました。

19. 参考 / References

- Redis — https://redis.io/

- Redis 8 Release Notes — https://redis.io/blog/redis-8-ga/

- Redis License FAQ — https://redis.io/legal/licenses/

- Valkey — https://valkey.io/

- Valkey GitHub — https://github.com/valkey-io/valkey

- Linux Foundation Valkey 発表 — https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community

- KeyDB — https://docs.keydb.dev/

- KeyDB GitHub — https://github.com/Snapchat/KeyDB

- Dragonfly — https://www.dragonflydb.io/

- Dragonfly GitHub — https://github.com/dragonflydb/dragonfly

- Memcached — https://memcached.org/

- Microsoft Garnet — https://microsoft.github.io/garnet/

- Garnet GitHub — https://github.com/microsoft/garnet

- Apache Ignite — https://ignite.apache.org/

- Hazelcast — https://hazelcast.com/

- Infinispan — https://infinispan.org/

- Aerospike — https://aerospike.com/

- Tarantool — https://www.tarantool.io/

- Skytable — https://skytable.io/

- Speedb — https://www.speedb.io/

- AWS Elasticache — https://aws.amazon.com/elasticache/

- AWS Elasticache for Valkey — https://aws.amazon.com/elasticache/valkey/

- AWS MemoryDB — https://aws.amazon.com/memorydb/

- GCP Memorystore — https://cloud.google.com/memorystore

- Caffeine — https://github.com/ben-manes/caffeine

- lru-cache (Node) — https://github.com/isaacs/node-lru-cache

- node-cache — https://github.com/node-cache/node-cache

- cachetools (Python) — https://github.com/tkem/cachetools

- ristretto (Go) — https://github.com/hypermodeinc/ristretto

- bigcache (Go) — https://github.com/allegro/bigcache

- groupcache (Go) — https://github.com/golang/groupcache

- XFetch アルゴリズム（Probabilistic early expiration）— https://www.vldb.org/pvldb/vol8/p886-vattani.pdf

- RedisJSON — https://github.com/RedisJSON/RedisJSON

- RediSearch — https://github.com/RediSearch/RediSearch

- RedisGraph EOL — https://redis.io/blog/redisgraph-eol/

- RedisTimeSeries — https://github.com/RedisTimeSeries/RedisTimeSeries

- RedisBloom — https://github.com/RedisBloom/RedisBloom

- Speedb vs RocksDB — https://www.speedb.io/blog

- Memgraph（RedisGraph 代替） — https://memgraph.com/

- Picodata（Tarantool 分岐） — https://picodata.io/