対処編
1. リソースの確認
実際に東京リージョンのDynamoDB Tablesを見てみたところ、本番稼働させているTableの他、使っていない8個のテーブルが放置されていた。
それぞれ書き込み/読み込みキャパシティユニットは5CUとなっており、これにより合計30000CU-Hrs程度を無駄に消費していた模様。
(5 * 8)CU * 24時間 * 30日 = 28800CU-Hrs
※AWS CDKでDynamoDB Tableを作成した場合、キャパシティユニットのデフォルトは5CUとなる。
2. リソースの修正/削除
本セクションはDynamoDBに対するコスト削減の詳細なので、趣旨から逸れますが、参考まで。
2-1. 不要なテーブルの削除
放置していた不要テーブルを削除した。
AWS CDKでデプロイされていたため、併せて不要なCloudFormation Stackも削除しておいた。
2-2. 本番稼働テーブルの性能の見直し
DynamoDBのキャパシティ戦略は大きく3つある。
- プロビジョニング:一定のキャパシティユニットを時間あたりで買う
- プロビジョニング + Auto Scaling :キャパシティユニットを幅で指定することで、ワークロードが小さいときは課金料を抑えつつ、スパイク時のスケールも可能にする
- オンデマンド:割高だが、使った分だけの課金となり、スケール可能。ただし、無料枠はない
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html (再掲)
もともと1. の戦略を取っており、キャパシティユニットは3CUとなっていた。
試算の結果、2. が最もコストを抑えられることが分かったため、そちらに修正した。
【修正後の設定値イメージ】
![](https://cdn.apollon.ai/media/notebox/userimages/c6a3b153-b19e-4bf6-bbf7-dbb97e7c0357.png)
上記キャパシティ戦略を取る際の、AWS CDKのサンプルコードも
別記事で公開します。
※ DynamoDB経験者向け:GSIも、テーブルから独立してキャパシティユニット戦略を指定します。今回は、GSIや他テーブルも全てプロビジョニング + Auto Scalingにしました。
3. 事後確認
10日後に、コスト状況を確認した。
※例えばEC2だと、Auto Scaling Groupが効いてたせいで、インスタンスを落とした数分後には新たに立ち上がっていて、コスト削減できていなかった、ということがよく起きる。
AWS Billingで7/10時点での7月請求を確認。
このまま行くと16500W(R)CU-Hrs程度に落ち着きそうな見込みであり、半分以下まで改善されていることが実際に確認できた。
補足:再発防止
AWS Budgetsを利用すると、AWSの費用が想定より上振れているときに通知を知ることができる。
なお、Budgetを作成するだけでは通知が来ないことに注意。BudgetにAlertを紐付ける設定を行う。
今回は予算10USDに対して、予測が200%(20USD)となった際にメールが発火されるように設定した。
追伸
DynamoDBは無料枠もあって安いので、S3のように激安のイメージが先行していましたが、無料枠を超えるとインスタンス系とそんなに変わらない費用になってきますね。
今回の記事で「DynamoDBくらい複雑な料金体系でも、こうやって地道に調査すれば自信を持って対策打てそうだな」というイメージを持っていただければ嬉しいです。
AWS認定ソリューションアーキテクトプロフェッショナル資格を来年更新しないといけないので、各サービス思い出していかないといけないなぁと思いました。