2024年3月、長年にわたりWebシステムのキャッシュ、セッションストア、Pub/Subのデファクトスタンダードとして君臨してきた Redis が、そのライセンスモデルの劇的な変更を発表し、IT業界に大きな衝撃を与えました。
この決定を受け、Redisが守り続けてきた「中立で自由なオープンソース精神」を維持すべく、Linux Foundation主導で誕生した完全な代替フォークが Valkey です。
この記事では、Redisのライセンス変更の裏にある真実、誕生したValkeyが主要クラウド事業者（AWS, Google Cloud等）から熱狂的な支持を受ける理由、Redisとの技術的互換性、そして実務における移行プロセスと選定基準について徹底的に解説します。
1. Redisライセンス変更の衝撃とValkey誕生の真相#
Redisが2024年に発表したライセンスの変更は、長年愛されてきたオープンソースソフトウェア（OSS）のビジネスモデルにおける大きな転換点となりました。
何が変わったのか？：BSDライセンスから非OSSライセンスへの移行#
これまでの Redis は、商用・非商用を問わず極めて自由な改変・再配布が認められた「BSDライセンス」で提供されていました。しかし、Redis 7.4 以降は、以下の2つのデュアルライセンスへと移行しました。
- RSALv2 (Redis Source Available License v2): ソースコードの閲覧や改変は許可されるが、Redisの機能を直接用いた競合サービス（マネージドデータベースサービスなど）としての商用提供を禁止する。
- SSPLv1 (Server Side Public License v1): MongoDB社が開発したライセンス。プログラムをSaaSとして提供する場合、その管理ツールや周辺ネットワークコードを含むすべてのソースコードを同じオープンライセンスで公開することを義務付ける。
これらはOSI（Open Source Initiative）が定義する 「真のオープンソース」の定義に適合しない ため、実質的な「クローズドソース化（Source-Available化）」と受け止められました。
クラウドプロバイダとコミュニティの激怒#
AWSやGoogle Cloud、Microsoft Azureなどの巨大クラウドプロバイダは、自社で「Amazon ElastiCache」や「Google Cloud Memorystore」といったRedisのフルマネージドサービスを安価に提供し、多額の利益を得ていました。Redis社側の主張は「クラウド事業者がタダ乗りして利益を独占している」というものでしたが、クラウド事業者とOSS開発者コミュニティは、この急な商用ライセンス化に強く反発しました。
Linux Foundation による中立的フォーク「Valkey」の立ち上げ#
このライセンス変更からわずか数週間後、特定の企業の私有化を防ぎ、真のBSDライセンスを維持し続けるために、Linux Foundationの下でRedis 7.2.4からフォークされたプロジェクトが Valkey です。
AWS、Google Cloud、Oracle、Snap、Ericssonなどの業界の巨人たちが即座に開発の全面バックアップを表明し、中立なガバナンス体制の下で開発がスタートしました。
2. Redis と Valkey の技術的・組織的比較#
Valkeyは単なるRedisのフォークではなく、現在では独自のパフォーマンス改善や新機能の開発に着手しています。両者の構造的な違いは以下の通りです。
| 比較項目 | Redis (バージョン 7.4 以降) | Valkey (バージョン 7.2 / 8.0 以降) |
|---|---|---|
| 開発主導 | Redis Inc. (一企業による商業支配) | Linux Foundation (オープンコミュニティ) |
| ライセンス | RSALv2 / SSPLv1 (非オープンソース) | BSD 3-Clause (完全なOSS・商用自由) |
| 主要支援企業 | 自社および一部の独占ライセンス企業 | AWS, Google, Oracle, Snap, Ericsson等 |
| インフラの将来性 | 商用エンタープライズ機能の囲い込み | マルチスレッド処理の効率化、メモリ効率向上 |
| コマンド互換性 | 基準機能 | Redis 7.2系のすべてのコマンドと完全互換 |
3. 実務における移行ロードマップ：ドロップイン・リプレイスメントの実践#
Valkeyは既存のRedis環境から「ソースコードやクライアントライブラリを一切書き換えることなく、バイナリを差し替えるだけで動く（Drop-in replacement）」ことを最優先目標に掲げて開発されています。
具体的な移行プロセスは驚くほどシンプルです。
ステップ①：Docker環境での検証（イメージの差し替え）#
ローカル開発環境で Redis を動かしている場合、docker-compose.yml 内のコンテナイメージを書き換えるだけで移行が完了します。
Docker Compose の書き換え例#
# ❌ 旧 Redis 構成
# services:
# cache:
# image: redis:7.2-alpine
# ports:
# - "6379:6379"
# ✅ 新 Valkey 構成（そのまま差し替え可能）
services:
cache:
image: valkey/valkey:7.2-alpine
ports:
- "6379:6379"ステップ②：設定ファイルの互換性確認#
Valkeyは、従来の redis.conf 設定ファイルをそのまま読み込むことができます。起動時に指定する項目もRedisと全く同じです。
# 既存の redis.conf を使用して Valkey を起動可能
valkey-server /path/to/redis.confステップ③：CLI接続とクライアントライブラリの動作検証#
Valkeyには、従来の redis-cli に対応する valkey-cli が同梱されています。また、ポート番号もデフォルトで同じ 6379 を使用します。
Node.jsの ioredis や Python の redis-py、Goの go-redis などの一般的なアプリケーション用クライアントライブラリも、接続先のホスト名を Valkey のコンテナ/サーバーに向けるだけで、ライブラリのアップデートをすることなく完全に動作します。
# valkey-cli を用いた動作検証例
$ valkey-cli -h localhost -p 6379
localhost:6379> SET app_session "session_token_xyz"
OK
localhost:6379> GET app_session
"session_token_xyz"4. インフラエンジニアの視点：いつ Valkey に移行すべきか？#
「自社の本番システムを今すぐValkeyに移行させるべきか？」に対する、実務的な意思決定基準です。
現状維持（Redisのまま）で問題ないケース#
- クラウドのマネージドサービス（ElastiCache等）を利用している: AWSやGoogle Cloudは、既存の「ElastiCache for Redis」のサポートを継続しつつ、裏側でライセンス問題の影響を受けないバージョン管理を行っています。ベンダーがすべての保守とパッチ適用を巻き取っているため、ユーザーが今すぐ自前で移行作業を行う緊急性はありません。
- 現状のオンプレミス環境でバージョンアップの予定がない: すでに構築済みのRedis 6.x系や7.0〜7.2系をそのままホストし続ける限り、遡ってライセンス料を請求されることはありません。
即座に Valkey への移行・採用を検討すべきケース#
- 自社で Redis をビルド・セルフホストしている: Linuxサーバー上に自前でRedisをインストールしてキャッシュサーバーを構築している場合、今後の最新セキュリティパッチや機能アップデート（7.4以降）を適用しようとした際、非OSSライセンスの制限（監査の対象）に引っかかるリスクが生じます。これらを回避するため、中立な OSS である Valkey へのバイナリ切り替えを強く推奨します。
- 新規プロダクトの立ち上げ: 今後新しくインメモリデータベースを構築するのであれば、ベンダーロックインのリスクがなく、クラウド大手がこぞって将来の最適化（マルチスレッド化や省メモリ化）をコミットしている Valkey を最初から選定するのが最も賢明で持続可能な設計です。
5. よくある質問（FAQ）#
Q. Valkeyに移行することで、キャッシュのパフォーマンス（応答速度）は劣化しますか？#
A. いいえ、劣化しません。それどころか、Valkey 8.0以降では、主要クラウド事業者のコミッターたちによってマルチスレッドアーキテクチャの徹底的なチューニングが施されており、特定の並行処理シナリオにおいて従来のRedisと比較して約1.2倍〜2倍近くスループット（秒間クエリ処理数）が向上していることがベンチマークにより実証されています。
Q. Valkeyは将来的にRedisと互換性のない「独自コマンド」を増やしていきますか？#
A. 将来的にValkey独自の高度な拡張機能や新しいデータ構造（コマンド）が追加される可能性は高いです。ただし、基本理念として「Redisとの後方互換性」を極めて重視しているため、既存の基本的なキー操作コマンド（GET, SET, HGET, LPUSH 等）が廃止されたり、仕様変更されたりしてアプリケーションコードの書き換えが必要になる可能性は極めて低いです。
Q. Valkeyのクラスター構成（Valkey Cluster）は、Redis Clusterと同じように組めますか？#
A. はい、全く同じように組むことができます。クラスタリング用のコマンドやノード間のプロトコルも完全互換であるため、既存のRedis Clusterに対して1ノードずつ順次Valkeyノードに入れ替えていく（ローリングアップデート）ことも技術的に可能です。
