DynamoDB テーブルのキャパシティモードの評価

このセクションでは、DynamoDB テーブルで、適切なキャパシティモードを選択する方法の概要を説明します。各モードは、スループットの変化に対する応答性や使用に対する請求方法という点で、さまざまなワークロードのニーズを満たすように調整されています。決定を下す際には、これらの要素のバランスを取る必要があります。

利用可能なテーブルキャパシティモード

DynamoDB テーブルを作成する場合、オンデマンドまたはプロビジョンドキャパシティモードのいずれかを選択する必要があります。24 時間ごとに 1 回、キャパシティモードを切り替えることができます。唯一の例外は、プロビジョニングモードテーブルをオンデマンドモードに切り替えた場合、同じ 24 時間以内にプロビジョニングモードに戻ることができることです。

オンデマンドキャパシティモード

オンデマンドキャパシティモードは、DynamoDB テーブルのキャパシティをプランニングまたはプロビジョニングする必要がないように設計されています。このモードでは、テーブルへのリクエストにテーブルが即座に対応します。リソースをスケールアップまたはスケールダウンする必要はありません (テーブルの以前のピークスループットの最大 2 倍まで)。

DynamoDB オンデマンドは、読み込みおよび書き込みリクエストの料金が従量制であるため、使用した分だけを支払います。

プロビジョンドキャパシティモード

プロビジョンドキャパシティモードは従来型のモデルで、リクエストに対して利用できるテーブルのキャパシティを直接、または自動スケーリングを使って定義する必要があります。特定のキャパシティが指定された時間にテーブルにプロビジョニングされるため、請求は消費されたリクエストの数ではなく、プロビジョニングされたキャパシティの合計に基づいて行われます。割り当てられたキャパシティを超えると、テーブルがリクエストを拒否し、アプリケーションユーザーのエクスペリエンスが低下する可能性があります。

プロビジョンドキャパシティモードでは、テーブルのオーバープロビジョニングや過少プロビジョニングを避けるために継続的にモニタリングしてバランスを図る必要があります。スロットリングを低く抑え、コストを調整するためです。

オンデマンドキャパシティモードを選択する場合

コストを最適化する際、次のグラフのようなワークロードを実行する場合は、オンデマンドモードが最適です。

この種のワークロードには、次の要素が影響します。

上記の要素があるワークロードでは、トラフィックの急増に対応するために自動スケーリングを使用して十分なキャパシティをテーブルに維持しようとすると、テーブルが過剰にプロビジョニングされて必要以上にコストがかかったり、テーブルがプロビジョニング不足でリクエストが必要以上にスロットリングされたりする可能性があります。オンデマンドキャパシティモードは、キャパシティを予測または調整することなく、変動するトラフィックを処理できるため、より適しています。

オンデマンドモードのリクエストごとの支払い料金モデルでは、実際に使用したスループットに対してのみ料金を支払うため、アイドル状態のキャパシティについて心配する必要はありません。消費した読み取りまたは書き込みリクエストごとに課金されるため、コストは実際の使用量を直接反映します。そのため、コストとパフォーマンスのバランスを簡単に取ることができます。オプションで、個々のオンデマンドテーブルとグローバルセカンダリインデックスに対して 1 秒あたりの読み込みや書き込み (または両方) の最大スループットを設定して、コストと使用量を制限し続けることもできます。詳細については、「オンデマンドテーブルの最大スループット」を参照してください。

プロビジョンドキャパシティモードを選択する場合

プロビジョンドキャパシティモードに最適なワークロードは、以下のグラフのように、使用パターンがより安定しており、予測可能な場合です。

この種のワークロードには、次の要素が影響します。

一定時間内または 1 日のトラフィック量が安定しているため、テーブルのプロビジョンドキャパシティは、テーブルで実際に消費されるキャパシティに比較的近い値に設定できます。プロビジョンドキャパシティテーブルのコストを最適化することは、最終的には、テーブル上で ThrottledRequests を増やすことなく、プロビジョンドキャパシティ (青色の線) を消費キャパシティ (オレンジ色の線) にできるだけ近づけるための練習になります。2 つの線の間にある空白は、未使用のキャパシティであると同時に、スロットリングによるユーザーエクスペリエンスの低下に備えた保険でもあります。アプリケーションのスループット要件を予測でき、読み取りキャパシティと書き込みキャパシティを制御するコスト予測可能性を希望する場合は、プロビジョニングされたテーブルを引き続き使用することをお勧めします。

DynamoDB は、Auto Scaling を提供しており、ユーザーに代わって自動的にプロビジョンドキャパシティテーブルのバランスを調整します。これにより、1 日を通して消費されたキャパシティを追跡し、いくつかの変数に基づいてテーブルのキャパシティを設定できます。自動スケーリングを使用する場合、テーブルは過剰にプロビジョニングされるため、ワークロードのニーズに合わせてスロットリング数と過剰にプロビジョニングされたキャパシティユニットの比率をファインチューニングする必要があります。

キャパシティユニットの最小数

テーブルの最小キャパシティを設定してスロットリングを制限することはできますが、これによってテーブルのコストが削減されるわけではありません。テーブルの使用量が少ない期間が続いた後に突然使用量が急増した場合、最小値を設定しておくと、Auto Scaling がテーブルキャパシティを低く設定しすぎるのを防ぐことができます。

キャパシティユニットの最大数

テーブルの最大キャパシティを設定すると、テーブルが意図したより大きくスケールしてしまうことを制限できます。大規模な負荷テストを実施しない開発テーブルまたはテストテーブルには最大値を適用することを検討してください。最大数はどのテーブルにも設定できますが、本番環境で使用する場合は、誤ってスロットリングされないように、この設定をテーブルのベースラインと照らし合わせて定期的に評価してください。

目標使用率

テーブルの目標使用率を設定することは、プロビジョンドキャパシティテーブルのコストを最適化するための主な手段です。ここでパーセント値を低く設定すると、テーブルでオーバープロビジョニングされるキャパシティが増え、コストが増加しますが、スロットリングのリスクは軽減されます。パーセント値を高く設定すると、テーブルでオーバープロビジョニングされるキャパシティは減少しますが、スロットリングのリスクは増大します。

テーブルキャパシティモードを選択する際に考慮すべきその他の要素

2 つのモードのどちらかを決める際には、考慮すべき点が他にもいくつかあります。

プロビジョンドキャパシティの使用率

オンデマンドモードのコストがプロビジョンドキャパシティよりも安くなるタイミングを判断するには、プロビジョンドキャパシティの使用率を調べると便利です。これは、割り当てられた (またはプロビジョニングされた) リソースがどの程度効率的に使用されているかを示します。オンデマンドモードのコストは、プロビジョニングされた平均キャパシティ使用率が 35% 未満のワークロードで低くなります。多くの場合、プロビジョンドキャパシティ使用率が 35% を超えるワークロードでも、オンデマンドモードを使用する方が費用対効果が高くなります。特に、ワークロードのアクティビティが少ない期間とピークが混在している場合はそう言えます。

リザーブドキャパシティ

プロビジョンドキャパシティテーブルの場合、DynamoDB では読み込みおよび書き込みキャパシティ用にリザーブドキャパシティを購入できます (レプリケートされた書き込みキャパシティユニット (rWCU) と Standard-IA テーブルは現在対象外です)。リザーブドキャパシティは、標準のプロビジョンドキャパシティ料金を大幅に割引します。

2 つのテーブルモードのどちらかを決める際には、この追加の割引がテーブルのコストに与える影響を考慮してください。場合によっては、比較的予測が困難なワークロードでも、リザーブドキャパシティを利用してオーバープロビジョニングされたプロビジョンドキャパシティテーブルで実行する方が安く済む場合があります。

ワークロードの予測可能性の向上

状況によっては、ワークロードに予測可能なパターンと予測不可能なパターンの両方があるように見えることがあります。これはオンデマンドテーブルで簡単にサポートできますが、ワークロードの予測不可能なパターンを改善できれば、コストも改善できる可能性があります。

これらのパターンの最も一般的な原因の 1 つは、バッチインポートです。このタイプのトラフィックでは、ワークロードを実行するとスロットリングが発生してしまうほど、テーブルのベースラインキャパシティを超えることがよくあります。このようなワークロードをプロビジョンドキャパシティテーブルで実行し続ける場合は、次のオプションを検討してください。