この記事は NewsPicks Advent Calendar 2025 の6日目の記事です。
こんにちは。ソーシャル経済メディア「NewsPicks」のSREチームの飯野です。
今回は、リリースラッシュの裏側で地道に積み重ねてきたコスト最適化施策を振り返る で触れた AWS ElastiCache for Redis から AWS ElastiCache for Valkey への移行について話したいと思います。
コスト最適化施策として移行を行う
ValkeyはRedisのライセンス変更をきっかけに生まれたフォークです。Redisとの高い互換性を保ちながらオープンソースライセンスを保ち、Linux Foundationの元で開発されています。
AWS ElastiCache ではRedis と Valkey でコスト面で大きな差があります。これを狙って移行を行います。
ノードベースの ElastiCache for Valkey は、他のノードベースの ElastiCache エンジンと比べて 20% 低く設定されています。
Amazon ElastiCache と Amazon MemoryDB の Valkey サポートを発表 | Amazon Web Services ブログ
2025/08に古いエンジンバージョンの延長サポートが発表されました。一部古いエンジンを利用しているため、延長サポート費用を回避するためにも移行を行います。*1
ElastiCache における ElastiCache Redis OSS バージョン 4 と 5 の標準サポートは 2026 年 1 月 31 日に終了します。
Amazon ElastiCache for Redis OSS バージョン 4 および 5 の延長サポートの紹介 | Amazon Web Services ブログ
移行計画を立てる
NewsPicksでは大小さまざまなクラスターを目的ごとに用意しています。目的ごとに用意しているということで基本は垂直分割なのですが、ElastiCacheのシャードを使わずに水平分割しているクラスター群もあります。 SREの工数も潤沢には確保できないので、通年で少しずつ移行していきたいです。
これらを踏まえて次の方針を取りました。
- Valkey-7.2へ移行する
- Valkey 7.2.5はRedis 7.2.4からのブランディング変更版であるためRedisとの非互換がないと言える
- そのためRedis-7.0との差分だけを確認すれば良い
- 一部Redis-5.0.xのクラスターがあるのでRedis7.0に上げてからValkeyへ移行する
- Valkey 7.2.5はRedis 7.2.4からのブランディング変更版であるためRedisとの非互換がないと言える
- リザーブドノード購入タイミングを目安に計画的に移行を行う
- コスト削減が目的なのでリザーブドノード購入タイミングまでには移行を終える必要がある。
- 多少前後するのは許容する。
- コスト削減が目的なのでリザーブドノード購入タイミングまでには移行を終える必要がある。
次に、リザーブドノード購入タイミングや現在の利用状況を踏まえて移行方法を整理します。以下が実際の移行計画の概要です。
| redisの目的 | 移行タイミング | 移行作業 | その他 |
|---|---|---|---|
| タイムライン | 2024/12 | 日中にオンライン更新(切り替え時の少量のエラーを許容) | |
| NewsPicksのセッション | 2025/01 | 夜間(アクセスが少ないタイミング)にオンライン更新 | 水平分割を統合 |
| 広告カウント | 2025/01 | 夜間(アクセスが少ないタイミング)に広告配信を停止後に更新 | |
| 広告・記事入稿システムのセッション | 2025/07 | 夜間(アクセスが少ないタイミング)に広告配信を停止後に更新 | スケールダウン |
| 広告・記事入稿システムのpubsub | 2025/07 | 夜間(アクセスが少ないタイミング)に広告配信を停止後に更新 | |
| プッシュ通知事前テスト*2 | 2025/07 | 夜間(使っていないタイミング)に更新 | |
| 汎用 | 2025/11 | 夜間メンテナンスでRedis 7に更新 | |
| コメントスコア | 2025/11 | 夜間メンテナンスでRedis 7に更新 | |
| 汎用 | 2025/12 | 夜間メンテナンスで更新 | |
| コメントスコア | 2025/12 | 夜間メンテナンスで更新 |
SLOを守れそうなら日中にオンライン更新を行う
タイムラインについては「日中にオンライン更新」を行っています。これはユーザーへの影響が少ないと判断したためです。
- 過去(2022年)にRedisのEOLでオンライン更新の検討と実施が行われており、影響が限定的であると把握できている
- Redisにアクセスできない場合はDBを参照して返すなど調査済み
- 水平分割されており、一つずつ行なった時に影響があるユーザーが限定的である。
- Redisを利用する機能のリプレースが進んでおり、2024/12時点では2022年より利用頻度が下がっていた。
- Redis-7.0からValkey-7.2への移行のためリスクが少ない
全体としてはSLOを守れると判断できる場合は日中の更新も行っています。*3
移行準備
パラメータグループの変更内容確認
デフォルト値の変更があるか確認します。CLIでTSVの比較を行う場合は git diff --word-diff --no-index で単語単位の差分を確認すると良いです。
default.redis5.0.cluster.onとdefault.redis7.cluster.onの比較。
git diff --word-diff --no-index \ <(aws elasticache describe-cache-parameters --cache-parameter-group-name default.redis5.0.cluster.on --query "Parameters[].[ParameterName,ParameterValue,Description,Source,DataType,AllowedValues,IsModifiable,MinimumEngineVersion,ChangeType]" --output text) \ <(aws elasticache describe-cache-parameters --cache-parameter-group-name default.redis7.cluster.on --query "Parameters[].[ParameterName,ParameterValue,Description,Source,DataType,AllowedValues,IsModifiable,MinimumEngineVersion,ChangeType]" --output text)
- 項目の増減、項目の変名があります

default.redis7.cluster.onとdefault.valkey7.cluster.onの比較。
git diff --word-diff --no-index \ <(aws elasticache describe-cache-parameters --cache-parameter-group-name default.redis7.cluster.on --query "Parameters[].[ParameterName,ParameterValue,Description,Source,DataType,AllowedValues,IsModifiable,MinimumEngineVersion,ChangeType]" --output text) \ <(aws elasticache describe-cache-parameters --cache-parameter-group-name default.valkey7.cluster.on --query "Parameters[].[ParameterName,ParameterValue,Description,Source,DataType,AllowedValues,IsModifiable,MinimumEngineVersion,ChangeType]" --output text)
- MinimumEngineVersion以外の差分はありません

必要に応じてカスタムパラメータグループ作成します。
動作確認
事前に開発でValkeyへ移行などを行い動作確認を行います。 目的ごとにクラスターを用意しているのもあり、一つ一つは難しい使い方はしていないので助かりました。
汎用だけは様々な用途で使われており、かつ古いバージョンだったので二ヶ月前からRedis7に更新しておき、経過を観察していました。
移行作業
- バックアップを作成
- AWSコンソール上から移行を実施
- m6g.largeで30分ほどで移行完了しました。
- 動作確認、エラーなどを確認
今回の移行では大きな不具合などは発生しませんでした。
まとめ
AWS ElastiCache for Valkeyの発表から計画的に移行を行い、一年かけてNewsPicksで利用しているAWS ElastiCache for RedisをAWS ElastiCache for Valkeyに移行しました。
- 年間のリザーブドノード購入金額を20%削減し、延長サポート費の発生も回避できました。
- 応答速度など性能面で大きな変化は見られませんでした。
- Redis 5→Redis 7の移行により、メモリ使用率が5-7ポイントほど減少し、スケールアップ、スケールアウトの期限を伸ばすことができました。

リザーブドノード購入のタイミングに合わせて段階的に移行することで、限られた工数の中でも無理なく作業を進めることができました。今後も継続的にインフラの最適化を進め、安定したサービス提供に貢献していきます。
*1:Redis-5 → Redis-7でメモリ効率が良くなっているなど性能面での恩恵もあります。
*2:https://tech.uzabase.com/entry/2022/12/11/000000 で解説しています
*3:RDBのマイグレーションもサービス内容を踏まえてリスクが少ない変更と判断できる場合は日中に適用することがあると思います。
