Amazon ElastiCache Serverlessのエンドポイントの実態はVPCエンドポイントでした
初めに
Amazon ElastiCache Serverlessはそれ以前から登場している自身でノードを管理するタイプと異なり、CPUやメモリと言ったリソース量、可用性部分がマネージドに管理されるよりシンプルに利用できるインメモリキャッシュサービスとなります。
RDB方面でいうところのAurora ServerlessのElastiCache版に近いものだとイメージしてもらうのがわかりやすいかと思います。
しばらく前ですがリソースの棚卸しをしていたところ見覚えのないVPCエンドポイントを見つけ、おや？となり実態について調べたところこのElastiCache Serverless関連でしたので備忘録として確認した点を残しておきます。
ElastiCache Serverlessのノード実態はユーザ管理VPCにはない
先にまとめ的な話になるのですがElastiCacheのアーキテクチャについてはドキュメントに明確に公開されていました。
実態としてはユーザ管理VPCにはなくAWS管理領域にあるNLBの裏でRedis(or Valkey)のノードが動いている形となり、直接ユーザ側VPCで実態を持たない形で管理しているようです。
後ほど実際のリソースを見ていきますが、作成時にAWS管理のVPCエンドポイントが作成されそれを通してアクセスする形になります。
なお何度か作成してみましたが、上記の画像でVPCエンドポイントが3つなのはイメージ像ではなく実際に常に3つ固定で作成されるようです。
なのでElastiCache Serverlessの実態としては特別なアーキテクチャで提供されているというよりは、従来のノード管理タイプで考慮しないといけない、スケーリングや障害からの回復、Redisのマイナーパッチの適用をよしなにできる堅牢な仕組みをAWSで用意し、それをユーザ側にはVPCエンドポイントで隠蔽し提供するようなサービスとなりそうです。
マネジメントコンソールから見た場合
実際にリソースを作成して実物を確認してみましょう。
ElastiCacheのリソースを作成してみると、以下のようにVPCエンドポイントが複数作成されます。
サービス名にelasticache.serverlessという文字があるに加えてタグを見てみるとElastiCacheManaged: trueという値もあるのでなんとなくそれっぽいなというのがわかるかなと思います。
一応AWS管理リソースではあるものの、半年以上動かしている環境を見ていてもこれまでVPCエンドポイント自体が置換されたというのは見たことがないので、Nameタグ等をつけておくとどのクラスタのものであるか判別しやすいので作成時につけておくのが良いかもしれません。
※ ドキュメント上に置換されるような挙動の記載はないものの、現時点での動作ベースで保証するものではないためご注意ください
サブネットのタブを見てみるとそれぞれ2つのENIが割り当てられていますが、これに関しては作成してみる限りElastiCache側の設定に応じて変動するようで、２サブネット割り当てればここが2つ、３サブネット割り当てれば3つになるようです。
VPCエンドポイントの数は3つで固定でしたので、Serverlessを作る際には割り当てAZ数(=サブネット数)*3のIPを消費する形で計画しておくとよさそうです(2AZ=6 IP、3 AZ=9 IP)
ユーザ側で提供されるインターフェースがVPCエンドポイントということは？と思いElastiCache側のエンドポイントの名前解決をしてみたところ、先ほど記載したVPCエンドポイントのIPと完全に一致するためこの点からElastiCache Serverlessのエンドポイントの実態=先ほどのVPCエンドポイントであることが確認できます。
% dig serverless-test-xxxxxx.serverless.apne1.cache.amazonaws.com
; <<>> DiG 9.10.6 <<>> serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56514
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. IN A
;; ANSWER SECTION:
serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN CNAME default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com.
default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN A 192.168.4.253
default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN A 192.168.3.12
default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN A 192.168.3.113
default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN A 192.168.3.107
default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN A 192.168.4.238
default.serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com. 15 IN A 192.168.4.70
なので一応Redisクライアント側から直接VPCエンドポイントに向けても通信は可能ではあります。
(ElastiCache側のエンドポイントのIPが直接このVPCエンドポイントを向いているので経路自体は変わらない。ただし1つのVPCエンドポイント(=裏の構造で言えば単一のNLB?)に集中するのであえてやる意味はない)
$ redis6-cli --tls -h vpce-008xxxx.vpce-svc-0428bxxxx.ap-northeast-1.vpce.amazonaws.com
vpce-008ccxxxx.vpce-svc-04xxxx.ap-northeast-1.vpce.amazonaws.com:6379> info
# Server
redis_version:7.2
server_name:valkey
valkey_version:8.1
redis_mode:cluster
os:Amazon ElastiCache
arch_bits:64
run_id:0
# Replication
role:master
connected_slaves:1
slave0:ip=serverless-test-xxxxx.serverless.apne1.cache.amazonaws.com,port=6380,state=online,offset=0,lag=0
# Cluster
cluster_enabled:1
vpce-xxxxx.vpce-svc-xxxxx.ap-northeast-1.vpce.amazonaws.com:6379>
$ redis6-cli --tls -h vpce-0439xxxx.vpce-svc-00fdxxxx.ap-northeast-1.vpce.amazonaws.com
vpce-04xxxx.vpce-svc-00exxxx.ap-northeast-1.vpce.amazonaws.com:6379> info
# Server
redis_version:7.2
server_name:valkey
valkey_version:8.1
redis_mode:cluster
os:Amazon ElastiCache
arch_bits:64
run_id:0
# Replication
role:master
connected_slaves:1
slave0:ip=serverless-test-xxxxxx.serverless.apne1.cache.amazonaws.com,port=6380,state=online,offset=0,lag=0
# Cluster
cluster_enabled:1
VPCエンドポイント分の追加の料金はかからない
インターフェース型のVPCエンドポイントは1つ当たり$0.01/h(東京リージョン、記事執筆時点)の料金が発生するのですが、今回検証のために作成したアカウントおよび実際の稼働環境の料金を確認する限りその料金の発生はありませんでした。
以下は私の検証環境で実際に立ち上げた時の請求情報ですが、ElastiCache Serverlessの請求はあるものの、VPC項目内にVPCエンドポイントの請求がないため請求対象とならないことが確認できます。
そのためElastiCache側の料金表の通り保存データ量とECPUで計算すればよさそうです。
ElastiCache Serverless キャッシュは、保存されているデータ最低 1 GB に対して計測されます (ElastiCache for Memcached と ElastiCache for Redis OSS の場合)。ElastiCache Serverless for Valkey では、サポートされている他のエンジンと比較して、料金が 33% 低く、最小データストレージ 100 MB が 90% 少なくなるため、コストをさらに最適化できます。
１点注意点としてServerlessは常に一定メモリを確保するためほとんど利用がない時間でもこの分の料金が発生します。
Valkeyは最小が100MBのためまだ少ないですが、Redisは1GB必要かつ$0.151/h・GBで最低でも$110/月近くが実質的に維持費として発生するため気をつけましょう(執筆時点の料金)。
終わりに
VPCエンドポイントは一回作ると棚卸しの機会でもないと見に行くことがないので今回調査は実態を知る良い機会になりました。
Serverlessというとすごい良い感じに提供側でやってくれる仕組みだなーくらいでなかなか裏の仕組みは公開されてないものが多いので、こうやって公開されているのはちょっと珍しいなという感じはします。
サービス料金だけ見てしまうとServerlessは時間単価高く少し手が伸びづらいサービスではありますが、あの金額でこれだけ堅牢アーキテクチャのものをユーザ側で管理することなく利用可能と考えると意外とお手頃というか納得の料金という感じはします。
とはいいつつServerlessタイプ料金はノードを自分で管理するタイプに比べて相対的にお高めではありますので、費用は出せるしある程度制約があっても管理を楽にしたいServerless、自由度が高くサービス的には安価ではあるけどその分管理が必要なノードタイプと環境によって使い分けていきましょう。
