Valkey 8.1 対 Redis 8.2:ハイパースケールでのメモリ効率

5,000 万件のソート済みセットのベンチマークで、Valkey 8.1 は Redis 8.2 よりメモリ使用量が 28% 少ない結果になりました。実環境に近い大規模テストのスループットとメモリデータを紹介します。

Khawaja Shams headshot Khawaja Shams
挿入件数に対するメモリ使用量のグラフ

ペタバイト規模のストレージで 1 日に数億回の操作を扱うインフラでは、メモリのオーバーヘッドは 1 バイトでも重要です。ランキングや優先度付きキューの基盤となるソート済みセットは、特に影響を受けます。1 エントリーあたり数バイトの余分な負担が数 GB に膨らみ、使用効率を下げ、コストを増やし、ピーク時の応答性低下のリスクを高めます。

数百万人の World of Warcraft プレイヤーをリアルタイムで追跡する Raider.IO は、この現実に日々向き合っています。同社にとってメモリ効率は単なる付加価値ではありません。シーズンごとの急増を円滑に処理できるか、障害でプレイヤーの体験を損なうかを分ける要素です。

Valkey と Redis の最近の改善が Raider.IO のようなワークロードにどう影響するかを調べるため、ソート済みセットに 5,000 万項目を挿入し、負荷をかけながらメモリ使用量とスループットを測定して、Valkey 8.1 と Redis 8.2 を比較しました。

Valkey と Raider.IO について

Momento では、Valkey を Cache サービスの主要なストレージエンジンの一つとして運用しています。メモリ効率と予測可能な挙動に優れ、大規模なミッションクリティカルのリアルタイムワークロードに適しています。Valkey を基盤にすることで、顧客の運用を複雑にせず、高速で耐障害性と費用対効果に優れたキャッシュを提供できます。

その顧客の一つが、World of Warcraft プレイヤーに最も広く使われる補助サイト Raider.IO です。Raider.IO は数百万のキャラクターやギルドを追跡するランキングを運用し、ダンジョンやレイドの攻略のたびに更新します。そのため、ソート済みセットの操作は 1 日に数億回に達します。この環境では、停止や遅延は許容できません。Valkey の効率性と Momento のマネージドインフラ、運用の専門知識を組み合わせることで、ピーク負荷でもランキングの応答性を保てます。

課題:大規模環境でのメモリ効率

Redis と Valkey は、どちらも最近メモリ最適化を発表しました。Redis 8.2 は、キーと JSON のメモリ使用量を最大 67% 削減できる新しい表現形式を含む、14 を超える効率改善を導入しています。Valkey 8.1 は、キーあたりのオーバーヘッドを約 20~30 バイト削減する新しいハッシュテーブルを採用し、スループットを約 10% 向上させています。ランキングのワークロードでは、どちらが良い結果を出すでしょうか。

8 vCPU、16 GB RAM の AWS c8g.2xl(Graviton4)インスタンスを用意し、同じノードで Valkey 8.1.1 と Redis 8.2 を実行しました。Rust で書いた社内のベンチマークツールで、ソート済みセットに 25 万項目ずつ、合計 5,000 万項目を挿入しました。100 万件ごとにメモリ使用量(INFO MEMORY)、スループット、ZSET のサイズを記録しました。

メモリ使用量の推移は次のとおりです。

ソート済みセットへの挿入件数が 5,000 万に近づくにつれ、Valkey のメモリ使用量が Redis より緩やかに増えるグラフ。

結果:一貫したメモリ削減とスループット

Valkey は最初から少ないメモリで動作しました。100 万件の挿入時には、Valkey が約 80 MB、Redis が約 100 MB を使用しました。5,000 万件では Valkey が 3.77 GB、Redis が 4.83 GB で、差は 1.06 GB(28%)でした。この削減は、Valkey のキーごとのオーバーヘッド削減や、Valkey 8.1 への更新でほとんどのワークロードのメモリ使用量を最大 20% 減らせるという Linux Foundation の説明に沿っています。スループットも同様の傾向でした。初めは Redis が上回りましたが、Valkey は安定し、最終的に毎秒約 57 万件の挿入を維持した一方、Redis は約 53 万件まで低下し、約 7% の差となりました。

この差は実運用に影響します。28% のメモリ削減は、キャッシュノード数と運用費用の削減、ピーク時の拡大余地につながります。安定したスループットにより、数百万件を更新していてもランキングをすばやく更新できます。また、Valkey の滑らかな性能曲線により、容量計画が立てやすくなります。データセットが特定のしきい値を超えたときに、突然メモリ使用量が跳ね上がることを避けられます。

自分で試す

私たちは透明性と再現可能な結果を重視しています。ベンチマークはオープンソースで、Docker と Rust が入った Linux システムなら実行できるようにしています。

クイックスタート

ベンチマークでは Valkey と Redis を別々のポートで同時に動かし、同じハードウェア上で直接比較します。次の手順で再現できます。

1. Redis 8.2 を起動

docker run --network="host" --rm \
  --cpuset-cpus="2-7" \
  redis:8.2 \
  --save "" --appendonly no \
  --io-threads 6 --protected-mode no \
  --maxmemory 10gb

2. 別のターミナルで Valkey 8.1.1 を起動

docker run --network="host" --rm \
  --cpuset-cpus="2-7" \
  valkey/valkey:8.1.1 \
  --save "" --appendonly no \
  --io-threads 6 --protected-mode no \
  --maxmemory 10gb --port 6378

3. ベンチマークをクローンして実行

git clone https://github.com/momentohq/sorted-set-benchmark
cd sorted-set-benchmark
cargo run --release -- \
  --valkey 127.0.0.1:6378 \
  --redis 127.0.0.1:6379 \
  --step 1000000 --flush \
  --total 50000000 --batch 250000

25 万件ずつ合計 5,000 万項目を挿入し、100 万件ごとにメモリとスループットを測定します。結果は、両データベースのメモリ使用量と毎秒の操作数を示す表として出力されます。

設定上の注意

  • –cpuset-cpus=”2-7″:公平に比較するため、両データベースを同じ CPU コアに固定します。
  • –save “” –appendonly no:永続化を無効にし、メモリ性能を分離して測定します。
  • –io-threads 6:今回のテスト構成に合わせます(CPU 数に応じて調整してください)。
  • –maxmemory 10gb:テスト中の OOM を防ぎます(使用可能な RAM に応じて調整してください)。
  • –network=”host”:ベンチマークツールが両インスタンスに接続できるようにします。

Valkey のベンチマークで 100 万 RPS を超えるための調整については、こちらの記事をご覧ください。

推奨ハードウェア

今回のテストでは AWS c8g.2xl(8 vCPU、16 GB RAM)を使いましたが、次の条件を満たすシステムなら実行できます。

  • 4 コア以上の CPU
  • 8 GB 以上の RAM(5,000 万項目の完全なテストには 16 GB を推奨)
  • Linux(–cpuset-cpus フラグに必要)

小規模なシステムでは、–total を 1,000 万または 2,500 万項目に減らしてください。メモリ効率の違いは、どの規模でも一貫しています。

出力内容

ベンチマークはリアルタイムで進捗を出力し、完了すると実行中の情報をまとめた比較表を生成します。

5,000 万件のソート済みセットを使い、Valkey と Redis のメモリ、実行時間、スループットを比較したベンチマーク表。

ソート済みセットのワークロードや大量の処理を行うリアルタイムアプリケーションを運用している方は、ぜひご自身のハードウェアで試し、結果を共有してください。Valkey コミュニティに参加して、より良いインメモリデータストアを一緒に作りましょう。

あわせて読みたい