IoT（Internet of Things）プログラムに取り組む技術チームやマーケティングチームは、遅かれ早かれ、デバイス群（フリート）とクラウド間でデータをやり取りする必要があるプロジェクトに直面します。このデータは極めて重要です。マーケティングはユーザーにより多くの機能を提供したいと考え、ビジネスチームはデータに基づく意思決定を求め、技術チームは既存デバイスフリートとの接続性を最適化しようとします。これらすべての理由は、最終的にはカスタマーエクスペリエンスの向上という一点に収束します。本記事では、IoT プロジェクトの初期段階と、デバイスとクラウド間で通信するために利用可能な選択肢のいくつかを紹介します。また、要件やプロジェクト制約に基づいて通信方式を選択するための具体的な指針も提供します。一般的なソリューションから、あまり標準的ではないアプローチまでを取り上げ、コスト・スコープ・期間を損なう典型的な落とし穴を回避するための助けとなることを目的としています。

IoT デバイスとデバイスデータ

IoT プロジェクトに携わる前、私は IoT をデバイス中心の視点で捉えていました。接続されたデバイスは、センサーやアクチュエータを通じて現実世界と相互作用する、IoT の中核コンポーネントです。しかし、それはソリューションの一部にすぎません。もう一つの重要な要素が「データ」です。プロジェクトによっては、必要なのはデバイスデータだけというケースもあります。多くの IoT プロジェクトでは、最初の技術的な議論は、デバイスとクラウド間でデータをどのように流すか、そしてどの通信プロトコルが必要かという点に集中します。では、どの通信プロトコルが必要なのでしょうか。結論から言えば、ケースバイケースです。さまざまなプロジェクト、プロトタイプ、業界での経験を通じて、単一のプロトコルだけを使う必要はないということを学びました。プロジェクトごとに適切な通信プロトコルを選択することは、探索的なプロセスになることもあります。その鍵となるのが、次の 4 つのシステム制約に分解して考えることです。

• デバイス： メモリ容量、利用可能な通信インターフェース、計算能力、消費電力といった物理的な制約は何か。
• データ： デバイスで収集されるデータの種類は何か。各データタイプの量（ボリューム）はどれくらいか。データの流れは双方向か片方向か。
• コスト： 各データタイプにおける通信コストはいくらか。できるだけ早くクラウドに送るだけの価値があるか。
• セキュリティ： 単にデータを送受信するだけでは不十分です。通信は、認証・認可・検証・プライバシーポリシーをサポートする安全な方法で管理される必要があります。セキュリティ機能は、分析段階および通信プロトコル選定時の基盤要件として考慮しなければなりません。

注：本記事で紹介する各通信プロトコルは、X.509 証明書、カスタムオーソライザー、フェデレーションなど、さまざまな認証方式を実装できます。

MQTT プロトコル

MQTT は、IoT プロジェクト向けの標準的なメッセージングプロトコルです。双方向で、軽量かつスケーラブルであり、HTTP と同様にアプリケーションレイヤの高レベルプロトコルですが、特性は異なります。また、多くのライブラリやプログラミング言語で広くサポートされています。

OSI モデルにおける HTTP と MQTT プロトコル

MQTT は パブリッシュ-サブスクライブモデルに基づいており、ブローカーがクライアント間の通信を仲介します。基本的な MQTT メッセージは、メッセージ内容を階層的に識別する「トピック」と、JSON、バイナリ、テキストなどの形式で表現される「ペイロード」という 2 つの要素で構成されます。

もしプロジェクトにおいて、デバイスとクラウド間でメッセージを送受信するための通信チャネルが必要な場合、MQTT は非常に適した選択肢です。MQTT を利用することで、デバイスのデータやステータスをクラウドに送信し、クラウドからのリクエストやメッセージを受信できます。シンプルで柔軟な設計を維持しながら、MQTT はアプリケーションを簡素化するための機能をネイティブに提供します。たとえば、適切なトピック階層構造を設計することで、デバイスが送信または受信できるメッセージを効率的に制御できます。詳細については AWS IoT Core 向け MQTT トピック設計を参照してください。

AWS IoT Core は、MQTT、MQTT5、MQTT over WebSocket、HTTPS プロトコルをサポートしています。また、MQTT ブローカーとして動作し、デバイスをクライアントとして扱います。AWS IoT Core は、さまざまな追加機能やサービスを提供しています。たとえば、デバイスの自動プロビジョニングを可能にする仕組みや、デバイスタイプ・属性・タグに基づいて静的または動的なデバイスグループ（ジョブ）を制御する機能などがあります。さらに、単一デバイスの運用から、デバイスフリート全体の管理へと移行することもサポートしています。

AWS IoT Core を用いた MQTT 通信

データストリームと MQTT

デバイスから送信される MQTT メッセージには、通常、測定値、ステータス、イベント、制御データ、設定データなどが含まれます。このプロトコルは柔軟性が高く、1 つのメッセージに 1 つまたは複数のデータペイロードを含めることができます。たとえば、単一のイベントを含むメッセージもあれば、特定の時点における複数の測定値やデバイスステータスを含む JSON オブジェクトをペイロードとして送信することも可能です。一方で、複数のメッセージを管理するよりも、ストリームベースの通信が適しているケースもあります。代表的なユースケースの一つが、デバイスの不揮発性メモリにローカル保存またはキャッシュされているデータを扱う場合です。デバイスは、定期的に、あるいはリクエストに応じてオンデマンドでこれらのデータを送信できます。また、ストリームは、高ボリュームで準リアルタイムなデータを送信する際にも一般的に利用されます。たとえば、複数のデバイスから生の測定データを送信し、クラウド上で処理・分析を行うケースです。

データまたは映像ストリームの取り込み

Amazon Kinesis は、データやビデオストリームの取り込み、処理、分析をサポートするサービス群です。代表的なユースケースとして、デバイスから Amazon Kinesis Data Streams へデータをストリーミングするケースがあります。詳細については、AWS IoT Core および Amazon Kinesis を用いたデバイスデータ取り込みのベストプラクティスを参照してください。これら 2 つの通信チャネルは、クラウドとの通信要件を満たすために、同一デバイス上で併用されることも少なくありません。

送信専用（メッセージ送信のみ）パターン

一部のプロジェクトでは、デバイスからクラウドへの軽量な片方向通信レイヤのみが求められます。アプリケーション、デバイス、またはプロジェクト上の制約により、デバイスとクラウド間で双方向通信を確立することが常に可能とは限りません。また、システムがサードパーティによって開発されており、新たな機能追加が難しい場合にも、このような片方向通信の構成が採用されることがあります。

双方向通信は、デバイスがステータス更新や測定値を送信し、それに対してクラウドが確認応答を返す場合に一般的に用いられます。一方で、この片方向通信パターンをサポートするために、AWS IoT Core、Amazon API Gateway または AWS AppSync などのサービスを利用できます。ただし、これは publish-only プロトコルであるため、デバイス側はクラウドの更新情報を取得するためにポーリングを行う必要があります。その結果、デバイス切断検知などの機能は、他のプロトコルのように標準で提供されず、追加実装が必要になります。

HTTP によるリクエストのみの通信

MQTT が利用できない場合でも、HTTPS プロトコルを使用し、レスポンスメッセージを通じてクラウドからデータを受信することが可能です。データが AWS に取り込まれた後は、200 を超える AWS のマネージドサービスを利用して、データの処理、分析、知能化を行えます。

デバイスで静的データを受信する

デバイスまたはデバイスフリートが、クラウドから静的または準静的なデータを読み取る必要がある場合もあります。たとえば、設定情報やソフトウェアアップデートなどです。アプリケーションですでに MQTT プロトコルを実装している場合、MQTT シャドウは、設定情報のような比較的小さな静的データを取得するための効率的な手段です。詳細については、AWS IoT Core のメッセージブローカーおよびプロトコルの制限とクォータを参照してください。

Amazon S3 バケットからの読み取り

ファームウェア更新のように、バージョン番号やステータスを含む比較的大きなファイルについては、Amazon Simple Storage Service (Amazon S3) から直接ダウンロードできます。

S3 からの能動的なデータ受信：双方向プロトコルと片方向プロトコルの比較

デバイスを 伴わない IoT プロジェクト（稀なケース）

IoT デバイスを直接扱って開発を行うことが、常に可能とは限りません。たとえ複数のデバイスを管理する IoT クラウドアプリケーションを構築することが目的であっても、さまざまな制約によって状況が複雑になる場合があります。たとえば、次のようなケースです。

• 現場に展開済みの既存デバイスを更新できない、または更新に非常に大きな開発工数が必要な場合。
• 既存システムが依存しているため、現在のデバイス通信機能を変更できない場合。
• サードパーティ製デバイスが含まれる場合。これには、独自の制御システムや独自の通信プロトコルを持つデバイス、あるいはチーム側で変更できないクローズドなシステムが含まれる可能性があります。

実現可能性の検証やシステム全体像の把握が目的であれば、IoT クラウド基盤およびアプリケーションのプロトタイプを開発することが有効です。この際、既存デバイスのテレメトリデータや制御機能を活用できます。このアプローチには、主に次の 2 つの戦略が考えられます。

• クラウド間（Cloud-to-Cloud）通信ソリューションを実装する。
• 既存デバイス API に対するラッパーを開発する。

デバイス開発を伴わない、クラウド間通信

クラウド間通信を利用することで、既存ソリューションを新しい開発から分離できるという利点があります。また、異なるアプリケーションプロトコルを使用してデバイステレメトリデータを転送し、データの制御性を高めることも可能です。既存アプリケーションと新規アプリケーション間に仮想ネットワークを構築するために、Amazon Virtual Private Cloud (Amazon VPC) を活用することも考えられます。この通信方式は、たとえばデバイスグループ単位で測定値や状態を受信するようなケースでは、非常に効率的です。一方で、Amazon VPC の運用には追加の管理工数が必要となります。また、対象デバイスがサードパーティ製である場合には、共同開発が必要になることがあり、これが導入の障壁となることもあります。

デバイス開発を伴わない、既存の通信機能を活用する方式

もう一つの選択肢は、Amazon API Gateway を利用して、外部システムがすでに提供している API を活用するラッパーを開発する方法です。典型的なユースケースとしては、REST API や WebSocket API と通信するケースが挙げられます。サードパーティ API を利用する場合、1 秒あたり、1 分あたり、あるいは 1 日あたりのリクエスト数を制限するセキュリティ対策が施されていることがあります。これらの制約はスケーラビリティを制限する要因となる可能性があるため、事前に考慮しておく必要があります。

結論

IoT の強みの一つは、通信、データ保存、そしてエッジで意思決定を行える点にあります。IoT プロジェクトの進め方としては、デバイス（モノ）を起点に、その能力に基づいて設計を行うアプローチがあります。一方で、本記事では、データ中心のモデルに基づく異なるアプローチを紹介しました。最初にデータに着目することで、よりコスト効率の高いソリューションを設計できます。また、複数の通信プロトコルを使ってデータを取得することで、プロジェクトの目的や制約に合致した構成を実現できます。

参考文献

[ 1 ] https://aws.amazon.com/what-is/mqtt/
[ 2 ] https://docs.aws.amazon.com/pdfs/whitepapers/latest/designing-mqtt-topics-aws-iot-core/designing-mqtt-topics-aws-iot-core.pdf
[ 3 ] https://aws.amazon.com/blogs/iot/best-practices-for-ingesting-data-from-devices-using-aws-iot-core-and-or-amazon-kinesis/
[ 4 ] https://docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html
[ 5 ] https://docs.aws.amazon.com/general/latest/gr/iot-core.html#message-broker-limits

著者について

Alfonso Torres Soto は、インダストリアルエンジニア（修士）およびプロジェクトマネージャー（PMP）です。AWS のソリューションアーキテクトとして、お客様のアイデアを現実のものにする支援を行っています。テクノロジーと哲学の双方に情熱を持っています。