世界一スケーラブルなMQTTブローカー - IoT Edge Connect -
ここ数年様々なニュース、アナリストによるレポート等で叫ばれている通り、いわゆる"IoTデバイス"の数は加速度的に増え続けています。増加見込みについても様々な機関が予測を発表しており、その内容にはバラつきもありますが、今後数年で数百億台程度に達するとしているものが多く見られます。また5Gネットワークの普及が、従来は実現困難であったIoTサービスの創出を後押しすると考えられます。
しかし一方で、IoTデバイスとの通信を馴染みのあるHTTPで行おうとすると、様々な課題に直面します。例えば以下のような課題です。
IoT通信におけるHTTPの課題
1) 大量のIoTデバイスとのコネクション
HTTPはクライアント・サーバーモデルなので、当たり前ですがクライアントとWebサーバー(あるいはリバースプロキシ、ロードバランサ等)の間で直接コネクションが確立されます。IoTサービスにおいてクライアントとなるのは通常IoTデバイスですが、これが莫大な数に及んだ時、安定してサービス提供が可能なキャパシティを用意することは困難となります。
2) 再送への対応
IoTデバイスの中には、品質の悪いネットワーク環境の中に配置されるものも少なくありません。そのようなデバイスとの通信ではタイムアウトの発生等で再送が頻発し、サーバー側の負荷を更に増加させてしまいます。
3) IoTデバイスへのプッシュ通知
HTTPの通信は、必ずクライアントによるリクエストで開始されます。(※1) そのため、サーバーからクライアントへ能動的にメッセージを通知することができません。これは、IoTデバイスの遠隔操作を困難にしてしまいます。
4) 使用できるネットワーク帯域、バッテリーに制限があるIoTデバイス
HTTPは非常にリッチなプロトコルであるため、リクエスト・レスポンスともに多数のヘッダが付与されています。一方でIoTデバイスとの通信では、例えばセンサー等から小さなデータを頻繁に送信する等、リクエスト・レスポンスの回数が多くなる傾向にあります。その分、HTTPヘッダのオーバーヘッドの影響も大きくなり、ネットワーク帯域やバッテリーに制限があるIoTデバイスは長時間の稼働が難しくなってしまいます。
MQTT (MQ Telemetry Transport)
上記のような課題を克服するため、IoTデバイスとデータセンター間のプロトコルとしてMQTTの使用を検討されている皆様も多いと思います。MQTTはHTTPのようなクライアント・サーバー間のリクエスト・レスポンスではなく、以下のようなPubSubモデルとなります。
MQTTにおけるメッセージは任意の"Topic"というグループに分類されます。メッセージを受け取る側 (Subscriber) は、予め受け取る必要のあるメッセージのTopicを指定して、Subscribeしておきます。メッセージを送る側 (Publisher)がそのTopicに対してメッセージをPublishすると、同じTopicをSubscribeしているSubscriberにメッセージプッシュで配信されます。誰がどのTopicをSuscribeしているか、あるいはどのTopicに何のメッセージが配信されたか等は全て"Broker"という仲介役が管理しており、全てのやりとりはBrokerを経由して行われます。これをもう少しIoTサービスのイメージに当てはめると以下のようになります。
データの流れ(どちらが受信でどちらが送信か)によって、IoTデバイスもサーバーもSubscriberになったりPublisherになったりします。MQTT自体の詳細は本記事では割愛させて頂きますが、このようなアーキテクチャを踏まえてMQTTの使用が上述のHTTPでの課題にどう影響するかを見てみましょう。(※2)
1) 大量のIoTデバイスとのコネクション
⇒ IoTデバイスと直接コネクションを確立するのはBrokerのみ。サーバーもBrokerのみとコネクションを確立すれば良い。
2) 再送への対応
⇒再送が行われるのもIoTデバイス - Broker間か、Broker - サーバー間のみ。
3) IoTデバイスへのプッシュ通知
⇒サーバーからのPublishによって、SubscriberであるIoTデバイス群へ一斉にプッシュ通知を行うことが可能。
4) 使用できるネットワーク帯域、バッテリーに制限があるIoTデバイス
⇒MQTTのヘッダはHTTPのヘッダに比べて大幅に小さいため、オーバーヘッドが少なくて済みネットワーク帯域やバッテリーの消費を軽減することが可能。
3), 4)についてはMQTTというプロトコルの仕様によって解決・軽減できますが、1), 2)についてはBrokerのスケールが鍵となることが分かります。
では、Brokerはどのようなプラットフォームで構築するのでしょうか？Mosquitto (※3) 等のオープンソースが公開されていますので、自社でIaaSやオンプレ上にMQTT Brokerを構築することも可能です。ただし大量の、あるいはグローバルに分散したIoTデバイスとのPublish/Subscribeに耐えうるスケールを用意することはコストや手間を考えれば困難となるでしょう。
Akamai IoT Edge Connect
Akamaiではこのようなニーズに対応するため、"IoT Edge Connect" というソリューションを提供しております。IoT Edge ConnectはAkamaiがCDN、クラウドWAFで培ってきたAkamai Intelligent Edge PlatformをMQTT Brokerとして活用できるソリューションで、以下のような特徴を備えています。
世界随一の規模を持つプラットフォーム
Akamai Intelligent Edge Platformはインターネット上の約24万台のエッジサーバーで構成されており、世界随一の規模を持っています。これをMQTT Brokerとしてご活用頂くことにより、大量IoTデバイスとの通信に耐えうるキャパシティを労せずして手に入れることが可能です。
世界各国のISP網内へ配置された超分散型
Akamai Intelligent Edge Platformはエッジサーバーの台数もさることながら、世界130カ国以上、約2,400カ所のデータセンター(2019年6月20日現在)へ配置された超分散型であることも最大の特徴です。これにより、どのような地域に置かれたIoTデバイスであってもほぼ1ネットワークホップで最寄りのエッジサーバー (MQTT Broker) に到達できるため、物理的距離による遅延を一気に短縮して高速なSubscribe/Publishが可能です。
クライアント認証への対応
JWT (JSON Web Token) またはTLS相互認証によって、クライアントであるIoTデバイスを認証します。これによって不正なデバイスからメッセージをSubscribeされることなく、そうしたデバイスからPublishされたメッセージをBrokerが受け取ることも、正規のSubscriberが受け取ることもありません。
MQTT国際標準への完全準拠
IoT Edge ConnectはMQTTの国際標準であるISO/IEC:20922に完全準拠しています。皆様が開発されるSubscriber, Publisherとの相互接続性を非常に保ちやすく、QoSレベル 0,1,2への対応を含め、MQTTが本来持つ機能を最大限にご活用頂くことが可能です。
地域別のデータ分離
各国・地域でのデータ保護に関する法令へ対応するため、MQTT Broker上に保持されるメッセージを地域毎に分離できるようになっています。本記事執筆時点ではグローバル(地域分離無し)以外に、日本、US、EUに閉じたメッセージ管理が可能となっておりますので、GDPRへもスムーズに対応可能です。
世界一スケーラブルでセキュアなMQTT Brokerを容易にご利用頂くことが出来ますので、現在自社のIoTサービスに課題をお持ちの方、またはこれから開始予定の方はお気軽にAkamaiへご相談ください。
またIoT Edge Connectは現在でも機能の拡張を続けており、今後はIoT Edge Connect上でメッセージを加工したり、任意のロジックを実行させたりといったエッジコンピューティングへの進化も見据えて日々製品開発を行っております。ご報告できる段階になりましたら、また本ブログや弊社Webサイト、各種イベント等を通じてアップデートさせて頂きます。
(※1) HTTP/2にはServer Pushという仕組みもあります。ただしそちらの場合はHTMLのリクエストに伴って、そのHTML上で必要なオブジェクトをServerが予めPushするというものであり、IoTデバイスに対して任意の内容、タイミングでメッセージを配信するといった用途には使用することができません。
(※2) MQTTにはメッセージの到達性を担保するための"QoS"等、他にも便利な仕組みが備わっています。この辺りはまた別の記事で取り上げたいと思います。
(※3) https://mosquitto.org/
