Amazon DynamoDB Auto Scaling: 規模を問わないパフォーマンスとコストの最適化

データベース容量の拡大は、面倒でリスクが伴う作業になり得ます。データベースとアプリケーションの微妙な動きを理解しているベテランの開発者とデータベース管理者でさえも、この作業には細心の注意を払います。共有 NoSQL クラスターの今の時代にもかかわらず、容量の増加は何時間、何日、または何週間もかかりかねません。このようなタスクを行った人なら誰でも、容量拡大中におけるパフォーマンスへの影響は予測不可能であったり、ダウンタイムを伴う場合があることを証言できます。逆に、容量を縮小する値打ちがあると判断することは、まれな状況でしかあり得ないでしょう。これにも独自の複雑な検討事項がつきものだからです。データベース容量の計画と作業がこれほど難しいのはなぜでしょうか? データベースをアンダープロビジョニングすると、アプリケーションに壊滅的な影響を及ぼす可能性があり、オーバープロビジョニングすると、数万、または数十万ドルが無駄になる可能性があります。誰もそのような経験はしたくありません。

Amazon DynamoDB は、開発者とデータベース管理者たちが 10 年以上前から信頼してきた完全マネージド型のデータベースです。DynamoDB は、あらゆる規模で低レイテンシーパフォーマンスを実現し、データベース容量管理を大幅にシンプル化します。最小限の取り組みで、多種多様な SDK および AWS のサービスと簡単に統合される、完全にプロビジョニングされたテーブルを得ることができます。テーブルをプロビジョニングした後は、その容量をすぐさま変更できます。アプリケーションが一晩で大人気を集めたことがわかったとしても、簡単に容量を増加できます。その一方で、アプリケーションロジックを最適化し、データベーススループットを大幅に低減する場合は、プロビジョニングされた容量を減らすことでコスト節約を即座に実現できます。DynamoDB のアダプティブキャパシティーは、裏手で容量の増加と削減をスムーズに処理します。

2017 年 6 月、DynamoDB は効率的な容量管理を容易にする Auto Scaling をリリースしました。それ以来、Auto Scaling は DynamoDB ユーザーが予測可能なトラフィックパターンを持つワークロードのコストを削減できるように援助し続けています。Auto Scaling がリリースされる前は、テーブルのピークロードと小さなバッファに対応するために容量を静的にプロビジョニングしていました。しかし、大抵の場合、テーブルをピーク容量以上に静的にプロビジョニングすることはコスト効率性が良くありません。このブログ記事では、Auto Scaling がトラフィックの変化に対応する方法、Auto Scaling に最適なワークロード、ワークロードの最適化方法とコストベネフィットの計算方法、そして毎秒 100 万件のリクエストで DynamoDB が実現できるパフォーマンスについて説明します。

背景: DynamoDB Auto Scaling の仕組み

DynamoDB テーブルを作成すると、Auto Scaling がデフォルトの容量設定となりますが、それがアクティブになっていないテーブルで Auto Scaling を有効化することもできます。以下の図で説明されているように、DynamoDB Auto Scaling は背面で アプリケーションの Auto Scaling のスケーリングポリシーを使用します。DynamoDB で Auto Scaling を設定するには、ターゲット使用率の割合に加えて、読み込みキャパシティーと書き込みキャパシティーの最小レベルと最大レベルを設定します。Auto Scaling は Amazon CloudWatch を使ってテーブルの読み込みおよび読み取りのキャパシティーメトリクスを監視します。これを行うため、Auto Scaling は消費された容量を追跡する CloudWatch アラームを作成します。

上限しきい値アラームは、消費された読み込みキャパシティーまたは読み取りキャパシティーがターゲット使用量の割合を連続する 2 分間超過するとトリガーされます。下限しきい値アラームは、トラフィックがターゲット使用率から 20 パーセントを差し引いた値を連続する 15 分間下回るとトリガーされます。アラームがトリガーされると、CloudWatch が Auto Scaling アクティビティを開始します。これは、消費された容量をチェックし、テーブルのプロビジョニングされた容量を更新します。例えば、読み込みキャパシティーユニット (RCU) を 100、ターゲット使用率を 80 パーセントに設定すると、Auto Scaling は、使用率が連続する 2 分間 80 RCU を超える場合にプロビジョニングされた容量を増加させ、消費量が 15 分間 60 RCU (100RCUの80 パーセントより 20 低い60%のRCU) を下回る場合は容量を削減します。

以下のグラフは、Auto Scaling がないテーブルがどのように静的にプロビジョニングされるかを示しています。赤線はプロビジョニングされた容量で、青い部分は消費された容量です。消費のピークはプロビジョニングされた容量のほぼ 80 パーセントで、これは標準のオーバーヘッドバッファを表しています。赤線と青い部分の間にある領域が未使用の容量です。

DynamoDB Auto Scaling は、プロビジョニングされた容量と消費された容量の間の領域にある未使用の容量を少なくします。以下のグラフは、この記事で使用するワークロード例からのもので、これには Auto Scaling が有効化されています。このグラフから、消費された容量とプロビジョニングされた容量の比率が改善されていることが分かります。これによって、十分な動作容量を提供しながら、無駄なオーバーヘッドが低減されます。

この記事の残りの部分では、DynamoDB Auto Scaling が、容量管理のすべてとは言わずとも、そのほとんどをオートメーションに委ねることを可能にする方法について説明していきます。

テストのセットアップ

このブログ記事の Auto Scaling を実演するために、24 時間の周期的なワークロードを生成しました。このワークロードのパターンは、1 日の間にトラフィックがピークまで増加し、その後低減する現実のアプリケーションの多くを表しています。このパターンの例には、Internet of Things (IoT) 企業のメトリクス、オンライン小売業者のショッピングカートデータ、およびソーシャルメディアアプリで使用されるメタデータが含まれます。

今回は、AWS Elastic Beanstalk にカスタムの Java ロードジェネレータをデプロイしてから、CloudWatch ダッシュボードを作成しました。以下のスクリーンショットにあるこのダッシュボードは、リクエストレート、平均的なリクエストレイテンシー、読み込みと書き込みのためにプロビジョニングされた容量と消費された容量といった主なパフォーマンスメトリクスを監視します。

ダッシュボードで示されているように、ジェネレータは、着々と増加し、正午にピークを迎え、その後ゼロまで低減する周期的な負荷を作成しました。テストは、カーディナリティが高いキー分散が行われている、ランダムに作成されたアイテムを使用して読み込みおよび書き込みを生成しました。変化を付けるために、平均サイズが 4 KB の 10 のアイテムサイズを用意しました。毎秒 1,000,000 リクエストのピークロードを達成するために、平均的なアイテムサイズ、リクエストレート、20 パーセントのオーバーヘッド、および読み込み/書き込み比率を使って、テーブルに 2,000,000 WCU　および 800,000 RCU (キャパシティー計算のドキュメント) が必要であることを見積りました。ベストプラクティスに従って、ロードジェネレータアプリケーション (ClientConfiguration javadocs) で useTcpKeepAlive が有効化されていることも確実にしました。この設定は、リクエストごとに接続を再確立するのではなく、TCP 接続を再利用するようクライアントに伝えることから、オーバーヘッドを低減し、パフォーマンスを向上させるために役立ちます。

テスト結果

テストは、最終的に毎秒 1,100,000 リクエストのピークに到達しました。DynamoDB Auto Scaling は、積極的にプロビジョニングされた容量を生成されたトラフィックに一致させており、これは効率的にプロビジョニングされたワークロードが存在したことを意味します。テストにおけるサービス側の平均的なリクエストレイテンシーは、読み込みでは 2.89 ミリ秒、書き込みでは 4.33 ミリ秒でした。驚くことに、平均的なリクエストレイテンシーは、テーブルでの負荷の増加に従って少なくなりました。

以下のスクリーンショットは、DynamoDB コンソールのメトリックスタブからのものです。右側のスクリーンショットにあるように、読み込みリクエストレイテンシーはピークロードで約 2.5 ミリ秒まで降下しています。

同様に、書き込みレイテンシー (以下のスクリーンショットの右側参照) も 4 ミリ秒をわずかに超えるところまで降下しました。

これらの結果は、控えめに言っても驚くべきものです。従来、負荷がかかったデータベースはトラフィックに比例してどんどん遅くなるため、負荷とともにパフォーマンスが向上するのが見られるのは注目に値することです。調査をいくつか行うことによって、この低いレイテンシーは、すべてのリクエストが同じテーブルにアクセスしたために強化された DynamoDB における内部最適化によるものであることが明らかになりました。useTcpKeepAlive 設定も、1 接続あたりにより多くのリクエストという結果を生じ、低いレイテンシーの実現に役立ちました。

Auto Scaling はどれほど良く容量を管理したでしょうか? Auto Scaling は、その日全体を通じて堅実なプロビジョニング済み容量対消費済み容量の比率を維持しました。最初の 1 時間に、ロードジェネレータが 2 分間あたり 80 パーセントを超える速さでトラフィックを増加させた短い期間がありました。しかし、バーストキャパシティーのおかげで、その影響はごくわずかでした。メトリクスは、読み込みリクエスト 335 万件あたり 15 件のスロットル読み込みイベントがあったことを示しており、これは 1 万分の 4 パーセントです。この初期期間の後、スロットリングはありませんでした。

この記事で前述したとおり、CloudWatch はテーブルアクティビティを監視し、しきい値の超過が設定された期間続くと対応します。以下の CloudWatch からのスナップショットは、ターゲット使用率アラームのアクティビティを示しています。これから分かるように、読み込みと書き込みの消費された容量とプロビジョニングされた容量を追跡するために 2 分および 15 分の期間を用いる上限しきい値と下限しきい値があります。

使用率アラームは、次にスケーリングイベントをトリガーしました。これは、DynamoDB 容量タブの Auto Scaling アクティビティとして確認できます (以下のスクリーンショットを参照)。Auto Scaling は単独で、プロビジョニングされた読み込みキャパシティーと書き込みキャパシティーを、しきい値を超過した消費済み容量に変更しました。

テストは、最終的に毎秒 100 万リクエストを超えました。以下のグラフは、読み込み (青い部分) と書き込み (オレンジの部分) の両方を示しており、665 万/60 秒間 = 毎秒 111 万リクエストになります。

このテストは、トラフィックが 80 パーセントのターゲット使用率に到達したときに、Auto Scaling が 2 分ごとにプロビジョニングされた容量を増加させたことを実証しました。この記事の前のスクリーンショットから、スケールダウン期間が長くなっていたことに気が付かれたかもしれません。これは、消費量が 15　分間ターゲット使用率よりも 30 パーセント低くなると、Auto Scaling が容量を低減するからです。キャパシティーをゆっくりと低減するのは仕様であり、これは 1 日あたりの減少に対する制限に適合するものです。

DynamoDB Auto Scaling の絶え間ない更新は、効率的にプロビジョニングされたテーブルと、次のセクションで説明する 30.8 パーセントの節約につながりました。このテストは、毎秒 100 万件のリクエストにおける DynamoDB の一貫性のあるパフォーマンスと低レイテンシーを明確に実証しました。

Auto Scaling によるコスト最適化: プロビジョンドキャパシティー、オンデマンドキャパシティー、リザーブドキャパシティー

このセクションでは、静的なプロビジョニング、Auto Scaling、およびオンデマンドの各オプションでのテーブルコストを比較します。また、リザーブドキャパシティーがコストモデルをどのように最適化するかも計算します。

覚えておられるかと思いますが、静的にプロビジョニングされた従来のテーブルは、容量を期待されるピークロードよりも 20 パーセント多く設定し、今回のテストでは 2,000,000 WCU および 800,000 RCU になります。書き込みおよび読み込みのキャパシティーユニットは 1 時間単位の料金設定となっているため、毎月のコストは、プロビジョニングされた WCU と RCU にユニット時間あたりのコスト (.00013 USD/RCU　および .00065 USD/WCU) を掛けてから、それに平均的な月の時間数 (730) を掛けて計算します。すべてのユニットコストは DynamoDB 料金ページに記載されています。そうすると、今回のテストのための静的にプロビジョニングされたテーブルのコストは 1 月あたり 1,024,920 USD になります。

1,024,920 USD/月 = 730 時間 × ((2,000,000 × .00065 USD) + (800,000 × .00013 USD))

この記事で実行した Auto Scaling テストの実際のコストを計算するために、サービスおよび日付ごとにコストを特定するために役立つ請求の要素である AWS 使用状況レポートを使用します。使用状況レポート内には、WriteCapacityUnit-Hrs、ReadCapacityUnit-Hrs、および TimeStorage-ByteHrs という DynamoDB 向けの 3 つの主なコスト単位があります。ここでは最初の 2 つに注目します。ストレージコストは最低限であることと、他の設定にかかわらず同じであることから無視できます。以下のスクリーンショットでは、テストの読み込みと書き込みコストがわかり、1 日あたり合計で 23,318.06 USD です。

毎月 30.4 日 (365 日/12 か月) とすると、Auto Scaling は平均で 1 月あたり 708,867 USD になり、先ほど計算した静的にプロビジョニングされたテーブルのコスト (1,024,920 USD) よりも 316,053 USD (つまり 30.8 パーセント) 少ない金額です。

毎月の節約 316,053 USD = 静的なプロビジョニングの 1,024,920 USD – Auto Scaling の 708,867 USD

これは、Auto Scaling がテーブルのコストをどのように削減したかを示しています。本番環境では、Auto Scaling によってプロビジョニングされたテーブルの計画と管理に関連する業務時間を短縮することが可能です。これらの運用上の節約は、DynamoDB におけるどのワークロードのコスト見積りにも含めることができます。

では、Auto Scaling による節約をオンデマンドキャパシティモードによる節約と比べるとどうでしょうか? オンデマンドでは、DynamoDB が必要に応じて即座に容量を割り当てます。プロビジョンドキャパシティーという概念はなく、CloudWatch のしきい値、またはそれに続くテーブルの更新を待つことによる遅れもありません。オンデマンドは、トラフィックが数秒または数分でスパイクし、アンダープロビジョニングされた容量がユーザー経験に影響を及ぼすバースト的、新規、または予測不能なワークロードに適しています。オンデマンドは、チームが NoOps またはサーバーレス環境に移行している場合に最適のソリューションです。サーバーレスワークフローのコストベネフィットはこのブログ記事の対象外であり、今回のテストでは徐々に変化するトラフィックを使っているため、オンデマンドはこの比較にはあまり適していませんが、それらの計算方法を理解するために、とりあえずコストを見てみましょう。

オンデマンドキャパシティーモードの料金には、100 万件の書き込みまたは読み込みユニットそれぞれに 1.25 USD および .25 USD が設定されています。1 日のうちにテストが使用した WCU と RCU の合計を特定するため、CloudWatch ダッシュボードに戻ります。先ほどは、1 分あたりのリクエスト数を追跡したことを覚えておられると思います。これは 「メトリクスとディメンション」文書で説明されているとおり、SuccessfulRequestLatency の SampleCount メトリクスを使って行いました。このメトリクスの期間を丸 1 日に変更することによって、以下のスクリーンショットにあるように、読み込みと書き込みのリクエストの合計数がわかります。このリクエスト数とともに、テストの平均オブジェクトサイズ (4 KB) を使って、オンデマンドモードではいくつの WCU と RCU が使われるかを概算できます。消費された容量を計算するための方程式は、このドキュメントで詳しく説明されています。

RCU と WCU のコストを統合することによって、毎月のオンデマンドコストを 2,471,520 USD と見積もることができます。

2,471,520 USD/月 = 30.4 日 × (5,800 USD + 75,500 USD)

Auto Scaling での 1 月あたり 708,867 USD と比べてオンデマンドモードのコストが高いのは、今回のテストが予測可能なワークロードを使っていることと、実際の NoOps コストベネフィットを考慮していないことから当然のことです。ここで覚えておく点は、このワークロードが Auto Scaling とコスト最適化にぴったりな候補であるということです。

Auto Scaling は大幅なコスト節約を実現しますが、さらに節約することはできるのでしょうか? リザーブドキャパシティーは、どのようにコスト最適化に組み入れればよいでしょうか? DynamoDB のリザーブドキャパシティーは Amazon EC2 リザーブドインスタンスモデルと一致しています。ユーザーは 1 年期間または 3 年期間でリザーブドキャパシティーを購入して、大幅な割引を受けます。リザーブドキャパシティーは、100 WCU または 100 RCU のセットで購入します。比較のために、1 年の予約モデルを使用しましょう。1 WCU のリザーブドキャパシティーの料金は、1 時間あたり .000299 USD になります。

.000299 USD/時間 = ((150 USD の予約 ÷ 8,760 時間/年) + 予約された WCU .0128 USD/時間 ) ÷100 ユニット

これは標準価格の 46 パーセント、つまり .00065 USD で、大幅な節約になります。予約された RCU についてもコスト節約は変わらず、予約された RCU 1 つあたり .000059 USD、または標準の RCU 1 つあたり .00013 USD です。

.000059 USD/時間 = ((30 USD の予約 ÷ 8,760 時間/年) + 予約された RCU .0025 USD/時間) ÷ 100 ユニット

Auto Scaling と リザーブドキャパシティーは連携させることができるのでしょうか? できます! リザーブとプロビジョニングのコストの比率を使って、リザーブドキャパシティーと Auto Scaling を混合したコストを見積もることができます。例えば、リザーブドキャパシティーのコストは標準価格の 46 パーセントであることがわかっているので、1 日のうち 46 パーセント以上アクティブな容量の任意の部分をリザーブドキャパシティーとして節約できるはずです。正午を端点として使って、比率の転移点を計算することができます。そうすると、12 時間の 46 パーセントは正午の 5.5 時間前、つまり午前 6:30 になります。

正午の 331 分前 = 46% × (12 時間 × 60 分)

DynamoDB は時間単位で課金され、時間単位の使用率のメトリクスは請求レポートからダウンロードできます。リザーブドキャパシティーと Auto Scaling 間の移行のために午前 6:30 を切り上げて午前 7:00 にします。CloudWatch ダッシュボードは、午前 7:00 に 174 万の WCU と 692,000 の RCU があったことを示しています。混合コストを見積もるために、RCU と WCU のリザーブドレートを使い、午前 7:00 から午後 7:00 (負荷が予約量を下回る時刻) までの Auto Scaling の 1 時間あたりの使用率を追加します。以下のスクリーンショットは、予約された WCU と Auto Scaling WCU との間の混合比率を示しています。

1 時間あたりの使用率は、請求コンソールからダウンロードしました。以下の表は、混合比率における Auto Scaling 部分の 1 時間あたりのコストを示しています。リザーブドキャパシティーは個別に追加されたことから、RCU および WCU から差し引かれています。

リザーブドキャパシティーの毎月のコストを計算するため、ユニットの合計数に予約されたユニットのコスト (1 WCU 時間あたり .000299 USD、1 RCU 時間あたり .000059 USD) を掛けてから、ひと月の時間 (730) を掛けました。

379,789 USD/月 = 174 万 WCU × .000299 USD × 730 時間
29,804 USD/月 = 692,000 RCU × .000059 USD × 730 時間

合計すると、リザーブドキャパシティーの合計コストは 1 月あたり 409,593 USD になります。これを Auto Scaling のコスト (1,668.88 USD x 30.4 日で 50,734 USD) に足すことによって、毎月の混合レート 460,327 USD を求めることができます。これは、Auto Scaling の見積り 708,867 USD よりも 248,540 USD 低い値段です。

3 年期間のリザーブドキャパシティーオプションも使用でき、これは 75 パーセントを超える割引です。大幅な割引のため、すべてのリザーブドキャパシティーを静的にプロビジョニングすることがコスト効率性の良い方法です。

以下の表は、最適化のテスト結果を要約したものです。この表では、各シナリオを比較し、静的にプロビジョニングされたテーブルについての関連節約に注目しています。皆さんのワークロードパターンはこれとは異なるため、独自のパターンに基づいて節約金額を計算する必要があります。今回説明した最適化を使用することによって、コストを大幅に削減することができます。

Auto Scaling とコスト最適化について覚えておく重要点

それでは、この記事の DynamoDB Auto Scaling テストの結果と、学んだ教訓を見直しましょう。

• Auto Scaling の仕組みは? このテストで、Auto Scaling はトラフィックに迅速に適応するために CloudWatch アラームを使用しました。Auto Scaling は、数分以内でテーブルのプロビジョニングされた容量を負荷と一致するように更新しました。Auto Scaling はスケールダウンするよりも迅速にスケールアップし、これはターゲット使用率を設定することによって調整できます。今回のテストでは、Auto Scaling がオーバーヘッドを低減させながら、十分な容量を提供しました。
• Auto Scaling は重要ではないワークロードをどのように処理したか? 非常によく処理しました。今回は 12 時間のうちにリクエストがゼロから毎秒 110 万件に増加する負荷テストを実行し、Auto Scaling はターゲット使用率のしきい値を超過するたびにテーブルを更新しました。Auto Scaling アクティビティをチェックしたところ、Auto Scaling が正確かつ迅速に更新を行っていたことが確認されました。Auto Scaling はパフォーマンスを劣化させませんでした。むしろ、トラフィックが毎秒 1,100,000 リクエストに増加すると、各リクエストの平均レイテンシーが低減しました。
• Auto Scaling はコスト削減に役立つのか? このテストで、Auto Scaling はコストを 30.8 パーセント削減しました。テストには 80 パーセントのターゲット使用率を使用しましたが、節約額を増やし、容量が適切に割り当てられていることを確実にするために、ワークロードそれぞれのターゲット使用率を調整するようにしてください。また、この記事では 1 年期間のリザーブドキャパシティーと Auto Scaling の組み合わせを使うことによってコストをさらに最適化する方法もご紹介しました。テストでは、これによってコストが 55.1 パーセント削減されました。

このように、アクティブに変化するトラフィックでの DynamoDB Auto Scaling の使用には説得力のある理由があります。Auto Scaling は迅速に応答し、容量管理をシンプル化することから、テーブルのプロビジョニングされた容量のスケーリングを行い、運用上のオーバーヘッドを低減することによってコストが削減されます。

著者について

Daniel Yoder は LA を拠点とする AWS のシニア NoSQL スペシャリストソリューションアーキテクトです。

Sean Shriver はダラスを拠点とし、DynamoDB に焦点を当てるシニア NoSQL スペシャリストソリューションアーキテクトです。