Amazon Web Services ブログ

時系列データの効率的な管理の為の Amazon Timestream Compute Unit (TCU) の理解と最適化

Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレスの時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析できます。様々な業界のお客様が Amazon Timestream を採用して、重要なビジネスアプリケーションを監視し、モノのインターネット (IoT) を含むアプリケーション、ウェブサイト、デバイスにわたる数百万のリアルタイムイベントを分析し、リアルタイムの洞察を導き出しています。 Timestream は、基盤となるインフラストラクチャの管理が不要で、ワークロードの要求に合わせて自動的に拡張するため、お客様はアプリケーション開発に集中する事が出来ます。

Amazon Timestream for LiveAnalytics は、お客様からのフィードバックに応える形で、時系列データをクエリ時にコスト効率が高く、金額が予測可能となるように設計された新しい価格モデルを導入しました。以前のクエリの価格モデルは、スキャンされるデータ量に基づいて課金され、クエリ毎に最低 10 MB でしたが、クエリが数 KB 程度の比較的小さい時系列データをスキャンすることが多いユースケースでは、高額となる場合がありました。さらに、クエリへの課金に上限を設定することも困難でした。これらの懸念に対処するために、クエリによってスキャンされたデータ量ではなく、使用されたコンピューティングリソースに基づいて料金を請求する新しい料金モデルを導入しました。Timestream Computing Unit (TCUs) に基づくこの新しい価格モデルにより、実際に使用されるリソースに応じてコストが調整され、クエリに使用するコンピューティングリソースの最大数を設定できるため、予算の順守が容易になります。

本投稿では、TCU の概要、TCU を使用したコスト管理、および最適なコストパフォーマンスを実現するためのワークロードに必要な TCU を見積もる方法について説明します。

Timestream Compute Units (TCU)

TCU は、Timestream for LiveAnalytics のクエリに割り当てられるコンピューティングの容量です。各 TCU は 4 つの vCPU と 16 GB のメモリで構成されます。時系列データをクエリすると、Timestream サービスは主にクエリ (リアルタイムクエリと分析クエリ) の複雑さと、処理されるデータ量に基づき、必要な TCU の数を決定します。各コンピューティングユニットは同時に複数のクエリを実行するため、使用中の TCU で全クエリを処理できるかどうか、または追加のコンピューティングユニットが必要かどうかを評価し、必要に応じて、コンピューティングユニットを拡張します。TCU の数とその使用期間によって関連コストが決まり、クエリワークロードの管理が透過的かつコスト効率よく行われます。

コスト管理

TCU の利点の 1 つは、クエリコストを制御し、より効率的に管理できることです。 MaxQueryTCU は、AWS リージョン毎、アカウント毎に設定できますが、この設定をすることで、Timestream はクエリワークロードに対してMaxQueryTCU までスケールされるように制限することができます。 TCU の最大制限を設定することで、ワークロードのコスト上限を設定できるため、予算内に収める事が容易になります。

コンピューティングユニットの最大数は 4 の倍数に設定できます。料金は、使用したコンピューティングリソースに対してのみ発生します。つまり、最大 TCU を 128 に設定しても、一貫して 8 TCU のみを使用する場合は、 8 つの TCU を使用した課金のみが発生します。従量課金制の料金設定と使用制限の構成により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。Timestream を初めて利用する場合、各 AWS アカウントのデフォルトの MaxQueryTCU 制限は 200 になります。

MaxQueryTCU の設定は UpdateAccountSettings API を使用するか、AWS マネジメントコンソールから行います。また、TCU を事前に見積もる方法については、本投稿の後半で詳しく説明します。

  1. Timestream コンソールの管理者ダッシュボードで、管理者設定を設定を選択します。
  2. 最大クエリ TCU に希望の値を設定し、設定を保存します。

  1. 現在、使用中のアカウントがクエリによってスキャンされたデータ量に対して請求が行われており、TCU にオプトインするか選択できる場合は、追加のポップアップが表示されます。

尚、最大クエリ TCU を削減する際、使用状況によっては有効になるまでに最大 24 時間かかる場合があります。また、クエリが実際に消費した TCU に対してのみ料金が請求される為、最大クエリ TCU 制限を高くしても、それらの TCU がワークロードで使用されない限り、コストには影響しません。

TCU による請求

TCU を使用すると、最低 30 秒間、使用したコンピューティングリソースに対して 1 秒毎に料金が請求されます。これらのコンピューティングユニットの使用単位は TCU 時間です。アプリケーションが Timestream にクエリを送信すると、Timestream サービスは使用中のコンピューティングユニットでリクエストを処理できるかどうかを確認します。処理出来ない場合、サービスはスケールアップして、クエリを処理するために追加のコンピューティングユニットを割り当てます。クエリの実行後、サービスは追加のクエリを最大 10 秒間待機します。この期間内に追加のクエリがない場合は、使用中のコンピューティングユニットの数をスケールダウンして、リソースを最適化し、コストを最小限に抑えます。

実際の例を使って説明しましょう。まず、アプリケーションに 1 分のうち 40 秒の間、レイテンシが 1 秒未満のクエリを含むクエリパターンがあると仮定します。アプリケーションは、1 分の開始時刻 t1 秒から t40 秒にクエリを Timestream に送信します。

コンピューティングユニットには、最低 30 秒ごとに料金が請求されます。Timestream サービスは、最小時間(30 秒)が経過し、最大 10 秒間クエリがない場合に、コンピューティング ユニットをスケールダウンします。サービスが t1 でクエリ用に 4 つの TCU を割り当て、後続のすべてのクエリが同じ 4 つの TCU で処理されると想定します。 4 つの TCU 使用量のうち 50 秒 (=0.0138889 TCU 時間)、即ち、4 * 0.01388 TCU 時間 = 0.05552 TCU 時間に対して請求されます。このパターンが 1 日 8 時間、毎分 (t1 ～ t60) 繰り返されると仮定すると、消費される合計 TCU 時間は、1 日あたり 0.05552 TCU 時間 * 60 分 * 8 時間 = 26.6496 TCU 時間となります。 TCU 時間を取得したら、目的のリージョンごとのクエリ料金を確認する事で料金を計算できます。

請求をより深く理解するために、さらにいくつかの例を見てみましょう。

  • ワークロードが 3 時間で 20 個の TCU を使用する場合、 60 TCU 時間 (20 TCU x 3 時間) に対して請求されます。
  • ワークロードが 30 分間に 12 TCU を使用し、次の 30 分間に 20 TCU を使用します。この場合、16 TCU 時間に対して請求されます (12 TCU x 0.5 時間 + 20 TCU x 0.5 時間)。

TCU の推定

Timestream for LiveAnalytics は、容量とパフォーマンスを調整するために自動的にスケーリングされるため、基盤となるインフラストラクチャの管理や容量のプロビジョニングは必要ありません。データの取り込み、ストレージ、クエリを独立して拡張できる完全に分離されたアーキテクチャを特徴としており、アプリケーションのニーズに合わせて事実上無限の拡張性を提供できます。

必要なコンピューティングユニットの数は、クエリの同時実行性、データモデル、クエリによってスキャンされるデータ量などのワークロードの特性によって決まります。処理可能なクエリの数を見積もるために、Timestream for LiveAnalytics でデータが収集および分析され、Grafana を通じて視覚化されるインフラストラクチャ監視のユースケースをシミュレートしました。現実世界のシナリオと同様に、複数のユーザーがメトリクスを監視する 2 つの一般的な可観測性クエリパターンをシミュレートし、ユーザーを 1 から 21 に増やしました。次に、MaxQueryTCU 設定 (4 および 8) を変更して、ユーザーの増加に応じて処理されるクエリの量とそれに対応する待ち時間を監視しました。

ホストの最新のメモリ使用率 (lastpoint-query.ipynb) を取得するパターン、及び、過去 10 分間の CPU 使用率をビニングする (single-groupby-orderby.ipynb) クエリパターンについて、4 および 8 TCU でクエリボリュームとレイテンシーメトリクスを測定しました。

これらのワークロードでは、サービスにクエリを発行する 1 人のユーザーから開始し、同時ユーザーの数を 21 人までスケールします。テストは、ユーザー構成毎に 1 分間実行され、対応するレイテンシー (p50、p90、p99)、 1 分あたりのクエリ数、およびスロットリング数 (もしあれば) が観察されます。詳細については、README.md を参照してください。

最初のシミュレーションでは、MaxQueryTCU を 4 に設定し、次のクエリを実行します。これにより、特定のホストの最新のメモリ使用率が取得されます。

select memory 
from "devops"."sample_devops" 
where time > ago(10m) and hostname='host1' 
order by time desc limit 1

次のグラフは、レイテンシーのパーセンタイル (秒)、1 分あたりのクエリ数、およびスロットリング数とユーザー数の関係を示しています。

最初は 1 人のユーザーから始めて、時系列データにアクセスするユーザーの数を増やし続けます。わずか 4 つの TCU で、Timestream サービスは 1 分あたり 4,560 件のクエリ、つまり 1 秒あたり約 76 クエリ (QPS) を処理し、p99 レイテンシーは 160 ミリ秒未満でした。 Grafana ユーザーの数が増えると、レイテンシーが増加し、それによって 1 分あたりのクエリ数が減少しますが、スロットリングは最小限に抑えられました。これは、デフォルトの SDK の最大再試行数が 3 (ベストプラクティス) に設定されており、SDK はスロットリングが発生する前にクエリをリトライするためです。クエリのレイテンシには再試行時間が含まれるため、同時ユーザー数が 7 名 (76 QPS) を超えると、主に複数のリトライが原因で p99 レイテンシーが増加していることがわかります。ユースケースで 1 秒未満のクエリ遅延が許容できる場合は、4 つの TCU で最大 9 人の同時ユーザーと 1 分あたり 4,853 件のクエリをサポート出来る事が分かりました。

次に、MaxQueryTCU を 8 に増やしてテストを再実行します。Timestream サービスはオンデマンドでコンピューティング ユニットを割り当てるため、サービスは 4 TCU から開始され、ワークロードが増加するにつれて追加の 4 TCU を割り当てます。次のグラフは、8 TCU のメトリクスを示しています。

8 TCU の場合、200 ミリ秒未満の p99 レイテンシーで 9,556 件のクエリ (約 159 QPS) を処理可能でした。Grafana ユーザーの数が増えると、レイテンシーが増加し (330 ミリ秒未満)、そのため 1 分あたりのクエリ数がわずかに減少しますが、スロットリングは発生しませんでした。つまり、500 ミリ秒未満のクエリ遅延がユースケースで許容できる場合は、 8 つの TCU で最大 15 人の同時ユーザーと 1 分あたり 9,556 のクエリをサポート出来る事が分かりました。

MaxQueryTCU は最大 1,000 まで増やすことができるため、ユーザーベースの拡大に合わせて拡張できます。許容できるコストに応じて、MaxQueryTCU を増やし続けることも、遅延がユースケースとして許容できる場合には、既存の TCU を使用して追加のユーザーにもサービスを提供することもできます。

次に、以下のクエリ 2 でシミュレーションを繰り返します。これは、ビン分割、グループ化、並べ替えを実行しますが、クエリ 1 と比べるとリソースを大量に消費するクエリです。

select bin(time, 1m) AS binned_time, 
max(cpu_utilization) as max_cpu_utilization 
from "devops"."sample_devops" 
where time > ago(10m) and hostname='host2' 
group by bin(time, 1m) 
order by binned_time asc

次のグラフは、クエリ 2 に対応するメトリクスを示しています。

前のテストと同様に、1 人のユーザーから始めて、データにアクセスするユーザーの数を増やしていきます。4 つの TCU で、180 ミリ秒の p99 レイテンシーで 6 人の同時ユーザーに対して 3,310 件のクエリ(約 55 QPS)を処理出来ました。 Grafana ユーザーの数が増加すると、主に再試行によるオーバーヘッドが原因で 1 分あたりのクエリが減少し、レイテンシーも増加します。

次のグラフは、8 つの TCU の際のメトリクスを示しています。

8 つの TCU を使用すると、500 ミリ秒未満の p99 レイテンシーで 15 人の同時ユーザーに対して 6,051 (約 100 QPS) 件のクエリをサポートできます。

必要なパフォーマンスに必要な TCU を使用できますが、少ない TCU から始めて、希望のパフォーマンス基準を満たすか、価格とパフォーマンスの適切なバランスが見つかるまで、アカウント内の MaxQueryTCU を増やすアプローチがあります。

尚、Timestream のスケジュールクエリ機能は、集計およびロールアップ操作をサポートするように設計されており、パフォーマンスを向上させるために派生テーブル (データがすでに集計されており、データ量が削減されている) からダッシュボードや視覚化用のデータを生成するのに最適です。詳細については、「Improve query performance and reduce cost using scheduled queries in Amazon Timestream」を参照してください。

シミュレーションで実証されたように、4 つの TCU は 76 QPS (月間 1 億 9,900 万クエリに相当) および 55 QPS (月間 1 億 4,300 万クエリに相当) のクエリ量をサポート可能でしたが、クエリの複雑さに依存する為、シミュレーションで示されているよりも多くなる可能性があります。また、TCU はクエリ数ではなくコンピューティング使用時間に基づいて課金されるため、76 QPS と 55 QPS の費用は変わりません。クエリの同時実行の利点を最大限に高めるには、データモデル、クエリ、ワークロードを最適化してコンピューティングリソースを効果的に利用することが不可欠です。これにより、コストが削減され、クエリのスループットが向上し、リソースの使用率が向上します。

AWS Pricing Calculator を使用したコストの見積もり

AWS Pricing Calculator を使用して、Timestream for LiveAnalytics の月額コストを見積もることができます。このセクションでは、リアルタイムクエリと分析クエリとみなされるものについての一般的なガイダンスを提供します。

  • リアルタイムクエリ – 小さなウィンドウ (5 分や 15 分などの数分) 内でメジャーを分析するクエリ、または通常は数百のレコードをスキャンするクエリ。
  • 分析クエリ – 大きな時間範囲 (12 時間、日、月等) にわたってメジャーを分析するクエリ。複雑な結合やサブクエリが含まれる場合があり、通常は数千のレコードをスキャンします。これらのクエリでは、パフォーマンスを向上させるためにデータの集約とセグメント化に高いコンピューティング (CPU/メモリ) が必要です。

これは一般的なガイダンスです。小さなウィンドウ内で補間、導出、またはその他の複雑な関数を要求するような、リアルタイムクエリとして認められない可能性のあるコストのかかるクエリが存在する可能性があります。

わかりやすくするために、料金計算では、1 秒あたり 7 つの同時クエリが 4 つの TCU で 1 秒のレイテンシーで処理されると想定しています。我々の実験では、160 ミリ秒未満の p99 レイテンシーで 72 QPS を達成しました。料金計算ツールは、指定された時間単位 (秒、分、時間、日、月あたり) にわたって均等に分散されるクエリの数を分割します。場合によっては、クエリが 30 秒を超えて実行されない場合 (アイドル期間を含む)、その 1 分全体に対して料金が請求されるわけではありませんが、この Calculator では考慮されないため、実際の合計額はさらに小さくなる可能性があります。クエリのワークロードをよりよく理解している場合は、本投稿の前半で共有した例に基づいて、さらに正確なコストを計算できます。

TCU の監視

TCU の使用状況を効果的に監視するために、Timestream for Live Analytics は Amazon CloudWatch メトリクス QueryTCU を提供します。このメトリクスは、1 分間に使用されるコンピューティングユニットの数を測定し、1 分ごとに更新されます。このメトリクスを使用すると、1 分間に使用された最大および最小の TCU を追跡でき、コンピューティングの使用状況を把握できます。さらに、このメトリクスにアラームを設定して、コンピューティング使用量が特定の閾値を超えたときにリアルタイム通知を受け取ることができ、使用量を最適化し、クエリコストを削減できます。

次のグラフは、過去 3 時間に使用された QueryTCU の最大値を示しています。

最大 TCU は価格の計算には直接役立ちませんが、最大/最小 TCU がどの程度になるかに関して洞察を与える事が出来ます。正確な TCU 時間は、AWS Cost Management コンソールを開いて Cost Explorer を開始し、Timestream for LiveAnalytics でフィルターする事で確認できます。

2024 年 4 月 29 日以降に初めて Timestream for LiveAnalytics を使用する全ての AWS アカウントは、クエリ料金設定にデフォルトで TCU を使用するようになります。 2024 年 4 月 29 日より前にサービスを利用していた場合は、「コスト管理」セクションで説明されているように、API を通じて TCU へのオプトインを行うか、AWS Timestream コンソールで変更出来ます。 TCU ベースの価格設定に移行すると、コスト管理が改善され、クエリごとに計測される最小バイト数が無くなります。 TCU ベースの価格設定モデルへのオプトインはオプションであり、元に戻すことのできない変更です。つまり、クエリ価格設定に TCU を使用するように AWS アカウントを移行した場合、クエリ価格設定にスキャンされたバイト数を使用するように戻す事はできません。

結論

この投稿では、TCU、請求、コスト見積もりについて説明し、4 および 8 TCU 構成でのクエリワークロードのシミュレーションを実証しました。リソースを効果的に利用すれば、コストを増加させることなくワークロードを拡張できます。従量制の料金体系と TCU 使用量の最大値の設定により、高度なコストの透明性と予測可能性が提供され、クエリのコストをより適切に計画および管理できるようになります。詳細については、次のリソースを参照してください。

今すぐ Timestream for LiveAnalytics の利用頂き、多くのメリットを享受することをお勧めします。さらに詳しく知りたい場合は、通常の AWS サポート連絡先に問い合わせるか、Amazon Timestream の AWS re:Post に質問を投稿してください。

翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文はこちらをご覧下さい。