InfoQ が Beyond Speed Limits: Exploring the Performance Power of Valkey（2026-06-08）で、Redis のオープンソース後継として登場した Valkey が、マルチスレッド I/O などによって従来の Redis から大きく性能を伸ばしている状況を取り上げました。Valkey は Redis 7.2.4 をベースに BSD 3-clause ライセンスで分岐したフォークで、Linux Foundation 配下で AWS・Google・Oracle といった主要クラウドが支援しています。Redis とワイヤープロトコル互換のため、既存のクライアント・コード・データ構造をほぼそのまま活かしながら移行できるのが特徴です。
受託でシステム開発やインフラを担う現場では、「Redis のライセンスが RSALv2 / SSPL、さらに AGPLv3 へと変わり、いまのキャッシュ基盤をこのまま使い続けてよいのか」「マネージドサービスの提供方針が変わり、移行を迫られているが互換性が読めない」という不安が一気に増えました。これは 「最新のキャッシュエンジンを使えるか」ではなく、「ライセンスリスクを切り離し、互換性を検証し、性能を保証した状態でキャッシュ基盤を引き渡せるか」を設計に組み込む課題です。これまで バックエンドのメモリ削減でクラウドコスト最適化（GH Media） で扱った メモリとコストの最適化方針、k6 負荷テストで性能保証（GH Media） で扱った 性能を数値で保証する考え方と接続して、本記事では 「キャッシュ基盤移行・性能設計支援」を 受託パッケージとして整理します。
なぜ「いま」RedisからValkeyを検討するのか
Redis Inc. は 2024 年に、長く採用してきた寛容な BSD 3-clause ライセンスから、より制約の強いソースアベイラブルライセンス（RSALv2 / SSPLv1）へ移行しました。さらに 2025 年には Redis 8.0 以降で AGPLv3 が選択肢として加わりました。AGPLv3 はコピーレフト条項を持つため、法務・商用リスクの観点から採用を禁止している組織も多く、マネージドサービス側でも Redis 社との契約が必要になるなど、利用条件が変わりました。
この流れを受けて生まれたのが Valkey です。Redis が BSD だった最後の版（7.2.4）から分岐し、ライセンスは BSD 3-clause を維持。Linux Foundation のもとで単独の支配企業を持たない体制で運営され、Amazon・Google・Oracle・Huawei・Ericsson などが参画しています。
| 観点 | Redis（ライセンス変更後） | Valkey（2026） |
|---|---|---|
| ライセンス | RSALv2 / SSPL / AGPLv3 | BSD 3-clause |
| ガバナンス | Redis Inc. 主導 | Linux Foundation / 複数企業 |
| 互換性 | — | Redis 7.2 とプロトコル互換 |
| マネージド対応 | 契約条件が変化 | ElastiCache / Memorystore / OCI Cache |
| 性能 | バージョンで向上 | マルチスレッド I/O で大幅向上 |
| 移行コスト | — | コード変更ほぼ不要 |
つまり 「Redis を使い続ける」ことと「ライセンスリスクの少ないキャッシュ基盤を持つ」ことは別物になりました。受託でも 「ライセンスを切り離し、互換性を検証し、性能を保証して引き渡す」ことが品質の前提になっています。
Valkeyで何が変わるか
マルチスレッドI/Oによる性能向上
Valkey 8.0 では新しいマルチスレッド I/O アーキテクチャが導入され、コマンドの読み取り・解析・応答の書き込みといった処理を I/O スレッドにオフロードできるようになりました。公式ベンチマークでは、スループットが 7.2 系と比べて約 230% 向上（36 万 → 119 万 RPS 規模）し、平均レイテンシも大きく改善したと報告されています。8.1 では TLS ネゴシエーションの I/O スレッドへのオフロードなども進み、新規接続の受け入れ性能がさらに伸びました。
単一スレッドで完結していた従来 Redis のボトルネックを、I/O 処理を別スレッドに逃がすことで緩和するのが要点です。ただし後述するとおり、スレッド数は CPU コアやワークロードに応じて適切に設定する必要があり、「上げれば速くなる」単純な話ではありません。
コミュニティと主要クラウドのマネージド対応
主要クラウドは Valkey をマネージドサービスに取り込みました。AWS は Amazon ElastiCache for Valkey / MemoryDB for Valkey、Google Cloud は Memorystore for Valkey、Oracle は OCI Cache with Valkey を提供しています。ElastiCache の Valkey は Redis OSS 比でサーバーレスで約 33%、ノードベースで約 20% 安価という価格設定も発表されています。ライセンスリスクの回避とコスト最適化を同時に狙える点が、移行検討を後押ししています。
移行で確認すべき互換性とリスク
Valkey は Redis 7.2 とプロトコル互換のため、多くのケースでクライアントの接続先を切り替えるだけで動きます。接続文字列の例は次のとおりです。
# 既存の Redis クライアントはそのまま Valkey に接続できる
redis-cli -h my-valkey-endpoint.example.com -p 6379 PING
# => PONG
# valkey-cli も利用可能（Valkey 同梱）
valkey-cli -h my-valkey-endpoint.example.com -p 6379 INFO server | grep -i versionマルチスレッド I/O を有効化する場合は、設定ファイルで I/O スレッド数を指定します。コア数やワークロードに合わせた検証が前提です。
# valkey.conf — I/O スレッドの有効化（例）
# CPU コア数より小さい値から始め、負荷テストで最適値を探る
io-threads 4
# 永続化方針は Redis から引き継ぐ前に必ず再確認する
appendonly yes
appendfsync everysec互換性の確認では、次の点を必ず洗い出します。バージョン差（Redis のどの版から移るか）、モジュールの非互換（RediSearch / RedisJSON など一部モジュールは Valkey 側で別実装・別名になることがある）、マネージドサービスの仕様差（プロバイダごとのパラメータグループやフェイルオーバ挙動）、一度 Valkey に移すと Redis OSS へ戻せないケースがあること。性能を語る前に、まず 「いまの資産がそのまま動くか」を実機で確かめるのが鉄則です。
受託で提供する「キャッシュ基盤移行・性能設計支援」5フェーズ
フェーズ 1: 棚卸し・診断（1 週間）
- 現行 Redis のバージョン・モジュール・利用機能の洗い出し
- ライセンス区分（OSS / マネージド契約）とリスクの確認
- 使用クライアント・接続構成・データ量の計測
- 成果物: キャッシュ資産棚卸し表 + 移行可否・互換性レポート
フェーズ 2: 設計（1 週間）
- 移行先（自前 Valkey / ElastiCache / Memorystore / OCI Cache）の選定
- マルチスレッド I/O・永続化・フェイルオーバ方針の設計
- ロールバック方針と切り戻し不可ポイントの明示
- 成果物: 移行設計書 + 性能設計書
フェーズ 3: 移行・実装（1〜3 週間）
- 互換性検証環境の構築と差分の潰し込み
- I/O スレッド数・パラメータのチューニング
- 段階移行（並行稼働・切り替え手順）の実装
- 成果物: 移行手順 + チューニング済み構成
フェーズ 4: 検証・引き渡し（1 週間）
- 負荷テストでのスループット・レイテンシ検証
- フェイルオーバ・障害時挙動の検証
- 成果物: 性能検証レポート + 保守手順書
フェーズ 5: 継続保守（継続）
- バージョン追従とセキュリティ更新
- 性能の定点観測とチューニング見直し
- 新規キャッシュ用途の設計支援
受託向け実装標準セット
| 用途 | 推奨 | 避ける |
|---|---|---|
| エンジン | Valkey（BSD 3-clause） | ライセンス不明のまま継続 |
| マネージド | ElastiCache / Memorystore for Valkey | 契約条件未確認の利用 |
| 性能設計 | 負荷テストで io-threads を最適化 | スレッド数の当て推量 |
| 互換検証 | 検証環境で全機能を実機確認 | 本番ぶっつけ切替 |
| 永続化 | 用途に応じた AOF / RDB 設計 | デフォルト放置 |
| 切り戻し | 並行稼働 + 退避手順 | 不可逆移行の無計画実施 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| Redis をマネージドで本番運用している | キャッシュをほぼ使っていない |
| ライセンス区分を確認できていない | OSS 範囲で完結し契約不要 |
| 性能・コストを改善したい | 規模が小さく影響軽微 |
| マネージド方針変更の影響を受けた | 既存契約で問題が出ていない |
| 高負荷でレイテンシに課題がある | 負荷が低く余裕がある |
受託契約に書く6つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 移行する基盤の範囲 | 対象クラスタ / 用途の境界 |
| 互換性 | 保証する機能・モジュール | 非互換時の代替方針 |
| 性能基準 | 保証する指標 | スループット / レイテンシ目標 |
| 切り戻し | ロールバック条件 | 不可逆ポイントの明示 |
| 引き渡し | 構成 / 保守手順 | 保守体制 |
| 継続保守 | 追従・監視範囲 | 運用費用 |
価格モデル — キャッシュ基盤移行パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 20 万円〜 | 1 環境 | 棚卸し + 移行可否・互換性レポート |
| 標準移行 | 80 万円〜 | 中規模 | 移行 + 基本的な性能設計 |
| 本格移行 | 160 万円〜 | 大規模 | + 全互換検証 + 負荷テスト + チューニング |
| Lite 保守 | 3 万円〜 / 月 | 小規模 | バージョン追従 + 軽微対応 |
| Standard 保守 | 10 万円〜 / 月 | 中規模 | + 性能定点観測 + チューニング見直し |
顧客側 ROI 試算（Redis マネージド運用想定）
| 項目 | Redis 継続 | Valkey へ移行 | 差分 |
|---|---|---|---|
| ライセンスリスク | 契約・法務リスクを抱える | BSD で切り離し | リスクの低減 |
| マネージド費用 | 従来価格 | 約 20〜33% 安い設定 | 運用コストの低減 |
| スループット | 単一スレッド由来の頭打ち | マルチスレッド I/O で改善 | 処理能力の向上 |
| レイテンシ | 高負荷で悪化 | 各分位で改善 | 体感速度の改善 |
| 年間効果 | — | — | リスク低減 + コスト圧縮 + 性能向上 |
診断（20 万円〜）だけでも、「いまのキャッシュ基盤に、どれだけライセンス・互換性・性能のリスクが潜んでいるか」を可視化できること自体に価値があります。ライセンス区分の確認漏れは、たいてい契約更新や監査のタイミングで一気に顕在化します。
ハマりやすい5つの落とし穴
落とし穴 1: バージョン互換を確認せず移す
移行元 Redis のバージョンや機能を把握せずに切り替え、想定外の挙動が出ます。移行前に現行版と利用機能を棚卸しします。
落とし穴 2: モジュールの非互換を見落とす
RediSearch / RedisJSON などのモジュールは Valkey 側で別実装・別名になることがあります。依存モジュールを洗い出し、代替を検証します。
落とし穴 3: マネージドサービスの差異を無視する
プロバイダごとにパラメータグループやフェイルオーバ挙動が異なります。移行先の仕様を個別に確認します。
落とし穴 4: フェイルオーバ検証を省く
正常系だけ確認し、障害時にデータ欠損や切り替え失敗が起きます。障害注入を含めた検証を必ず実施します。本番の挙動監視は PinterestのCPUゾンビとSRE性能監査（GH Media） の観点が役立ちます。
落とし穴 5: マルチスレッド I/O の性能を過信する
io-threads を闇雲に増やしても、コア数やワークロード次第では逆効果です。負荷テストで最適値を実測します。
90日アクションプラン
| 週 | アクション |
|---|---|
| Week 1 | キャッシュ資産の棚卸し + ライセンス区分の確認 |
| Week 2 | 移行先選定 + 互換性・性能設計 |
| Week 3〜5 | 検証環境での互換検証 + チューニング |
| Week 6 | 負荷テスト + フェイルオーバ検証 + 手順整備 |
| Week 7〜13 | 段階移行 + 性能定点観測 + 追従体制の確立 |
まとめ — 「Redisを使い続ける」から「リスクを切り離して引き渡す」へ
Valkey が Redis 後継として実用域に入ったことは、キャッシュ基盤の選び方を「ライセンス変更に振り回される」から「BSD のフォークでリスクを切り離し、互換性を保ったまま性能を伸ばす」へと押し進めます。受託でシステム開発・インフラを支える立場では、ライセンスを切り離し、互換性を検証し、性能を保証して引き渡す 「キャッシュ基盤移行・性能設計支援」が、安心して長く使える基盤を届ける主力サービスです。テナント分離まで含めたデータ層の設計を見直すなら PostgreSQL RLSでマルチテナント設計（GH Media） を併読してください。
弊社では診断 / 標準移行 / 本格移行 / Lite / Standard の各段階で本パッケージを提供しています。「Redis のライセンス変更が不安」「Valkey に移してよいか診断してほしい」「移行後の性能を数値で保証してほしい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
Sources
- Beyond Speed Limits: Exploring the Performance Power of Valkey（InfoQ 2026-06-08）
- Unlock 1 Million RPS: Experience Triple the Speed with Valkey（Valkey 公式ブログ）
- Valkey 8.1: Continuing to Deliver Enhanced Performance and Reliability（Valkey 公式ブログ）
- What is Valkey? A comparison with Redis（Redis）
- バックエンドのメモリ削減でクラウドコスト最適化（GH Media）
- PinterestのCPUゾンビとSRE性能監査（GH Media）
- k6 負荷テストで性能保証（GH Media）
- PostgreSQL RLSでマルチテナント設計（GH Media）
