こんにちは。ES課で研修中の柏葉です。
本記事ではCloudFomationでRedis OSSクラスターを作成し、スタック更新によりValkeyへエンジンを変更して挙動を確認してみます。 併せて、変更前後の性能についても簡単に比較してみます。
本記事はサーバーワークスAdvent Calendar 2024の16日目の記事です。他の記事も是非ご覧ください！ qiita.com
概要
Amazon ElastiCache（以下、Elasticache）のエンジンとして、現在はRedis OSS・Memcachedに加えてValkeyの中から選択可能となっています。 今回は題名の通り、Redis OSSからValkeyへCloudFormationでの移行を試してみます。
オンデマンドノードの場合、同じキャッシュノードタイプでValkeyはRedisに比べ20%低価格となります。
| エンジン | キャッシュノードタイプ | 時間あたりの料金 |
|---|---|---|
| Valkey | cache.r7g.large | USD 0.2104 |
| Redis | cache.r7g.large | USD 0.263 |
※東京リージョン、2024/12/16時点（料金 - Amazon ElastiCache | AWS）
アナウンスブログに記載の通り、Redis OSSからValkeyへはダウンタイム無しで変更が可能です。
ElastiCache for Redis OSS から ElastiCache for Valkey へのアップグレード ElastiCache for Redis OSS の既存ユーザーの場合、ダウンタイムなしで ElastiCache for Valkey にすばやくアップグレードできます。
そもそもValkeyとは何か、という点については以下の弊社ブログでも解説がありますので是非ご参照ください。 blog.serverworks.co.jp
事前準備
Redisクラスターの作成
今回は簡単な検証のため、最低限の構成で構築しました。 以下の構成のクラスターを作成し、事前に構築したEC2インスタンスから接続できる設定とします。
- ノードのタイプ：cache.r7g.large
- エンジンバージョン：7.1.0
- マルチAZ：有効
- ノードの数：2
クラスターを作成する部分のCloudFomationテンプレートは以下の通りです。
Resources: ElasticacheReplicationGroup: Type: AWS::ElastiCache::ReplicationGroup DeletionPolicy: Retain Properties: AutomaticFailoverEnabled: true CacheNodeType: cache.r7g.large CacheSubnetGroupName: !Ref ElastiCacheSubnetGroup Engine: redis EngineVersion: "7.1" MultiAZEnabled: true NumCacheClusters: 2 Port: 6379 ReplicationGroupDescription: "Test ElastiCache replication group" ReplicationGroupId: "test-elasticache-cluster" SecurityGroupIds: - !Ref SecurityGroupElastiCache
性能確認
ついでに簡単に性能の影響も見てみたかったので、「valkey-benchmark」を使ってテストしてみます。
まずは以下のドキュメントに従い、「valkey-cli」を導入します。 docs.aws.amazon.com
- インストール
sudo yum install gcc wget https://github.com/valkey-io/valkey/archive/refs/tags/7.2.6.tar.gz tar xvzf valkey-7.2.6.tar.gz make
- 接続確認
src/valkey-cli -c -h <ホスト名> -p 6379 <エンドポイント>:6379> dbsize (integer) 0
valkey-cliでも問題無くRedisクラスターに接続できました。
続いて、パッケージ内に含まれている「valkey-benchmark」を実行します。
./src/valkey-benchmark -h <ホスト名> -q
※ -q：出力を簡素化し、クエリ/秒の値のみ表示（オプション）
デフォルトでは20並列で100000リクエストが送信されます。 参考： Valkey Documentation · Valkey benchmark
実行結果はコンソールに出力されるため保存しておき、エンジン変更後にまとめて確認します。
エンジンをValkeyに変更する
注意点
本筋からは逸れますが、CloudFormationテンプレートで指定するエンジンを変更してスタック更新を実行した際、以下のエラーに遭遇しました。
redis parameter group is not applicable to engine valkey (Service: AmazonElastiCache; Status Code: 400; Error Code: InvalidParameterCombination
エラー文の通り、前述のテンプレートではパラメータグループを明示しておらず、デフォルトパラメータグループ（default.redis7）が使用されている点が原因です。 エンジンの変更の際、一緒にパラメータグループも変更する必要があります。
公式ドキュメントの記載(2024/12 時点)を読むと、「modify-replication-group API」の実行について以下の記載があります。
If you have an existing Redis OSS replication group that is using the default cache parameter group, you can upgrade to Valkey by specifying the new engine and engine version with modify-replication-group API.
（中略）
If you have a custom cache parameter group applied to the existing redis replication group you wish to upgrade, you will need to pass a custom Valkey cache parameter group in the request as well.
[日本語訳]
デフォルトのキャッシュパラメータグループを使用している既存の Redis OSS レプリケーショングループがある場合は、modify-replication-group API を使用して新しいエンジンとエンジンバージョンを指定することで Valkey にアップグレードできます。
（中略）
アップグレードする既存の redis レプリケーショングループにカスタムキャッシュパラメータグループが適用されている場合は、リクエストでカスタムの Valkey キャッシュパラメータグループも渡す必要があります。 https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/VersionManagement.HowTo.cross-engine-upgrade.html
今回の構成だとどちらに該当するか迷いましたが、CloudFormationでのスタック更新の場合は明示的にパラメータグループ名を指定する必要があります。 実際にスタック更新時のCloudTrailのイベントレコードを見ると、明示していない「"cacheParameterGroupName": "default.redis7"」が渡されていました。（考えてみれば、勝手に変わっても困りますね）
運用中のテンプレートでパラメータグループ名を明示していない方はご注意ください。
再実行
ということで、パラメータグループを明示しながら更新します。
CloudFomationテンプレートの変更
Resources: ElasticacheReplicationGroup: Type: AWS::ElastiCache::ReplicationGroup DeletionPolicy: Retain Properties: AutomaticFailoverEnabled: true CacheNodeType: cache.r7g.large CacheSubnetGroupName: !Ref ElastiCacheSubnetGroup CacheParameterGroupName: "default.valkey7" # 追加 Engine: valkey # 変更 EngineVersion: "7.2" # 変更 MultiAZEnabled: true NumCacheClusters: 2 Port: 6379 SecurityGroupIds: - !Ref SecurityGroupElastiCache ReplicationGroupDescription: "Test ElastiCache replication group"
利用可能なエンジンバージョンはRedisとValkeyで異なります。 以下のように確認できます。（2024/12/16 時点）
$ aws elasticache describe-cache-engine-versions --engine valkey { "CacheEngineVersions": [ { "Engine": "valkey", "EngineVersion": "7.2", "CacheParameterGroupFamily": "valkey7", "CacheEngineDescription": "Valkey Engine for ElastiCache", "CacheEngineVersionDescription": "valkey version 7.2.6" }, { "Engine": "valkey", "EngineVersion": "8.0", "CacheParameterGroupFamily": "valkey8", "CacheEngineDescription": "Valkey Engine for ElastiCache", "CacheEngineVersionDescription": "valkey version 8.0.1" } ] }
更新時のレイテンシーについて
「概要」にて前述の通り、Redis OSSからValkeyへはダウンタイム無しで変更が可能です。 参考のため、単純ですが、valkey-cliにてレイテンシーを確認しながら変更をかけてみました。
./src/valkey-cli -h <ホスト名> --latency
変更前の出力例は以下の通りです。
min: 0, max: 7, avg: 0.32 (38665 samples)
変更完了時の出力は以下の通りとなっていました。
min: 0, max: 1003, avg: 0.27 (119382 samples)
エラーも発生せず接続断は起こりませんでしたが、一時的にレイテンシーが増加したことは確認できました。
結果確認
更新開始から20分程度経った時点で、スタックの更新が完了しました。
変更後も同様にベンチマークテストを実行して、結果を確認します。
性能比較
変更前（Redis OSS 7.1.0）と変更後（Valkey 7.2.6）の比較結果は以下の通りです。
エンジンバージョンに差異があることや、今回は簡単な検証のため厳密な比較ではありませんが、概ね同程度の性能となっている印象を受けました。
まとめ
RedisからValkeyへのエンジン変更について、CloudFormationでの変更方法と変更時の影響を確認しました。 変更の所要時間や接続の影響、性能などについてはワークロードによるところが大きいため、あくまでも簡単な一例としてとらえて頂ければ幸いです。
移行作業自体も非常に簡単で、Redisと変わらない使用感のままコスト削減出来るため、Valkeyへ移行するメリットは十分ありそうだと感じました。 本記事が移行を検討している方の一助となれば幸いです！
