MS_AzureIoTHub - NetDevInfraWGinOSSConsortium/NetDevInfraWiki GitHub Wiki

Azure IoT Hub

概要

  • IoT デバイスの登録・認証・管理を行い、監視／管理する
  • フロントエンドとバックエンドの双方向の通信を仲介する

双方向通信の仲介

デバイス認証

デバイス認証によるセキュリティ強化

補足（デバイス認証の選択）: IoT Hub がサポートする認証方式は
大きく 3 つある。規模と運用性で選ぶ。

方式 特徴
対称キー（SASトークン） 最も簡単。鍵が漏れたら終わり。試作・小規模向け
X.509 自己署名 デバイスごとに拇印を登録。中規模まで
X.509 CA 署名 CA を信頼するだけ。デバイスを個別登録せずに済む。大規模の定石

3 番目は「工場で証明書を焼き込み、現場で初回接続時に自動登録する」
という運用が可能になる（後述の DPS と組み合わせる）。
数万台規模では事実上これ以外の選択肢が無い。

メッセージ ハブ

  • 双方向通信の中央メッセージ ハブとして機能
    • 管理する IoT デバイス（Device Endpoint）
    • IoT アプリケーション（Service Endpoint）
  • Azure Event Hubsと異なり、
    Kafka Endpoint などは使えないらしい。

メッセージング パターン

複数のメッセージング パターンをサポート

  • ファイルのアップロード
  • IoT デバイス制御の要求/応答メソッド

補足（Event Hubs との使い分け）: よく比較されるので整理しておく。

IoT Hub Event Hubs
通信方向 双方向（D2C + C2D） 一方向（取り込みのみ）
デバイス管理 あり（登録・ツイン・直接メソッド） 無し
デバイス単位の認証 あり 無し（接続文字列単位）
プロトコル MQTT / AMQP / HTTPS AMQP / Kafka / HTTPS
用途 デバイスを制御したい 大量イベントを取り込みたい

「デバイスに指示を送り返す必要があるか」で決まる。
送り返す必要が無く、単に大量のテレメトリを受けるだけなら
Event Hubs の方が安価である。

ソリューション構築

  • デバイス管理等の機能が追加されている。
  • 信頼性が高く、セキュリティで保護された通信を提供

接続

  • ほぼすべての IoT デバイス
  • 何百万もの IoT デバイス
  • 大規模なデバイス・プロビジョニング（DPS）

監視

イベントの追跡により、ソリューションの正常性維持に役立つ。

  • IoT デバイスの作成 / 障害 / 接続

アプリケーション開発

Azure IoT Hub SDK を使用して開発。

SDK 用途
Device SDK デバイス側のアプリケーション
Service SDK クラウド・サービス側のアプリケーション
管理 SDK サブスクリプション内の IoT Hub 管理アプリケーション
Provisioning SDK DPS を使用してデバイスを IoT Hub にプロビジョニング

詳細

機能

スケール調整

毎秒数百万のイベントに対応するようにスケーリングする。

クォータと制限

DoS 攻撃から保護するため、サブスクリプションごとの IoT ハブの数を制限。

IoTデバイスの構成と制御

  • IoT デバイス毎、または共通特性に基づいて、IoT デバイスの状態を設定。

  • IoT デバイスのデバイス メタデータと状態情報を保存、同期、照会。

  • IoT デバイスで報告された状態の変化に自動的に対応。

  • ライフサイクル: 計画 → プロビジョニング → 構成 → 監視・制御 → 廃棄

補足（デバイス ツインが中核）: 上記「状態を設定・同期・照会」を
実現しているのが デバイス ツイン（Device Twin） である。
クラウド側にデバイスごとの JSON ドキュメントを持つ。

セクション 書き込む側 用途
tags クラウドのみ 分類（設置場所、機種）。デバイスからは見えない
desired（望ましい状態） クラウド 「こう設定してほしい」（例: 送信間隔 60 秒）
reported（報告された状態） デバイス 「今こうなっている」 
クラウド ──desired──> デバイス（オフラインなら次回接続時に受け取る）
クラウド <──reported── デバイス

デバイスがオフラインでも設定変更を予約できるという点が、
単なるメッセージングとの決定的な違いである。
「望ましい状態」と「実際の状態」を分けて持つ設計は
Kubernetes の宣言的モデルと同じ発想である。

デバイスからクラウドへの制御手段

手段 同期/非同期 用途
直接メソッド (Direct Method) 同期（応答を待つ） 「今すぐ再起動して」
デバイス ツイン（desired） 非同期 「設定を変えておいて」
C2D メッセージ 非同期（キュー） 「このデータを渡す」

ルーティング

メッセージ・ルーティング

イベント・ルーティング

Azure Event Gridでのルーティング。

補足（メッセージとイベントの違い）: 2 つのルーティングが並ぶが、
対象が違う。

メッセージ ルーティング イベント ルーティング
対象 テレメトリ本体（センサー値など） メタなイベント（デバイス作成／接続／切断）
経由 IoT Hub の組み込み機能 Event Grid
例 「温度が 30 度」 「デバイス A が切断された」

「異常値を検知したい」ならメッセージ ルーティング、
「デバイスが落ちたら通知したい」ならイベント ルーティングになる。

Device Provisioning Service (DPS)

大量のデバイスを手作業なしで適切な IoT Hub に登録する仕組み。

  1. デバイスは共通の DPS エンドポイントだけを知っていればよい。
  2. DPS が証明書等で認証し、割り当てポリシーに従って IoT Hub を決定。
  3. 以降、デバイスはその IoT Hub と直接通信する。

補足（DPS が無いと詰む）: 「工場出荷時にどの IoT Hub に繋ぐか
決められない」というのが IoT の現実である。

  • 出荷先の国・リージョンが未定
  • Hub をスケールアウトするとき、既存デバイスを振り分け直したい
  • Hub の障害時に別 Hub へフェイル オーバーしたい

DPS はこれらをデバイス側のファームウェアを書き換えずに解決する。
数千台以上を扱うなら、最初から DPS 前提で設計するのが定石である。

参考

Microsoft Learn

Tags: 移行, インフラストラクチャ, クラウド, Azure, IoT

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

⚠️ **GitHub.com Fallback** ⚠️