ハクソク

世界を動かす技術を、日本語で。

Valkeyが1周年を迎えました：Redisのコミュニティフォーク

360日前原文(gomomento.com)

概要

  • Redisのソースクローズ を契機に、コミュニティ主導で誕生した Valkey の1年目の成果
  • Valkey 8.1 が Redis 8.0 を実ベンチマークで上回る性能を達成
  • I/Oスレッドやコア割り当て などの最適化手法の詳細解説
  • ベンチマーク再現方法や パフォーマンスチューニングの実践例 を紹介
  • Momento社 による支援体制と今後への展望

Valkey誕生とRedisコミュニティの分岐

  • Redis Inc がソースコードをクローズし、コミュニティとの信頼関係に亀裂
  • Valkey がRedisからフォークされ、オープンソース文化の継承を目指す動き
  • Salvatore Sanfilippo（Antirez） のRedis復帰とRedis 8.0の再オープンソース化
  • SSPL採用によるコミュニティとの関係悪化、コントリビューション減少の課題
  • Valkey が分裂ではなく、協調と進化の象徴として機能

Valkey 8.1 vs Redis 8.0：性能比較

  • AWS Graviton4 c8g.2xlarge（8 vCPU） でベンチマーク実施
  • Valkey 8.1.1 が 999.8K RPS（SET）/ 0.8ms p99レイテンシ を記録
  • Redis 8.0 は 729.4K RPS（SET）/ 0.99ms p99レイテンシ に留まる
  • SETで37%高いスループット、GETで16%高いスループット をValkeyが実現
  • p99レイテンシ もSETで30%、GETで60%以上高速化

I/Oスレッドとマルチスレッド化による進化

  • Redis/Valkeyはシングルスレッド という誤解の払拭
  • I/Oスレッド を6本有効化で、Valkeyは 239K → 678K RPS へ大幅向上
  • p99レイテンシ も1.68msから0.93msへ短縮
  • Redisも同様に 235K → 563K RPS、p99レイテンシ1.35ms→0.84ms
  • 3スレッド以上 から効果が顕著、4スレッド以降はValkeyが大きくリード

コア割り当てとIRQ最適化による更なる高速化

  • Rezolus でCPU使用率やIRQ割り込みの偏りを可視化
  • IRQを2コアにピン止め し、残り6コアにValkey/Redisを割り当て
  • Dockerの--cpuset-cpus でプロセスのコア固定を実現
  • クロスコア競合低減・キャッシュローカリティ向上 でレイテンシ最小化
  • この最適化により 832K → 999.8K RPS へスループット向上

ベンチマーク再現方法とチューニングのポイント

  • AWS Graviton4 c8g.2xlarge （8 vCPU）と c8g.8xlarge （32 vCPU）を使用
  • EC2プレースメントグループ（クラスターモード） でネットワークジッタを最小化
  • コア割り当て・IRQ数削減 によるパフォーマンス向上
  • 接続数調整 が重要（Valkeyは400接続でベスト、1024接続以上でレイテンシ急増）
  • キー空間・アイテムサイズ を現実的な値（1KB, 3Mアイテム）で設定
  • ベンチマークツールのマルチスレッド化 も効果的（--threads 6）

ベンチマークの限界と今後の展望

  • valkey-bench は最大負荷を与える設計、現実的なTPSターゲットや負荷変動には未対応
  • SET:GET比率 の調整やスパイク再現など、より現実的なシナリオが今後の課題
  • Momento社ではrpc-perfを活用 し、より実運用に近い検証を推進
  • ベンチマーク結果はあくまで一例、 本番環境では小さな差異が大きな影響

パフォーマンスは継続的な実践

  • ValkeyはRedisを凌駕する新たな基準 を提示
  • パフォーマンス最大化には システム・インフラ・ワークロードの総合的な知見 が不可欠
  • Momento社 はValkey、Redisのパフォーマンスチューニング支援を提供
  • リアルタイムインフラの最適化 を目指す企業へのサポート体制

謝辞・著者紹介

  • IOP SystemsのYao氏とBrian氏、rpc-perfやrezolusのツール提供に感謝
  • Khawaja Shams （Momento CEO/Co-Founder）：AWS DynamoDBやメディアサービス、NASAでの実績
  • チーム・ビジョン・実行力 を重視したリーダーシップ

Redis/Valkeyの最新動向 や 高パフォーマンス化 に関心のある方は、Momento社までご相談を。

Hackerたちの意見

valkeyをデフォルトのディストリビューションパッケージマネージャーに入れてほしいな。キーを追加したり、ディストリビューションを更新してvalkeyをインストールするのが面倒なんだよね、例えばGitHub Actionランナーで。

└

どのディストリビューションに必要なの？ https://repology.org/project/valkey/versionsをざっと見た感じ、nixpkgs、Arch、Ubuntu、Fedora、Debian、EPELには入ってるみたいだね。その中で、Debianは13か12+backportsでしか手に入らないのがちょっと気になるかな。

└

ちなみに、Arch LinuxではvalkeyがRedisの代わりになったよ。

俺はRedisを何十個ものアプリで使ってるんだけど、ValkeyがAWSで割引価格になったときはめっちゃワクワクしたんだ。2ヶ月前にやっと試してみたら、すごく順調だった。パフォーマンスに目立った違いもなかったし。ところが、Valkeyが突然ダウンしちゃったんだ。AWSはまだ動いてると思ってたみたいだけど、完全にオフラインになってた。復旧するのに12時間以上かかって、また同じことが起きた… AWSは2週間調査しても原因がわからなかった。今後、重要なことにValkeyを使うのはかなり時間がかかりそう。結局、そのValkeyを同じ負荷の下でRedisに置き換えたら、問題は全くなくなったよ。

└

それってAWSの運用問題じゃない？Valkeyのせいだとはすぐに思わないけど、俺はRedisしか使ってないし。

└

自分のValkeyで新しいインスタンスを立てればいいじゃん？

└

参考までに、どのインスタンスタイプを使ってたの？

└

おそらくAWSの問題だね。数ヶ月前、うちの本番環境のRDS Postgresクラスターがそうなった。ネットワークで全く反応しなくなったんだ。ヘルスチェックは問題なかったのに。AWSサポートはほとんど役に立たなくて、1時間経っても解決できなかった。エンタープライズサポートの最上級プランを持っていたのにね。お客さんがダウンしてたから、新しいクラスターを作ってバックアップから復元する羽目になった。これに4時間かかった。RDSはもうなくなったよ。今はEC2インスタンスがいくつかあって、レプリケーション、毎時のEBSスナップショット、毎日のS3へのバックアップをしてる。以来、AWSの「カプセル化された」サービスを使うのが嫌になった。

ちょっと気になるんだけど、HashiCorpがTerraformのライセンスを変更したときにOpenTofuが企業スポンサーを集めたのに、Valkeyはどうしてそこまで行かなかったの？HashiがBSLに変えたときのコミュニティの反応に比べて、あんまり意味のある反応を見てない気がする。

└

おそらく、Terraformの価値は常にプロバイダーやモジュールのコミュニティにあったからだと思う。それが危険にさらされていたんだよね。一方で、Redis/Valkeyのエコシステムは主に支持者と満足しているユーザーが中心になってる。アーキテクチャの中心になるかもしれないけど、以前のオープンソース版を使うことが大きな問題を引き起こす可能性は低いと思う。BUSLのTerraformに関しては、既存のプロバイダーとの互換性を壊すような大きな変更があったら、HashiCorpの新しい不利な条件に縛られることになるからね。

└

ValkeyってLFに支持されてるんじゃないの？ライセンス変更に不満を持ってるRedisの顧客の要望でそうなったのかも。

└

ValkeyにはAmazon、Oracle、Google、Percona、Ericssonなどたくさんの企業スポンサーがいるよ。Linux Foundationの下にあって、そこからサポートやカバレッジを受けることができる（しかもそれ自体もさらに多くの大企業にスポンサーされてる） https://valkey.io/participants/

└

「Valkeyは、HashiCorpがTerraformのライセンスを変更したときにOpenTofuが得たような企業スポンサーをなぜ獲得していないのか、気になる。」 それ、完全に情報がキャッチアップできてないよ。ValkeyはAWS、Google Cloud、Oracleなどに支えられてるんだ。確か、AWSの主任エンジニアがこのプロジェクトを先導してたはず。 https://valkey.io/participants/

これが起こって、まだ元気に続いてるのが嬉しい。さようならRedis（早くそうなってほしい）。

└

そうそう、金儲けは悪いよね。オープンソースは独占企業のためだけに存在する。Redisから何百万も稼ぐのはAWSやハイパースケーラーだけがふさわしい。Redisの作者やメンテナーなんてどうでもいい。DBスタートアップへの教訓：ライセンスは公平にしよう。ハイパースケーラー対策の条項をライセンスに入れて、収益を上げて持続可能でいる能力を守ろう。顧客にはコードへの無制限アクセスを許可してもいいけど、AWSやGoogleが管理版を提供できないようにしないと。彼らにはお金を払わせるべきだよ。RedisやElasticsearchになってはいけない。彼らはもう手遅れだ。超緩和的になってしまって、今や運命が決まってしまった。彼らは巨人たちにとって数億ドルの現金牛になってしまったけど、主要なコミッターはその恩恵を受けていない。

antirezがRedisを（実際に）オープンソースに戻すって発表したんじゃなかったっけ？ https://antirez.com/news/151 もしそうなら、潮流を変えるには手遅れすぎるのかな？Node.jsは短命のIo.jsフォーク時代の後、ほぼ崩壊しそうだったけど、コミュニティが修復したよね。Redisでも同じことが可能かな？昔はよく使ってたけど、ここ数年は使ってないから、この二つのプロジェクトのコミュニティについては同じ視点を持てないんだ。

└

もしそうなら、潮流を変えるには手遅れすぎるのかな？私もそう思う。少なくとも私にとっては、Redisの rug pull がRedisを完全に排除することを強制したし、これからはValkeyがデフォルトの選択肢になると思う。騙されたら恥はあなたに。

└

それに、RedisはAGPLでオープンソース化されているけど、ValkeyはBSDライセンス（昔のRedisと同じ）なんだよね。どちらも公式のオープンソースライセンスだけど、BSDの方がずっと緩いんだ。

└

彼らがやったことを考えると、どうしてまたRedisを信じられるの？

└

最後に確認したとき、RedisはまだCLAを持ってたよ。つまり、彼らは再びクローズドソースに戻る権利を独占的に保留してるってこと。寄稿者がその条件に同意することを求めている限り、また同じことをする可能性があるから信じる理由がないよね。

└

正直言って、99%のユーザーはプロジェクトの所有者なんて気にしてないと思うよ。無料のKVストアにデータを入れられればそれでいいんだ。ビジネスの観点から見ると、Redisはすごく微妙な立ち位置にあって、50種類くらいのことができるけど、ほとんどの人はそのうちの5%しか使わないし、SentinelやStreamsみたいな高機能なものを使う気もないんだよね。さらに厄介なのは、どんなソフトウェアツールでもお金を取ろうとすると、ユーザーの選択肢は「Redisをやめる」か「お金を払う」だけじゃないってこと。「競合に乗り換える」「必要な機能だけで自分で書き直す」「OSSプロジェクトなら最後のオープンソース版をフォークして、自分でメンテする」って選択肢もある。Redisは多くのビジネスユーザーにとって、フォークしたり自分で作ったりする方が好まれる超微妙な位置にいる気がする。Postgresよりもずっとね。だって、Redisの安くて簡単なバージョンは「ただの」ハッシュマップにネットワークインターフェースがついてるだけだから。

いつものことだけど、GPLに関するFUDが出てくると思う。これがいい説明だよ。 https://drewdevault.com/2024/04/19/2024-04-19-Copyleft-is-no...

└

コピーレフトライセンスがより自由だっていう主張は、せいぜい曖昧な感じだね。文字通りの意味で、義務は自由に対する制限だから、そういう意味ではコピーレフトライセンスは許可制のものより自由度が低いよ。義務の全体的な利点が自由に対する制限を上回るかどうかは議論する価値があるけど、どのライセンススタイルがより自由かっていう質問には関係ないね。

Redisが方向転換した今、ValkeyとRedisが話し合って、合併して協力する価値はないの？

最近、いくつかのdotnetプロジェクトが商業化されてるんだ。なんか詐欺にあった気分。これって他のオープンソースのdotnetライブラリにとってはダメージだと思う。開発者がそれらを採用しづらくなるから、 tractionを得るのが難しくなるんだよね。

└

特に.NETの場合、それは最近のことじゃないよ。 .NETビジネスはずっとフリーウェアやオープンコアに隣接してきたんだ。

ValKeyがI/Oスレッドの分野で素晴らしい仕事をしてくれて嬉しいし、最近最も面白い変更を取り入れ始めたよ。ValKeyの貢献者たちに大感謝！でも、この記事はちょっと誤解を招くかもね。>「Antirezの共有なしアーキテクチャへのこだわりはRedisの基盤となっている。」とはいえ、2020年にはRedisがI/Oスレッドのサポートを追加したんだ。残念ながら、最近まで大きな改善はなかったけど。以前にI/Oスレッドを試してみてダメだった人は、再評価する時かも！実は、2020年にI/Oスレッドを実装したのもAntirezなんだ。共有なしの理由を壊さないからこそ実装したんだよ。I/Oスレッドが何をするかっていうと、イベントループから戻った時に、write(2) / read(2)のシステムコールがすごく遅いことを認識して、その瞬間は競合がゼロだから、NスレッドでそのI/Oを並列化して、すぐにシングルスレッドに戻すってこと。だからこのシステムを実装して、ValKeyの人たちがさらに良くしてくれたんだ（再度感謝！）。でも、当時このシステムが機能しなかったわけじゃないし、今改善されたのはこの記事のグラフを見ればわかるよね… これらの投稿が誰かにお金をもらって書かれてるのか気になるな。Redis側にも似たような意味不明な投稿があって、同じようにクソだし、ランダムなことを喋ってる。マジで… こんなジャーナリズムは本当に迷惑だよ。とにかく、これらのことがRedisの会社自体やAmazon、Googleにとっては面白いけど、普通のRedisユーザーにはほとんど関係ないってのが、機能があまり使われない理由なんだ。多くのRedisユーザー、特に大規模なユーザー（人気のあるソーシャルネットワークの数値を覚えてる）なんかは、RedisのCPU使用率が低すぎて気にしないんだよね。ところで、スレッドについては、合う時もあるよ。最近のRedisの新しいベクタセットデータ型を見てみて。クエリはデフォルトでスレッド化されてるし、VADD（ベクタセットへの書き込み）もスレッド方式で使えるんだ。なんで考えを変えたかって？HNSWは巨大な定数時間を持つ最初のデータ構造だから、Redisにはそんなのなかったし、デザインスペースが考慮する価値があるものになったからなんだ。だから2020年にはすでにスレッドに前向きだったし、過去にはモジュール操作のためにスレッドサポートを実装してたし、今はベクタセットもスレッド化されてる。賛成か反対かじゃなくて、状況次第だね。

└

ありがとう、antirez。ニュアンスはクリックされないからね。