Redisライセンス変更後のValkey移行｜本番キャッシュ層の互換性検証と段階切り替え計画

なぜ今、ValkeyへのRedis移行が現場課題になっているのか

2024年3月、Redisは従来のBSD系ライセンスからSSPL（Server Side Public License）とRSAL（Redis Source Available License）のデュアルライセンスへと移行しました。SSPLはクラウドプロバイダーがサービスとして提供する場合にソース公開義務を課す条件を含むため、OSIによるオープンソース認定を受けていません。この変更を受けてAWS・Google Cloud・Azureといった主要クラウドが独自のRedis互換フォークへの切り替えを開始し、Linux Foundationが主導するコミュニティフォーク「Valkey」が2024年3月に発足しました。

Valkeyは発足後の開発ペースが速く、2025年末時点で8.x系がリリースされており、Redis 7.2系との高い互換性を維持しながら独自の性能改善も取り込んでいます。AWSのElastiCache・MemoryDBがValkey対応を標準化し、Ubuntuの公式パッケージにもValkeyが収録されるようになった2026年時点では、新規構築でRedis OSS版を選ぶ理由は実質的になくなりつつあります。一方で既存の本番環境を抱える運用担当にとって「いつ・どのように切り替えるか」の判断材料が整理されないまま先送りになっているケースも少なくありません。本稿では、互換性の確認ポイントから段階切り替えの手順、切り戻し準備まで一連の流れを整理します。

互換性の実態：何が使えて何が変わったのか

ValkeyはRedis 7.2系のコードベースをフォーク元としているため、RESP2/RESP3プロトコル・既存のコマンドセット・AOFおよびRDBの永続化形式について高い互換性があります。一般的なキャッシュ用途（SET/GET/EXPIRE/TTL/INCR/HSET系・Pub/Sub・Sorted Sets）は移行後も変更なしに動作します。Redisクライアントライブラリ（StackExchange.Redis・jedis・go-redis・ioredis等）もそのまま接続先をValkeyに向けるだけで動作するものがほとんどです。

ただし注意が必要な領域もあります。RedisModules（RedisSearch・RedisJSON・RedisTimeSeries等）はValkey本体には含まれておらず、これらに依存したアプリケーションはモジュール互換の代替手段を個別に検討する必要があります。Redisの商用機能（Redis Cluster Proxyやエンタープライズ向けのActive-Activeレプリケーション等）は当然ながら対象外です。また、Redis 7.4以降に追加されたコマンドや動作変更については、Valkeyのバージョンとの対応関係を個別にリリースノートで確認することを推奨します。

移行前に確認すべきチェックリスト

• アプリケーションがRedis Modulesに依存していないか（MODULE LISTコマンドで確認）
• 使用中のクライアントライブラリのバージョンがValkeyと接続確認済みか
• Redis Clusterモードを使用している場合、クラスタ構成の移行手順を別途立案しているか
• AOF/RDBの永続化データを引き継ぐ場合、バージョン間のファイルフォーマット互換性を確認しているか
• 監視ツール（Prometheus exporterや既存のモニタリング設定）がValkey対応済みか

段階切り替え計画：本番ゼロダウンタイムを目指す構成

本番キャッシュ層の切り替えで現場がよく採る手法は「シャドーモード＋段階的トラフィック移行」です。一度に全トラフィックを切り替えるのではなく、Valkey環境を並走させながら動作確認を重ねることでリスクを分散します。

フェーズ1：Valkey環境の並走構築

まずRedis本番環境とは別にValkeyインスタンスを構築します。Ubuntuであれば公式パッケージからapt install valkeyでインストールできます。設定ファイルはRedisのredis.conf形式と互換性があるため、既存の設定をベースに接続ポートや最大メモリ設定を調整するだけで起動できます。

この段階ではアプリケーションからは既存のRedisを参照したまま、バックグラウンドでredis-cli --pipeやredis-cli --rdbを使ったスナップショット転送でデータをValkeyへ同期します。本番トラフィックには影響しません。

フェーズ2：ステージング環境での動作検証

アプリケーションのステージング環境の接続先をValkeyに向けて、実際のワークロードパターンを再現します。このフェーズで確認すべき主な観点は以下の通りです。レスポンスタイムの変動・コマンドのエラー率・TTL/Expireの動作・Pub/Subのメッセージ配信遅延、そしてメモリ使用量の推移です。特にメモリ効率はValkey 8.x系でlistpack最適化が強化されており、同じデータ量でも使用メモリが削減されるケースがあります。この差分を監視ベースラインの更新として記録しておくことが後工程に役立ちます。

フェーズ3：本番トラフィックの段階移行

ステージングでの検証が完了したら、本番切り替えをトラフィック比率で段階的に行います。アプリケーション側でキャッシュ接続先を環境変数や設定ファイルで切り替えられる構成であれば、10%→30%→100%のようにロールアウトできます。ロードバランサーやサービスメッシュ（Envoy/Istio等）でバックエンドの重み付けができる環境では、さらに細かい制御が可能です。

各段階で最低1〜2営業日のモニタリング期間を設け、キャッシュヒット率・エラーレート・P99レイテンシを基準値と比較します。異常が検出された場合はトラフィックを戻せる状態を維持したまま次の段階へ進むことが重要です。

切り戻し計画と運用上の注意点

本番移行後に予期しない挙動が発覚した場合に備えて、元のRedis環境をすぐに戻せる状態を最低1週間は維持することを推奨します。Valkeyが書き込んだRDBファイルはRedis 7.2と互換性があるため、AOF無効の構成であれば最後のRDBスナップショットからRedisへの復元も現実的な選択肢です。ただしValkeyで追加・変更されたデータはスナップショット取得時点以降のものが失われる点に注意が必要です。キャッシュ層であれば多くの場合キャッシュミスによる再生成で対応できますが、セッションストアやレートリミットカウンターとして使用している場合は影響範囲を事前に洗い出しておく必要があります。

また、Valkeyデフォルトの設定値にはRedisと異なる点がいくつかあります。bindのデフォルト動作・protected-modeの初期値・ログ出力形式などが該当します。既存の監視ダッシュボードやアラートルールがRedis固有のメトリクス名（redis_*系）を参照している場合は、Valkey用のexporterへの切り替えとメトリクス名の変更対応が必要になります。prometheus-redis-exporterはValkey対応を明示しているバージョンを使用してください。

2026年時点での環境差分と今後の動向

2026年時点では、主要ディストリビューションのパッケージリポジトリへのValkey収録が進んでいます。Ubuntu 24.04 LTSの公式リポジトリにはValkey 7.2系が、24.10以降ではValkey 8.x系が含まれています。Debian sidにも収録済みで、RHEL/Rocky系では公式ではないものの非公式リポジトリ経由での導入が一般的になっています。

マネージドサービス側の動向では、AWSのElastiCache for RedisがValkey対応エンジンを選択できるようになり、新規作成時のデフォルト候補として扱われるケースが増えています。GCP MemorystoreもValkey対応を追加しています。既存のマネージドRedisインスタンスからの移行パスについては各クラウドプロバイダーのドキュメントで確認が必要ですが、多くの場合スナップショットリストアによる移行手順が用意されています。

Valkey自体の開発コミュニティはLinux Foundation傘下で継続的に活発な状態にあり、8.x系では読み取りスループットの改善・マルチスレッドI/Oの拡張・TLS関連の強化が主なトピックとなっています。Redis本体（商用版）との機能差が今後どう広がるかは不確定ですが、汎用キャッシュ・セッションストア・Pub/Sub用途に限定すれば、現時点でのValkeyの完成度は本番投入に十分なレベルに達しています。ライセンスリスクを排除しながらOSSエコシステムとの継続的な連携を維持したい運用環境にとって、Valkeyへの計画的移行は2026年以降の標準的な選択肢の一つといえます。