~~NOCACHE~~
~~DISCUSSION~~
## オンデマンドとプロビジョンド比較
DynamoDBのテーブル設計は複雑ですね、自動で行われる部分と手動でコントロールできる部分を意識した設計が必要そうです。
大体検討できたので、追加で情報があれば追記したいと思います。
異論や間違いあればコメントに・・・ぜひ
## DynamoDBの構造
{{:Aws:DynamoDB:pasted:20210614-164133.png?direct 600x0}}
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html
## 前提
DynamoDBで扱うデータによって設計が変わるので、今回は以下の条件で記載しようと思います。
### 観点
以下3点について、比較したい。
・性能：スロットル(キャパシティ上限による読み/書きエラー)が発生しないこと
・運用負荷：キャパシティのモニタリングおよびモニタリング結果によるキャパシティ上限変更作業の有無
・費用：検討案ごとの月額AWS利用料金を試算する(運用費用は対象外とする)
### データ条件
①DynamoDBで扱うデータは、ユーザIDとトークンを管理し、プライマリーキーはユーザIDとする。
②プライマリーキー(ユーザID)はユニークな値で重複させない。(パーティションキーのみとしソートキーは利用しない、パーティションごとに均等に分散されて格納される)
③ユーザIDとトークンはそれぞれユニークな値の為、セカンダリインデックスを必要としない
④1項目(item)のサイズは1kB以下で、1つの処理では1項目(item)のみ読み書きされる想定
・テーブルイメージ
^ UserID ^ Token ^ Date ^
| user001 | G0dsw5WsQ | 2021-06-13 07:23:00+09:00 |
| user002 | MBiDgD5Ws | 2021-05-13 22:23:00+09:00 |
| user003 | rQKeDrkEU | 2021-05-23 12:23:00+09:00 |
### 容量及び性能条件
利用開始時～5年後の性能条件は以下とする。
^ 項目 ^ データ容量 ^ WCU ^ RCU ^ 備考 ^
| 利用開始 | 10GB | 100 | 300 | |
| 5年後 | 30GB | 300 | 900 | |
## 予備知識
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb
### 基本事項
・データは3つのAZに格納される。
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/25
・テーブルは、計算式に基づきパーティションが分割される。
・テーブルの性能(キャパシティ)はパーティション数で分割された数値がパーティションごとの性能となる。
→性能分割の仕様は変わらないが、アダプティブキャパシティーの「キャパシティの余っているパーティションのユニットを利用できる機能」により意識する必要が無くなった。
・データは3つのAZに格納され、結果的に整合性が保たれる。 (通常は 1 秒以内)
・データの書き込みは 少なくとも２つのAZでの書き込み完了が確認とれた時点で書き込み完了とみなす。
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/9
・読み込みモードは、結果整合性と強い整合性がある。
結果整合性は、書き込みから1秒以内の読み込みでは、更新されていないデータが読み込まれることがある。
強い整合性は、更新が反映された最新データの応答を返す。(2箇所のAZからデータを読み取り、結果が違った場合に残りのAZの値で判断)
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
### キャパシティユニット
テーブルへのデータのWCU(書き込み)/RCU(読み込み)の指標として、キャパシティユニットが定義されている。
それぞれのキャパシティユニット上限値は以下の通り。
^ 項目 ^ 1ユニットの上限値 ^ 備考 ^
| WCU(書き込み) | 最大1KBのデータを1秒に1回書き込み可能\\ ※複数item(項目)を1回書き込みで合計1KBも可能 | 1 秒あたりの書き込み項目数 x 項目のサイズ (1 KB ブロック) |
| RCU(読み込み) | 最大4KBのデータを1秒に1回読み込み可能\\ ※複数item(項目)を1回書き込みで合計4KBも可能 | 強い整合性：1 秒あたりの読み込み項目数 x 項目のサイズ (4 KB ブロック) \\ 結果整合性：1 秒あたりの読み込み項目数 x 項目のサイズ (4 KB ブロック) x ½\\ 1 回の強力な整合性のある読み込みリクエスト、あるいは 2 回の結果整合性のある読み込みを表します。 |
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/32
### パーティション
#### パーティション数の計算
下記の計算結果のうち大きいほうでパーティション数が決まる。
・テーブルサイズを10GBで割った数値
・WCUを1000で割った数＋RCUを3000で割った数
例：
・テーブルサイズが25GB＝25/10＝2.5 → 繰り上げて3パーティション
・WCUを1500、RCUを3000＝(1500/1000)+(3000/3000)＝1.5+1=2.5 → 繰り上げて3パーティション
今回の条件を当てはめると以下のようになる。
^ 項目 ^ データ容量 ^ WCU ^ RCU ^ パーティション数 ^ 備考 ^
| 利用開始 | 10GB | 100 | 300 | 2 (キャパシティ＞データ容量) | |
| 5年後 | 30GB | 300 | 900 | 3 (データ容量＞キャパシティ) | |
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/38
#### パーティション数の特性
・パーティション数は上記計算式に基づいて、自動で拡張されるが縮小は自動で行われない。(性能試験をしたらパーティション数は増える。)
・プロビジョンドでキャパシティを縮小する場合は、拡張されたパーティション数で割った数が上限値となるため、パーティション単位の性能が落る場合がある。
→アダプティブキャパシティーの「キャパシティの余っているパーティションのユニットを利用できる機能」により意識する必要が無くなった。
※アダプティブキャパシティが有効の場合は、パーティション間でキャパシティを分け合えるため性能は落ちない。らしい
※格納するデータにもよるが、メンテナンスが可能であればキャパシティを縮小する場合はテーブルの作り直しを検討すること。
### パーティションへ書き込まれるデータ
パーティションへ書き込まれるデータは、パーティションキーによって分散される
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/HowItWorks.Partitions.html
### スロットル
スロットル(読み書きエラー)は、以下の条件で発生する。
■オンデマンド
・30 分以内に前回のトラフィックピークの 2 倍を超えると、スロットルが発生する可能性があります。
・テーブルの各パーティションで、最大 3,000 の読み取りリクエスト単位または 1,000 の書き込みリクエスト単位を超えた場合。
■プロビジョンド
・テーブルの各パーティションで、設定したキャパシティを超えた場合。
・テーブルの各パーティションで、最大 3,000 の読み取りリクエスト単位または 1,000 の書き込みリクエスト単位を超えた場合。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/on-demand-table-throttling-dynamodb/
### アダプティブキャパシティー
・キャパシティの余っているパーティションのユニットを利用できる機能
・アクセス頻度の高いデータを分離する機能 ※別途新規のパーティションを追加して分離する。
・アダプティブキャパシティーはすべての DynamoDB テーブルで自動的に有効化されます。追加料金はありません。
・アダプティブキャパシティーを明示的に有効化あるいは無効化する必要はない。
※「アクセス頻度の高いデータを分離する機能」は、ローカルセカンダリインデックス、プロビジョンドでDynamoDB Streamsが有効となっている場合は適用されない。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-partitions-adaptive
### バーストキャパシティー
下記の特徴があるが、利用者の利用頻度に左右されるので期待しない保険程度と思ったほうが良い。
・読み取りまたは書き込みアクティビティが時折バーストする間、余分なキャパシティーユニットが利用できる機能
・未使用の読み取りおよび書き込みキャパシティーは、最大 5 分 (300 秒) 保持される。
・テーブルに対して定義したスループットキャパシティーよりも高速らしい。高速？？先に使われるという意味かな・・？
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/bp-partition-key-design.html#bp-partition-key-throughput-bursting
### Auto Scaling
・上限と下限値と使用率を設定して、その範囲内で設定した使用率を維持するようキャパシティユニットを変動させる機能
・Amazon CloudWatch アラームによってトリガーされるため、急なバーストには対応できない
https://aws.amazon.com/jp/premiumsupport/knowledge-center/dynamodb-auto-scaling/
https://www.slideshare.net/AmazonWebServicesJapan/20170809-black-belt-dynamodb/78
### DynamoDB でのエラー処理
結果整合性でも強い整合性でも、DynamoDBからエラーレスポンスがあることを考慮して適切なアクションを組み込んでおく。
https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/Programming.Errors.html
## 比較案
### サマリ
・性能が高くなるにつれて、プロビジョンドの方が遥かにオンデマンドより費用が抑えられる。
・プロビジョンドのキャパシティは余裕を持たせた設計が望ましいため、費用は下記表よりも多くなります。※オンデマンドより遥かに安いのは変わらない。
・高い性能を求められるシステムに関しては、プロビジョンドで適切な運用を行いながらのチューニングが良いと思う。
・DynamoDB Streamsを有効にする場合は、オンデマンドでないとアダプティブキャパシティの恩恵が受けられない。(Kinesis Data Streams for DynamoDBであればたぶん大丈夫)
・性能が高くないシステムに関しては、運用負荷や運用対処が不要なことからオンデマンドとした方が良いと思う。
※何れの案でも、スロットルが発生してしまった場合は何かしらの対策が必要なため、ConsumedReadCapacityUnits/ConsumedWriteCapacityUnitsのモニタリングは必要
^ 比較案 ^ 特記事項 ^ 備考 ^
| ①オンデマンド | | |
| ②プロビジョンド(スモールスタート) | 利用開始時のキャパシティで開始、上限値を5年後キャパシティで想定する。 | |
| ③プロビジョンド(スモールスタート＋Auto Scaling) | 利用開始時のキャパシティで開始、上限値を5年後キャパシティで想定する。 | |
| ④プロビジョンド(5年後キャパシティ想定) | 利用開始時から、上限値を5年後キャパシティで想定する。 | |
^ 比較案 ^ 性能 ^ 運用負荷 ^ 費用 ^ 備考 ^
| ①オンデマンド | ◎：スロットルが発生した際の性能影響\\ 運用対処が間に合わない場合でも、一時的に性能に影響がでるが時間経過で解消される | 低：キャパシティは自動調整 | △：高スループットになるにつれ、プロビジョンドと費用の乖離が激しくなる。\\ ・利用開始時：約600 USD/月\\ ・5年後：約1,800 USD/月 | |
| ②プロビジョンド\\ (スモールスタート) | △：スロットルが発生した際の性能影響\\ 運用対処が間に合わない場合は、対応完了まで性能に影響が出る可能性あり | 高：キャパシティが不足した場合は手動調整が必要 | 〇：オンデマンドと比べ費用が抑えられる。\\ ・利用開始時：約90 USD/月\\ ・5年後：約270 USD/月 | |
| ③プロビジョンド\\ (スモールスタート＋Auto Scaling) | 〇：スロットルが発生した際の性能影響\\ AutoScalingの範囲内であれば、一時的に性能に影響がでる可能性があるが時間経過で解消される。\\ AutoScalingの範囲外で運用対処が間に合わない場合は、対応完了まで性能に影響が出る可能性あり | 高：AutoScalingの頻度が高くなった場合は、下限値の手動調整が必要\\ 上限値が想定を超えた場合は手動調整が必要 | 〇：オンデマンドと比べ費用が抑えられる。\\ ・利用開始時：約90 USD/月\\ ・5年後：約270 USD/月 | 費用はAuto Scalingの発生によって変動する。 |
| ④プロビジョンド\\ (5年後キャパシティ想定) | △：スロットルが発生した際の性能影響\\ 運用対処が間に合わない場合は、対応完了まで性能に影響が出る可能性あり | 中：上限値が想定を超えた場合は手動調整が必要 | 〇：オンデマンドと比べ費用が抑えられる。\\ ・利用開始～5年後まで一定\\ 約270 USD/月 | |
## 料金(参考)
### 料金表
■オンデマンド
^ 料金タイプ ^ 月あたりの料金 |||
| 書き込み要求単位 | 書き込み要求ユニット 100 万あたり | 1.4269 | USD |
| 読み出し要求単位 | 読み出し要求ユニット 100 万あたり | 0.285 | USD |
https://aws.amazon.com/jp/dynamodb/pricing/on-demand/
■プロビジョンド
^ プロビジョニングするスループットタイプ ^ 時間あたりの料金 |^ 月あたりの料金 ||
| 書き込みキャパシティーユニット (WCU) | 0.000742 | USD | 0.53424 | USD |
| 読み込みキャパシティーユニット (RCU) | 0.0001484 | USD | 0.106848 | USD |
https://aws.amazon.com/jp/dynamodb/pricing/provisioned/
### 料金比較グラフ
以下の条件で費用算出した結果、リクエスト数に応じてオンデマンドの料金が爆上がりなのがわかります。
・ストレージの料金はオンデマンド、プロビジョンドとも同額のため含めていません。
・オンデマンドの1*100万単位リクエストに合わせて、プロビジョンドのキャパシティユニットを計算しています。
・書き込み数＝読み込み数として算出しています。
{{:Aws:DynamoDB:pasted:20210615-103039.png?direct 800x0}}
{{tag>AWS DynamoDB}}