はじめに
こんにちは、JMDCエンジニアの片岡です。
本記事は、JMDC Advent Calendar 2025の24日目の記事です。
今回、弊社アプリPepUpで利用していたAWS ElastiCache for Redis OSSを、AWS ElastiCache for Valkeyに移行しました。(Redis 6.2 => Valkey 7.2)
本記事では、移行の際のポイントや、実際に移行作業でハマった部分について解説します。
Valkeyとは?
Valkeyとは、Redis互換のオープンソースインメモリデータベースです。
2024年3月、RedisがBSD 3-Clauseライセンスから、商用利用に制限のあるRSAL v2/SSPLへとライセンス変更を行いました。これを受けて、 Linux Foundationの支援のもと、Redisからフォークして生まれたのがValkeyです。
AWS ElastiCacheでも2024年10月からValkeyがサポートされるようになりました。
移行の背景
- コスト削減:約20%削減(年間約72,000円)
- パフォーマンス向上:約12%のスループット改善 のメリットが移行の背景です。
また、ValkeyはRedisとの高い互換性があるため、既存のアプリケーションコードをほぼ変更せずに移行できます。
同時に、Redisで購入済みだったリザーブドインスタンスの期限が切れるタイミングでもありました。
移行の際の注意ポイント
移行の際のポイントは以下の3点です。
- ダウンタイムの発生:移行中は一時的にサービスが利用できなくなります。
- ロールバック手順を用意しておく:万一の場合に備えて、元の状態に戻せる手順を準備しておきましょう
- ホストの変更は発生しない:エンドポイントは維持され、中身のkey-valueデータも保持されます
移行の流れ
Valkeyへの移行は比較的シンプルです。以下の手順で実施しました。
移行手順メモ
手順0. 対象サービスにログインしておく(移行後の動作確認用)
手順1. サービスメンテナンスを開始
手順2. AWS ElastiCache for Redisでバックアップ(スナップショット)を取得
手順3. AWS ElastiCache Redisのインスタンス設定値のスクリーンショットを取得(万一のロールバック用)
手順4. Terraformのapply(Redis → Valkeyへと移行)
# Terraformコード例 (サンプル) resource "aws_elasticache_replication_group" "example" { # ... 既存の設定 ... engine = "valkey" engine_version = "7.2" apply_immediately = true # ← 重要!(後述) }
手順5. RailsからValkeyへの疎通確認
Rails consoleにて下記コマンドを実行します。
# Rails Cache用のRedis接続確認 cache_redis_config = { url: "redis://XXXXXXXXXXXXXXXXXXXX" } cache_redis = Redis.new(cache_redis_config) # 接続テスト cache_redis.ping # => "PONG" が返れば接続成功 # 既存のキーを1つランダムに取得(テスト) random_key = cache_redis.randomkey
手順6. サービスメンテナンスを終了
手順7. 手順0でログインしていたセッションが保持されているか確認
ロールバック手順メモ
万一の場合に備えてロールバック手順も作成&検証しました。
- スナップショットからRedisを復元
- アプリケーションサーバを新しいエンドポイントに繋ぎ直す
移行時にハマった話と、その回避策
手順4「Terraformのapply(Redis → Valkeyへと移行)」でハマりました。
Terraformのapply自体は成功したのですが、実際のAWS上でValkey移行が始まらない...
AWSコンソールから手動で試してみると、以下のエラーが表示されました。
The requested action: Engine Upgrade is blocked by the following pending action: Engine Upgrade. Please do one of the following: (1) Perform the pending action(s) now (2) Schedule the requested action for your next maintenance window

調査してみると、エンジンアップグレードが即時実行ではなく、メンテナンスウィンドウでの実行待ちになってしまっている状況でした。
つまり、Terraformで以下の設定が抜けていたのです...orz
apply_immediately = true
この操作は取り消せませんでした。メンテナンスウィンドウの実行を待つしかありません。
しかし、それだと意図しないタイミングでダウンタイムが発生してしまう恐れがあります...
ここで、事前に用意していたロールバック手順が活きました。
スナップショットから復元する際に、エンジンをValkeyに指定して復元。 そして、アプリケーションサーバを新しいValkeyエンドポイントに繋ぎ直すことで、無事に移行を完了できました。🎉
まとめ
- 検証環境でうまくいったからといって慢心しないこと(特に
apply_immediatelyの設定) - 移行時は常にロールバック手順を用意しておくこと(今回はこれが役立ちました)
途中トラブルに見舞われましたが、無事Valkeyへの移行が完了したのはよかったです。 万一の備えの大切さと、慢心しないことの大切さ学んだプロジェクトでした。
最後までお読みいただき、ありがとうございました。
おわりに
明日25日目は、黒木さんによる「Amazon Q Developerを検証的に導入のお話」です。お楽しみに!
JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です!
フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。
詳細は下記の募集一覧からご確認ください。
hrmos.co
まずはカジュアルにJMDCメンバーと話してみたい/経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co
★最新記事のお知らせはぜひ X(Twitter)、またはBlueskyをご覧ください! Tweets by jmdc_tech twitter.com bsky.app