翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
DAX クラスターサイジングガイド
このガイドでは、Amazon Amazon DynamoDB Accelerator (DAX) クラスターの適切なサイズとノードタイプを、アプリケーションのために選択する際のアドバイスを提供します。以下の手順では、アプリケーションでの DAX トラフィックの見積もりと、クラスター設定の選択、およびそのテストを行うためのチュートリアルが得られます。
既に DAX クラスターが存在し、そのクラスターに適切な数とサイズのノードが備わっているどうかを評価したい場合は、「DAX クラスターのスケーリング」を参照してください。
概要
新しい DAX クラスターを作成する場合も、既存のクラスターをメンテナンスしている場合も、ワークロードに合わせてクラスターを適切にスケーリングすることが重要です。時間が経過し、アプリケーションのワークロードが変化するにつれて、スケーリングに関する決定を定期的に再検討して、それらが引き続き適切であることを確認する必要があります。
通常、このプロセスは以下の手順に従います。
-
トラフィックの見積もり。このステップでは、アプリケーションから DAX に送信されるトラフィックのボリュームや、そのトラフィックの性質 (そのオペレーションが読み込みか書き込みか)、および予想されるキャッシュヒット率についての推定を行います。
-
負荷テスト。この手順では、クラスターを作成し、前のステップからの見積もりをミラーリングするクラスターにトラフィックを送信します。適切なクラスター設定が見つかるまで、この手順を繰り返します。
-
本番稼働モニタリング。実稼働のアプリケーションで DAX を使用する場合には、クラスターをモニタリングしながら、時間的なワークロードの変動に応じてそのクラスターが正しくスケーリングされていることを、継続的に検証する必要があります。
トラフィックの見積もり
一般的な DAX ワークロードの特性は、以下の 3 つの主要素により表されます。
-
キャッシュヒットレート
-
1 秒あたりの読み込みキャパシティーユニット (RCU)
-
1 秒あたりの書き込みキャパシティーユニット (WCU)
キャッシュヒットレートの見積もり
既存の DAX クラスターについては、ItemCacheHits および ItemCacheMisses の Amazon CloudWatch メトリクスを使用することでキャッシュヒット率を確認できます。キャッシュヒット率は ItemCacheHits / (ItemCacheHits + ItemCacheMisses) に等しくなります。ワークロードに Query または Scan オペレーションが含まれている場合は、QueryCacheHits、QueryCacheMisses、ScanCacheHits、および ScanCacheMisses の各メトリクスも確認する必要があります。キャッシュヒット率はアプリケーションごとに異なり、クラスターの有効期限 (TTL) 設定から大きな影響を受けます。DAX を使用するアプリケーションでの標準的なキャッシュヒット率は、85～95% です。
読み込みキャパシティユニットと書き込みキャパシティユニットの見積もり
アプリケーション用の DynamoDB テーブルが既に存在する場合は、ConsumedReadCapacityUnits および ConsumedWriteCapacityUnits の CloudWatch メトリクスを確認します。Sum 統計を使用して、期間の秒数で除算します。
DAX クラスターも既に存在する場合、DynamoDB の ConsumedReadCapacityUnits メトリクスでは、キャッシュミスのみが計算されることに注意してください。DAX クラスターで処理される 1 秒あたりの読み込みキャパシティーユニットの数を把握するには、このメトリクスからの数値をキャッシュミス率 (つまり、1 - キャッシュヒット率) で割ります。
まだ DynamoDB テーブルを用意していない場合は、「読み込みキャパシティーユニット」および「書き込みキャパシティーユニット」のドキュメントを参照して、アプリケーションの推定リクエスト率、リクエストごとにアクセスされる項目、およびアイテムのサイズに基づいて、トラフィックを見積もります。
トラフィックの見積もりを行う際、将来の増大と予想されるピークと予想外のピークを計画して、トラフィックの増加に十分なヘッドルームがクラスターにあることを確認します。
負荷テスト
トラフィックを見積もった後の次の手順は、負荷をかけてクラスター設定をテストすることです。
-
最初の負荷テストでは、
dax.r4.largeノードタイプ、最もコストの低い固定パフォーマンス、メモリ最適化ノードタイプから開始することをお勧めします。 -
耐障害性の高いクラスターには、3 つのアベイラビリティーゾーンにまたがって分散される少なくとも 3 つのノードが必要です。この場合、アベイラビリティーゾーンが使用できなくなると、有効なアベイラビリティーゾーンの数が 3 分の 1 減少します。最初の負荷テストでは、3 ノードクラスター内の 1 つのアベイラビリティーゾーンの障害をシミュレートする 2 ノードクラスターから開始することをお勧めします。
-
負荷テスト期間中、持続的なトラフィック (前のステップで見積もったもの) をテストクラスターに駆動します。
-
負荷テスト中にクラスターのパフォーマンスをモニタリングします。
理想的には、負荷テスト中に駆動するトラフィックプロファイルは、アプリケーションの実際のトラフィックと可能な限り類似している必要があります。これには、オペレーションの分散 (GetItem 70%、Query 25%、PutItem 5% など)、各オペレーションのリクエスト率、リクエストごとにアクセスされた項目数、項目サイズの分散が含まれます。アプリケーションの予想キャッシュヒット率と同様のキャッシュヒット率を達成するには、テストトラフィックでのキーの分散に細心の注意を払います。
注記
T2 ノードタイプ (dax.t2.small および dax.t2.medium) をロードテストする際は注意してください。T2 ノードタイプは、ノードの CPU クレジットバランスに応じて時間の経過とともに変化する、バースト可能な CPU パフォーマンスを提供します。T2 ノードで実行されている DAX クラスターのオペレーションが正常に見える場合でも、いずれかのノードがそのインスタンスのパフォーマンスベースラインを上回ってバーストする場合には、そのノードは蓄積 CPU クレジット残高を消費しています。クレジットで実行中のノードが少ない場合、パフォーマンスは次第にベースラインのパフォーマンスレベルに下がります。
負荷テストにより、DAX クラスターをモニタリングして、そこで使用しているノードタイプが適切なノードタイプであるかどうかを判断します。さらに、負荷テスト中にリクエスト率とキャッシュヒット率をモニタリングして、テストインフラストラクチャが意図したトラフィック量を実際に駆動していることを確認する必要があります。
選択したクラスターインスタンスタイプのネットワークバイト消費量に注意する必要があります。Amazon EC2 インスタンスで使用可能なベースライン帯域幅を超えると、クラスターがアプリケーションのワークロードに耐えられなくなり、スケーリングする必要が出てくるかもしれません。
負荷テストにより、選択したクラスター設定ではアプリケーションのワークロードを維持できないことが示された場合、特にクラスター内のプライマリノードでの高い CPU 使用率や、高い削除率、あるいは高いキャッシュメモリー使用率が見られる場合には、より大きなノードタイプに切り替える必要があります。ヒット率が一貫して高く、書き込みトラフィックに対する読み込みトラフィックの比率が高い場合は、ノードをクラスターに追加することを検討してください。どのような場合により大きなノードタイプを使用するか (垂直スケーリング)、ノードを追加するか (水平スケーリング) の詳細なガイダンスについては、「DAX クラスターのスケーリング」を参照してください。
クラスター設定を変更した後、負荷テストを繰り返す必要があります。
