IoT Hub Device Provisioning Service とは？超概要

IoTに関わる皆様こんにちは。
突然ですが、デバイスとクラウド（その他サーバーサイド）の接続情報、どうしていますか？
もう少し具体的に言いますと、例えば接続先アドレスをどうしていますか？
例えば以下のようなパターンがあると想定しています。

- デバイスに直書き
- 設定ファイルに書いて保存
- 特定用途向けで設置台数も少ないので、設置時に書き込んでいる

そしてデバイスを前に、こんな時に困るのだと思っています。

- 接続先アドレスを更新しなければならない
- そもそも設置作業が大変でミスも多い

IoTサービスを運用しているとこんな問題も出てきます。

- 故障したときに代替品に変えると設定変更、そして修理が終わったらまた設定変更・・・
- デバイスが１台乗っ取られたので、そこからの通信は遮断しなければならないが・・・

# IoT Hub Device Provisioning Service (DPS)
前置きが長くなりましたが、デバイスの接続を楽にしたいときに使えるのが、このDPSというサービスです。
前置きだけじゃなくてサービス名も長いので"DPS"と略します。全世界で"DPS"で通用します。
一言で言うと、どこに接続したらいいのかを都度教えてくれるサービスです。
デバイス側はこのDPSというサービスに接続します。するとDPSが"どこのIoT Hubに接続したら良いのか"を教えてくれます。
DPS自体は良い感じのWebサーバーみたいなものでHTTPSで問い合わせをします。
こういうものって思いついても、作るのも管理するのも面倒ですよね？
コストでしかないですし、必要性は理解しても作りたくないのが現実ではないでしょうか。
それでは具体的な動きを簡単に確認したいと思います。
今回は"超概要"ですので、細かい部分は省略していますし、正確ではない部分もあります。
しかしながらまずは、大きな流れをご理解いただけたらと思います。

# １．事前準備
以下、デバイス側のことは"デバイス"、クラウド側のことは"サービス"と記載します。
この呼び方はAzureのIoT系ドキュメント全般的に使われる言い回しですので慣れてください。
技術屋さんとしてはデバイスとクラウドがわかりやすいかもしれませんが、クラウドは機能を提供しているだけです。ユーザーが得る価値をベースに考えると、デバイスはデバイスですが、クラウドではなくサービス（を提供する側）という言葉が適切です。

## サービス側の準備
まずはIoT HubとDPSを１つずつ作成します。
できたら、DPSにIoT Hubを登録します。DPSはデバイスからの問い合わせを受けた際、自分の配下に登録されているIoT Hubの中から適切なものを選択します。("適切"の中身は省略。)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/62ef4760-c2be-121d-e49b-ef0bb00d2bd9.png)

## デバイス側の準備
デバイスはこのあとの手順で、DPSに問い合わせを実施します。
問い合わせには、接続先と鍵が必要となりますので、事前に登録します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/9c81230c-7909-2945-2ac6-4b6dd9f062f2.png)

# ２．プロビジョニング作業
まずはデバイスから、"接続したい" とDPSに問い合わせを実施します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/7e8159b1-45ea-68fb-05bb-d4430a888e59.png)

問い合わせを受けたDPSは適切なIoT Hubを探し、接続したいデバイスが存在する旨を伝えます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/7862d63d-25d5-b589-b5d0-70bcdf0b0463.png)

依頼を受けたIoT Hubは、接続に必要な情報をDPSに渡します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/456de02d-16fa-c7eb-216d-25f3a3b3a8e6.png)

DPSは、IoT Hubから返却された接続情報をデバイスに返却します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/d0fdcf40-f0ce-ce01-099b-5a256fe37488.png)

# ３．IoT Hubに接続
最後に、IoT Hubに接続します。
接続情報はさきほどDPS経由でもらった新鮮なものを使います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/458a4b8d-c13a-4d38-e82b-dafb94a0d8a5.png)

# その後のDPSはどうなるの？
次の問い合わせがあるまで何もしません。
例えば、電源が入ったらDPSに問い合わせるように作っておけば、その時にDPSが使われます。
デバイス側でIoT Hubとの接続状況をエラーハンドリングして、接続が切れたらDPSに問い合わせるように作っておけば、その時にDPSが使われます。
普段は働きません。


# DPSを使うと何がうれしいのか
全世界共通の接続先になっている(最初から冗長構成＆分散配置されている)DPSを採用することは、非常に大きなメリットを生みます。

"IoTのサービスをクラウドネイティブに"と考えた場合に、考慮しなければならないことがあります。
それは例えば

- デバイスはいつか壊れる
- サービスはいつか落ちる
- IoTのベース(つないで情報授受する)は儲からない

このようなことです。
持続可能なコストとマンパワーを前提に、ユーザー要望に沿える稼働率で、どのようにデバイスやサービスのライフサイクルをまわしていくかを意識しなければなりません。

DPSを使い、デバイスの電源をいれただけで適切なIoT Hubと連携してサービス提供を始める仕掛けをデバイスに仕込むことで例えば

- 全世界に共通のデバイスを配布できる(出荷先ごとに接続先を書き換える必要は無い)
- 冗長化に備えて複数のIoT Hubの情報を書き込む必要は無い
- プロビジョニングに関して、安定した環境を安価に入手できる

このようなメリットがあります。

# まとめ
IoTサービスはとにかくベースを安価に提供する必要があります。しかも、安定稼働が当然のものとして語られます。このような環境を24時間365日提供するためには、サービスのどこかが落ちても自動で迅速に復旧できる仕掛けが必要となります。
DPSは、デバイスに１番近いところでサービスの安定稼働に重要な役割を果たします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/cba047b4-9c35-da31-52f2-feaf8677b78f.png)
０．事前準備
１．デバイス->DPS：接続依頼
２．DPS<->IoT Hub：接続先選定と接続情報の提供
３．DPS->デバイス：接続情報の提供
４．デバイス<->IoT Hub：接続、メッセージの授受開始