IoT Hub メッセージ ルーティングを使用して device-to-cloud メッセージを別のエンドポイントに送信する

Note

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

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

  • デバイスのテレメトリ メッセージだけでなくイベント (デバイス ライフサイクル イベント、デバイス ツイン変更イベント、デジタル ツイン変更イベント、およびデバイス接続状態イベント) を組み込みのエンドポイントとカスタム エンドポイントに送信する。 ルーティング エンドポイントについて確認してください。 IoT プラグ アンド プレイ デバイスから送信されるイベントの詳細については、「IoT プラグ アンド プレイのデジタル ツインを理解する」を参照してください。

  • リッチ クエリを適用して、さまざまなエンドポイントにルーティングする前にデータをフィルター処理する。 メッセージ ルーティングでは、メッセージ プロパティとメッセージ本文に基づいてクエリを実行できるほか、デバイス ツインのタグとプロパティに基づいてクエリを実行することもできます。 メッセージ ルーティングでクエリを使用する方法の詳細について確認してください。

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

IoT ハブでは、各種プロトコルにおける相互運用性を確保するためにすべての device-to-cloud メッセージ用の共通形式が定義されています。 メッセージが、同じエンドポイントを指している複数のルートと一致する場合、IoT Hub はそのエンドポイントにメッセージを 1 回だけ送信します。 そのため、Service Bus キューまたはトピックで重複除去を構成する必要はありません。 このチュートリアルを使用して、メッセージ ルーティングを構成する方法について学習してください。

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

IoT ハブには、Event Hubs との互換性がある、既定の組み込みのエンドポイント (messages/events) があります。 サブスクリプション内の他のサービスを IoT ハブにリンクして、メッセージのルーティング先となるカスタム エンドポイントを作成することができます。

各メッセージは、一致するルーティング クエリを持つすべてのエンドポイントにルーティングされます。 つまり、メッセージは複数のエンドポイントにルーティングできます。

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

IoT Hub では現在、次のエンドポイントがサポートされています。

  • 組み込みのエンドポイント
  • Azure Storage
  • Service Bus キューと Service Bus トピック
  • Event Hubs

ルーティング エンドポイントとしての組み込みのエンドポイント

標準的な Event Hubs 統合と SDK を使用して、組み込みのエンドポイント (messages/events) から device-to-cloud メッセージを受信することができます。 ルートの作成後、組み込みのエンドポイントへのルートが作成されていないと、そのエンドポイントへのデータ フローは停止します。 ルートが作成されていない場合でも、組み込みのエンドポイントにメッセージをルーティングするために、フォールバック ルートを有効にする必要があります。 ポータルまたは CLI を使用してハブを作成した場合、フォールバックは既定で有効になります。

ルーティング エンドポイントとしての Azure Storage

IoT Hub がメッセージをルーティングできるストレージ サービスとして、Azure Blob Storage アカウントと Azure Data Lake Storage Gen2 (ADLS Gen2) アカウントの 2 つがあります。 Azure Data Lake Storage アカウントは、BLOB ストレージ上に構築された、階層型名前空間に対応したストレージ アカウントです。 これらはどちらも、そのストレージとして BLOB を使用します。

IoT Hub は、Apache Avro 形式と JSON 形式での Azure Storage へのデータの書き込みをサポートしています。 既定値は AVRO です。 JSON エンコードを使用する場合は、メッセージのシステム プロパティで contentType を application/json に設定し、contentEncoding を UTF-8 に設定する必要があります。 これらのどちらの値でも大文字と小文字は区別されません。 コンテンツのエンコードが設定されていない場合、IoT Hub では Base 64 エンコード形式でメッセージが書き込まれます。

このエンコード形式は、Blob Storage エンドポイントが構成されている場合にのみ設定できます。既存のエンドポイントに応じて編集することはできません。 既存のエンドポイントのエンコード形式を切り替えるには、エンドポイントを削除してから、必要な形式で再作成する必要があります。 便利な方法の 1 つとして、目的のエンコード形式で新しいカスタム エンドポイントを作成し、そのエンドポイントに並列ルートを追加する方法があります。 これにより、既存のエンドポイントを削除する前にデータを確認できます。

エンコード形式は、IoT Hub の作成または更新 REST API (具体的には RoutingStorageContainerProperties)、Azure portalAzure CLI、または Azure PowerShell を使用して選択できます。 次の画像は、Azure portal でエンコード形式を選択する方法を示しています。

Blob storage endpoint encoding

IoT Hub は、バッチが特定のサイズに達するか、または一定の時間が経過すると常に、メッセージを一括処理してストレージにデータを書き込みます。 IoT Hub の既定のファイル名前付け規則は次のとおりです。

{iothub}/{partition}/{YYYY}/{MM}/{DD}/{HH}/{mm}

任意のファイル名前付け規則を使用可能ですが、一覧で示されているすべてのトークンを使う必要があります。 書き込むデータがない場合、IoT ハブは空の BLOB に書き込みます。

パーティションを前提にすることなくすべての BLOB またはファイルが確実に読み取られるようにするために、BLOB またはファイルは一覧表示してから反復処理することをお勧めします。 Microsoft が開始するフェールオーバー中や IoT Hub の手動フェールオーバー中にパーティションの範囲が変わる可能性があります。 List Blobs API を使用して BLOB の一覧を、または List ADLS Gen2 API を使用してファイルの一覧を列挙できます。 ガイダンスとして次のサンプルを参照してください。

public void ListBlobsInContainer(string containerName, string iothub)
{
    var storageAccount = CloudStorageAccount.Parse(this.blobConnectionString);
    var cloudBlobContainer = storageAccount.CreateCloudBlobClient().GetContainerReference(containerName);
    if (cloudBlobContainer.Exists())
    {
        var results = cloudBlobContainer.ListBlobs(prefix: $"{iothub}/");
        foreach (IListBlobItem item in results)
        {
            Console.WriteLine(item.Uri);
        }
    }
}

Azure Data Lake Gen2 と互換性のあるストレージ アカウントを作成するには、次の図に示すように、新しい V2 ストレージ アカウントを作成し、 [詳細] タブで [階層型名前空間] フィールドの [有効] を選択します。

Select Azure Date Lake Gen2 storage

ルーティング エンドポイントとしての Service Bus キューと Service Bus トピック

IoT Hub エンドポイントとして使用される Service Bus のキューおよびトピックでは、セッション重複データ検出も有効にしないでください。 これらのオプションのいずれかが有効になっている場合、エンドポイントは Azure Portal に到達不能として表示されます。

ルーティング エンドポイントとしての Event Hubs

組み込みの Event Hubs 互換エンドポイントとは別に、Event Hubs タイプのカスタム エンドポイントにデータをルーティングすることもできます。

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

このチュートリアルに従って、ルートを構成することができます。

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

フォールバック ルート

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

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 に認識されたルーティング クエリとエンドポイントの正常性の評価中に発生したエラーを追跡することができます。 IoT Hub でのメトリック ログとリソース ログの使用の詳細については、IoT Hub の監視に関するページを参照してください。

REST API の GetEndpointHealth を使用して、エンドポイントの正常性状態を取得できます。

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

次のステップ