IoT Hub デバイスの再プロビジョニングの概念
IoT ソリューションのライフサイクル中に、デバイスを IoT ハブ間で移動することはよくあります。 この移動の理由として、次のようなシナリオが挙げられます。
位置情報/geo 待機時間: デバイスが異なる場所の間を移動するときは、より近い IoT Hub にデバイスを移行することにより、ネットワーク待機時間が改善されます。
マルチ テナンシー: デバイスは同じ IoT ソリューション内で使用され、新しい顧客または顧客サイトに再割り当てされる可能性があります。 この新しい顧客には、別の IoT ハブを使用してサービスが提供される可能性があります。
ソリューションの変更: デバイスは、新しい IoT ソリューションまたは更新された IoT ソリューションに移動される場合があります。 この再割り当てでは、その他のバックエンド コンポーネントに接続されている新しい IoT ハブと通信するためにそのデバイスを必要とする可能性があります。
検疫: ソリューションの変更と同様です。 正常に動作していないデバイス、セキュリティ侵害を受けたデバイス、または古いデバイスは、更新してコンプライアンスが確保された状態に戻す操作のみが可能な IoT ハブに再割り当てされることがあります。 デバイスが適切に機能するようになったら、そのメインのハブに再び移行されます。
Device Provisioning Service 内の再プロビジョニングのサポートでは、これらのニーズに対処します。 デバイスは、デバイスの登録エントリで構成された再プロビジョニング ポリシーに基づいて、新しい IoT Hub に自動的に再割り当てされる場合があります。
デバイスの状態データ
デバイスの状態データは、デバイス ツインとデバイスの機能で構成されています。 このデータは Device Provisioning Service インスタンスおよびデバイスが割り当てられている IoT Hub に格納されます。
デバイスが Device Provisioning Service インスタンスで最初にプロビジョニングされる場合、次の手順が実行されます。
デバイスによって Device Provisioning Service インスタンスにプロビジョニング要求が送信されます。 サービス インスタンスでは、登録エントリに基づいてデバイス ID が認証され、デバイスの状態データの初期構成が作成されます。 サービス インスタンスによって、デバイスが登録の構成に基づいて IoT Hub に割り当てられ、IoT Hub 割り当てがそのデバイスに返されます。
プロビジョニング サービス インスタンスによって、任意のデバイスの初期状態のデータをコピーしたものが割り当てられた IoT Hub に提供されます。 デバイスが割り当てられた IoT Hub に接続され、操作を開始します。
時間の経過とともに、IoT Hub 上のデバイスの状態データは、デバイスの操作とバックエンドの操作によって更新される可能性があります。 Device Provisioning Service インスタンスに格納されているデバイスの初期状態の情報は、変更されずに保持されます。 この変更されていないデバイスの状態データが初期構成です。
シナリオに応じて、デバイスが IoT Hub 間で移動されるときに、前の IoT Hub で更新されたデバイスの状態を新しい IoT Hub に移行することが必要な場合もあります。 この移行は、Device Provisioning Service でポリシーを再プロビジョニングすることによってサポートされます。
再プロビジョニング ポリシー
シナリオに応じて、再起動時にデバイスからプロビジョニング サービス インスタンスに要求が送信される可能性があります。 また、オンデマンドでプロビジョニングを手動でトリガーする方法もサポートしています。 登録エントリの再プロビジョニング ポリシーによって、Device Provisioning Service インスタンスでこれらのプロビジョニング要求を処理する方法が決まります。 また、このポリシーによって、再プロビジョニング中にデバイスの状態データを移行する必要があるかどうかも決まります。 同じポリシーを個別の登録と登録グループに利用できます。
データの再プロビジョニングと移行: このポリシーは新しい登録エントリの既定値です。 このポリシーは、登録エントリに関連付けられているデバイスが新しい要求 (1) を送信するときに処理されます。 登録エントリの構成に応じて、デバイスは別の IoT ハブに再割り当てされる可能性があります。 デバイスの割り当て先の IoT ハブが変更されると、最初の IoT ハブへのデバイスの登録は削除されます。 最初の IoT Hub から更新されたデバイスの状態情報は、新しい IoT Hub (2) に移行されます。 移行中、デバイスの状態は "割り当てています" と報告されます。
再プロビジョニングして初期構成にリセット: このポリシーは、登録エントリに関連付けられているデバイスが新しいプロビジョニング要求を送信したときにアクションを実行します (1)。 登録エントリの構成に応じて、デバイスは別の IoT ハブに再割り当てされる可能性があります。 デバイスの割り当て先の IoT ハブが変更されると、最初の IoT ハブへのデバイスの登録は削除されます。 プロビジョニング サービス インスタンスが、デバイスがプロビジョニングされたときに受け取った初期構成のデータは、新しい IoT Hub (2) に提供されます。 移行中、デバイスの状態は "割り当てています" と報告されます。
このポリシーは、IoT Hub を変更せずにファクトリ リセットに使用されることが多いです。
再プロビジョニングしない: デバイスは別のハブに再プロビジョニングされることはありません。 このポリシーは、下位互換性を管理するために提供されます。
Note
DPS では、デバイスの新しい ReturnData がある場合、再プロビジョニング ポリシーに関係なく、常にカスタム割り当て Webhook が呼び出されます。 再プロビジョニング ポリシーが [再プロビジョニングしない] に設定されている場合、Webhook は呼び出されますが、デバイスに割り当てられたハブは変更されません。
ソリューションを設計し、再プロビジョニング ロジックを定義する場合、いくつかの点を考慮する必要があります。 次に例を示します。
- 予想されるデバイスの再起動の頻度
- DPS のクォータと制限
- フリートでの予想されるデプロイ時間 (段階的なロールアウトの場合とすべて一括の場合)
- クライアント コードに実装された再試行機能。Azure アーキテクチャ センターの再試行の一般的なガイダンスを参照してください
ヒント
デバイスを再起動するたびにプロビジョニングすることはお勧めしません。これにより、一度に数千または数百万ものデバイスを再プロビジョニングするときに問題が発生するおそれがあります。 代わりに、デバイスの登録状態の検索 API の使用を試し、その情報を使用して IoT Hub への接続を試みる必要があります。 それが失敗した場合は、IoT Hub の情報が変更されている可能性があるため、再プロビジョニングしてみてください。 登録状態のクエリは新しいデバイス登録としてカウントされるため、デバイス登録の制限を考慮する必要があります。 また、ランダム化による指数バックオフなどの適切な再試行ロジックの実装も検討してください。再試行の一般的なガイダンスに関する記事を参照してください。 デバイスの機能によっては、DPS を使用した初回プロビジョニングが行われた後に、IoT Hub 情報を直接デバイスに保存して IoT Hub に直接接続できる場合があります。 これを行う場合は、Hub から特定のエラーを受け取った場合に備えて、必ずフォールバック メカニズムを実装してください。たとえば、次のシナリオを検討します。
- 結果コードが 429 (要求の数が多すぎる) であるか、5xx の範囲のエラーが発生した場合は、Hub の操作を再試行します。 その他のエラーの場合は、再試行しないでください。
- 429 エラーの場合は、Retry-After ヘッダーに示されている時間が経過した後でのみ再試行してください。
- 5xx エラーの場合は、指数バックオフを使用します。最初の再試行は、応答から 5 秒以上が経過した後です。
- 429 と 5xx 以外のエラーの場合は、DPS を使用して再登録します
- 理想的には、オンデマンドでプロビジョニングを手動でトリガーするメソッドにも対応する必要があります。
また、フリートへの更新のプッシュなどのアクティビティを計画する際は、サービスの制限を考慮することもお勧めします。 たとえば、フリートをすべて一括で更新すると、DPS を使用してすべてのデバイスを再登録する事態になる可能性があります (これによって、登録クォータ制限を簡単に超えるおそれがあります)。このようなシナリオでは、フリート全体を同時に更新するのではなく、段階的なデバイスの更新を計画してください。
下位互換性を管理する
2018 年 9 月より前は、IoT Hub へのデバイスの割り当てには固定の動作がありました。 デバイスがプロビジョニング プロセスから戻された場合、同じ IoT Hub に戻るように割り当てられるだけです。
この動作の依存関係を取得するソリューションの場合、プロビジョニング サービスには下位互換性が含まれます。 この動作は現在、次の条件に従ってデバイスに対して保持されます。
デバイスは、Device Provisioning Service のネイティブな再プロビジョニング サポートが利用可能になる前の API バージョンに接続されます。 以下の API の表を参照してください。
デバイスに対する登録エントリには、再プロビジョニングのポリシー セットがありません。
この互換性によって、以前にデプロイしたデバイスで、初期テスト時に存在したのと同じ動作が確実に行われるようになります。 前の動作を保持するには、再プロビジョニング ポリシーをこれらの登録に保存しないでください。 再プロビジョニング ポリシーが設定されると、再プロビジョニング ポリシーは動作より優先されます。 再プロビジョニング ポリシーが優先されることを許可することによって、顧客はデバイスの再イメージ化することなく、デバイスの動作を更新できます。
次のフロー チャートは、動作が存在するときを示しています。
以下の表は、Device Provisioning Service のネイティブな再プロビジョニング サポートが利用可能になる前の API バージョンを示しています。
| REST API | C SDK | Python SDK | Node SDK | Java SDK | .NET SDK |
|---|---|---|---|---|---|
| 2018-04-01 以前 | 1.2.8 以前 | 1.4.2 以前 | 1.7.3 以前 | 1.13.0 以前 | 1.1.0 以前 |
Note
これらの値とリンクは、変更される可能性があります。 これは、バージョンを顧客が決定できる場所、および想定されるバージョンの内容を決定しようとする単なるプレースホルダーです。