Amazon DynamoDBのスループットを減らす時は、以下の画面キャプチャように1日1回しかできないようになっている。 その理由を考えてみた。ほとんど推測なので、間違っているかもしれない。目くじら立てないで欲しい。 これはもしかして、これはアザトい仕様なのかもしれない… とか少し思った。

理由１ 技術的(理論的？)制約があるため

* スループットを増やす時

DyanmoDBは基本的にDHT(Distributed Hash Table)なのでconsistent hashingアルゴリズムを使っている。 スループットを上げる時は、内部でマシンの数を増やして、スケールアウトしているはず。 例えば、スループットを倍に上げるためには、単純にマシンの数を倍にすれば良い。単純複製をすると、半分のデータはアクセスされずゴミになるが… マシンの数を増やすためには、ストレージの内容を複製する必要がある。 実際にDynamoDBを使ってみるとわかるが、Webコンソールからスループットを倍に上げる指示を出してから約1分程度で反映される。 また、ガーベッジコレクションとして、アクセスされる可能性の無くなったゴミデータは少しずつ消しているはず。これは後でゆっくりやっているはずだ。

* スループットを減らす時

次にスループットを下げる時は、内部でマシンの数を減らす必要がある。 そうしないと、遊んでいるマシン分をAWS側が負担しなければならず、原価割れするだろう。 問題はスループットを下げる時は、複数のマシンとストレージに入っているデータをマージする必要があることだ。 そのとき、primaryキーのインデックスを再構築する必要がある。 DynamoDBの仕様として、primaryキーはレンジサーチができる必要があるので、おそらくB+ツリーなどのインデクスを利用していくだろう。 いづれにしても再構築には時間がかかる。 なので、スループットを下げる時は、どうしてもなんらかの時間的制約を入れる必要がある。

理由２ スループット設定を下げ忘れさせるため

ちょっといじわるな見方をしてみよう。 もしかして、ユーザーにスループットを下げることを忘れさせて、課金を最大化するためにやっているのではないか？

まとめ

良心的な目でみるなら、理由１だろう。 私が初めてこの制限を知った時には、結構失望したが、技術的・理論的な理由が考えられなくも無いということで、一応メモ。

もしあなたが、急激なアクセスピークをDynamoDBで乗りきった後、上司やクライアントにすぐ設定を減らすように言われたが、すぐにはできないというこの制限に気がついた時は一つの釈明として使ってもらえればと思う。