Zenn
😇

DynamoDBの料金で失敗しないために。~俺みたいになるな~

2021/08/01に公開
AWS
DynamoDB
#
失敗談
tech

事件は突然に

私は社内用の、Twitter クローリングツールを作っていた。
DBとしてこれまで使ったことがなかったが、大規模なクローリングと相性の良さそうな NoSQL の DynamoDB を採用した。
サイドプロジェクトで期限もタイトな1人プロジェクト、とりあえず serverless framework で AWS のリソースを管理していた。

DynamoDB は思ったより簡単に実装でき、「キャパシティというものの大きさによって金額が変わる」らしいので、「一時的にたくさん書き込むだろうから、とりあえず大きくして様子を見よう」と思い Read / Write Capacity を 1000に設定した。

... 次の日　Slack を見ると、先輩から連絡が
「AWS の費用爆増しているけど、大丈夫？」
変な汗をかきながら AWS のコンソールを確認。DynamoDB が 40$ くらい増えていた。

※ この記事は、DynamoDB の費用を最適化させるための覚書です

事故が起きた原因

事故が起きた原因はいろいろあるとは思いますが、２つ大きくあります。

  • 「キャパシティ」の課金体系を誤解していた
  • 「大は小を兼ねるだろう」という雑な思考

それぞれについて、詳細と対策を考えてみました。
今後 DynamoDB を導入される方の参考になれば幸いです。

「キャパシティ」　の料金体系

まず、DynamoDB の料金体系については　https://aws.amazon.com/jp/dynamodb/pricing/provisioned/　をご覧ください。
主に

  • キャパシティユニット
  • データストレージ

という２つで金額が決まります。

中でも、キャパシティユニット（Capacity Unit）とは DynamoDB に 1s あたりどれくらい書き込めるか。という独自の単位です。このキャパシティの料金体系なのですが、「利用している時だけ課金」ではなく「常時課金」です。

東京リージョンであれば

プロビジョニングするスループットタイプ 時間あたりの料金
書き込みキャパシティーユニット (WCU) 0.000742USD/WCU
読み込みキャパシティーユニット (RCU) 0.0001484USD/RCU

といった具合です。
これで 24h 稼働させると 10 Unit で 10 Units * 0.000742 * 24h ~ 0.18 USD となり、１ヶ月では、5.6$ になります。稼働させているだけで課金されるので、Capacity Units はなるべく小さく定めることがコストカットの観点では重要です。

コストのシミュレーションはこちらにて！
https://dynobase.dev/dynamodb-pricing-calculator/

下から抑える

私の２つ目のミスとして、「とりあえず大きく設定しておこう」という考えがありました。
クラメソさんの https://dev.classmethod.jp/articles/monitoring-dynamodb-capacity-units-tips/ こちらの記事を参考に Read / Write Capacity Units の実際の消費量を計測したところそれぞれ 5 Units あれば十分であることがわかりました。

まとめ

  • Capacity Units は時間あたりの課金。使わない Table は削除、可能な限り小さいキャパシティでコストカット。
  • 閾値は CloudWatch 等で計測し、下から抑えるようにしよう

Discussion