IoT Hub メッセージ ルーティングを使用して device-to-cloud メッセージを Azure サービスに送信する

  • [アーティクル]

メッセージ ルーティングを使用すると、自動化された、スケーラブルで信頼性の高い方法で、デバイスからクラウド サービスにメッセージを送信することができます。 メッセージ ルーティングを使うと次のことができます。

  • 組み込みのエンドポイントとカスタム エンドポイントに、デバイスのテレメトリ メッセージとイベントを送信します。 ルーティングできるイベントには、デバイス ライフサイクル イベント、デバイス ツイン変更イベント、デジタル ツイン変更イベント、デバイス接続状態イベントが含まれます。

  • 豊富なクエリを適用して、ルーティングする前のデータをフィルター処理します。 メッセージ ルーティングでは、メッセージ プロパティとメッセージ本文に基づいてクエリを実行できるほか、デバイス ツインのタグとプロパティに基づいてクエリを実行することもできます。 詳細については、メッセージ ルーティングのクエリに関する記事をご覧ください。

IoT ハブでは、各種プロトコルにおける相互運用性を確保するためにすべての device-to-cloud メッセージ用の共通形式が定義されています。 詳細については、「IoT Hub メッセージを作成し、読み取る」を参照してください。

Note

この記事で言及されている一部の機能 (cloud-to-device メッセージング、デバイス ツイン、デバイス管理など) は、IoT Hub の Standard レベルだけで使用することができます。 Basic および Standard または Free レベルの IoT Hub の詳細については、ソリューションに適した IoT Hub のレベルの選択に関するページを参照してください。

ルーティング エンドポイント

各 IoT ハブには、Event Hubs と互換性がある、messages/events という名前の既定のルーティング エンドポイントがあります。 また、Azure サブスクリプション内の他のサービスを指すカスタム エンドポイントを作成することもできます。

IoT Hub では現在、メッセージ ルーティング用に次のエンドポイントがサポートされています。

  • 組み込みのエンドポイント
  • ストレージ コンテナー
  • Service Bus キュー
  • Service Bus トピック
  • Event Hubs
  • Cosmos DB

これらの各エンドポイントについて詳しくは、「IoT Hub エンドポイント」をご覧ください。

各メッセージは、一致するルーティング クエリを持つすべてのエンドポイントにルーティングされます。つまり、1 つのメッセージが複数のエンドポイントにルーティングされる可能性があります。 ただし、メッセージが同じエンドポイントを指している複数のルートと一致する場合、IoT Hub はそのエンドポイントにメッセージを 1 回だけ送信します。

IoT Hub でメッセージのルーティングを機能させるには、これらのサービス エンドポイントへの書き込みアクセス許可が必要です。 Azure Portal を使用してエンドポイントを構成する場合、必要なアクセス許可は自動的に追加されます。 PowerShell または Azure CLI を使用してエンドポイントを構成する場合は、書き込みアクセス許可を指定する必要があります。

エンドポイントを作成する方法については、次の記事を参照してください。

予想されるスループットをサポートするようにサービスを構成してください。 たとえば、Event Hubs をカスタム エンドポイントとして使っている場合は、IoT Hub のメッセージ ルーティングを介して送信する予定のイベントのイングレスを処理できるように、そのイベント ハブに対するスループット ユニットを構成する必要があります。 同様に、Service Bus キューをエンドポイントとして使用する場合は、コンシューマーによるエグレスが行われるまでキューがすべてのイングレス データを保持できるように、最大サイズを構成する必要があります。 IoT ソリューションを初めて構成する場合は、他のエンドポイントを監視し、実際の負荷の調整を行う必要があります。

カスタム エンドポイントにファイアウォール構成がある場合、Microsoft が信頼を置くファースト パーティの例外の使用を検討してください。

別のサブスクリプション内のエンドポイントにルーティングする

エンドポイント リソースが IoT ハブとは異なるサブスクリプションにある場合は、カスタム エンドポイントを作成する前に、信頼できる Microsoft サービスとして IoT ハブを構成する必要があります。 カスタム エンドポイントを作成する際は、認証の種類をユーザー割り当て ID に設定します。

詳細については、IoT Hub から他の Azure リソースへのエグレス接続に関するページを参照してください。

ルーティング クエリ

IoT Hub メッセージ ルーティングでは、データをエンドポイントにルーティングする前にフィルター処理するクエリ機能が提供されています。 各ルーティング クエリには、次のプロパティがあります。

プロパティ 内容
名前 クエリを識別する一意の名前。
ソース 処理するデータ ストリームの元データ。 たとえば、デバイス テレメトリです。
Condition エンドポイントと一致するかどうかを確認するために、メッセージ アプリケーションのプロパティ、システムのプロパティ、メッセージ本文、デバイス ツインのタグ、デバイス ツインのプロパティに対して実行されるルーティング クエリのクエリ式。
エンドポイント クエリに一致するメッセージを IoT Hub が送信するエンドポイントの名前。 お使いの IoT ハブと同じリージョンのエンドポイントを選択することをお勧めします。

1 つのメッセージが複数のルーティング クエリの条件と一致することがあり、その場合、IoT Hub は一致する各クエリに関連するエンドポイントにメッセージを送信します。 IoT Hub はメッセージ配信の重複を自動的に排除するため、配信先が同じである複数のクエリに一致するメッセージの場合は、その配信先に 1 度だけ書き込まれます。

詳細については、「IoT Hub メッセージ ルーティングのクエリ構文」を参照してください。

ルーティングされたデータの読み取り

エンドポイントからメッセージを読み取る方法については、以下の記事を参照してください。

フォールバック ルート

フォールバック ルートは、既存のルートのいずれかでクエリ条件を満たさないすべてのメッセージを、Event Hubs と互換性のある組み込みのエンドポイント (メッセージ/イベント) に送信します。 メッセージ ルーティングが有効になっている場合は、フォールバック ルート機能を有効にすることができます。 何らかのルートが作成されると、ルートが作成されていない組み込みのエンドポイントには、データが流れなくなります。 組み込みのエンドポイントへのルートがなく、フォールバック ルートが有効になっている場合は、ルートのどのクエリ条件とも一致しないメッセージのみが組み込みのエンドポイントに送信されます。 既存のルートをすべて削除する場合でも、組み込みのエンドポイントですべてのデータを受信するため、フォールバック ルート機能を有効にしておく必要があります。

Azure portal の [メッセージ ルーティング] ブレードで、フォールバック ルートを有効または無効にできます。 また、Azure Resource Manager で FallbackRouteProperties を使用して、フォールバック ルート用にカスタム エンドポイントが使用されるようにすることもできます。

非テレメトリ イベント

メッセージ ルーティングでは、デバイス テレメトリのほかに、次のようなテレメトリ以外のイベントの送信を有効にすることもできます。

  • デバイス ツインの変更イベント
  • デバイス ライフサイクル イベント
  • デバイス ジョブ ライフサイクル イベント
  • デジタル ツインの変更イベント
  • デバイス接続状態イベント

たとえば、データ ソースをデバイス ツイン変更イベントに設定してルートを作成した場合、IoT Hub は、デバイス ツインの変更が含まれているメッセージをエンドポイントに送信します。 同様に、データ ソースをデバイス ライフサイクル イベントに設定してルートを作成した場合、IoT Hub は、デバイスまたはモジュールが削除または作成されたかどうかを示すメッセージを送信します。 デバイス ライフサイクル イベントの詳細については、「デバイスまたはモジュールのライフサイクルの通知」を参照してください。

Azure IoT プラグ アンド プレイを使用して、開発者は、データ ソースをデジタル ツイン変更イベントに設定したルートを作成できます。IoT Hub では、デジタル ツインのプロパティが設定または変更されたとき、デジタル ツインが置き換えられたとき、または基になるデバイス ツインで変更イベントが発生したときに、メッセージを送信します。 最後に、データ ソースをデバイス接続状態イベントに設定してルートを作成した場合、IoT Hub は、デバイスが接続または接続解除されたかどうかを示すメッセージを送信します。

IoT Hub は Azure Event Grid とも統合されているため、デバイス イベントを発行して、それらのイベントに基づくワークフローのリアルタイムの統合と自動化をサポートできます。 ご自分のシナリオにどれが最適かについては、メッセージ ルーティングと Event Grid の主な違いに関するページを参照してください。

デバイス接続状態イベントの制限

デバイス接続状態イベントは、MQTT または AMQP のいずれかのプロトコルを使用して、または WebSocket 経由でこれらのプロトコルのいずれかを使用して接続しているデバイスで使用できます。 HTTPS でのみ行われた要求では、デバイス接続状態の通知はトリガーされません。 IoT Hub でデバイス接続状態イベントの送信を開始するには、接続を開いた後、cloud-to-device receive message 操作または device-to-cloud send telemetry 操作のいずれかを呼び出す必要があります。 Azure IoT SDK の外部の MQTT では、これらの操作は、適切なメッセージング トピックでの SUBSCRIBE または PUBLISH 操作と同じになります。 AMQP 経由では、これらの操作は適切なリンク パスでメッセージをアタッチまたは転送することと同じです。 詳細については、次の記事をご覧ください。

IoT Hub は、デバイスごとに接続と切断のイベントを個別に報告するのではなく、60 秒間隔で取得される現在の接続状態のスナップショットを公開します。 異なるシーケンス番号で同じ接続状態イベントを受信する場合も、異なる接続状態イベントを受信する場合も、60 秒の期間中にデバイスの接続状態が変化したことを示します。

ルートのテスト

新しいルートを作成したり、既存のルートを編集したりする場合は、サンプル メッセージを使用してルート クエリをテストする必要があります。 個々のルートをテストすることも、すべてのルートを一度にテストすることも可能で、テスト中にメッセージがエンドポイントにルーティングされることはありません。 テストには、Azure portal、Azure Resource Manager、Azure PowerShell、および Azure CLI を使用することができます。 結果は、サンプル メッセージがクエリに一致したか一致しなかったか、サンプル メッセージまたはクエリ構文が正しくないためにテストを実行できなかったかを識別するのに役立ちます。 詳細については、ルートのテストに関するページとすべてのルートのテストに関するページを参照してください。

Latency

device-to-cloud テレメトリ メッセージをルーティングすると、最初のルートの作成後にエンド ツー エンドの待ち時間が若干上昇します。

ほとんどの場合、待機時間の増加は平均で 500 ミリ秒未満です。 ただし、発生する待機時間は、お使いの IoT ハブのレベルとお使いのソリューション アーキテクチャに応じて異なる場合があり、さらに長くなる可能性があります。 待ち時間は、Routing: message latency for messages/events (ルーティング: メッセージ/イベントのメッセージ待機時間) または d2c.endpoints.latency.builtIn.events という IoT Hub メトリックを使用して監視することができます。 最初のルーティング後にルーティングを作成または削除してもエンド ツー エンドの待機時間には影響しません。

監視とトラブルシューティング

IoT Hub には、ハブの正常性と送信されたメッセージの概要を示す、ルーティングおよびエンドポイント関連のメトリックがいくつか用意されています。 また、IoT Hub リソース ログのルート カテゴリでは、IoT Hub によって認識された、ルーティング クエリとエンドポイントの正常性の評価中に発生したエラーを追跡できます。 IoT Hub でのメトリック ログとリソース ログの使用の詳細については、「Azure IoT Hub の監視」を参照してください。

REST API の Get Endpoint Health を使って、エンドポイントの正常性状態を取得できます。

ルーティングのトラブルシューティングに関する詳細とサポートが必要な場合、ルーティングのトラブルシューティング ガイド ページを参照してください。