血と汗となみだを流す

個人の思ったこと、やったことの吐き出し口です。

多分日刊IT問題(DynamoDBの制限)

問題

  • 皆大好きDynamoDBの説明で、誤っているものはどれか？！

選択肢

  1. 読込/書込キャパシティの変更は無制限にできる
  2. AutoScaleを使ってScaleUpした後、リクエストがないとScaleDownしないまま同じキャパシティを保った状態になる
  3. 読込/書込キャパシティ/ストレージ容量/データ転送量で課金される
  4. 開発用のローカルバージョンがある

解答

  • 誤っているものは「1.読込/書込キャパシティの変更は無制限にできる」でした！

解説

1. 読込/書込キャパシティの「減少」には制限があります

  • なんと、増加は無制限なのですが、減少は1日に実行できる回数が決まっているんですよね・・・
  • 参考
  • AutoScalingを設定しているときも同じ制限が適用されるようです。
  • AutoScaleするから安心！とか思っていると、減少の制限に引っかかってキャパシティが下がらないまま！というのがあり得るよ！
  • キャパシティ管理は別途CloudWatch Alertを設定しておいたほうが良いかと思います。

2. AutoScaleを使ってScaleUpした後、リクエストがないとScaleDownしないまま同じキャパシティを保った状態になる

  • これも注意ポイントなのですが、ScaleInは、リクエストがトリガーとなって行われます。
  • つまり、ScaleUpしたあと、全然アクセスがないとUpしたキャパシティを維持し続けるので料金やべぇ！ってなるわけです。
  • Lambdaなどを使って定期的にping/pongさせてキャパシティをDownさせる仕組みが必要かも・・・

3. 読込/書込キャパシティ/ストレージ容量/データ転送量で課金される

  • 「キャパシティだけに料金がかかる」とずっと思っていましたが、テーブルが使用するディスク容量でも課金されるようです。(知らなかった)
  • 東京リージョンだと月額「1 GB あたり最低 0.25 USD」のため、そこまで気にしなくてもよいかもしれません。

4. 開発用のローカルバージョンがある

  • ローカル開発用のものがあります！
  • これを使えば、開発時の課金を気にしなくて済みますね！
  • ちなみに俺はローカル環境は常に読込/書込キャパシティを10000(MAX)にしていましたが、ローカルのキャパシティは設定しても無意味っぽいです。(速度は変わらず)

まとめ

  • 今回はDynamoDBでハマったポイントについて出題してみました！
  • マネージドサービスで便利は便利なのですが、いろいろと制限があるので、利用用途によっては使えなくなる可能性があります。
  • 用法・容量を守って使いましょう。
プライバシーポリシー