翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
このセクションでは、Amazon Keyspaces テーブルで、適切なキャパシティモードを選択する方法の概要を説明します。各モードは、スループットの変化に対する応答性や使用に対する請求方法という点で、さまざまなワークロードのニーズを満たすように調整されています。決定を下す際には、これらの要素のバランスを取る必要があります。
利用可能なテーブルキャパシティモード
Amazon Keyspaces テーブルを作成するとき合、オンデマンドキャパシティモードとプロビジョンドキャパシティモードのいずれかを選択する必要があります。詳細については、「Amazon Keyspaces で読み取り/書き込みのキャパシティモードを設定する」を参照してください。
オンデマンドキャパシティモード
オンデマンドキャパシティモードでは、Amazon Keyspaces テーブルのキャパシティをプランニングまたはプロビジョニングする必要がありません。このモードでは、リクエストにテーブルが即座に対応します。いかなるリソースもスケールアップやスケールダウンの必要はありません (テーブルの過去のピークスループットの最大 2 倍まで対応可能)。
オンデマンドテーブルは、テーブルに対する実際のリクエスト数をカウントして請求されるため、お支払いいただくのは、プロビジョニングされたリクエスト数ではなく、実際に使用したリクエスト分のみです。
プロビジョンドキャパシティモード
プロビジョンドキャパシティモードは従来型のモデルで、リクエストに対して利用できるテーブルのキャパシティを、直接、または Application Auto Scaling で定義できます。特定のキャパシティが指定された時間にテーブルにプロビジョニングされるため、請求はリクエスト数ではなく、プロビジョニングされたキャパシティに基づいて行われます。割り当てられたキャパシティを超えると、テーブルはリクエストを拒否し、アプリケーションのユーザーのエクスペリエンスが低下する可能性があります。
プロビジョンドキャパシティモードでは、テーブルをオーバープロビジョニングとアンダープロビジョニングの双方の間で調整して、スループットキャパシティエラーの発生率の軽減と、コスト最適化の両方を実現する必要があります。
オンデマンドキャパシティモードを選択する場合
コストを最適化する際、次のグラフに示すような想定外のワークロードがある場合は、オンデマンドモードが最適です。
この種のワークロードには、次のような要素が影響します。
-
リクエストのタイミングが予測できない (トラフィックの急増につながる)
-
リクエストの量が変動する (バッチワークロードに起因)
-
一定時間、ゼロまで低下する、またはピーク時の 18% を下回る (開発環境またはテスト環境に起因)
上記のような特性のワークロードでは、Application Auto Scaling を使用してテーブルがトラフィックの急増に対応できる十分なキャパシティを維持すると、望ましくない結果が生じるおそれがあります。その場合、テーブルの過剰なプロビジョニングによって必要以上のコストが発生するか、テーブルのプロビジョニングが不十分でリクエストに不必要な低キャパシティスループットエラーが発生するおそれがあります。このような場合は、オンデマンドテーブルの方が適しています。
オンデマンドテーブルはリクエストに応じて請求されるため、コスト最適化のためにテーブルレベルでこれ以上の対応は不要です。オンデマンドテーブルを定期的に評価して、ワークロードに上記の現象が引き続き残っていることを確認してください。ワークロードが安定したら、コスト最適化のためにプロビジョンドモードへの変更を検討してください。
プロビジョンドキャパシティモードを選択する場合
プロビジョンドキャパシティモードに最適なワークロードは、以下のグラフに示すように、使用パターンを予測しやすい場合です。
予測可能なワークロードには、次のような要素があります。
-
特定の時間または 1 日のトラフィックが予測可能/周期的
-
トラフィックの急増が短期間で限定的
一定時間内または 1 日のトラフィック量が安定しているため、プロビジョンドキャパシティは、テーブルで実際に消費されるキャパシティに比較的近い値に設定できます。プロビジョンドキャパシティテーブルのコストの最適化は、最終的には、テーブル上で ThrottledRequests
イベントを増やさずに、プロビジョンドキャパシティ (青色の線) を消費キャパシティ (オレンジ色の線) にできるだけ近づける練習になります。2 つの線の間にある空白は、未使用のキャパシティであると同時に、スループットキャパシティ不足エラーによるユーザーエクスペリエンスの低下に備えた保険にもなります。
Amazon Keyspaces は、Application Auto Scaling を備えており、あなたに代わって自動的にプロビジョンドキャパシティテーブルのバランスを調整してくれます。1 日を通して消費されたキャパシティを追跡し、いくつかの変数に基づいてテーブルのプロビジョンドキャパシティを設定できます。
キャパシティユニットの最小数
テーブルの最小キャパシティを設定すると、スループットキャパシティ不足のエラーの発生を抑えることはできますが、これによってテーブルのコストが削減されるわけではありません。テーブルの使用量が少ない期間が続いた後に突然使用量が急増した場合、最小値を設定しておくと、Application Auto Scalingによって低すぎるテーブルキャパシティが設定されるのを防ぐことができます。
キャパシティユニットの最大数
テーブルの最大キャパシティを設定すると、テーブルが意図したより大きくスケールしてしまうことを制限できます。大規模な負荷テストが望ましくない開発テーブルやテストテーブルには最大値の適用を検討してください。最大数はどのテーブルにも設定できますが、本番環境で使用する場合は、不意のスループットキャパシティ不足エラーを防ぐため、この設定はテーブルのベースラインと照らし合わせて定期的に評価してください。
目標使用率
テーブルの目標使用率を設定することは、プロビジョンドキャパシティテーブルのコストを最適化するための主な手段です。ここでパーセント値を低く設定すると、テーブルでオーバープロビジョニングされるキャパシティ増により、コストが増加しますが、スループットキャパシティ不足エラーのリスクは軽減できます。パーセント値を高く設定すると、テーブルの過剰プロビジョニングの割合を軽減できますが、スループットキャパシティ不足エラーが発生するリスクが高まります。
テーブルキャパシティモードを選択する際に考慮すべきその他の要素
2 つのキャパシティモードのどちらかを選択する際には、考慮すべき点が他にもいくつかあります。
2 つのテーブルモードのどちらかを選択する際は、この追加の割引でテーブルのコストに与えられる影響を考慮してください。多くの場合、比較的予測が困難なワークロードでも、リザーブドキャパシティを利用すればオーバープロビジョニングされたプロビジョンドキャパシティテーブルで実行する方がコスト効率が良くなる場合があります。
ワークロードの予測可能性の向上
状況によっては、ワークロードに予測可能なパターンと予測不可能なパターンの両方があるように思われる場合があります。これはオンデマンドテーブルで簡単にサポートできますが、ワークロードの予測不可能なパターンを改善できれば、コストも低くなる可能性があります。
これらのパターンの最も一般的な原因の 1 つは、バッチインポートです。このタイプのトラフィックでは、ワークロードを実行するとスループットキャパシティ不足エラーが発生してしまうほど、テーブルのベースラインキャパシティを超えることがよくあります。このようなワークロードをプロビジョンドキャパシティテーブルで実行し続ける場合は、次のオプションを検討してください。
-
予定した時間にバッチが行われる場合は、バッチの実行前にアプリケーションオートスケーリングキャパシティを増やすようにスケジュールできます。
-
バッチがランダムに行われる場合は、できるだけ速く実行することよりも、実行する時間を延長することを検討してください。
-
Application Auto Scaling でテーブルキャパシティの調整を開始できるまで、低インポート速度で開始し、数分かけてゆっくりと速度を上げていくランプアップ時間をインポートに追加します。