Redis、Valkey、DragonflyDB:インメモリデータベースのモダンガイド
インメモリデータベースが当たり前になったのは、キャッシュ、セッションストア、軽量キュー、そして最近ではベクトル検索の基盤として使われるようになったからです。現代のアーキテクチャでインメモリデータベースを一つも持たないシステムを探す方が難しいかもしれません。
2024 年、Redis がライセンスを変更しました。これで状況が一気に動きました。Valkey と DragonflyDB という二つの代替が台頭し、どちらも Redis プロトコルとの互換性を保ちつつ、パフォーマンス、ライセンス、ハードウェアの使い方で異なるアプローチをとっています。
このノートでは、三つの違いを実用的に比較し、Spring Boot プロジェクトでコードを変えずに切り替える方法を紹介します。
Redis:業界標準
10 年以上、Redis はインメモリデータベースの事実上の標準でした。小さなサイドプロジェクトから高トラフィックのプラットフォームまで、どこでも使われています。
コアのデータ処理エンジンは、操作をシンプルかつアトミックに保つためにシングルスレッドのままです。ただし最近のバージョンでは、ブロッキング作業をオフロードするバックグラウンドスレッドと I/O スレッドが導入されています。
Redis 8.0 では、かつて「Redis Stack」として別途提供されていた機能が本体に統合されました。JSON サポート、時系列、そして Vector Sets(ベクトル検索)です。
ライセンスについては注意が必要です。現在は RSALv2、SSPLv1、または AGPLv3 のトリプルライセンスモデルになっています。つまり Redis はもう OSI 承認のオープンソースではありません。商用製品やマネージドサービスでの利用を検討する際は、法務チームと相談すべき領域です。
Redis を選ぶべきなのは、成熟したエコシステムと全言語対応のクライアントライブラリが必要な場合、公式のエンタープライズサポートが欲しい場合、そして AI や検索、JSON などの高度なモジュールを活用したい場合です。
Valkey:コミュニティの後継、真のオープンソース
Valkey は、最後の BSD ライセンス版 Redis(7.2.4)のフォークとして生まれました。Linux Foundation が支援し、AWS や Google がバックについています。
目標は明確です。完全にオープンな Redis 互換エンジンを提供し、コマンドとプロトコルの互換性を保ちながら、内部構造を改善する。
ライセンスは BSD スタイルを維持しています。OSI オープンソースに準拠しているので、企業ポリシーの壁に引っかかりません。
内部も手が入っています。ハッシュテーブルが CPU キャッシュに効くように再設計され、キーバリューペアごとに約 20 バイトのメモリを節約しています。Valkey 9.0 では Atomic Slot Migration が導入され、クライアント側にエラーが見えないままクラスターリバランスを最大 9 倍高速化できるようになりました。
Redis からの移行でドロップイン互換を探している場合、組織が 100% オープンソースを要求している場合、あるいはメモリ使用量を減らしてクラウドコストを削りたい場合。Valkey が魅力的な選択肢になります。
DragonflyDB:クラウド時代のためにゼロから作った
DragonflyDB は Redis のフォークではありません。現代のマルチコアハードウェアを完全に活用するために、ゼロから設計された新しいエンジンです。
アーキテクチャが特徴です。各スレッドが独自のデータシャードを所有する共有なし設計を採用しています。グローバルロックがなく、ボトルネックもない。そのため、単一マシンでの垂直スケーリングが非常に効率的にできます。
メモリ効率も良い。DragonflyDB の内部構造(Dashtable)は、キーのパターンに応じて従来の Redis と比較して 30% から 60% のメモリを節約できます。重い読み書きワークロードでは、Redis 展開と比較して最大 25 倍高速だと報告されています。
ライセンスは BSL(Business Source License)です。多くのシナリオで無料で使えますが、OSI 承認ではなく、競合するサービスでの利用には制限があります。
DragonflyDB が力を発揮するのは、テラバイト規模のインメモリデータを扱うとき、単一ノードで毎秒数百万回の操作が必要なとき、そしてピーク負荷を捌くために必要なインスタンス数を減らしたいときです。
実用比較
三つを並べて比較してみます。
エコシステムの成熟度では、Redis が圧倒的に先行しています。クライアントライブラリもツールも一番揃っている。Valkey は急速に成長しており、Redis のツールとの互換性も高い。DragonflyDB は若いですが、高性能ユースケースに焦点を絞っています。
ライセンスは三者三様です。Redis は RSALv2/SSPLv1/AGPLv3 のトリプルで、OSI 非対応。Valkey は BSD で真のオープンソース。DragonflyDB は BSL で、制限付きながら多くの場面で無料です。
スレッドモデルの違いがパフォーマンスの差を生みます。Redis はシングルスレッドコアにマルチスレッド I/O を組み合わせています。Valkey はシングルスレッドコアのまま非同期 I/O を改善した設計。DragonflyDB は真のマルチスレッドで、共有なし設計です。
ユースケースで言えば、Redis はエンタープライズサポートと高度モジュールが必要な重要なアプリに、Valkey はオープンソースとコスト最適化が優先の移行案件に、DragonflyDB は単一ノードで巨大ワークロードを捌く必要がある場面に適しています。
メモリ使用量は、Valkey がキーバリューペアごとに約 20 バイト節約し、DragonflyDB はシナリオによって 30〜60% の節約を実現します。Redis は効率的ですが、設計の限界があります。
Spring Boot統合
三つのエンジンはどれも Redis プロトコルを話します。つまり Spring Boot からの統合はほぼ同じに見えます。これが一番嬉しい点です。
pom.xml では標準の依存関係だけが必要です:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>application.properties(または application.yml)では、ホストを指すだけです:
# Redis、Valkey、DragonflyDBで同じように動作
spring.data.redis.host=localhost
spring.data.redis.port=6379シンプルなキャッシュサービスは、三つのエンジンすべてで全く同じコードになります:
@Service
public class CacheService {
@Autowired
private StringRedisTemplate redisTemplate;
public void saveData(String key, String value) {
// Redis、Valkey、DragonflyDBでのアトミック操作
redisTemplate.opsForValue().set(key, value);
}
}クライアントが Redis プロトコルを使う限り、Redis から Valkey や DragonflyDB への切り替えは URL の変更と、デプロイパラメータ(メモリ、CPU、永続化など)の調整だけで済むことが多いです。
プロジェクトでの選択方法
実用的な判断は、三つの軸で考えます。
ライセンスと企業ポリシー。組織が OSI 承認のオープンソースを要求するなら、Valkey が自然な選択です。すでに Redis と商用契約やサポートがあるなら、Redis のままがシンプルです。最大限のパフォーマンスを求め、BSL ライセンスを受け入れるなら、DragonflyDB は非常に魅力的です。
ワークロードパターン。中程度の負荷と安定したエコシステムが必要なら Redis で十分です。メモリあたりのコストが重要な環境では、Valkey と DragonflyDB が請求額を下げられます。単一ノードでの極端な負荷には DragonflyDB が主候補になります。
クラウド戦略。クラウドプロバイダーが各エンジンに対して提供するマネージドサービスを確認してください。インスタンス、サポート、ストレージ、ネットワークトラフィックを含めた総コストで評価します。
三つを料理に例えるなら、Redis は 15 年の評判がある老舗で、メニューが一番揃っていて誰もが知っているが、メインのシェフが一人なので混雑時には列ができる。Valkey は元のシェフたちが作った協同組合で、同じレシピを使いながら厨房を効率化し、入り口を無料で開いている。DragonflyDB は最新鋭の産業厨房で、複数の独立ステーションが並列に動き、一つの建物から都市全体に給仕できる設計です。
予算、負荷の規模、そしてサポートの要件で考えれば、選択はずっとシンプルになります。