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

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

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

DynamoDB テーブルを作成する場合、オンデマンドまたはプロビジョンドキャパシティモードのいずれかを選択する必要があります。この設定は 24 時間に 2 回変更できるため、今後変更する必要があるとしても心配はいりません。

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

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

オンデマンドテーブルは、テーブルに対する実際のリクエスト数をカウントして請求されるため、お支払いいただくのは、プロビジョニングされたものではなく、実際に使用した分のみです。

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

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

プロビジョンドキャパシティモードでは、スロットリングを低く抑え、コストを調整するために、テーブルのオーバープロビジョニングを避ける、あるいはプロビジョニングを不足させないというバランスが必要になります。

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

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

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

• リクエストのタイミングが予測できない (トラフィックの急増につながる)

• リクエストの量が変動する (バッチワークロードに起因)

• 一定時間、ゼロまで低下する、またはピーク時の 18% を下回る (開発環境またはテスト環境に起因)

上記の要素があるワークロードでは、トラフィックの急増に対応するのに Auto Scaling を使用して十分なキャパシティをテーブルに維持しようとすると、テーブルが過剰にプロビジョニングされて必要以上にコストがかかったり、テーブルがプロビジョニング不足でリクエストが不必要にスロットリングされたりする可能性があります。

オンデマンドテーブルはリクエストに応じて請求されるため、コストを最適化するためにテーブルレベルでこれ以上何かを行う必要はありません。オンデマンドテーブルを定期的に評価して、ワークロードに上記の要素がいまだに残っていることを確認する必要があります。ワークロードが安定したら、コストをさらに最適化するためにプロビジョンドモードに変更することを検討してください。

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

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

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

• 特定の時間または 1 日のトラフィックが予測可能/周期的

• トラフィックの急増が短期間で限定的

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

DynamoDB は、Auto Scaling を提供しており、ユーザーに代わって自動的にプロビジョンドキャパシティテーブルのバランスを調整します。これにより、1 日を通して消費されたキャパシティを追跡し、いくつかの変数に基づいてテーブルのキャパシティを設定できます。

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

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

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

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

目標使用率

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

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

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

リザーブドキャパシティ

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

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

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

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

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

• スケジュールされた時間にバッチが行われる場合は、バッチの実行前に Auto Scaling のキャパシティを増やすようにスケジュールできます。

• バッチがランダムに行われる場合は、できるだけ速く実行するよりも、実行する時間を延長することを検討してください。

• Auto Scaling でテーブルキャパシティの調整を開始できるようになるまで、インポートの速度を小さく開始し、数分かけてゆっくりと速度を上げていくランプアップ時間をインポートに追加します。