こんにちは。
コンサルティング & テクノロジー部の Azure チームの茨木です。
今回は Azure IoTHub のメッセージ交換速度を計測してみました。
HoloLens でインターネットスケールのシェアリングを実装する基盤として使えないかな～、という調査です。HoloLens をひとつのIoTデバイスに見立てちゃいます。そして、大規模IoTを支えうるクラウドの能力を活かしたい！
さっそく結果から
計測データ（50メッセージ分）
83.4808,79.0807,80.4362,106.1287,107.8595,132.7864,143.2341,99.0367,95.0567,98.1113,103.7593,126.0579,87.52,81.521,123.0194,86.5453,110.5467,77.53,93.0664,107.9788,132.8832,100.0395,134.6327,105.5885,125.6452,94.8599,96.6338,74.5254,88.0342,126.7914,100.0541,115.0617,99.457,70.5218,112.7258,83.6304,118.2345,100.6299,106.028,96.5275,123.732,108.5852,85.5909,109.5293,112.7504,116.6388,106.6326,119.0645,87.5188,95.2303,
生データ見てもわかりませんね。ヒストグラムでどうぞ。時間単位はmsです。
概ね 100ms といったところでしょうか。ターンアラウンドタイムです。これなら使える、かも。
では、細かな計測条件
- リソース、ネットワーク構成はこの図のとおり
- 東日本リージョンに設置したリソースに関東圏から接続
- データペイロードは16バイト（別途、自動で付随するデータあり）
- 送受信はそれぞれ別スレッドからシーケンシャルに
いけそう？
単一デバイスからのシーケンシャルな計測ですが、クラウドリソースは柔軟にスケールするので多数のデバイスを抱えても、メッセージ数が増えても、おそらく影響はないです。
デバイス～IoTHub間は MQTT で接続できるので、オーバーヘッドの少ない通信が実現できるでしょう。QoS 1 で接続されるので、メッセージロストについても心配ないでしょう。
この結果なら、実際にシェアリングの実験に移っても良さそうな気がします。MRは体験がすべて、なので、まだまだやってみなくちゃわからない！
注意点
完全に非同期なメッセージ交換しかできませんので、デバイス／クラウド共に繊細な制御が必要になります。また、C2Dメッセージのキューはデバイスあたり50個に制限されている点にはご注意を。デバイスでのメッセージ受信は専用スレッドを設けるなど、滞ることなく回す必要があるでしょう。
また、IoTHub（≒EventHub）の設計思想は大量の小さなデータを捌く指向だろうと思います。対して速度については重要度が低いはず。アプリ間のメッセージ交換に特化しているのは Service Bus のほうなので、これも含めて検討する必要がありそうです。
