はじめに
IoTシステムのデータ伝送には、MQTTが一般的に広く採用されています。AWS IoT、Azure IoT Hubなど、主要クラウドプラットフォームでもMQTTブローカーを内蔵したマネージドサービスが提供されており、ここ数年でIoTシステムの構築は劇的に楽になりました。
しかしながら、MQTTで伝送したリアルタイムデータを実際に活用するための 可視化や分析ツール に関しては、現在も様々なサービスが登場し発展の途上にあります。
MQTTデータ可視化ツールの現状と課題
代表的なMQTTデータの可視化ツールとして、以下のようなものが挙げられます。
これらのツールにはそれぞれ特徴がありますが、高頻度なセンサーデータ（数百～数千Hz）のリアルタイム表示には十分に対応できず、パフォーマンスに問題が生じるものも多くあります。また、センサーデータに動画や音声といったマルチモーダルデータを統合的かつ同期的に扱うことは難しく、多くのツールでは同期再生ができません。
高頻度マルチモーダルデータの可視化を実現するintdash/Visual M2M
当社は、高頻度でリアルタイム性を求められるIoTデータの伝送と可視化に特化したintdash（伝送ブローカー）およびVisual M2M（可視化ダッシュボードツール）を自社開発しています。intdashとVisual M2Mは、以下のような特徴を持ちます。
- ハイパフォーマンス : 数千Hzを超える超高頻度データでもスムーズに描画
- マルチモーダル : センサー値に加え、動画や音声なども統合的に同期再生
本記事では、可視化ダッシュボードツールであるVisual M2Mを用いて、MQTTで伝送された高頻度リアルタイムデータを、ハイパフォーマンスに可視化する方法についてご紹介します。
従来Visual M2M（可視化ダッシュボード）を利用するにはバックエンドの伝送基盤としてintdash（伝送ブローカー）を導入し、送信デバイス側もintdashへの対応が必要でしたが、既存のMQTT環境からもintdashの高性能な可視化環境を利用してみたいとのお声をいただき、このたび、後段でご紹介する「MQTT-intdashリレープログラム」を実験的に開発しました。本記事ではこのリレープログラムを用いたMQTTとVisual M2Mの連携方法をご紹介します。
本プロジェクトは現在 Experimental なステータスにあり製品化を模索している状況ですが、ご要望をいただければ本番システムにて稼働できる品質のソフトウェアをご提供可能です。ご興味をお持ちいただけましたら、お問い合わせ等の詳細情報についてはブログ末尾をご確認ください。
MQTTからintdashへのリレー構成
本来、最適なパフォーマンスを実現するには、伝送基盤のintdashと可視化ツールのVisual M2Mをセットで導入していただき、デバイス側も含めてすべてintdashに置き換えていただくのが理想です。
しかし、デバイス側の置き換えには大きな移行コストがかかることも踏まえ、今回は既存システムを活用しながらリレーによってMQTTとintdashを接続する構成をご紹介します。こちらの構成では、まずはintdashとVisual M2Mの性能を気軽に体感していただくことを目的としています。
本構成のメリット：
- 既存のMQTT環境を変更することなく試験的にVisual M2Mを導入可能
- Visual M2Mの優れたパフォーマンスと高機能な可視化を手軽に体験
デメリットとしては、MQTTとintdashの二重構造による冗長性が挙げられますが、まずはVisual M2Mの利便性を体感し、最終的にintdashへの全体移行を検討するためのきっかけとしてご活用いただければ幸いです。
構築ハンズオン
本記事では、既存のMQTTベースのIoTシステムにintdashおよびVisual M2Mを追加導入する構成を前提としたハンズオンを行います。具体的には、OSSのMQTTブローカー（Mosquitto）とRaspberry Piを用いたセンサーデバイスで既存システムを模倣し、そのシステムにintdash/Visual M2Mをリレープログラム経由で追加して、データの可視化までを行います。
※ 記事執筆当初はハンズオンも含む記事とする予定でしたが、想定外に分量が多くなってしまったため、ハンズオン部分は別途別記事に切り出すこととしました。後日公開予定です。以降のセクションは、ハンズオンの結果についてスクリーンショット付きで解説していきます。
実際の可視化の様子
まずは一般的なMQTTダッシュボードを使用してデータを可視化してみましょう。Raspberry Piからデータ送信を開始しMQTTダッシュボードを確認すると、データが流れている様子が確認できます。
今回は冒頭でも触れた MQTT ExplorerとNode-RED Dashboardをサンプルとしてご紹介します。
MQTT Explorer
MQTT Explorer は構築しやすい反面、可視化の表現が限定的です。1トピックあたり1パネルとなり、それぞれのデータの相関具合を確認したりするには少し工夫が必要です。
Node-RED Dashboard
次に、Node-RED Dashboardで可視化する方法も試してみます。 こちらは重ね合わせでの表現も可能ですが、一方でパフォーマンス面で問題が生じました。パフォーマンスの問題については後続のセクションでVisual M2Mと比較します。
Visual M2M
同じデータをintdashにリレーし、Visual M2Mで可視化してみます。 Visual M2Mでは、様々な可視化パーツとグリッドで構成された柔軟なダッシュボードにより、流れているデータを自由に可視化することができます。
ダッシュボードの自由度も高く、描画パフォーマンスも良好で、高頻度なセンサーデータをリアルタイムに描画できました。
描画パフォーマンスの比較
今度は、ダッシュボードの描画パフォーマンスについて、Visual M2Mとその他のツールを比較してみましょう。 今回は比較対象として、Node-RED Dashboardを取り上げます。以下に、Node-RED Dashboard と Visual M2M を並べて再生した動画を示します。
Node-RED Dashboardは、静止画では一見問題なく描画されているようにも見えましたが、連続再生していると徐々に描画がリアルタイムから遅れていき、最終的には何秒も遅れたデータが画面上に描画されるようになってしまいました。一方、Visual M2Mは、高頻度データでも滑らかかつ遅延なく表示できています。
低遅延なIoTデータの伝送や可視化については、MQTTなどの "伝送プロトコル" の部分が注目されがちではありますが、最終的にエンドツーエンドで低遅延にデータを届けるには描画側のパフォーマンスも重要な要素であることをおわかりいただけたかと思います。
Grafana との比較と Visual M2M の強み
MQTTに少し詳しい方であれば、広く使われている Grafana が比較対象として出てきていないことにお気づきかもしれません。 Grafana は、ダッシュボードの柔軟性やリアルタイム描画のパフォーマンスに関して評価する場合、OSSにおいては最も魅力的かつデファクトスタンダードとなりつつある選択肢の一つです。
このセクションでは、この Grafana について個別に枠を設けて特に掘り下げて、 Visual M2M との違いを明らかにしていきます。
Grafana におけるリアルタイム再生の仕組み
Grafana は、もともとサーバー監視などで利用されることが多く、単体のままではリアルタイム描画には対応していませんでした。 しかし、v8 で追加された Grafana Live というメッセージングエンジン（Grafana専用のブローカー）を有効化することによって、リアルタイム描画が可能になります。
Grafana Live では、Grafana が稼働しているサーバーのプロセス内に可視化専用の Pub/Sub ブローカーを起動するようです。 Grafana と MQTT とをつなぐ MQTT Data Source は、この仕組みを使用してMQTTブローカーからのデータを専用ブローカーに中継し、Webブラウザまで送り届けます。 Grafana Liveの可視化専用ブローカーは可視化に特化した簡易的なものではあるものの、MQTTブローカーから別のブローカーに中継するという意味で、intdash/Visual M2Mの構成と近しい構成といえます。
Grafana vs Visual M2M
それでは、比較のために Grafana での描画の様子をみてみましょう。 UIのデザインに関にしては、これまでに比較した MQTT Explorer や Node-RED Dashboard からは一歩抜きん出ていることが分かります。
黒を基調としたダークなデザインである点がVisual M2Mと良く似ていますが、Visual M2Mのほうが若干ビビッドではっきりした色合い、Grafana のほうがすこし落ち着いた色合いをしています。
ここからは、Visual M2Mとの違いを一つずつ見ていきます。
Visual M2Mとの違い① : ブローカーの違い
違いの1つ目は、ブローカーの違いです。
Grafana Live の可視化専用ブローカーは可視化専用の簡易的なもので、通常構成ではサーバーのプロセス内でしか通信ができません。複数のプロセス間で通信するには v8.1 で追加された Redis-based Live HA の構成が必要ですが、これはまだ Experimental 扱いのようです。また、メッセージサイズやフレーム頻度にも限界があり、今回のケースのようなIMUセンサー1台程度であれば問題ありませんでしたが、大量のデバイスからのデータや大量データの可視化ではパフォーマンスが追いつかなくなることが予想されます。
一方、intdash/Visual M2Mでは、そもそも大量のデータを中継するために作られたデータ伝送用のブローカーintdashがデータを中継する構成をとるため、デバイスやデータ量が増えても問題は生じにくくなっています。
Visual M2Mとの違い② : マルチモーダル対応の違い
違いの2つ目は、マルチモーダルデータへの対応方法の違いです。
IoTデータを収集するフィジカルな現場では、数値データだけでなく映像や音声などマルチモーダルなデータを取り扱うことがよくあります。 たとえばリアルタイムな映像データをGrafanaで再生しようと考えた場合、どうなるでしょうか？
そもそもMQTTでの映像伝送はあまり一般的ではないのでWebRTCなどを併用することになりますが、WebRTC用のプラグインはコミュニティにより提供されたものしか存在しないようです。 さらにWebRTC用をはじめとする映像再生系のプラグインは、いずれもGrafana Live を使用する仕組みではなく、直接映像データを映像ソースから受け取る仕組みになっているようでした。
このようにデータがそれぞれ別の経路を辿って伝送され、さらに別々の開発元によって作られた別のパネルで再生されるような構成では、 一見同時に再生されているように見えても、各瞬間瞬間で本当に同時刻のデータが画面上に描画されているかは担保できません。
一方、intdashでは、共通のブローカー（intdash）により、センサー値から映像・音声、点群データまで大小様々なデータを、単一のコネクションにより転送することができます。 可視化ツールである Visual M2M も、データの同期を正しく取って再生するように作り込まれているので、マルチモーダルな様々なデータがその瞬間どの様に関連していたのかを正確に把握することができます。
今後の拡張性と推奨構成
今回は、既存システムを活かすことを重視し、intdash/Visual M2Mを横付けする構成としました。しかし、この構成はintdash/Visual M2Mの持つパフォーマンスを最大限に生かせるものではなく、構成上の冗長性もあります。
intdashの性能を最大限に活かすには、バックエンドのMQTTブローカーもintdashに移行し、よりシンプルで効率的な構成とすることがおすすめです。
Visual M2Mはマルチモーダルデータを同一のダッシュボードで再生できるため、従来のMQTTベースのダッシュボードツールでは対応していなかった製造や音声などのデータも、センサーデータとあわせて同期再生できるようになります。
intdashをベースとすることで、マルチモーダルなデータを含む高度なリアルタイム監視や分析環境をシンプルな構成で実現することができるようになり、複数のOSSを組み合わせて構築する場合に比べて運用や保守の負担が大きく軽減されます。
おわりに
本記事では、既存のMQTT環境を維持しながら、intdashおよびVisual M2Mを導入し、その強力なパフォーマンスやマルチモーダルデータの統合表示機能を体感いただける構成をご紹介しました。本記事をきっかけに、まずはVisual M2Mの優れた性能をお試しいただき、そのメリットを実感していただければ幸いです。
ぜひ、この機会にintdash/Visual M2Mのトライアルをお試しください。ご質問や導入に関するご相談は、以下のリンクからお気軽にお問い合わせください。
