LabHub

ブログ

インメモリキャッシュ & KV ストア 2026 — Redis 8 / Valkey / KeyDB / Dragonfly / Memcached / Garnet (Microsoft) / Speedb 徹底比較

2026-05-16 · 34 分で読めます · #caching#key-value-store#redis#valkey#keydb#dragonfly#memcached#apache-ignite#hazelcast#infinispan#aerospike#tarantool#elasticache#memorydb#garnet-microsoft#skytable#speedb#rocksdb#lru-cache#cachetools#caffeine#cache-aside#read-through#write-through#write-back#hot-key#cache-stampede#deep-dive#japanese

한국어English日本語

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

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

ここに 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 の主な変更点を素早く整理すると。

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 のコア約束。

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

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 の差別化。

# 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シャードが同じプロセス内で動作します。

技術的な差別化。

# 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 が生き残った理由は単純さ。

# 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 の要点。

# 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 などフルスタックを提供します。

Infinispan (Red Hat)

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

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

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

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

差別化ポイント。

# Aerospike を Docker で
docker run -d --name aerospike \
  -p 3000-3002:3000-3002 \
  aerospike/aerospike-server

# Python クライアント
python3 << EOF
import aerospike
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 です。

-- 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 RedisRSALv2/SSPLオプション（バックアップ）標準Redis 互換性を最優先
Elasticache for ValkeyBSDオプション（バックアップ）Redis 比33％安い新規ワークロード、ライセンス回避
Elasticache for MemcachedBSDなし最安純粋キャッシュ
MemoryDB for RedisRSALv2/SSPL強制（Multi-AZ WAL）最高プライマリ DB として利用
MemoryDB for ValkeyBSD強制（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倍のスループットを出します。

// 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 の利用例
import { LRUCache } from '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

# 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 の利用
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

インプロセスキャッシュは分散キャッシュよりずっと速い（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％になります。

対策。

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

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

対応パターン。

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

_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

その他のパターン。

# XFetch（Probabilistic early expiration）— Redis 7+ の CLIENT NO-EVICT と組み合わせ可能
import random, math, time

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 の主要モジュールは次の状況です。

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

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

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

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

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

日韓両国の共通点は「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。

パターンガイド

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

19. 参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます