この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
概要
こんにちは、yoshimです。
本企画は、弊社チームIoTメンバーが初心に返ってIoTサービスについて学びなおし、解説してみようというものです。
本エントリーでは、IoTデータの収集・変換・活用までサポートしてくれる「AWS IoT Analytics」について紹介します。
目次
1.はじめに
IoTで実現したいこととして、「現場の見える化」、「現場のデータを用いた分析」、「異常検知」等が挙げられます。
そして、これらを実現するためにはIoTデータを適切に収集・加工・保存・分析・可視化できるようにしておく必要があります。
今回紹介する「AWS IoT Analytics」はこれらのプロセスを強力にサポートしてくれるフルマネージドサービスです。
参照: AWS IoT Analytics とは
以降、各フェーズに沿って「AWS IoT Analytics」が提供する機能について確認していきますが、その前に簡単に「AWS IoT Analytics」で出てくる基本的な用語をまとめます。
| 役割 | 知っておきたいこと | |
|---|---|---|
| Channel | - データの入口 | - 処理前の生データがS3に格納される - channelにデータを投入する方法は2パターンある |
| Pipeline | - Channelに投入されたデータを処理してDatastoreに格納 | - 1つのChannel、1つのDatastoreに接続する。 - 処理内容を変更した際に「期間を指定」して再処理することができる（←便利！） |
| Datastore | - pipelineの処理結果 | - S3にファイルとして格納される - 複数のPipelineから1つのDatastoreに接続可能 - 1つのDatasotreから複数のDatasetが作成できる |
| Dataset | - Datastoreのデータに処理を加えたもの - 「SQLデータセット」と「コンテナデータセット」の2パターンある - 定期処理するようにスケジューリングも可能 |
-「SQLデータセット」では、指定したSQLに基づいてDatasetを更新する - 「SQLデータセット」にはサポートされていない式 がある - 「SQLデータセット」のクエリ結果をS3、もしくはIoT Eventsに送信可能 - 「コンテナデータセット」では任意の処理を実行可能 |
2.収集
まずは「channel」にデータを投入することでデータを収集します。
「channel」に投入されたデータは、「AWSが管理するS3バケット」、もしくは「我々が自分で管理するS3バケット」のいずれかで管理できます。
どちらの場合でも料金に違いはありません。
2.未加工データ: Amazon S3 に保存され、標準の S3 の料金で課金されます
また、channelにデータを投入する方法は「AWS IoT rule actions」か「BatchPutMessageAPIでPUTする」の2パターンあります。
それぞれ、メリットデメリットを整理すると下記のようになります。
「BatchPutMessageAPIでPUTする」場合は、「IoT AnalyticsのGreengrassコネクタ」がインストールされているデバイス、もしくはLambdaから実行するケースが多そうです。
| メリット | デメリット | 使い所 | |
|---|---|---|---|
| AWS IoT rule actions | IoT Coreを介しているので、同じデータを他のサービスにも展開しやすい | 「AWS IoT Rule Action」を実行する分コストがかかる | 他のAWSサービスにもIoTデータを連携したい時 |
BatchPutMessageAPI |
「AWS IoT Rule Action」が不要な分、コストが低い | 同じデータを他のサービスに展開しにくい | とりあえずデータを貯められれば良い時 |
ちなみに、AWS管理コンソール上でchannelにどれだけメッセージがきたかを確認できます。
3.加工
channelに投入されたデータはpipelineでニアリアルタイムに処理されます。
pipelineについては下記2点の特徴を頭に入れておきましょう。
| 特徴 | 詳細 |
|---|---|
| 多様な処理手法 | - 「不要なデータをフィルタリング」、「アトリビュートの値に基づいて計算したアトリビュートを追加」等の基本的な計算が可能 - IoT Coreからデバイス情報（シャドー、レジストリ情報）を取得可能 - Lambda関数を起動して外部データを利用可能 |
| 再集計が簡単 | - channelに保存されているデータの期間を指定して、再計算が可能 - pipelineの処理内容を変更した時に便利 |
「再集計が簡単」とはありますが、もし処理で「外部データ」等を利用している場合、外部データ依存の問題が発生しうる点に注意してください。
また、「データ処理量」に応じてコストがかかります。
そのため、Pipelineを設計する際には「不要なデータを処理しない」、「重複処理をしない」といった観点が必要になります。
この点については、「7.「AWS IoT Analytics」におけるデータフローの設計について」で少しだけ言及します。
4.保存
pipelineで処理したデータはDatastore(実態としてはS3に処理した時間でパーティショニングされた状態)に保存されます。
「Datastore」に処理を加えた「Dataset」もS3に保存できます。
「Datastore」から「Dataset」を作成する際に、「Datastore」のデータに対してJoin句やWith句が使えない等の制限があるため、Datastoreの設計時には注意してください。
気になるお値段は、通常のS3バケット利用より少しだけ割高でした。
（下記はバージニア北部の料金）
参照: 料金
また、似たようなユースケースで競合となるかもしれない「Amazon Timestream」の料金(マグネティックストア)と比較してみたところ同じ料金でした。
参照: 料金
5.分析
「Datastore」に保存されたデータに対して分析処理を実行します。
また、分析結果でもある「dataset」をS3に配信してGlueにメタデータをエクスポートすることで、既存のデータレイクのデータと結合して利用することも可能です。
API経由でも「dataset」を取得できるので、例えばSageMakerノートブックインスタンス上のJupyternotebookからもdatasetを参照できます。
「AWS IoT Analytics」による分析のアプローチは、「SQLデータセット」と「コンテナデータセット」の２パターンがありますので、それぞれの内容をざっくり見ていきます。
SQLデータセット
「Datastore」に対してSQLを実行し、その結果をS3に出力します。
RDBMSで言うところのマテリアライズドビューをイメージするといいと思います。
SQLデータセットの特徴は下記の通りです。
- スケジュール設定可能
- バージョン管理可能
- 分析結果に再現性を持たせることが可能
- 結果をS3/IoT Eventに配信可能
- IoT Eventsに配信することで、「集計を定期的に実行＆閾値で結果を判断&後続処理を実行」することが可能
コンテナデータセット
カスタムのコンテナイメージを用いて任意の処理ができるので、複雑・高度な処理（ex.機械学習モデルの更新）ができます。
SQLデータセット更新後、もしくは事前に定めたスケジュールにそって実行可能です。
ECRにコンテナイメージを登録して利用します。
6.可視化
DatasetのデータをQuicksightで可視化することが可能です。
（「Dataset」と「QuicksightのSPICE」の更新タイミングを調整することを忘れないように！）
また、コンテナデータセットを定期更新することで、作成したHTMLビューをAWSコンソール画面上から確認することもできます。
参照: 20191030 AWS Black Belt Online Seminar AWS IoT Analytics Deep Dive
7.「AWS IoT Analytics」におけるデータフローの設計について
「AWS IoT Analytics」におけるデータフローの設計についてもう少し知りたい方はDesigning dataflows for multi-schema messages in AWS IoT Analyticsを一読することをお勧めします。
下記にその内容をざっくり整理しておきます。
まず、「AWS IoT Analytics」の各要素技術について、下記3点を頭に入れておく必要があります。
- 1つのChannelは複数のpipelineにメッセージを送信できる
- pipelineは1つのchannel、1つのdatastoreと紐づく
- 1つのDatastoreから複数のdatasetを生成できる。しかし、dataset生成時に複数のDatastoreを参照することはできない
また、「AWS IoT Analytics」においては「pipelineで処理したデータ量に比例してコストがかかる」ため、「同じ処理を重複させたくない」という点も思い出してください。
さて、channel、pipeline、datastoreの関係性として下記の4パターンが考えられます。
(他の関係性は分解することで下記いずれかのパターンで説明できます)
| channel | pipeline | datastore | |
|---|---|---|---|
| Type1 | 1 | 1 | 1 |
| Type2 | N | N | 1 |
| Type3 | 1 | N | N |
| Type4 | 1 | N | 1 |
さて、上記4種類のフローの中で一番シンプルなのは「Type1」です。
もし「Type1」で実現したいことが実現できるのならこの構成が理想でしょう。
参照: Designing dataflows for multi-schema messages in AWS IoT Analytics
ただし、これだと「Inputデータのスキーマが多岐にわたる場合（multi-schema）」に「処理内容が複雑」になる可能性があります。
また、複数あるスキーマのうち「特定のスキーマ」だけ仕様変更となった時に「pipeline」で再計算をするかもしれませんが、その際に「再計算する必要がないデータ」も再計算することになってしまいます。
そのようなInputデータのスキーマが多岐に渡り処理内容が複雑になりそうな時は、下記のようにType2がいいでしょう。
参照: Designing dataflows for multi-schema messages in AWS IoT Analytics
それぞれのchannelに処理対象となるデータのみを投入し、pipelineごとに各スキーマ独特の処理を実行します。
datastoreを1つにしているのは、「dataset生成時に複数のdatastoreを参照することはできない」ためです。
ただし、この構成でdatasetを生成した場合に「datasetをスキャンした際に不要なデータまでスキャンしてしまう（ex.multi-schemaなデータを投入しているものの、特定のschemaのデータのみ必要であった場合）ためコストが高くついてしまう」可能性もあります。
datasetスキャン時のコストを安く抑えるという観点では、Type3も検討の価値があるかもしれません。
参照: Designing dataflows for multi-schema messages in AWS IoT Analytics
しかしType3の構成では、「それぞれのpipelineに同じデータを投入することになるので、処理が重複する」という問題があります。
（データ処理時とデータ利用時、どちらの方がコストへの影響が大きいかを考慮する必要があります）
この問題に対応するには、「channel:pipeline:datastore=N:N:N」というType1を繰り返した構成を取ることが有効です。
(channelを分割することで、pipelineで処理を重複させない)
また、最後にType４の構成を見てみましょう。
この構成は、「1つのメッセージで複数の異なる処理」をしつつ「1つのdatastoreにまとめることで使いやすくしたい」時に有効です。
参照: Designing dataflows for multi-schema messages in AWS IoT Analytics
ただ、これだとそれぞれのpipelineで「重複した処理を実行」してしまうので無駄なコストが発生してしまいます。
これを回避するためには、Type2の構成のようにchannelを複数用意するのがいいでしょう。
各Typeごとのデータフロー設計については以上です。
「IoT Analytics」におけるデータフローのみならず、「Kinesis」との使い分けについて悩んだ方もいらっしゃるのではないでしょうか？
この点については、よくある質問でも言及されていました。
ざっくり言うと、デバイスのメタデータを利用する、長期間のデータを利用する、もしくは複雑なクエリやモデルが必要な場合は「AWS IoT Analytics」を使うと良いとのことです。
Kinesisと「AWS IoT Analytics」を併用するケースについても説明されています。
8.まとめ
長くなりましたが、「AWS IoT Analytics」について概要を整理しました。
「pipeline」の定義を変更しても再計算できるという点が個人的には一番気に入りました。
channel、pipeline、datastoreの設計をしっかりやれればかなり便利そうなので、「これからIoTデータの利活用を推進しよう」と考えている方には是非一度お試しいただきたいサービスです。
21
