この投稿はタスデザイングループ 代表取締役 甲田 将史氏から株式会社アイ・グリッド・ソリューションズの AWS IoT Greengrass V2 、 Amazon Timestream 、 Amazon SageMaker を利用した再生可能エネルギープラットフォームの構築の取り組みについて寄稿頂いたものです。

 Amazon Timestream の Scheduled Query を利用したコスト削減

【寄稿】株式会社アイ・グリッド・ラボの太陽光 PPA 事業から蓄電池・ EV サービスまでの幅広い GX ソリューションでの Amazon Timestream 活用 (Part1)  に引き続き、アイグリッドのR.E.A.L. New Energy Platform®を構成するAWSサービス の中からAmazon Timestream を取り上げます。ここからは、Amazon Timestream運用する中でのコスト低減に向けた取り組みをご紹介したいと思います。

AWS で構築したシステムを運用する際、多くの方が日々コストを気にしていると思います。本プラットフォームにおいても、 Amazon Timestream のコスト増減の特性が把握しきれていなかったため注視して運用していましたが、 2021 年 9 月の商用リリースからプラットフォームを利用するサービスは順調に拡大を続け、 Amazon Timestream のデータ量も増加の一途をたどる中で、すぐにコスト増加が課題になりました。

完全従量課金の Amazon Timestream ですが、書き込む際のデータ量、ストレージに格納されたデータ量（メモリストア、マグネティックストア）、クエリによってスキャンされたデータ量の 3 つが課金対象となります。

集計値の見直しによるクエリ発行回数の削減

コスト増加の要因分析として、まずクエリに対するコストに注目しました。本プラットフォームでは、 Amazon Timestream が Web アプリケーションやバッチシステムからの直接のデータ参照にも十分なパフォーマンスを発揮できることをフィジビリティ・スタディで確認できていたため、本プラットフォームではアプリケーションから Amazon Timestream を参照するアーキテクチャを採用しています。そのため画面やバッチ処理の仕様によっては膨大なデータをスキャンするクエリが発行されており、アプリケーション利用者の増加に伴うスキャン量の増加がコストを押し上げる主要因となっていました。

エッジデバイスから収集する電力使用量等の実績データは全て 1 分値のため、 1 ヶ月分のデータを抽出するだけでも 1 サイト 1 項目（ measure_name ）あたり 43,200 レコード（ 60 分× 24 時間× 30 日）が対象となりますので、対象のサイト数や項目数によってはかなりのデータ量となります。また、サイト分、対象エラー種類分クエリが発行される実装となっていたため、 5 分に 1 回バッチ処理を起動した場合でも、 1 サイト 1 エラー種類の抽出あたり 1 ヶ月間で約 8,784 回（ 12 回 / 時間 × 24 時間 / 日 × 30.5 日）と相当数のクエリが発行されます。電力使用量や太陽光発電量は多くの場合 30 分値や日間値で使用されるため、これに合わせエッジデバイスから収集するデータを事前にデータ集計してアプリケーションで利用することがクエリ回数低減に寄与することは明らかでした。単純計算で 30 分値集計をすれば対象レコード数は 1/30 に、日間値集計をすれば 1/1,440 に、月間値集計では 1/43,920 （月 30.5 日で計算）までに削減されることになります。

また、対象のサイト、エラー毎にクエリを発行する設計としている点にも着目しました。 Amazon Timestream の場合、クエリに対する課金はスキャンされたバイト数に依存するものの、 10MB 未満のクエリは 10MB として計算されますので 1KB のクエリも 10MB のクエリも同料金となります。この料金体系を考慮し、全サイト、全対象エラー種類のデータを 1 回のクエリで取得することでクエリ回数を削減し、大幅にコストを抑えることに成功しました。

このようにして当時リリースされたばかりの Scheduled Query 機能を活用して、まずは 30 分値の集計から着手しました。

 Scheduled Query による集計テーブルのレイアウト設計

エッジデバイスから収集したデータを Amazon Timestream に格納する際、電力使用量 [kWh] 、太陽光発電量 [kWh] といった単に合計して積算値を格納すれば良いものもあれば、気温 [℃] は平均値や最大値（最高気温）、最小値（最低気温）といったように、計測データの種類によって集計方法が異なります。そればかりでなく、エッジデバイスでの計測には欠損値がつきものです。今回の設計では欠損値の補完を独自の計算式で行うために有効時点数を集計テーブルのレイアウトにも追加しています。なお、 Amazon Timestream でも欠損値を補う補完関数が用意されていますが、アプリケーション毎に異なる補完アルゴリズムを利用したかったこと、また補完関数利用時に毎度複数のテーブルに対しクエリを発行する必要があるため、費用対効果が見込めないことから、アプリケーションによる補完を採用しています。

さらにAWS Timestreamではマルチメジャーコードを採用しております。AWSからの例えば同じタイムスタンプで複数の項目（メジャー値）を持たせることができるので、結果的にストレージコストを削減し、クエリスキャンの回数も削減することができます。

以上の集計要件と Scheduled Query の実行コストを勘案して下表のテーブルレイアウトに決定しました。

Scheduled Query に設定したクエリステートメントを以下に示しますが、このような汎用的な集計テーブルにしたことで、 Scheduled Query のメンテナンスコストを最低限に抑えられています。

SELECT
owner,
site,
equipment,
deviceId,
measure_name AS name,
BIN(time,30m) AS time,
AVG(measure_value::double) AS value_avg,
MIN(measure_value::double) AS value_min,
MAX(measure_value::double) AS value_max,
SUM(measure_value::double) AS value_sum,
COUNT(*) AS value_count
FROM オリジナルテーブル名
WHERE
time >= ( date_trunc( 'hour', NOW() ) - parse_duration('30m') ) AND
equipment = 'smartmeter'
GROUP BY
owner,
site,
equipment,
deviceId,
measure_name,
BIN(time,30m)

今後、更なるコスト削減として Scheduled Query の結果テーブル以外でのマルチメジャーコード採用に向けた検討を進めております。エッジデバイスからのデータ取得安定性への影響など、既存の仕組みにどのような影響を与えるかを検証しながら採用可否を判断する予定です。

メモリストア期間の調整

本プラットフォームでは、送配電事業者から小売電気事業者に提供される 30 分電力量を Amazon Timestream で保管しています。この 30 分電力量には速報値、日次確報値、月次確報値と同時刻に複数の種類が存在するため、そのデータ量は膨大です。アプリケーションの処理性能と年次処理への対応を考慮して、当初メモリストアの保持期間を 365days 6hours に設定していたため、メモリストアにかかるコストも大きなものとなっていました。

マグネティックストアを利用することでコスト低減が可能ですが、アプリケーション処理性能へ影響を与えてはいけないため、まずステージング環境を使用してマグネティックストアの性能評価を行いました。本番環境とステージング環境でデータ量も異なるため単純比較はできませんが、マグネティックストアを利用した場合でもサービスの提供に十分耐えうる性能が確保できることを確認できました。

これに加え、各アプリケーションの仕様を精査したところ高いパフォーマンスが要求されるのは 2 週間というデータ期間であることが判明したので、最終的にはメモリストアの保持期間は 15days に設定変更しました。これによってメモリストアでのコストを低減し、前述のクエリ回数削減の効果もあり、コスト面からも Amazon Timestream を安定運用に乗せることができました。書き込みの課金では未だ課題に直面した経験がありませんが、 Amazon Timestream を採用してコスト増加が問題になった際は、本記事で言及してきたように使い方を見直すことでコスト削減が必ず実現できると考えています。これから Amazon Timestream を使われる方々が、コスト面の課題に直面した際に一助になれば幸いです。

AWS for Energy について詳細はこちらをご覧ください。

著者について