12/11にクラスメソッド大阪オフィスで開催されたre:Invent2023の振り返りイベントre:Growth 2023 OSAKAで登壇する予定でしたが、前日に肉離れを起こしまして出社できなくなったため急遽、登壇をキャンセルさせていただきました。当日、登壇にてご紹介予定だった内容を記事として供養します！
スライド
特徴
1分以内にキャッシュを作成
実際に何度か試してみてもステータスとてAvailableになるまでは2〜3分程度掛かったのはご愛嬌。従来のクラスタも試しに作ってみると15分以上掛かったので、これまでと比較すれば爆速です。
キャパシティプランニング不要
そして何より運用負担の大きかったであろう、キャッシュのクラスタ運用の大部分から解放されるのは最大のメリットです。
高可用性
ElastiCache Serverlessは自動的に複数AZでレプリケートされます。また、マイナーバージョンやパッチ適用は自動的に行われます。下位互換性がなくなるようなメジャーバージョンアップについては通知されたうえで、いつでも行うことが可能です。そのうえで、SLAは99.99%を実現します。
単一エンドポイント
ElastiCache Serverlessへの接続としてクライアントが意識するのは、たった1つのエンドポイントのみです。従来のクラスタであればノードやシャードが追加されたことをAuto Discoveryやポーリング等によって何かしら検知する必要がありましたが、ElastiCache Serverlessでは不要です。単一エンドポイントはクライアントとキャッシュノードをつなぐためのプロキシとして提供されており、クライアントからのリクエストをルーティングします。
"引用元：AWS re:Invent 2023 - [LAUNCH] Introducing Amazon ElastiCache Serverless (DAT342)"
低レイテンシー
読み込みについてはp50で1ミリ秒以下、書き込みについても1.1ミリ秒と非常に低レイテンシーです。また、クライアントからのリクエストはローカルAZのプロキシにルーティングされますが、読み込み先としてもローカルAZノードを優先するためにRead from Replicaオプションをクライアント側で有効にすることがベストプラクティスとして紹介されていました。
従量課金
料金の構成はストレージ料金およびElastiCache Processing Units（ECPUs）の2つの要素があります。ストレージ料金はGBあたり$0.151/hですが最小で1GBからの課金となっている点はご注意ください。なお、ストレージの使用量については1時間ごとの平均値によって算出されます。
ECPUsについては、転送データ1KBあたりを1ECPU、vCPU消費を1ECPUとして算出します。通常の3倍のｖCPUを消費する処理の場合、3ECPUになります。転送データとvCPUのECPUについては足し算ではなく、どちらか高い方に基づいてECPUが消費されます。
- 単純なSET/GETコマンドの3倍のvCPU時間を消費し、3.2KBのデータを転送する場合、3.2ECPUを消費
- 単純なSET/GETコマンドの3倍のvCPU時間を消費し、2KBのデータを転送する場合、3ECPUを消費
高いセキュリティ
VPCを必要とする点がElastiCache Serverlessのデメリットとして取り上げられがちですが、それは非VPC Lambdaからの利用を想定した一面でしかありません。そもそも従来のElastiCacheクラスターの置き換えと考えるならばネットワーク的な課題は何もありません。
たしかにSaaSキャッシュサービスと比較する場合において、VPC等のネットワークを意識せずに利用できる手軽さは魅力的ではあります。一方で本番環境や扱うデータによっては、よりセキュアな通信経路を希望されるケースも少なくありません。SaaSキャッシュサービスにおいても、そういった声に応えるべくVPC PrivateLinkのオプションが提供されていますが、多くの場合はEnterpriseなどの上位プラン（最低料金の設定あり）が条件となっています。
そのようなことを考えると、小規模な環境からでもVPCでプライベートネットワークとして接続出来る点はメリットになる、という考え方も出来るのではないでしょうか。
スケーリングの仕組み（概要レベル）
ElastiCache Serverlessが動的な垂直スケールや、迅速な水平スケールを提供可能としている裏側には「Caspian」という新たなEC2プラットフォームの存在があります。Aurora Serverlessや、同じくre:Invent2023で発表されたAurora Limitless DatabaseもCaspian上で提供されています。
スケーリングには「検知」「プロビジョニング」「データのリバランシング」の三段階のフェーズがあります。
検知
検知は1秒以内に行われ、利用パターンをモニタリングしています。また、モニタリングするだけではなく、将来必要とされるリソースの需要を予測する機能を持っています。これにより、プロアクティブに前もってリソース拡張しています。
プロビジョニング
追加のリソースが必要と判断された場合に、そのプロビジョニングは1分以内に完了します。ウォームプーリングという待機モードのノードを保持しておくプールから、必要とされるクラスタにアタッチすることで迅速なスケールアウトを実現しています。
データのリバランシング
ElastiCache Serverlessのスケーリングにおいて特徴的なのは、まず動的な垂直スケールによってノード単位のサチュレーションを回避しつつ、並行して水平スケールを行う点です。時間を要する水平スケールが完了するまでの時間を、垂直スケールによって時間稼ぎをしている、といったイメージです。このような仕組みが行える裏にはCaspianの存在があります。
また大量のデータ移行を迅速化するために、ネットワークバッファ強化、コネクションの再利用によるオーバヘッドを削減しています。また従来であればレプリケート後にパージ処理が行われていましたが、レプリケートとパージ処理も並行して実行可能になり、全体としてスケーリング性能が向上しているようです。
注意点
パラメータグループは使用されず、すべてのRedisコンフィギュレーションは変更できません。Redisパラメータについてはドキュメントを参照ください。 また、Serverlessなので当然ですがリザーブドインスタンスの提供はありません。
特に言及されているものは見つけれてないのですが、従来のクラスタではスローログやエンジンログをCloudWatch Logs等に配信することが可能でしたが、ElastiCache Serverlessではそのような設定項目が無かったので、ログ配信機能は無さそうです。
またCLUSTER INFOなどで、どのようにクラスタがスケールしているかを確認しようと試みましたが、CLUSTERコマンドで取得される情報は単一シャードの情報として返されるため、クラスタ全体での状況を把握することは出来ません。公式ドキュメントにも、そのように記載があります。
Returns information about the state of a node. In a serverless cache, returns state about the single virtual “shard” exposed to the client.
ポジティブに解釈すればユーザーがクラスタ全体のリソース状況を把握する必要はない、ということでしょう。
さいごに
是非、大阪リージョンでお試しください！
0
