Amazon Web Services ブログ

Amazon DynamoDBにおけるコスト最適化に向けたリザーブドキャパシティの算出方法

本記事は、VMwareのデータサイエンティストであるSanjna Srivatsaとの共同執筆です。
Amazon DynamoDBは、リザーブドキャパシティと呼ばれる最小限の使用レベルの支払いを約束する顧客に対して、最大50%から70%程度の割引を提供します。この記事では、過去のDynamoDBが使用したデータを使用して、DynamoDBリザーブドキャパシティを予測する方法について学びます。

FinOpsの実践者(およびデータサイエンティスト)として、私はVMwareを支えるクラウドテクノロジーへの支出を最適化することに重点を置いています。VMwareでは、DynamoDBでかなりの量のプロビジョニング容量を使用していましたが、情報に基づいたリザーブドキャパシティの購入を行うための正しい方法を見つけるのに苦労しました。ツールやチュートリアルがなかったため、私は独自の方法を開発し、皆様にも共有したいと思います。

DynamoDBのキャパシティと課金モード

まず、DynamoDBのキャパシティと課金モードの違いを理解することが重要です。DynamoDBでは、テーブルの読み書き容量を管理するために、オンデマンドとプロビジョニングという2つのモードがあります。オンデマンドモードは、ワークロードの変化に自動的に対応し、読み書きのリクエストごとに課金されます。プロビジョニングモードでは、テーブルが1秒間にサポートできる読み取りと書き込みの数を指定する必要があり、1時間あたりの読み取りと書き込みの回数に対して請求が行われます。プロビジョニングモードは、同等のオンデマンドモードよりも安価で、予測可能なトラフィックを持つワークロードに適した選択です。

プロビジョニングされた書き込み容量は、書き込み容量単位(WCU)でプロビジョニングされます。各WCUは、1秒間に最大1KBのサイズを書き込む能力を提供します。テーブルに毎秒100KBを書き込む必要がある場合、少なくとも100個のWCUをプロビジョニングすることになります。プロビジョニングされた読み取り容量は、読み取り容量ユニット(RCU)単位でプロビジョニングされます。各RCUは、1秒間に4KBまでのサイズの強力な整合性のある読み込みを1回、または1秒間に8KBまでのサイズの読み取りを行うため、最終的に結果整合性のある読み込みを2回実行する機能を提供します。1秒間に400KBの強い一貫性のあるデータを読み込む必要がある場合、少なくとも100RCUまたは50RCUの最終的な一貫性のある読み取りのプロビジョニングを行うことになります。

DynamoDBのリザーブドキャパシティ

DynamoDBでは、プロビジョンドキャパシティモードに対してリザーブドキャパシティを購入するオプションがあります(リザーブドキャパシティに対してオンデマンドは現在サポートされていません)。1年または3年のコミットメントで、リザーブドキャパシティはプロビジョニングキャパシティのコストに対して大幅な割引を提供します。ただし、3年コミットメントは一部のAWSリージョンでのみ利用可能です。
リザーブドキャパシティを購入する場合、以下のように指定します。

  • リザーブドキャパシティが適用されるリージョン
  • 読み込みまたは書き込み容量(RCUまたはWCU)
  • 容量単位(リザーブドキャパシティは100個単位で購入します)
  • 期間(1年または3年)

リザーブドキャパシティ割引は、指定されたリージョンのすべてのWCUとRCUに、購入された容量ユニット数を上限として適用されます。コストを最小限に抑えるため、まずお客様の使用量と購入されたリザーブドキャパシティが比較されます。毎時間、使用容量が購入したリザーブドキャパシティの合計以下である場合、すべての容量がリザーブドキャパシティ料金で課金されます。超過したスループットは、標準の提供容量料金で請求されます。例えば、100WCUを購入し、実際の使用量が100WCU以下である場合、リザーブドキャパシティ料金が課金されます。リザーブドキャパシティを超える容量(この例では100WCU以上)をプロビジョニングした場合は、標準のプロビジョニング容量料金で請求されます。

AWS Organizationsを使用し、連結請求で複数のアカウントをリンクしている場合、支払者アカウントレベルまたはリンクされたアカウントレベルのいずれかで購入したリザーブドキャパシティユニットは、支払者アカウントに接続されたすべてのアカウントで共有されます。リザーブドキャパシティは、まず購入したアカウントに適用され、その後、未使用の容量が他のリンク先のアカウントに適用されます。また、グローバルテーブルのレプリケート書き込みキャパシティーユニット (rWCU)では、現在、リザーブドキャパシティは利用できません。また、DynamoDB Standard-IAテーブルクラスやオンデマンドキャパシティモードを使用しているテーブルでは、現在、リザーブドキャパシティは使用できません。次にリザーブドキャパシティ購入の計算方法について説明します。

どれだけのリザーブドキャパシティを購入するか算出する

AWS Cost and Usage Report (CUR)は、AWSのコストを複数の観点で分析した詳細レポートです。CUR は、選択したAmazon Simple Storage Service (Amazon S3)のバケットに配信するようスケジュールすることができます。CURを有効にしていない場合は、「コストと使用状況レポートの作成」を参照してください。
先に進む前に、少し立ち止まって、アプリケーションの季節性について考えてみることが重要です。データが1年を通して季節性を持っているのと同じように、データにも日々の季節性があります。トラフィックが最も多いのは朝の時間帯か午後かもしれません。VMwareは、リザーブドキャパシティの購入金額を計算するために、日次データを使用します。しかし、データの日次変動をよりよく理解するために、まずは1時間単位のデータを使用することをお勧めします。さらに、検討するのに適した期間を設定するために、少なくとも30日間を振り返ることが推奨されます。ただし、30日間の振り返りの期間を選択する際には、年間の季節性に留意してください。

次のステップは、データを抽出してグラフ化し、初期リザーブドキャパシティ購入額を求めます。

AWS Cost and Usage Reports(CUR)から関連データを抽出する

Amazon Athena、またはサードパーティのツールやパイプラインでCURにアクセスし、クエリすることができます。Athenaは、標準的なSQLを使用してAmazon S3内のデータを簡単に分析できるインタラクティブなクエリサービスです。Athenaはサーバーレスなので、管理するインフラがなく、実行したクエリに対してのみ支払いが発生します。お好みのツールを選択して以下のクエリを実行すると、最初の購入額を計算するために必要なデータが抽出されます。なお、これらのAthenaクエリを実行するとコストが発生する場合があります(詳細はAthenaの価格ページで確認できます)。

次のクエリは、過去30日間のデータを1時間単位で抽出します。

SELECT
DATE_TRUNC('hour', line_item_usage_start_date) AS line_item_usage_start_date,
    line_item_line_item_type,
    product_group,
    product_region,
    line_item_product_code,
CAST(SUM(reservation_unused_quantity) AS DECIMAL(38,3)) AS reservation_unused_quantity,
CAST(SUM(line_item_usage_amount) AS DECIMAL(38,3)) AS line_item_usage_amount
FROM 
    <table_name>
WHERE 
    line_item_product_code IN ('AmazonDynamoDB')
    AND line_item_line_item_type = 'Usage'
    AND product_group IN ('DDB-ReadUnits', 'DDB-WriteUnits')
    AND line_item_usage_start_date BETWEEN DATE_ADD('day', -30, CURRENT_DATE) AND CURRENT_DATE
GROUP BY 1,2,3,4,5
ORDER BY 1,2,3;

CURファイルの<table_name>をAthenaテーブル名に置き換える必要があります。
CURのクエリについて詳しくは、Amazon Athenaを使用したコストと使用レポートのクエリを参照してください。

最適なリザーブドキャパシティユニットを探す

データを抽出したら、次はAmazon QuickSightなど、お好みのデータ分析ツールに取り込みます。データ量によっては、Microsoft Excelのような表計算ソフトを分析ツールとして使用することも可能です。データをインポートしたら、データを正しくグラフ化できるように、正しいデータ型で列をフォーマットすることが重要です。例えば、日付の列は日付データ型に設定する必要があります。

最後に、使用パターンを可視化する必要があります。使用量の傾向や変動がわかるようにデータを可視化するのがベストです。プロビジョニング容量の使用量が増えているのか減っているのか、使用量が時間ごとに変化しているのかなどを把握することができます。これを行うには、任意のデータ可視化ツールを使用することができます。前述のように、データのサイズによっては、Excelを使用することができます。以下は、データを視覚化するための推奨事項です。

  • リージョン別にデータをフィルタリングする(リージョンによって料金が異なるため)
  • グラフの種類:線
  • X軸:line_item_usage_start_date
  • 粒度:時間単位
  • Y軸:line_item_usage_amount(平均値)
  • リピートバイ:product_region
  • カラー:product_group

DynamoDBを複数のリージョンで使用している場合は、リージョンごとのリザーブドキャパシティ購入額を算出する必要があります。以下の図1のようなグラフが完成します。

図1:1時間あたりの読み込みおよび書き込み量を示すサンプルグラフ

line_item_usage_amountカラムは、1秒あたりの使用量を記録します。使用量を1時間単位で正規化するには、このカラムを3,600 (秒) で割る必要があります。可視化する前に正規化を行いたい場合があります。前述のグラフは、1時間ごとの粒度でシミュレーションされたデータを使用しています。リージョンごとに別のグラフを作成することができます。先のグラフでは、いくつかの時間帯で使用量が急増するため、リザーブドキャパシティの購入量を適宜調整する必要があることに注意してください。これは、予約を購入する前に時間ごとの使用パターンを理解することの重要性を示しています。数時間の間に読み取り/書き込み単位が大きく急増すると、日次の平均値が歪むことがあります。このため、日次や月次の粒度では、すべての人の使用パターンに対応した購入推奨値を導き出すことは難しいかもしれません。

DynamoDBのリザーブドキャパシティ購入を初めて行う方は、プロセスに慣れるために小さく始めて、反復して購入することをお勧めします。上のグラフを例にとると、リージョンに安定した利用があるため、最初の購入は最低利用量(Y軸)の50%程度、この場合は110,000WCUと28,000RCUとすることができます。繰り返しますが、リージョンごとのリザーブドキャパシティ購入を決定するためには、各リージョンについてこれと同じ分析を行う必要があります。

リザーブドキャパシティの購入

最後のステップは、グラフ化されたデータでリザーブドキャパシティ購入を行うことです。これを行うには、AWS Management ConsoleのDynamoDB Reserved capacityのページに移動する必要があります。正しいリージョンにいることを確認することが重要です。読み取り、書き込みのどちらの容量単位を購入するか、期間を選択し、金額をフォームに入力します。入力した金額は、1時間あたりのコミットメントであることを忘れないでください。フォームに入力したら、「リザーブドキャパシティーの購入」を選択します。

まとめ

本記事で紹介したプロセスにより、各リージョンで購入すべきリザーブドキャパシティユニットの安全な数を導き出すことができます。定期的に本記事で紹介したグラフを作成し、使用状況に変化がないかどうかを把握し、それに応じて今後の購入量を見直すことをお勧めします。

著者について 

Sanjna Srivatsaは、VMwareのパブリッククラウドの最適化を専門とするCloud Business Office (CBO)のデータサイエンティストです。データサイエンスを用いて複雑なFinOpsの問題を解決することに興味がある。
Kevin Willisは、Amazon DynamoDBチームのプロダクトマネージャーです。現在、製品のプログラマビリティ領域を担当している。
Sahil Thaparは、AWSプリンシパルソリューションアーキテクトです。ISVのお客様を担当し、AWSクラウド上で高可用性、拡張性、耐障害性の高いアプリケーションの構築を支援しています。現在は、コンテナや機械学習ソリューションに注力している。
 

本記事は 2023/03/06に投稿された Calculate Amazon DynamoDB reserved capacity recommendations to optimize costs を翻訳した記事です。翻訳はデータベーススペシャリストソリューションアーキテクトの木村 達也が行いました。