Azure IoT Hubのススメ ～デバイス管理編～

2017/8/26
IoTに限らず遠隔地にあるクライアント（デバイス）を管理することは大変です。本セッションでは実戦で想定されるシナリオに対しIoT Hubに備わる管理機能でどう対応するか等を実務経験を踏まえながら解説します。

Transcript

1. Azure IoT Hubのススメ ～デバイス管理編～ ２０１７/８/２６
2.     
3. 本日のお題 IoTに限らず遠隔地にあるクライアント（デバイス）を管理する ことは大変です。  障害が発生したからといって簡単には行けない。（僻地だからこその遠 隔操作機能）  同時多発テロ的に障害が発生した場合、保守員がいくらいても足りない。 本セッションでは実戦で想定されるシナリオに対し IoT Hubに備わる機能でどう対応するか等を 実務経験を踏まえながら解説します。
4. 管理面での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。
5. おさらい（よく出る用語集）  デバイス  IoT Hubに接続するPC的なもの（なんでもいい）  サービス  バックエンドの管理などのこと  C2D  Cloud To Device の略  D2C  Device To Cloud の略  IDレジストリ  デバイスの識別情報を保管しておくところ  デバイスツイン  デバイス管理用のプロパティ
6. AZUREのドキュメントを読む際の注意点  日本語訳ページを読むと原文とニュアンスが違うので注意すること！！！  日本人の感覚からするとIdentityをIDと略されちゃうと別物に感じる。  個人的な意訳としては「識別情報の登録先（保管先）」ですかね。  なるべく原文を読みましょう！
7. 管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。
8. 該当する機能は大きく分けて二つ  デバイスの状態情報を操作する。（日本語訳がこうなので。。。）  デバイスIDを指定する。（１台分だけ）  デバイスIDを指定しない。（1000台まで取得可能） 条件指定は出来ない為、1001台目以降は一覧取得できない。。。 ⇒SDKの仕様ではなくIoT Hubの仕様。（意味不明）  認証関連もここに含まれる。  デバイスツイン（JSON型）にCRUD操作とクエリ発行が可能。  クエリも投げられる。  メタデータはいじれない。  上記の状態情報とは別物。（わかりにくい）  違いがわかりにくい。
9. デバイスの状態情報とやらを覗いてみる  デバイス取得用メソッド クライアントのソケット開閉状態で ConnectedとDisconnectedが リアルタイムで切り替わるので便利。 Azureのドキュメントには 開発時以外は参照しないでと書いてあります。 理由はこのクラスにはクエリが実行できないから。  デバイスクラス 1000まで！ ページングも無い メモ的に自由な文字列が保存できる。 例）撤去のため停止、など Disableにするとデバイスが持つ認証情報が 有効であってもコネクションが張れなくなる。
10. デバイスツインとは  簡易DocumentDBのようなもの。  JSON型  XML DBと比べて軽くてクエリがシンプル。  xpathとかxqueryとか面倒だった。。。  デバイス側、サービス側とで権限などが異なる。  どこがどう違うのかをしっかり理解して設計する必要がある。  JSON配列は保存できない。  どうしてもやりたければサイズ制限内でうまくやるしかない。  楽観的実行制御を使用。  デバイスから見たとき、競合相手がいないので意識することはないが サービス側は複数人が触る可能性があるため注意が必要。
11. デバイスツインの構成 デバイスからは見えない  変更通知機能がある。
12. JSONのサンプル Tags Desired Reported
13. 各項目の使い方とか •その名の通り、一般的な「タグ」の解釈で良い。 •階層化も可能。 •デバイスからは見えない為、デバイスに必要となる情報はここに入れない。 •デバイスへの変更通知も無いため、好きなタイミングで変更できる。 Tags •サービスがデバイスの構成を同期するため使用する。 例）送信間隔：5分など •デバイスからは読み取り専用な為、安全。 •プロパティの変更はリアルタイムで通知される。（イベントが発火する） Desired •デバイスがサービスと状態を同期するために使用する。 例）”起動時刻”：”HH:mm:ss”, ”アップデート”：”ダウンロード済み” •プロパティの変更はリアルタイムで通知される。（イベントが発火する） •サービス側ではクエリを発行し状態を確認する。 例）SELECT * FROM DEVICES WHERE properties.reported.updateStatus = ‘downloaded’ Reported
14. クエリの基本  FROM句は「devices」固定。  オブジェクト型なのでSELECT句、WHERE句ともに「◦◦. ◦◦ 」と書く。 SELECT tags.location.region FROM devices WHERE tags.location.plant = ‘Redmond43’  AS,IN,GROUP BY も使える。  関数もある。 一般的な集計関数（sum,maxなど）、文字列操作（CONCAT,SUBSTRING） などなど
15. 管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。
16. ハートビートを送る  定期的にD2Cメッセージを送信する。  流れとしては、タイマー作成⇒イベント発火⇒メッセージ送信 ※タイマー省略 そもそもデータの送信間隔が短い（1分以内とか）場合はサービス側でメッセージを飛ばし てないデバイスを抽出するのもよい。 JSONシリアライズ 匿名型である必要はない SDKのイケてないとこ…
17. Reported Propertyをハートビートの代用にする  メッセージの場合、捌きと解析が必要になる。  StreamAnalyticsは高いしロジック作りこむのも面倒。  Reported Propertyの場合ならクエリ投げるだけで確認出来る。  パターンとしてタイマーで更新、何か実行するたびに更新が考えられる。 ※中略  過去１０分以内の更新を検索する場合
18. 管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。
19. デバイスへの通知は3パターン  C2Dメッセージを送信する。  受信側はメッセージを解析して何か処理を行う。  メッセージをいつ受信して、いつ実行するかはわからない。（非同期）  受信完了通知があるため、未受信、受信したが失敗、などが検知可能。  Desired Propertyを更新する。  こいつの基本用途はConfigのため、候補外。  ダイレクトメソッドを使う。  デバイス側に予めメソッドを実装しておく必要がある。  サービス側はメソッド名を引数に実行する為、名前を知っておく必要がある。  デバイス側でコネクションが生きていれば即座に実行される。（同期）  裏を返せばネットワーク断、電源断だと受信すらされない。  なんらかの問題が発生した場合、すぐにわかる。
20. C2Dメッセージのサンプル  送信側  受信側
21. ダイレクトメソッドのサンプル  デバイス側  ダイレクトメソッドの引数、戻り値は固定  ダイレクトメソッドを登録
22. ダイレクトメソッドのサンプル  サービス側  注意点  デバイスからの戻り値（JSON）には2000バイトまでの制限がある。
23. ダイレクトメソッドのおまけ  デバイスクライアントをWindowsServiceで実装する。  実行ユーザーをLocalSystemにし、sc createする。  コマンドプロンプトを実行するダイレクトメソッドを実装する。  これで大概のことが出来るｗ
24. 管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。
25. ジョブ機能を使う 実行日時をしていしてダイレクトメソッド、ツインの更新、デ バイス全体のexport/importが可能。 クエリを使用して対象デバイスを絞ることも可能。 Freeプランの場合は１つまでしか作れない。  ジョブが終わるまでは次が作成出来ない。 過去のジョブが閲覧可能（期限はある）なため、 定期的に保存しておけば監査ログにもなる。  普通にダイレクトメソッドを呼ぶよりもジョブのほうが 運用面を考えると適している。
26. 管理視点での主なユースケース 一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 稼働状況を知りたい。 遠隔操作をしたい。 定期または定時などでデバイスへ指示を送りたい。 クライアントアプリをアップデートしたい。
27. アプリのアップデート Azureドキュメントの目次を見るとファームアップデートとあるが 機能としては用意されていない。 いろんなものの合わせ技で実現する。  アップデート用のダイレクトメソッドを実装しておく。  Blobへファイルをアップロードする。  このファイルのSAS（Shared Access Signatures）を作成する。  ダイレクトメソッドの引数にSASを渡し、実行する。  アップデートに時間がかかる場合は戻り値を先に返しておき、 状況はReported Propertyを逐次更新する。 Download開始 ⇒ Download終了 ⇒ Update開始 ⇒ Update終了
28. おまけ  Blobへのファイルアップロードが簡単。  デバイス側のConfigにBlobのURLやKeyを持つ必要がない。  Azure側でIot HubとBlobコンテナの紐づけをしておくだけ。  binフォルダ覗かれても安心。  以下のようなケースで使う。  1回のメッセージサイズの制限に引っ掛かり普通のメッセージでは送れない。  ダイレクトメソッドの戻り値も同様。  1日に受信するメッセージが多すぎてお金がかかりすぎる。  データをファイルへまとめて保存し、アップロードする。  但し、リアルタイムに必要のないデータに限る。
29. まとめ  一覧画面などで見たい。  属性を付与して管理したい。  マスタ的なもの。（住所や所属に関する情報など）  属性値でフィルタリングして画面に表示。 ⇒デバイスツイン  稼働状況を知りたい。 ⇒ハートビート、Reported Property  遠隔操作をしたい。 ⇒ダイレクトメソッド、C2Dメッセージ  定期または定時などでデバイスへ指示を送りたい。 ⇒JOBスケジューラ  クライアントアプリをアップデートしたい。 ⇒ダイレクトメソッド、 Reported Property等の合わせ技
30. 最後に  前回までのセッションを踏まえてIoT Hub単体の使い方は以上になります。  ここから先はデータの蓄積、分析、ML、AI、BI等に広がっていきます。  IoTをソリューションとして見たとき、ゴールはまだ先にある。  IoT Hubは安価で手軽に双方向通信基盤が作れるため、所謂IoT以外のシー ンでも是非活用していただければと思います。