Posted inデータベース

Valkey：ライセンス変更後のインストール・設定・Redisからの移行ガイド

Database tutorial - IT technology blog
Database tutorial - IT technology blog

RedisのコストがついにValkeyへの移行を決断させた日

2024年3月。チームが定例のインフラレビューを進めていた最中に、ある知らせが届いた。Redis Ltd.がRedisのライセンスをBSDからデュアルライセンス（RSALv2およびSSPL）に変更したというのだ。Redisをセルフホスティングしている小規模なチームのほとんどにとって、この変更は大きな影響をもたらさなかった。しかし、我々は小さなチームではなかった。SaaSプラットフォームを構築していた我々にとって、突然リーガルチームが「SSPLが自社プロダクトにどういう意味を持つのか」という厄介な質問を投げかけてきた。

それから6ヶ月後、開発・ステージング・本番の3環境すべての移行が完了した。本記事では、実際に効果があったこと、うまくいかなかったこと、そして最初から知っておきたかったことを余すことなく紹介する。

Redisライセンス変更で実際に何が起きたのか

簡単に言うと、Redis Ltd.は大手クラウドプロバイダー（AWS、Azure、GCP）がRedisから多大な利益を得ながら、プロジェクトへの貢献が乏しいと感じていた。その解決策として、2018年にMongoDBが採用したのと同じSSPLへの切り替えを選んだ。SSPLは実質的に、Redisをサービスとして提供するあらゆる企業にスタック全体のオープンソース化を義務付けるものだ。

SSPLは意図的に広範な解釈ができるよう設計されている。Redisが商用プロダクトの一部として組み込まれている場合、法務チームはその使用がSSPLの条項に触れるかどうかを判断するのに何週間も費やすことになる。このあいまいさには現実のコストが伴う。エンジニアリング上の意思決定が滞り、弁護士費用が発生し、結局は移行を余儀なくされる。Redis 7.2.xはBSDライセンス下での最後のバージョンであり、それ以降はすべて新ライセンスに移行している。

既存の選択肢がうまくいかない理由

Redis 7.2に永久に留まることは、深く考えるまでは魅力的に思える。しかし、セキュリティパッチ、新しいデータ構造機能、クライアントライブラリの互換性はいずれも前進し続ける。7.2で止まると、スキップするリリースサイクルごとに技術的負債が積み重なっていく。そのサイクルは止まらない。

Valkeyが登場する以前に存在した代替選択肢も検討したが、どれも完全にフィットするものはなかった。

  • Memcachedは正真正銘のBSDライセンスで高速だが、純粋なキーバリューキャッシュに過ぎない。我々はリーダーボードにソート済みセット、イベントキューにストリーム、リアルタイム通知にpub/subを多用していた。Memcachedへの移行はアプリケーションロジックの大規模な書き直しを意味する。
  • KeyDBはRedisからフォークしてマルチスレッドを追加したものだ。Snapchatが買収してオープンソース化したが、その後は静かなままだ。リリースは不定期で、コミュニティの活動も少なく、重要な依存関係として賭けるには不安が残った。
  • Dragonflyは内部的に根本的に異なるアプローチを採用しており、データ構造レイヤーを再設計してより優れたメモリ効率を謳っている。紙の上では有望だが、当時はまだ新しく、Redisコマンドの互換性にギャップがあり、アプリケーション側の変更が必要になる箇所があった。

このライセンス変更と既存の代替手段の限界が重なったことが、Linux Foundationが素早く動いた理由だ。

Valkeyと他の選択肢の比較：なぜValkeyを選んだのか

Valkeyはライセンス変更直後に、BSDライセンスの最後のリリースであるRedis 7.2.4からフォークされた。現在はLinux Foundationが管理しており、AWS、Google、Oracle、Ericssonがアクティブなコントリビューターとして参加している。このガバナンスモデルこそが重要な点だ。単一のベンダーがロードマップを支配しない。

オプション ライセンス API互換性 コミュニティ
Redis 7.4+ RSALv2/SSPL 完全 大規模、ベンダー主導
Valkey 8.x BSD 3-Clause 完全 (7.2) 成長中、財団支援
KeyDB BSD ほぼ完全 小規模
Dragonfly BSL 1.1 部分的 小規模
Memcached BSD なし 安定、最小限

ドロップイン置き換え、活発な開発、BSDライセンス、SSPLの曖昧さのない財団支援のガバナンス。この組み合わせが、我々の議論をあっという間に終わらせた。

Valkeyのインストール

Ubuntu/DebianでAPTを使ってインストール

curl -fsSL https://packages.valkey.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/valkey-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/valkey-archive-keyring.gpg] https://packages.valkey.io/apt $(lsb_release -cs) main" \
  | sudo tee /etc/apt/sources.list.d/valkey.list

sudo apt update && sudo apt install valkey -y
sudo systemctl enable valkey --now

# 確認
valkey-cli PING  # PONGが返れば成功

Docker Compose（実際に使っている方法）

services:
  valkey:
    image: valkey/valkey:8
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - valkey_data:/data
      - ./valkey.conf:/usr/local/etc/valkey/valkey.conf
    command: valkey-server /usr/local/etc/valkey/valkey.conf

volumes:
  valkey_data:

設定

Valkeyは既存のRedisと同じ設定フォーマットを読み込む。既存のredis.confがあれば、valkey.confにリネームしてValkeyに指定するだけで、一切編集せずに動作する。本番環境の設定は以下のようになっている。

# メモリ
maxmemory 2gb
maxmemory-policy allkeys-lru

# 永続化 — RDB + AOF
save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

# セキュリティ
requirepass 強力なパスワードをここに入力
bind 127.0.0.1

# パフォーマンス
tcp-backlog 511
hz 10
lazyfree-lazy-eviction yes

Redisからの移行：3つのアプローチ

方法1：RDBダンプ（計画メンテナンスウィンドウに最適）

RedisとValkeyは7.x系で同じRDBフォーマットを共有している。これは非本番環境で使用した方法だ。

# Redisサーバーでバックグラウンドセーブを実行
redis-cli BGSAVE

# 完了時刻を確認
redis-cli LASTSAVE

# 新しいValkeyサーバーにダンプをコピー
scp /var/lib/redis/dump.rdb user@new-server:/data/valkey/dump.rdb

# Valkeyを起動（ダンプは自動的に読み込まれる）
sudo systemctl start valkey

# キー数が一致することを確認
valkey-cli DBSIZE

方法2：レプリケーションベース（ゼロダウンタイム）

アップタイムSLAがメンテナンスウィンドウを許可しない場合は、まずValkeyをRedisプライマリのレプリカとして起動する。これが本番環境の切り替えに使用した方法だ。

# Valkeyサーバー上で既存Redisのレプリカとして参加
valkey-cli REPLICAOF redis-primary-ip 6379

# レプリケーションが追いつくまで監視
valkey-cli INFO replication
# 確認事項：master_sync_in_progress:0 および master_link_status:up

# アプリの接続文字列をValkeyに向ける
# その後ValkeyをプライマリにPromote
valkey-cli REPLICAOF NO ONE

# 旧Redisをシャットダウン
sudo systemctl stop redis

方法3：選択的なキー移行（クリーンアップに有効）

移行は古くなったキーを引き継がずに整理する良い機会でもある。

#!/bin/bash
# 特定のキーパターンをRedisからValkeyに移行
# 注意：大規模データセットではブロッキングを避けるためにKEYSをSCANに置き換えること
REDIS_HOST="old-redis-host"
VALKEY_HOST="new-valkey-host"

for key in $(redis-cli -h $REDIS_HOST KEYS "session:*"); do
  ttl=$(redis-cli -h $REDIS_HOST TTL "$key")
  dump=$(redis-cli -h $REDIS_HOST DUMP "$key")
  if [ "$ttl" -gt 0 ]; then
    valkey-cli -h $VALKEY_HOST RESTORE "$key" $((ttl * 1000)) "$dump"
  else
    valkey-cli -h $VALKEY_HOST RESTORE "$key" 0 "$dump"
  fi
done

アプリケーション側の変更点

Pythonでredis-pyを使用している場合、変更が必要なのはホスト名だけだ。

# 変更前
import redis
client = redis.Redis(host='old-redis-host', port=6379, password='secret')

# 変更後 — ホスト名だけを変更
import redis
client = redis.Redis(host='valkey-host', port=6379, password='secret')

# または、明示的な依存関係としてvalkeyパッケージをインストール
# pip install valkey
import valkey
client = valkey.Valkey(host='valkey-host', port=6379, password='secret')

valkey Pythonパッケージはredis-pyのメンテナンスされたフォークで、APIは完全に同一だ。ioredisやnode-redisを使うNode.jsユーザーも同様だ。接続文字列を更新するだけで完了する。

一つ注意が必要なのは、redis-cli PINGを呼び出しているモニタリングスクリプトやヘルスチェックをvalkey-cli PINGに切り替える必要があることだ。バイナリ名は変わったが、コマンド自体は変わっていない。

6ヶ月後：実際に確認できたこと

メモリ使用量は我々のワークロードでRedis 7.2と比較して約5〜8%低い。Valkey 8.0のI/Oスレッド改善は、pub/subを多用するサービスで計測可能な差をもたらした。マルチコアサーバーでのスループットが向上し、我々の側での設定変更は一切不要だった。

コマンド互換性は、使用しているすべての機能において完璧だった。文字列、ハッシュ、ソート済みセット、ストリーム、pub/sub、Luaスクリプティング、トランザクション。6ヶ月間の本番トラフィックを通じて非互換性はゼロだった。

移行中、デプロイスクリプトを更新するためにCSV形式の設定エクスポートをJSONに変換する必要があった。そのためにtoolcraft.app/ja/tools/data/csv-to-jsonを使用した。完全にブラウザ上で動作するため、設定データがマシンの外に出ることはない。機密情報を見知らぬWebサービスに貼り付けることができないインフラ作業に便利だ。

3つの環境全体を通じた合計時間はおよそ2日間だった。そのほとんどはテストとモニタリングダッシュボードの更新に費やされ、実際のデータ移動ではなかった。各環境のデータ移行は1時間以内に完了した。レプリケーションベースの本番環境切り替えはゼロダウンタイムで実現できた。

Valkeyはあなたの環境に適しているか？

Redis 7.2以前をセルフホスティングして商用プロダクトを構築している場合、弁護士に指摘される前にSSPLの問題に先手を打っておこう。Valkeyは明確な道筋を提供している。同じAPI、活発なメンテナンス、BSDライセンス、そして単一のベンダーに支配されないガバナンスだ。

すでにRedis EnterpriseやElastiCacheのようなライセンス処理済みのマネージドサービスを利用している場合、移行コストは正当化されないだろう。そのままで問題ない。しかし、商用プロダクトでセルフホスティングのオープンソースRedisを使っている場合、Valkeyが最も直接的な出口となる。1週間の統合作業を見込んでいたが、実際には環境ごとに半日程度で済んだ。

Share:
Tags: