「Azure × IoTプラットフォーム」 事始め④

皆さん、こんにちは！
前回から少し間が空いてしまいましたが、「Azure × IoT プラットフォーム」 事始めシリーズもいよいよ最終回となります。最後も 湯下 が担当させて頂きますので、どうぞよろしくお願いします！

前回は、Azure で提供されている IoT プラットフォーム向けのサービスを1つ1つご紹介しましたが、より具体的なイメージを持って頂くために、今回はそれらを組み合わせた構成例をお伝えします。
また、弊社で開発したデモをムービー形式でご紹介しつつ、本シリーズのまとめをしたいと思います。

構成例 [1]　とりあえずデータを集めたい

PoC（概念検証）フェーズでたまにあるパターンですが、デバイス側で取得したデータを「とりあえずクラウドに集めたい」場合は、下記のように IaaS の「仮想マシン」を使う方法があります。

この構成では、デバイスからのセンサーデータを HTTP/S で受信できるよう、フロントエンドに Web API を稼働させ、データ格納用にバックエンドで RDB を稼働させています。
ある意味「古典的」な方法ですが、これまでご紹介してきた IoT 向けの PaaS サービスの知識が無くても、基本的な開発・DB の知識があれば、比較的容易に構築できる点がメリットです。

ただし、この方法はあくまで PoC・プロトタイプ向けのシステム構成で、本格的に稼働させようとすると、例えば下記の点が課題となります。

課題

1. データ増加時やスキーマ（データ構造）変更時の拡張性
2. デバイス増加時のシステムパフォーマンス
3. 機能追加/変更における依存性・柔軟性
4. デバイス接続におけるセキュリティ
5. プラットフォームの可用性
6. プラットフォームの構築・運用管理コスト

具体的には、以下のような懸念点と対応策が考えられます。

懸念点

1. デバイスから受信したセンサーデータを、RDB データファイルの形で仮想マシンディスク内に格納しているため、データ格納容量やディスク I/O の観点で拡張性が低い。また、データ構造が変更された際のスキーマ拡張・変更が煩雑になりやすい。
2. HTTP/S はプロトコル仕様的にデータ送受信時のオーバーヘッドが大きく、デバイス数やコネクション数に対するシステムパフォーマンスが低め。
3. フロントエンドでデータ受信・加工・表示を行う処理を一括で実装している場合、コンポーネント間の依存性が高く、機能追加/変更時の柔軟性が低い。
4. デバイスがフロントエンドに接続する際のアクセス制御（接続、権限等）を、独自に実装・管理する必要がある。
5. フロントエンドもバックエンドもそれぞれ1台の仮想マシンで構成しているため、データセンター側でメンテナンス等が発生した際に、システムのダウンタイムが長くなりやすい。
6. PaaS と比べて、IaaS は OS/ミドルウェアに関する各種作業（インストール、設定、メンテナンス等）が必要となるため、構築・運用管理コストが大きくなりやすい。

対応策

1. 容量拡張が容易でスキーマ依存性が低い PaaS サービス（KVS 型やドキュメント型の NoSQL 等）を利用する。
2. HTTP/S よりもオーバーヘッドの少ないプロトコルを利用する。（AMQP/S、MQTT/S 等）
3. 処理毎に利用するサービスを分割し、コンポーネント同士を疎結合にする。
4. デバイス接続におけるセキュリティ機能が標準で提供されている「Event Hubs」や「Azure IoT Hub」を利用する。
5. 標準で冗長構成となっている PaaS を利用する。もしくは、仮想マシンを冗長化する。（RDB はアプリケーションレベルで冗長化し、トランザクションデータに不整合が発生しないようにする）
6. PaaS を利用する。

特に対応策について、以下で具体的に説明していきます。

構成例 [2]　ちゃんとデータを集めたい

構成例[1]では、仮想マシンベースでとりあえずデータを集めるシステム構成としましたが、実際に本格的に稼働させようとすると、下記のように PaaS の活用がキモになってきます。

この構成で使用しているサービスは、あくまで一例で、いつでも使えるとは限らないですが、それぞれ次の意図があって選択しています。

まず、システム全体として、処理毎に利用するサービスを分割しており、コンポーネント同士の結合度を下げることで、いわゆる「疎結合」なシステム構成にしています。
また、プラットフォームの可用性を高めつつ、運用管理コストを抑えるために、IaaS は一切使用せず、PaaS のみで構成しています。
※もちろん、実装方式や利用したいランタイム等によっては、IaaS を利用し、その上で冗長構成とする場合もあります。

格納するデータの構造や形式にも依りますが、ここでは KVS の「Table Storage」を利用し、センサーデータを格納しています。
こうすることで、ディスク追加無しで最大500TB まで非構造化・半構造化データを格納することが可能です。また、「Table Storage」のパーティション分割により、ディスク I/O の負荷を分散させることが出来ます。
ただ、全てのデータを無理に KVS のデータフォーマットで格納する必要は無いため、例えばスキーマが変更されにくいデバイス管理情報（デバイス固有 ID やファームウェアバージョン等）は、「SQL Database」のような RDB に格納するのもアリだと思います。

また、データ受信の受け口として「Event Hubs」を利用していますが、デバイスと Event Hubs 間の通信プロトコルは、HTTP/S よりも軽量な AMQP/S を利用しています。
その結果、デバイス数が数百、数千規模に増加しても、HTTP/S を利用した場合よりもオーバーヘッドが少なく、大量のセンサーデータを効率的に処理することが出来ます。

ちなみに、「Event Hubs」では、「SAS キー」と「トークン」という仕組みでデバイスの認証を行い、デバイス毎もしくは全てのデバイスで共有されるトークン（SAS キーから生成）を利用します。
そのため、標準で提供される上記の仕組みにより、ユーザは1から開発することなく、容易にデバイスのアクセス制御を実装出来ます。
なお、「Event Hubs」の認証の概要については、以下の URL をご覧頂ければと思います。

構成例 [3]　デバイスの制御もしたい

構成例[1]と[2]では、クラウド側からのデバイス制御（フィードバック、設定管理、ソフトウェアアップデート等）は考慮していませんでした。
そのため、構成例[3]では「Azure IoT Hub」を利用することで、デバイスからクラウド（Device to Cloud：D2C）への通信だけでなく、クラウドからデバイス（Cloud to Device：C2D）への通信も可能とし、各種のデバイス制御を実現します。
なお、「Event Hubs」を利用した構成例[2]でも C2D 通信は可能ですが、そもそも「Event Hubs」がデータ受信を指向したサービスのため、C2D 通信をするためには追加の実装が必要となります。

また、「Azure IoT Hub」では、「Event Hubs」よりも細やかなアクセス制御（デバイス毎の権限管理やキー管理）が可能です。
そのため、例えば、不要となったデバイスを個別に接続不可としたい場合は、「Web Apps」上に Azure IoT Hub SDK を組み込んだ独自の Web アプリケーションを開発することで実現出来ます。

ちなみに、「Azure IoT Hub」を使った場合のデバイスの死活監視は、

（1） 「デバイス ID レジストリ」の「connectionState」フィールド値の参照
（2） デバイスから一定間隔で D2C メッセージを送信
（3） 「操作の監視」機能でデバイス状態を追跡

といった方法がありますが、（1）は開発・検証目的にとどめ、運用環境では（2）もしくは（3）により実装することが推奨されています。

構成例 [4]　データ分析もしたい

最後に、収集したデータを分析する構成例をご紹介します。
データ分析の手法やツールは様々ありますが、ここでは無償ツールの「Power BI Desktop」を利用しています。
「Power BI Desktop」のデータソースとして、センサーデータが格納された「Table Storage」を指定することで、収集したデータを取り込み、簡単に可視化することが出来ます。

なお、今回は「Stream Analytics」で処理したデータを「Table Storage」に送信していますが、直接「Power BI」のストレージ領域に送信することも可能です。
そのため、「Power BI」の Web インターフェイス上でリアルタイムに可視化でき、簡易的な状態監視ダッシュボードを作ることも出来ます。

また、機械学習サービスの「Azure Machine Learning」では、データソースとして「Table Storage」を指定できるため、例えば、収集しているセンサーデータの傾向から、異常発生を事前予測することも可能です。
さらに、構築した機械学習モデルを REST API 形式で外部公開する機能もあるため、外部システムから接続し、予測データを利用したリッチな IoT システムを作ることも出来ます。

その他

以上、4つのシステム構成例をご紹介しましたが、より詳細な情報（特に、デバイス層/処理層/プレゼンテーション層におけるコンポーネントの配置やデータフロー等）を知りたい方は、「Microsoft Azure IoT Reference Architecture」（英語）がオススメです。

また、開発者向けですが、下記ドキュメントの「Azure IoT 開発者ガイド」（日本語）には、設計や実装に役立つ情報が詳細にまとめられています。

ところで、「Azure で IoT」というと、個々のサービスよりも、むしろ「Azure IoT Suite」をご存知な方が多いかもしれません。

「Azure IoT Suite」は、Microsoft 社が前稿でご紹介したような Azure サービスを組み合わせて、事前構成したリモート監視/メンテナンスソリューション（スイート）です。
ほんのわずかの操作で必要なサービスが構成され、リッチなデバイス管理ポータルが10分～20分程度でデプロイされます。
実際のハードウェアのデバイスだけでなく、ソフトウェア実装のシミュレートデバイスも登録/管理できるため、「AzureでIoT」の利用イメージが掴めていない方は、是非ともお試し頂ければと思います。
なお、リモート監視ソリューションについては、Microsoft 社より自習書が出ているので、こちらも合わせてご覧下さい。

デモムービー「顔認証型ドア開閉システム」

最後に、弊社でプロトタイプ開発した「顔認証型ドア開閉システム」のデモムービーをご紹介します。

ルネサスエレクトロニクス社製の mbed 対応ボード「GR-PEACH」とカメラシールド、CMOS カメラを組み合わせたデバイスで、認証したいユーザの顔を撮影し、その写真と事前登録した写真を「Cognitive Services」の「Face API」で照合します。
「Face API」で本人認証（顔の特徴点から同一人物かどうかを判定）が出来た場合のみ、「Azure IoT Hub」経由でサーボモーター付きの開錠用デバイスにコマンドを送信し、鍵を開錠するという仕組みになります。
文字だけだと全体像が少しイメージし難いかと思いますので、以下のムービーを是非ともご覧頂ければと思います！

最後に

4回に分けてお届けした本シリーズですが、IoT プラットフォームで必要なコンポーネントや Azure のサービス、システム構成イメージは、何となくでもご理解頂けたでしょうか？
もちろん、より具体的な設計や開発を進めていくには、深い知識と経験が要求されますが、まずは

・IoT プラットフォームを構成するコンポーネントとサービスを概観すること
・各々のサービスで何が出来て、それらをどう組み合わせれば良いかをイメージすること

が重要だと考え、このテーマで投稿させて頂きました。

次回以降は、実際の構築や開発に役立つような情報を、キャプチャやサンプルコードを合わせながら、個々のテーマで投稿していきたいと思いますので、どうぞよろしくお願いします！(‘∀‘)

• データは理解してこそ価値を生む

どうぞお楽しみに！(*'▽')