無料枠で頑張るためにDynamoDBのキャパシティを理解する
Amazon DynamoDBはフルマネージドなNo SQLデータベースで、LambdaやAppSyncのデータソースとしてよく使用されています。
私も要件によってはDynamoDBを選択するケースがあるのですが、無料枠の詳細を確認せずテーブルを量産した結果、なんと$30を超える請求が来てしまいました・・
そこで、今回は同じような失態を防いでもらうために注意すべきことについて説明します。
DynamoDBの無料枠の詳細
公式サイトに記載があります。
DynamoDBの無料枠はというと、、
「ほぉほぉ。25GBのストレージか。まぁ超えることはないな。」
ここで完全に安心しきっていました。
ただ、この詳細を見てみると次のように書かれています。
- 25ユニットの書き込みキャパシティ
- 25ユニットの読み込みキャパシティ
「んー。よくわからん。」
そこで、一体DynamoDBのどこで無料枠を超過したのか見てみます。
なにやら、ReadCapacityUnit-HrsとWriteCapacityUnit-Hrsで超過しているのがわかりました。
ではこいつらは一体何者か見ていきましょう。
書き込みキャパシティ、読み込みキャパシティとは
DynamoDBにおけるスループットキャパシティの単位として、書き込みキャパシティユニットと読み込みキャパシティユニットを指定します。
キャパシティユニットとは1秒あたりにN回の読み書きできる容量のことです。
1キャパシティユニットでできることは以下のようになっています。（一部簡略化しています）
| 読み書き | 内容 |
|---|---|
| 読み込み (強力な整合性) | 1秒に1回 (4KBまでは) |
| 読み込み (結果整合性) | 1秒に2回 (4KBまでは) |
| 書き込み | 1秒に1回 (1KBまでは) |
※サイズの上限を超えると、より多くのキャパシティユニットが必要になります。
キャパシティユニットは1テーブルごとに設定するため、
例えば、5ユニットの書き込みキャパシティ/読み込みキャパシティをテーブルに設定すると、
- 1秒に5KBまでの書き込み (1KB × 5回)
- 1秒に20KBまでの強力な整合性読み込み (4KB × 5回)
- 1秒に40KBまでの結果整合性読み込み (4KB × 10回)
というスループットを実現できることになります。
ですので、無料枠の詳細に記載されている
- 25ユニットの書き込みキャパシティ
- 25ユニットの読み込みキャパシティ
というのは、
各テーブルに設定した書き込みキャパシティ、読み込みキャパシティの合計がそれぞれ25を超えていないか
ということになります。
キャパシティユニットによる課金の詳細
課金の基準としては、 実際にどれだけのI/Oが発生したかではなく、どれだけのキャパシティを消費したかとなっています。
25ユニットの〜〜とは謳われていますが、25ユニット以上テーブルに設定したら即課金ではなく、
ユニット数 × 24時間 × 31日 (月日数) の値がいくらか
によって決まります。
これが先述したReadCapacityUnit-Hrs、WriteCapacityUnit-Hrsにあたります。
例えば2018年12月の場合、31日まであるので、課金の基準としては
- 5(ユニット) × 24(時間) × 31(日) → 18,600 CapacityUnit-Hrs
となり、これを超過した分が課金の対象となります。
ちなみに、読み込みと書き込みキャパシティが異なり、
| 読み書き | 課金 (1時間あたり) |
|---|---|
| 読み込み | $0.0001484 |
| 書き込み | $0.000742 |
と書き込みキャパシティの方が5倍以上高くなっています。
ちなみに私の場合は、
37,735 CapacityUnit-Hrs超過したので、
- 読み込み：0.0001484 × 37,735 ≒ $5.6
- 書き込み：0.000742 × 37,735 ≒ $28.0
の課金となりました。
課金されないために考慮すべきこと
DynamoDBの課金としては、キャパシティによる課金の他にストレージ容量やデータ転送量などありますが、やはりキャパシティが一番ハマることが多いと思います。
キャパシティによる課金を抑えるポイントとしては
- 使っていないテーブルは削除する
- テーブルのアクセス頻度を考慮したキャパシティユニットの設定をする（デフォルトだと5で作成されている）
ということが言えます。
幸いにも、テーブルのキャパシティユニットの設定は稼働中でも変更可能ですので定期的に見直した方が良いと思います。
仮に今の時点で25ユニットを超えてしまっていても、何時間稼働したかで変わってくるので早めに対処すればするほど課金のリスクは減ります。
最適な設定で高いコストパフォーマンスを
今回の記事では無料枠で収めることを目的に記載しましたが、キャパシティユニットを下げればスループットが落ちるのでパフォーマンスは下がります。
なので最適なキャパシティユニットの設定を行うことが大前提であり、その上で無駄にキャパシティユニットを多く消費することを防ぐことが、高いコストパフォーマンスに繋がると思います。
最適な設定をした上で課金になるのは仕方ありませんし、正しい姿です。
【補足】
DynamoDBの料金体系は
- プロビジョニング済みキャパシティモード
- オンデマンドキャパシティモード (2018年12月頃より開始)
の2つがあり、今回の記事ではプロビジョニング済みキャパシティモードについてのお話でした。
（オンデマンドキャパシティモードは無料枠対象外のようなので）
プロビジョニングの方はあらかじめ決まったキャパシティユニットのリソースを確保しますが、オンデマンドの方はキャパシティユニットの設定は必要なく、読み書きのリクエストの応じた従量課金となります。
ケースバイケースでどちらを適用するのかという点も料金・パフォーマンスの最適化を行う上で重要な内容ですので、是非ご検討いただければと思います。
その他
AWSの請求をいち早くキャッチするための設定はこちらの記事をご確認ください↓↓
AWS管理者が最初にやるべき請求アラームの設定 - Tatsuyashi's Blog
