mockmock Data Recorderを使って異常検知を試してみた！

こんにちは、IoTエンジニアのHaruka Yamashita (@YamaHaruka925) | Twitterです。

2019年4月にプレビュー版がリリースされた、mockmock DataRecorderを使ってみて、IoT PoCを担当する者としてグッときたポイントをご紹介します！

■mockmock DataRecorderとは

mockmockは、クラウド上に仮想デバイスを作成し、開発中のサーバーに疑似データを届けられるサービスです。

これまでは、
　・データの階層構造や、値の型・生成方法などをコンソール上で入力するだけで、簡単に疑似データを設定することができる。
　・仮想デバイスは、瞬時に動作や台数を変更できる。
　・欲しいデータを、欲しいタイミングで、欲しい量だけ受け取ることができる。
という特徴がありました。

さらに、新たにリリースされたDataRecorderでは、人工的に作成した疑似データではなく、実際のデバイスから収集されるリアルなデータを用いて仮想デバイスを生成することができます。

1. mockmock DataRecorderを使えば、IoT PoCのよくある困った！を解決できるのでは？

1-1. IoT PoCでよくある困った！ポイント

PoCを実施する中では、次のような課題が発生することが多くあります。
私自身、IoT担当エンジニアとして、以下のような点を毎度自分で作成・加工するのに時間を取られています。。。

• センサー/エッジデバイスの選定から始めると、分析までたどり着くまで時間がかかる
• データを蓄積するのに、時間がかかる。
• PoCの期間内に、想定する異常（部品の消耗など）が発生するとは限らない
• データの取得間隔やデータ量、送信頻度など、パラメータを変更するのが大変
• PoCで実施した数台での試行だけでは、最終的な可視化や分析の効果まで予測できない

1-2. mockmock DataRecorderを利用することで、IoT開発の「困った」を解決！

1-1. のような課題に対し、mockmock DataRecorderを利用すれば、データ収集や実データを基にした想定される異常波形を作成・加工する部分を簡単にできる！

• 実際に測定したデータをmockmock DataRecorderに登録することで、疑似波形ではなく実際のデータをもとに、パラメータの試行錯誤ができる。
• 通信方式が決定していなくても、csvファイルからmockmock DataRecorderに登録することができる。
• 実際のデータをベースに波形加工をできるため、想定される異常波形など作りこむことができる。
• 実際のデータをベースに仮想デバイスの台数を増やすことができるため、対象機器の種類や台数が増えた場合のシステム全体を想定できる。

2. mockmock DataRecorderを利用して実際のデータから想定される異常データを作成してみる

2-1. mockmock DataRecorderにデータを登録する

まずは、mockmock DataRecorderに実際のデータを登録します。
そのためには、
　①mockmock DataRecorderにMQTTSでデータを送信する
　②csvファイルをアップロードする
という二つの方法があります。
詳しくは、mockmockのドキュメントをご覧ください。

実際のデータを登録することで、仮想デバイスから送るデータを疑似データではなく実際のデータをそのまま利用することができるようになります。

2-2. 実際のデータをもとに、異常波形をつくりこむ

mockmockに登録した実際のデータを基に、異常波形をつくりこんでみましょう。
mockmock DataRecorderには、データ変換タイプとして以下の4種類が用意されています。

• 無変換（コピー）
• ノイズを付与する
• ピーク値を付与する
• データを間引く

今回は、「ピーク値を付与する」を利用して、異常データを作りこんでみました。

もともとの波形に対し、データの途中からピーク値をのっけることで想定外の振動が発生した状態を模擬します。
元データに対し、「どのデータ位置から、どのようなピーク値を、どれくらいの点数分、どれくらいの間隔をあけて」付与するかをJsonでパラメータ定義してあげます。

これだけで、もともとのデータに対し、ピーク値を付与することができます。
今回は、以下のように波形を変化させました。
mockmock DataRecorderにはデータ可視化機能も付いており、登録/変形させたデータをすぐに可視化して確かめることができます！

2-3. Torrentioへのデータ送信

今回、データ分析部分は当社Torrentioを利用しています。
mockmockからTorrentioにデータを送るための設定は簡単です。
mockmockのデータ送信先設定にTorrentioのMQTTエンドポイント設定を記入するだけ。

mockmockから送信するデータのリプレイヤー定義にて、2-1. で登録したDataRecorderのデータセットを選択します。

mockグループ設定にて、上で定義したデータリプレイヤーを利用するよう設定し、TorrentioのTopic名、MQTTクライアントIDを設定して準備完了。

あとは好きな台数の仮想デバイス（mock）を作成し、起動するだけ！
今回は、もともと1台から収集したデータを3台に増幅して送っています。

2-4. 異常検知してみる

mockmockから送信されたデータをTorrentioで異常検知してみます。

PoCとしてセンサーによりデータを測定しているのは1台ですが、mockmockにより実データを送信できる仮想デバイスを増やすことで、複数台で実施した場合の分析の見え方なども検討することができます。

※ここでは異常検知を実施しましたが、Torrentioでは、他にもIoTダッシュボードでのリアルタイム可視化やルールエンジンによる制御なども実施することができます。
　詳しくは、Torrentio Cloudについてをご覧ください。

3. まとめ

小さく始めることで、実施しようとしているIoTシステム開発が有効かどうかを見極めるためのPoC（実証実験）ですが、IoTシステムにはセンサー/ネットワーク/分析プラットフォームなど必要なステップが多く試行錯誤に時間がかかることや、監視対象の機器台数がスケールした場合の想定が難しいなどの課題がありました。
mockmock DataRecorderを利用することにより、「測定した実際のデータをもとに」仮想デバイスの台数を増やせたり、異常波形を創りこむことができます。
PoCでの試行錯誤がぐんとやりやすくなりますね！

Acroquest Technologyでは、キャリア採用を行っています。

• ディープラーニング等を使った自然言語／画像／音声／動画解析の研究開発
• Elasticsearch等を使ったデータ収集／分析／可視化
• マイクロサービス、DevOps、最新のOSSを利用する開発プロジェクト
• 書籍・雑誌等の執筆や、社内外での技術の発信・共有によるエンジニアとしての成長

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

www.wantedly.com

MQTT Broker比較（2015/12版）

こんにちは、ishida(@kojiisd)です。

「IoT」という言葉も、IT／ICT関係者だけでなく、一般ニュースやビジネス雑誌にも登場するようになり、大分バズって広まってきていますね。

IoTといえば、やはりMQTTとの関係は切り離せず、商用のMQTT Brokerとしては、Sango だけでなく、 AWS IoT なども登場してきており、どれを利用するのが良いか、迷ってしまいますよね。

また、前回2015年6月にOSSの MQTT Broker 比較を行った際は、日本語の記事にも関わらず、VerneMQやeMQTTのコミッタの方からコメントも頂き、反響の大きさには驚きました。
ということで、OSSのBrokerも、バージョンアップがされてきているので、改めて比較レポートを作成しました！

※前回の比較内容は以下になります。

• MQTT Broker比較～機能比較編 - Taste of Tech Topics
• MQTT Broker比較～性能比較編 - Taste of Tech Topics

機能比較

各MQTT Brokerの機能比較に関しては、以下のようになります（○：対応あり、×：対応なし）。

Broker(version)	開発言語	対応しているMQTT version	対応OS	QoSレベル	Retain	Will	WebSocket	UI	冗長化
Mosquitto(1.4.5)	C	MQTT 3.1/3.1.1	Win/Mac/Linux	0,1,2	○	○	○	×	×
Apollo(1.7.1)	Java	MQTT 3.1	Win/Mac/Linux	0,1,2	○	○	○	○	×
RabbitMQ(3.5.6)	Erlang	MQTT 3.1	Win/Mac/Linux	0,1	×	○	×	○	○
Mosca(0.32.1)	Node.js	MQTT 3.1	Win/Mac/Linux	0,1	○	○	○	×	×
eMQTT(0.13.0)	Erlang	MQTT 3.1/3.1.1	Win/Mac/Linux	0,1,2	○	○	○	○	○
VerneMQ(0.12.2)	Erlang	MQTT 3.1/3.1.1	Mac/Linux	0,1,2	○	○	○	×	○

• Brokerのversionは調査時のものです。
• 今回、新たに「対応OS」の列を加えました。

性能比較

Publish性能(retain=false)

Publish性能(retain=true)

Subscribe性能

• グラフの縦軸は「スループット（処理したメッセージ数/秒）」です。
• 機能的に対応していない箇所はグラフを記載していません。

結果

• eMQTTには管理のためのWebUIが追加されて、使い勝手が良くなりました。
• eMQTTとVerneMQは、前回評価時は、retainをtrueにした際の性能が大幅に低下したのですが、今回はその点が改善され、retainをtrueにしても性能劣化は見られなくなりました。
• eMQTTが全体的に性能が向上し、VerneMQと同等の性能になっています。

前回評価時から、たった半年ですが、eMQTTやVerneMQなどはリリースの頻度も多く、性能も大幅に改善されていました。
個人的には、前回の結果からは「使うならVerneMQだろう」と思っていたのですが、今回の結果からはeMQTTもかなり魅力的になりました。

用途や目的に応じて、最適なBrokerを選択するのに役に立てて頂ければと思います。

計測内容

計測について、以下に処理内容を示します。

1. Publish（Retainなし）
   • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainなしの場合は、最後にPublishされたメッセージをBrokerが保持しません。
2. Publish（Retainあり）
   • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainありの場合は、最後にPublishされたメッセージをBrokerが保持します。
3. Subscribe
   • MQTT Broker から、クライアントがメッセージを受信する処理になります。MQTTの特性として、接続されているときのみメッセージを受信するため、Subscribeしている間、それとは別プロセスでPublish（Retainなし）の処理を行っています。

またベンチマークの条件は以下になります。

• 構成、メッセージ長
  • MQTT Broker に対して、500connections で同時処理
  • 1つのメッセージ長は 1024byte
• マシンスペック
  • OS: CentOS 6.5 (64bit)
  • CPU: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (4コア HT有効)
  • メモリ: 32GB
  • NIC: 1Gbps

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

MQTT Broker比較～性能比較編

こんにちは、ツカノ(@snuffkin)です。

MQTT Broker 比較の第二弾です。

前回は、機能の比較を行いました。

• MQTT Broker比較～機能比較編

実際のシステムへの適応を考えると、性能は特に気になるところ。
ということで、今回は性能比較を行ってみました。
ベンチマークは環境や測定方法、バージョンによっても大きく異なりますので、
あくまで一例として参考にしてもらえればと思います。

ベンチマークに利用したプログラムは、Goで開発された以下の MQTT-Bench を利用しています。

• MQTT-Bench : MQTT Benchmark Tool

ベンチマークの条件は以下の通りです。

• 構成、メッセージ長
  • MQTT Broker に対して、500connections で同時処理
  • 1つのメッセージ長は 1024byte
• マシンスペック
  • OS: CentOS 6.5 (64bit)
  • CPU: Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (4コア HT有効)
  • メモリ: 32GB
  • NIC: 1Gbps
• MQTT Broker のバージョン
  • Mosquitto(1.4.2)
  • Apollo(1.7.1)
  • RabbitMQ(3.5.3)
  • Mosca(0.29.0)
  • eMQTTD(0.8.6-beta) ※クラスタに対応しているが、1プロセスで処理
  • VerneMQ(0.9.4) ※クラスタに対応しているが、1プロセスで処理

計測内容

計測は、以下のパターンで行っています。

1. Publish（Retainなし）
   • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainなしの場合は、最後にPublishされたメッセージをBrokerが保持しません。
2. Publish（Retainあり）
   • MQTT Broker に対して、クライアントからメッセージを送信する処理になります。Retainありの場合は、最後にPublishされたメッセージをBrokerが保持します。
3. Subscribe
   • MQTT Broker から、クライアントがメッセージを受信する処理になります。MQTTの特性として、接続されているときのみメッセージを受信するため、Subscribeしている間、それとは別プロセスでPublish（Retainなし）の処理を行っています。

計測結果は、以下のグラフになりますが、グラフの縦軸は、「処理したメッセージ数/秒」です。
また、機能的に対応していない箇所はグラフを記載していません。

※RabbitMQ のQoS=1の場合のSubscribeの処理は、Publishされたメッセージが内部のキューを介するようで、今回のSubscribeの計測方法では、性能があまり出なかったため、計測結果からは除いています。

Publish性能(retain=false)

Publish性能(retain=true)

Subscribe性能

結果

• 全体として、Mosquitto／Apollo／VerneMQの性能が良いです。
• 以前は、Mosquittoの性能はいまひとつ、という話がありましが、現在のバージョンでは、他と比べてもトップレベルの性能になっているようです。
• VerneMQ は、Retainありの場合は性能が低くなる傾向がありますが、1プロセスでもトップレベルの性能になっています。クラスタ構成を組むことで、分散して処理することができるため、さらに性能を向上できる可能性があります（クラスタ構成での性能は、今回未計測です）。

さて、2回に分けて、MQTT Brokerの機能比較と性能比較を行ってきましたが、
この1～2ヶ月の間にも、MQTT Brokerがバージョンアップされて機能や性能が改善したり、
VerneMQのような新しいプロダクトがリリースされたりと、動きが大きい分野だと感じています。

これからも、IoTとともにMQTT Brokerは要注目、ですね！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

MQTT Broker比較～機能比較編

こんにちは、ツカノ(@snuffkin)です。

このところ IoT（Internet of Things）関連のニュースを目にすることが増えました。
最近であればPepper君の一般販売などが大きなニュースでしたが、
システムの足回りが大好きな自分としては、IoTと言えば、そう、MQTTですね！（強引！）

Googleトレンドで調べてみたら、こんな感じでした。ここ1-2年で急速に伸びていますね。

MQTTは、Message Queue Telemetry Transport の略ですが、Pub/Sub型モデルのメッセージキュー"プロトコル"であり、MQ（Message Queue）と言いつつ、メッセージを蓄積はしないんですよね。よく勘違いされる点なので、注意が必要です。

MQTTの詳しい説明は、以下のサイトが参考になります。

• MQTT.ORG
• MQ Telemetry Transport (MQTT) V3.1 プロトコル仕様
• MQTT Version 3.1.1(OASIS)
• MQTTについてのまとめ

さて、そんなMQTTですが、メッセージをやり取りするには、仲介役となる MQTT Broker が必要になります。
OSSの MQTT Broker も多く登場してきているのですが、それぞれ実装されている仕様も異なっているため、利用時には注意が必要です。

そこで、自分としてもどのような差分があるのか知りたくなり、代表的なOSSの MQTT Broker について調査してみました。

MQTTの参照実装と言われる Mosquitto をはじめとして、利用されるケースが多い、Apollo、RabbitMQ、eMQTTD、Mosca について機能比較を行いました。

その結果が以下の表です(○:対応あり、×:対応なし)。

Broker(version)	開発言語	対応しているMQTT version	QoSレベル	Retain	Will	WebSocket	UI	冗長化
Mosquitto(1.4.2)	C	MQTT 3.1/3.1.1	0,1,2	○	○	○	×	×
Apollo(1.7.1)	Java	MQTT 3.1	0,1,2	○	○	○	○	×
RabbitMQ(3.5.3)	Erlang	MQTT 3.1	0,1	×	○	×	○	○
Mosca(0.29.0)	Node.js	MQTT 3.1	0,1	×	○	○	×	×
eMQTTD(0.8.6-beta)	Erlang	MQTT 3.1/3.1.1	0,1,2	○	○	○	×	○
VerneMQ(0.9.4)	Erlang	MQTT 3.1/3.1.1	0,1,2	○	○	○	×	○

Brokerのversionは調査時のものです。

以下、今回比較した観点について、簡単に説明します。

• MQTT 3.1と3.1.1の違いは以下に解説されています。3.1.1では、曖昧な点の仕様を明確にしたり、Client IDのサイズ拡張等が行われています。
  • 6 facts why it’s worth upgrading to the brand new MQTT 3.1.1 version
  • Differences between 3.1.0 and 3.1.1
• QoS(Quality of Service)はメッセージ配信に関する品質保証のレベルで、以下の3段階存在します。
  • QoS 0: At most once - 最高1回配信します。(1回も配信されない可能性があります)
  • QoS 1: At least once - 少なくとも一回配信します。(2回以上配信される可能性があります)
  • QoS 2: Exactly once - 正確に一回配信します。
• Retainに対応していると、トピックにSubscribeしたときに、最新のメッセージが配信されます。
• Willは「Last Will and Testament」のことで、Publisherが切断した際に予め決めておいたメッセージを、Subscriberに配信する流す仕組みがあります。
• WebSocketは、MQTTのメッセージをWebSocketのプロトコルを使って配信できるかどうかです。
• UIは、Brokerの管理画面などがUIで提供されているかどうか表します。Webブラウザを使って管理できると便利ですよね。

各Brokerに対して寸評を書くと。。。

• Mosquitto
  • 冗長化が無いものの（MQTTの仕様上は、冗長化は必要ありません）、参照実装だけあって、QoSやretain等の仕様は全て対応されています。
• Apollo
  • 機能的には良いのですが、動作をさせてみたところ、MQTTのメッセージのヘッダが標準と多少異なるようで、MQTTクライアントのAPIの種類によっては、Subscribeできないケースがありました。
• RabbitMQ
  • 以前から普通のMQとして利用することも多かったので、期待していたのですが、未だに、QoS=2に対応していなかったり、retainに対応していなかったり（開発は進んでおり、v3.6.0で対応する予定があるようです）する点は、残念な状況です。
• Mosca
  • MQTTとしての機能は不足している感じがします。ただし、MoscaはStandaloneでもEmbedded(他アプリ内で動作する)でも動作する、という特徴があります。
• eMQTTD
  • クラスタ構成を組むことができるため、冗長化にも対応しており、機能的には良いですね。現在、バージョンアップも頻繁に行われています。
  • ただ、次回紹介しますが、性能が他Brokerに追いついていないところがあり、そこは今後に期待ですね。
• VerneMQ
  • 直近の2015年5月に、最初のリリースが行われましたが、MQTTの仕様も網羅されている上に、クラスタ構成にも対応しているため、OSSのMQTT Brokerとしてはかなり有力候補となるプロダクトですね。
  • ドキュメントも充実して分かりやすいです。

また、今回はそのままインストールして利用するのではないため、比較の対象からは外していますが、750,000 Messages/sec を達成したという、Goで実装された SugeMQ （MQTT Broker／Client ライブラリ、という位置づけ）なんかもあったりします。

バージョンが変わると、また状況は変わってくるかもしれませんが、MQTT Broker を利用する際の参考なれば、と思います。
＃できれば、商用の MQTT Broker も対象にしたかったのですが、それはまた今度の機会に。

次回はこれらの MQTT Broker に対して、皆さん気になるベンチマークした結果を紹介したいと思います！

2015/06/26 更新
MQTT Brokerの動きも早く、短期間の内にバージョンアップされていたり、新しいBrokerが登場していました。
それらに関してコメントを頂いたため、内容を更新しました。

• 調査対象のバージョンを、2016/06/26時点で最新のものに更新しました。
• Will、WebSocket の項目を追加しました。
• 調査対象にVerneMQを追加しました。

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ

MQTT Meetup Tokyo 2014.08に参加してきました！

id:KenichiroMurata（@muraken720 ）です。

皆さんはMQTTに興味はありますか？私は昨年末くらいからMQTTに興味を持ち、そこからあれこれ調べています。

また社内でも、Stormのエコシステムとして開発しているAcroMUASHI Streamの開発チームが、MQTTと連係した分散ストリーム処理を実現しており、私の周辺では盛り上がっています。

そんな中、先日 MQTT Meetup Tokyo 2014.08が開催され、幸運にも参加することができましたので、今回はその参加レポートをお届けします。

イベントの概要はこちらをご覧下さい。イベントは非常に内容の濃いものであり、面白かったです。
少しでも何かお手伝いできることがあればとイベント当日のtweetをtogetterにまとめましたので、当日の雰囲気や反応をご覧になりたい方はMQTT Meetup Tokyo 2014.08 まとめも合わせてご覧下さい。

1. MQTTの機能概要 - ツキノワ 若山さん(@r_rudi)

• 資料 MQTT meetup in Tokyo 機能概要

MQTTについてのまとめ — そこはかとなく書くよん。を書かれた方による発表。MQTTの概要についての説明であり、特にWill、Retain、CleanSessionについての説明は理解を復習する意味でも非常に分かりやすかったです。Retainの活用方法の例として、Subscribeしてくるデバイスに最新の設定情報をRetainを使って渡すという話は、なるほどでした。また、Microservicesについても少し触れられていました。

2. IBM MessageSight - IBM 鈴木徹さん

IBM MessageSightはMQTTのアプライアンスサーバーで、なんと100万デバイスを常時接続可能、毎秒1500万メッセージを処理できるとのこと。100万のデバイスを60秒以内で全て接続できるとか、毎秒1万メッセージを平均85マイクロ秒でさばけるとか、サーバの冗長化も当然可能という凄いものでした。お値段は怖くて聞けないレベルです。

プレゼンをされた鈴木さんは、普段はMQTTがどれだけ良いかを説明するのにほとんどの時間を使うのに対して、今日は参加者が皆MQTTのことは良いモノと知っているので、その説明がいらないのが最高！とあれこれネタを仕込んだマシンガントークを展開し、非常に面白かったです。

話の焦点はMQTTうんぬんではなく、IoTをどのようにしてビジネスにつなげて利益を生み出すのか？という内容になり、車内センサーで運転手の状態を常時接続で情報収集し、その情報を保険会社が活用するといった事例紹介もありました。

あとは、IBMさんでは、MQTT/IoTで収集したデータをどうやって活用するのか、既存の様々なシステムと結合できるように仕組み化している点についても説明があり、ここでもMicroservicesを連想させる「3年後に取り替え可能な部品によるシステムを作る。疎結合に」なんて話が聞けました。

3. IoT/M2M Hot Topics in IETF - レピダム 林さん(@lef)

CoAPとその周辺に関する話題について。CoAPについては私は初めて知りました。HTTP/RESTと親和性のあるIoT/M2M用の軽量プロトコルであり、UDPとのこと。MQTTがTCPで常時接続であるのに対して、UDPを利用するMQTT-SNと対応付く関係にあるものだと理解しました。

CoAPそのものというよりもIETFの仕様策定の裏側（仕様に関するユースケースを話してしまうと、ビジネス上問題なので、ユースケースの話になると大人の事情で議論が進まなくなる）みたいな話がきけて面白かったです。

4. 時雨堂 MQTT ブローカー (AKANE) - @voluntas さん

• 資料 時雨堂 MQTT ブローカー (AKANE)

本イベントの主催者であり、イベント前日にMQTT as a Seriviceであるsangoを発表した時雨堂の@voluntasさんによるsangoの中で使われている MQTT ブローカー (AKANE) の開発苦労談。

仕様としてはシンプルなMQTTですが、MQTT Brokerを本気で開発しようとすると、どのような問題があって、苦労するのかという話で非常に面白かったです。特に、仕様には含まれていないが、現実的にシステムとして運用できるようにするために実装した機能についてはとても参考になりました。

仕事上、数万、数十万の監視対象ノードを集中監視制御するシステムを開発してきたので、リトライ、ノード別の状態遷移制御、時系列制御、優先キュー、一斉接続などなど、それに類する話題が基本なのでイメージしやすかったし、共感できました。MQTTでは、さばくクライアント数が多いのは当然として、トピックのSubscribeの指定方法によっては１クライアントに配信するメッセージが爆発的に増えるし、QoSダウングレードはさらに複雑になるので、その実装はたしかにつらそうです。なぜに世のMQTT Brokerの実装が（私が観測する範囲では）どれも途中に見えるのは、このような背景があるからなんですね。

5. MQTT+RaspberryPi+Arduino+センサーで制御とGUIを実装した話 - 小松電機産業 廣江さん (@hiroe_orz17)

RaspberryPi+Arduino、オムロンPLC、Intel Galileo でMQTTしてみた話 - ごろねこ日記を書かれた方による発表。具体的にアプリケーションを作る上で、どのように考えて、何を試して、結果どう実現したかが具体的に分かる内容でした。MQTTのペイロード部をどのようにするのか、3G環境下で通信量を削減／効率化するために配列やバイト列を使った表現やMessagePackの利用など、試行錯誤も含めての説明だったので、イメージが沸きました。

おまけ sangoを試してみる

githubアカウントで簡単にsangoを使い始められるということで、イベント終了後に早速アカウントを作成し、試してみました。mosquittoを使ってCLIで試すのは直ぐにできたので、以前から気になっていたMQTTInspectorというiOSアプリ（有料）を使って試してみました。

アプリの使い方そのものに慣れるのに手探り状態でしたが、以下のように簡単に動作させることができました。ビューによっては通信状態が見えるのがよいですね。

メッセージを送受信している例

通信ログ

最後に

MQTT Meetup Tokyo 2014.08 はMQTTの概要から始まって、仕様の話、ビジネス活用の話、Broker実装の裏話、クライアントアプリ開発の話と幅広い内容で、しかもそれぞれが濃い話でした。このようなイベントを企画してくださり、どうもありがとうございました！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　キャリア採用ページ