Amazon Web Services ブログ
Amazon Timestream でスケジュールドクエリを使用して、クエリのパフォーマンスを向上させ、コストを削減する
本ブログでは、 Amazon Timestream のスケジュールドクエリを使用してクエリのパフォーマンスを向上させ、コストを削減する方法を紹介します。スケジュールドクエリにより、リアルタイム分析がよりパフォーマンスとコスト効率に優れたものになるため、データからさらなる洞察を引き出し、より良いビジネス上の意思決定を継続的に行うことができます。
Timestream はサーバーレスの時系列データベースであり、幅広い業種のお客様がリアルタイムの洞察を引き出し、重要なビジネスアプリケーションを監視し、ウェブサイトやアプリケーションで何百万ものリアルタイムイベントを分析するために採用しています。これらの多様なワークロードを、クエリアクセスパターンやクエリ同時実行数の要件と合わせて分析することで、Timestream にいくつかの最適化を行い、その結果、異なるワークロード間でクエリレイテンシを最大3倍高速化することができました。
AWS re:Invent 2021 で Timestream は多くのユースケースをより簡単かつ安価に実装するための新しい機能のアップデートを発表しました：
- マルチメジャーレコード – Timestream に複数のメジャー値を書き込めるようになりました。データの書き込みが簡単になり、より多くのユースケースで扱うレコードの数が減る事になります。例えば、同じソースから同じ時間に放出された複数のメトリックを追跡する際にマルチメジャーレコードを使用出来ます。また、リレーショナルデータベースから Timestream へのデータ移行を考える際に、マルチメジャーレコードであればスキーマの変更が多くの場合不要となる為、Timestream へのデータ移行が簡単になるというメリットもあります。
- マグネティックストレージへの書き込み – Timestream はデータのライフサイクルを直近データのメモリストアと履歴データのマグネティックストアという 2 つのストレージ階層で管理しています。メモリストアからマグネティックストアへのデータの移動は設定したポリシーに応じて自動的に実施されます。以前はデータはメモリストアにしかロード出来ず、遅れて到着するデータを格納する為には、メモリストアの保持時間を拡張して対応する必要がありました。今回、直接マグネティックストアに書き込む事が出来るようになり、ストレージコストを削減する事が出来ます。
- スケジュールドクエリ – ダッシュボードやレポートを作成する際、ソースとなるテーブルに直接クエリを実行する代わりに、スケジュールされたクエリを実行して別テーブルに結果を格納する事が出来るようになりました。例えば、大規模なデータから頻繁に集約や合計の為のクエリを実行している場合、これらの結果を別テーブルに格納して、待ち時間とコストの削減が可能となります。
以下のセクションでは、Timestream でスケジュールされたクエリを作成し、直接クエリとパフォーマンスを比較する方法を示していきます。
ソリューションの概要
頻繁に処理されるデータセットに対してクエリを繰り返すと、集計処理と結果の生成に計算リソースが使われるため、コストがかかります。このメカニズムにはいくつかのステップがあります。
スケジュールドクエリでは、入力データに対して集計、ロールアップ、その他のリアルタイム分析を行うクエリを定義するだけです。Timestream はこれらのクエリを定期的かつ自動的に実行し、その結果を設定可能な指定されたテーブルに確実に書き込みます。そして、ダッシュボード、レポート、アプリケーション、モニタリングシステムに対して、時系列データが入ってくる非常に大きなソーステーブルにクエリするのではなく、スケジュールドクエリで設定されたテーブル(宛先テーブル)をクエリするように指示することができます。これにより、パフォーマンスを向上させながら、コストを1桁削減することができます。宛先テーブルは、ソーステーブルよりもはるかに少ないデータしか含まないため、データへのアクセスや保存がより高速かつ低コストで行えます。
宛先テーブルのデータ量はソーステーブルよりもはるかに少ないため、ソーステーブルのストレージコストの数分の一で、宛先テーブルに長期間データを保存できます。また、ソーステーブルのデータ保持期間を短くすることで、支払いコストをさらに最適化することもできます。従って、スケジュールドクエリは、時系列分析をより高速に、よりコスト効率よく、より多くの顧客がアクセスできるようにし、より良いデータ駆動型のビジネス上の意思決定を継続的に行えるようにします。
このブログを実例で示すために、気象データを収集するサンプルデータセットを作成し、スケジュールされたクエリを使用して集計クエリを作成します。
スキーマとデータセット
次のスクリーンショットは、IoTセンサーデータテーブルのスキーマを示しています。
15秒ごとに湿度と温度を収集するサンプルのIoTセンサーデータセットをロードしました。テーブルには 3,754,312 レコードが書き込まれています。次の表はデータの例です。
| country | city | state | gpio | time | temperature | humidity |
| US | Jersey City | NJ | 17 | 2023-03-07 00:30:00.000000000 | 77.67058823529413 | 37.372549019607845 |
| US | Jersey City | NJ | 22 | 2023-03-07 00:30:00.000000000 | 77.0 | 35.254901960784316 |
| US | Jersey City | NJ | 17 | 2023-03-07 00:15:00.000000000 | 78.421052631579 | 38.50877192982456 |
| US | Jersey City | NJ | 22 | 2023-03-07 00:15:00.000000000 | 77.0 | 35.59649122807018 |
| US | Jersey City | NJ | 22 | 2023-03-07 00:00:00.000000000 | 77.0 | 36.206896551724135 |
| US | Jersey City | NJ | 17 | 2023-03-07 00:00:00.000000000 | 78.80000000000008 | 39.0 |
| US | Jersey City | NJ | 17 | 2023-03-06 23:45:00.000000000 | 78.80000000000008 | 39.29824561403509 |
| US | Jersey City | NJ | 22 | 2023-03-06 23:45:00.000000000 | 77.0 | 36.91228070175438 |
| US | Jersey City | NJ | 22 | 2023-03-06 23:30:00.000000000 | 77.0 | 37.91228070175438 |
| US | Jersey City | NJ | 17 | 2023-03-06 23:30:00.000000000 | 78.80000000000008 | 39.85964912280702 |
前提条件
以下の前提条件が必要です。
- スケジュールされたクエリの出力を格納する空のテーブルを作成します。スケジュールされたクエリを作成する際にこのテーブルを参照します。
- Amazon Simple Storage Service ( Amazon S3 )バケットに、クエリ実行エラーログを保存します。
- Amazon Simple Notification Service ( Amazon SNS )トピックで、クエリ実行状況に関する通知アップデートを送信します。
- ソーステーブルと宛先テーブル、および通知を送信する SNS トピックへの権限を持つ AWS Identity and Access Management ( IAM )ロールを用意します。
- データ全体を暗号化するために AWS Key Management Service ( AWS KMS )キーを使用します。
*追加で発生するコストは、クエリ実行コストと追加ストレージコスト(集計結果データ)です。
集計クエリの作成
スケジュールされたクエリの使い方を示すために、まず、都市別、月別、年別の平均気温と湿度を計算する単純な集約クエリを作成します：
SELECT city
, AVG (temperature) AS avg_temp
, AVG (humidity) AS avg_humidity
, cast(month(time) as VARCHAR) AS month
, cast(year(time) as VARCHAR) AS year
, from_iso8601_timestamp('2022-01-01T00:00:00') AS time
FROM "IoTHome"."sensordata"
WHERE measure_name ='weather'
GROUP BY city, month(time), year(time)
ORDER BY city, year, month
次のスクリーンショットは出力を示しています。
次のセクションでは、Timestream でスケジュールされたクエリを作成し、実行する手順を示します。
スケジュールされたクエリの作成
スケジュールされたクエリを作成するには、以下の手順を実行します：
- Timestream コンソールのナビゲーションペイン( Management Tools の下)の Scheduled queries を選択します。
- Create scheduled query を選択します。
- Destination Table のところで、ドロップダウンから Database name と Table name (前提条件として作成したクエリ出力テーブル)を選択します。
- Query Name のところにクエリの名前を入力します。
- Next を選択します。
- Query statement のところで集計クエリを入力し、 Validate を選択します。
クエリが正常に検証されると、宛先テーブルのスキーマが設定されます。お客様は、提案されたスキーマで進めるか、ユースケースに基づいて変更を加えるか選択できます。 - Next を選択します。
- Run schedule では、クエリを実行するスケジュール間隔を指定します。このブログでは、クエリを6時間ごとに実行したいと思います。
- Security settings では、 IAM ロールと KMS キーを指定します。
- SNS notifications では、SNS トピックを指定します。
- Error report logging には、S3 バケットを入力します。
- Next を選択します。
- 設定を確認し、 Create を選択します。
これで、 Scheduled queries ページにクエリがリスト表示されるようになります。クエリがスケジュール通りに実行されると、Last run time 列の情報が更新されます。
以下のスクリーンショットは、スキャンされたバイト数、実行時間、返された合計行数などのクエリのメトリクスの詳細を示しています。
クエリパフォーマンスメトリクス
以下の表は、 Timestream でスケジュールドクエリを使用することで得られるパフォーマンスの利点を示しています。スケジュールされたクエリは、同じクエリを直接実行した場合と比較して、スキャンされた総バイト数だけでなく、期間においてもパフォーマンスの向上を示しています。
| Query Type | Total Bytes Scanned | Duration (Cold Start) | Duration |
| Direct Query | 177.57 MB | 3.622 seconds | 2.264 seconds |
| Scheduled Query | 627.00 B | 0.2510 seconds | 0.1520 seconds |
スケジュールされたクエリのパフォーマンスは14倍向上しました。これは小さな例ですが、データ規模が大きくなると、スキャンするデータが大幅に減るため、大幅なコスト削減を実現できます。実際の金額は、データ規模やクエリーによって異なります。
また、同じデータセットに対してクエリを実行するユーザーやレポートの数も考慮する必要があります。これにより、パフォーマンスが大幅に向上し、コスト削減も可能になります。
まとめ
本ブログでは、Timestream のスケジュールドクエリがクエリのパフォーマンス向上とコスト削減にどのように役立つかを紹介しました。Timestream スケジュールドクエリの詳細やその他の例については、ドキュメントを参照してください。
翻訳はソリューションアーキテクトの宮﨑が担当しました。原文はこちらです。