はじめに
SREチームの中島です。現在は、株式会社アプリボットにて各種サービスの構築運用を行っています。
本記事は、 CyberAgent Group SRE Advent Calendar 2025 / Applibot Advent Calendar 2025 7日目の記事になります。
今回は、ElastiCache Serverless for Valkey を約1年ほど検証・運用してきた経験から、実運用で見えてきたポイントをまとめました。
ElastiCache Serverless は運用の手間を減らしつつ安価にスパイク耐性を確保できる選択肢として、検証環境だけでなく本番環境でも非常に実用的なサービスです。この記事では、実際に運用してわかった特性や監視のポイント、運用上の注意点について詳しく解説します。
また記事後半に、re:Invent 2025で発表されたばかりの Database Savings Plans for AWS Databases を適用した場合の所感についても記述しました。
本記事に含まれない過去の ElastiCache に関するまとめもありますので、合わせてご覧いただければと思います。( 昨年 / 一昨年 )
全体的な運用所感
ECPU の拡張スピードとスパイク耐性
実際の運用で改めて感じた ElastiCache Serverless の最大の強みは、ECPU の拡張が早く、スパイク耐性が優秀な点です。
(ECPU: vCPU 時間と転送データの両方を含むElastiCache Serverlessの処理単位)
30k ECPU/秒の最低保証値を超えた状態で、かつ数分でリクエストが5倍程度になる状態のかなりきついスパイクでも問題なく捌けています。
従来のノードベースの構成では「ピーク時の負荷に合わせてインスタンス構成を決定する」必要がありましたが、Serverless ではその作業が大幅に軽減されます。
スパイク耐性が優秀なので、CPU使用率をベースにしたクラスタ規模について頭を悩ませる必要がありません。
事前スケーリング機能の優秀性
スパイク耐性について、Pre-Scalingによりイベントなどに事前に対応を行うことができ、前例のない負荷に対して構成を変えずに大きめの備えをすることができるところも大きいです。
先述の実運用におけるスパイク耐性は、その規模以上の事前スケーリング設定を一度以上実行したことがあることも理由と思われます。
イベントの初回など、スパイクが発生する際の運用に際しては適切な事前スケーリングをお勧めします。
また、Pre-Scalingに関しては、解除に関して即座に影響なく実施できるため、多少多めにスケールさせておいても、イベント時刻を通過した時点で問題なければ速やかに解除できる点も運用上、およびコスト上のメリットです。
解除以降の挙動については、その時点でのECPU消費量に対して通常のスケール速度が適用されるため、一般的な運用では問題にならないものと思います。
ref: ElastiCache サーバーレスでの事前スケーリング
ECPU 費用について
上記のような運用が可能な結果、ECPU 費用はほとんどの場合、備えなければいけない規模に比較すると劇的に安いです。サーバレスサービスの面目躍如といったところでしょうか。
ただし、よく意識される GET/SET コマンド数の他に、 eval ベースコマンドなど普段意識していないものも ECPU消費 として計上されるので、事前に内訳を確認できるならなおよいでしょう（我々のケースでは、排他制御を行うミドルウェアが内部的にevalを多用しているケースがありました）。
利用メモリサイズの管理
逆にデータストレージ料金(メモリ費用)は高めで、オンデマンドノードと比較すると大体3倍程度になります。実際にevictionをなるべくさせないようなクラスタ構成を組んだ場合は以下のように1.5倍〜2.5倍程度になる可能性が高いです。
(※Serverlessの場合はさらにECPU費用が必要なことに留意)
| メモリ使用量100GBで 運用する場合の構成 (apne1) |
クラスタ容量 | データ単価/ インスタンス単価 |
ノード数 | クラスタ$月 | 対Serverless比 |
|---|---|---|---|---|---|
| Serverless MaxSize指定なし ※evictionなし |
100 | $0.101/hGB | - | 7272 | - |
| オンデマンド メモリ使用率50%運用 r7g.xlarge 26G * 8 レプリカ数1 |
200 | $0.4192/h | 16 | 4829.184 | 0.66 |
| オンデマンド メモリ使用率80%運用 r7g.xlarge 26G * 5 レプリカ数1 |
125 | $0.4192/h | 10 | 3018.24 | 0.42 |
そのため、利用メモリサイズを適切に管理することがオンデマンドクラスタの場合に比べより重要になります。
Keyに対するTTLの適切な設定などもありますが、ElastiCache Serverlessの場合はPre-Scaling機能の一環としてクラスタで利用できる最大データストレージ量を設定することができます。
この最大サイズを超えた場合は、TTLが設定されたKeyはevictionにより削除され、削除できるデータがない場合はOOMとなります。
興味深い現象として、我々の運用中には Max size の設定により Eviction がそれなりの規模で継続して発生していてもスパイク耐性を含んだパフォーマンスの劣化を観測できたことはありません。これにより、evictionの発生による処理性能低下をあまり気にせず、コスト最適化を優先できています。
Max size は現在利用しているデータ量以下には設定できないので、もし運用中のクラスタに利用中のメモリより小さな制限をかけたい場合は明示的にキーを削除するなどの対応をする必要があります。
ref: 削除できるデータがない場合、追加データを書き込むリクエストにはメモリ不足(OOM) エラーメッセージが表示されます。
エンジンバージョンの自動アップデートについて
ElastiCache Serverless の特徴の1つに、最新のマイナーバージョンとパッチをキャッシュクラスタに自動的に適用してくれる仕様があります。
実際に 2025/07 に Valkey エンジンが 8.1対応した際に、 Valkey 8系を指定した Serverless クラスタのエンジンが 8.1 に自動でバージョンアップがされています。
これはパッチ適用などの運用負荷を軽減してくれる反面、スナップショットの運用などで注意するべき点があるため、注意していただければと思います。
ElastiCache の仕様的に取得したスナップショットより古いバージョンで復元できない、かつ、クラスタ自体のダウングレードは現状できません。そのため、自動でクラスタのバージョンがアップされた後、万一データを古いバージョンに切り戻しなどの対応をしたい際は手動での dump → restore が必要になります。
バージョンの問題さえなければ、Serverless ⇔ オンデマンド間のデータ移行についてはスナップショットを経由することで問題なく実施可能なので、万一Serverlessで負荷的その他の問題が発生した際は、データをそのままオンデマンドクラスタに移行することは可能です。
もちろん、キャッシュデータをすべて破棄してよい場合はこれらの制限を気にすることはありません。
監視について
ThrottledCmds
ThrottledCmds は、何かクラスタに異常があったときの事実確認として利用しています。
運用当初は、Key Metricと考え検知したら即時にアラートするようにしていましたが、単発（1分間）の Throttle ぐらいだと本当に数ms程度のレイテンシ上昇が見られるだけでほぼ影響がなさそうでしたので、現在は数分以上継続した時のみアラートするように変更しています。
CloudWatch Metric Stream などを使わない限り CloudWatch からの検知にもラグがあるので、実際に影響があるような場合はアプリケーションエラーの方に先に現れてくる可能性が高いです。
Valkey(Redis) のアプリケーションエラー
ElastiCache for Serverless に異常が発生するのは、つまり内部的に管理されているクラスタに異常が発生した場合です。その場合、Valkey からのクラスタの異常メッセージをアプリケーションは受け取ることになります。
具体的には以下のエラーが観測される場合がありました：
- CLUSTERDOWN エラー
- READONLY エラー
ref: ElastiCache Redis クライアントでのエラーメッセージ トラブルシューティング
外部（我々ユーザー）から観測できるのは現状ほぼこの1点と言ってよく、クラスタの管理状態の可視化は今後期待したいところです。
運用におけるその他のポイント
事前スケーリング時のECPUの計算方法
事前スケーリングにおいて、ECPUは1秒あたりの値を指定する必要があります。
Cloudwatchメトリクスの ElastiCacheProcessingUnits メトリクスで表示されるECPU消費量は、1分あたりの合計値になっているため、例えば ElastiCacheProcessingUnits が 12,000,000 = 12M 消費している状態を事前スケールで担保したい場合は、これを60で割った値をスケール値に設定します。この場合、 12,000,000 ECPU / 60 = 200,000 ECPU/秒 を設定することになります。
ref: Choosing Metric Statistics and Periods - Amazon ElastiCache
All ElastiCache samples are published for a 60 second duration for each individual cache node. For any 60 second period, a cache node metric will only contain a single sample.
内部的に利用される PrivateLink のエンドポイント費用
公式の Pricing ページには記載がありませんが、PrivateLink のエンドポイントで費用がかかるため、厳密には最低料金の $6 ではありません。VPC エンドポイント時間あたりの料金が追加で発生し、$6+$10前後の費用(usリージョン計算)となります。
re:Invent で発表された Database Savings Plans の利用が可能という嬉しいニュース
re:Invent 2025 で発表された Database Savings Plans は、ElastiCache Serverless に対して適用可能であると発表されました。
ECPUおよびデータストレージ料金にそれぞれ30%の削減効果を適用できるため、前述のメモリ費用の高さという課題に対する有効な対策となります。
先述の費用図では対RIインスタンスでの費用差を含めていませんでしたが、1年前払いなしベースではその差がほぼなくなり(RIは約32%割引)、純粋にElastiCache Serverlessのサービス特性で選択ができるようになるかなり嬉しいニュースです！
まとめ
ElastiCache Serverless は数々のアップデートを経た結果、数あるクラウドサービスの中でも個人的に特にオススメできるサービスであると断言できます。
データストレージ料金がやや割高なことを差し引いても、総合的なコストを考えると優秀であり、その状態で高スパイク耐性・スケール性を担保できていることの安心感は大規模サービスの運用において計り知れません。
極論ですが、インフラ担当者が1週間寝込んでいる間に負荷が10倍になっていても全然平気、ぐらいの安心感があります。
本記事中では詳細に触れていませんが、Valkey 8.2 で対応がなされた vector searchも、ユースケースを考えるとServerlessが対応した場合にはServerlessでの利用がベストとなるのではないでしょうか。
ストレージ料金に対しても、Database Savings Plansが利用できるというケアがなされたことで、より運用に使いやすいサービスとなったと思います。
ここまでお読みいただいてありがとうございました。
株式会社アプリボット（applibot.co.jp/）のテックブログです！ 採用情報はこちら > applibot.co.jp/recruit/ 過去の技術ブログはこちら > blog.applibot.co.jp/
Discussion