AWS DynamoDBのオンデマンド/プロビジョニングモードまとめ

DynamoDBを利用する際、テーブルごとに読み書きのキャパシティモードを設定します。その際にオンデマンドとプロビジョニングのどちらかを選択する必要があり、それぞれワークロードによって選択が変わってくると思います。
本記事ではキャパシティモードについて公式のデベロッパーガイドを元に概要をまとめました。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html

オンデマンドモード

EC2と同様に使用した分だけ課金がされる仕組みです。ここでいう使用した分とは、リクエストあたりの読み書き操作の種別とその容量(キャパシティユニット)となります。(整合性、トランザクション、キャパシティユニットについては割愛)
したがって事前に性能などを計画して設定しておく必要がありません。

メリット

• 管理が容易

  • スループット設定に関する手動の管理が不要。DynamoDBが必要なスループットを自動的に調整する。

• 費用の最適化

  • 利用したリクエストに対して支払いが発生し、無駄なキャパシティを割り当てなくて済むことで費用の最適化が可能である。

• 急な負荷増加への適応

  • アプリケーションの負荷が急増した場合でも、自動的に対応するため、スケーラビリティが高い。

デメリット

• コストの予測の難しさ

  • 使用したリクエストに対して支払いが発生するため、コストの予測が難しく、計画立てた予算管理ができない。

• 予測不能な遅延

  • スループットが自動的に調整されるため、リクエストの処理に遅延が発生する可能性がある。

  • 場合によってはピークタイムに備える事前ウォームアップが必要。

プロビジョニングモード

事前計画が必要な課金体系となります。1秒当たりの読み書き性能(スループットキャパシティ)を設定する必要があり、実際に使った使わない関わらずその料金がかかります。またAutoScaling設定が可能で、プロビジョニングする最大と最小を定義することで、トラフィックの変更に応じて設定した最大最小内でキャパシティが調整されます。

メリット

• コントロール

  • 事前にスループットを手動設定することで予測可能なパフォーマンスを確保可能。

• コスト予測

  • スループットの事前設定により、コスト予測が可能で、予算管理しやすい。

• 安定的な性能

  • 設定されたスループットに基づいて、低遅延でリクエストを処理可能。

デメリット

• 手動管理

  • ワークロードに応じたスループットの管理が必要。特に負荷が変動する場合などは高負荷時に合わせた設定を行う必要がある。

• 予測誤差

  • 負荷を正確に予測しなければ、スループットの設定が不十分または過剰になる可能性がある。

  • スループットが不十分の場合にはスロットリングが発生

どちらを選ぶか

結局のところどちらが良いと言うわけではなく、ワークロードに沿った選択をする必要があります。負荷の変動が大きい、予測が難しいワークロードなどではオンデマンドが適していますが、一方でトラフィックの予測が可能で、キャパシティ、料金のコントロールが可能な場合はプロビジョニングが適しているでしょう。テーブル作成後もオンデマンド/プロビジョニングの切り替えが可能ですので、ワークロードに変化があった場合でも対応できます。（ただし切り替え時のスループットに制約があるため注意）