ElastiCache for RedisをValkeyへ移行しました

ツール導入前の課題

• チーム目標としてインフラコスト削減が設定されており、費用対効果の高い施策を選定していました。
• Redis6.2のEOLが近づいており、バージョンアップが必要でした。

当時の状況

• インフラはAWS上で構築されており、Terraformで管理していました。
• キャッシュやメッセージブローカーとして、ElastiCache for Redis6.2をオンデマンドノードで使用していました。
• アプリケーションは Python + Django で構築しており、ライブラリに redis-py や django-redis、Celery を使用していました。

1. インフラコストが削減できる

ElastiCache for Valkeyの場合、 ElastiCache for Redisに比べて、オンデマンドノードで20%、サーバレスで33%のコスト削減 ができます。

2. 移行コストが低い

ValkeyはRedis7.2からフォークされたOSSであり互換性があるため、RedisURLや既存コマンドがそのまま使え、コード修正が最小限に抑えられると判断しました。

3. 移行リスクが低い

AWS ElastiCacheの構成によってはダウンタイムなしで移行できます。 また、Redisと互換性があるため、移行後の障害リスクも低いと判断しました。

4. パフォーマンスが向上する

Valkey 8.0ではI/Oスレッディングが強化されており、 スループットやレイテンシーの向上が見込めました。

どのような成果が得られたか

1. インフラコストを削減できた

AWS公式価格に基づき約20%のコスト削減を実現しました。 本番環境での運用期間がまだ短いため、今後、実際の請求額でも効果を検証していく予定です。

2. アプリケーションコードの変更は不要だった

redis-pyやdjango-redis、Celeryの設定変更なしで移行でき、Terraformの変更のみで完了しました。

3. 移行後も安定稼働している

運用開始後、接続エラーやパフォーマンス劣化などの障害は発生していません。

1. インフラ構成の変更が必要だった

私たちのプロダクトでは、レプリケーショングループがないシングルノード構成のElastiCache for Redisを運用していました。
しかし、Valkeyへの移行はレプリケーショングループ構成が前提となっているため、まずはレプリケーショングループの作成を実施しました。
今回の移行目的は インフラコストの削減 であったため、レプリカノードは追加せずに シングルノード構成のまま運用を継続 しています。
ElastiCacheの料金はノード数に応じて課金される仕組みのため、レプリケーショングループを作成しても、ノード数が変わらなければインフラコストは増加しません。

2. Terraform Providerのバージョンアップが必要だった

当時のTerraformは AWS Provider v4を使用しており、Valkeyに対応してませんでした。
そのため、Valkeyへの移行前にProviderをv5へバージョンアップする必要がありました。

RedisからValkeyへの移行は、費用対効果が高いインフラコスト削減施策としておすすめです。
特にRedisのEOL対応が必要なタイミングで、Valkeyへの移行を検討されてはいかがでしょうか。

• RedisライブラリからValkeyライブラリへの移行を実施予定です。
  （redis-py → valkey-py、django-redis → django-valkey）
• Valkey9がリリースされたら、バージョンアップを実施予定です。
• AWSがリリースしたRust製のValkeyクライアント Valkey GLIDE の導入を検討しています。