デバイスの再接続を管理して回復性があるアプリケーションを作成する
この記事では、デバイスの再接続戦略を追加して回復性があるアプリケーションを設計するのに役立つ大まかなガイダンスを提供します。 デバイスが切断され、再接続が必要な理由について説明します。 また、切断されたデバイスを再接続するために開発者が使用できる特定の戦略について説明します。
切断の原因
デバイスが 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 から切断された後、デバイスを再プロビジョニングするのではなく、再接続するのが最良の解決策です。 IoT Hub と DPS を使う場合、DPS のコストはプロビジョニングごとにかかります。 DPS で多数のデバイスを再プロビジョニングすると、IoT ソリューションのコストが増加します。 DPS のプロビジョニング コストについて詳しくは、IoT Hub DPS の価格に関するページを参照してください。
回復性の設計
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 アーキテクチャ センターの一時的な障害の処理に関するガイダンスに基づいています。
再試行パターン
以下の手順では、接続エラーが検出されたときの再試行処理について説明します。
SDK がネットワーク、プロトコル、またはアプリケーションでエラーと関連エラーを検出します。
SDK はエラー フィルターを使用してエラーの種類を特定し、再試行が必要かどうかを判断します。
SDK が回復不能なエラーを識別すると、接続、送信、受信などの操作は停止されます。 SDK は、ユーザーに通知します。 回復不能なエラーの例としては、認証エラーや不正エンドポイント エラーなどがあります。
SDK は、回復可能なエラーを識別すると、ユーザーが指定した再試行ポリシーに従って、定義されているタイムアウト時間が経過するまで、再試行します。 この SDK では、既定でエクスポネンシャル バックオフとジッター再試行ポリシーが使用されます。
定義されているタイムアウト時間が経過すると、SDK は接続や送信の再試行を停止します。 ユーザーに通知します。
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# 実装 |
| ノード | setRetryPolicy | 既定:ExponentialBackoffWithJitter class カスタム:RetryPolicy インターフェイスを実装 再試行なし:NoRetry クラス |
ノード実装 |
| Python | 現在、サポートされていません | 現在、サポートされていません | 組み込みの接続再試行:ドロップされた接続は、既定では 10 秒間隔で再試行されます。 この機能は必要に応じて無効にすることができ、間隔も構成できます。 |
ハブの再接続フロー
DPS なしで IoT Hub のみを使用する場合は、次の再接続戦略を採用します。
デバイスが IoT Hub に接続できない場合、または 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 に再プロビジョニングします。 |
次の図は、再接続フローをまとめたものです。
次のステップ
推奨される次の手順は以下のとおりです。