Amazon DynamoDB におけるスケジューリングされたプロビジョニングモードのコスト最適化

Amazon DynamoDB は、ハイパフォーマンスなアプリケーションをあらゆる規模で実行するために設計された、フルマネージドでサーバーレスの key-value NoSQL データベースです。DynamoDB テーブル内のデータの読み取りと書き込みの保存に加え、お客様が有効化したオプション機能が課金の対象となります。DynamoDB には「オンデマンド」と「プロビジョニングモード」という 2 種類のキャパシティモードがあり、それぞれのモードでテーブルの読み込みと書き込み処理の請求オプションがあります。

DynamoDB プロビジョニングモードのテーブルのコスト管理では、読み取りと書き込みのキャパシティを設定できます。Application Auto Scaling またはトラフィックのピーク時とオフピーク時を考慮したスケジュールに基づいて設定ができます。

Amazon DynamoDB には自動スケーリング機能があり、 Application Auto Scaling サービスを使用して、実際のトラフィックパターンに応じてプロビジョンドキャパシティを動的に調節します。Application Auto Scaling を使用すると、テーブルまたはグローバルセカンダリインデックスでプロビジョニングされた読み込み、書き込みキャパシティを増やして、トラフィックの急激な増加に対応できます。ワークロードが減少すると、 Application Auto Scaling はスループット性能を調整させ、未使用のプロビジョンドキャパシティに料金が発生しないようにします。

本記事では、Application Auto Scaling とスケジュールに基づき最小スループットに変更しつつも、希望する時間に遅延なく書き込みキャパシティを増やせる、プロビジョニングモードのテーブルコストを最適化する方法を示します。

想定される課題

定期的に変化がある予測可能なワークロードがあります。たとえば、金融取引のプラットフォームです。金融業界では、取引は月曜日の朝に始まり、金曜日の夜に終わります。月曜日に市場が開かれると取引が急に活発になり、閑散な時間はありません。別の例では、盛大なマーケティングプロモーションと同時に行う小売販売があります。販売が始まると、オンラインストアでは注文が急増する可能性があります。

オンデマンドキャパシティモードは予測不可能なワークロードには最適ですが、上記のようなケースでは、「オンデマンド DynamoDB テーブルがスロットルされるのはなぜですか? 」の説明のとおり、30分以内に前回のトラフィックピークの2倍のキャパシティまで増加するとスロットルする可能性があります。

金融業界の例のように周期的に予測可能な高い需要に対して、直ぐに調節が必要なケースにプロビジョニングモードを使用する場合は、最小値が高い読み取りと書き込みキャパシティをAmazon DynamoDB テーブルに設定する必要があります。つまり、週末などトラフィックが少ない時期には、未使用のキャパシティに対して多額の支払いをすることになる可能性があります。Application Auto Scaling では、予測可能なトラフィックの変化に対応するために、プロビジョンドキャパシティを調節するスケーリングポリシーのスケジュールが可能です。キャパシティの値を手動で調節することもできますが、Application Auto Scaling の利用が推奨されます。

解決策の概要

Application Auto Scaling では cron を使用してポリシーをスケジュールできます。複数のスケジュールを作成して、必要に応じてテーブルのキャパシティを変更できます。

AWS CloudFormation テンプレートをダウンロードして実行し、サンプル構成を作ります。オフピークまたはピークのスケジュールが始まるのを待つと、 Amazon DynamoDB の対象テーブルの結果が Amazon CloudWatch メトリックスに表示されます。AWS CloudFormation テンプレートには、スケーリングを実行できる入力として IAM ロールの ARN が必要です。このロールに必要な権限については、「開発者ガイド」を参照してください。

スニペットに示すように、リソースは AWS CloudFormation テンプレートによってに作成されます。

読み込みおよび書き込み共に初期設定されたプロビジョンドキャパシティの Amazon DynamoDB テーブル。
ScalableTarget コマンドを実行して、最小書き込みキャパシティを 90 書き込みキャパシティユニット (WCU) に変更してから、月曜日の午前 8 時 (UTC) にピークスケーリングを開始します。そして、金曜日の午後 6 時 (UTC) に最小書き込みキャパシティが 30 WCU に変更されます。(ユースケースに合わせてスケジュールを変更できます)。

calingTarget:
    Type: AWS::ApplicationAutoScaling::ScalableTarget
    Properties:
    MinCapacity: 30
    MaxCapacity: 90
    ResourceId: !Sub "table/${ CyclicalTable }"
    RoleARN: !Ref DynamoDBAutoscalingRoleArn
    ScalableDimension: dynamodb:table:WriteCapacityUnits
    ServiceNamespace: dynamodb
    ScheduledActions:
      - ScheduledActionName: startWeekday
        #Monday 8AM: UTC<br />Schedule: "cron(0 8 ? * 2 *)"
        ScalableTargetAction:
          MinCapacity: 90
      - ScheduledActionName: startWeekEnd
        #Friday 6pm: UTC
        Schedule: "cron(0 18 ? * 6 *)"
        ScalableTargetAction:
          MinCapacity: 30

WCU に与えるスケジュール変更の影響の例として、図 1 で1 時間ごとの WCU 変更の推移を示しています。 WCU の変更は、テーブルの書き込み量としてすぐに反映されます。

図 1:1 時間ごとに変化する WCU

AWSサンプル構成の削除

今後、課金されないようにするには、AWS CloudFormation テンプレートで作成したリソースを削除してください。 AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して AWS CloudFormation スタックを削除することで、すべてのリソースを削除できます。詳細については、「AWS CloudFormation コンソールでのスタックの削除」を参照してください。

コスト削減の事例

ある金融業界のお客様は、予想されるトラフィックに比例した、プロビジョニングモードを利用することでコストを 25% 削減できました。

まとめ

本記事では、cron 方式の Application Auto Scaling スケジュールを使用して Amazon DynamoDB でプロビジョンドキャパシティをスケールする方法を説明しました。この手法を使用することで、既知で予測可能なトラフィックパターンのワークロードのコストを最適化できます。

作者情報

Jiten Dedhia は、ソフトウェア業界で 20 年以上の経験を持つシニアソリューションアーキテクトです。グローバル金融サービスのお客様を担当して、AWS サービスを利用したモダナイズの支援をしています。

この記事の翻訳はソリューションアーキテクトの梶山政伸が担当しました。原文はこちらです。

Amazon Web Services ブログ