次の方法で共有

デバイスを再プロビジョニングする方法

  • [アーティクル]

IoT ソリューションのライフサイクル中に、デバイスを IoT ハブ間で移動することはよくあります。 このトピックは、再プロビジョニング ポリシーを構成するソリューション オペレーターを支援するために記述されています。

再プロビジョニング シナリオの詳細については、「IoT ハブ デバイスの再プロビジョニングの概念」を参照してください。

再プロビジョニング ポリシーを設定する

次の手順では、個々の登録または登録グループの再プロビジョニング ポリシーを構成します。

  1. Azure portal にサインインし、Device Provisioning Service インスタンスに移動します。

  2. [登録を管理します] を選び、[登録グループ] または [個々の登録] のいずれかのタブを選びます。

  3. 再プロビジョニング用に構成する登録グループまたは個々の登録の名前を選択します。

  4. [再プロビジョニング ポリシー] のドロップダウン メニューを使用して、次のいずれかの再プロビジョニング ポリシーを選択します。

    • デバイスを再プロビジョニングしないでください。

    • デバイスを再プロビジョニングし、初期状態にリセットする: このポリシーは、登録エントリに関連付けられているデバイスが新しいプロビジョニング要求を送信したときにアクションを実行します。 登録エントリの構成に応じて、デバイスは別の IoT ハブに再割り当てされる可能性があります。 デバイスの割り当て先の IoT ハブが変更されると、最初の IoT ハブへのデバイスの登録は削除されます。 デバイスがプロビジョニングされたときにプロビジョニング サービス インスタンスが受け取った初期構成のデータは、新しい IoT ハブに提供されます。 移行中、デバイスの状態は "割り当てています" と報告されます。

    • デバイスを再プロビジョニングし、現在の状態を移行する: このポリシーは、登録エントリに関連付けられているデバイスが新しいプロビジョニング要求を送信したときにアクションを実行します。 登録エントリの構成に応じて、デバイスは別の IoT ハブに再割り当てされる可能性があります。 デバイスの割り当て先の IoT ハブが変更されると、最初の IoT ハブへのデバイスの登録は削除されます。 最初の IoT ハブからのすべてのデバイス状態情報は、新しい IoT ハブに移行されます。 移行中、デバイスの状態は "割り当てています" と報告されます

  5. [保存] を選択して、変更に基づくデバイスの再プロビジョニングを有効にします。

登録割り当てポリシーを構成する

割り当てポリシーは、登録に関連付けられたデバイスが再プロビジョニングされた後に IoT ハブにどのように割り当てられるかを決定するものです。 割り当てポリシーの詳細については、割り当てポリシーの使用方法に関するページを参照してください。

次の手順に従って、デバイスの登録の割り当てポリシーを構成します。

  1. Azure portal にサインインし、Device Provisioning Service インスタンスに移動します。

  2. [登録を管理します] を選び、[登録グループ] または [個々の登録] のいずれかのタブを選びます。

  3. 再プロビジョニング用に構成する登録グループまたは個々の登録の名前を選択します。

  4. [登録の詳細] ページで、[IoT ハブ] タブを選択します。

  5. 次のいずれかの割り当てポリシーを選択します。

    • [静的]: このポリシーでは、プロビジョニングするデバイスの登録エントリのリストに、目的の IoT ハブを含める必要があります。 このポリシーを使用すると、デバイスを割り当てる単一の IoT ハブを指定できます。

    • [加重が均等に分布]: このポリシーを使用すると、デバイスは、各 IoT ハブに構成された割り当ての重みに基づいて IoT ハブ全体に分散されます。 割り当ての重みが最も高い IoT ハブは、割り当てられる可能性が高くなります。 デバイスを 1 つの IoT Hub にのみプロビジョニングする場合は、この設定をお勧めします。 これは既定の設定です。

    • [最低待ち時間]: このポリシーを使用すると、デバイスは IoT ハブに割り当てられ、デバイスと IoT Hub の間で行われる通信の待ち時間が最小に抑えられます。 このオプションを使用すると、デバイスは位置に基づいて最も近い IoT ハブと通信できます。

    • [カスタム (Azure 関数を使用)]: このポリシーでは、Azure Functions でホストされているカスタム Webhook を使用して、デバイスを 1 つ以上の IoT ハブに割り当てます。 カスタム割り当てポリシーを使用すると、デバイスを IoT ハブに割り当てる方法をより細かくコントロールできます。 詳細については、「 カスタム割り当てポリシーを理解する」を参照してください。

  6. [ターゲット IoT ハブ] で、割り当てポリシーに含めるリンクされた IoT ハブを選択します。 必要に応じて、[IoT ハブへのリンクを追加します] ボタンを使用して、リンクされた IoT ハブを新たに追加します。

    • [Static configuration]\(静的構成\) 割り当てポリシーでは、デバイスを割り当てる IoT ハブを選択します。

    • [加重が均等に分布] 割り当てポリシーでは、構成された割り当ての重みに基づいて、選択したハブ間でデバイスがハッシュされます。

    • [最短待機時間] 割り当てポリシーでは、選択した IoT ハブが、デバイスの最も近い割り当て先 IoT ハブを特定するための待ち時間評価の対象となります。

    • [カスタム] 割り当てポリシーでは、カスタム割り当て Webhook で割り当てを評価する IoT ハブを選択します。

  7. [保存] を選択します。

デバイスからプロビジョニング要求を送信する

前のセクションで行った構成の変更に基づいてデバイスを再プロビジョニングするには、これらのデバイスから再プロビジョニングを要求する必要があります。

デバイスからプロビジョニング要求を送信する頻度は、シナリオによって異なります。 ソリューションを設計し、再プロビジョニング ロジックを定義する場合、いくつかの点を考慮する必要があります。 次に例を示します。

  • 予想されるデバイスの再起動の頻度
  • 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 を使用してすべてのデバイスを再登録する事態になる可能性があります (これによって、登録クォータ制限を簡単に超えるおそれがあります)。このようなシナリオでは、フリート全体を同時に更新するのではなく、段階的なデバイスの更新を計画してください。

次のステップ