みなさんこんにちは!サーバーワークス IoT担当の中村です。
最近自宅のスマートハウス活動が疎かになっている上、スマートハウスの要になっているMac miniをSierraにしてみたら色々と動かなくなり、OSのUpdateをしたことを後悔しています。でも、macOSからSiriが使えるようになったのは大きいですよね。Siriは音声認識も発音もとてもレベルが高いのでうまくスマートハウスに取り込めないかどうか、色々と考えています。
本題
さて、今日は可視化の話です。AWS IoTでデータを収集して、それを可視化する時、皆さんはどんな手段で可視化を実現していますか?今よく挙がる手法としては、AWS IoT -> Kinesis Firehose -> Amazon Elasticsearch Service(AES)の順にデータを流して、Kibanaで可視化する方法ではないでしょうか。この構成だと全てマネージドサービスにできるため、一度構築してしまえばその後の運用は手がかからず楽ですね。
ここで気になるのがお値段です。AWS IoTとKinesis Firehoseは、データを送った分だけ課金が発生するサービスで、これらに関しては環境が小規模であれば月額数ドル程度で利用することができます。しかし、AESについてはノードにEC2インスタンスを利用している関係上、EC2インスタンスの利用料が発生します。一番小さなインスタンスタイプ(t2.micro.elasticsearch)を選んだとしても月額 $20.16 ($0.028 * 24Hour * 30Day) です。というわけで、今回はこの$20という額を下回る圧倒的な安さで可視化を実現してみます。
使うのはトラブルシューティングに使うアイツ
見出しで若干ネタバレ感ありますが、安く可視化を行うために今回はCloudWatchを使います。
設定手順としてはAWS IoTのRule ActionにCloudWatchにデータを送る機能があるので、それを設定してしまえばおしまいです。後はCloudWatchにデータが溜まっていくため、マネジメントコンソールから確認すれば必然的に折れ線グラフとなるわけです。簡単ですね!
設定してみる
さて、それでは実際にIoTのデータをCloudWatchで可視化できるように設定してみましょう!
今回やること
今回はAWS IoTにPublishしたデータをAWS IoTのRuleの機能を使ってCloudWatchに貯めます。そして、CloudWatchで可視化されている様子を確認します。手順は以下のような流れで進みます。
- AWS IoTのRuleを設定する
- 15分ほど待つ
- 可視化する
- ダッシュボードも作ってみる
なお、サンプルデータとしては、社内で実際に使っている温湿度センサーの値を使います。実際に送っているJSONはこのような感じです。
{ "devicePlace": "Concentration Area", "temperature": 25.9, "humidity": 53.1, "pressure": 1018 }
1. AWS IoTのRuleを設定する
まずはAWS IoTのRuleを作成します。そしてRuleのActionにはCloudWatch metricsを選択します。CloudWatchのActionは2つあるので間違えないように気をつけて下さい。
Actionの設定はこのような感じに設定します。各項目についての説明は以下の通りです。
- Metric name: メトリクス名。ここではセンサーの位置を記載しています。(${devicePlace}/temperature)
- Metric namespace: メトリクスを集約する名前空間。ここではAmbientとしています。
- Unit: 数値の単位。ここでは単位は無し(None)にしています
- Value: 数値。ここでは温度(${temperature})を設定しています。
- Timestamp: タイムスタンプです。ISO8601形式の表記である必要があり、UnixTimestampは使えません。省略すると現在時刻になります
- Role name: CloudWatchにデータを貯めるためのIAM Roleです。Rule作成画面から「Create a new role」をクリックしてさくっと作れます
今回利用しているセンサーは湿度(humidity)と気圧(pressure)も取得できるので、同様に2つRuleを追加します。ひとつのRuleに計3つのActionが追加されました。
※少し脱線してCloudWatchの話
CloudWatchのデータの分類は、Metric Namespace、Metrics、Dimensionの3つがあります。
Metric Namespaceはメトリクスを集約する名前空間で、例えば「EC2」や「RDS」といった分類です。
Metricsとはいわゆる監視項目のことで、例えば「CPUUtilization」や「DiskReadOps」等の分類です。
Dimensionとは、データ元を一意に特定できるもので、リソース名やリソースIdになります。 CloudWatchのデータの分類についてはAWSより公開されている資料のP12にわかりやすく説明されています。CloudWatchの3つの分類を正しく使うならば、Metric namespaceにAmbient、Metricsにはtemperature, humidity, pressure、DimensionにはdevicePlaceを設定したい所ですが、AWS IoTのRuleのActionではDimensionの項目は今のところ設定できないようです。今回Metric nameの欄の設定を ${devicePlace}/temperature としているのは、Dimensionの項目を設定することができないため、Metirc nameに両方含めてしまおうという意図です。
2. 15分程待つ
AWS IoTのRuleの設定ができたら、15分程正座して待ちます。これは、CloudWatchに新規メトリクスが表示されるまでに最大15分程かかるためです。また、既存メトリクスにデータを送る場合にも、最大二分ほど遅れが発生します。以下のドキュメントに記載があります。
http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/publishingMetrics.html
put-metric-data コマンドで新しいメトリックスを作成した場合、get-metric-statistics コマンドを用いてその新規メトリックスの統計を取得できるようになるまで最大 2 分かかります。ただし、list-metrics コマンドを用いて取得したメトリックスのリストに新規メトリックスが表示されるまで最大 15 分かかることがあります。
3. いざ可視化!
15分ほど待ったら、CloudWatchを確認してみましょう。カスタムメトリクスから先程設定したメトリクスが見えるようになっているはずです。 実際にCloudWatchを確認すると、以下のようになっています。まず、左下のカスタムメトリクスのセレクトボックスから先程設定したMetirc Namespaceを選択すると、メトリクス名が一覧で表示されます。そして、メトリクス一覧から任意のメトリクスにチェックを入れることでデータの可視化を行うことができます。チェックは複数入れることができるため、スクリーンショットのように、3箇所の湿度の遷移についてひとつのグラフで確認できます。
4. ダッシュボードも作れる
CloudWatchは実はダッシュボードを作成することもできます。先程の画面で、「ダッシュボードに追加」ボタンをクリックすると、今表示しているグラフをダッシュボードに追加することができます。ここでは、temperature, humidity, pressure毎のグラフを作成し、それぞれダッシュボードに貼ってみました。もちろんダッシュボードでは各グラフの位置や大きさ等を調整することができます。 というわけで、CloudWatchだけでKibanaもびっくりな可視化を実現することができました。料金
さて、肝心の料金ですが、CloudWatchの課金体系は以下のようになっています。- 1カスタムメトリクスあたり 月額$0.5
- リクエスト1000件あたり $0.01
- 1ダッシュボードあたり 月額$3
- 9カスタムメトリクス(3つのセンサー*3種類の値): 月額$4.5 (9metrics * $0.5)
- 129,000リクエスト: 月額$1.29 (129,000requests / 1000 requests * $0.01)
- 1ダッシュボード: 月額$3
CloudWatchにおける注意点
さて、CloudWatchの良い点ばかり上げてきましたが、ここからはIoTのデータをCloudWatchで可視化する上での注意点をいくつかご紹介します。データの間隔は最小1分
下記のドキュメントの通りです。そのため、ミリ秒レベルで値を送信するもの、値が変化するものを可視化したい場合にはCloudWatchは向いていません。粒度が 1 秒の 1,000 分の 1 のタイムスタンプでデータポイントをパブリッシュできますが、CloudWatch は、データを最小粒度の 1 分に集約します。CloudWatch は 1 分の期間ごとに受け取った値の平均(すべての項目の合計を項目数で割った値)と、同じ期間内のサンプル数、最大値、最小値を記録します。たとえば、前の例の PageViewCount メトリックスには、3 つのデータポイントで、数秒違いのタイムスタンプがあります。3 つのデータポイントはタイムスタンプがすべて 1 分の期間内にあるため、CloudWatch はそれらを集約します。
2週間経つと消える
残念ながらCloudWatchの仕様で、2週間が過ぎたデータから順に削除されるようになっています。なお、CloudWatchのデータを2週間以上残したい!というあなたはこちらの記事を御覧ください。
【そんなときどうする?】CloudWatchのデータを2週間以上残したい!
設定できる単位に縛りがある
AWS IoTのActionでCloudWatchにデータを投入するとき、Unitという項目でデータの単位を設定することができます。しかし、実はこのUnitに設定出来る値は予め決まっていて、温度計だからUnitはDegreeにしよう、とはできません。Unitに設定出来る値は以下の通りです。- Seconds
- Microseconds
- Milliseconds
- Bytes
- Kilobytes
- Megabytes
- Gigabytes
- Terabytes
- Bits
- Kilobits
- Megabits
- Gigabits
- Terabits
- Percent
- Count
- Bytes/Second
- Kilobytes/Second
- Megabytes/Second
- Gigabytes/Second
- Terabytes/Second
- Bits/Second
- Kilobits/Second
- Megabits/Second
- Gigabits/Second
- Terabits/Second
- Count/Second
- None
The parameter MetricData.member.1.Unit must be a value in the set [ Seconds, Microseconds, Milliseconds, Bytes, Kilobytes, Megabytes, Gigabytes, Terabytes, Bits, Kilobits, Megabits, Gigabits, Terabits, Percent, Count, Bytes/Second, Kilobytes/Second, Megabytes/Second, Gigabytes/Second, Terabytes/Second, Bits/Second, Kilobits/Second, Megabits/Second, Gigabits/Second, Terabits/Second, Count/Second, None ].
The parameter MetricData.member.1.Timestamp must specify a time within the past two weeks.
実はそんなに安くない
ここに来てタイトルと矛盾している事を書くのですが、実はそんなに安くないんです。もちろん今回のケースのように小規模なデータを可視化する場合は無料枠に収まりますし、無料枠を無視したとしても月額$8程度の課金となります。ただし、リクエストやメトリクスが増える毎に料金もリニアに増えていきますので、ある程度の規模からはAESやEC2等のインスタンスを1つ用意してしまったほうが料金は安くなります。具体的には、40メトリクスを超えるとメトリクスの料金が$20となるため、AESのミニマムの料金と並びます。
まとめ
今回は小規模のIoTのデータを圧倒的に安く可視化する手法として、CloudWatchで可視化する方法を紹介しました。CloudWatchには色々と制約がありますが、小規模なIoTのデータを安く可視化する方法としては候補のひとつになるかと思います。また、インスタンス等を用意せずに簡単にダッシュボード作成まで行えたり、容量を気にせずデータをどんどん投げ込めるところもCloudWatchの良いところです。ただし、AWSサービスは適材適所が大事です。各サービスごとに向き不向きがありますので、実際に可視化を行う際は規模や用途等を考慮した上で最適なAWSサービスを選択しましょう。どのサービスを使えばいいかわからない!という方は是非弊社までお問い合わせ下さい。