⏱️

IoTにおけるAmazon Timestreamの活用

2023/04/30に公開

AWS

IoT

timestream

tech

Amazon Timestreamとは

IoT アプリケーションのセンサーデータ、DevOps ユースケースのメトリクス、クリックストリームデータ分析などのアプリケーションモニタリングシナリオのテレメトリを簡単に保存および分析できます。

どういうソリューションに向いているか

IoT向け、デバイス情報のデータ収集、利用状況を把握
- センサー・ネットワーク監視
- 在庫計画
- 製造・物流の管理
分析アプリケーション向け、サイト滞在時間や離脱ポイントを把握
- クリックストリーム分析
- 商品需要予測
- 企業データ分析
DevOpsアプリケーション向け、サーバー監視や異常値の検知
- 物理システムのモニタリング
- アプリケーションのモニタリング
- ソフトウェアシステムのモニタリング

特徴

低コストで高性能
サーバーレスと自動スケーリング
データライフサイクル管理
簡素化されたデータアクセス
時系列に特化
常に暗号化

ストレージ階層

インメモリストア
- 1時間~最大約1年
- 保持期間に達したデータをマグネティックストアへ移動
マグネティックストア
- 1日~最大200年
- 保持期間に達したデータを削除

機能

スケジュールクエリ
複数のメジャーを 1 つのテーブル⾏に格納(マルチメジャーレコード)
マグネティックストア書き込み
バックアップ
- ストアには保持期限があるため、AWS Backupへデータバックアップとることが可能
バッチロードタスク
- CSV ファイルを使用して、S3からTimestreamにデータをまとめて移行可能

用語

ディメンション(Dimensions)

測定値を識別するための属性情報セット

各テーブルで128個のディメンションが利用可能
全てのディメンションは文字列(varchars)として扱われる
ディメンションはテーブルにデータが取り込まれたとき、動的に
追加される
一度定義されたディメンションは変更不可

メジャー

測定値
名前 (measure_name) と値 (measure_value) のセット
1レコードにつき measure_value は１つ

時系列レコードのタイプ

Single-measure records

テーブル行ごとに 1 つのメジャーを保存。アプリケーションとデバイスが任意の時点で単一のメトリクスのみを生成する場合は、この形式を使用。
1度のリクエストで書き込めるレコードの最大数は 100件まで。

Multi-measure records

複数のメジャーを 1 つのテーブルの行に保存。アプリケーションとデバイスが任意の時点で複数のタイプのメトリクスを生成する場合は、この形式を使用。

料金

※アジアパシフィックリージョンの料金で説明

Timestreamにはデータストアとして、「メモリストア」と「マグネティックストア」の2種類のストレージ階層がある。

書き込み

アプリケーションまたはスケジュールクエリによってテーブルに書き込まれた時系列データの量に基づいて課金されます。各書き込みリクエストは、最も近い KB に丸められます。

メトリクス	料金
1 KB サイズの書き込み 100 万件	0.625USD

クエリ

クエリは、Amazon Timestream のサーバーレス分散クエリエンジンが、お客様のアプリケーションから送信されたクエリや、お客様が設定したスケジュールクエリのデータを計算しながら、スキャンした時系列データの量に基づいて課金され、クエリごとに最小 10 MB となります。

メトリクス	料金
1 GB あたりのスキャン量	0.0125USD

メモリストア

メモリストアの料金は、各 Amazon Timestream テーブルのメモリストアに格納された時系列データの量に基づいて計算されます。

メトリクス	料金
格納された GB 時間あたりの料金	0.045USD

マグネティックストア

マグネティックストアの料金は、各 Amazon Timestream テーブルのマグネティックストアに格納された時系列データの量に基づいて計算されます。

メトリクス	料金
格納された GB 月あたりの料金	0.0375USD

注意事項

インメモリ階層の保持ポリシーは1時間~最大約1年
- 保持期間に達した場合はマグネティックへ移動
マグネティック階層の保持ポリシーは1日~最大200年
- 直接マグネティックへの書き込みは不可。
- 保持期間に達した場合はデータを削除
保持期間は後で変えられる。ただし変えた後のデータに対して適用される。
Dimensions
- 各テーブルで128のディメンションが使えて、全部varcharで扱われる。一度定義されたら変更不可。
Measures
- 各テーブルで1024のメジャーの種類を定義できる。メジャーはテーブルにデータが取り込まれたとき動的に追加される。一度定義したら変更不可。
同じ秒数に送られたレコードは無視される(先勝ち)
- Versionを指定すれば、後勝ち対応も可能。
マルチメジャーレコードのmeasure値は2048byteまで。
時間はUTCのみ
１回のクエリで取得できるデータの最大量は1Mb。そのため大量のデータ取得にはページネーションが必要。
データ補完について
- マルチメジャーレコードの場合、補完関数は使用不可。そのため異常値の場合、データ補完は取得後処理が必要
- もしくは異常値を覗いてクエリするなどして対応。
データ構造について
- メジャーの値にnullは入らない??
- ディメンションの値にnullは入らない??
- 時間はunixtimeでもOK??
- 後からメジャー(属性)を増やすことが可能。後から追加したメジャーの既存データカラムはnull。
- 既存メジャーの型変更は不可。
- 空レコードが入らないので、空はそもそも挿入しないなどで対応。
- 必ず取得可能なディメンションのみ入れてクエリできるようにしておく。
  - jsonのkeyごとない欠損値のようなデータはそもそもディメンションとして定義しないなど

Quotas

Query reference

サポートされている型やSQLサポートの詳しく↓に記載されている。

IoTにおけるアーキテクチャ

ここからIoTソリューションでのAWSアーキテクチャを説明

IoT Core Rule Action

向いているケース
- シングルメジャーレコード書き込み
- シングルメジャーレコードのため料金をマルチメジャーレコードより安く抑えられる
- 小規模でデバイスの稼働率が低い場合で利用

Kinesis Data Stream + Lambda

RuleActionsからLambdaを直接アタッチすることもできるが、大量のMQTTで送られるデータが大量のあるケースはKinesis Data Streamを経由してコンシューマーLambdaからマルチメジャーレコードで書き込みを行う。
これを行うことによって、スループットやデータ量の変化に応じてMQTTデータをTimestreamへバッチ書き込みができる。

向いているケース
- テレメトリーデータを必要な項目だけをTimestreamへ流すことができる
- マルチメジャーレコード書き込み
- 複数デバイスが同時に毎秒テレメトリをAWS IoT Coreへデータ送信してる場合で利用
- デバイス稼働の送信数が見えない場合などで利用
起動間隔
- リアルタイム集計したい場合、最短1秒間隔で起動可能
- Lambdaの起動回数を抑制したい場合、Buffer持たせて1度に複数秒分(例: 20秒など)のデータ挿入を試みる(書き込み回数も減る)

Data Modeling

例

ディメンションはセンサーIDとして設定した場合、毎秒位置情報を送信するセンサーのデータを格納するテーブルの例。

Timestamp	Sensor ID	Latitude	Longitude
2023-04-06T00:00:00	1	35.6895	139.6917
2023-04-06T00:00:01	1	35.6896	139.6918
2023-04-06T00:00:02	1	35.6897	139.6919
2023-04-06T00:00:03	1	35.6898	139.6920
2023-04-06T00:00:04	1	35.6899	139.6921

Timestamp: センサーが位置情報を送信した時刻
Sensor ID: センサーの一意の識別子（ディメンション）
Latitude: 緯度の位置情報
Longitude: 経度の位置情報

このテーブルは、センサーから送信された位置情報を時系列で追跡し、AWS Timestreamを活用してデータを格納・解析する際に使用可能。
センサーIDをディメンションとすることで、複数のセンサーからのデータを効果的に管理・分析することができる。

またサクッとどういった使い方ができるかサンプルデータベースを作成することができ、

上記の添付図のようにマルチメジャーレコードでデータベース名sampleDatabase テーブル名をIoTMultiで作成することができる。

VS DynamoDB

サーバーレスアプリケーション開発のDBには、NoSQLのDynamoDBを使うケースがでてくるが、クエリ速度を重視する場合で活用するのにはDynamoDBを使うのが適している。
時系列のログデータを取り扱うユースケースはTimestreamを使うのがシンプルに設計でき、コストパフォーマンスも良いので設計判断時に候補として適している。

まとめ

時系列の機能要件があればTimestreamをまず使えるか検討材料にいれましょう。

参考サイト

https://youtu.be/kF8Ump0aNss