IoT ワークロードのパフォーマンス効率
IoT ソリューションには、デバイス、エッジ、クラウドのコンポーネントが含まれており、クラウドに接続されている数百万台の小さなデバイスから、いくつかの強力なサーバーがクラウド接続のゲートウェイである産業用ソリューションまで多岐に及びます。 デバイスの数、物理的および地理的な配置、および送受信するメッセージの数は、IoT ワークロードのパフォーマンス効率を定義できる要因の一部です。
パフォーマンス効率には、需要に合わせて効率的にスケーリングする IoT ワークロードの機能も含まれます。 クラウドの利点は、地理的な可用性と、アプリケーションのダウンタイムがほとんどまたはまったくないオンデマンドでサービスをスケーリングできることです。
パフォーマンス効率は、指定された条件下でのリソースの使用に対するパフォーマンスを表します。 パフォーマンス効率は、製品またはシステムが機能を実行する際に、次の要件をどの程度満たしているかを測定します。
応答時間、処理時間、スループット レートなどの時間の動作。
リソース使用率、または使用されるリソースの量と種類。
容量、または最大制限。
IoT ワークロードのパフォーマンス効率を評価する
Well-Architected Framework のパフォーマンス効率の柱のレンズを通じて IoT ワークロードを評価するには、 Azure Well-Architected Review で IoT ワークロードのパフォーマンス効率に関する質問を完了します。 評価で IoT ソリューションの主要なパフォーマンス効率に関する推奨事項が特定されたら、次のコンテンツを使用して推奨事項を実装します。
設計原則
アーキテクチャの卓越性の 5 つの柱 が、IoT ワークロードの設計手法を支える。 これらの柱は、 主要な IoT 設計領域全体で後続の設計上の決定を行うためのコンパスとして機能します。 次の設計原則は、Azure Well-Architected Framework - パフォーマンス効率の品質の柱を拡張します。
| 設計原則 | 考慮事項 |
|---|---|
| 水平スケーリングの設計 | IoT ソリューションは、数百のデバイスまたはメッセージから始まり、1 分あたり何百万ものデバイスとメッセージに拡張できます。 クラウド サービスは負荷の増加に合わせて簡単にスケーリングできますが、IoT デバイスとゲートウェイでは状況が複雑になる可能性があります。 IoT デバイスは、ソリューションが完成する前に設計またはデプロイできます。 産業用 IoT または同様の業界では、数十年でデバイスの寿命を測定できます。 デバイスを交換して容量を更新すると、コストがかかります。 これらのシナリオでは、先に計画することが特に重要です。 |
| パフォーマンス テスト時に Shift キーを押しながら左へ移動 | 早期にテストし、問題を早期にキャッチするために頻繁にテストします。 通信の特性、速度、信頼性が異なる地理的に異なる場所にセンサー、デバイス、ゲートウェイを配置する複雑さに注意してください。 テストでこの複雑さを計画し、ネットワーク切断などの障害シナリオをテストしてください。 IoT ソリューション内のすべてのデバイス、エッジ、クラウド コンポーネントのストレステストとロード テストを行います。 |
| 運用環境のパフォーマンスを継続的に監視する | 複数の地理的リージョンのさまざまな種類のデバイスを監視するには、分散監視ソリューションを使用します。 監視され、クラウドに送信される情報の量と、メモリとパフォーマンスのコストのバランスを取ります。 診断シナリオの送信を調整し、複数のレベルとレイヤーで監視します。 産業用ソリューションまたはゲートウェイ対応ソリューションのゲートウェイ メトリックを公開します。 |
IoT アーキテクチャ レイヤー
パフォーマンス効率設計の原則は、 IoT ワークロードが基本的な IoT アーキテクチャ レイヤー全体の要件を満たしていることを確認するための考慮事項を明確にするのに役立ちます。 次のセクションでは、パフォーマンス効率の柱のレイヤーの詳細について説明します。
デバイスとゲートウェイのレイヤー
IoT デバイスは、IoT ソリューションに接続し、データの収集、送信、または受信を行うことができるコンピューティング デバイスです。 ゲートウェイは、デバイスとクラウド間、または IoT と他のコンポーネント間の接続ポイントです。
ハードウェア機能を最適化する
ハードウェアのアップグレードまたは交換には、コストと時間がかかります。 必要な容量と機能のために IoT デバイスのサイズを事前に設定します。
ハードウェア機能を最適化するには:
特定のハードウェアでコンピューティングおよび入出力集中型タスクを実行します。 たとえば、ローカル グラフィックス処理装置 (GPU) で機械学習 (ML) アルゴリズムを実行します。
Embedded C や Rust Embedded などの効率的な言語とフレームワークを使用して、既存のハードウェア機能を最適化します。 Azure IoT Embedded C SDK は、制約付きデバイス用に開発する場合、またはほとんどのセキュリティと通信スタックが既にデバイスで使用できる場合に使用できます。
クラウド ゲートウェイに接続するために必要なすべてについて、 Azure IoT device SDK for C を使用します。 Azure IoT Device ソフトウェア開発キット (SDK) は、回復性のある接続に必要な必要なメッセージ変換、エラー処理、再試行メカニズムを管理します。
スケーリングは、デバイス層とゲートウェイ層にとって重要です。 このレイヤーをスケーリングするには:
ゲートウェイをスケールの単位として使用します。 ソリューションで IoT デバイスまたは資産 ( OPC UA サーバーなど) が時間の経過と同時に追加される場合は、より多くのエッジ ゲートウェイを使用してそれらのサーバーからデータを取り込みます。
クラウド ゲートウェイやクラウド サービスを含むすべてのアップストリーム レイヤーに対してスケール評価を実施します。 IoT ソリューションのスケール ユニットとして複数の IoT ハブを使用する方法の詳細については、「IoT ハブ間でデバイスをプロビジョニングする方法」を参照してください。
エッジでワークロードを実行する
ネットワーク スループットや待機時間などのシステム制約に応じて、エッジで一部のワークロードを実行することを検討してください。 時間制約と必要な待機時間と応答時間でワークロードを分離します。 待機時間が短く、断続的に接続されるシナリオには、ローカル コンピューティングを使用します。 クラウドで大規模なワークロードを実行する。
エッジでは、優先度キューを使用して、必要な順序で異なるデータ ストリームを送信します。 優先度の高いキューでは、メッセージは優先順位の順に送信されますが、Azure IoT Hubは引き続き受信順に基づいてメッセージをジャーナル処理します。
デバイスの接続を最適化する
デバイスの接続を最適化するには、次の点を考慮してください。
デバイスの待機時間が最も短い IoT Hubs を使用します。 デバイスが異なる地理的な場所から接続する必要がある場合は、複数のリージョンで IoT Hubs が必要になる場合があります。
デバイスと IoT ソリューション間の双方向通信には、オープンステートフル接続を使用して、接続を設定するオーバーヘッドを最小限に抑えます。
リージョンの停電後など、すべてのデバイスを一度に接続しないでください。 再試行時に、切り捨てられた指数バックオフを使用し、ジッターが発生します。
オフライン シナリオを最適化する
クラウド接続なしで動作し、データをローカルに格納するのに十分な情報とコンテキストをデバイスに提供できるため、切断や再起動から回復できます。 オフライン操作をサポートする戦略を次に示します。
デバイスが接続されていない場合に、デバイスがローカルにデータを格納できることを確認します。これには、優先順位に従ったログとキャッシュされたテレメトリが含まれます。
有効期限が切れたデータが自動的に削除されるように、データの有効期間 (TTL) を設定します。
デバイスが接続されていないときに重要度の低いデータを破棄して、必要なローカル ストレージを減らし、デバイスが再接続するときの同期時間を短縮します。
エッジ デバイス ストレージが容量に達した場合は、先入れ先出し (FIFO)、先入れ先出し (LIFO)、優先度ベースなどのキャッシュ削除戦略を使用します。
記憶域が不足している場合でもデバイス ランタイムまたはアプリケーションが引き続き機能するように、別のディスクまたはディスク コントローラーを使用してデータを格納することを検討してください。
デバイス ツインとモジュール ツインを使用して、デバイスが現在クラウド ゲートウェイに接続されていない場合でも、デバイスとクラウドの間で状態情報を非同期的に同期します。 デバイス ツインとモジュール ツインには、特定の時点の現在の状態のみが含まれており、履歴や削除された情報は含まれません。
インジェストと通信のレイヤー
データ インジェストと通信レイヤーは、デバイスから IoT ソリューションにデータを送信します。 デバイスと IoT ソリューション間の通信パターンは次のとおりです。
- デバイスからクラウドへのメッセージ。
- cloud-to-device メッセージ
- ファイルのアップロード。
- デバイス ツイン。
- ダイレクト メソッド。
メッセージングの効率を最適化する
デバイスからクラウドへのメッセージの数とサイズは、IoT ソリューションのパフォーマンス効率にとって重要なパラメーターです。 IoT Hubや Azure IoT Central などの Azure IoT サービスでは、レベルごとのメッセージ制限が定義されており、ソリューションのパフォーマンスとコストの両方に影響します。
次のメッセージングの推奨事項を検討してください。
IoT Hubと IoT Central では、4 KB のメッセージ サイズに基づいて毎日のクォータ メッセージ数が計算されます。 小さいメッセージを送信すると、容量が使用できなくなります。 一般に、4 KB 境界に近いメッセージ サイズを使用します。 小さいデバイスからクラウドへのメッセージを大きなメッセージにグループ化してメッセージの合計数を減らしますが、メッセージを結合するときに発生する待機時間を考慮してください。
おしゃべりなコミュニケーションは避けてください。 デバイス間通信またはモジュール間エッジ通信の場合は、多数の小さなメッセージを送信する相互作用を設計しないでください。
Advanced Message Queuing Protocol (AMQP) の組み込みの Azure IoT Edge SDK メッセージ バッチ処理を使用して、複数のテレメトリ メッセージをクラウドに送信します。
ダウンストリーム デバイスで複数の小さなメッセージを組み合わせ、より大きなメッセージをエッジ ゲートウェイに送信することで、アプリケーション レベルのバッチ処理を使用します。 このバッチ処理により、メッセージのオーバーヘッドが制限され、ローカル エッジ ディスク ストレージへの書き込みが減ります。
AMQP 接続の多重化を使用して、SDK クライアントごとの伝送制御プロトコル (TCP) 接続の制限への依存を減らします。 AMQP 接続多重化では、複数のデバイスで 1 つの TCP 接続を使用してIoT Hubできます。
ユーザーが指定したタイムアウトの直後に成功または失敗する可能性がある要求/応答操作には、ダイレクト メソッドを使用します。 この方法は、デバイスが応答したかどうかによってアクションの経過が異なるシナリオに役立ちます。
デバイス ツインは、メタデータや構成など、デバイスの状態情報に使用します。 IoT Hubは、接続するデバイスごとにデバイス ツインを維持します。
メッセージング クォータと調整について理解する
IoT Hub層は、クラウド ゲートウェイのユニットごとの制限を設定します。 メッセージング クォータ は、階層の持続的なスループットと継続的な送信速度を定義します。 IoT Hubは、バーストまたは負荷オーバーシュートを回復性のある方法で処理するために、これらのクォータを超える負荷を短時間処理できます。
もう 1 つの重要な制限は、時間単位または毎日のサービス負荷または スロットル 制限です。 スロットル制限により、IoT ハブが長すぎる負荷から保護されます。
次の図は、負荷、クォータ、スロットルの制限の関係を示しています。 左側の図は、IoT Hubが、IoT Hub レベルのクォータ レベルまでの持続的または一定の高負荷を処理できることを示しています。 右の図は、IoT Hubがスロットル制限に達せず、平均してIoT Hubレベルのクォータを超えていない限り、時間の経過と伴って変化する負荷を処理できることを示しています。
メッセージ処理を最適化する
デバイスまたはゲートウェイからのメッセージは、ストレージの前に、より多くの情報を使用して変換、処理、またはエンリッチする必要がある場合があります。 この手順は時間がかかる可能性があるため、パフォーマンスへの影響を評価することが重要です。 一部の推奨事項は競合します。たとえば、データ転送を最適化するための圧縮の使用や、メッセージの暗号化解除でのクラウド処理の回避などです。 これらの推奨事項は、他のアーキテクチャの柱とソリューション要件に対してバランスを取って評価する必要があります。
クラウド データ処理のパフォーマンスを最適化するには:
クラウドにデータを送信するために使用されるデータ形式を最適化します。 必要なクラウド データ処理を少なくして、帯域幅のパフォーマンス (およびコスト) とパフォーマンスの向上を比較します。 メッセージ エンリッチメントIoT Hub使用して、デバイス メッセージにコンテキストを追加することを検討してください。
未処理のデータを格納し、複雑なクエリでデータを取得する必要がある代わりに、取り込まれたデータに対してタイム クリティカルなイベント処理を行います。 タイム クリティカルなイベント処理の場合は、到着遅延とウィンドウ化の影響を考慮してください。 クリティカル アラーム処理やメッセージ エンリッチメントなど、ユース ケースに応じて評価します。
ソリューションの要件に基づいて、適切なIoT Hubレベル (Basic または Standard) を選択します。 Basic レベルでサポートされていない機能に注意してください。
適切なIoT Hub層サイズ、1、2、または 3、およびデータ スループット、クォータ、操作スロットルに基づいてインスタンスの数を選択します。 IoT Central の場合は、デバイスからクラウドに送信されたメッセージの数に基づいて、適切なレベル (Standard 0、Standard 1、Standard 2) を選択します。
パブリッシュ/サブスクライブ イベント ルーティングにAzure Event Gridを使用することを検討してください。 詳細については、「Event Grid を使用してアクションをトリガーしてイベントをIoT HubするReact」および「メッセージ ルーティングと Event Grid をIoT Hubと比較する」を参照してください。
データに優先順位を付ける
デバイスがクラウドに送信する一部のデータは、他のデータよりも重要な場合があります。 優先順位に基づいてデータを分類して処理することは、パフォーマンス効率を高める良い方法です。
たとえば、サーモスタット センサーは温度、湿度、その他のテレメトリを送信しますが、温度が定義された範囲外の場合もアラームを送信します。 システムはアラーム メッセージを優先度が高いと分類し、温度テレメトリとは異なる方法で処理します。
データの分類と処理に関する次の推奨事項を検討してください。
IoT Edge優先度キューを使用して、IoT Hubへの送信中に重要なデータの優先順位が設定されていることを確認します。 IoT Edgeは、接続がない場合にメッセージをバッファーしますが、接続が復元された後に、バッファー内のすべてのメッセージを優先順に送信し、その後に新しいメッセージを送信します。
メッセージ ルーティングIoT Hub使用して、ユース ケースに応じて異なるデータ優先度のルートを分離します。 メッセージ ルーティングIoT Hubすると、待機時間が少し長くなります。
より長い間隔で、またはバッチまたはファイルのアップロードを使用して、優先度の低いデータを保存して送信します。 アップロードされたファイルに対するマルウェア検出により、待機時間が長くなります。
時間制約に基づいてメッセージを分離します。 たとえば、時間制約がある場合にメッセージをIoT Hubに直接送信し、時間制約がない場合はAzure Data FactoryのようなIoT Hubまたはバッチ データ転送を使用してファイルのアップロードを利用します。 ファイルのアップロードには、IoT Edge BLOB モジュールを使用できます。
デバイス管理とモデリングのレイヤー
さまざまな種類のデバイスが IoT ソリューションに接続でき、IoT ソリューションは多数のデバイスとゲートウェイに同時に接続できます。 IoT ソリューションは、デバイスとゲートウェイの接続と構成に加えて、デバイスとゲートウェイがキャプチャして取り込むデータを理解し、そのデータを転送してコンテキスト化する必要があります。
IoT コンポーネントでは、さまざまなプロトコル、接続、データ インジェスト頻度、および通信パターンを使用できます。 IoT ソリューションは、接続されているデバイスとゲートウェイ、およびそれらの構成方法を管理できる必要があります。
パフォーマンス効率を高めるためにデバイスと構成を管理するには:
デバイスとメッセージの読み込みに基づいてサイズを最適化します。
層とユニット数に応じて、クラウド ゲートウェイが処理できるメッセージの数を把握します。
データ分散、季節性、バーストによる持続的スループットの異常を考慮します。
IoT ソリューションで何百万ものデバイスを管理する必要がある場合は、複数のクラウド ゲートウェイを使用します。 DPS を使用して IoT ハブにデバイスを割り当てます。
DPS を使用してデバイスをプロビジョニングする
プロビジョニング中、IoT Hub接続が使用できなくなった場合、またはデバイスの再起動中に、DPS を使用して IoT ハブへの接続を設定します。
DPS 均等重み付け配布ポリシーを使用して、ユース ケースに基づいてプロビジョニングの重みを調整します。 詳細については、「 割り当てポリシーが IoT Hubs にデバイスを割り当てる方法」を参照してください。
DPS の負荷とクォータのバランスを取るために、一定期間にわたって分散または小規模なバッチでデバイスを IoT ソリューションにプロビジョニングすることを検討してください。 バッチでオンボードする場合は、バッチと全体的な移行タイムラインを計画します。 待機時間や再試行を含む、1 分あたりの操作数、デバイス登録、最大接続数の DPS 制限を考慮します。
DPS を使用して、待機時間に基づいて異なるリージョンの IoT Hub にデバイスを割り当てます。
DPS 再接続操作を減らすには、DPS 接続文字列のキャッシュ戦略を使用します。
ダウンストリーム デバイスを管理する
IoT ソリューションは、サイトまたは場所ごとに複数のゲートウェイまたはエッジ デバイスがあり、これらのゲートウェイまたはエッジ デバイスのいずれかに接続できるダウンストリーム デバイスがある場合、水平方向にスケーラブルです。
ダウンストリーム デバイスの数、メッセージとメッセージ サイズが時間の経過と同時に変化し、プロトコルまたはメッセージを 変換 する必要がある場合は、変換モードで複数のゲートウェイとエッジ デバイスを使用します。 変換モードのゲートウェイとエッジ デバイスは、ダウンストリーム デバイスとの間でプロトコルまたはメッセージを変換できますが、ダウンストリーム デバイスが接続されているゲートウェイを見つけるにはマッピングが必要です。 変換モードを使用する場合に、ゲートウェイまたはエッジ デバイスで追加されたメッセージ変換とバッファーオーバーヘッドを考慮します。
複数のゲートウェイとエッジ デバイスを 透過的 モードで使用して、ダウンストリーム のメッセージ キュー テレメトリ トランスポート (MQTT) または AMQP デバイスを接続します。その数は、サイトまたは場所ごとに時間の経過と同時に変化する可能性がある場合です。 透過的モードのゲートウェイとエッジ デバイスは、双方向通信のために MQTT/AMQP デバイスを接続できます。 透過的モードを使用する場合に、ゲートウェイまたはエッジ デバイスで追加されたメッセージ バッファリング、ストレージ、および構成オーバーヘッドを考慮します。
Transport layer
トランスポート層は、デバイスと IoT ソリューション間の接続を処理し、IoT メッセージをネットワーク パッケージに変換し、物理ネットワーク経由で送信します。 IoT ソリューションでは、一般的に AMQP および MQTT 接続プロトコルが使用されます。
リソースの使用を最適化する
デバイスとクラウド間の接続は、対象となる数のデバイスとメッセージを処理するために、セキュリティで保護され、信頼性が高く、スケーラブルである必要があります。
デバイスからクラウド ゲートウェイへのオープンステートフル接続を使用します。 IoT Hubは、MQTT、AMQP、または WebSocket プロトコルを使用して、何百万ものオープンステートフル接続を管理するために最適化されています。 セキュリティ ハンドシェイク、認証、承認のオーバーヘッドを最小限に抑えるために、デバイスへのオープン接続を維持します。 この方法により、パフォーマンスが向上し、必要な帯域幅が大幅に削減されます。
1 つの接続で複数のチャネルの多重化をサポートする AMQP プロトコルを使用して、クラウド ゲートウェイで必要な開いている接続の数を最小限に抑えます。 多重化を使用すると、透過的ゲートウェイは、1 つの接続で独自のチャネルを使用して複数のリーフ デバイスを接続できます。
デバイスとモジュール ツインのクラウド ゲートウェイ パターンを使用して、デバイスとクラウドの間で状態情報を非同期的に交換します。
デバイスが別のクラウド ゲートウェイに接続したときにデバイスの状態を移動するように DPS を構成します。
データ通信を最適化する
デバイスからクラウドへのメッセージの数とサイズは、パフォーマンスとコストに影響します。 データ通信の評価は、IoT ワークロードのパフォーマンス効率の鍵となります。
クラウドにデータを送信するために広範な帯域幅を使用しない効率的なデータ形式とエンコードを使用します。 低帯域幅ネットワークの場合は、圧縮形式またはバイナリ形式を使用することを検討しますが、クラウドでデータを圧縮解除または変換するオーバーヘッドを理解してください。
大量のデータをローカルに格納し、1 時間または 1 日にアップロードすることを検討してください。
多数の小さなデバイスからクラウドへのメッセージを少数の大きなメッセージにグループ化して、合計数を減らします。 ただし、大きなメッセージのみを送信するのではなく、平均メッセージ サイズとスループットのバランスを取ります。
ストレージ レイヤー
IoT ソリューションで収集および参照されるさまざまな種類のデータには、多くの場合、デバイス、ゲートウェイ、クラウド上のさまざまなシナリオに特化して最適化されたストレージの種類が必要です。 複数の地理的リージョンでグローバルまたはローカルで使用できる必要があり、場合によっては待機時間を最適化するためにレプリケートされるデータにより、IoT ストレージの複雑さが増します。
タイムスタンプと値を含む時系列データを格納する場合は、時系列データベースを使用します。 CustomerID、RoomID、その他のユース ケース固有の列など、フィルター処理用の列を使用して時系列データ テレメトリを強化します。
データをキャッシュしたり、切断時にデータを保持したりするには、デバイスとゲートウェイのストレージを使用します。 必要なストレージ領域のアカウント。 すべてのデータを保持するのではなく、ダウンサンプリングを使用するか、集計のみを格納するか、限られた期間のデータを格納します。
データ インジェストとイベント処理ストレージをレポートと統合ストレージのニーズから分離することを検討してください。
必要なスループット、サイズ、保持期間、データ ボリューム、CRUD 要件、リージョン レプリケーションのニーズに合ったデータ ストレージの種類を使用します。 たとえば、Azure Data Lake Storage、Azure Data Explorer、Azure SQL、Azure Cosmos DB などです。
イベント処理と分析レイヤー
IoT ソリューションとの間で送信する前に、デバイスによって生成されるデータを処理できます。 データ処理には、翻訳、コンテキスト化、フィルター処理とルーティング、傾向分析や異常検出などのより高度な分析が含まれます。
エッジとクラウドの処理を最適化する
ローカル コンピューティングを使用して、デバイスまたはエッジで、リアルタイムおよびほぼリアルタイムのワークロード、または時間制約を伴う小さく最適化された低待機時間の処理を実行します。 クラウドで、大規模なワークロード、または外部データまたはコンピューティング依存関係を追加した他のワークロードを実行します。
たとえば、エッジで機械学習アルゴリズムを実行してビデオ ストリーム内のユーザーをカウントし、カウントを含むイベントをクラウドに送信します。 クラウドを使用して、さまざまなファクトリ間の傾向を比較します。
Stream Analytics Edge モジュールを使用して、エッジで分析ワークロードを実行します。 たとえば、エッジで異常検出を実行し、検出された異常を使用してクラウドに送信されたイベントにラベルを付けることができます。 エッジで分析を実行する場合は、追加の待機時間、到着遅延、ウィンドウへの影響を考慮します。
多数のダウンストリーム デバイスが接続されているエッジ ワークロードのオーバーヘッドに注意してください。 エッジ ノードは、すべてのメッセージを転送または処理し、断続的なクラウド接続がある場合にすべてのデータのキャッシュを処理する必要があります。 エッジ ノードあたりのダウンストリーム デバイスとメッセージの計画された最大値を使用してテストすることで、ソリューションに対するパフォーマンスへの影響を検証します。 メッセージ変換またはエンリッチメントがエッジ、IoT Hub、またはクラウド イベント処理に与える可能性があるパフォーマンスへの影響に注意してください。
個々のワークロードを分類する
時間制約と必要な待機時間と応答時間でワークロードを分離します 。たとえば、1 時間あたりのバッチと秒内の応答などです。 ハイブリッド ハードウェア システムオンチップ (SoC) は、デバイス レベルのワークロードをサポートできます。
エッジでは、優先度キューを使用して、優先順位と TTL が異なる異なるデータ ストリームを分離します。 たとえば、アラームは常に最初に送信する必要がありますが、TTL はテレメトリよりも低くなります。
クラウドでは、Azure Event Hubsのコンシューマー グループを使用して、さまざまなデータ ストリームを分離し、テレメトリとは異なる方法でアラームを処理およびスケーリングできます。 また、IoT Hub ルートを使用して、フィルター処理と個別のエンドポイントを使用して、異なるデータ ストリームを分離することもできます。 メッセージ ルーティングIoT Hub、待機時間が増加します。 Event Hubs、Azure Event Grid、またはAzure Service Busを使用して、クラウドの背圧から保護しながらワークロードを分散します。
過度に複雑なIoT Hubルーティング規則は、スループットに影響を与える可能性があります。特に、すべてのメッセージを逆シリアル化してスキャンする必要があるメッセージ本文 JSON フィルターを使用したルーティング規則。
大量のクラウド データを処理する
大量のクラウド データのパフォーマンス効率を最適化するには:
IoT Hubと、高パフォーマンススループット用に既に最適化されているAzure Data Lake Storageや Azure Data Explorerなどのデータ変換先との間で、すぐに使用できるサービス統合を使用します。
Event Hubs SDK を使用して、含まれているイベント プロセッサを使用して IoT ハブからカスタム インジェストを開発します。 イベント プロセッサは、デバイスとホストを再調整できます。
同時データ リーダーの数と必要なスループットには、適切な数のIoT Hub パーティションとコンシューマー グループを使用します。
データ インジェストとイベント処理に必要なストレージと、レポートと統合に必要なストレージを分離します。
必要なスループット、サイズ、保持期間、データ ボリューム、CRUD 要件、リージョン レプリケーションに基づいて、ニーズに合ったデータ ストレージを使用します。 たとえば、Azure Data Lake Storage、Azure Data Explorer、Azure SQL、Azure Cosmos DB などです。 詳細については、「 アプリケーションの Azure データ ストアを選択する」を参照してください。
統合レイヤー
統合レイヤーは、IoT ソリューションを他のサービスやビジネス アプリケーションに接続します。
IoT ソリューション インジェスト パイプラインを統合処理から分離します。 複雑なクエリまたは統合レイヤーからの読み込みがデータ インジェストのパフォーマンスに影響しないことを確認します。
IoT データとコマンドにアクセスするには、適切に定義されたバージョン管理された API を使用します。
エンド ユーザーが IoT データ ストレージに対してユーザー定義クエリを作成するためのツールは避けてください。 統合とレポート用に個別のデータ ストアを使用することを検討してください。
DevOps レイヤー
パフォーマンス効率を最大化するには、次の DevOps メカニズムを使用します。
コンテナー イメージのローカル キャッシュとデプロイ用の 接続されたレジストリ 。
デバイスやゲートウェイなど、複数のデバイスへの展開を一度に更新するIoT Hub。
デバイス ツインとモジュール ツインを使用して、スケーラブルで効率的な方法でデバイス構成を更新します。
場所や異種デバイスなどの運用環境をレプリケートするためのストレス テストやロード テストを含むパフォーマンス テスト。
監視
Azure Monitor を使用して、重要なメトリックのアラートを含むIoT Hubメトリックを収集します。 デバイスからクラウドへの 1 秒あたりの送信メッセージなど、現在のスケール制限に基づいて Azure Monitor アラートを設定します。 今後のスケーラビリティの制限を事前に通知するために、アラートを制限の割合 (75% など) に設定します。 また、調整エラーの数などのログとメトリックに対する Azure Monitor アラートを設定します。
状態が変更されたときに通知をトリガーするように Azure Service Health サービスアラートIoT Hub設定します。