自社サービスのCacheをRedis->Valkey移行してみた
はじめに
こんにちは、DELTAの馬場です。
今回は少し話題になったElastiCacheのRedisをフォークした新しいエンジンのValkeyについて記事を書きます。
これをやるに至った背景としては単純に20%程安くなるといったところと、ぶっちゃけCache周りでそこまでリッチなことしてないケースも多いのでは？意外と気軽に移行しても問題なく動くのでは？と思い、まずは自社のプロダクトに手を加えていこうぜ！という勢いがベースになります。
移行周りで少し詰まったこともありましたが、結構簡単に移行できたのでどのようなことをやったのか？を紹介していきます。
やったこと
既存のTerraformに以下の変更を加えました。
main.tf
resource "aws_elasticache_replication_group" "main" {
replication_group_id = "${var.service}-${var.stage}"
+ engine = "valkey"
+ engine_version = "7.2"
+ parameter_group_name = var.parameter_group_name
variables.tf
+variable "parameter_group_name" {
+ default = "default.valkey7"
+ type = string
+}
environments/main.tf
required_providers {
aws = {
source = "hashicorp/aws"
+ version = "~> 5.73"
}
}
つまりポイント
下記公式の記載にもありましたが、apply_immediately を有効化していなかったため変更が反映されず慌てることがありました。 これは先に気付けた内容になりますが、以下のissueにあるようにterraform-provider-awsのversionが 5.73 以降である必要があり、そこも見逃しやすいポイントかなと思います。
まとめ
実際に移行してみた所、アプリ側の改修無しで移行することができました！
今回RedisからValkeyに移行したプロダクトはRedisのsidekiqのqueue管理でだけ使用されていて、かなりシンプルな用途に限られていたためであろうことは予測できましたが、それでもインフラ領域のみの移行で完了しきったことはかなり驚きました。
以下のような機能差分があるようですが、このケースのようなシンプルな利用だと意外とスムーズに移行が完了するかもしれません。
今後フォークされたValkeyが独自進化をしていくと、それに追走するライブラリなどを選定する必要がありそうですが、現在は自前か既存のRedis用ライブラリの流用でことが足りるケースも多そうです。
最後に
今回検証に利用した自社プロダクトでは 150社を超える実績から得たデータとノウハウをもとに 無料でクラウドコスト削減の簡易診断ができます!
いつでも利用できますので、気になったときに、システムの健康診断としてご利用ください!
We're hiring!
最後までお読みいただきありがとうございます。
現在DELTA では一緒に働いてくださる仲間を大募集中です！
ご興味をお持ちいただけましたら、お気軽にフォームからご連絡ください。
Discussion