ElastiCache Serverlessの登場から数週間が経過し、開発者はキャッシングの展望に興奮する理由を持っています。どのようなエコシステムにおいても、選択肢があることは良いことです。設計の観点からのサーバーレスアーキテクチャは、パフォーマンス、機能性、コストに基づいて選択されたコンポーネントの組み立てに焦点を当てています。このアイデアは、設計にできるだけ多くの双方向のドアを作ることで、何かが意図したとおりに全く機能しない場合、部品をより適切なものと交換できるようにすることです。

しかし、コストなど前もって知ることができるものもあります。サーバーレス・デザインにおけるコストは、使用量によって決定され、定義によれば、消費されていないときはゼロにスケールするはずです。最近リリースされたElastiCacheサーバーレス・サービスを見てみましょう。

ElastiCache Serverless pricing

ElastiCache Serverlessの価格には2つの部分があります。1つは保存されたデータで、もう1つはElastiCacheプロセッシング・ユニット（ECPU）に基づいています。表面的には、これは理にかなっています。データに対して支払い、コンピュートに対して支払います。しかし、もう少し詳しく見てみると、この仕組みにはいくつかのニュアンスがあります。

ElastiCache Processing Units (ECPUs)

ECPUは1KB単位で計算され、100万単位で課金されます。正確な価格は、100万ECPUあたり0.0034ドルです。このように考えると、キャッシュされるアイテムのサイズは、そのアイテムの書き込みまたはフェッチに支払われるコストに影響します。ECPUは、1KBの読み取りまたは書き込みあたりです。

Storage

AWSのドキュメントによると、ElastiCache Serverlessに保存されたデータは、1分ごとに複数回サンプリングされ、1時間ごとの平均値が作成されます。そして、その平均量が$0.125 / GB-Hrで価格設定されます。この価格設定の残念な点は、1時間あたり最低1GBを課金することで、真にサーバーレスであるというスケール・トゥ・ゼロの原則に違反していることです。この点を考慮すると、30日間の月では、ElastiCache Serverlessの最低利用コストは$90となります。31日の月では、この数字は93ドルになるのです。

価格設定例

設計を計画する際、プロセスの早い段階でコストを考慮することは重要です。そこで、2つの例を取り上げて、このAWSの新機能の使用量に基づくコストを見るためにいくつかのバリエーションをみてみましょう。

少ないストレージ

プロジェクトの開発初期を想定します。データ・ストレージ自体は少なく、ElastiCacheが設定するストレージの最小値1GBにも届いていません。ECPUがどのようにコストを押し上げるかを理解するために、以下では低容量と高容量の例を取り上げます。

少量 / 低ストレージ・アプリケーション

大容量/低ストレージ・アプリケーション

もう1つの例として、小さなキャッシュ・ストレージから読み取りを行う大容量のアプリケーションで、静的データのルックアップ・パフォーマンスを改善しようとしている場合を考えてみましょう。

ストレージの月額基本料金とほぼ同額のコストが発生するためには、1ヶ月あたり2億5,900万リクエストが必要です。ElastiCache Serverlessは、読み書きにかかるコストがコンピュートよりもストレージの方が300倍以上高くなります。

大容量ストレージ

ElastiCache Serverlessをどのように活用するのがベストかを考えるとき、キャッシュデータの量が増えるとコストの影響が出始めます。上記の例から、ECPUは100万ユニットあたり0.0034ドルであればそれほど高価ではありません。しかし、1GB時あたりほぼ$.13のデータは、かなり早く値上がりします。キャッシュする量によっては、そのコストはかなりのものになるでしょう。

大容量/大容量ストレージ・アプリケーション‍

容量が少ないのにストレージが多い例をモデル化しても、あまり意味がありません。キャッシュの中心的な目的のひとつはパフォーマンスを向上させることであり、それはデータアクセス時の待ち時間を減らすことを意味します。データのアクセス頻度が低い場合、キャッシュに入れるコストは、アクセス頻度の低さを正当化するものではないでしょう。

重いストレージと高い読み取りリクエストの例として、上記の1秒あたり10,000リクエストを想定します。しかし、500MBのストレージの代わりに、このデータはより顧客固有で大容量です。その総量は50GBです。

留意しておくべき事項

データ・ストレージがコストを押し上げる

ElastiCache Serverlessは、1時間あたりに保存されるデータ量が増えるにつれて、急激にコストが高くなります。コストをモデル化する際、設計にこのサービスが含まれている場合は、1時間あたりに保存されるデータ量に細心の注意を払ってください。GB時間単位で課金されるため、使用量がピークに達する時間が1時間あっても、ストレージの必要量が少ない時間が23時間あれば、コストは低く抑えられます。しかし、1日のうちに大量のストレージを消費する時間帯があれば、費用はすぐにかさみます。

ElastiCache Serverlessには最低使用量が設定されているため、ゼロへのスケーリングは不可能です。デプロイされるプロジェクトがまだ開発初期であれば、この量は手入れされた庭の雑草のように目立つでしょう。Lambda、SQS、EventBridge、DynamoDB、S3は、使用量やストレージがなければゼロにスケールします。その中にこのキャッシュ・サービスが入ると、1時間あたりゼロにはスケールせず、1時間ごとに$.125の課金が発生します。

ECPUsは “ほとんど無料”

ElastiCache Processing Unitsは、おそらく全体のコストにはあまり影響しません。100万ECPUあたり0.0034ドルで、これは例えばDynamoDBのRead Capacity Unitsが100万あたり25ドルであるのに比べればかなり安いといえます。もちろん、読み書きされる項目が非常に大きく、読み込みが多い場合はコストがかかります。しかし、キャッシュのほとんどの用途は、一般的に5KB以下の小さなペイロードであり、高い読み取りまたは書き込みスループットであっても、高額な請求は発生しません。

選択肢に戻る

現在、サーバーレス・エコシステムの最大の利点の1つは、アーキテクトやエンジニアがシステムを構築する際の選択肢の多さだ。上で見たように、ElastiCache Serverlessは、データストレージが少なくスループットが高い場合には、素晴らしいコストプロファイルを持ちます。しかし、ゼロにスケールすることができないことと、データストレージ周りの料金が高いことから、ソフトウェア開発ライフサイクル全体では苦戦しています。

開発、QA、プリプロダクション、プロダクションの4つの環境での影響を考えてみましょう。コンピ ュートを消費しない場合、請求額は360ドル（90ドル* 4環境）です。しかし、多くの場合、これは多くのシナリオでコスト的に不可能であり、リソースの有効活用とは言えません。そして、コスト＝持続可能性であることを忘れてはなりません。

Momentoは、コストに関して言えば、いくつかの重要なシナリオにおいてElastiCache Serverlessに代わる説得力のある選択肢を提供します。

・非本番環境でのコストと利用 – Momentoは、ゼロまで拡張できる従量課金制を採用しています。利用しないときは、費用は一切かかりません。データとコンピューティングの分割はありません。
・大小のペイロードで低利用率 – 最低料金のないMomentoの価格設定が光ります。
・使用量は多いが、ペイロードサイズは小さい – $.50 / GBのデータ転送で、最初の5GBは無料です。

上記の例で、1KBのペイロードサイズで、10、100、10,000リクエスト/秒の例を見てみましょう。

まとめ

ElastiCache Serverlessは、AWSのサーバーレス・エコシステムにおける素晴らしい一歩です。価格設定はGB時間単位で非常に素晴らしく、読み取りと書き込みは非常に開発者に優しい。主な欠点は、1GBのストレージのベースラインに対して1時間あたり0.125ドルの最低料金がかかることです。特にMomentoのキャッシング・サービスのような他の真のサーバーレス・コンポーネントの価格設定と比較した場合、このゼロにスケールできないことは、初期段階の製品や機能にとって法外です。

アプリケーションのニーズと使用方法を理解することは、提供される機能にコスト面で影響を与える設計上の考慮事項を形成するのに役立ちます。

もしこの機能が最初から最低1GB以上のデータを保存し、それを下回らないのであれば、100万ECPUあたりのコストは非常に優しく、他のサーバーレスのコストとうまく調和するはずです。しかし、それは総コストと、すべての環境でゼロにスケールできないこととを天秤にかける必要があります。さらに、Momentoの従量課金モデルに見られるように、必要なペイロードとデータをモデル化することは、コストに多大な影響を与える可能性があります。

繰り返しになるが、選択は良いことです。キャッシュの決定は、システムの設計において一方通行のドアであってはなりません。賢く選択し、実験を恐れないでください。そして、最終的な設計にはコストも要素として含めること。コスト＝持続可能性であることを忘れないでください。

この記事についてご質問がありますか？benjamenpyleにツイートするか、LinkedInでご連絡ください。技術プログラミング、AWS、サーバーレスに関するより多くの洞察については、私のブログをチェックしてください。

ベンジャミン・パイル

著者

Benjamen Pyle is a technology executive and software developer with over 20 years of experience across startups and large enterprises. He is Co-Founder and CEO of Pyle Cloud Technologies, an AWS-focused cloud consultancy specializing in cloud strategy, architecture, training, and cost optimization. He’s also an AWS Community Builder recognized for his deep expertise in serverless computing, event-driven architecture, and cloud-native and containerized solutions. When Benjamen doesn’t have his head in the clouds, he’s either playing golf with his wife and two boys or outside with their 12 paws.