デバイスの再接続を管理して回復性のあるアプリケーションを作成する

この記事では、デバイス再接続戦略を追加して回復力のあるアプリケーションを設計するのに役立つ概要ガイダンスを提供します。 デバイスが切断され、再接続が必要な理由について説明します。 また、開発者が切断されたデバイスを再接続するために使用できる特定の戦略について説明します。

切断の原因

デバイスがIoT Hubから切断される最も一般的な理由を次に示します。

  • 有効期限が切れた SAS トークンまたは X.509 証明書。 デバイスの SAS トークンまたは X.509 認証証明書の有効期限が切れています。
  • ネットワークの中断。 デバイスのネットワークへの接続が中断されます。
  • サービスの中断。 Azure IoT Hub サービスでエラーが発生するか、一時的に使用できません。
  • サービスの再構成。 IoT Hubサービス設定を再構成すると、デバイスで再プロビジョニングまたは再接続が必要になることがあります。

再接続戦略が必要な理由

次のセクションで説明するように、デバイスを再接続する方法を用意することが重要です。 再接続戦略がないと、ソリューションのパフォーマンス、可用性、コストに悪影響を及ぼす可能性があります。

一括再接続の試行によって DDoS が発生する可能性がある

1 秒あたりの接続試行回数が多いと、分散型サービス拒否攻撃 (DDoS) と同様の状態が発生する可能性があります。 このシナリオは、数百万単位のデバイスの大規模なフリートに関連しています。 この問題は、フリートを所有するテナントを超えて拡張され、スケール ユニット全体に影響を与える可能性があります。 DDoS では、スケールアウトが必要なため、Azure IoT Hub リソースのコストが大幅に増加する可能性があります。また、DDoS は、リソース不足のためにソリューションのパフォーマンスを低下させる可能性もあります。 さらに悪いケースでは、DDoS によってサービスの中断が発生する可能性があります。

ハブの障害または再構成により、多くのデバイスが切断される可能性がある

IoT ハブで障害が発生した後、または IoT ハブでサービス設定を再構成した後に、デバイスが切断される可能性があります。 適切なフェールオーバーを行うには、切断されたデバイスの再プロビジョニングが必要です。 フェールオーバー オプションの詳細については、「高可用性とディザスター リカバリー IoT Hub」を参照してください。

多くのデバイスを再プロビジョニングすると、コストが増加する可能性がある

デバイスがIoT Hubから切断された後、デバイスを再プロビジョニングするのではなく再接続するのが最適な解決策です。 DPS でIoT Hubを使用する場合、DPS にはプロビジョニングごとのコストがかかります。 DPS で多くのデバイスを再プロビジョニングすると、IoT ソリューションのコストが増加します。 DPS プロビジョニング コストの詳細については、「DPS の価格をIoT Hubする」を参照してください。

回復性の設計

IoT デバイスは、多くの場合、非継続的または不安定なネットワーク接続 (GSM やサテライトなど) に依存します。 サービスの可用性やインフラストラクチャ レベルの断続的な障害または一時的な障害のため、デバイスがクラウド ベースのサービスとやり取りしているときに、エラーが発生することがあります。 デバイス上で実行されるアプリケーションでは、接続、再接続、メッセージの送受信の再試行ロジックのメカニズムを管理する必要があります。 また、再試行戦略の要件は、デバイスの IoT シナリオ、コンテキスト、機能に大きく依存します。

Azure IoT Hub device SDK の目的は、接続と、cloud-to-device および device-to-cloud からの通信を、簡素化することです。 これらの SDK では、Azure IoT Hub に接続する堅牢な方法と、メッセージを送受信するための包括的なオプション セットが提供されています。 開発者は、既存の実装を変更し、特定のシナリオに合わせて再試行戦略をよりよくカスタマイズすることもできます。

接続と信頼性の高いメッセージングをサポートする関連する SDK 機能は、次のIoT Hubデバイス SDK で利用できます。 詳しくは、API のドキュメントまたは特定の SDK をご覧ください。

次のセクションでは、接続をサポートする SDK 機能について説明します。

接続と再試行

このセクションでは、接続を管理するときに使用できる再接続と再試行のパターンの概要を示します。 デバイス アプリケーションでさまざまな再試行ポリシーを使用するための実装のガイダンスについて詳しく説明し、device SDK の関連する API の一覧を示します。

エラー パターン

接続エラーはさまざまなレベルで発生します。

  • ネットワークのエラー: ソケットの切断や名前解決エラー

  • HTTP、AMQP、MQTT トランスポートのプロトコルレベル エラー: リンクのデタッチやセッションの期限切れ

  • ローカルな誤りに起因するアプリケーションレベル エラー: 無効な資格情報やサービスの動作 (クォータの超過やスロットリングなど)

device SDK は 3 つのレベルすべてでエラーを検出します。 ただし、デバイス SDK は OS 関連のエラーやハードウェア エラーを検出して処理しません。 SDK の設計は、Azure アーキテクチャ センターの一時的な障害の処理に関するガイダンスに基づいています。

再試行パターン

以下の手順では、接続エラーが検出されたときの再試行処理について説明します。

  1. SDK がネットワーク、プロトコル、またはアプリケーションでエラーと関連エラーを検出します。

  2. SDK はエラー フィルターを使用してエラーの種類を特定し、再試行が必要かどうかを判断します。

  3. SDK が回復不能なエラーを識別すると、接続、送信、受信などの操作は停止されます。 SDK は、ユーザーに通知します。 回復不能なエラーの例としては、認証エラーや不正エンドポイント エラーなどがあります。

  4. SDK は、回復可能なエラーを識別すると、ユーザーが指定した再試行ポリシーに従って、定義されているタイムアウト時間が経過するまで、再試行します。 SDK では、既定で ジッター再試行ポリシーで指数バックオフ が使用されます。

  5. 定義されているタイムアウト時間が経過すると、SDK は接続や送信の再試行を停止します。 ユーザーに通知します。

  6. SDK によって、ユーザーはコールバックをアタッチし、接続ステータス変更を受信できます。

SDK には通常、次の 3 つの再試行ポリシーが用意されています。

  • 指数関数的後退とゆらぎ:この既定の再試行ポリシーでは、最初は積極的に、その後は最大遅延に達するまで時間経過と共に頻度を減らしながら、再試行が行われます。 このデザインは、Azure アーキテクチャ センターの再試行に関するガイダンスに基づいています。

  • カスタム再試行:SDK の一部の言語では、シナリオに適したカスタム再試行ポリシーを設計して、RetryPolicy に挿入することができます。 カスタム再試行は C SDK では使用できません。Python SDK では現在サポートされていません。 Python SDK は必要に応じて再接続します。

  • 再試行なし: 再試行ポリシーを "再試行なし" に設定すると、再試行ロジックが無効になります。 接続が確立されていれば、SDK は一回の接続と一回のメッセージ送信を試行します。 このポリシーは通常、帯域幅またはコストが重要なシナリオで使用されます。 このオプションを選択すると、送信できなかったメッセージは失われ、回復できません。

再試行ポリシー API

SDK SetRetryPolicy メソッド ポリシー実装 実装ガイダンス
C IOTHUB_CLIENT_RESULT IoTHubDeviceClient_SetRetryPolicy 参照: IOTHUB_CLIENT_RETRY_POLICY C の実装
Java SetRetryPolicy 既定:ExponentialBackoffWithJitter class
カスタム: RetryPolicy インターフェイスを実装
再試行なし:NoRetry クラス
Java 実装
.NET DeviceClient.SetRetryPolicy 既定:ExponentialBackoff クラス
カスタム:IRetryPolicy インターフェイスを実装
再試行なし:NoRetry クラス
C# 実装
Node setRetryPolicy 既定:ExponentialBackoffWithJitter class
カスタム:RetryPolicy インターフェイスを実装
再試行なし:NoRetry クラス
ノード実装
Python 現在、サポートされていません 現在、サポートされていません 組み込みの接続の再試行: 切断された接続は、既定で固定の 10 秒間隔で再試行されます。 この機能は必要に応じて無効にでき、間隔を構成できます。

ハブ再接続フロー

DPS なしでのみIoT Hubを使用する場合は、次の再接続方法を使用します。

デバイスがIoT Hubに接続できない場合、またはIoT Hubから切断された場合:

  1. ジッター遅延関数で指数バックオフを使用します。
  2. IoT Hubに再接続します。

次の図は、再接続フローをまとめたものです。

IoT Hubのデバイス再接続フローの図。

DPS 再接続フローを含むハブ

DPS でIoT Hubを使用する場合は、次の再接続方法を使用します。

デバイスがIoT Hubに接続できない場合、またはIoT Hubから切断された場合は、次の場合に基づいて再接続します。

再接続のシナリオ 再接続戦略
接続の再試行を許可するエラーの場合 (HTTP 応答コード 500) ジッター遅延関数で指数バックオフを使用します。
IoT Hubに再接続します。
再試行が可能ですが、再接続が 10 回連続して失敗したことを示すエラーの場合 デバイスを DPS に再プロビジョニングします。
接続の再試行を許可しないエラーの場合 (HTTP 応答 401、Unauthorized または 403、Forbidden、404、Not Found) デバイスを DPS に再プロビジョニングします。

次の図は、再接続フローをまとめたものです。

DPS を使用したIoT Hubのデバイス再接続フローの図。

次のステップ

推奨される次の手順は次のとおりです。