Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Azure Iot Edge Shallow Dive

motoriderse
February 06, 2018

Azure Iot Edge Shallow Dive

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

motoriderse

February 06, 2018
Tweet

More Decks by motoriderse

Other Decks in Programming

Transcript

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

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

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

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

    緊急時は速やかに対処したい  帯域幅の確保や通信コストの懸念  データや処理の増大によりクラウド環境がスケールしすぎて費用がばか にならない
  5. Azure IoT Edgeとは これまでクラウドで行っていた分析やビジネスロジックをデバ イスで行えるようにするもの。  Edge Computingと呼ばれる なぜ必要なのか? 

    緊急時は速やかに対処したい  帯域幅の確保や通信コストの懸念  データや処理の増大によりクラウド環境がスケールしすぎて費用がばか にならない
  6. Azure IoT Edgeの構成 IoT Edge モジュール  Azure のサービス、サード パーティのサービス、またはカスタム

    コー ドを実行するコンテナー(Docker)。 Edge デバイスにデプロイし、 ローカルで実行。 IoT Edge ランタイム  個々のEdge デバイス上で動作し、各デバイスにデプロイされたモ ジュールを管理。 クラウドベースのインターフェイス  IoT Edge デバイスをリモートから監視して管理。
  7. 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 拡張予定? 加工して送信
  8. Azure IoT Edgeの構成 IoT Edge モジュール  Azure のサービス、サード パーティのサービス、またはカスタム

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

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

    デバイス側、サービス側とで権限などが異なる。  どこがどう違うのかをしっかり理解して設計する必要がある。  JSON配列は保存できない。  どうしてもやりたければサイズ制限内でうまくやるしかない。  楽観的実行制御を使用。  デバイスから見たとき、競合相手がいないので意識することはないが サービス側は複数人が触る可能性があるため注意が必要。 Device Twin Module Twin Module Twin Module Twin
  11. 各項目の使い方とか •その名の通り、一般的な「タグ」の解釈で良い。 •階層化も可能。 •デバイスからは見えない為、デバイスに必要となる情報はここに入れない。 •デバイスへの変更通知も無いため、好きなタイミングで変更できる。 Tags •サービスがデバイスの構成を同期するため使用する。 例)送信間隔:5分など •デバイスからは読み取り専用な為、安全。 •プロパティの変更はリアルタイムで通知される。(イベントが発火する)

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

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

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

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

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

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

    モジュールまたはリーフデバイスなどのクライアントからの論理 接続数を取得し1つの物理接続へ統合することでクラウドへの実 際の接続数を最適化している。  クライアントからすると独自に接続していると認識する。 IoT Edge agent  モジュールのインスタンス化、実行、クラウドへステータスを報 告。 本日は割愛
  19. 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コマンドをつかえるよう にしておく
  20. 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だとうまくいく
  21. 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  ポータルから疎通確認できる