IoT Hub と信頼性
Azure IoT Hub は、クラウドでホストされるマネージド サービスであり、IoT アプリケーションとその接続されたデバイス間の通信のための中央メッセージ ハブとして機能します。 何百万ものデバイスとそのバックエンド ソリューションを確実かつ安全に接続できます。 ほぼすべてのデバイスを IoT Hub に接続できます。
IoT Hub では、デバイスの作成、デバイス接続、デバイスの障害の追跡に役立つ監視がサポートされています。
IoT Hub では、次のメッセージング パターンもサポートされています。
- デバイスからクラウドへのテレメトリ
- デバイスからのファイルのアップロード
- クラウドからデバイスを制御するための要求/応答メソッド
IoT Hub の詳細については、「IoT の概念 Azure IoT Hub」を参照してください。
IoT Hub で信頼性の高いワークロードがどのようにサポートされるかを理解するには、次のトピックを参照してください。
- IoT Hub の高可用性とディザスター リカバリー
- IoT Hub を使用してリージョン間の高可用性を実現する方法
- Azure IoT Hub を別のリージョンに複製する方法
次のセクションは、Azure IoT Hub と信頼性に固有のものです。
- 設計に関する考慮事項
- 構成チェックリスト
- 推奨される構成オプション
設計に関する考慮事項
Azure IoT Hub サービス レベル アグリーメントの詳細については、Azure IoT Hub
チェックリスト
信頼性を念頭に置いて Azure IoT Hub を構成しましたか?
- 別のリージョンに 2 つ目の IoT Hub をプロビジョニングし、デバイスにルーティング ロジックを設定します。
- イベントを頻繁に送信するときは、
AMQPまたはMQTTプロトコルを使用します。 - デバイス接続に X.509 証明書
使用している場合は、運用環境でルート CA によって検証された証明書のみを使用します。 - 最大スループットを得るために、組み込みエンドポイントを使用する予定の場合は、IoT Hub の作成時に最大パーティション数 (
32) を使用します。 - スケーリングの場合は、リージョンごとに複数の IoT Hub を追加するのではなく、レベルと割り当てられた IoT Hub ユニットを増やします。
- 高スループットのシナリオでは、バッチ 処理されたイベントを使用します。
- 可能な最小限の待機時間が必要な場合は、ルーティングを使用せず、組み込みのエンドポイントからイベントを読み取ります。
- ソリューション全体の可用性とディザスター リカバリー戦略の一環として、IoT Hub リージョン間のディザスター リカバリー オプション使用することを検討してください。
- SDK を使用して IoT Hubs にイベントを送信する場合は、再試行ポリシー (
EventHubsExceptionまたはOperationCancelledException) によってスローされる例外が正しくキャッチされていることを確認します。 - スロットリングやクォータの枯渇によるテレメトリの中断を回避するために、カスタム自動スケール ソリューションを追加することを検討してください。
構成に関する推奨事項
Azure IoT Hub を構成するときの信頼性を最適化するには、次の推奨事項を検討してください。
| 勧告 | 説明 |
|---|---|
| 別のリージョンに 2 つ目の IoT Hub をプロビジョニングし、デバイスにルーティング ロジックを設定します。 | これらの構成は、コンシェルジェ サービスを使用してさらに拡張できます。 |
イベントを頻繁に送信するときは、AMQP または MQTT プロトコルを使用します。 |
AMQP と MQTT では、セッションを初期化するときにネットワーク コストが高くなりますが、HTTPS 要求ごとに追加の TLS オーバーヘッドが必要です。 AMQP と MQTT は、頻繁に発行を行う場合にパフォーマンスが高いです。 |
| デバイス接続に X.509 証明書 |
証明書の有効期限が切れる前に、証明書を更新するプロセスが整っていることを確認します。 |
最大スループットを得るために、組み込みエンドポイントを使用する予定の場合は、IoT Hub の作成時に最大パーティション数 (32) を使用します。 |
Event Hub と互換性のあるエンドポイントのデバイスからクラウドへのパーティションの数は、実現できるダウンストリーム並列処理の度合いを反映しています。 これにより、同時処理エンティティ 32 までスケールアップでき、送受信の可用性が最も高くなります。 作成後にこの番号を変更することはできません。 |
| スケーリングの場合は、リージョンごとに複数の IoT Hub を追加するのではなく、レベルと割り当てられた IoT Hub ユニットを増やします。 | リージョンごとに複数の IoT Hub を追加しても、すべてのハブが同じ基になるクラスターで実行できるため、追加の回復性は提供されません。 |
| 高スループットのシナリオでは、バッチ 処理されたイベントを使用します。 | サービスは、1 つのイベントを含む配列ではなく、複数のイベントを含む配列をコンシューマーに配信します。 使用するアプリケーションは、これらの配列を処理する必要があります。 |
| 可能な最小限の待機時間が必要な場合は、ルーティングを使用せず、組み込みのエンドポイントからイベントを読み取ります。 | IoT Hub でメッセージ ルーティングを使用すると、メッセージ配信の待機時間が長くなります。 平均すると、待機時間は 500 msを超えないようにする必要がありますが、配信待ち時間の保証はありません。 |
| ソリューション全体の可用性とディザスター リカバリー戦略の一環として、IoT Hub リージョン間のディザスター リカバリー オプション使用することを検討してください。 | このオプションにより、IoT Hub エンドポイントがペアの Azure リージョンに移動されます。 デバイス レジストリのみがレプリケートされます。 イベントはセカンダリ リージョンにレプリケートされません。 顧客が開始したフェールオーバーの RTO は、10 分から数時間までかかります。 Microsoft が開始するフェールオーバーの場合、RTO は 2-26 時間です。 このRTOが顧客の要件に一致しており、さらに、より広範な可用性戦略に適合していることを確認してください。 より高い RTO が必要な場合は、クライアント側のフェールオーバー パターンの実装を検討してください。 |
SDK を使用して IoT Hub にイベントを送信する場合は、再試行ポリシー (EventHubsException または OperationCancelledException) によってスローされる例外が正しくキャッチされていることを確認します。 |
HTTPSを使用する場合は、適切な再試行パターンを実装します。 |