ElastiCache for Valkey の新機能、耐久性の変更が可能になったので試してみた
はじめに
ElastiCache for Valkey に、既存のノードベースクラスターでも耐久性を有効化・無効化できるようになるアップデートがありました。
従来、ノードベースクラスターの耐久性は作成時のみ指定でき、既存クラスターでは変更できませんでした。
この記事では、クラスターモード有効の Valkey 9.0 クラスターで耐久性を無効・同期・非同期に切り替え、変更ごとの所要時間、変更中の Status、フェイルオーバーの有無を確かめました。
変更の前提条件
既存クラスターの耐久性を変更するには、次の条件を満たす必要があります。
- Valkey 9.0 以上
- クラスターモード有効
- Multi-AZ 有効で、シャードあたりレプリカが1以上
- 転送中の暗号化（TLS）が有効
- インスタンスファミリーが R8g、R7g、R6g、M8g、M7g、M6g、C8gn、C7gn のいずれか
- Global Datastore に含まれていない
変更時の注意事項
- 耐久性の変更は、ほかの設定変更と同時には行えません。
- 変更はノードの置き換えを伴い、シャードごとにプライマリの切り替えか自動フェイルオーバーが起きます。変更中もクラスターはトラフィックを処理しますが、クライアントの接続は一時的に切れることがあります。
検証方法
検証環境
| 項目 | 値 |
|---|---|
| リージョン | ap-northeast-1（東京） |
| エンジン | Valkey 9.0 |
| ノードタイプ | cache.m6g.large |
| 構成 | クラスターモード有効、1シャード、レプリカ1（ap-northeast-1a と ap-northeast-1c） |
| Multi-AZ / 自動フェイルオーバー | 有効 / 有効 |
| 転送中の暗号化 | 有効 |
| データ | 検証用のキー3件以下 |
| 変更を実行したクライアント | 同じ VPC の EC2 上の AWS CLI 2.38.0 |
変更と確認のコマンド
変更は無効 → 同期 → 無効 → 非同期 → 同期の順に、前の変更の完了を待ってから行いました。同期へ変更したときのコマンドと応答を示します。無効・非同期へ変更するときは、--durability の値だけを変えました。--query は、応答の Status、Durability、EffectiveDurability を確認するためのものです。
aws elasticache modify-replication-group \
--replication-group-id my-valkey-cluster \
--durability sync \
--apply-immediately \
--query 'ReplicationGroup.[Status,Durability,EffectiveDurability]' --output text
modifying disabled disabled
変更中の状態は、次のコマンドを約10秒間隔で実行し、時刻と変更開始からの経過秒を付けて記録しました。出力の列は左から、Status、Durability、EffectiveDurability、MultiAZ、ノード数、シャードの Status です。
aws elasticache describe-replication-groups \
--replication-group-id my-valkey-cluster \
--query 'ReplicationGroups[0].[Status,Durability,EffectiveDurability,MultiAZ,length(MemberClusters),NodeGroups[0].Status]' \
--output text
計測結果
所要時間は、変更コマンドの実行から、Status が available で、かつ Durability と EffectiveDurability が要求した値（無効は値なし）になった最初の記録までの経過時間です。記録の間隔（約10秒）分の誤差を含み、各値は1回の測定です。
| 変更 | 所要 | 変更中の Status | フェイルオーバーのイベント |
|---|---|---|---|
| 無効 → 同期 | 約20分（1226秒） | modifying | 1回 |
| 同期 → 無効 | 約14分半（872秒） | modifying | 1回 |
| 無効 → 非同期 | 約20分（1195秒） | modifying | 1回 |
| 非同期 → 同期 | 約20秒 | available のまま | なし |
最初の変更の開始（02:00:55）から非同期 → 同期の完了（03:05:18）までに、レプリケーショングループには次のイベントが記録されました。時刻は UTC です。
2026-10-28T02:15:34.565000+00:00 Failover to replica node my-valkey-cluster-0001-001 completed
2026-10-28T02:30:57.668000+00:00 Failover to replica node my-valkey-cluster-0001-001 completed
2026-10-28T02:59:09.082000+00:00 Failover to replica node my-valkey-cluster-0001-001 completed
2026-10-28T03:05:13.990000+00:00 Successfully updated the durability setting to sync.
フェイルオーバーの3行は耐久性を有効化・無効化した3回の変更に1回ずつ対応し、03:05:13 の行は非同期 → 同期の変更に対応します。
非同期 → 同期の変更直後から同期になるまでの記録では、Status はすべて available でした。
03:04:56 +1s available async async enabled 2 available
03:05:07 +11s available async async enabled 2 available
03:05:18 +22s available sync sync enabled 2 available
まとめ
既存クラスターの耐久性を、クラスターを作り直さずに変更できました。変更中もクラスターはトラフィックを処理し続けます。
耐久性を有効化する変更と無効化する変更は、完了まで今回の環境で1回あたり約14分半〜約20分かかり、その途中で1回フェイルオーバーが起きました。フェイルオーバーの瞬間はクライアントの接続が切れることがあるので、有効化・無効化は、接続断をリトライや再接続で吸収できるワークロードであることが前提になります。
非同期から同期への変更は約20秒で、フェイルオーバーもありませんでした。
設計時から要件が変わり、耐久性の変更が必要になった場合は、今回のアップデートをご活用ください。
