Azure Iot Edge Shallow Dive

98c875db019d655ad0bda12a32cf0d10?s=47 motoriderse
February 06, 2018

Azure Iot Edge Shallow Dive

2018/1/27
クラウドコンピューティングにより従来では考えられない速度でデジタルトランスフォーメーションが進んでいます。 そんな中インフラはクラウドへの集約からエッジコンピューティングによる分散処理へ向かうと予測されています。 本セッションではインフラとアーキ寄りにAzure IoT Edgeを解説したいと思います。

98c875db019d655ad0bda12a32cf0d10?s=128

motoriderse

February 06, 2018
Tweet

Transcript

  1. Azure IoT Edge Shallow Dive 2018/1/27

  2.     

  3. Azure IoT Edgeとは これまでクラウドで行っていた分析やビジネスロジックをデバ イスで行えるようにするもの。  Edge Computingと呼ばれる なぜ必要なのか? 

    緊急時は速やかに対処したい。  帯域幅の確保や通信コストの懸念。  データや処理の増大によりクラウド環境がスケールしすぎて費用がばか にならない。 ※現在プレビューの為、本セッションの内容は2018/1/27時点のものとなり 今後仕様が変わる可能性があります。
  4. Azure IoT Edgeとは これまでクラウドで行っていた分析やビジネスロジックをデバ イスで行えるようにするもの。  Edge Computingと呼ばれる なぜ必要なのか? 

    緊急時は速やかに対処したい  帯域幅の確保や通信コストの懸念  データや処理の増大によりクラウド環境がスケールしすぎて費用がばか にならない
  5. Computingの変遷 Centralized Distributed Cloud Edge

  6. Computingの変遷 Centralized Distributed Cloud Edge

  7. Computingの変遷 Centralized Distributed Cloud Edge

  8. Computingの変遷 Centralized Distributed Cloud Edge 進んでいるようで戻っている

  9. Cloud Computing から Edge Computing へ  Cloud Computingにおける課題 

    端末からクラウドまでの通信経路(携帯電話網⇒インターネット⇒DC)がある為、ネッ トワークによる遅延が発生しうる。  ユーザーが増えれば増えるほどコストが上がる。  解決策  ネットワーク遅延を最小限にするようになるべく近い場所のサーバーで処理させ遅延 を最小化。  携帯の基地局にサーバーを設置?(ほんとにあるかどうか知りません)  なるべく近いDCへリクエスト。  東京のユーザーなら東日本リージョンのDCへ。(効果薄)  なるべく意味の無いデータはクラウドまで上げないことでコストダウン。  フィルタリングやサマライズ ⇒ Edge Computing
  10. Azure IoT Edgeとは これまでクラウドで行っていた分析やビジネスロジックをデバ イスで行えるようにするもの。  Edge Computingと呼ばれる なぜ必要なのか? 

    緊急時は速やかに対処したい  帯域幅の確保や通信コストの懸念  データや処理の増大によりクラウド環境がスケールしすぎて費用がばか にならない
  11. 例えば Connected Car

  12. 例えば Connected Car Stop! 通信してたら間に合わない…

  13. Edge で処理

  14. Edge で処理 Stop!

  15. Edge で処理 Stop! その場で判断 ログとかは後でもいい Logとか

  16. Azure IoT Edgeとは これまでクラウドで行っていた分析やビジネスロジックをデバ イスで行えるようにするもの。  Edge Computingと呼ばれる なぜ必要なのか? 

    緊急時は速やかに対処したい  帯域幅の確保や通信コストの懸念  データや処理の増大によりクラウド環境がスケールしすぎて費用がばか にならない
  17. 例えば 画像解析システム ・・・

  18. 例えば 画像解析システム ・・・

  19. 例えば 画像解析システム ・・・ リソース食い過ぎ

  20. 例えば 画像解析システム ・・・ リソース食い過ぎ 通信コスト高すぎ

  21. Edgeで処理 ・・・

  22. Edgeで処理 ・・・

  23. Edgeで処理 ・・・

  24. Edgeで処理 ・・・ クラウド側で意味のあるデータだけを送信

  25. Edge Computingの事例 IoTのシナリオだけとは限りません SOMPOホールディングス  深層学習はクラウドより自社構築が安い http://itpro.nikkeibp.co.jp/atcl/column/17/090600369/090600005/ トライアルホールディングス エッジで店内動画を分析 http://itpro.nikkeibp.co.jp/atcl/column/17/090600369/090600004/

    激しいサービス競争 http://itpro.nikkeibp.co.jp/atcl/column/17/090600369/090600003/?SS=imgview&FD=54139247
  26. ここから本題

  27. Azure IoT Edgeの構成 IoT Edge モジュール  Azure のサービス、サード パーティのサービス、またはカスタム

    コー ドを実行するコンテナー(Docker)。 Edge デバイスにデプロイし、 ローカルで実行。 IoT Edge ランタイム  個々のEdge デバイス上で動作し、各デバイスにデプロイされたモ ジュールを管理。 クラウドベースのインターフェイス  IoT Edge デバイスをリモートから監視して管理。
  28. Azure IoT Edgeの構成(将来含む) Edge Device Module Twin Device Twin Container

    Local Storage Module Twin Module Twin Module Twin Module Twin Container Management Functions Runtime Device Twin Azure IoT Edge Module Twin 拡張予定? 加工して送信
  29. Azure IoT Edgeの構成 IoT Edge モジュール  Azure のサービス、サード パーティのサービス、またはカスタム

    コー ドを実行するコンテナー(Docker)。 Edge デバイスにデプロイし、 ローカルで実行。 IoT Edge ランタイム  個々のEdge デバイス上で動作し、各デバイスにデプロイされたモ ジュールを管理。 クラウドベースのインターフェイス  IoT Edge デバイスをリモートから監視して管理。
  30. IoT Edgeモジュール  ビジネス ロジックをモジュール形式でEdgeに展開し管理します。  モジュールは管理の最小単位でStream AnalyticsなどのAzureのサービス、独自 のカスタムコードになります。 

    モジュールは4つの概念で構成されます。  イメージ  ソフトウェアを含むパッケージのこと。(コンテナイメージ)  カスタムコードを実装した際はビルド⇒イメージ化⇒デプロイとなる。  インスタンス  Edgeデバイス上での実行単位。ランタイムによって開始される。  モジュールID  IoT Hubに格納されている情報の一部で、各インスタンスの紐づけに利用される。  モジュールツイン(後述)  IoT Hub に格納されているJSONドキュメントで、メタデータ、構成、条件、インス タンスの状態等の情報が含まれています。
  31. モジュールツインとは  デバイスツインに紐づくモジュールのメタデータ等。  簡易DocumentDBのようなもの。  JSON型  クエリがSQLライクでシンプル。 

    デバイス側、サービス側とで権限などが異なる。  どこがどう違うのかをしっかり理解して設計する必要がある。  JSON配列は保存できない。  どうしてもやりたければサイズ制限内でうまくやるしかない。  楽観的実行制御を使用。  デバイスから見たとき、競合相手がいないので意識することはないが サービス側は複数人が触る可能性があるため注意が必要。 Device Twin Module Twin Module Twin Module Twin
  32. デバイスツインの構成 デバイスからは見えない  変更通知機能がある。

  33. JSONのサンプル Tags Desired Reported DevieID

  34. 各項目の使い方とか •その名の通り、一般的な「タグ」の解釈で良い。 •階層化も可能。 •デバイスからは見えない為、デバイスに必要となる情報はここに入れない。 •デバイスへの変更通知も無いため、好きなタイミングで変更できる。 Tags •サービスがデバイスの構成を同期するため使用する。 例)送信間隔:5分など •デバイスからは読み取り専用な為、安全。 •プロパティの変更はリアルタイムで通知される。(イベントが発火する)

    Desired •デバイスがサービスと状態を同期するために使用する。 例)”起動時刻”:”HH:mm:ss”, ”アップデート”:”ダウンロード済み” •プロパティの変更はリアルタイムで通知される。(イベントが発火する) •サービス側ではクエリを発行し状態を確認する。 例)SELECT * FROM DEVICES WHERE properties.reported.updateStatus = ‘downloaded’ Reported
  35. クエリの基本  FROM句は「devices」固定。  オブジェクト型なのでSELECT句、WHERE句ともに「◦◦. ◦◦ 」と書く。 SELECT tags.location.region FROM

    devices WHERE tags.location.plant = ‘Redmond43’  AS,IN,GROUP BY も使える。  関数もある。 一般的な集計関数(sum,maxなど)、文字列操作(CONCAT,SUBSTRING) などなど
  36. Azure IoT Edgeの構成 IoT Edge モジュール  Azure のサービス、サード パーティのサービス、またはカスタム

    コー ドを実行するコンテナー(Docker)。 Edge デバイスにデプロイし、 ローカルで実行。 IoT Edge ランタイム  個々のEdge デバイス上で動作し、各デバイスにデプロイされたモ ジュールを管理。 クラウドベースのインターフェイス  IoT Edge デバイスをリモートから監視して管理。
  37. IoT Edgeランタイムとは 2つの役割に分けられる。 IoT Edge hub  IoT Hubへ接続する為のローカルプロキシ。 

    モジュールまたはリーフデバイスなどのクライアントからの論理 接続数を取得し1つの物理接続へ統合することでクラウドへの実 際の接続数を最適化している。  クライアントからすると独自に接続していると認識する。 IoT Edge agent  モジュールのインスタンス化、実行、クラウドへステータスを報 告。
  38. IoT Edgeランタイムとは 2つの役割に分けられる。 IoT Edge hub  IoT Hubへ接続する為のローカルプロキシ。 

    モジュールまたはリーフデバイスなどのクライアントからの論理 接続数を取得し1つの物理接続へ統合することでクラウドへの実 際の接続数を最適化している。  クライアントからすると独自に接続していると認識する。 IoT Edge agent  モジュールのインスタンス化、実行、クラウドへステータスを報 告。
  39. IoT Edge hubのアーキテクチャ  IoT Edge hub は Message Broker

     ModuleはMessage Brokerを通じたPub/Subメッセージングモデル Edge Device Module Twin Device Twin IoT Edge hub (Message Broker) Azure IoT Edge Module A Module Twin Publisher Subscriber Module B Module Twin Publisher Subscriber
  40. IoT Edgeランタイムとは 2つの役割に分けられる。 IoT Edge hub  IoT Hubへ接続する為のローカルプロキシ。 

    モジュールまたはリーフデバイスなどのクライアントからの論理 接続数を取得し1つの物理接続へ統合することでクラウドへの実 際の接続数を最適化している。  クライアントからすると独自に接続していると認識する。 IoT Edge agent  モジュールのインスタンス化、実行、クラウドへステータスを報 告。
  41. IoT Edgeランタイムとは 2つの役割に分けられる。 IoT Edge hub  IoT Hubへ接続する為のローカルプロキシ。 

    モジュールまたはリーフデバイスなどのクライアントからの論理 接続数を取得し1つの物理接続へ統合することでクラウドへの実 際の接続数を最適化している。  クライアントからすると独自に接続していると認識する。 IoT Edge agent  モジュールのインスタンス化、実行、クラウドへステータスを報 告。 本日は割愛
  42. デモ デプロイしてみる

  43. IoT Edge のデプロイ前提条件 Windows編  以下のOSバージョンであること  Windows 10 Fall

    Creators Update  Windows Server 1709 (ビルド 16299)  x64 ベース デバイス上の Windows IoT Core (ビルド 16299)  仮想マシンで試す場合は以下を満たすこと  ExposeVirtualizationExtensions をtrueに  メモリは2GB以上  DockerとPython2.7をインストールしてpipコマンドをつかえるよう にしておく
  44. Pythonが上手く動かない時  Path(環境変数)が通ってない  ¥Python¥Python27  ¥Python¥Python27¥Scripts  ルートフォルダはあなた次第 

    pipがインストールされてない  https://bootstrap.pypa.io/get-pip.py よりget-pip.pyを任意のディレクトリに保存  保存したディレクトリで下記コマンドを実行  python get-pip.py  下記コマンドを実行しインストールされたか確認  pip –V  pypiwin32のバージョンを確認  219だとうまくいく
  45. IoT Edge のデプロイ Windows編  IoT Edge 制御スクリプトをダウンロード  pip

    install -U azure-iot-edge-runtime-ctl  IoT Edge デバイスを登録  ポータルからポチポチ  接続文字列をコピーしておく  ランタイムを構成  iotedgectl setup --connection-string "{接続文字列}" --auto-cert-gen-force-no- passwords  ランタイムを開始  iotedgectl start  実行確認  docker ps  ポータルから疎通確認できる
  46. 参考リンク http://itpro.nikkeibp.co.jp/atcl/column/17/090600369/090600005/ http://itpro.nikkeibp.co.jp/atcl/column/17/090600369/090600004/ http://itpro.nikkeibp.co.jp/atcl/column/17/090600369/090600003/?SS=imgview&FD=54139247 https://github.com/Azure/iot-edge https://github.com/Azure/iot-edge/blob/master/v1/samples/ble_gateway/iot-hub-iot-edge- physical-device.md https://github.com/Azure/iot-edge-modbus https://www.softbanktech.jp/service/list/ms-azure_blog/ms-azure_blog_0019/ https://www.softbanktech.jp/service/list/ms-azure_blog/ms-azure_blog_0020/

    https://azure.microsoft.com/ja-jp/services/iot-edge/ https://docs.microsoft.com/ja-jp/azure/iot-edge/