ElastiCache検証：Valkey化でアップデートされた Serverless 導入のポイントとValkey 8.0について
SREチームの中島です。
こちらは Applibot Advent Calendar 2024 1日目の記事になります。昨年は「新世代ElastiCache for Redisの性能：マルチコアを効率的に利用できるRedis7.1+Graviton3」という記事で参加させていただきましたが、今年はトップバッターを飾らせていただくことになりました。昨年の記事ともどもよろしくお願いいたします。
この記事では、ElastiCache for Valkey の発表によってより気軽に導入できるようになったElastiCache Serverlessの導入時のポイントを、2024年11月21日にリリースされたばかりの Valkey 8.0対応 を含めまとめました。
ElastiCacheにおけるValkey7.2およびValkey 8.0
ElastiCache Serverlessに関するまとめが本記事のメインなのですが、発表されたばかりで皆さん気になっていると思われるValkey 8.0に関するパフォーマンスについてを前段としてまとめておきます。（ValkeyはRedisの7.2をベースとして2024 年 3 月にプロジェクトが開始されたRedis OSS の代替製品です。）
結論から言うと、昨年検証で確認したような新バージョンでの大幅な性能向上は特に発生していません。
今回の ElastiCache for Valkey 8.0 の改善点を公式ブログから引用してまとめると以下のようになります。
- Serverless では、スケールスピードが 5 倍に向上 (これまで10分 で 2 倍だったところが、2 分で 2 倍に)
- Node-base では、メモリ効率が改善され最大 20% 程度の使用量の低減が可能に
特に公式ブログでもRPSベースのパフォーマンスの向上に言及がありませんね。
手元でも何度か昨年と同じ設定にて Redis 7.1 / Valkey 7.2 / Valkey 8.0 にそれぞれmemtier_benchmarkをかけてみましたが、まあm7g系のGraviron3インスタンスのCPU個体差（5〜10%程度のブレ）かな…？という範囲に収まっています。
とはいえRedis 7.1 の段階で良いパフォーマンスを発揮していることは間違いありませんし、先日発表されたElastiCacheのRIサイズ柔軟性についても「エンジンの変更に追従する」（Redisで購入したRIをValkeyでは0.8の係数でそのまま利用できる）という素晴らしい変更が入っていますので、既存システムでRIを含んだ導入がされていても問題なくValkey8.0にアップデートして良いと思います。
その他確認できたValkey 8.0での変更点など
lazyfree系のオプションがvalkey8のパラメータグループでは変更（指定）できなくなっています。OSS版でもvalkey8からすべてデフォルトonになっています。
また、これはValkey7.2からですが、後述するServerless用だったメトリクスであるSuccessfulWriteRequestLatency/SuccessfulReadRequestLatencyがオンデマンドノードでも取得できるようになっているようです。
補足：OSS版Valkey はValkey 8.0 で速度の改善あり
OSS版Valkeyについては、Valkey8.0へのアップデート時にスループットが Valkey 7.2 と比較して230%上がる等の結果が出ています。しかし、この Valkey 8.0 のスループット改善は、ElastiCache に既に導入されている技術 (Enhanced IO and Multiplexing)のバックポートであることが同記事中で明記されています。
ElastiCache Serverlessについて
2024年における各種改善
さて、本題となるElastiCache Serverlessについてです。
2023月11月の発表時は、後述する設定面の注意点を除き、以下のような内容でした。
- Redis 7.1 から利用可能、ECPU+メモリ消費量による料金、最低利用料金（ストレージ1G）あり
- ストレージ1Gあたりの時間費用$0.151(apne1)＝月あたりの最低利用料金約$108
当時apne1でRedis7.1のt4g.micro（0.5GB）を選択した場合、時間あたり$0.025＝月約$18でしたので少し差が大きく、運用が楽になるとはいえすぐに全部切り替えよう！とはならない印象でした。
その後、2024年に入り以下のような改善が行われています。
- (2024/3) ECPUの最低値を指定することによる事前スケーリングが可能となる
- (2024/10) Valkey化の発表に伴い、エンジン変更の値下げ（-33%）とストレージ最低利用量の100MBへの引き下げ＝最低利用料金月あたり約$7.2 (apne1)
- (2024/11) Valkey 8.0 で自動スケール速度の改善
特にValkey化により料金面で改善が行われたことで、Redisおよびオンデマンドノードと比較した場合を表として起こしてみると以下のようになります。
| 表：月額あたり費用(apne1) | Valkey 7.2/8.0 | Redis 7.1 |
| t4g.micro | $14.4 | $18 |
| t4g.micro (RI1年前払いなし) | $9.9 | $12.4 |
| serverless (最低価格) | $7.2 + α | $108 + α |
ECPU値の指定によるスケーリングのコントロールができるようになっていることもあり、検証環境、本番環境ともにElastiCacheをServerless化するなら今！という状況が整ってきています。
ElastiCache Serverless導入時のチェックポイント
実際の運用における変更点をまとめていきます。まず、そもそもの話ではありますが、Serverlessの導入には条件があります。
- tls（転送中の暗号化）が必須である
- クラスタモードのみ利用できる
- パラメータグループは指定できず固定である(doc)
- maxmemory-policyはvolatile-lru固定
- timeoutは0固定
検証環境などではtlsを有効にしているケースは少なそうです。Serverlessを利用する場合はマルチaz・クラスタ前提で、仮想化されたServerless内部のレイヤーが増えると思われるため、既存プロジェクトにServerlessの導入を行う場合はこの部分の影響をきちんと把握しておく必要があります。
設定ごとのレイテンシの違い
Serverlessと今までのクラスタでレイテンシにはどんな差があるか、低負荷の状態で確認してみます。ElastiCache側はすべてValkey8を使用し、apne1のaz4にあるEC2インスタンスからmemtier_benchmarkのオプションをコネクション数10(-c 10)、コネクションあたり1000rps程度に絞った状態でのレイテンシを計測しました。
| 項目 | Instance type | az | tls接続 | クラスタ | serverless | 平均レイテンシ （低負荷時） |
| (1) | m7g.large | az4 | 約0.1ms | |||
| (2) tls | m7g.large | az4 | ◯ | 約0.1ms | ||
| (3) tls+cluster | m7g.large | az4/az1 (マルチaz) | ◯ | ◯ | 約0.8ms | |
| (4) tls+cluster | m7g.large | az1のみ | ◯ | ◯ | 約1.5ms | |
| (5) serverless | serverless | (az4/az1) | ◯ | ◯ | ◯ | 約1.7ms |
Serverless（5）の場合、すべて違うazにあるnodeへのアクセス(az4→az1)が発生するクラスタ構成（4）の場合よりほんの少しだけ遅い結果となりました。通常のマルチazクラスタ（3）の場合は同一azからの応答は早いのでその差はありますが、Serverlessのレイヤが存在してもほぼaz間のレイテンシに起因すると思われる差だけで、極端に遅いわけではないことがわかりました。これなら早めに既存のクラスタと置き換えることも可能な範囲内に思えますね。また、必要によっては同一azからのみ読み込むオプションポートの利用が可能です。
運用に必要なServerless用のメトリクス
最後に、運用に必要なメトリクス周りを整理します。Serverlessの監視には専用のメトリクスを使うことが必要です。主な違いを上げると、
- CPU使用率
- CPUUtilizationの値がないため、ElastiCacheProcessingUnitsの消費量で代用
- メモリ使用率
- 最大メモリやメモリ利用率の概念がないため、BytesUsedForCacheによるメモリ使用量で代用
などがあります。いずれの場合も、スケーリング設定で設定したECPUsやストレージ使用量についてはCloudwatchには反映されていませんでした。上限を設定しないスケーリングの場合は問題ないですが、スケーリング上限を設定した運用を行う場合は明示的に上限に対するアラートを設定したほうが良さそうです。
また、ストレージに関しては100MBを超えた分は従量課金になるので、CurrVolatileItems/CurrItemsの比率をチェックしTTL未設定の不要なキーが累積していないかチェックするのがより重要になってくるかと思います。
まとめ
ElastiCache Serverless は Valkey 化によりコスト面の懸念も解消し、検証環境・本番環境を問わない多くのユースケースでServerlessへの移行が現実的になっていそうです。セキュリティパッチなどその他の運用面で楽になる点を考えても、今後はServerlessへの移行をどんどん進めたいと思える内容でした。
オンデマンドノードについても昨年の記事で要望を上げていたRIの柔軟性向上が行われるなど運用面での改善が進んでおり、特にValkeyへのエンジン変更がサポートされていることについては、既存プロジェクトへのValkeyの導入ハードルをほぼなくしてくれるかなり嬉しいポイントかと思います。
ここまでお読みいただいてありがとうございました。
この記事へのコメントはありません。