Valkey 1周年：コミュニティフォークはいかにRedisを追い抜いたのか

 (gomomento.com)
8 ポイント 投稿者 GN⁺ 2025-06-01 | 4件のコメント | WhatsAppで共有
  • Redis Inc はソースクローズド化（SSPL への移行）の決定でコミュニティの信頼を揺るがしたが、Valkey フォークを中心に開発者コミュニティが結集し、活発なイノベーションと貢献が続いている
  • Redis 8.0 は再びオープンソースに戻り、創設者 Antirez が復帰して新機能や最適化に参加するなど、両陣営とも急速な発展を見せている
  • 最新のベンチマーク結果では、Valkey 8.1.1 は 8vCPU 環境で SET 性能が Redis 8.0 比で 37% 高く、p99 レイテンシもより短いことが確認された（GET 性能も 16% 優位）
  • IO スレッド／コアピニングなどの実践的なチューニング手法により、Valkey はマルチスレッド環境で 3 倍以上のスループット向上とレイテンシ最小化を実現
  • 実運用に近いベンチマークやチューニングのノウハウも共有され、ベンチマーク結果を解釈する際の注意点と実際の運用環境への適用方法も案内している

Redisのソースクローズド化とValkeyの登場

  • 1年前、Redis Inc（旧 Garantia Data）が オープンソースライセンス変更（SSPL 導入）を行い、コミュニティとの信頼関係が悪化した
  • その解決策として誕生したオープンフォーク Valkey は、分散システム、キャッシュ、リアルタイムデータ処理などで広く使われる技術資産となった
  • Redis 側もその後、Antirez（創設者） の復帰、性能／機能強化、Redis 8.0 のオープンソース再移行などで信頼回復を試みている

Valkey 8.1 vs Redis 8.0：性能比較

  • 同一の 8vCPU AWS c8g.2xl インスタンス、1KB アイテム／3M キースペース／500 接続条件で SET ベンチマークを実施
    • Valkey 8.1.1: 999.8K RPS（p99 0.8ms）
    • Redis 8.0: 729.4K RPS（p99 0.99ms）
    • Valkey は SET で 37%、GET で 16% 高く、SET p99 は 30%、GET p99 は 60% 高速
  • 6 個の IO スレッド導入時、Valkey は 239K → 678K RPS（2.8倍↑）、p99 1.68ms → 0.93ms（44%↓）
  • Redis も IO スレッドで 235K → 563K RPS、p99 1.35ms → 0.84ms（40%↓）

マルチスレッド／コアチューニングの効果

  • IO スレッドは 3 個以上から効果が大きく現れ、Valkey は 4 スレッド以降で Redis より大きな差 を見せる
  • IRQ（割り込み）コアを 2 個に制限した後、Redis／Valkey を残りの 6 コアに固定（pinning）すると、さらに性能が向上
    • Valkey: 832K → 999.8K RPS（コア／IRQ ピニング、CPU 使用率 80%）
    • IRQ／アプリケーションコアの分離により、キャッシュ効率と tail latency を最小化
    • 実際に Docker で cpuset-cpus、--io-threads などを活用する例も提示

ベンチマーク再現と実践的なヒント

  • 最新の AWS Graviton4（c8g.2xlarge） インスタンス、cluster placement group を活用
  • コアピニング／IRQ 分離／接続数調整（400〜500 程度）で最大性能を実現
  • キースペース／アイテムサイズ の調整も必要で、小さな値／キースペースは L3 キャッシュのヒット率を高める
  • valkey-benchmark や rpc-perf（実利用により近い Rust ベースのツール）など、マルチスレッド対応ベンチマークツールの積極活用を推奨 
    docker run --network="host" --rm --cpuset-cpus="2-7" \  
valkey/valkey:8.0.1 valkey-benchmark \  
-h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
-r 3000000 --threads 6 -d 1024

性能測定の限界と注意点

  • ベンチマーク結果は実際の運用環境と異なる可能性がある

    • 実際のワークロードには SET:GET の混在、負荷変動、TPS ターゲット、ネットワーク遅延など複合要因がある
    • 接続数が急増すると、キュー遅延やスループット低下、tail latency 増加も観測される
    • ベンチマークツール／オプション、ネットワークトポロジーなどによって結果は大きく変わり得る

主な成長過程とコミュニティの発展

Valkey プロジェクトはこの 1 年間、さまざまな面で活発に進化してきた

  • GitHub などで 多くの開発者と企業の協業 のもと、機能追加、バグ修正、セキュリティ改善などを実現
  • ドキュメント整備やユーザー支援にも注力し、新規ユーザーの参入障壁を引き下げた
  • プロジェクト運営では 透明な意思決定 と コミュニティ投票 などが重視されている

業界における意義と技術的価値

Valkey には次のような強みがある

  • ライセンス制約なしで誰でも利用できるため、クラウドサービスベンダー や 大規模 Web サービス企業 にとって魅力的な選択肢となる
  • Redis と 高い互換性があり、移行も容易 である
  • コミュニティ主導で開発されているため、多様な要件を反映しつつ迅速で継続的なアップデートが可能

結論と示唆

  • Valkey は Redis フォークから 1 年で、技術・性能・コミュニティの各面で Redis を上回る成果を示した
  • IO スレッド、コア／IRQ 分離、接続数調整などの実践的なチューニングノウハウとツールが鍵となる
  • 性能は自動的についてくるものではなく、システム／ワークロード／インフラに合わせた継続的な最適化が不可欠
  • 実サービス環境ではベンチマーク数値だけに依存せず、多様な状況を自らテストする実務的アプローチが必要

関連記事

4件のコメント

 
ethanhur 2025-06-02

Redisは多くの誤った判断をしてきましたが、働いたのは熊なのに金を受け取るのは調教師、という構図になっているのは残念ですね。
 
kgcrom 2025-06-02

Facebookの「Redis User Group」に投稿された、
Valkey 8でどのような改善が行われたのかを整理した資料です。
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

上記の内容とあわせて読むと、理解の助けになると思います。
 
ndrgrd 2025-06-01

実際のところ、Valkey が何かを成し遂げたというよりは……向こうが勝手に自滅したという感じで……
 
GN⁺ 2025-06-01
Hacker Newsの意見
  • ValkeyがI/Oスレッディング分野で素晴らしい進歩を遂げたことをうれしく思うし、最近では最も興味深い変更点のいくつかも導入し始めている。Valkeyのコントリビューターの皆さんには大いに感謝したい。ただ、この文章はやや誤解を招きやすい傾向があると思う。もともとRedisではshared nothingアーキテクチャが非常に重要な哲学だったし、2020年に私自身がI/Oスレッディングを導入した当事者でもある。shared nothingの趣旨を損なわないようにしつつ、event loopから戻る際に write(2)/read(2) syscall が非常に遅くなり得ることを踏まえ、その時点でzero contentionの状態でI/OだけをN本のスレッドに並列化し、その後すぐにシングルスレッドへ戻る構造を導入した。Valkeyチームがこのシステムをさらに発展させてくれたことには感謝している。以前からこのシステムは機能していたし、実質的には変わっていない点をメディアが誇張する傾向には不快感がある。こうした機能は実際には、大多数の一般的なRedisユーザーよりも、エンタープライズ利用者やクラウドプロバイダー（Amazon、Googleなど）のほうが強く関心を持つものだ。極端な高負荷や多数ユーザーの同時処理が必要な場合でなければ、たいていRedisのCPU使用率は低く、わざわざ有効化する必要はないのが実情だ。最近Redisでvector set data type（ベクトル集合データ型）を開発するにあたり、スレッディングをデフォルトにしており、VADDによるベクトル集合への書き込みもスレッド方式で行えるようにしている。HNSWのようなデータ構造はRedis史上初めて巨大な定数時間を持ち、設計領域そのものが異なる。過去にはモジュール向けのスレッド対応もすでに実装したことがある。スレッドを使うかどうかは状況次第の判断だ。
    • 微妙な見解ではクリックを稼げないという事実に触れている
    • こういう種類の批判記事が毎月HNのトップに上がってくるように感じるし、私はいつもantirezを応援したくなる。技術的な要点には同意するが、こうした批判はしばしば具体的な内容というより、大きな成功を収めた人を攻撃する古典的なtall poppy syndrome（成功者を引きずり下ろす現象）に関係していると思う。他人の反応はコントロールできないのだから、こうした批判記事はあなたの業績が大きいことへの間接的な承認だと受け取るほうが健全かもしれない。LinkedInでつながっていることにも感謝している tall poppy syndromeを見る
  • antirezがRedisを再びオープンソース化すると発表していたのを覚えている 関連記事 以前Node.jsはIo.jsフォーク騒動でほとんど崩壊しかけたが、コミュニティが回復させた前例がある。Redisにもそうした回復が可能なのか気になる。以前はRedisをよく使っていたが、ここ数年のコミュニティ動向はあまり追っていない
    • 最後に確認した時点ではRedisは依然としてCLA（コントリビューターライセンス契約）を要求していた。つまり、いつでも再びソースを閉じる独占的権利を持っているということだ。コントリビューターがその条件に同意しなければならないのであれば、また同じことをしないと信頼する理由はない
    • RedisはAGPL、ValkeyはBSDライセンス（BSDは以前のRedisライセンス）で配布されている。どちらも正式なオープンソースライセンスだが、BSDのほうがはるかに自由度が高い
    • 正直、利用者の99%は誰が所有しているかなど気にせず、無料のキーバリューストアがきちんと動けばそれでいい。ビジネスの観点ではRedisは独特な位置にあり、非常に多くの機能を提供しているのに実際に使われるのは5%程度にすぎず、Sentinel/Streamsのような複雑な機能には関心もない。有料化しようとしたとき、ユーザーの選択肢は「単に使わない」「競合へ移行する」「本当に必要な機能だけ自作する」「最後のオープンソース版をフォークして自前で保守しコストを抑える」など多様にある。PostgreSQLと比べるとRedisの単純な版（ハッシュマップ+ネットワークインターフェース）は自作しやすく、そのため多くのビジネスではフォークするか自作するほうがより良い選択になる
    • 私も、もう手遅れ感があると思う。Redisの急激な方針転換によって、私にとってRedisはもはや信頼できない存在であり、今後はValkeyがデフォルトの選択肢だ。一度だまされたら二度は信じない
    • Redisが起こした件の後で、どうやって信頼できるのかという疑問を呈している
  • Valkeyは標準的なディストリビューションのパッケージマネージャーに入るべきだと思う。たとえばGitHub Action runnerでインストールしようとすると、毎回キーを追加してディストリビューションを更新するのが面倒だという不満がある
    • どのディストリビューションに入っていないのか気になる。repologyのデータを見る限り、nixpkgs、Arch、Ubuntu、Fedora、Debian、EPELなどにはすでに入っている。ただしDebianは13または12+backportsからだ
    • ちなみにArch LinuxではValkeyがすでにRedisを置き換えている
    • CIでコンテナイメージを取得した直後にあれこれインストールするのが最初の作業なら、自分でイメージを作るほうがよいという意見
  • こうした変化が起き、Valkeyが継続的にうまくいっているのはとてもうれしい。どうかRedisは早く消えてほしい
    • オープンソースは独占企業のためのものだ、という皮肉な調子で、AWSのようなハイパースケーラーはRedisで数億ドルを稼いでいるのに、実際の開発者やコントリビューターはその恩恵を受けていないという残念さを表明している。だからDBスタートアップは最初からフェアソース（anti-hyperscaler条項を含むライセンス）で始めるべきで、コード自体は誰でも自由に使えても、AWSやGoogleがマネージドサービスとして提供するなら対価を支払わせるべきだという。すでにuber permissiveなライセンスで始まったRedisやElasticsearchは、もはや後戻りが難しい運命にあると述べている
  • 最近はdotnetプロジェクトが商用化へ転じるケースが増えている。こうした変化は開発者にとって、まるでラグプル（信頼を壊す突然の方針転換）のように感じられる。この雰囲気は、他のオープンソースdotnetライブラリの普及にも悪影響を与える可能性がある
    • .NETではこの種の商業化傾向は最近の話ではなく、もともとfreeware/open-coreとビジネスが常に結びついてきた性質があると述べている
  • 去年からValkeyの名前を聞いていたが、今でも好調だという点がうれしい
  • Valkeyが独自のクライアントライブラリを提供しているのか気になる。現在GCP環境でMemoryStoreと自己管理環境の両方でRedis/Redis Clusterを使っており、公式CライブラリはRedis Cluster+TLSで期待外れだったため、hiredis-clusterという非公式クライアント（https://github.com/Nordix/hiredis-cluster）を使わざるを得ない。GCPのMemorystoreにもあまり満足していない。Scyllaへの移行も検討中だ
    • hiredisとhiredis-clusterを組み合わせたlibvalkeyという公式フォークがあり、既存のhiredis/hiredis-clusterメンテナーたちが管理している libvalkeyを見る
  • Redisが方針を変えた今、ValkeyとRedisが話し合って統合できるのか気になる
    • ライセンスが元に戻ったのではなくAGPLへ移行しただけなので、本当のUターンではないと指摘している
  • 予想されるGPL関連のFUD（恐怖・不確実性・疑念）についての優れた解説記事へのリンクが共有されている 関連記事
    • 投稿で、copyleftライセンスのほうがより自由だと主張するのはやや安易な論法だと考える。義務が増えるほど自由は減る性質があるため、どのスタイルがより「自由」なのかという議論はもっと掘り下げる余地があると思う
  • 私は数十のアプリケーションでRedisを使っている。AWSがValkeyを割引価格で提供しているので2か月前から試してみたが、性能差も感じなかった。ところがValkeyが突然ハングし、AWS上では依然として稼働中と認識されていたのに接続が完全に切れた。12時間以上復旧せず、その後また再発した。AWSが2週間調査しても原因を特定できなかった。今後Valkeyをミッションクリティカルな環境で使うのは難しくなった。その後、同じワークロードでRedisに置き換えたところ問題は起きていない
    • おそらくAWSの問題かもしれない。こちらでも本番のRDS postgresクラスタで似た経験があった。ネットワーク応答が止まり、AWSエンタープライズサポートも受けたが、最終的には自力でバックアップから新しいクラスタを復旧して作り直し、4時間かかった。その後はAWSのカプセル化されたサービスを避け、通常のEC2上でreplication、snapshot、S3レプリケーションなどへ移行した
    • AWS運用上の問題の可能性もあり、Redisしか直接動かしたことはないが、Valkey自体の問題ではないかもしれない
    • なぜ自分でValkeyインスタンスを立てないのか気になる
    • どのインスタンスタイプを使っていたのか知りたい、参考までの質問