Go to Qiita Advent Calendar 2024 Top
LoginSignup
6
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@HiroyukiSakoh(Hiroyuki Sakoh)

Azure IoT Hub デバイス ストリームを試してみた

Last updated at Posted at 2019-02-24

はじめに

こんにちは
1月下旬にパブリックプレビューが開始された、
IoT Hubの機能の一つデバイスストリームをご存知ですか？

今回は、実際に触ってみて、どういった機能なのか、
優れている点はどこか を確認していきます。

デバイス ストリーム

とりあえず軽くMicrosoft Docsの受け売り説明

概要

デバイスストリームは双方向TCPトンネルの作成が簡単になる機能です。

デバイスとサービスの間をIoTHubが仲介することで、
ファイアウォールの後ろにあっても、プライベートネットワーク内にいても、
サービスからデバイスへのTCP接続ができるようになります。
image.png
Microsoft Docs|IoT Hub デバイス ストリーム (プレビュー) 1

利点

ファイアウォールフレンドリ

デバイスがIoTHubへ 443のアウトバウンド接続を作成するだけで、
ファイアウォールに穴をあけることなく、インバウンド(着信)の接続を受け取れます。

接続の簡略化

デバイスのIPアドレスを識別せず、デバイスIDのみでデバイスとの通信が開始できます。

認証

通常のIoTHubで提供される、デバイスやサービスの認証機能が利用できます

暗号化

デバイスストリームを通したい通信が暗号化されていない場合でも、
デバイスとIoTHub、サービスとIoTHubはそれぞれTLS接続なので、
経路はセキュアに保たれます。

TCP/IPとの互換

いわゆる普通のソケット通信が可能です

ストリーム作成の流れ

image.png
引用元:Microsoft Docs|IoT Hub デバイス ストリーム (プレビュー)2

  1. デバイスがIoTHubに接続して、ストリームの開始要求リクエストの応答を待機するコールバックを登録します
  2. サービスがIoTHubに接続して、デバイスIDを指定してストリームの開始要求を送信します
  3. IoTHubがデバイスのコールバックを呼び出して通知します。デバイスは、ストリームの開始要求を受け入れるか拒否する事ができます。
  4. デバイスはIoTHubのストリーミングエンドポイントにアウトバウンドTCPで接続し、WebSocketにアップグレードします
  5. サービスは、ストリームの開始要求の結果通知を受け取り、ストリーミングエンドポイントにWebSocketで接続します。

使用するSDK

接続要求を開始する側は、Service用のSDKを使用します。
着信接続を受ける側は、Device用のSDKを使用します。

対応リージョン

パブリックプレビュー中は米国中部か米国中部EUAP(?)にIoTHubを作成すると利用できます。

SKU

Standard(S1-3)と、Free(F1)で利用できます

費用

不明… テレメトリメッセージとかではなく、いろんなメトリック見ても接続開始時に操作分しかカウントされていないような。。
IoTHubの標準費用と、Azureからのアウトバウンド通信分の費用は少なからず発生する(はず)

サンプルプログラムを試す

.NET Core、Node.js(サービスのみ)、C言語(デバイスのみ)の3種類が提供されています。
今回は.NET Coreで試します。

提供されているサンプル(.NET Core)

今回はローカルプロキシーサンプルでSSHとSQLServerに接続してみます。

SSH

まずはサンプルのそのまま、チュートリアルに従って、
AMQPで直接インターネットに出るパターンで試しました。
構成/設定値はこんな感じ。
image.png

※SSHDはDeviceLocalProxyを動かすPCとは別で試しています(ラズパイ)

あっさりと接続できました。
スクショではまったく表現できないですが、遠隔地にあるなといった遅延を感じます

この時のTCP接続の状態は以下の通り。
image.png

実験1 WebProxy経由にしてみる

社畜の足枷であるWebProxy経由で接続できれば素敵なので、試してみます。
今回は、WebProxyに私の愛してやまないFiddlerを使用しています。ハンドシェイクの過程を多少は可視化できますし。

image.png

サンプルコードを少し修正します。
修正点

  1. IoTHubへ接続する、ServiceClientとDeviceClientのコンストラクタでそれぞれWebProxyを使用するよう指定します
  2. プロトコルはAMQPではなくて、AMQP over WebSocketを指定します

差分はこちらgithub

※ServiceClient側のWebProxy対応が不十分(?)で、一部ReflectionでWebProxy無理矢理指定してます

すべての通信がProxy経由になっていることが確認できます。
image.png

ストリームの開始要求のリクエストとレスポンスです
image.png

URLを見ると、twinsの中のstreamなんですね。
また、ストリームエンドポイントのURLが返っていることが確認できます。
image.png

SQLServer

実験2 構成そのまま

実験1と同様の構成で
クライアントにSSMS、サーバーをローカルに立てたSQLServerで試してみます。
image.png

SSMS上はタイムアウトしました。

SSMS,SQLServerのプロトコルの理解が不足しているようなので、
デバイスストリーム使用しない通信をWiresharkで観察してみましたが、
どうやらSSMSはソースポートの異なる複数のコネクションを張っているようでした。

Fiddlerからも、複数回デバイスストリーム要求を出していて、
2回目のデバイスストリーム開始要求が504応答となっていました。
image.png
image.png

実験3 複数のコネクションに対応する

デバイス側のサンプルプログラムは1回分のデバイスストリーム開始要求を受け取ったら、
次を待たないようになっていたため、繰り返し待ち受けるように変更しました。

差分はこちらgithub

うまくいきました。

実験4 通信速度を計測してみる

さて次は、通信速度がどの程度出るのか、遅延はどの程度となるか 試してみます。
＃米国中部-日本を往復するので遅延は当然ですが
以下の構成です。
image.png

結果

Connecting to host 127.0.0.1, port 50001
[  4] local 127.0.0.1 port 53082 connected to 127.0.0.1 port 50001
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec  4.25 MBytes  35.6 Mbits/sec
[  4]   1.00-2.00   sec  7.00 MBytes  58.7 Mbits/sec
[  4]   2.00-3.00   sec  1.50 MBytes  12.6 Mbits/sec
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec
[  4]   4.00-5.00   sec  1.00 MBytes  8.39 Mbits/sec
[  4]   5.00-6.00   sec  1.50 MBytes  12.6 Mbits/sec
[  4]   6.00-7.00   sec  1.00 MBytes  8.39 Mbits/sec
[  4]   7.00-8.00   sec  1.00 MBytes  8.39 Mbits/sec
[  4]   8.00-9.01   sec  1.50 MBytes  12.5 Mbits/sec
[  4]   9.01-10.01  sec  1.00 MBytes  8.37 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-10.01  sec  19.8 MBytes  16.6 Mbits/sec                  sender
[  4]   0.00-10.01  sec  10.1 MBytes  8.49 Mbits/sec                  receiver

iperf Done.

比較対象がなく比較はできませんが、WebSocketに乗せる分のオーバーヘッドがあると思いますが、
普通に実用レベルの速度は出せそうです。

まとめ

  • Azure IoT Hub デバイス ストリームはTCP互換の接続が可能な機能
  • SDKは双方向のWebSocket用Endpointを提供する所まで実施する
  • WebSocketをプログラムで扱うなり、別のソース/宛先へ転送することもできる

何が優れているか

  • デバイスもサービスも アウトバウンド443のみでTCPの相互通信が可能となる

どういった使い方が想定できるか

  • Edgeデバイスのリモートメンテナンスなどのサービスに活用

  • アプリケーションに組み込んで、どんな環境でも通信できるライブラリとして使う
    TeamViewerとかSkypeとか、StackOverflowのCEO Joel Spolskyが昔作ってた Copilotとか
    考え方は昔からあるけど、PaaSとしてはないと思うので、
    IoTHubの機能の一つではなく、独立したサービスとしてあっていいかもしれない。

  • 社畜の足枷であるWebProxy対策としてつかう
    SSHポートフォワーディングの中継サーバーの代わりとして、
    IoTHubの認証+WebScoketで、SSH構えるより狙われにくそうなイメージがある。
    Proxyを簡単に超えられるので、マネージド中継サーバー的な用途として考えると、強力な社畜の味方となりうる(か?)
    →現状のSDKだけではなくて、Proxyのサンプルプログラムの異常系とかしっかり実装して、バイナリで提供してほしい所

おわりに

仕組みを見て、
社会人の初めごろに読んだJoel on Softwareを思い出した。
エンジニアとして必要なことの大半はこの本で学んだ 気がする。
テンポよく面白いので、飽きずに読めます。良書。
MS系技術が好きになったきっかけも、この本だったかもしれない。

Azure IoT Hub デバイス ストリーム
PublicPreview中なので、使ってみてフィードバックしましょう。
いろんな使い道がありそうな機能なので、今後の動向を要チェックです。

参考

Microsoft Docs | IoT Hub デバイス ストリーム (プレビュー)
Microsoft Docs | クイック スタート:C# プロキシ アプリケーションを使用した IoT Hub デバイス ストリーム経由の SSH または RDP (プレビュー)

  1. https://docs.microsoft.com/ja-jp/azure/iot-hub/iot-hub-device-streams-overview#overview ↩

  2. https://docs.microsoft.com/ja-jp/azure/iot-hub/iot-hub-device-streams-overview#device-stream-creation-flow ↩

6
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?