AWS ElastiCache for Redis を Valkey へ移行した話

はじめに

はじめまして。フリーで DBRE に所属している pon です。

弊社では 2025 年 9 月から 2026 年 1 月の期間で AWS ElastiCache for Redis のうちエンジンバージョンが Redis のクラスターに対して Valkey エンジンへ移行するプロジェクトを行いました。本プロジェクトでは約 50 個のクラスターが対象となり、期間内での移行が完了しました。

この記事では、 Valkey 移行プロジェクトの移行プロセスや躓いた事例を共有します。今後移行を考えている方の参考になれば幸いです。

Valkey 移行を決定した背景

AWS は 2026 年 1 月 31 日に Redis 5 系エンジンバージョンの標準サポートを終了しました。これが今回の移行プロジェクトの直接的なきっかけです。

サポート終了告知にあたり、互換性・コストの2つの観点から、弊社ではまず Redis 5.0.6 を使用しているクラスターをメイン対象に移行を行うことを決定しました。

Redis と Valkey の互換性

Valkey は元々 Redis 7.2.4 を fork した OSS であり、Redis 7.2.4 との互換性を保ちながら現在まで開発が続けられています。

そのため、Redis 7 時点から見た Valkey は機能的に同等であり、アプリケーション側の移行負担は大きくならないと判断しました。

コスト削減

Redis のライセンス変更に伴い、コミュニティはオープンソースの代替として Valkey を採用しています。

AWS でも Valkey のサポートを開始しており Amazon ElastiCache for Valkey では、Redis OSS と比較してServerless において33%、ノードベースでは20%安い価格で利用できるようになっています。そのため、Valkey 移行を行うことでコストカットが実現できると考えました。

事前検証

弊社では実際に移行を行う前に、リスク評価を行った上で互換性の調査とダウンタイム計測の 2 つの検証を実施しました。

リスク評価

弊社における Redis の役割は大きくキャッシュと Job Queue の 2 つに分類されます。キャッシュ用途であれば、移行時に問題が生じてもアプリケーションが直接 DB にアクセスするようフォールバックするため、サービスの停止には至りません。一方、Job Queue 用途の場合はメンテナンスウィンドウの確保やダウンタイムの検証が必要と判断しました。

また、いずれの用途においても GET SET 等基本的な Redis の機能を利用している箇所は少ないことを確認しました。

以上から、移行時の影響範囲は限定的と判断し、互換性の調査は以下の方針で実施しました。

ベンチマークツールによる基礎動作の確認
リリースノートベースの互換性調査
検証環境での動作確認

互換性の調査

今回は Redis 5.0.6 から Valkey 8.1 への移行です。

まず Valkey 8.1 環境において redis-benchmark を実行し、基本的な操作が問題なく動作することを確認しました。

次に、リリースノートベースでの互換性調査を行いました。Redis 7.2.4 と Valkey 7.2 の互換性は Valkey 7.2 release notes より保証されているため、互換性の調査を行ったのは以下 2 箇所でした。

Redis 5.0.6 から Redis 7.2.4まで
Valkey 7.2 から Valkey 8.1 まで

結果、Redis 間におけるマイナーアップデートには破壊的変更が存在してはいますが、弊社プロダクトへの影響がないことを確認しました。

残りのカバレッジは Integration 環境でアプリケーションを実際に動作させることで担保しました。

ダウンタイム計測

リスク評価において Job Queue 用途ではダウンタイムの検証が必要と判断したため、計測を実施しました。

AWS における Valkey 移行では、既存クラスターのエンジンのみを切り替えるインプレース方式であればダウンタイムを最小限に抑えられます。

調査段階では以下の手順で複数回ダウンタイムの計測を行い、数秒程度のダウンタイムが発生することがわかりました。

Redis 5.0.6 クラスタとそこへアクセス可能な EC2 を作成
Redis 5.0.6 に1000個のランダムデータを挿入
継続的に SET / GET 操作を行うスクリプトを実行

しかし、実際に移行を行うと、このダウンタイム中のタイミングで接続を行った場合、クライアント側でキャッシュしているクラスター構成情報が更新されるまで reader endpoint を参照してしまう事象が確認されました。アプリケーションの構成によってはダウンタイムが分単位になってしまうかもしれないので、注意が必要です。

移行手順の概要

弊社では AWS のインフラリソースを Terraform で管理しているため、PR ベースでの移行を行いました。apply_immediately パラメータやメンテナンスウィンドウで反映タイミングを適切に制御するように注意が必要です。実際の移行の流れを以下にまとめます。

aws provider バージョンを v5.73.0 以降にする v5.73.0 以前では engine valkey に対応ができておらず provider のバージョンアップが必要です。
valkey 用の parameter group の作成
aws_elasticache_replication_group リソースの engine / version / parameter group の変更
apply 後、プロダクトチーム側で動作確認を行う

そして、リトライ機構の有無・フォールバック先の有無・データロストの許容非許容等プロダクトの特性に合わせて移行を実施しました。

躓いた事例

aws_elasticache_cluster リソースで作成された ElastiCache

上記の移行手順は aws_elasticache_replication_group においては適用可能ですが、aws_elasticache_cluster の場合には適用できません。この場合、マネジメントコンソールからも直接のエンジン変更は不可となります。今回の移行対象の中にも数個該当リソースで作成された Elasticache が存在していました。

弊社では AWS 公式手順を参考に以下のコマンドでまず既存クラスターを元にレプリケーショングループを作成し、その後 Terraform 側で辻褄合わせを行った後に通常のValkey移行手順を実施することで移行を完了しました。

aws elasticache create-replication-group \
   --replication-group-id "replication groupの名前" \
   --replication-group-description "replication groupの説明" \
   --num-cache-clusters 1 \
   --primary-cluster-id "既存clusterのid"

この変更はメタデータの変更のみが行われるため、ダウンタイムやデータロストは発生しませんでした。

同じエンドポイントを使用した復旧

ElastiCache for Redis から Valkey への移行では、切り戻しはサポートされていません。仮に Redis へ戻す場合には新しく Redis の ElastiCache を作成する必要があります。

今回の移行の中で 1 件、 Staging 環境における ElastiCache にて移行後より一部の内部プロダクト間通信に問題が発生し、 Valkey 移行を中止した事例がありました。

Staging 環境かつデータロストを許容するケースだったため、止血対応として同名で Redis を再作成することでエンドポイントを共有し復旧を図りました。しかし、作成完了後しばらくアプリケーションからもタイムアウトが続き、別名で Redis を作り直したところ接続できるようになりました。自社側、AWS 側でもテスト環境にて再現を図りましたが、この事象の再現には至っていません。

再発防止として、実際の Production 環境では復旧までの時間も考慮し、あらかじめ別名の復旧用の Redis を立てておきエンドポイントを切り替える手順に変更しました。

移行を振り返って

今回は 50 個の Redis クラスターを移行しましたが、実際の移行作業はプロダクトチームが主体となって進めました。効率的に進められたポイントは以下だと考えています。

詳細な手順書の作成
- 移行背景、互換性調査結果、ダウンタイム計測結果を含める
- レビュー観点も明記し、PRベースで自主的に進められる形に
専用チャンネルでの情報集約
- 各チームの代表者を集め、知見やトラブル情報をリアルタイムで共有

DBRE は手順書とサポート体制の整備に注力し、プロダクトチームが自走できる環境を作ることを意識しました。

フリーの DBRE はまだ発展途上にあり、運用保守を直接担っている領域も多くあります。その中で、今回のプロジェクトはプロダクトチームの自律化を支援する Enabling の取り組みとして成果を出せたと考えています。プロダクトチームが自身の担当領域に責任を持ち、信頼性を守れる体制づくりを今後も推進していきます。

残りの Redis クラスターについても、今回の知見をもとに移行を継続していく予定です。