IoT、霧、雲: テクノロジーについて話しましょう?

ソフトウェアおよびハードウェアの分野におけるテクノロジーの発展、新しい通信プロトコルの出現により、モノのインターネット (IoT) が拡大しました。 デバイスの数は日々増加しており、膨大な量のデータが生成されています。 したがって、このデータを処理、保存、送信できる便利なシステム アーキテクチャが必要です。

現在、これらの目的にはクラウド サービスが使用されています。 ただし、人気が高まっているフォグ コンピューティング パラダイム (Fog) は、IoT インフラストラクチャの拡張と最適化によってクラウド ソリューションを補完できます。

クラウドはほとんどの IoT リクエストをカバーできます。 たとえば、サービスの監視、デバイスによって生成されるあらゆる量のデータの高速処理、およびその視覚化を提供します。 フォグ コンピューティングは、リアルタイムの問題を解決する場合により効果的です。 リクエストに対する迅速な応答と、データ処理の遅延を最小限に抑えます。 つまり、Fog は「雲」を補完し、その機能を拡張します。

しかし、主な質問は異なります。IoT のコンテキストでこれらすべてがどのように相互作用するべきでしょうか? IoT、フォグ、クラウドを組み合わせたシステムで動作する場合、どの通信プロトコルが最も効果的ですか?

HTTP が明らかに優勢であるにもかかわらず、IoT、フォグ、クラウド システムでは他にも多数のソリューションが使用されています。 これは、IoT では、さまざまなデバイス センサーの機能と、セキュリティ、互換性、その他のユーザーの要件を組み合わせる必要があるためです。

しかし、リファレンス アーキテクチャと通信規格については、単一のアイデアが存在しません。 したがって、特定の IoT タスク用に新しいプロトコルを作成したり、既存のプロトコルを変更したりすることは、IT コミュニティが直面している最も重要なタスクの XNUMX つです。

現在どのようなプロトコルが使用されており、それらは何を提供できるのでしょうか? それを理解しましょう。 その前に、雲、霧、モノのインターネットが相互作用するエコシステムの原理について説明しましょう。

IoT フォグツークラウド (F2C) アーキテクチャ

おそらく、IoT、クラウド、フォグのスマートで調整された管理に関連する利点とメリットを探求することに、どれほどの労力が費やされているかに気づいているでしょう。 そうでない場合は、次の XNUMX つの標準化への取り組みを紹介します。 OpenFog コンソーシアム, エッジコンピューティングコンソーシアム и mF2C H2020 EU プロジェクト.

以前はクラウドとエンドデバイスの 2 つのレベルのみが考慮されていた場合、提案されたアーキテクチャでは新しいレベルであるフォグ コンピューティングが導入されます。 この場合、フォグ レベルは、リソースの詳細や、これらのサブレベルでのさまざまなデバイスの使用を決定する一連のポリシーに応じて、いくつかのサブレベルに分割できます。

この抽象化はどのようなものになるでしょうか? これは典型的な IoT-Fog-Cloud エコシステムです。 IoT デバイスは、低遅延が必要な問題を解決するために、より高速なサーバーやコンピューティング デバイスにデータを送信します。 同じシステム内で、クラウドは大量のコンピューティング リソースやデータ ストレージ スペースを必要とする問題を解決する責任を負います。

スマートフォン、スマートウォッチ、その他のガジェットも IoT の一部となる可能性があります。 しかし、そのようなデバイスは、原則として、大規模な開発者が提供する独自の通信プロトコルを使用します。 生成された IoT データは、REST HTTP プロトコルを介してフォグ レイヤーに転送され、RESTful サービスを作成する際の柔軟性と相互運用性が実現します。 これは、ローカル コンピューター、サーバー、またはサーバー クラスターで実行されている既存のコンピューティング インフラストラクチャとの下位互換性を確保する必要性を考慮すると重要です。 「フォグ ノード」と呼ばれるローカル リソースは、受信したデータをフィルタリングしてローカルで処理するか、さらなる計算のためにクラウドに送信します。

クラウドはさまざまな通信プロトコルをサポートしていますが、最も一般的なのは AMQP と REST HTTP です。 HTTP はよく知られており、インターネット向けに調整されているため、「IoT やフォグと連携するために HTTP を使用すべきではないでしょうか?」という疑問が生じるかもしれません。 ただし、このプロトコルにはパフォーマンスの問題があります。 これについては後で詳しく説明します。

一般に、必要なシステムに適した通信プロトコルの 2 つのモデルがあります。 これらはリクエスト/レスポンスとパブリッシュ/サブスクライブです。 最初のモデルは、特にサーバークライアント アーキテクチャにおいて、より広く知られています。 クライアントはサーバーに情報を要求し、サーバーはその要求を受信して​​処理し、応答メッセージを返します。 REST HTTP および CoAP プロトコルはこのモデルで動作します。

XNUMX 番目のモデルは、データを生成するソースとこのデータの受信者の間に非同期、分散型の疎結合を提供する必要性から生まれました。

このモデルは、パブリッシャー (データ ソース)、ブローカー (ディスパッチャー)、およびサブスクライバー (受信者) の XNUMX 人の参加者を想定しています。 ここで、サブスクライバとして機能するクライアントは、サーバーに情報を要求する必要はありません。 リクエストを送信する代わりに、ブローカーを通じてシステム内の特定のイベントをサブスクライブします。ブローカーは、すべての受信メッセージをフィルタリングし、パブリッシャーとサブスクライバー間でメッセージをルーティングする役割を果たします。 そして、パブリッシャーは、特定のトピックに関してイベントが発生すると、それをブローカーにパブリッシュし、ブローカーは、要求されたトピックに関するデータをサブスクライバーに送信します。

基本的に、このアーキテクチャはイベントベースです。 そして、この対話モデルは、スケーラビリティを提供し、さまざまなデバイス間の相互接続を簡素化し、動的な多対多通信と非同期通信をサポートする機能があるため、IoT、クラウド、フォグのアプリケーションにとって興味深いものです。 パブリッシュ/サブスクライブ モデルを使用する最もよく知られた標準化されたメッセージング プロトコルには、MQTT、AMQP、DDS などがあります。

明らかに、パブリッシュ/サブスクライブ モデルには多くの利点があります。

• パブリッシャーとサブスクライバーは、お互いの存在について知る必要はありません。
• XNUMX 人のサブスクライバーは多くの異なる出版物から情報を受信でき、XNUMX つのパブリッシャーは多くの異なるサブスクライバーにデータを送信できます (多対多の原則)。
• パブリッシャーとサブスクライバーは、通信するために同時にアクティブである必要はありません。これは、ブローカー (キュー システムとして機能) が、現在ネットワークに接続していないクライアントへのメッセージを保存できるためです。

ただし、リクエスト/レスポンス モデルにも利点があります。 複数のクライアント要求を処理するサーバー側の能力が問題にならない場合は、実績のある信頼性の高いソリューションを使用することが合理的です。

両方のモデルをサポートするプロトコルもあります。 たとえば、「サーバー プッシュ」オプションをサポートする XMPP と HTTP 2.0 です。 IETF は CoAP もリリースしました。 メッセージングの問題を解決するために、WebSocket プロトコルや QUIC (Quick UDP Internet Connections) での HTTP プロトコルの使用など、他のいくつかの解決策が作成されています。

WebSocket の場合、サーバーから Web クライアントにリアルタイムでデータを転送し、同時双方向通信による永続的な接続を提供するために使用されますが、コンピューティング リソースが限られたデバイス向けではありません。 新しいトランスポート プロトコルは多くの新しい機会を提供するため、QUIC も注目に値します。 しかし、QUIC はまだ標準化されていないため、その応用の可能性や IoT ソリューションへの影響を予測するのは時期尚早です。 そのため、将来を見据えて WebSocket と QUIC を念頭に置いていますが、今はこれ以上詳しくは検討しません。

世界で一番かわいいのは誰ですか: プロトコルの比較

次に、プロトコルの長所と短所について話しましょう。 今後を見据えて、明確なリーダーはいないということを直ちに留保しておきます。 各プロトコルにはいくつかの利点と欠点があります。

応答時間

通信プロトコルの最も重要な特性の XNUMX つは、特にモノのインターネットに関連した場合、応答時間です。 しかし、既存のプロトコルの中で、さまざまな条件下で動作する際に最小レベルの遅延を示す明確な勝者は存在しません。 しかし、プロトコルの機能については膨大な調査と比較が行われています。

たとえば、 結果 IoT を使用する場合の HTTP と MQTT の有効性を比較したところ、MQTT のリクエストに対する応答時間は HTTP よりも短いことがわかりました。 そしていつ 勉強する MQTT と CoAP の往復時間 (RTT) を調べたところ、CoAP の平均 RTT は MQTT の平均 RTT より 20% 短いことがわかりました。

Другой 実験 MQTT および CoAP プロトコルの RTT を使用した実装は、ローカル ネットワークと IoT ネットワークの 2 つのシナリオで実行されました。 IoT ネットワークでは平均 RTT が 3 ～ 0 倍高いことが判明しました。 QoS1 を使用した MQTT は CoAP と比較して低い結果を示し、QoSXNUMX を使用した MQTT はアプリケーション層とトランスポート層での ACK により高い RTT を示しました。 さまざまな QoS レベルで、輻輳のないネットワーク遅延は、MQTT では数ミリ秒、CoAP では数百マイクロ秒でした。 ただし、信頼性の低いネットワークで作業する場合、TCP 上で実行される MQTT はまったく異なる結果を示すことを覚えておく価値があります。

比較 ペイロードを増やして AMQP および MQTT プロトコルの応答時間を測定したところ、負荷が軽い場合の遅延レベルはほぼ同じであることがわかりました。 ただし、大量のデータを転送する場合、MQTT の応答時間は短くなります。 もう一つで 調査 CoAP は、ガス センサー、気象センサー、位置センサー (GPS)、およびモバイル ネットワーク インターフェイス (GPRS) を備えた車両の上部に展開されたデバイスを使用したマシン間通信シナリオで HTTP と比較されました。 モバイル ネットワーク経由で CoAP メッセージを送信するのに必要な時間は、HTTP メッセージを使用するのに必要な時間よりもほぼ XNUMX 倍短かったです。

XNUMX つではなく XNUMX つのプロトコルを比較した研究が実施されました。 例えば、 比較 ネットワーク エミュレーターを使用した医療アプリケーション シナリオにおける IoT プロトコル MQTT、DDS、および CoAP のパフォーマンス。 DDS は、さまざまな劣悪なネットワーク条件下でテストされたテレメトリ遅延の点で MQTT を上回りました。 UDP ベースの CoAP は、高速応答時間を必要とするアプリケーションにはうまく機能しましたが、UDP ベースであるため、予測できない重大なパケット損失が発生しました。

スループット

比較 帯域幅効率の観点からの MQTT と CoAP は、メッセージごとに送信されるデータの総量の計算として実行されました。 CoAP は、小さなメッセージを送信する場合、MQTT よりもスループットが低いことが示されています。 しかし、転送された合計バイト数に対する有用な情報バイト数の比率という観点からプロトコルの効率を比較すると、CoAP の方が効率的であることが判明しました。

に 分析 MQTT、DDS (トランスポート プロトコルとして TCP)、および CoAP 帯域幅を使用した場合、CoAP は一般に比較的低い帯域幅消費を示し、MQTT や DDS とは異なり、ネットワーク パケット損失やネットワーク遅延の増加によって帯域幅消費量が増加しないことがわかりました。前述のシナリオにおける帯域幅使用率の増加。 もう XNUMX つのシナリオには、IoT 環境では一般的な、多数のデバイスが同時にデータを送信することが含まれます。 結果は、使用率を高めるには CoAP を使用する方が良いことを示しました。

負荷が軽い場合、CoAP の使用帯域幅が最も少なく、次に MQTT と REST HTTP が続きます。 ただし、ペイロードのサイズが増加した場合、REST HTTP が最良の結果をもたらしました。

消費電力

エネルギー消費の問題は常に非常に重要であり、特に IoT システムでは重要です。 もし 比較する MQTT と HTTP は電力を消費しますが、HTTP はより多くの電力を消費します。 そしてCoAPはさらに エネルギー効率 MQTT と比較して、電源管理が可能です。 ただし、単純なシナリオでは、特に電力制限がない場合、モノのインターネット ネットワークでの情報交換には MQTT の方が適しています。

Другой モバイルまたは不安定なワイヤレス ネットワークのテストベッドで AMQP と MQTT の機能を比較した実験では、AMQP の方がセキュリティ機能が高く、MQTT の方がエネルギー効率が高いことがわかりました。

セキュリティ

セキュリティは、モノのインターネットとフォグ/クラウド コンピューティングのトピックを研究する際に提起されるもう XNUMX つの重要な問題です。 セキュリティ メカニズムは通常、HTTP、MQTT、AMQP、XMPP の TLS、または CoAP の DTLS に基づいており、両方の DDS バリアントをサポートします。

TLS と DTLS は、サポートされている暗号スイートとキーを交換するために、クライアント側とサーバー側の間で通信を確立するプロセスから始まります。 双方がセットをネゴシエートして、安全なチャネルでさらなる通信が確実に行われるようにします。 XNUMX つの違いは、信頼性の低い接続でも UDP ベースの DTLS が動作できるようにするための小さな変更にあります。

に テスト攻撃 TLS と DTLS のいくつかの異なる実装では、TLS の方が優れたパフォーマンスを発揮することがわかりました。 DTLS はエラー耐性があるため、DTLS に対する攻撃はより成功しました。

ただし、これらのプロトコルの最大の問題は、これらのプロトコルが元々 IoT で使用するように設計されておらず、霧やクラウドで動作することを意図していないことです。 ハンドシェイクを通じて、接続が確立されるたびに追加のトラフィックが追加され、コンピューティング リソースが消耗されます。 平均すると、セキュリティ層のない通信と比較して、オーバーヘッドが TLS で 6,5%、DTLS で 11% 増加します。 リソースが豊富な環境では、通常は 曇り レベルではこれは問題になりませんが、IoT とフォグ レベルの間の接続では、これは重要な制限になります。

何を選ぶべきですか？ 明確な答えはありません。 MQTT と HTTP は、他のプロトコルに比べて比較的成熟しており、より安定した IoT ソリューションであると考えられているため、最も有望なプロトコルであると思われます。

ユニファイドコミュニケーションプロトコルに基づくソリューション

単一プロトコル ソリューションの実践には多くの欠点があります。 たとえば、制限された環境に適したプロトコルは、厳格なセキュリティ要件があるドメインでは機能しない可能性があります。 これを念頭に置くと、MQTT と REST HTTP を除く、IoT の Fog-to-Cloud エコシステムで考えられるほぼすべての単一プロトコル ソリューションを廃棄することになります。

単一プロトコル ソリューションとしての REST HTTP

REST HTTP リクエストとレスポンスが IoT-to-Fog スペースでどのように対話するかを示す良い例があります。 スマートファーム。 動物にはウェアラブルセンサー (IoT クライアント、C) が装備されており、スマート農業システム (フォグサーバー、S) によるクラウドコンピューティングを介して制御されます。

POST メソッドのヘッダーでは、変更するリソース (/farm/animals) と HTTP バージョンおよびコンテンツ タイプを指定します。この場合、これはシステムが管理する動物農場 (Dulcinea/cow) を表す JSON オブジェクトです。 。 サーバーからの応答は、HTTPS ステータス コード 201 (リソースが作成されました) を送信することで、要求が成功したことを示します。 GET メソッドでは、URI で要求されたリソース (/farm/animals/1 など) のみを指定する必要があります。これにより、その ID を持つ動物の JSON 表現がサーバーから返されます。

PUT メソッドは、特定のリソース レコードを更新する必要がある場合に使用されます。 この場合、リソースは変更するパラメーターの URI と現在の値 (たとえば、牛が現在歩いていることを示します、/farm/animals/1? state=walking) を指定します。 最後に、DELETE メソッドは GET メソッドと同様に使用されますが、操作の結果としてリソースを単に削除するだけです。

単一プロトコル ソリューションとしての MQTT

同じスマート ファームを考えてみましょう。ただし、REST HTTP の代わりに MQTT プロトコルを使用します。 Mosquitto ライブラリがインストールされたローカル サーバーはブローカーとして機能します。 この例では、単純なコンピューター (ファーム サーバーと呼ばれる) Raspberry Pi が MQTT クライアントとして機能し、Mosquitto ブローカーと完全な互換性がある Paho MQTT ライブラリのインストールによって実装されます。

このクライアントは、センシング機能とコンピューティング機能を備えたデバイスを表す IoT 抽象化レイヤーに対応します。 一方、メディエータはより高いレベルの抽象化に対応し、より大きな処理能力と記憶容量を特徴とするフォグ コンピューティング ノードを表します。

提案されているスマート ファーム シナリオでは、Raspberry Pi が加速度センサー、GPS、温度センサーに接続し、これらのセンサーからのデータをフォグ ノードに公開します。 ご存知かと思いますが、MQTT はトピックを階層として扱います。 単一の MQTT パブリッシャーは、特定のトピックのセットにメッセージをパブリッシュできます。 私たちの場合、それらは XNUMX つあります。 畜舎内の温度を測定するセンサーの場合、クライアントはテーマ (畜舎/小屋/温度) を選択します。 加速度計を通じて GPS 位置と動物の動きを測定するセンサーの場合、クライアントは (animalfarm/animal/GPS) および (animalfarm/animal/movement) への更新を公開します。

この情報はブローカーに渡され、後で別の関心のある加入者が現れた場合に備えて、ローカル データベースに一時的に保存できます。

フォグ内で MQTT ブローカーとして機能し、MQTT クライアントとして機能する Raspberry Pi がセンサー データを送信するローカル サーバーに加えて、クラウド レベルに別の MQTT ブローカーが存在する場合があります。 この場合、ローカル ブローカーに送信された情報は、ローカル データベースに一時的に保存したり、クラウドに送信したりすることができます。 この状況におけるフォグ MQTT ブローカーは、すべてのデータをクラウド MQTT ブローカーに関連付けるために使用されます。 このアーキテクチャを使用すると、モバイル アプリケーション ユーザーは両方のブローカーにサブスクライブできます。

いずれかのブローカー (クラウドなど) への接続が失敗した場合、エンド ユーザーは他のブローカー (フォグ) から情報を受け取ります。 これは、フォグとクラウド コンピューティング システムを組み合わせた特徴的な機能です。 デフォルトでは、モバイル アプリは最初にフォグ MQTT ブローカーに接続し、それが失敗した場合はクラウド MQTT ブローカーに接続するように構成できます。 このソリューションは、IoT-F2C システムにある数多くのソリューションのうちの XNUMX つにすぎません。

マルチプロトコルソリューション

単一プロトコル ソリューションは、実装が簡単なため人気があります。 しかし、IoT-F2C システムでは、異なるプロトコルを組み合わせることが合理的であることは明らかです。 考え方は、異なるプロトコルが異なるレベルで動作できるということです。 たとえば、IoT、フォグ、クラウド コンピューティングのレイヤーという XNUMX つの抽象化を考えてみましょう。 IoT レベルのデバイスは一般に制限されていると考えられます。 この概要では、IoT 層を最も制約が多く、クラウドを最も制約が少なく、フォグ コンピューティングを「その中間」と考えてみましょう。 IoT とフォグ抽象化の間に、現在のプロトコル ソリューションには MQTT、CoAP、XMPP が含まれていることがわかります。 一方、フォグとクラウドの間では、AMQP が REST HTTP とともに使用される主要なプロトコルの XNUMX つであり、その柔軟性により IoT とフォグ レイヤの間でも使用されます。

ここでの主な問題は、プロトコルの相互運用性と、あるプロトコルから別のプロトコルへのメッセージの転送の容易さです。 理想的には、将来的には、クラウドおよびフォグ リソースを備えたモノのインターネット システムのアーキテクチャが、使用される通信プロトコルから独立し、異なるプロトコル間の良好な相互運用性が保証されるようになります。

現在はそうではないため、大きな違いがないプロトコルを組み合わせるのが合理的です。 この目的を達成するために、考えられるソリューションの XNUMX つは、同じアーキテクチャ スタイルに従う XNUMX つのプロトコル、REST HTTP と CoAP の組み合わせに基づいています。 提案されているもう XNUMX つのソリューションは、パブリッシュ/サブスクライブ通信を提供する XNUMX つのプロトコル、MQTT と AMQP の組み合わせに基づいています。 同様の概念 (MQTT と AMQP は両方ともブローカーを使用し、CoAP と HTTP は REST を使用) を使用すると、これらの組み合わせの実装が容易になり、必要な統合作業が少なくなります。

図 (a) は、HTTP と CoAP という 2 つのリクエスト/レスポンス ベースのモデルと、IoT-FXNUMXC ソリューションにおけるそれらの配置の可能性を示しています。 HTTP は現代のネットワークで最もよく知られ採用されているプロトコルの XNUMX つであるため、他のメッセージング プロトコルに完全に置き換えられる可能性は低いです。 クラウドとフォグの間にある強力なデバイスを表すノードの中でも、REST HTTP はスマートなソリューションです。

一方、フォグ層と IoT 層の間で通信するコンピューティング リソースが限られているデバイスの場合は、CoAP を使用する方が効率的です。 CoAP の大きな利点の XNUMX つは、実際には HTTP との互換性です。これは、両方のプロトコルが REST 原則に基づいているためです。

図 (b) は、MQTT と AMQP を含む、同じシナリオにおける XNUMX つのパブリッシュ/サブスクライブ通信モデルを示しています。 仮想的には両方のプロトコルを各抽象化層のノード間の通信に使用できますが、その位置はパフォーマンスに基づいて決定する必要があります。 MQTT は、コンピューティング リソースが限られているデバイス向けの軽量プロトコルとして設計されているため、IoT-Fog 通信に使用できます。 AMQP は、フォグ ノードとクラウド ノードの間に理想的に配置される、より強力なデバイスにより適しています。 MQTT の代わりに、XMPP プロトコルは軽量であると考えられているため、IoT で使用できます。 しかし、このようなシナリオではあまり広く使用されていません。

所見

ここで説明したプロトコルの XNUMX つで、コンピューティング リソースが限られたデバイスからクラウド サーバーに至るまで、システム内のすべての通信をカバーできるとは考えにくいです。 この調査では、開発者が最もよく使用する XNUMX つの最も有望なオプションは、MQTT と RESTful HTTP であることがわかりました。 これら XNUMX つのプロトコルは最も成熟していて安定しているだけでなく、十分に文書化され成功した実装とオンライン リソースも多数含まれています。

MQTT は、その安定性とシンプルな構成により、限られたデバイスを使用して IoT レベルで使用された場合に、その優れたパフォーマンスが時間の経過とともに証明されているプロトコルです。 一部のフォグ ドメインやほとんどのクラウド コンピューティングなど、通信の制限やバッテリー消費が問題にならないシステムの部分では、RESTful HTTP が簡単な選択です。 CoAP も IoT メッセージング標準として急速に進化しており、近い将来、MQTT や HTTP と同様の安定性と成熟度のレベルに達する可能性が高いため、CoAP も考慮する必要があります。 しかし、この標準は現在進化中であり、短期的な互換性の問題が伴います。

ブログでは他に何が読めますか? クラウド4Y

→ コンピュータがあなたを美味しくしてくれる
→ AI はアフリカの動物の研究に役立つ
→ 夏ももう終わりに近づいています。 漏洩したデータはほとんど残っていない
→ クラウドバックアップを節約する 4 つの方法
→ 人口に関する情報を含む統合連邦情報リソースについて

購読してください Telegram次の記事を見逃さないように、 -channel をご覧ください。 私たちは週に XNUMX 回まで、ビジネスに関するもののみを書きます。

出所： habr.com