DynamoDBのオートスケール化検討

2018-06-18AWS, DynamoDB

この記事は最終更新日から1年以上が経過しています。

はじめに

DynamoDBのコスト削減について考えてみました。

リザーブドキャパシティ

DynamoDBのコストを考えるときに真っ先に対応したいのはリザーブドキャパシティです。
年単位でキャパシティを前払い購入することで大幅な値引きが実現できます。

オートスケールの検討

オートスケールを導入することで、実際の消費キャパシティに応じてキャパシティ値を動的に変更することが可能です。
ピーク時と平常時でキャパシティの消費量に差がある場合、大きな効果が期待できます。

DynamoDBのオートスケールは2017年6月頃から提供され始め、現在ではデフォルトでオートスケールが有効になっているようです。
今回のテーブルはそれ以前に作成したものなのと、どのようにオートスケールが実行されるのか気になったので、まずは検証用の環境で手順に従ってオートスケールを使ってみました。
※AWSマネージメントコンソールから使用する手順もあります

オートスケールの挙動

オートスケールの設定を行なうと、CloudWatchのアラームが自動的に作成されます。
オートスケール実行のしきい値は、以下のとおりになります。

増加の場合: 5分間設定値を上回る
削減の場合: 15分間設定値を下回る

増加 or 削減後のキャパシティ値は、ターゲット使用率を維持する値になります。
（例）ターゲット使用率: 70%、WCU: 1,000 で設定したテーブルで、消費キャパシティが 800 になった場合：
=> WCUが 1143( 800 / 0.7 ) に変更される

上限値、下限値を設定できるので、それを超えてスケーリングされることはありません。

オートスケールの料金について

1時間ごとのキャパシティ値による課金になります。
1時間以内にキャパシティの変動があった場合、最も高かったキャパシティ値をもとに計算されるようです。

値を設定するうえで、知っておいたほうが良いこと

キャパシティ値の削減は 1 日に最大 4 回までいつでも実行できます。その後は、最後の削減から 1 時間ごとに 1 回のみ実行できます。
オートスケール（スケールダウン）は消費キャパシティが 0 のときには実行されません。（使い方によっては、キャパシティ値が高い状態が維持されてしまう危険性があるので注意しましょう）
キャパシティ値を超える消費が発生した場合、過去最大 5 分間の未使用キャパシティーが使用され、スロットルの発生を抑えることができます。この機能はベストエフォートで提供されているので、頼りすぎは禁物です。
オートスケールのテスト方法として、テーブルに書き込みトラフィックを送る Python プログラムが開発者ガイドに載っているので参考にすると良いです。
上限値について、上げすぎてしまうとパーティションの分割が行われる可能性があります。詳しくは前の記事を確認してください。

導入時に気をつけたいこと

本番環境については、オートスケールの設定値をいきなり攻めすぎた値にするのは怖いので、最初はターゲット使用率を低めに設定してみて徐々に詰めていくと良さそうです。
前の記事で紹介したパーティションの問題もありますので、ピーク時だけでなく、平常時にもスロットルが発生していないか注視する必要がありそうです。

おわりに（感想）

私がいま見ているシステムはピーク時と平常時の差が激しいので、オートスケールによるコストメリットはそこそこあるものの、サービスの安定性を犠牲にしてまでやるべきかというと、なかなか難しいところです。
安全を考慮してキャパシティ値を大きく減らさない程度に実施する、ということになりそうですが、そうなるとあまりやる意味が無いんですよねぇ。
とにかくややこしい仕組みだということが分かったので、慎重に導入を進めたいと思いました。