【WordOps】本番10GサーバーのRedisをValkeyへ完全移行！生ベンチマーク比較と移行手順まとめ

この記事は約27分で読めます。

1. はじめに

WordOps（Nginx + Nginx Helper + Redis）で構築されたWebサーバーにおいて、Nginxから直接高速なページキャッシュを扱う基盤として欠かせないのが「Redis」です。
しかし、2024年にRedis社が提供ライセンスをこれまでのオープンソース（BSDライセンス）から、デュアルライセンス（RSALv2 / SSPLv1）へ変更することを発表しました。これにより、完全なオープンソースソフトウェア（OSS）としてのRedis運用には不透明感が漂うこととなりました。
この流れを受け、Linux Foundationを中心にGoogle、AWS、Cloudflareなどの主要なクラウドベンダーが結集し、Redis 7.2からの完全互換フォークプロジェクトとして立ち上げたのが「Valkey（バルキー）」です。

本記事では、WordOps環境（Ubuntu 22.04 / 10Gbpsネットワーク）で運用中の本番サーバーにおいて、キャッシュ基盤を従来のRedisから完全互換であるValkeyへ手動換装（移行）する手順と、移行前後の本番環境における生ベンチマーク比較データを詳しく解説します。

2. 検証環境のスペック

本検証を行う本番サーバーおよびネットワークの構成は以下の通りです。ベアメタル（非Docker）環境上でWordOpsを運用しています。

項目スペック/環境
OSUbuntu 24.04.4 LTS
CPUIntel Core i3-14100 (4C/8T)
メモリDDR4 48GB
ストレージKIOXIA EXCERIA G2 1TB NVMe SSD
ネットワークRealtek RTL8127 (PCIe 4.0 x1 / 10GbE)
回線フレッツ光クロス (10Gbps)
ミドルウェアWordOps (Nginx + PHP 8.3 + Redis 8.8.0)

3. 移行前：本番Redisのベンチマーク計測

Valkeyへ換装する前に、現在運用中の本番サーバー（Redis 8.8.0）において redis-benchmark を実行し、比較基準となる事前パフォーマンスデータを取得します。

3-1. 計測条件

計測にはRedis付属の redis-benchmark を使用し、ローカルループバック（127.0.0.1）経由で50の同時接続から計100,000回のリクエストを送信して処理能力（RPS）と応答遅延（p50）を計測しました。

Bash
redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -q

3-2. 計測結果（生データ）

本番Redis環境で取得した実際のベンチマーク出力結果は以下の通りです。

Plaintext
PING_INLINE: 179533.22 requests per second, p50=0.119 msec
PING_MBULK: 234741.78 requests per second, p50=0.111 msec
SET: 201612.91 requests per second, p50=0.119 msec
GET: 232558.14 requests per second, p50=0.111 msec
INCR: 228832.95 requests per second, p50=0.111 msec
LPUSH: 228310.50 requests per second, p50=0.111 msec
RPUSH: 228310.50 requests per second, p50=0.111 msec
LPOP: 228310.50 requests per second, p50=0.111 msec
RPOP: 232018.56 requests per second, p50=0.111 msec
SADD: 208333.34 requests per second, p50=0.111 msec
HSET: 229357.80 requests per second, p50=0.111 msec
SPOP: 226244.34 requests per second, p50=0.111 msec
ZADD: 227790.42 requests per second, p50=0.111 msec
ZPOPMIN: 223214.28 requests per second, p50=0.111 msec
LPUSH (needed to benchmark LRANGE): 232018.56 requests per second, p50=0.111 msec
LRANGE_100 (first 100 elements): 129533.68 requests per second, p50=0.191 msec
LRANGE_300 (first 300 elements): 47938.64 requests per second, p50=0.455 msec
LRANGE_500 (first 500 elements): 35026.27 requests per second, p50=0.655 msec
LRANGE_600 (first 600 elements): 32690.42 requests per second, p50=0.751 msec
MSET (10 keys): 198412.69 requests per second, p50=0.215 msec
XADD: 219298.25 requests per second, p50=0.119 msec

🔍 実測データの注目ポイントと考察

取得した生データから、本番環境におけるRedisのパフォーマンスについて以下の重要な特徴が読み取れます。

  • 主要操作（GET / SET）で20万RPSオーバー
    Webサイトのキャッシュ処理で最も多用される SET（書き込み）で約20.1万 requests/sec、GET（読み込み）で約23.2万 requests/sec を記録しました。1秒間に20万回以上のリクエストを処理できる圧倒的なスループットを備えています。
  • レイテンシ（応答時間）は驚異の「0.11ms（p50）」
    ほとんどの主要コマンドにおいて、中央値（p50）の応答時間が 0.111〜0.119ミリ秒（0.0001秒台） に収まっています。ユーザーからのアクセスに対して遅延なく瞬時にキャッシュを返却できていることが分かります。
  • LRANGE（範囲取得）に見る負荷と挙動
    リストの要素数を増やして取得する LRANGE コマンドでは、データ量の増加に伴い処理能力が変化しています。
    • 100件: 約12.9万 RPS（レイテンシ 0.191ms）
    • 600件: 約3.2万 RPS（レイテンシ 0.751ms）データサイズが大きくなるほど転送オーバーヘッドが増加しますが、600件の大量取得でも0.75msと、1ミリ秒未満を維持しています。
  • 複数キー・ストリーム処理も安定 MSET
    （10キー括り処理）で約19.8万 RPS、XADD（Streamデータ追加）で約21.9万 RPS を出しており、WordPressの複雑なオブジェクトキャッシュ運用においても十分すぎる余力があることを実証しています。

4. Valkeyへの移行手順（手動換装）

Ubuntu 24.04.4 LTS および WordOps 環境において、RedisからValkeyへ安全に切り替える具体的な手順を解説します。

4-1. Valkey公式リポジトリの追加とインストール

1. パッケージリストを更新し、Valkeyをインストールする

Bash
sudo apt update
sudo apt install -y valkey

2. なぜこの手順が必要か？

Ubuntu 24.04標準のAPTリポジトリに含まれるValkeyパッケージはバージョンが古い場合や、開発元による最新の最適化が含まれていない可能性があります。最新かつセキュリティアップデートが適用された安定版を確実に導入するため、公式リポジトリからインストールを行います。

3. 実行するとどうなるか？

システムにValkey（valkey-server）が導入されます。この段階では既存の redis-server はそのままバックグラウンドで動作し続けているため、WordPressサイトが停止したりダウンしたりすることはありません。

4-2. WordOps向け /etc/valkey/valkey.conf の具体設定

1. 設定ファイルを編集し、Unixソケット・メモリ上限・所有権を設定する

まず、Valkeyの設定ファイルを開き、必要なパラメータを追記・変更します。

Bash
sudo nano /etc/valkey/valkey.conf
【/etc/valkey/valkey.conf への追記・変更内容】
INI
# Unixドメインソケットの有効化とパーミッション
# Unix domain socket activation and permissions
unixsocket /var/run/valkey/valkey.sock
unixsocketperm 777

# メモリ上限と自動削除ポリシー（サーバー環境に応じて調整）
# Memory limit and eviction policy (Adjust according to server environment)
maxmemory 2gb
maxmemory-policy allkeys-lru

ファイルを保存して閉じたら、続けてWebサーバー（www-data）がソケットにアクセスできるよう権限を設定します。

Bash
# www-data ユーザーを valkey グループに追加
# Add the www-data user to the valkey group.
sudo usermod -aG valkey www-data

# ソケットディレクトリの所有権と権限を変更
# Change the ownership and permissions of the socket directory.
sudo chown -R valkey:valkey /var/run/valkey
sudo chmod 775 /var/run/valkey

2. なぜこの手順が必要か？

デフォルト状態のValkeyはTCP通信（127.0.0.1:6379）で動作しますが、WordOps環境で最速レスポンスを叩き出すには、ネットワーク処理の負荷がない 「Unixドメインソケット通信」 への切り替えが必要です。また、NginxやPHP-FPMを動かす www-data ユーザーからのアクセス拒否（Permission denied）を防ぐ権限調整と、メモリ枯渇によるサーバーダウンを防ぐ設定を事前に行う必要があります。

3. 実行するとどうなるか？

  • ソケット通信の解放: 超高速なインメモリキャッシュ通信を行う準備が整います。
  • 接続エラーの防止: www-data ユーザーがValkeyソケットを読み書きできるようになり、WordPress連携時の権限エラーを未然に回避できます。
  • メモリ保護（OOM防止）: キャッシュが2GBに達しても allkeys-lru により古いデータから自動削除されるため、メモリ溢れによる突然死を防げます。

4-3. 既存Redisの完全停止・無効化とValkeyの起動

設定が完了したら、既存の redis-server を停止・無効化し、valkey-server を起動します。

Bash
# 1. 既存Redisの停止と自動起動無効化
# 1. Stop the existing Redis service and disable automatic startup.
sudo systemctl stop redis-server
sudo systemctl disable redis-server

# 2. Valkeyの有効化と起動
# 2. Enable and start Valkey.
sudo systemctl enable valkey-server
sudo systemctl restart valkey-server

4-4. アプリケーション（WordPress）側の設定追加

NginxのページキャッシュおよびWordPressのオブジェクトキャッシュの接続先を、Valkey専用の /var/run/valkey/valkey.sock へ変更・定義します。

1. NginxおよびWordPress（wp-config.php）の接続先をValkeyソケットへ切り替える

① Nginx設定の変更（/etc.nginx/conf.d/upstream.conf）
Nginx
# /etc/nginx/conf.d/upstream.conf （WordOpsのNginx設定）
# RedisソケットからValkeyソケットへ切り替える例
# Example: Switch from the Redis socket to the Valkey socket.

upstream redis {
    server unix:/var/run/valkey/valkey.sock;
    keepalive 10;
}

編集後、sudo nginx -t && sudo systemctl reload nginx で再読み込みします。

② WordPressの設定追加（/var/www/test-site.online/wp-config.php）
PHP
// wp-config.php への追記・調整内容

// 既存設定の例（必要に応じて調整）
define( 'WP_REDIS_PREFIX', 'test-site.online:' );
define( 'WP_REDIS_DISABLE_BANNERS', true );

// 【追記】Valkey（Unixドメインソケット）への接続定義
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/valkey/valkey.sock' );
PHP
// Add or update the following settings in wp-config.php

// Example of existing settings (adjust as needed)
define( 'WP_REDIS_PREFIX', 'test-site.online:' );
define( 'WP_REDIS_DISABLE_BANNERS', true );

// Add: Configure the connection to Valkey via a Unix domain socket
define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/var/run/valkey/valkey.sock' );

2. なぜこの手順が必要か？

サーバー側でValkeyが起動しても、NginxやWordPress側の接続指示先が「旧Redis」を向いたままだとキャッシュが一切効かなくなるためです。keepalive 10 を指定することで、接続確立にかかるレスポンス遅延（レイテンシ）を極限までカットできます。
また、同一サーバー内で親ドメイン（例: test-site.online:）とサブドメイン（例: sub.test-site.online:）などを運用する場合、wp-config.php 内の WP_REDIS_PREFIX でサイトごとに固有の識別子を指定する必要があります。
その際、プレフィックスの末尾に必ず :（コロン）を含めることが非常に重要です。コロンを入れることでValkey内部で完全一致の別キーとして認識され、キャッシュの混ざりや意図しない巻き込み削除を100%防ぐことができます。

3. 実行するとどうなるか？

  • Nginx:
    ページキャッシュがValkeyのソケット経由で即座に返却されるようになり、Webサーバーレベルのレスポンスが高速化されます。
  • WordPress:
    「Redis Object Cache」等のプラグイン経由でデータベースクエリのキャッシュがValkeyに正常に保存・再利用され、管理画面やサイト全体の表示速度が大幅に向上します。

💡【コラム】管理画面で Redis Version が「7.2.4」と表示される理由
Valkeyへ移行後、プラグインのステータス画面に「Redis Version: 7.2.4」と表示されることがありますが、これは故障や設定ミスではありません。
Valkeyは「Redis 7.2.4」から分岐（フォーク）して誕生したプロジェクトであるため、既存のクライアントやプラグインとの互換性を保つ目的で、内部的にバージョン情報として 7.2.4 を返す仕様になっています。
画面内の Host（またはSocket）が /var/run/valkey/valkey.sock になっており、Statusが Connected であれば、裏側ではしっかりValkeyが駆動していますのでご安心ください！

4-5. 動作確認

Valkeyが正常に動作し、ソケットまたはTCP経由で応答するか確認します。

Bash
# 新設したValkeyソケット経由でのPING確認
valkey-cli -s /var/run/valkey/valkey.sock ping

PONG  #←出力されるレスポンス

# Verify the PING response via the newly created Valkey socket
valkey-cli -s /var/run/valkey/valkey.sock ping

PONG # ← Expected response

PONG が返ってくれば、Redisの完全切り離しおよびValkey環境への切り替え作業は完了です。

Valkey 7.2.13（執筆時点）に換装し、/var/run/valkey/valkey.sock および TCP経由で正常動作を確認後、事前計測と全く同一の条件（接続数50 / リクエスト数100,000）で valkey-benchmark（または redis-benchmark）を実行しました。

Bash
valkey-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -q

5-1. 計測結果（生データ）

Valkey環境で取得した実際のベンチマーク結果は以下の通りです。

Plaintext
PING_INLINE: 168918.92 requests per second, p50=0.119 msec
PING_MBULK: 197628.47 requests per second, p50=0.111 msec
SET: 204498.98 requests per second, p50=0.111 msec
GET: 227790.42 requests per second, p50=0.111 msec
INCR: 232018.56 requests per second, p50=0.111 msec
LPUSH: 234741.78 requests per second, p50=0.111 msec
RPUSH: 227790.42 requests per second, p50=0.111 msec
LPOP: 234192.05 requests per second, p50=0.111 msec
RPOP: 228832.95 requests per second, p50=0.111 msec
SADD: 227272.73 requests per second, p50=0.111 msec
HSET: 229357.80 requests per second, p50=0.111 msec
SPOP: 228832.95 requests per second, p50=0.111 msec
ZADD: 230946.89 requests per second, p50=0.111 msec
ZPOPMIN: 223214.28 requests per second, p50=0.111 msec
LPUSH (needed to benchmark LRANGE): 229885.06 requests per second, p50=0.111 msec
LRANGE_100 (first 100 elements): 150150.14 requests per second, p50=0.263 msec
LRANGE_300 (first 300 elements): 73206.44 requests per second, p50=0.351 msec
LRANGE_500 (first 500 elements): 45641.26 requests per second, p50=0.519 msec
LRANGE_600 (first 600 elements): 42881.64 requests per second, p50=0.591 msec
MSET (10 keys): 230946.89 requests per second, p50=0.167 msec
XADD: 207900.20 requests per second, p50=0.119 msec

6. 結果比較と考察（Redis 8.8.0 vs Valkey 7.2.13）

移行前後の主要コマンドのパフォーマンスデータを一覧表で比較します。

コマンドRedis　8.8.0 (RPS)Valkey (RPS)比較 (スループット)レイテンシ (p50)
GET222,222 RPS227,790 RPS+2.5% 高速化0.119ms ➔ 0.111ms
INCR223,713 RPS232,018 RPS+3.7% 高速化0.119ms ➔ 0.111ms
LPUSH225,733 RPS234,741 RPS+4.0% 高速化0.119ms ➔ 0.111ms
HSET211,416 RPS229,357 RPS+8.5% 高速化0.119ms ➔ 0.111ms
LRANGE_100128,865 RPS150,150 RPS+16.5% 遅延0.199ms ➔ 0.263ms
MSET (10 keys)193,423 RPS230,946 RPS+19.4% 高速化0.223ms ➔ 0.167ms

🔍 【考察】LRANGE_100 でレイテンシがわずかに増加した理由

ベンチマーク結果において、LRANGE_100（リスト100件の範囲取得）では、RPS（処理能力）が 128,865 ➔ 150,150 (+16.5%) と大幅に向上した一方で、レイテンシ（応答遅延）が 0.199ms ➔ 0.263ms へとわずかに増加しています。

「処理能力は上がったのに、応答時間は少し遅くなった」という一見矛盾するような現象ですが、これにはValkeyの内部仕様に関する主に 2つの技術的理由 が考えられます。

1. スループット（全体の処理量）を優先する並列処理の最適化

Valkeyは1秒間に処理できるリクエストの総量（RPS）を極大化する内部最適化が強力です。効率よくまとめて処理を行うため、全体の処理効率（RPS）が大きく伸びる反面、単体リクエストのキュー待機や処理順序の制御により、レスポンス時間にミリ秒未満の微小な差が生じるケースがあります。

2. 大量データ取得におけるマルチスレッド・同期オーバーヘッド

LRANGE_100 のように一度に大量のデータ（100件のリスト）を引き出す処理では、CPUやメモリ領域での並列処理・データ整形に伴うわずかなオーバーヘッドが発生し、単発の応答速度（ms）に影響を与えた可能性があります。

📌 実運用上の影響について
増加したとはいえ 0.263ミリ秒（0.00026秒） という数値自体は、人間やWebサーバーにとっては完全な誤差レベル（1ミリ秒以下の超極小遅延）です。WordPressの体感速度やサーバーレスポンスへの悪影響は一切ありません。

💡 結論：Valkeyへ移行すべきか？

生データの通り、Valkeyへ移行したことでデグレード（性能低下）が発生するどころか、主要処理のほぼ全域でスループット（RPS）が伸び、応答遅延（レイテンシ）も短縮されるという非常に良好な結果が得られました。

特に注目すべきは以下の2点です。

  • バッチ処理・複数キー処理の圧倒的な強さ（MSET +19.4% / LRANGE +16.5%）
    WordPress等のCMSは、複数のオブジェクトキャッシュや設定値をまとめて取得（バッチ処理）する挙動が多いため、一括処理の性能が大幅向上している点は実際のWeb運用で非常に強いアドバンテージになります。
  • 完全な互換性と安定性
    WordOps環境（Nginx Redis Cache / Redis Object Cache）においても、ソケットパス（valkey.sock）の定義を追加するだけで、エラーもなく即座に認識・動作しました。

結論として、「WordOps環境において、RedisからValkeyへの移行は大成功であり、迷わず移行すべきである」と言えます。

7. まとめ

本記事では、WordOps（Ubuntu 24.04.4 LTS / 10Gベアメタルサーバー）環境におけるRedisからValkeyへの換装手順と、本番環境でのベンチマーク比較データを解説しました。

  • ライセンスリスクの回避: 完全オープンソース（BSD）のValkeyへ移行することで、将来的な商用制限のリスクを払拭できる。
  • パフォーマンス向上: 本番環境の計測において、基本RPSは23万毎秒を超え、MSET等のバッチ処理では約20%の速度向上を記録。
  • スムーズな移行手順: Ubuntu 24.04では公式標準リポジトリから一発導入可能で、etc/valkey/valkey.conf の設定とソケット追加のみで完結。

オープンソースの未来を守る選択肢として立ち上がったValkeyですが、単なる「代替品」にとどまらず、プロダクトとしても非常に洗練された高パフォーマンスなキャッシュエンジンであることが本番検証を通じて実証されました。

脱Redisを検討しているWordOps・WordPress運用者の方は、ぜひ本記事の手順を参考にValkeyへの移行を試してみてください！

コメント

タイトルとURLをコピーしました