![[アップデート] Amazon ElastiCache for Valkey で既存クラスターの耐久性（durability）を変更できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-c7d483f10fc34f2be56f1a37c8fc65f7/8d3a05910fb22a9bc4727b93c25b846d/amazon-elasticache?w=3840&fm=webp)
[アップデート] Amazon ElastiCache for Valkey で既存クラスターの耐久性（durability）を変更できるようになりました
いわさです。
Amazon ElastiCache for Valkey には耐久性（durability）という概念？設定？みたいなものがあります。
有効化するとキャッシュに書き込んだデータを Multi-AZ のトランザクションログに永続化してくれて、障害時のデータ保護が出来たり素早く復旧できるようになったりします。ほぼ永続データストアみたいな感じで使えるようになります。
この耐久性ですが、さらに「同期書き込み（sync）」と「非同期書き込み（async）」の2つのモードみたいなものがあります。
sync はクライアントへ応答する前に2つ以上の AZ へ永続化するのでデータロスを抑えられますが、その代わり書き込みレイテンシが1桁ミリ秒まで上がってしまいます。
一方 async は応答した後に永続化するのでマイクロ秒のレイテンシを保てますが、まれな障害時に最大10秒ぶんのデータを失う可能性があるそうです。
まぁ要件に応じて使い分ける形になるわけですが、これまで既存クラスターの耐久性は後から変更できず、設定を変えたいときはクラスターを作り直す必要がありました。
これが先日のアップデートで、既存のノードベースクラスターの耐久性を、作り直さずに有効化・無効化・切り替えできるようになりました。やったぜ。
今回こちらを確認してみたので紹介します。
切り替えてみる
まぁあとは切り替えるだけなので、おもしろさはあまりないのだが、やってみましょう。
まず前提として、耐久性の変更にはいくつか条件があります。
公式ドキュメントによると次の要件を満たすクラスターが対象とのことです。
- The cluster runs Valkey 9.0 or later.
- Multi-AZ is enabled with at least one replica per shard.
- The cluster has encryption in transit (TLS) enabled.
- The cluster uses Cluster Mode Enabled (CME).
- The cluster is not an ElastiCache Serverless cache.
- The cluster is not part of a Global Datastore.
対応するノードタイプも R8g / R7g / R6g / M8g / M7g / M6g / C8gn / C7gn に限られていて、t 系のバーストノードは使えません。
今回は東京リージョンで Valkey 9.0、クラスターモード有効、Multi-AZ、レプリカ1、TLS 有効の cache.r7g.large のクラスターを、耐久性 async で作成しておきました。
この状態のクラスターを、稼働させたまま sync に切り替えます。
コンソールの場合はクラスターの「変更」画面（Update cluster）で耐久性の設定を変えて保存します。
変更を適用すると、ElastiCache が稼働中のクラスターに対して設定変更を進めます。
切り替えが終わると、イベントに耐久性の更新も記録されていました。
切り替え後の状態を確認すると、耐久性が sync になっていました。
設定した値（Durability）と、サービスが実際に解決した有効値（EffectiveDurability）がどちらも sync になっています。
async と sync の切り替えは数十秒ほどで終わり、クラスターのステータスも available のまま推移することが多かったです。
何度か async と sync を行き来させましたが、そのたびにイベントへ耐久性更新が記録され、期待どおり切り替わっていました。
切り替えるだけじゃなくて無効化も出来ます。
ただ、async や sync のときと違い、無効化はちょっと挙動が違いました。
クラスターのステータスが modifying に変わり、しばらくその状態が続きます。
ドキュメントにも、耐久性の変更はノード置換を伴い、シャードごとにプライマリの交代や自動フェイルオーバーが発生すると書かれています。
Changing the durability mode involves node replacement. For each shard, this causes a brief primary node change or an automatic failover.
実際に disabled へ切り替えたときの様子が先ほどのイベントログ画面になるのですが、イベントにフェイルオーバーの完了（Failover to replica node ... completed）が記録されていますね。
なお、耐久性を sync や async にすると保管時暗号化が自動で有効になります。
今回のクラスターも async で作成した時点で保管時暗号化が有効になっていました。
ただし、ドキュメントによると無効化しても保管時暗号化は無効化されないと書かれています。
Changing the durability mode to
disabledlater does not disable encryption at rest.
実機でも disabled に切り替えた後のクラスターは保管時暗号化が有効なままでした。
一度暗号化が有効になると、耐久性を無効化しても暗号化は維持される仕様のようだ。問題になることは多くないと思いますが、ここはちょっと気をつけましょう。
なお、耐久性の変更は、クラスターのステータスが available になっただけでは成功と判断できないそうです。
これは、変更が失敗するとロールバックされることがあるためのようで、ドキュメントによると available になった後に EffectiveDurability が要求した値と一致しているかを確認するよう案内されています。
A status of
availabledoes not by itself confirm that the change succeeded, because a failed change can roll back. After the cluster is available, confirm thatEffectiveDurabilitymatches the durability mode you requested.
今回の検証では sync・async・disabled のいずれも、切り替え後に EffectiveDurability が要求どおりの値になっていました。
disabled のときだけは EffectiveDurability が値を持たない状態（null）になっていました。
なお、耐久性の変更は単独の変更として実行することが推奨されています。
他の設定変更と同時にリクエストすると変更アクションが拒否される、とドキュメントには記載があります。
Change the durability mode as a standalone modification. ElastiCache rejects a
ModifyReplicationGrouprequest that changes durability together with any other modification.
切り替え自体はクライアントの接続が一時的に切れる可能性があるので、計画されたメンテナンス時間に行うのが無難そうです。
あるいはクライアント側は再接続とリトライを実装しておくとかですかね。
さいごに
本日は Amazon ElastiCache for Valkey で既存クラスターの耐久性（durability）を変更できるようになったので試してみました。
稼働中のクラスターの耐久性をそのまま変えれますよってだけではあるのですが、変更したかったけどクラスター作り変えるのはな...と思っていた方はぜひ試してみてください！
前提条件だけ気をつけましょう。
