Each language version is independently generated for its own context, not a direct translation.
🍽️ 物語の舞台：老舗レストラン「Redis」の危機
昔々、インターネットの世界では「Redis」というお店が、**「とにかく速くて、誰でも使える」**として圧倒的な人気を博していました。データ（注文）を瞬時に記憶し、すぐに返すのが得意だったのです。
しかし、最近 Redis を運営する会社が**「ライセンス（利用規約）を厳しく変えた」ため、多くの企業や開発者が「このままでは自由に使えなくなる！」と不安になり、「Redis 以外の新しいお店」**を探すようになりました。
そこで登場したのが、この論文で評価された3 つの新しいお店です。
- Valkey（ヴァルキー）：Redis の「弟分」。
- KeyDB（キー DB）：Redis の「多忙な兄貴」。
- Garnet（ガーネット）：Microsoft が作った「全く新しい高級店」。
🔍 3 つのお店を比較する実験
研究者たちは、Kubernetes（クラウドという大きなショッピングモール）の中にこれら 3 つのお店を建て、「1 日に何人の客をさばけるか（スループット）」や「客が待たされる時間（レイテンシ）」、**「人件費や家賃（CPU・メモリ効率）」**を徹底的にテストしました。
1. Valkey（ヴァルキー）：「完璧なリノベーション店」
- 特徴: 元々 Redis のお店を改造して作られました。メニュー（API）は100% 同じです。
- 性能: 元の Redis よりも30〜40% 速くなりました。
- メリット: 「Redis から乗り換えるなら、これ一択！」です。お店の看板を「Valkey」に書き換えるだけで、中身は全く同じように動きます。Linux ファウンデーションという大きな団体がバックアップしているので、**「将来も潰れない安心感」**があります。
- 結論: 既存のシステムを乗り換えるなら、最もおすすめ。
2. KeyDB（キー DB）：「多忙な兄貴」
- 特徴: 元々 Redis のお店を改造しましたが、**「複数の従業員（マルチスレッド）を同時に働かせて」**処理を速くしようとしています。
- 性能: Redis より少し速い（10〜15%）ですが、**「従業員が増えすぎたせいで、人件費（CPU 消費）が割高」**になってしまいました。
- デメリット: 最近、お店の改装や新メニューの開発が止まってしまっています。「このお店、いつ閉店するの？」という不安があります。
- 結論: コストと将来性を考えると、あまりおすすめできない。
3. Garnet（ガーネット）：「Microsoft 製・超高速新店舗」
- 特徴: Redis のお店とは全く別の、Microsoft がゼロから建てた新しい高級店です。
- 性能: 圧倒的に速い！Redis の2 倍近くの客をさばけます。また、「スペース効率（メモリ）」も抜群で、同じ人数をさばくのに必要な家賃（サーバー代）が 40% 節約できます。
- デメリット: メニュー（API）が70% しか共通していません。つまり、Redis で使っていた特別な注文方法が通じないため、**「メニューを全部書き直して、従業員を再教育する（コードを書き換える）」**という大変な手間がかかります。
- 結論: 「最初から新しく建てるお店」や「とにかく速度とコスト削減が最優先」なら最強。
📊 実験の結果（まとめ）
| お店の名前 |
速さ (スループット) |
待ち時間 (遅延) |
経費 (効率) |
乗り換えのしやすさ |
将来性 |
| Valkey |
⭐⭐⭐ (Redis より速い) |
⭐⭐⭐ |
⭐⭐⭐ |
🌟🌟🌟🌟🌟 (簡単) |
🌟🌟🌟🌟🌟 (安心) |
| KeyDB |
⭐⭐ (少し速い) |
⭐⭐ |
⭐ (割高) |
⭐⭐⭐⭐ |
⭐ (不安) |
| Garnet |
🌟🌟🌟🌟🌟 (爆速) |
🌟🌟🌟🌟🌟 |
🌟🌟🌟🌟🌟 (激安) |
⭐⭐ (大変) |
⭐⭐⭐ (Microsoft あり) |
💡 結局、どっちを選べばいいの？
この論文の著者たちは、以下のようにアドバイスしています。
- 「今使っている Redis を、手間をかけずに乗り換えたい」
👉 Valkey が正解です。メニューも同じで、速さも向上し、将来も安心です。
- 「新しくシステムを作るので、とにかく速くて安くていい」
👉 Garnet が正解です。乗り換えの手間はかかりますが、その分、長期的なサーバー代が大幅に浮きます。
- 「KeyDB はどう？」
👉 残念ながら、**「開発が止まっている」**という理由で、今回はおすすめしません。
🎯 一言で言うと
**「Redis の後継者探しなら、Valkey が『安全で快適なリノベーション』、Garnet が『未来の超高速新店舗』。KeyDB は『少し古びてきたお店』だから、今回は見送ろう」**というのが、この研究の結論です。
Each language version is independently generated for its own context, not a direct translation.
次世代クラウドネイティブ・インメモリストア：Redis から Valkey へ、そしてその先へ
論文の技術的サマリー（日本語）
本論文は、現代のクラウドネイティブインフラにおいて不可欠な「インメモリ鍵値データストア」の進化、特に Redis の代替候補としてのValkey、KeyDB、Garnetを、Kubernetes 環境下で現実的なワークロードを用いて体系的にベンチマーク評価した研究です。Redis のライセンス変更（RSALv2/SSPLv1 への移行）に伴うオープンソースコミュニティへの影響を背景に、これらの代替システムの性能、互換性、持続可能性を包括的に分析しています。
1. 研究の背景と課題 (Problem)
- Redis のライセンス変更: Redis は過去 10 年間のデファクトスタンダードでしたが、ライセンスの変更により、オープンソース原則を重視する組織やコミュニティでの採用に懸念が生じています。
- 代替システムの台頭: Redis の代替として、Linux Foundation が主導するValkey（Redis のフォーク）、マルチスレッド化されたKeyDB、Microsoft Research 開発のGarnet（.NET ベース）が登場しました。
- 既存研究の不足: 現在の文献には、これらの最新ツールを現実的なワークロード（特にクラウドネイティブ環境）で実験的に評価したものが不足しており、ベンダー発表のベンチマークに依存している傾向があります。また、単純な性能だけでなく、移行の複雑さ、運用互換性、長期的な持続可能性を総合的に評価した研究が欠如していました。
2. 研究方法論 (Methodology)
本研究は、再現性が高く、生産環境に近い条件での評価を目指しました。
- 実験環境:
- プラットフォーム: Kubernetes (Kubeadm v1.31.5, Ubuntu 24.04 LTS)。
- 構成: 4 vCPU / 12GB RAM のリソース制約下で、各システムをスタンドアローンモードでデプロイ。
- 対象システム: Redis v7.2.7, Valkey v8.0.2, KeyDB v6.3.4, Garnet v1.0.62。
- ベンチマークツール:
- memtier_benchmark: Redis 評価のデファクトスタンダードツールを使用。
- ワークロード設計: 現実的なトラフィックを模擬するため、Zipfian 分布（一部の「ホットキー」へのアクセスが偏る分布）を採用。
- 書き込み重視 (Write-Heavy): 50% SET / 50% GET, スケュー係数 α=0.9。
- 読み込み重視 (Read-Heavy): 5% SET / 95% GET, スケュー係数 α=1.4。
- メモリ圧力: 8GB メモリに対し、約 75% 利用率（約 480 万キー）まで事前にデータをロードし、空のメモリ状態での評価を避けた。
- 評価指標:
- スループット（TPS）、P99/P999 レイテンシ（テールレイテンシ）、CPU 効率、メモリ効率。
- 統計的有意性検定（t 検定）を用いて結果の信頼性を確保。
3. 対象システムのアーキテクチャ比較
| 特徴 |
Redis |
Valkey |
KeyDB |
Garnet |
| スレッドモデル |
シングル |
シングル（I/O 多スレッド化） |
マルチ |
マルチ |
| Redis API 互換性 |
100% |
100% |
95% |
70% |
| ライセンス |
RSALv2/SSPLv1 |
BSD-3 |
BSD-3 |
MIT |
| 開発活動 |
高 |
高 (Linux Foundation) |
低 |
中 (Microsoft) |
| 特徴 |
標準 |
高性能 I/O、RDMA 実験的サポート |
マルチコア活用、FLASH ストレージ |
.NET ベース、ロックフリー構造 |
4. 主要な結果 (Key Results)
A. スループット性能
- Garnet: 全コンカレンシーレベルで最高性能を記録。書き込み負荷では Redis より最大108%、読み込み負荷では**110%**高いスループットを達成。
- Valkey: Redis より**15%〜38%**の向上（負荷が高いほど改善率大）。I/O マルチスレッド化の効果が顕著。
- KeyDB: modest な改善（8%〜15%）にとどまり、マルチスレッド化によるオーバーヘッドが性能向上を相殺している可能性あり。
B. レイテンシ（P99/P999）
- Garnet: P99 レイテンシが Redis より40-55% 低く、テールレイテンシ（P999）も安定している。
- Valkey: 読み込み負荷では Garnet に匹敵する低レイテンシを示すが、書き込み負荷の高負荷時では若干劣化。
- KeyDB: 負荷が高まるにつれレイテンシのばらつき（P999）が大きくなり、スレッド競合の問題が示唆される。
C. リソース効率（CPU/メモリ）
- Garnet: 同等のスループットを達成するために、Redis より30-40% 少ない CPU、25-30% 少ないメモリで済む。.NET のメモリ管理最適化が寄与。
- Valkey: CPU 効率で 15-20%、メモリ効率で 8-10% の改善。
- KeyDB: 性能向上は限定的であるにもかかわらず、マルチスレッド構造によりCPU 使用率が 10-15% 増加し、リソース効率が悪化。
D. 移行と運用の観点
- Valkey: 100% API 互換性により、コード変更なしで「ドロップインリプレイスメント」が可能。Linux Foundation によるバックアップもあり、長期的な持続性が高い。
- Garnet: 70% の互換性のみ。高度な機能を使用する既存システムからの移行には大幅なリファクタリングが必要。
- KeyDB: 95% 互換性だが、開発活動が停滞しており、長期的なメンテナンスリスクが高い。
5. 論文の貢献と意義 (Contributions & Significance)
- 包括的な独立評価: ベンダー発表ではなく、Kubernetes 環境下で標準化された手法を用いた、Redis 代替システムの最初の体系的な比較評価を提供。
- トレードオフの明確化: 単なる性能数値だけでなく、「性能」「互換性」「持続可能性」「移行コスト」の間のトレードオフを定量的に示した。
- 実用的な推奨事項:
- 既存システムの移行: Valkeyが最適（互換性が高く、性能向上も得られるため）。
- 新規の高パフォーマンスプロジェクト: Garnetが有力（リソース効率とスループットが圧倒的に優れるため）。
- KeyDB: 開発停滞とリソース効率の悪さから、本番環境での採用は推奨しない。
- クラウドネイティブへの示唆: 計算リソースコストが支配的なクラウド環境において、Garnet のような高効率システムは、移行コストを数ヶ月で回収できる可能性があることを示した。
結論
本論文は、Redis のライセンス変更後のインメモリストア市場において、Valkeyが既存システムからの移行先として最もバランスの取れた選択肢であり、Garnetがリソース効率と性能を最優先する新規プロジェクトの有力候補であることを実証しました。一方、KeyDBは開発の停滞とリソース効率の課題により、慎重な検討が必要であると結論付けています。