DynamoDBの料金で失敗しないために。~俺みたいになるな~
事件は突然に
私は社内用の、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://dev.classmethod.jp/articles/monitoring-dynamodb-capacity-units-tips/ こちらの記事を参考に Read / Write Capacity Units の実際の消費量を計測したところそれぞれ 5 Units あれば十分であることがわかりました。
まとめ
- Capacity Units は時間あたりの課金。使わない Table は削除、可能な限り小さいキャパシティでコストカット。
- 閾値は CloudWatch 等で計測し、下から抑えるようにしよう
Discussion