HAQM Web Services ブログ

ウォームスループットによる HAQM DynamoDB テーブルの事前ウォーミング

(本記事は 2024/11/03に投稿された Pre-warming HAQM DynamoDB tables with warm throughput を翻訳した記事です。翻訳は SA の嶋田朱里が担当しました。)

HAQM DynamoDB は需要に応じて自動的にスケーリングできることで有名な NoSQL データベースです。しかし、ユースケースによっては、テーブルを作成した瞬間から大量のトラフィックを処理する必要がある、または今後のイベントに備えて突発的なトラフィックの増加に対応する必要がある場合があります。このような場合に対応するために、新機能として ウォームスループット が導入されました。この機能により、DynamoDB テーブルとインデックスが即座にサポート可能なスループットを把握し、パフォーマンスを最適化するための事前ウォーミングを行うことが可能になります。

この記事では、ウォームスループットについて、その仕組みを説明し、高トラフィックシナリオを処理する際のメリットを紹介します。また、この機能を DynamoDB テーブルとインデックスで最大限活用するためのベストプラクティスと実践的なユースケースについても説明します。

DynamoDB のキャパシティモード

ウォームスループットについて説明する前に、 DynamoDB のキャパシティモードとスループットについて復習しましょう。

プロビジョンドキャパシティモードでは、予測可能なワークロードに対して、特定のスループットを設定できます。一方、オンデマンドモードは需要に合わせて自動的にスケーリングするため、予測不可能なワークロードに適しています。スループットは、Read Capacity Unit (RCU) と Write Capacity Unit (WCU) で測定されます。RCU は 1 秒あたり 4 KB の読み取りを、WCU は 1 秒あたり 1 KB の書き込みを可能にします。

詳細については、開発者ガイドの DynamoDB スループットキャパシティ を参照してください。

ウォームスループットとは

ウォームスループットは、テーブルまたはインデックスがすぐにサポートできる読み取りおよび書き込み操作について、インサイトを提供します。これらの値は使用量が増加するにつれて大きくなります。また、より高いウォームスループット値を積極的に設定することで、テーブルまたはインデックスをあらかじめ事前ウォーミングすることもできます。この方法は、商品の発売、フラッシュセール、大規模なオンラインイベントなど、瞬間的なトラフィックの急増が予想されるシナリオで特に有益です。次のビデオでは、ウォームスループットを使用して、テーブルとインデックスをあらかじめ事前ウォーミングしておくことで、商品の発売やフラッシュセールなどの重要なイベント中に生じる、大量のトラフィックの急増を効果的に処理し、レイテンシーの削減とアプリケーションの応答性向上を実現する方法を紹介しています。

ウォームスループットの理解

ウォームスループット値は、DynamoDB テーブルのスループットキャパシティの最大値を示すものではありません。むしろ、テーブルが即座に処理できる最小スループットを表しています。テーブルをあらかじめ事前ウォーミングすることで、テーブルが即座にサポートできる読み取りと書き込みの数を設定し、特定レベルのトラフィックに処理開始時から対応できるようにします。

テーブルの事前ウォーミングは非同期で行われ、他の操作を妨げることはありません。そのため、事前ウォーミング処理と同時に、他のテーブルへの更新を実行することができます。この柔軟性により、アクティブな事前ウォーミング操作中でも、更新された値を含む新しいリクエストを送信することで、いつでも簡単にウォームスループット値を調整できます。事前ウォーミング処理の完了に要する時間は、要求されたウォームスループット値とテーブルまたはインデックスのストレージサイズによって異なります。

DynamoDB のスケーリング機能は最初の事前ウォーミングだけでなく、アプリケーションの成長に合わせて動的に調整されます。時間の経過とともにワークロードが増加すると、DynamoDB は自動的にウォームスループット値を高めて、より多くのトラフィックに対応できるようになり、手動の介入なしに一貫したパフォーマンスを確保できるようになります。

例えば 1 秒あたり 10 万件の書き込みリクエストに対応するようにテーブルを事前ウォーミングした場合、そのテーブルはすぐにそのトラフィックを処理できるようになります。例えばアプリケーションのトラフィックが増加し、1 秒あたり 15 万件の書き込みリクエストに達した場合、DynamoDB はこの追加の負荷に対応するために自動的にスケーリングを行います。アプリケーションの成長ニーズに応じて、シームレスにテーブルを対応できるようにします。ウォームスループット値はテーブルの現在のキャパシティとパフォーマンス能力を正確に反映するように調整されます。

ウォームスループット値を追跡し、時間の経過とともにどのように変化するかを確認するには、DescribeTable API を使用します。この API は、テーブルとグローバルセカンダリインデックスの両方について、現在のウォームスループット値に関する詳細情報を提供します。そのため、トラフィックパターンと将来の要件に基づいた積極的な調整に役立てることができます。

事前ウォーミングの一般的なユースケース

DynamoDB テーブルの事前ウォーミングが必要かどうかを判断する前に、アプリケーションが必要とするピークスループットを理解することが重要です。ピークスループットを見積もることで、予想される負荷を DynamoDB テーブルで処理できるように準備することができ、スロットリングやパフォーマンスの問題を回避できます。以下はアプリケーションのピークスループットを計算し、事前ウォーミングが必要かどうかを判断するためのガイドです。これらのステップはオンデマンドキャパシティモードとプロビジョンドキャパシティモードのどちらのテーブルにも適用されます。

Step1：ワークロードパターンの理解

ピークスループットを計算する最初のステップは、ワークロードのトラフィックパターンを明確に理解することです。以下を考慮してください:

  • 操作の種類: 主に読み取りリクエストと書き込みリクエストのどちらを処理しますか、それとも両方のリクエストを処理しますか？
  • トラフィックの性質: 予測可能なピーク時間帯 (例えば、日次や週次のパターン) はありますか、それとも不定期な急増 (例えば、フラッシュセール、商品の発売、主要なイベントなど) がありますか？

Step2：秒間のピークリクエスト数の見積もり

ワークロードを理解したら次のステップは、アプリケーションがピーク時に処理する必要がある 1 秒あたりの読み取りリクエストと書き込みリクエストの数を見積もることです。これには 2 つの方法があります。

  • 過去のデータ: アプリケーションがすでに本番環境で稼働している場合は、トラフィックログやモニタリングデータを確認して、ピーク時の 1 秒あたりの最大読み取りリクエスト数と書き込みリクエスト数を特定します。これらの値をピークスループットの計算の基準として使用します。
  • 予測: 将来のイベントやリリースに備える場合は、想定されるトラフィックの増加を予想し、ピークスループットを見積もります。ユーザー数、ユーザーあたりの予想アクション数 (商品の閲覧回数や取引回数など)、ピーク時間の長さを考慮します。

Step3：読み取りと書き込みのキャパシティユニットの計算

リクエスト数の推定値を取得したら、DynamoDB テーブルに必要な読み取りリクエストユニット (RRU) と書き込みリクエストユニット (WRU) を計算できます。この例では、オンデマンドキャパシティモードの値を使用していますが、プロビジョンドキャパシティモードのテーブルでも同様のプロセスになります。

  • RRU: 強い整合性の読み取りの場合、 1つのアイテム (最大 4 KB) を読むために 1 RRU が消費されます。結果整合性の読み取りの場合、 1 つの RRU で 2 つの読み取りリクエスト (最大 4 KB) が可能です。RRU を計算するには:
    • アイテムの平均サイズを KB で計算する
    • アイテムの平均サイズを 4 で割る
    • 1 秒あたりの読み取りリクエスト数を掛ける
    • 結果整合性の読み取りか強い整合性の読み取りかに基づいて調整する
    • 注: 小さいアイテムを扱う場合、強い整合性の読み取りリクエストでは 1 RRU、結果整合性の読み取りリクエストでは 0.5 RRU を消費する
  • WRU: 1 つのアイテム (最大 1 KB) を書き込むために 1 つの WRU が消費されます。WRU を計算するには:
    • アイテムの平均サイズを KB で計算する
    • 1 秒あたりの書き込みリクエスト数を掛ける

キャパシティユニットの詳細については、開発者ガイドを参照してください。

Step4：変動性を考慮する

大抵の場合、トラフィックは一定ではないため、最初の見積もりを超えるトラフィックの急増に備えることも重要です。予期しないスパイクに対応できるよう、ピークスループットの計算にはバッファを追加することを検討してください。

例えばピーク時に 80,000 WRU/秒と見積もった場合、需要の急増に対応するために 100,000 WRU/秒で事前ウォーミングを行うことを検討してください。ただし、余裕を持って事前ウォーミングを行うと、追加コストが発生する可能性があります。

Step5：事前ウォーミングの必要性の判断

ピーク時の RRU と WRU を計算したら、これらの値をテーブルの現在のウォームスループット値と比較します。計算されたピークスループットが現在のウォームスループット値を大幅に上回る場合、または即時のトラフィックの急増 (商品の発売時やフラッシュセールなど) が予想される場合は、事前ウォーミングをお勧めします。これにより、テーブルがピークトラフィックに対応でき、パーティションの容量制限を超えた場合に発生する可能性のあるスロットリングを回避できます。システムが需要を満たすために対応する過程で、スロットリングやパーティション分割が発生すると、クライアントのレイテンシーが上昇することがあります。

ユースケース例

ウォームスループットの概念を紹介したので、次にこの機能が特に有益となる実際のユースケースを見ていきましょう。

高トラフィックに備えた新しいオンデマンドテーブルの準備

新しい DynamoDB オンデマンドテーブルは、初期のウォームスループットとして、毎秒 4,000 件の書き込みリクエストと 12,000 件の読み取りリクエストで開始します。新しいアプリケーションの起動時など、トラフィックが突然増加した場合、増加する需要を満たすために、DynamoDB は容量を徐々に拡張します。ただし、テーブルの書き込み要求が瞬時に 1 秒あたり 4,000 件を超えた場合、スケーリング処理中に一部のリクエストがスロットリングする可能性があります。このスロットリングにより、レイテンシーが増加したり、障害が発生したりして、ユーザー体験に影響が生じ、結果として収益が失われる可能性があります。

これらの問題を防ぐため、リリース時に高トラフィックが予想される場合は、テーブルを事前ウォーミングしておくことが推奨されます。事前ウォーミングにより、想定される負荷をテーブルが即座に処理できるようになり、スロットリングのリスクが低減します。DynamoDB のリアクティブなスケーリングするのを待つことなく、シームレスなユーザー体験を提供できます。

次のグラフは、新しいオンデマンドテーブルに対して実施された負荷テストを示しています。テーブルが予想以上のスループット(青線)に対応するためにスケールされるまで 、過剰なスロットリング(オレンジ線)が発生しました。

あらかじめ事前ウォーミングをすると、1 秒あたり 100,000 件の書き込みリクエストのベースラインを設定できます。DynamoDB はこのレベルのトラフィックを即座に処理できるようにテーブルをスケーリングするため、スケーリングの遅延がなくなり、スロットリングのリスクを軽減できます。

この事前準備により、ピーク時の需要でも顧客が迅速に取引を完了できるスムーズなユーザー体験を実現できます。リクエストの失敗、パフォーマンスの低下、スケーリングの遅延を心配する必要はなく、システムがイベントに備えられているという確信を得ることができます。

次のグラフは、前回と同じ負荷テストを実施したものですが、今回はテーブルを 100,000 WRU で事前ウォーミングしています。テーブルはすでにスケールアウトされ、スループットを処理する準備ができていたため、スロットリングは発生しませんでした。

大規模イベントへの準備

あなたは E コマース企業で、1 年の中で最もトラフィックが多いイベントの 1 つであるスーパーボウルの期間中に、フラッシュセールを準備しているとします。
すでに DynamoDB テーブルを用意しており、リクエストを処理できる状態にしていますが、予想されるトラフィックの急増を考えると、テーブルがその負荷に耐えられるかを確認することが重要です。推定に基づき、このイベントの最大トラフィックは 10% のバッファを含めて、100,000 件/秒の書き込みリクエストに達する可能性があると計算しました。

準備として、まず上記のように予想される負荷を計算し、現在のテーブルのウォームスループット値と比較します。推定されるピーク値が既存のウォームスループット値を上回る場合は、テーブルの事前ウォーミングが推奨されます。これにより、テーブルがトラフィックを即座に処理できるよう準備され、このような需要の高いイベント中にスロットリングや遅延が発生するリスクを軽減できます。

DynamoDB への移行の準備

既存のアプリケーションを DynamoDB に移行する際、移行開始時からテーブルが予想されるトラフィックに対応できるよう準備しておくことが、スムーズな移行のために重要です。従来のリレーショナルデータベースや他の NoSQL ソリューションから移行する場合、抽出、変換、ロード (ETL) ジョブが DynamoDB に書き込む際に、大量のデータとトラフィックの急増に対処する必要があります。

必要なキャパシティを DynamoDB テーブルにあらかじめ事前ウォーミングしておくことで、すぐに予想されるトラフィックを処理できるようになり、移行時に発生するかもしれない読み取りおよび書き込みリクエストの急増にもすぐに対応できるようになります。特にダウンタイムやパフォーマンス低下への余裕がほとんどない場合には、事前ウォーミングによって移行に伴う不確実性を排除できます。データを移行する際、DynamoDB は予想されるスループットのレベルまでスケーリングできるため、アプリケーションは高トラフィックを即座に処理することができます。

高トラフィックの E コマースプラットフォームや重要なエンタープライズワークロードを移行する場合でも、テーブルのウォームスループットの値を増やしておくことで、アプリケーションに必要なパフォーマンスのベースラインが保証され、ユーザがシステムとやり取りを開始する際の潜在的なスロットリングや遅延の問題を回避することができます。ウォームスループットのメリットとユースケースについて説明したので、続いて設定方法を説明します。

ウォームスループットの設定方法

AWS マネジメントコンソール、AWS Command Line Interface (AWS CLI)、または Software Development Kit を利用することで、事前に大量のトラフィックに備えるための設定を行うことができます。

AWS マネジメントコンソールを使用した、ウォームスループット値の設定

  1. DynamoDB コンソールに移動し、Create table を選択します。
  2. テーブルの主キー属性を指定します。
  3. Table settings の下で、Customize settings を選択します。
  4. Read/write capacity settings で、On-demand を選択します。
  5. Warm Throughput に予想される最大の読み取りリクエスト数と書き込みリクエスト数を入力します。
  6. テーブル作成を完了させます。

既存のテーブルまたはインデックスにウォームスループット値を適用する方法については、開発者ガイドを参照してください。

AWS Command Line Interface (AWS CLI) を使用した、ウォームスループット値の設定

aws dynamodb create-table \ 
    --table-name FlashSaleTable \ 
    --attribute-definitions AttributeName=ProductID,AttributeType=S \ 
    --key-schema AttributeName=ProductID,KeyType=HASH \ 
    --billing-mode PAY_PER_REQUEST \ 
    --warm-throughput ReadUnitsPerSecond=50000,WriteUnitsPerSecond=100000
        ...
        "WarmThroughput": {
            "ReadUnitsPerSecond": 50000,
            "WriteUnitsPerSecond": 100000,
            "Status": "UPDATING"
        },
        ...

ベストプラクティス

事前ウォーミングのベストプラクティスは次のとおりです。

  • 正確に見積もる: 過去のトラフィックパターンを分析したり、予測ツールを使用したりして、ピークスループットを正確に見積もります。
  • 重要なテーブルに適用する: 注目度が高く、即時のトラフィックスパイクが予想されるイベントやアプリケーションをサポートするテーブルに焦点を当てます。
  • 必要に応じて調整する: ワークロードの要件に対する理解を深めながら、テーブルの事前ウォーミングを調整します。

ウォームスループット値の監視

DynamoDB テーブルの現在の機能を理解し管理することは、大規模なイベントの前に特に重要です。DescribeTable API を使用すると、オンデマンドモードとプロビジョンドモードのすべてのテーブルで、ウォームスループットの値を監視できます。この呼び出しにより、現在のテーブルのウォームスループット値が提供されるため、大きなトラフィックイベントの前にすべてが適切に設定されているかを確認できます。

aws dynamodb describe-table --table-name FlashSaleTable

     ...
     "WarmThroughput": {
            "ReadUnitsPerSecond": 50000,
            "WriteUnitsPerSecond": 100000,
            "Status": "ACTIVE"
        },
     ...

これらの設定を定期的に確認することで、大規模な処理に対して自信を持って備えることができ、DynamoDB テーブルは常に最高のパフォーマンスを発揮できるようになります。

ウォームスループットの互換性

ウォームスループットは、グローバルセカンダリインデックスやグローバルテーブルなどの DynamoDB の重要な機能と完全に統合されており、システム全体で一貫したパフォーマンスを確保するのに役立ちます。

セカンダリインデックス

グローバルセカンダリインデックス (GSI) の場合、ウォームスループットの値を個別に指定できるため、ワークロードの要件に合わせてパフォーマンスを細かく調整できます。ベーステーブルから GSI への書き込みレプリケーションでボトルネックを回避するには、GSI の WriteUnitsPerSecond をベーステーブルと同等以上の値に設定することをお勧めします。ただし、インデックスのパーティションキーまたはソートキーのいずれか、あるいは両方を頻繁に更新する場合は、書き込み競合を防いで最適なパフォーマンスを実現するために、 WriteUnitsPerSecond をベーステーブルの値の 1.5 倍に増やすことをお勧めします。

次のコード例は、GSI に事前ウォーミングを設定する方法を示しています。

aws dynamodb update-table \ 
--table-name FlashSaleTable \ 
--attribute-definitions AttributeName=GSI1PK,AttributeType=S \ 
--global-secondary-index-updates '[ 
    {
        "Create": {
            "WarmThroughput": {
                "ReadUnitsPerSecond": "12000",
                "WriteUnitsPerSecond": "100000",
            },
            "IndexName": "GSI1",
            "KeySchema": [ 
                {
                    "AttributeName": "GSI1PK",
                    "KeyType": "HASH"
                }
             ],
            "Projection": {
                "ProjectionType": "ALL"
            },
        }
    }
 ]'

グローバルセカンダリインデックスを更新する手順については開発者ガイドを参照してください。

DynamoDB グローバルテーブル

ウォームスループットは DynamoDB Global Tables v2019.11.21 (現行) と完全に互換性があり、一貫したパフォーマンスでグローバルワークロードを効率的に管理できます。レプリカがあるすべての AWS リージョンでテーブルを事前ウォーミングできます。そのため、ユーザーの地理的位置に関係なく、高トラフィックを同時に処理できるようになります。

デフォルトでは、ウォームスループット値を更新するリクエストは、読み取りと書き込みのどちらの操作においても、すべてのレプリカ間で自動的に同期されます。そのため、すべてのリージョンで一貫したパフォーマンスが実現されます。

Infrastructure as Code (IaC)

ウォームスループットの主なメリットの 1 つとして AWS CloudFormation などのインフラストラクチャーコード (IaC) ツールとの統合があります。以前はオンデマンドの DynamoDB テーブルを事前ウォーミングするには、複数のステップが必要でした。テーブルをプロビジョンドモードに切り替え、手動でキャパシティを増やし、一定期間後にオンデマンドモードに戻す必要がありました。この方法で目的は達成できますが、複数回のデプロイと調整が必要でした。

ウォームスループットを使えば IaC を利用した DynamoDB テーブルの管理が大幅に簡単になります。テーブル作成時にウォームスループットの値を渡すことで、テーブルをあらかじめ事前ウォーミングできるようになりました。これにより手動の介入や複雑なワークフローが不要になり、IaC テンプレート内で直接、テーブルのパフォーマンスベースラインを定義できるようになります。

次の CloudFormation テンプレートは、オンデマンド (PAY_PER_REQUEST) モードで FlashSaleTable という名前の DynamoDB テーブルを定義しています。このテーブルには String 型の ProductID という主キーがあります。WarmThroughput は、最初の ReadUnitsPerSecond を 50,000 RCU、WriteUnitsPerSecond を 100,000 WCU に設定しています。

AWSTemplateFormatVersion: 2010-09-09 
 Resources:
  TestTableTemplate:
    Type: 'AWS::DynamoDB::Table'
    Properties:
      TableName: FlashSaleTable 
      BillingMode: PAY_PER_REQUEST 
      AttributeDefinitions:
        - AttributeName: ProductID 
          AttributeType: S 
      KeySchema:
        - AttributeName: ProductID 
          KeyType: HASH 
      WarmThroughput:
        - ReadUnitsPerSecond: 50000 
          WriteUnitsPerSecond: 100000

次のテンプレートでは、eu-west-1 と eu-west-2 リージョンにレプリケートされた、FlashSaleTable という名前の DynamoDB グローバルテーブルを作成します。単一リージョンの例と同様に、WarmThroughput を 50,000 RCU、100,000 WCU に設定しています。

AWSTemplateFormatVersion: 2010-09-09 
 Resources:
  TestTableTemplateGlobal:
    Type: 'AWS::DynamoDB::GlobalTable'
    Properties:
      TableName: FlashSaleTable 
      AttributeDefinitions:
        - AttributeName: ProductID 
          AttributeType: S 
      BillingMode: PAY_PER_REQUEST 
      KeySchema:
        - AttributeName: ProductID 
          KeyType: HASH 
      WarmThroughput:
        ReadUnitsPerSecond: 50000 
        WriteUnitsPerSecond: 100000 
      Replicas:
        - Region: eu-west-1 
        - Region: eu-west-2 
      StreamSpecification:
        StreamViewType: NEW_AND_OLD_IMAGES

ウォームスループットの料金

ウォームスループットの料金は、テーブルが配置されている特定のリージョンでプロビジョニングされた WCU と RCU のコストに基づきます。テーブルを事前ウォーミングする場合、コストは新しい値と現在のテーブルまたはインデックスがサポートしているウォームスループットの差に基づいた 1 回限りの料金として計算されます。

デフォルトでは、オンデマンドテーブルのウォームスループットのベースラインは 4,000 WCU と 12,000 RCU です。新しく作成したオンデマンドテーブルを事前ウォーミングする場合、指定した値とこれらのベースライン値の差分のみが課金されます。

例えば既存のテーブルを 40,000 WCU と 40,000 RCU で事前ウォーミングする場合、テーブルにすでに 10,000 WCU と 12,000 RCU が設定されていれば、追加で必要な 30,000 WCU と 28,000 RCU に対して 1 回限りの課金が発生します。事前ウォーミングでは、テーブルが現在使用しているテーブルクラスやキャパシティモードに関係なく、Standard テーブルクラスのプロビジョンドキャパシティが使用されます。

バージニアリージョン (us-east-1) のコストは次のとおりです。

- $0.00065 per WCU 
- $0.00013 per RCU

計算式:

- 30,000 write units * $0.00065 = $19.50 
- 28,000 read units * $0.00013 = $3.64

合計金額: $23.14

これにより、テーブルはスケーリングの遅延なしに即座に大量のトラフィックを処理できるようになります。また、課金は設定したキャパシティに対してにのみ生じます。コストを適切に管理するには、予想されるスループットの需要を正確に見積もり、それに応じてあらかじめ事前ウォーミングを実施することが重要です。詳細については、DynamoDB 料金ガイドを参照してください。

まとめ

ウォームスループットは DynamoDB テーブルを作成した瞬間から、または既存のテーブルに対して、高トラフィックに備えるために使用できる新機能です。新商品の発売やスーパーボウルなどの大規模なオンラインイベントに備える際、ウォームスループットは信頼性の高い、一貫したパフォーマンスを提供するテーブルの用意を確実に支援します。

ウォームスループットの詳細については HAQM DynamoDB 開発者ガイドを参照してください。

著者について

Lee Hannigan は、アイルランドのドネゴールに拠点を置く Sr. DynamoDB Specialist Solutions Architect です。分散システムに関する豊富な専門知識を持ち、ビッグデータと分析技術の強固な基盤を備えています。Sr. DynamoDB Specialist Solutions Architect として、 DynamoDB の機能を活用したワークロードの設計、評価、最適化を支援することが得意です。