RedisからValkey 8への本番環境移行: 無停止レプリケーションとレイテンシベンチマーク

このガイドでは、ミッションクリティカルなRedis 7ワークロードをValkey 8へ移行する際の詳細を説明します。特に、ゼロダウンタイム戦略、パフォーマンス検証、および本番環境への準備に焦点を当てます。この移行の主な動機は、ライセンスに関する懸念（RedisのRSALv2/SSPLv1への変更）と、オープンソースでコミュニティ主導の代替手段を活用したいという要望であることが多いです。ValkeyはRedisのフォークとして、プロトコルの互換性を維持し、直接的なアップグレードパスを提供します。

アーキテクチャの概要と互換性

Valkey 8はRedis 7.2.4の直接的なフォークであり、完全なRESP（REdis Serialization Protocol）互換性を維持しています。これにより、Redis 7.x向けに設計されたクライアントライブラリは、Valkey 8インスタンスに対して修正なしで機能します。コアとなるデータ構造、コマンド、およびレプリケーションメカニズムは同じままです。主な相違点はライセンスモデル（ValkeyはBSD 3-Clause）と将来の開発の方向性です。

BSDライセンスへの準拠

ValkeyがBSD 3-Clauseライセンスに準拠していることは、許容的なオープンソースライセンスを必要とする組織にとって重要な要素です。これは、クラウドプロバイダーや商用再配布に制限を課す可能性のあるRedisのRSALv2/SSPLv1への移行とは対照的です。ほとんどのエンドユーザーにとって、機能的な影響は最小限ですが、法的コンプライアンスは最重要です。

移行戦略：ゼロダウンタイムレプリケーションロールオーバー

Redis 7からValkey 8へのゼロダウンタイム移行は、Redisのネイティブなレプリケーション機能を活用します。この戦略では、Valkeyを既存のRedisプライマリのレプリカとして設定し、データセットを同期させた後、Valkeyインスタンスを昇格させてトラフィックをリダイレクトします。

フェーズ1：Valkeyレプリカのセットアップ

1. Valkeyインスタンスのプロビジョニング: Valkey 8インスタンスをデプロイします。そのハードウェアリソース（CPU、RAM、ネットワークI/O）が、現在のRedisプライマリと同等以上であることを確認してください。

2. レプリケーションの設定: Valkeyインスタンスを既存のRedis 7プライマリからレプリケートするように設定します。これは、valkey.confでreplicaofディレクティブを設定するか、REPLICAOFコマンドを使用することで実現できます。

   bashCopy

   # valkey.conf snippet for replica
   # Replace with your Redis primary's IP and port
   replicaof <redis_primary_ip> <redis_primary_port>
   
   # If your Redis primary requires a password
   masterauth <redis_primary_password>
   
   # Ensure AOF is enabled for durability on the Valkey replica
   appendonly yes
   appendfsync everysec
   

   または、valkey-cliを介して:

   bashCopy

   # Connect to the Valkey replica
   valkey-cli -h <valkey_replica_ip> -p <valkey_replica_port>
   
   # Set it as a replica of the Redis primary
   REPLICAOF <redis_primary_ip> <redis_primary_port>
   

3. 同期の監視: レプリケーションステータスを監視します。同期が完了すると、Valkeyレプリカ上のINFO replicationコマンドはmaster_link_status:upとmaster_sync_in_progress:0を表示するはずです。

   bashCopy

   valkey-cli -h <valkey_replica_ip> -p <valkey_replica_port> INFO replication
   

フェーズ2：デュアルライト戦略（オプション、高リスクシナリオ向け）

非常に機密性の高いアプリケーションの場合、デュアルライトフェーズによってリスクを軽減できます。これには、既存のRedisプライマリと新しいValkeyレプリカの両方に書き込むようにアプリケーションロジックを変更することが含まれます。読み取りは引き続きRedisプライマリから行われます。これにより、カットオーバー前に両方のデータベースが最新の状態であることが保証されます。

// Example Node.js client using ioredis
import Redis from 'ioredis';

const redisPrimary = new Redis({ host: 'redis-primary', port: 6379 });
const valkeyReplica = new Redis({ host: 'valkey-replica', port: 6379 }); // This will become primary

async function dualWriteSet(key: string, value: string, ttl?: number) {
  const primaryPromise = ttl ? redisPrimary.setex(key, ttl, value) : redisPrimary.set(key, value);
  const replicaPromise = ttl ? valkeyReplica.setex(key, ttl, value) : valkeyReplica.set(key, value);

  // Execute writes concurrently, handle potential errors
  await Promise.allSettled([primaryPromise, replicaPromise]).then(results => {
    results.forEach((res, index) => {
      if (res.status === 'rejected') {
        console.error(`Dual-write failed for ${index === 0 ? 'Redis Primary' : 'Valkey Replica'}:`, res.reason);
        // Implement robust error handling: logging, alerting, fallback
      }
    });
  });
}

async function readFromPrimary(key: string) {
  return redisPrimary.get(key);
}

// Usage
// await dualWriteSet('user:123:session', JSON.stringify({ token: 'abc' }), 3600);
// const sessionData = await readFromPrimary('user:123:session');

フェーズ3：カットオーバー

1. Redisプライマリへの書き込み停止: Redisプライマリへのアプリケーションの書き込みを一時的に停止します。これにより、Valkeyにレプリケートされない新しいデータが古いプライマリに書き込まれることがなくなります。トラフィックの多いシステムでは、これは非常に短い期間であるか、一時的なメンテナンスページを伴う場合があります。

2. レプリケーションラグの検証: Valkeyレプリカ上のINFO replicationが、Redisプライマリ上のrepl_backlog_first_byte_offsetと一致するmaster_repl_offsetを示していることを確認し、ラグがないことを確認します。

3. Valkeyの昇格: ValkeyレプリカでREPLICAOF NO ONEを実行します。これにより、プライマリに昇格します。

   bashCopy

   valkey-cli -h <valkey_replica_ip> -p <valkey_replica_port> REPLICAOF NO ONE
   

4. トラフィックのリダイレクト: アプリケーション設定（例：環境変数、サービスディスカバリ）を更新して、新しいValkeyプライマリを指すようにします。

5. 書き込みの再開: アプリケーションの書き込みを再度有効にします。

6. 監視: Valkeyのパフォーマンス、エラー率、アプリケーションの健全性を綿密に監視します。

フェーズ4：移行後のクリーンアップ

1. 古いRedisプライマリの廃止: Valkeyへの信頼が確立されたら（例：24〜48時間の安定稼働後）、古いRedisプライマリを廃止できます。
2. Valkey高可用性の設定: SentinelまたはClusterを使用している場合は、新しいValkeyプライマリ用にこれらを設定します。

メモリ断片化とjemalloc

Redis（およびValkey）は、Linux上でデフォルトのメモリアロケータとしてjemallocを使用します。jemallocは、並行マルチスレッドアプリケーション向けに最適化されており、一般的にglibcのmallocよりも優れたメモリ使用率と断片化特性を示します。

メモリ断片化は、used_memory_rss（Resident Set Size）がused_memory（実際のデータサイズ）よりも大幅に高くなる原因となり、RAMの無駄遣いを示します。

# Check memory fragmentation ratio
valkey-cli INFO memory | grep frag_ratio
# Example output: mem_fragmentation_ratio:1.05
# A ratio > 1.5 might indicate significant fragmentation.

jemallocが使用されていない場合（例：macOS上または明示的にコンパイルされていない場合）、または断片化が問題になる場合は、以下を検討してください。

• Valkeyの再起動: 完全な再起動により、断片化されたメモリを再利用できます。これは本番システムでは最終手段です。

• ACTIVEDEFRAG: Valkey 6+（したがってValkey 8）はアクティブなデフラグメンテーションをサポートしています。valkey.confで有効にします。

  bashCopy

  # valkey.conf snippet for active defragmentation
  activedefrag yes
  active-defrag-ignore-bytes 100mb # Start defrag if fragmentation exceeds 100MB
  active-defrag-threshold-lower 10 # Start defrag if fragmentation ratio exceeds 10%
  active-defrag-threshold-upper 100 # Stop defrag if fragmentation ratio exceeds 100% (i.e., 2x memory usage)
  active-defrag-cycle-min 5 # Min percentage of CPU time to use for defrag
  active-defrag-cycle-max 75 # Max percentage of CPU time to use for defrag
  

レイテンシベンチマーク（10万OPS未満でp99）

ベンチマークは、Valkeyのパフォーマンス特性が本番環境のような負荷の下でRedis 7と一致するか、それを上回ることを検証するために不可欠です。ここではvalkey-benchmark（redis-benchmarkと機能的に同一）を使用します。

セットアップ

• クライアントマシン: Valkeyサーバーとは別の専用マシンで、十分なCPUとネットワーク帯域幅を備えていること。
• Valkeyサーバー: 適切なリソースでプロビジョニングされていること。
• ネットワーク: クライアントとサーバー間の低レイテンシ、高帯域幅ネットワーク。

ベンチマークコマンド

一般的な操作を対象とします: SET、GET、LPUSH、LRANGE（小さなリスト）、HSET、HGET。

# Benchmark SET operations: 100,000 requests, 100 concurrent clients, 100-byte value
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 -d 100 SET

# Benchmark GET operations: 100,000 requests, 100 concurrent clients
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 GET

# Benchmark LPUSH operations: 100,000 requests, 100 concurrent clients, 100-byte value
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 -d 100 LPUSH mylist

# Benchmark LRANGE operations (small list, e.g., 10 elements): 100,000 requests, 100 concurrent clients
# First, populate a list:
# valkey-cli LPUSH mylist item1 item2 ... item10
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 LRANGE mylist 0 9

# Benchmark HSET operations: 100,000 requests, 100 concurrent clients, 100-byte value
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 -d 100 HSET myhash field value

# Benchmark HGET operations: 100,000 requests, 100 concurrent clients
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 HGET myhash field

# Comprehensive benchmark with latency distribution
# This will output p50, p90, p99, p99.9 latencies
valkey-benchmark -h <valkey_ip> -p 6379 -c 100 -n 100000 --csv --latency-dist

結果の解釈

レイテンシ分布、特にp99とp99.9に焦点を当てます。インタラクティブなアプリケーションの場合、p99レイテンシは理想的には5ms未満、バックエンドサービスの場合はSLAに応じて20ms未満であるべきです。スループット（1秒あたりのリクエスト数）も重要ですが、一貫した低レイテンシはユーザーエクスペリエンスにとってより重要であることがよくあります。

これらのメトリクスを、同一の負荷プロファイルの下でRedis 7とValkey 8インスタンス間で直接比較してください。コアエンジンは同じであるため、無視できる程度の違いが予想されます。

移行チェックリスト

本番環境での落とし穴とトラブルシューティング

1. レプリケーションリンク障害（master_link_status:down）:

   • 原因: ネットワーク接続の問題、ファイアウォールによるブロック、誤ったreplicaof IP/ポート、masterauthの不一致。
   • 修正:
     • ネットワーク到達可能性を確認します（ping、telnet <ip> <port>）。
     • プライマリとレプリカの両方のファイアウォールルールを確認します。
     • valkey.confまたはvalkey-cliを介して、replicaofとmasterauth（使用されている場合）が正しく設定されていることを確認します。
     • Redisプライマリのログで接続試行/失敗を確認します。

2. 高いメモリ断片化率（mem_fragmentation_ratio > 1.5）:

   • 原因: 頻繁なキー削除、大きなオブジェクトの更新、または非jemallocアロケータを含むワークロードパターン。
   • 修正:
     • valkey.confでactivedefrag yesを有効にし、パラメータ（active-defrag-threshold-lower、active-defrag-cycle-min）を調整します。
     • jemallocが使用されていない場合は、Valkeyがそれを使用してコンパイルされていることを確認します（Linuxではデフォルト）。
     • アクティブなデフラグメンテーションが不十分でused_memory_rssが非常に高い場合は、ローリング再起動戦略を検討します。

3. カットオーバー後のクライアント接続エラー:

   • 原因: アプリケーションがまだ古いRedisプライマリを指している、DNSキャッシュの問題、誤ったValkeyポート/IP、Valkeyが予期されたインターフェースでリッスンしていない。
   • 修正:
     • アプリケーション設定が新しいValkeyプライマリを指していることを確認します。
     • ホスト名を使用している場合は、DNSキャッシュをフラッシュします。
     • valkey.confでbindディレクティブとportを確認します。Valkeyが正しいネットワークインターフェースでリッスンしていることを確認します。
     • Valkeyサーバーでnetstat -tulnp | grep valkeyを使用して、リッスンしているポートを確認します。

4. Valkeyでの低速な操作/高レイテンシ:

   • 原因: 不十分なハードウェアリソース（CPU、RAM、ネットワーク）、ディスクI/O競合（AOF/RDBが頻繁に低速ディスクに同期される場合）、長時間実行されるコマンド、多数の同時クライアント。
   • 修正:
     • valkey-cli INFO cpu、INFO memory、INFO clientsを監視します。
     • valkey-cli SLOWLOG GET 128で低速なコマンドを確認します。アプリケーションクエリを最適化します。
     • AOF/RDB永続化が高速ストレージ（例：SSD）用に設定されていることを確認します。
     • Valkeyインスタンスのリソースをスケールアップします。
     • maxmemoryとエビクションポリシーを確認します。maxmemoryに達し、エビクションが積極的である場合、レイテンシの急増を引き起こす可能性があります。

5. デュアルライト中のデータ不整合:

   • 原因: デュアルライトの非同期性、ネットワークパーティション、一方の書き込みパスでのエラーが正しく処理されていない。
   • 修正:
     • 両方の書き込みに対して堅牢なエラー処理と再試行メカニズムを実装します。
     • 不一致をログに記録し、アラートを設定します。
     • デュアルライトフェーズ中に、特に重要なデータについて、RedisとValkey間のデータを定期的に比較する調整ジョブを検討します。
     • 真にミッションクリティカルなデータの場合、カットオーバー後に完全なデータ検証が必要になる場合があります。

よくある質問

Q1: ValkeyはRedis 7.xのドロップイン代替品ですか？

A1: はい、Valkey 8はRedis 7.2.4の直接的なフォークであり、完全なRESP互換性を維持しています。Redis 7.x向けに設計された既存のクライアントライブラリとアプリケーションコードは、Valkey 8インスタンスに対して修正なしで機能するはずです。主な違いはライセンスモデルと将来の開発ガバナンスです。

Q2: 技術的な観点から見て、Redis 7とValkey 8の主な違いは何ですか？

A2: 機能的には、7.2.4のベースラインではほぼ同一です。Valkey 8はRedis 7.2.4のすべての機能、コマンド、データ構造を継承しています。主な技術的相違点は、各プロジェクトが独立して開発される将来のバージョンで発生するでしょう。移行対象としては、運用経験は実質的に同じです。

Q3: ValkeyはRedisと比較して永続性（AOF/RDB）をどのように扱いますか？

A3: ValkeyはRedisと全く同じように永続性を扱います。RDB（スナップショット）とAOF（Append-Only File）の両方の永続性メカニズムをサポートしており、混合RDB-AOF形式も含まれます。appendonly yes、appendfsync、save、no-appendfsync-on-rewriteなどの設定ディレクティブは、Redisと全く同じように機能します。

Q4: Redis SentinelやRedis ClusterをValkeyで使用できますか？

A4: はい。Valkeyは高可用性のためのRedis SentinelとシャーディングのためのRedis Clusterと完全に互換性があります。既存のSentinelまたはCluster設定を、Valkeyバイナリとポートを指すように更新するだけで、Valkeyインスタンスを管理するように設定できます。SentinelまたはClusterプロトコルに変更は必要ありません。

Q5: Valkeyインスタンスを監視するための推奨アプローチは何ですか？

A5: 標準的なRedisの監視ツールとプラクティスはValkeyに直接適用されます。これには以下が含まれます。

• INFOコマンド出力（例：INFO memory、INFO replication、INFO clients）。
• 低速なコマンドを特定するためのSLOWLOG GET。
• メトリクス収集のためのPrometheusエクスポーター（例：valkey_exporterまたはredis_exporter）。
• 視覚化のためのGrafanaダッシュボード。
• 重要なイベントのためのログ集約とアラート。 メトリクスとログの形式はRedis 7と同一です。