 |
|
|||||
 |
[1] IoT(Internet of Things)がそろそろ現実になってきた。
IoT(Internet of Things：「モノのインターネット」)という得体の知れない名前のものが世間で言われ始めてからはや数年、やっと目に見える形でその実態が現れてきました。
具体的には、IoT用のプロトコルやインターフェースを実装した安価なボードやIoT向けのデータメッセンジャーサービス等です。 前回のARMプロセッサの記事とも関連がありますが、今回は実際にIoTシステムを作成する前提で、そこにどういうプロトコルやサービスが必要かを考えたいと思います。
[2] IoTで使用されるプロトコルやサービスについて
比較的最近まで、多くのIoT規格ではWebAPIのモデルとしてREST(REpresentational State Transfer)というWebAPIが主流でした。 このRESTはWebプロトコルであるHTTPまたはHTTPSのメソッド[POST、GET、PUT、DELETE]をある特定のURLにリクエストするというモデルで、以下の設計原則からなっています。
(1)アドレス指定可能なURIで公開されていること
(2)インターフェース(HTTPメソッドの利用)の統一がされていること
(3)ステートレスであること
(4)処理結果がHTTPステータスコードで通知されること
(注)ステートレスとは、サーバ側が過去の状態を保持しないということです。
このRESTモデルはIoTに限らず既に身近なtwitter等で使用され、一般公開されています。 自分で作成したアプリケーションからでもtwitterに投稿したりデータを読み込んだりできるのもこのAPIがあるからです。
・twitterのREST API（API reference index）
このREST APIですが、非常に汎用性が高く扱えるデータ種も多い為、いろいろなサービスで使用されていますが、欠点もあります。 それは
・少ないデータをポツリポツリと送る場合はデータロスが多い。
・httpプロトコルは複雑で、性能の低いIoT機器には荷が重すぎる。
という点です。
このHTTPプロトコルの欠点をカバーしようと2000年頃から考案されたプロトコルがMQTTプロトコルです。
[3] MQTTプロトコルについて（IBM DeveloperWorks) Michael Yuan氏の記事から引用
（配信 2017年 8月 24日）
（以下引用）
-----------------------------------------------------------------------------------------------
モノのインターネット (IoT) デバイスでは、インターネットに接続することが要件となります。 IoT デバイスはインターネットに接続することで、他のデバイスやバックエンド・サービスと通信するからです。 インターネットの基礎となっているネットワーク・プロトコルは TCP/IP であり、IoT 通信では TCP/IP スタックをベースに作成された MQTT (Message Queue Telemetry Transport) が標準的な通信プロトコルとなっています。
MQTT は、1990 年代後半に IBM が考案して開発したプロトコルです。 当初は油田パイプラインに取り付けられたセンサーを衛星とリンクするために使用されていました。 その名前が示唆するように、MQTT は 2 者間の非同期通信をサポートするプロトコルです。 非同期メッセージング・プロトコルは、メッセージの送信側と受信側を空間という点でも、時間という点でも切り離すため、信頼できないネットワーク環境内でスケーラブルな性質を発揮します。 一方、その名前に反して、MQTT はメッセージング・キューとはまったく関係がなく、パブリッシュ/サブスクライブ・モデルに従っています。2014 の後半になって MQTT は正式に OASIS オープン・スタンダードになりました。 現在は、よく使われているプログラミング言語で、さまざまなオープンソース実装を使用して MQTT がサポートされるようになっています。
なぜ MQTT なのか
IoT 開発者にとって、MQTT は軽量さと柔軟性の点で申し分のないバランスがとれたネットワーク・プロトコルです。
・軽量なプロトコルであるということは、制約が厳しいデバイス・ハードウェア上でも、待ち時間が長かったり帯域幅が限られていたりするネットワーク上でも実装できることを意味します。
・MQTT の柔軟性は、IoT デバイスおよびサービスの多種多様なアプリケーション・シナリオをサポートすることを可能にします。
IoT 開発者にとって、MQTT がいかに最適な選択肢であるかを理解するために、まずは、よく使われている他のネットワーク・プロトコルがなぜ IoT に向かないのかを考えましょう。
他のネットワーク・プロトコルが IoT に向かない理由
ほとんどの開発者はすでに HTTP Web サービスを十分に理解しているので、IoT デバイスを Web サービスに接続すればよいではないかと思うでしょう。 Web サービスに接続すれば、デバイスのデータを HTTP リクエストとして送信し、システムからの更新を HTTP レスポンスとして受信できます。 けれども、このリクエスト・レスポンス・パターンには重大な制約事項があります。
・HTTP は同期プロトコルです。 したがって、クライアントはサーバーからのレスポンスを待機します。 Web ブラウザーはこの要件に対応できますが、そのためにスケーラビリティーが犠牲になります。 IoT の世界では、デバイスの数が多く、通常はネットワークに信頼性がないか、待ち時間が長いことから、同期通信は問題になります。 非同期メッセージング・プロトコルのほうが IoT アプリケーションには断然適しています。 非同期通信であれば、センサーが測定値を送信して、そのデータを宛先のデバイスやサービスに配信するのに最適なパスとタイミングの判断は、ネットワークに任せることができるためです。
・HTTP は片方向です。 クライアントが接続を開始しなければなりません。 IoT アプリケーションで通常クライアントとなるのはデバイスやセンサーです。 つまり、デバイスまたはセンサーがネットワークから受動的にコマンドを受信することはできません。
・HTTP は 1 対 1 のプロトコルです。 クライアントがリクエストを送信し、サーバーがそれに応答します。 したがって、ネットワーク上のすべてのデバイスにメッセージをブロードキャストするのは困難であり、コストもかかります。 けれども、IoT アプリケーションでは、このようにメッセージをブロードキャストすることが一般的な使用ケースとなっています。
・HTTP は多数のヘッダーとルールを伴う重量級のプロトコルです。 帯域幅が限られたネットワークには適していません。
以上の理由から、ハイパフォーマンスでスケーラブルなシステムのほとんどでは、システム内のデータ交換に Web サービスではなく、非同期メッセージング・バスを採用しています。 実際、エンタープライズ・ミドルウェア・システムでは、AMQP (Advanced Message Queuing Protocol) というメッセージング・プロトコルが最もよく使われています。 けれどもこのようなハイパフォーマンス環境では、一般にコンピューティング能力とネットワーク待ち時間が問題になることはありません。 AMQP は、エンタープライズ・アプリケーションに信頼性と相互運用性をもたらすために設計されていて、充実した機能一式を備えていますが、リソースに限りがある IoT アプリケーションには向いていません。
AMQP の他にも、よく使われているメッセージング・プロトコルがあります。その一例は、XMPP (Extensible Messaging and Presence Protocol) です。 XMPP はピアツーピア・インスタント・メッセージング (IM) プロトコルであり、IM の使用ケースをサポートする機能 (プレゼンス、メディア添付など) に重点が置かれています。 MQTT と比べると、XMPP はデバイス上でもネットワーク上でも遥かに多くのリソースを必要とします。
MQTT をこれほどまでに軽量かつ柔軟なプロトコルにしているのはなぜでしょうか？ MQTT プロトコルの重要な特徴は、そのパブリッシュ・サブスクライブ・モデルです。 あらゆるメッセージング・プロトコルの例に漏れず、MQTT はデータのパブリッシュ側と取り込み側を切り離します。
----------------------------------------------------------------------------------------------------
（以上引用）
IBM(deveropersWorks)のサイトの中に手持ちのスマートフォンを利用して実際にMQTTプロトコルでIoT機器として使用できるサイトがあったので、MQTTの応用例としてリンクをあげておきます。
・スマートフォンを IoT デバイスに変身させる
[4] HTTPプロトコルのREST APIとMQTTプロトコルのシステム比較
HTTPプロトコルのREST APIを使用したIoT構成とMQTTを使用した構成例を示します。
(1) REST APIを使用したIoT構成
(2) MQTTを使用した場合の構成
どうですか、構成自体はあまり変わらないように見えますが、以下の点で違いがあります。
（「REST API」と「MQTT」の相違点）
・REST API方式は、画像ファイル等の比較的大きなデータの転送が可能だが、MQTTは大きなデータ転送には向かない。
・REST APIはHTTPまたはHTTPSプロトコルを使用する為、一度に送るデータ量が少ない場合は送信データと比較してヘッダー部等のデータロスが多い。
・REST APIはHTTPまたはHTTPSプロトコルを使用する為、Apache等のWebサーバにRESTのフレームワークを追加すればREST APIサーバを構築可能。
・REST APIをアクセスするにはCURL(カール）というHTTPプロトコルライブラリが必須ですが、処理能力の低いIoT機器では実装が重する場合がある。
・MQTTはMQTTブローカ（MQTTサーバソフト）が数種類あるので、それをインストールすれば構築可能、またMQTTクライアントソフトも処理能力の低いIoT機器でも実装可能。
・現在MQTTのブローカはリアルタイムのデータしかサポートしていない。履歴データ等の過去データ参照リクエストを実現する為にはHTTPサーバを併用しているのが現状です。
[5] まとめ
現在多くのIoT関連機器が作られ、市場に出回りつつありますが、その機器がREST APIに対応できるか、MQTTのみに対応できるかはシステム構築する際の選択肢のひとつとなります。 また、MQTT対応の機器はこれから多くなっていくでしょうが、REST APIでなくては処理不可能なIoT機器もありますので、IoT技術者には両方に対応する技術力が必要となります。 具体的にはMQTTのブローカ構築やREST APIを搭載したWebサーバの構築、それとCURLライブラリの操作とMQTTプロトコルライブラリの操作技術の習得ということになります。
IoT(Internet of Things：「モノのインターネット」)という得体の知れない名前のものが世間で言われ始めてからはや数年、やっと目に見える形でその実態が現れてきました。
具体的には、IoT用のプロトコルやインターフェースを実装した安価なボードやIoT向けのデータメッセンジャーサービス等です。 前回のARMプロセッサの記事とも関連がありますが、今回は実際にIoTシステムを作成する前提で、そこにどういうプロトコルやサービスが必要かを考えたいと思います。
[2] IoTで使用されるプロトコルやサービスについて
比較的最近まで、多くのIoT規格ではWebAPIのモデルとしてREST(REpresentational State Transfer)というWebAPIが主流でした。 このRESTはWebプロトコルであるHTTPまたはHTTPSのメソッド[POST、GET、PUT、DELETE]をある特定のURLにリクエストするというモデルで、以下の設計原則からなっています。
(1)アドレス指定可能なURIで公開されていること
(2)インターフェース(HTTPメソッドの利用)の統一がされていること
(3)ステートレスであること
(4)処理結果がHTTPステータスコードで通知されること
(注)ステートレスとは、サーバ側が過去の状態を保持しないということです。
このRESTモデルはIoTに限らず既に身近なtwitter等で使用され、一般公開されています。 自分で作成したアプリケーションからでもtwitterに投稿したりデータを読み込んだりできるのもこのAPIがあるからです。
・twitterのREST API（API reference index）
このREST APIですが、非常に汎用性が高く扱えるデータ種も多い為、いろいろなサービスで使用されていますが、欠点もあります。 それは
・少ないデータをポツリポツリと送る場合はデータロスが多い。
・httpプロトコルは複雑で、性能の低いIoT機器には荷が重すぎる。
という点です。
このHTTPプロトコルの欠点をカバーしようと2000年頃から考案されたプロトコルがMQTTプロトコルです。
[3] MQTTプロトコルについて（IBM DeveloperWorks) Michael Yuan氏の記事から引用
（配信 2017年 8月 24日）
（以下引用）
-----------------------------------------------------------------------------------------------
モノのインターネット (IoT) デバイスでは、インターネットに接続することが要件となります。 IoT デバイスはインターネットに接続することで、他のデバイスやバックエンド・サービスと通信するからです。 インターネットの基礎となっているネットワーク・プロトコルは TCP/IP であり、IoT 通信では TCP/IP スタックをベースに作成された MQTT (Message Queue Telemetry Transport) が標準的な通信プロトコルとなっています。
MQTT は、1990 年代後半に IBM が考案して開発したプロトコルです。 当初は油田パイプラインに取り付けられたセンサーを衛星とリンクするために使用されていました。 その名前が示唆するように、MQTT は 2 者間の非同期通信をサポートするプロトコルです。 非同期メッセージング・プロトコルは、メッセージの送信側と受信側を空間という点でも、時間という点でも切り離すため、信頼できないネットワーク環境内でスケーラブルな性質を発揮します。 一方、その名前に反して、MQTT はメッセージング・キューとはまったく関係がなく、パブリッシュ/サブスクライブ・モデルに従っています。2014 の後半になって MQTT は正式に OASIS オープン・スタンダードになりました。 現在は、よく使われているプログラミング言語で、さまざまなオープンソース実装を使用して MQTT がサポートされるようになっています。
なぜ MQTT なのか
IoT 開発者にとって、MQTT は軽量さと柔軟性の点で申し分のないバランスがとれたネットワーク・プロトコルです。
・軽量なプロトコルであるということは、制約が厳しいデバイス・ハードウェア上でも、待ち時間が長かったり帯域幅が限られていたりするネットワーク上でも実装できることを意味します。
・MQTT の柔軟性は、IoT デバイスおよびサービスの多種多様なアプリケーション・シナリオをサポートすることを可能にします。
IoT 開発者にとって、MQTT がいかに最適な選択肢であるかを理解するために、まずは、よく使われている他のネットワーク・プロトコルがなぜ IoT に向かないのかを考えましょう。
他のネットワーク・プロトコルが IoT に向かない理由
ほとんどの開発者はすでに HTTP Web サービスを十分に理解しているので、IoT デバイスを Web サービスに接続すればよいではないかと思うでしょう。 Web サービスに接続すれば、デバイスのデータを HTTP リクエストとして送信し、システムからの更新を HTTP レスポンスとして受信できます。 けれども、このリクエスト・レスポンス・パターンには重大な制約事項があります。
・HTTP は同期プロトコルです。 したがって、クライアントはサーバーからのレスポンスを待機します。 Web ブラウザーはこの要件に対応できますが、そのためにスケーラビリティーが犠牲になります。 IoT の世界では、デバイスの数が多く、通常はネットワークに信頼性がないか、待ち時間が長いことから、同期通信は問題になります。 非同期メッセージング・プロトコルのほうが IoT アプリケーションには断然適しています。 非同期通信であれば、センサーが測定値を送信して、そのデータを宛先のデバイスやサービスに配信するのに最適なパスとタイミングの判断は、ネットワークに任せることができるためです。
・HTTP は片方向です。 クライアントが接続を開始しなければなりません。 IoT アプリケーションで通常クライアントとなるのはデバイスやセンサーです。 つまり、デバイスまたはセンサーがネットワークから受動的にコマンドを受信することはできません。
・HTTP は 1 対 1 のプロトコルです。 クライアントがリクエストを送信し、サーバーがそれに応答します。 したがって、ネットワーク上のすべてのデバイスにメッセージをブロードキャストするのは困難であり、コストもかかります。 けれども、IoT アプリケーションでは、このようにメッセージをブロードキャストすることが一般的な使用ケースとなっています。
・HTTP は多数のヘッダーとルールを伴う重量級のプロトコルです。 帯域幅が限られたネットワークには適していません。
以上の理由から、ハイパフォーマンスでスケーラブルなシステムのほとんどでは、システム内のデータ交換に Web サービスではなく、非同期メッセージング・バスを採用しています。 実際、エンタープライズ・ミドルウェア・システムでは、AMQP (Advanced Message Queuing Protocol) というメッセージング・プロトコルが最もよく使われています。 けれどもこのようなハイパフォーマンス環境では、一般にコンピューティング能力とネットワーク待ち時間が問題になることはありません。 AMQP は、エンタープライズ・アプリケーションに信頼性と相互運用性をもたらすために設計されていて、充実した機能一式を備えていますが、リソースに限りがある IoT アプリケーションには向いていません。
AMQP の他にも、よく使われているメッセージング・プロトコルがあります。その一例は、XMPP (Extensible Messaging and Presence Protocol) です。 XMPP はピアツーピア・インスタント・メッセージング (IM) プロトコルであり、IM の使用ケースをサポートする機能 (プレゼンス、メディア添付など) に重点が置かれています。 MQTT と比べると、XMPP はデバイス上でもネットワーク上でも遥かに多くのリソースを必要とします。
MQTT をこれほどまでに軽量かつ柔軟なプロトコルにしているのはなぜでしょうか？ MQTT プロトコルの重要な特徴は、そのパブリッシュ・サブスクライブ・モデルです。 あらゆるメッセージング・プロトコルの例に漏れず、MQTT はデータのパブリッシュ側と取り込み側を切り離します。
----------------------------------------------------------------------------------------------------
（以上引用）
IBM(deveropersWorks)のサイトの中に手持ちのスマートフォンを利用して実際にMQTTプロトコルでIoT機器として使用できるサイトがあったので、MQTTの応用例としてリンクをあげておきます。
・スマートフォンを IoT デバイスに変身させる
[4] HTTPプロトコルのREST APIとMQTTプロトコルのシステム比較
HTTPプロトコルのREST APIを使用したIoT構成とMQTTを使用した構成例を示します。
(1) REST APIを使用したIoT構成
(2) MQTTを使用した場合の構成
どうですか、構成自体はあまり変わらないように見えますが、以下の点で違いがあります。
（「REST API」と「MQTT」の相違点）
・REST API方式は、画像ファイル等の比較的大きなデータの転送が可能だが、MQTTは大きなデータ転送には向かない。
・REST APIはHTTPまたはHTTPSプロトコルを使用する為、一度に送るデータ量が少ない場合は送信データと比較してヘッダー部等のデータロスが多い。
・REST APIはHTTPまたはHTTPSプロトコルを使用する為、Apache等のWebサーバにRESTのフレームワークを追加すればREST APIサーバを構築可能。
・REST APIをアクセスするにはCURL(カール）というHTTPプロトコルライブラリが必須ですが、処理能力の低いIoT機器では実装が重する場合がある。
・MQTTはMQTTブローカ（MQTTサーバソフト）が数種類あるので、それをインストールすれば構築可能、またMQTTクライアントソフトも処理能力の低いIoT機器でも実装可能。
・現在MQTTのブローカはリアルタイムのデータしかサポートしていない。履歴データ等の過去データ参照リクエストを実現する為にはHTTPサーバを併用しているのが現状です。
[5] まとめ
現在多くのIoT関連機器が作られ、市場に出回りつつありますが、その機器がREST APIに対応できるか、MQTTのみに対応できるかはシステム構築する際の選択肢のひとつとなります。 また、MQTT対応の機器はこれから多くなっていくでしょうが、REST APIでなくては処理不可能なIoT機器もありますので、IoT技術者には両方に対応する技術力が必要となります。 具体的にはMQTTのブローカ構築やREST APIを搭載したWebサーバの構築、それとCURLライブラリの操作とMQTTプロトコルライブラリの操作技術の習得ということになります。