DynamoDBのインフラコスト構造と削減策 - ゆううきブログ

Amazon DynamoDBは、RDSのようなインスタンスサイズによる課金モデルではなく、ストレージのデータ使用量とスループットを基にした課金モデルになっている。 インスタンスサイズによる課金モデルでないデータストア系サービスとして、他にはS3、Kinesisなどがある。 これらは、AWSの中でも、フルマネージドサービスと呼ばれる位置づけとなるサービスだ。 フルマネージドサービスは、ElastiCacheのようなそうでないものと比較し、AWSに最適化されていて、サービスとしてよくできていると感じている。 Mackerelの時系列データベースのスタックの一つとして、DynamoDBを採用している。 時系列データベースの開発は、コストとの戦いだったために、それなりにコスト知見が蓄積してきた。(時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ) (※ 以下は、2018

[y_uuki]

書いた

[kaerucircus]

よいまとめ。本当にいちいちwriteする必要があるのか等アーキテクチャ再考のきっかけにすると良いよね。autoscaleは必須だけど縮退時に性能劣化あるのは注意。redis clusterも結構コスト掛かるしそれに比べると安いよなあ

[takuya-a]

DynamoDBのコスト分かりづらいので助かる

[dekokun]

わかりやすい。

[yarumato]

“DynamoDBで時系列データベースの開発。知見が蓄積。大容量データをひたすら保持するより、エンドユーザに同期的応答するケースに向いている。writeのコストが大きくなりやすい。1KB単位にデータを詰め込んで書き込む”

[mapk0y]

DynamoDB や s3 の VPC エンドポイントは Private link と違って DNS の制御できないんだな～

[tmatsuu]

とても良い。

[tatsu_tora]

昔dynamoで百万近く溶かした事あって、結局辞めたんだけど、あれは適した使い方では無かったんだなと

[FumblePerson]

良いまとめ（LSIはプライマリのSort Keyと同じ物理配置になるから別途Writeコストはかからない認識）

[stk132]

これっすよね "メインDBとなるMySQLやPostgreSQLはwriteスケールアウトしづらいため、DynamoDBを使いたいケースにはwriteが支配的であることは多いように思う。"

[tofu-kun]

むずい

[akatakun]

特定プライマリキーにreadまたはwriteが集中すると、テーブルのキャパシティを増やしても、1つのノードの性能限界にあたってしまう

[hiromichinomata]

“DynamoDBは、writeが支配的なワークロードで、コストが大きくなりやすい” “DynamoDBを使いたいケースにはwriteが支配的であることは多い”

[kakku22]

素晴らしいまとめ．確かにコスト計算難しすぎてわかってない