AQプロジェクト入門（３）DesignSpark Air Quality Dashboardの紹介

この記事ではエアークオリティープロジェクトのセンサーデータストレージと可視化プラットフォーム”DesignSpark Metrics”を紹介していきます。このクラウドプラットフォームは、ストレージ用としてPrometheus時系列データベースを、分析と可視化としてGrafanaを元に構築されています。

クラウドプラットフォームの活用による強力な時系列データベースと分析ソリューション

Prometheus（プロメテウス）

Prometheus（プロメテウス）は時系列データベースです。ここに書き込まれたデータは時系列として一連の値として保存します。

Prometheusでは「メトリック名」と「１つ以上のラベル」の一意な組み合わせで識別される「シリーズ（series）」という単位でデータを特定・操作します。例えば“temperature（温度）”というメトリック名を持つ2つの系列がある場合でも、一方は“indoor（屋内）”もう一方は“outdoor（屋外）”というラベルを持つことでデータを判別できます。これにより、“indoortemp”や”outdoortemp”のようなグローバルで一意なメトリック名を考える必要はなく、データ書き込み時にメトリックを分離して興味のあるデータのみを返すクエリを構築することができるのです。

Prometheus Query Language（クエリ言語）はメトリック名と１つ以上のラベルによるデータ選択に加えて、選択範囲、サブクエリ、関数、演算子などもサポートしています。今回のプロジェクトでは可視化のために別プラットフォームのGrafanaウェブアプリケーションを使用しますが、これはPrometheusデータソースとのシームレスな連携性を持っています！

データを書き込む

Prometheusは単なる受動的なデータベースではなくプルモデルを採用しており、通常時はHTTP経由でメトリックを取得（スクレイピング）するように設定されています。この機能は特にメトリックを収集し、一箇所に保存するためにポーリングできる多くの既存のWebベースシステムがある場合のようなITインフラストラクチャに有用です。あるいは、独自のセンサーシステムを利用し、かつAPIが公開されておらずファームウェアの変更ができないけれど、取得できるウェブインターフェースがあるような場合にも有用です。

Prometheusリモートライトのプロトコルバッファの定義の一部（一例）

今回の場合、Prometheusはホスティングサービスなのでインターネット経由で接続してファイアウォールの内側にあるデバイスからメトリックを取得するのは不便です。そこでPrometheusが提供しているリモート書き込みメカニズムを使用します。このメカニズムでもHTTPを使用するのですが、今回はProtocol Buffersのバイナリ書き込み形式（ワイヤフォーマット）をベースにししています。エアークオリティープロジェクトでは、対応フォーマットをエアークオリティーデバイスアプリケーションが担当してESDKセンサーを読み込みPrometheusエンドポイントが設定されていれば、読み取ったデータをシリアル化したメッセージにパッケージ化してクラウドPrometheusに書き込まれます。

もう一つの選択肢はGrafana Agentを使用することです。 これはPrometheusの縮小版的なもので、LAN上でホストされているアプリケーションからメトリックを取得し、それらをリモートのPrometheusインスタンスに書き込むように設定することができます。これは今後の記事で紹介する予定ですが、ウェブインターフェースを伴うサードパーティセンサーからデータを収集したい場合に便利です。

紹介したエアークオリティーデバイスアプリケーションでも、Grafana Agentでもリモート書き込みメカニズムを利用するには、どちらもリモートのPrometheusインスタンスIDとAPIキーが必要です。

Grafana（グラファナ）

Grafanaは強力な分析・可視化ができるWebアプリケーションで、そのオープンソース版は他の様々なDesignSparkのプロジェクト、記事で使用されています。しかし、今回のDesignSpark Metricsの一部として提供されているホストバージョンはフルマネージドサービスであり、頻繁に更新されバックアップされていきます。

上図は、簡素なGrafanaの可視化で3つの異なる場所のESDKハードウェアによって生成された温度、湿度、TVOC、CO2の時系列データが折れ線グラフによって示されたものです。図からわかるようにGrafanaの可視化機能は非常にシンプルでわかりやすいものとなっています。

ここで温度の折れ線グラフの編集画面を開いてみると、Prometheusデータソースが使用されていることが分かります。上図の例ではプロットされた最初の系列（A）はfriendlyname='abackhome'の温度であることが分かります。一方、2番目の系列（B）はfriendlyname = ‘milnetowers’で温度を選択しており、3番目の系列（C）も同様に一意なfriendlynameが設定されていることが分かります。

さらに便利な機能として、Grafanaにはメトリックブラウザがあります。これを有効にしてポイント＆クリックでクエリを構成できるため、すべてのメトリック名とラベル名のリストを手動で管理する必要はありません。

もちろんデータの可視化は単純な折れ線グラフだけでなく、もっと面白い方法で表示することもできます。例えば上図のように大規模な統計値＋スパークラインなどです。ここでは右側にある他の可視化オプションも使用できます。

エアークオリティープロジェクト

データモデル

エアークオリティープロジェクトではさらに以下のPrometheusラベルが使用されています：

• hwid：ハードウェアのシリアル番号
• geohash：緯度・経度を簡略化したもの
• sensor： センサーの種類とハードウェアのバージョン

hwidはESDKハードウェアを一意に識別するために使用され、ユーザーが設定したfriendlynameだけを判定材料とした場合に発生しうる名前の競合を回避するのに役立ちます。geohashは経度と緯度を符号化するための便利なラベルです。例えば大気質の“ヒートマップ”を作成するために、データをエリアごとにグループ化する際にとても重要になります。sensorラベルは使用したセンサーの種類を判別するものです。センサーの種類を判別できることは結果を解釈する上で重要であり、複数のセンサーからのデータを組み合わせて補正をかけることでさらに精度を向上できます。

プライバシー

DesignSpark Metricsプラットフォームはエアークオリティープロジェクトなどのアクティブエンジニアの活動の先駆けに向けての公開ダッシュボードのみならず、個人利用向けのダッシュボードをホストすることができる予定です。後者についてはどのようなデータが保存され、どのように処理され、誰がアクセスできるかなどの詳細が公開ダッシュボードに投稿するためのサインアッププロセスの一部として明確化されます。

— Andrew Back