Amazon DynamoDB On-Demandをためしてみた！ #reinvent

AWS re:Invent 2018のKeynoteでAmazon DynamoDB On-Demandが発表されました！

https://aws.amazon.com/jp/blogs/aws/amazon-dynamodb-on-demand-no-capacity-planning-and-pay-per-request-pricing/

リクエストに応じてキャパシティユニットが自動調整されるため、今まで行っていたキャパシティユニットのプロビジョニング、スケジューリングなどが必要なくなります！

完全マネージドにキャパシティユニットを管理してくれるため、面倒なキャパシティプランニングから開放されそうです。

早速試してみたので様子をレポートします。

検証

こんな設定項目がふえました。

課金についての注意が表示されます。

リクエスト毎の支払いを選択すると、プロビジョニングとオートスケーリングが有効化できなくなりました。(※ちなみに AWS CLI、AWS SDK、およびAWS CloudFormationからの設定も可能だそうです）

また、自動スケーリング以外のすべてのDynamoDB機能（暗号化、ポイントインタイムリカバリ、グローバルテーブルなど）は通常どおり使えるそうです。

では、簡単に負荷かけていきます。

スキャンを実行してRead Capacity Unitがどう変化するのか？スロットリング発生するのか？などを試してみました。

for i in `seq 100`
do
aws dynamodb scan --table-name <table-name> &
done

CloudWatch Metricsの挙動

有効化時点で、プロビジョニングキャパシティが0になってますね。

会場ネットワークの関係で大した負荷はかけれませんでしたが、メトリクスの挙動を見る限りスロットルやエラーは発生してなさそうです。

まとめ

RCUに関してはDAXという選択肢があったため、個人的にはWCUの管理にとても悩まされていました。

また、オートスケーリングやスケジューリング機能は提供されていましたが、結局のところスケールアップに時間がかかるためスパイクなどの突発的なアクセス増加には耐えられない状態でした。

今回の発表で、RCU/WCUの管理から開放されるのではないかと思います。

一点、本番環境での運用の際は、スケーリングが請求額に直接反映されるため、CloudWatch Alarmsなどで適切に管理する必要が出てきそうです。

利用する際は、用法用量をまもって適切に行う必要がありそうです。

以上、現地からの検証記事でした。