翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
DynamoDB テーブルのコストをオンデマンドで見積る
作成者: Moinul Al-Mamun (AWS)
環境:本稼働 | テクノロジー: データベース CloudNative、サーバーレス、コスト管理 | AWS サービス: Amazon DynamoDB |
[概要]
Amazon DynamoDB
オンデマンドキャパシティモードでは、アプリケーションがテーブルに対して実行するデータの読み取りと書き込みに対して、リクエストごとに料金を支払います。AWS の料金は、1 か月あたりの累積読み取りリクエスト単位 (RRU) と書き込みリクエスト単位 (WRU) に基づいています。DynamoDB では、1 か月にわたるテーブルサイズの継続的なモニタリングに基づいてストレージ料金が決定されます。 point-in-time-recovery (PITR) による継続的バックアップをサポートしています。DynamoDB では、1 か月にわたる PITR 対応テーブルサイズの継続的なモニタリングに基づいてバックアップ料金が決定されます。
プロジェクトの DynamoDB コストの見積もりでは、製品ライフサイクルのさまざまな段階で消費される RRU、WRU、およびストレージの値を計算することが重要です。大まかなコスト見積もりには AWS 料金見積りツール
このパターンは、DynamoDB の基本的なコスト要因（書き込み、読み取り、ストレージ、バックアップ、リカバリの費用など）を見積もるメカニズムと再利用可能な Microsoft Excel テンプレートが提供されます。AWS 料金見積りツールよりも詳細で、ベーステーブルと GSI の要件を個別に検討します。また、項目データの月次増加率を考慮して、3 年間の費用を予測します。
前提条件と制限
前提条件
DynamoDB と DynamoDB データモデル設計に関する基本的な知識
DynamoDB の料金、WRU、RRU、ストレージ、バックアップとリカバリに関する基本的な知識 (詳細については、「オンデマンドキャパシティの料金
」を参照してください) DynamoDB のデータ、データモデル、項目サイズに関する知識
DynamoDB GSI に関する知識
機能制限
テンプレートではおおよその計算のみで、すべての構成に適応はしていません。より正確な見積もりを得るには、ベーステーブルと GSI の各項目のサイズを個別に試算する必要があります。
より正確な見積もりでは、各項目の書き込み (挿入、更新、削除) 回数と読み取り回数の平均を考慮する必要があります。
このパターンでは、固定データ増加の仮定に基づいて、今後数年間の書き込み、読み取り、ストレージ、バックアップ、リカバリ費用のみの見積もりが可能です。
ツール
AWS サービス
Amazon DynamoDB は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを発揮します。
その他のツール
AWS 料金見積りツール
は、ユースケースの見積りを作成するために使用できるウェブベースの計画ツールです。
ベストプラクティス
コストを低く抑えるには、次の DynamoDB 設計のベストプラクティスを考慮してください。
パーティションキーの設計 — カーディナリティの高いパーティションキーを使用して負荷を均等に分散します。
隣接関係リストの設計パターン – この設計パターンは、 one-to-many と の many-to-many 関係の管理に使用します。
スパースインデックス — GSI にはスパースインデックスを利用します。GSI を作成する際、パーティションキーおよびソートキー (オプション) を指定します。対応する GSI パーティションキーを含むベーステーブルの項目だけが、スパースインデックスに表示されます。これにより GSI を小さく抑えることができます。
インデックスの多重定義 — さまざまなタイプの項目のインデックス作成に、同じ GSI を使用します。
GSI 書き込みシャーディング — うまくシャーディングしてパーティション全体にデータを分散することで、クエリを効率的かつ高速に行うことができます。
大きなアイテム — テーブル内にメタデータのみを保存し、blob を Amazon S3 に保存し、リファレンスを DynamoDB に保持します。大きな項目を複数の項目に分割し、ソートキーを使用して効率的にインデックスを作成します。
設計のベストプラクティスについての詳細は、Amazon DynamoDB の「デベロッパーガイド」を参照してください。
エピック
| タスク | 説明 | 必要なスキル |
|---|---|---|
項目サイズを取得します。 |
| データエンジニア |
書き込み費用を見積もります。 | オンデマンドキャパシティモードでの書き込み費用を見積もるには、1 か月に消費される WRU の値を測定する必要があります。そのため、以下の要素を考慮する必要があります。
詳細については、「追加情報」セクションをご覧ください。 | データエンジニア |
読み取り費用を見積もります。 | オンデマンドモードでの読み取り費用を見積もるには、まず 1 か月に消費される RRU の値を測定する必要があります。そのため、以下の要素を考慮する必要があります。
| データエンジニア、アプリ開発者 |
ストレージのサイズと費用を見積もります。 | 最初に、テーブルの項目サイズに基づいて、月間平均ストレージ要件を見積もります。次に、ストレージサイズに AWS リージョンの GB あたりのストレージ料金を掛けてストレージ費用を計算します。 書き込み費用を見積もるためのデータを既に入力している場合は、ストレージサイズの計算のためにデータを再度入力する必要はありません。それ以外の場合、ストレージサイズの見積りでは、以下の要素を考慮する必要があります。
| データエンジニア |
| タスク | 説明 | 必要なスキル |
|---|---|---|
添付ファイルセクションから Excel テンプレートをダウンロードし、ユースケーステーブルに合わせて調整します。 |
| データエンジニア |
Excel テンプレートに情報を入力します。 |
テンプレートには、情報、メタデータ、リレーションシップの 3 つの項目またはエンティティが含まれます。2 つの GSI があります。ユースケースに合わせて、さらに項目が必要な場合は、新しい行を作成してください。さらに GSI が必要な場合は、既存の GSI ブロックをコピーして貼り付け、必要な数の GSI ブロックを作成します。次に、「合計」列と「合計」列の計算を調整します。 | データエンジニア |
関連リソース
リファレンス
ガイドとパターン
追加情報
費用計算の例
DynamoDB データモデルの設計では、1 つの製品について 3 つの項目が表示され、平均項目サイズは 4 KB です。DynamoDB ベーステーブルに新しい製品を追加すると、項目数 x (項目サイズ/1 KB 書き込み単位) = 3 x (4/1) = 12 WRU が消費されます。この例では、1 KB を書き込むと、製品は 1 WRU を消費します。
費用計算の例
RRU の見積もりを求めるには、各項目の 1 か月にわたる読み取り回数の平均を考慮してください。たとえば、情報項目は 1 か月に平均で 10 回読み取られ、メタデータ項目は 2 回、リレーションシップアイテムは 5 回読み取られます。このテンプレート例では、すべてのコンポーネントの合計 RRU = 毎月作成される新しいコンポーネントの数 x コンポーネントあたりの RRU = 1,000 万 x 17 RRU = 1 か月あたり 1 億 7,000 万 RRU です。
毎月、新しいもの (コンポーネントまたは製品) が追加され、製品の総数は時間の経過に伴い増えていきます。そのため、RRU の要件も時間に伴い増加していきます。
最初の 1 か月の RRU の消費量は 1 億 7,000 万になります。
2 か月目の RRU の消費量は 2 x 1 億 7,000 万 = 3 億 4,000 万になります。
3 か月目の RRU の消費量は 3 x 1 億 7,000 万 = 5 億 1,000 万になります。
次のグラフは、毎月の RRU 消費量と費用予測を示しています。
注意：グラフ内の料金は説明の目的でのみ使用されています。ユースケースに適応した正確な予測を作成するには、AWS 料金ページを確認し、その料金を Excel シートに入力してください。
ストレージ、バックアップ、リカバリ費用の計算例
DynamoDB ストレージ、バックアップ、リカバリはすべて相互に接続されています。バックアップはストレージに関係し、リカバリはバックアップサイズに関係します。テーブルのサイズが大きくなると、それに対応するストレージ、バックアップ、およびリカバリの費用も比例して増加します。
ストレージのサイズと費用
ストレージ費用は、データの増加率に応じて時間の経過に伴い増加していきます。例えば、ベーステーブルと GSI にあるコンポーネントまたは製品の平均サイズが 11 KB で、データベーステーブルに毎月 1,000 万個の新しい製品が追加されると仮定します。その場合、DynamoDB テーブルのサイズは (11 KB x 1000 万) /1024/1024 = 1 か月あたり 105 GB 増加します。最初の月のテーブルストレージのサイズは 105 GB になり、2 か月目には 105 + 105 = 210 GB というようになります。
最初の月には、AWS リージョンのストレージ費用は 105 GB x 1 GB あたりのストレージ料金になります。
2 か月目には、お住まいのリージョンのストレージ費用は 210 GB x 1 GB あたりのストレージ料金になります。
3 か月目には、そのリージョンのストレージ費用は 315 GB x 1 GB あたりのストレージ料金になります。
今後 3 年間のストレージサイズと費用については、「ストレージサイズと予測」セクションを参照してください。
バックアップの費用
バックアップの費用は、データの増加率に応じて時間の経過に伴い増加していきます。 point-in-time-recovery (PITR) で継続的バックアップを有効にすると、継続的バックアップ料金は平均ストレージ GB/月に基づきます。1 か月あたりの平均バックアップサイズは、テーブルのストレージサイズと同じですが、実際のサイズは若干異なる場合があります。新しい製品が毎月追加されるため、ストレージの合計サイズとバックアップサイズは時間の経過の伴い増加していきます。例えば、最初の月の平均バックアップサイズは 105 GB でしたが、2 か月目には 210 GB に増える可能性があります。
最初の月のバックアップ費用は、お使いの AWS リージョンの連続バックアップ料金 (GB あたり 105 GB x) になります。
2 か月目のバックアップ費用は、お住まいのリージョンの 1 GB あたり 210 GB/月 x 継続バックアップ料金になります。
3 か月目のバックアップ費用は、お住まいのリージョンの 1 GB あたりの継続バックアップ料金が 315 GB/月 * になります。
以降も同様になります
バックアップ費用は、「ストレージサイズとコストの予測」セクションのグラフに含まれています。
リカバリ費用
PITR を有効にした状態で継続的なバックアップを行う場合、リカバリ操作料金はそのサイズに基づいて計算されます。リカバリするたびに、リカバリデータのギガバイト数に基づいて支払いが発生します。テーブルのサイズが大きく、1 か月に複数回リカバリを実行すると、コストが高くなります。
リストア費用を見積もるために、この例では毎月月末に PITR 復元を実行することを想定しています。この例では、月間平均バックアップサイズをその月のリカバリデータサイズとして使用しています。最初の月の平均バックアップサイズは 105 GB で、月末の復元データサイズは 105 GB です。2 か月目は 210 GB になり、以降も同様になります。
リカバリ費用は、データの増加率に応じて時間の経過に伴い増加していきます。
最初の月には、105 GB x AWS リージョンの GB あたりの復元料金になります。
2 か月目のリカバリ費用は、210 GB * お住まいのリージョンの GB あたりの復元料金になります。
3 か月目のリカバリ費用は、315 GB * お住まいのリージョンの GB あたりの復元料金になります。
詳細については、Excel テンプレートの [ストレージ、バックアップ、リカバリ] タブと次のセクションのグラフを参照してください。
ストレージのサイズとコストの予測
テンプレートでは、実際の課金ストレージサイズは、標準テーブルクラスの毎月 25 GB の無料利用枠を差し引いて計算されます。シートには、月次値ごとに分割された予測グラフが表示されます。
次のグラフの例では、今後 36 か月間の月間ストレージサイズ (GB)、請求可能なストレージ費用、オンデマンドバックアップ費用、およびリカバリ費用を予測しています。コストの見積り グラフから、ストレージ、バックアップ、リカバリの費用は、ストレージサイズの増加に比例して増加することが分かります。
注意：グラフ内の料金は説明の目的でのみ使用されています。ユースケースに適応した正確な料金を作成するには、AWS 料金ページを確認し、その料金を Excel シートに入力してください。
添付ファイル
このドキュメントに関連する追加コンテンツにアクセスするには、次のファイルを解凍してください。「attachment.zip」
