IoT機器で温湿度を測定してクラウドでグラフ化 Elasticsearch設定編（その4）
コンテンツ
温湿度推移のグラフ化
RaspberryPi Zeroと温湿度モジュール（DHT22）を使用して温湿度を指定した間隔（分）で測定してクラウド（AWS IoT Core）にデータをアップロードしてグラフ化するまでの４回目。
過去記事は以下の通り。
今回の記事の範囲はElasticsearch Serviceの設定とする。
システム概要図
システム概要図と今回の記事の範囲は以下の通り。
主な実現したい機能は以下の通り。
- 指定した間隔（分）で温湿度を測定する
- 指定した間隔（分）でデータをサーバーにアップロードする
- アップロードしたデータは集計、グラフ表示する
- 温湿度のしきい値（上限、下限）を超えた場合はアラートを発信する
- しきい値は場所毎に異なる値を指定出来るようにする
- 設定情報はGoogle Sheetで一括指定して設定値を変更したら各端末に速やかに反映させる
- それぞれの端末は遠隔で再起動等の操作が出来るようにする
- 測定端末は複数台設置するが基本的に室内とする（屋外には設置しない）
- １００V電源を確保できる場所とする（バッテリー駆動も一応試してみる）
- 初期コスト、ランニングコストともに出来るだけローコストで実現する
Amazon Elasticsearch Service
Elasticsearch Serviceとは
Elasticsearch Serviceはリアルタイム（最小５秒間隔）でのモニタリングや分析ができるサービスでAWSに組み込まれてAmazon Elasticsearch Serviceとして提供されている。
同じ様に分析ができてグラフィカルな表示ができるAWSのサービスにQuick SightもあるのだがQuick Sightはリアルタイムでのデータの表示に不向き（スタンダードだと１日に１回）なのでほぼリアルタイムで温湿度を表示することが出来るElasticsearch Serviceを選択した。
またAWS IoT CoreからJSON形式のデータをElasticsearch Serviceに送信できる。
kibanaはElasticsearch Service上のデータをヴィジュアル化してダッシュボードに表示するオープンソースのツール。
ログ分析やリアルタイムのアプリケーションモニタリングが得意なので温湿度の推移をグラフ表示するのに適しているのではないかと思い選択した。
kibanaの方はライセンス料は発生しないがAWS Elastcsearch Serviceの方は選択するインスタンスタイプによって料金が異なる。
詳細はこちらの料金表を確認してもらいたいが最小のt2.micro.elasticsearch（１vCPU、１GiBメモリ）の場合、１ヶ月立ち上げっぱなしで東京リージョンだと約２０ドル、料金の安い米国東部（バージニア州）リージョンだと約１３ドルだった。
それほどレスポンスタイムが要求されるようなアプリケーションで無いのであれば米国東部リージョンでも良いのかも知れない。
ドメインの作成
AWSのメニューからElasticsearch Serviceをクリックする。
Amazon Elastcsearch Serviceが表示されるので「新しいドメインの作成」ボタンをクリックする。
デプロイタイプの選択
デプロイタイプは今回は１台のラズパイゼロで試すだけなので”開発およびテスト”を選択した。
ここで”本番稼働用”を選択すると次画面のインスタンスタイプのデフォルト値やノードの数などが違ってくる。
バージョンは7.4（最新バージョン）を選択して「次へ」ボタンをクリックする。
ドメインの設定
- Elasticsearch ドメイン名：temp-and-himu-ess
- インスタンスタイプ：t2.small
- ノードの数：１
を選択した。
データノードストレージはデフォルト値のまま変更していない。
専用マスターノードの有効化は未チェック。
※本番環境ではマスターノードを３つ割り当てることを推奨とあった
一番下までスクロールして「次へ」をクリックする。
アクセスとセキュリティ
ネットワーク構成は”パブリックアクセス”を選択した。
”VPCアクセス（推奨）”を選択するとVPC、サブネット、セキュリティグループを指定することになる。
当初VPCでパブリックなサブネット（IGWが指定されたサブネット）を指定してセキュリティグループでポートを透過させればローカルPCからもElastcsearch Serviceにアクセスできると思っていたのだがどうにも接続できなかった。
そもそもElastcsearch ServiceのIPv4は定期的に変更されてしまうらしい。
色々と調べてみると、ALB（Application Load Balancer）を使う方法やEC2（Elastic Compute Cloud）でリバースプロキシ立てる方法などがある事が分かったのだが、今回はVPCを使わずパブリックアクセスにして後述のアクセスポリシーでIP Addressでフィルタリングをかけることにした。
リバースプロキシの方法は別途試してみたいと思う。
”Amazon Cognito認証を有効化”は非チェック（これをチェックすればkibanaにログイン認証を付けられる）
ドメインアクセスポリシーは”カスタムアクセスポリシー”を選択して、IPv4で自分のローカルPCからのIP Addressを指定した。
- 暗号化：ドメインへのすべてのトラフィックに HTTPS を要求するにチェック
「次へ」ボタンをクリックする。
確認画面
確認画面が表示されるので一番下までスクロールして「確認」ボタンをクリックする。
※ボタン名は”確認”だが”作成”の間違いだと思う。
ドメインのステータスが”読込中”が１０分ほど続いた後、”アクティブ”になるので、KibanaのURLをクリックしてみる。
Kibanaの初期画面が表示されればElastcsearch Serviceの設定は終了。
IoT Core ACTルール
ルールの作成
続いてAWS IoT CoreのACTにルールの作成を行い、温湿度の通常データがIoT CoreにPublish（Edge端末からAWS IoT Coreへのデータの送信）された際に先ほど作成したElastcsearch Serviceにデータ送信するように設定を行う。
IoT Coreのメニューより”ACT”、”ルール”、「作成」ボタンをクリックする。
名前と説明
- 名前：to_temp_elasticsearch
- 説明：to Elasticsearch Service Temperature and Humidity（日本語が入力できない）
を設定する。
ルールクエリステートメント
ルールクエリステートメントにはTOPICの抽出条件を指定する。
通常データ（温湿度情報）の抽出を行いたいので以下のselect文を指定する。
SELECT * FROM 'dt/TempAndHumi/#'「アクションの追加」ボタンをクリックする。
アクションの追加
”Amazon Elasticsearch Serviceにメッセージを送信する”を選択して「アクションの設定」ボタンをクリックする。
アクションの設定
ドメイン名で先程作成したtemp-and-humi-essをプルダウンメニューから選択する。
- ID：${newuuid()}
- 索引：temp-app-${parse_time(“yyyyMMdd”, timestamp(), “Asia/Tokyo”)}
- タイプ：TempHumiData（テーブル名に相当する）
を入力して「ロールの作成」ボタンをクリックする。
索引に日付情報を含ませることによりElastcsearch Service上では１日毎に異なるインデックスファイルが作成される。
Kibanaでは複数のインデックスをまとめて扱うことができるのと、データが溜まってきた時に日付指定でインデックスを削除できるので色々と都合が良い。
つまりElasticsearch Serviceには３日分のインデックスのみを残す、のような運用も可能になる。
- 名前：IoTCoreToElasticsearchTempHumi
を設定して「ロールの作成」ボタンをクリックする。
先程の画面に戻って新規に作成されたポリシーをアタッチしてロールが選択されているので「アクションの追加」ボタンをクリックする。
ルールの作成
アクションが追加された。
エラーアクションはElastcsearch Serviceへのメッセージの送信が失敗した時に設定する。
今回は未設定で「ルールの作成」ボタンをクリックする。
ルールの有効化
ルールが作成されるので右端の”・・・”を選択して「有効化」をクリックすると有効化される。
続く
以上でElasticsearch Serviceの設定に関する記事は終了する。
次回はラズパイゼロ上のPythonのプログラムの記事とする。
最近のコメント