IoT ソリューションのライフサイクル中に、デバイスを IoT ハブ間で移動することはよくあります。 この記事は、ソリューションオペレーターが再プロビジョニング ポリシーを構成するのを支援するために書かれています。
再プロビジョニング シナリオの詳細については、「IoT ハブ デバイスの再プロビジョニングの概念」を参照してください。
再プロビジョニング ポリシーを設定する
次の手順では、個々の登録または登録グループの再プロビジョニング ポリシーを構成します。
Azure portal にサインインし、Device Provisioning Service インスタンスに移動します。
[登録を管理します] を選び、[登録グループ] または [個々の登録] のいずれかのタブを選びます。
再プロビジョニング用に構成する登録グループまたは個々の登録の名前を選択します。
[再プロビジョニング ポリシー] のドロップダウン メニューを使用して、次のいずれかの再プロビジョニング ポリシーを選択します。
デバイスを再プロビジョニングしないでください。
デバイスを再プロビジョニングし、初期状態にリセットする: このポリシーは、登録エントリに関連付けられているデバイスが新しいプロビジョニング要求を送信したときにアクションを実行します。 登録エントリの構成によっては、デバイスが別の IoT ハブに再割り当てされる場合があります。 デバイスが IoT ハブを変更している場合、初期 IoT ハブへのデバイス登録は削除されます。 デバイスがプロビジョニングされたときにプロビジョニング サービス インスタンスが受け取った初期構成のデータは、新しい IoT ハブに提供されます。 移行中、デバイスの状態は 割り当て済みとして報告されます。
デバイスを再プロビジョニングし、現在の状態を移行する: このポリシーは、登録エントリに関連付けられているデバイスが新しいプロビジョニング要求を送信したときにアクションを実行します。 登録エントリの構成によっては、デバイスが別の IoT ハブに再割り当てされる場合があります。 デバイスが IoT ハブを変更している場合、初期 IoT ハブへのデバイス登録は削除されます。 その初期 IoT ハブからのすべてのデバイス状態情報は、新しい IoT ハブに移行されます。 移行中、デバイスの状態は [割り当て中] として報告されます
[保存] を選択して、変更に基づくデバイスの再プロビジョニングを有効にします。
登録割り当てポリシーを構成する
割り当てポリシーは、再プロビジョニング後に、登録に関連付けられているデバイスを IoT ハブに割り当てる方法を決定します。 割り当てポリシーの詳細については、「 割り当てポリシーを使用して IoT ハブ間でデバイスをプロビジョニングする方法」を参照してください。
次の手順に従って、デバイスの登録の割り当てポリシーを構成します。
Azure portal にサインインし、Device Provisioning Service インスタンスに移動します。
[登録を管理します] を選び、[登録グループ] または [個々の登録] のいずれかのタブを選びます。
再プロビジョニング用に構成する登録グループまたは個々の登録の名前を選択します。
[登録の詳細] ページで、[IoT ハブ] タブを選択します。
次のいずれかの割り当てポリシーを選択します。
[静的]: このポリシーでは、プロビジョニングするデバイスの登録エントリのリストに、目的の IoT ハブを含める必要があります。 このポリシーを使用すると、デバイスを割り当てる単一の IoT ハブを指定できます。
[加重が均等に分布]: このポリシーを使用すると、デバイスは、各 IoT ハブに構成された割り当ての重みに基づいて IoT ハブ全体に分散されます。 割り当ての重みが最も高い IoT ハブは、割り当てられる可能性が高くなります。 デバイスを 1 つの IoT Hub にのみプロビジョニングする場合は、この設定をお勧めします。 これは既定の設定です。
待機時間が最も短い: このポリシーでは、デバイスと IoT Hub の間の通信の待機時間が最も短くなる IoT ハブにデバイスを割り当てます。 このオプションを使用すると、デバイスは位置に基づいて最も近い IoT ハブと通信できます。
[カスタム (Azure 関数を使用)]: このポリシーでは、Azure Functions でホストされているカスタム Webhook を使用して、デバイスを 1 つ以上の IoT ハブに割り当てます。 カスタム割り当てポリシーを使用すると、デバイスを IoT ハブに割り当てる方法をより細かくコントロールできます。 詳細については、「 Azure IoT Hub Device Provisioning Service を使用したカスタム割り当てポリシーについて」を参照してください。
[ターゲット IoT ハブ] で、割り当てポリシーに含めるリンクされた IoT ハブを選択します。 必要に応じて、[IoT ハブへのリンクを追加します] ボタンを使用して、リンクされた IoT ハブを新たに追加します。
[Static configuration]\(静的構成\) 割り当てポリシーでは、デバイスを割り当てる IoT ハブを選択します。
均等に重み付けされた分散割り当てポリシーでは、構成された割り当て重みに基づいて、選択した IoT ハブ全体でデバイスがハッシュされます。
最も短い待機時間の割り当てポリシーでは、選択した IoT ハブが待機時間の評価に含まれており、デバイスの割り当てに最も近い IoT ハブが決定されます。
[カスタム] 割り当てポリシーでは、カスタム割り当て Webhook で割り当てを評価する IoT ハブを選択します。
[保存] を選択します。
デバイスからプロビジョニング要求を送信する
前のセクションで行った構成の変更に基づいてデバイスを再プロビジョニングするには、これらのデバイスから再プロビジョニングを要求する必要があります。
デバイスからプロビジョニング要求を送信する頻度は、シナリオによって異なります。 ソリューションを設計し、再プロビジョニング ロジックを定義するときは、考慮すべき点がいくつかあります。 次に例を示します。
- 予想されるデバイスの再起動の頻度
- DPS のクォータと制限
- 艦隊の予想されるデプロイ時間 (段階的なロールアウト vs 一斉に)
- Azure アーキテクチャ センターの 一時的な障害処理 ガイダンスで説明されているように、クライアント コードに実装されている再試行機能
ヒント
デバイスの再起動ごとにプロビジョニングしないことをお勧めします。このアクションは、特に一度に数千または数百万台のデバイスを再プロビジョニングする場合に、サービス調整の制限に達する可能性があります。 代わりに、デバイスの登録状態の検索 API の使用を試し、その情報を使用して IoT Hub への接続を試みる必要があります。 それが失敗した場合は、IoT Hub の情報が変更されている可能性があるため、再プロビジョニングしてみてください。 登録状態のクエリは新しいデバイス登録としてカウントされるため、 デバイス登録の制限を考慮する必要があることに注意してください。 また、Azure アーキテクチャ センターの 一時的な障害処理 ガイダンスで説明されているように、ランダム化による指数バックオフなどの適切な再試行ロジックの実装も検討してください。 デバイスの機能によっては、DPS を使用した初回プロビジョニングが行われた後に、IoT Hub 情報を直接デバイスに保存して IoT Hub に直接接続できる場合があります。 デバイスに直接保存する場合は、 IoT Hub からの特定のエラーが発生した場合に備えてフォールバック メカニズムを実装してください。 たとえば、次のシナリオを考えてみてください。
- 結果コードが 429 (要求が多すぎます) または 5xx の範囲内のエラーである場合は、IoT Hub 操作を再試行します。 その他のエラーについては再試行しないでください。
- 429 エラーの場合は、Retry-After ヘッダーに示されている時間が経過した後でのみ再試行してください。
- 5xx エラーの場合は、指数バックオフを使用します。最初の再試行は、応答から 5 秒以上が経過した後です。
- 429 と 5xx 以外のエラーの場合は、DPS を使用して再登録します
- 必要に応じて手動でプロビジョニングをトリガーする ダイレクトメソッド もサポートする必要があるのが理想的です。
また、フリートへの更新のプッシュなどのアクティビティを計画する際は、サービスの制限を考慮することもお勧めします。 たとえば、フリートを一度に更新すると、すべてのデバイスが DPS を介して再登録される可能性があります (登録クォータの制限を簡単に超える可能性があります)。このようなシナリオでは、フリート全体を同時に更新するのではなく、段階的にデバイスの更新を計画することを検討してください。
次のステップ
- 再プロビジョニングの詳細については、 IoT Hub デバイスの再プロビジョニングの概念に関するページを参照してください。
- プロビジョニング解除の詳細については、「 以前に自動プロビジョニングされたデバイスのプロビジョニングを解除する方法」を参照してください。