IoT Hub メッセージ ルーティング と Event Grid の比較 — テレメトリとイベントが同じ問題ではない理由

温度の測定値、振動サンプル、マシンのサイクル、デバイスの切断は、いずれもイベントと呼ぶことができますが、同じアーキテクチャ上の問題を表しているわけではありません。産業用 IoT や製造環境では、連続的なテレメトリと離散的なイベントを混同すると、ノイズの多いワークフロー、不完全な生産履歴、不要な処理、そして十分な文脈なしに反応するシステムを生み出す恐れがあります。

このエピソードでは、現実的な製造シナリオをたどりながら、Azure IoT Hub Message Routing と Azure Event Grid のアーキテクチャ上の違いを解説します。プレスラインは、産業用ゲートウェイを通じて、温度、振動、サイクル数、エネルギー消費量、マシンの状態情報を継続的に送信します。これらの計測値は、後にエンジニア、データチーム、保全チーム、生産システムが分析を必要とする運用履歴を形成します。一方、デバイスの切断は異なります。これは、別のシステムや担当者による対応が必要かもしれない変化を表しています。

テレメトリは警報ではなく記録です
テレメトリは、時間の経過に伴う繰り返しの計測を表します。単一の温度値や振動計測は、通常、それ単体ではほとんど何も伝えません。実際の情報は時系列の中にあります。値がどれほど速く変化したか、その瞬間にマシンが何をしていたか、停止の前に何が起きたか、ネットワーク断の間に計測値が途絶えたか、同様の挙動が過去の生産ロットにも現れていたか、といった点です。

代表的な産業用テレメトリには次のものが含まれます:
• 温度、振動、圧力、エネルギー消費量、電流
• 稼働中、待機中、停止、障害といったマシン状態
• サイクル数、生産カウンター、プロセス計測値
• ソースのタイムスタンプ、デバイス識別子、シーケンス番号、相関情報

これらのレコードは、後に状態監視、品質調査、エネルギー分析、OEE の算出、Microsoft Fabric による分析、Power BI によるレポート作成、生産の最適化を支えることになります。そのため、テレメトリには保持、リプレイ、重複処理、独立したコンシューマー、そして生産タイムラインを確実に再構築する手段が必要です。

テレメトリのデータプレーンとしての IoT Hub Message Routing
Azure IoT Hub は、制御されたデバイスからクラウドへの境界を提供します。デバイスやゲートウェイは固有の ID で認証され、デバイスからクラウドへのメッセージを送信し、デバイス管理の状態を維持し、制御されたクラウドからデバイスへの通信にも参加できます。

テレメトリメッセージが IoT Hub に到達すると、Message Routing がそのデータの送り先を決定します。ルーティングでは、メッセージのプロパティ、システムプロパティ、メッセージ本文の一部、デバイスツインの情報を検査できます。これにより、下流のコンシューマーに届く前に、生産テレメトリ、エネルギー計測、診断などのメッセージクラスを分離することが可能になります。
一般的なアーキテクチャは次のようになります:産業用ゲートウェイ → Azure IoT Hub → Message Routing → Event Hubs または Storage → 処理 → Microsoft Fabric。

あるコンシューマーはほぼリアルタイムの分析を実行し、別のコンシューマーは生データのアーカイブを保持します。三つ目のコンシューマーは、Microsoft Fabric 向けに整理された運用データを準備するかもしれません。それぞれのコンシューマーは、すべてのテレメトリ値をワークフローの起動に変えることなく、独立して動作できます。

順序が重要な理由
産業用テレメトリは、特に順序に敏感です。マシンが稼働状態に入ったと報告し、その後いくつかのサイクル数を送信し、続いてプロセス逸脱が発生し、最後に停止状態になったと想像してください。これらのレコードが誤って再構築されると、下流のシステムは、マシンが停止中に部品を生産したと結論づけたり、生産が終了した後にプロセス逸脱が起きたと判断したりするかもしれません。

同じ問題は、ダウンタイムの計算、OEE、生産数、状態監視にも影響します。したがって、ソースがいつ何かを観測したか、IoT Hub がいつメッセージを受信したか、下流のシステムがいつそれを処理したか、を区別する必要があります。

そのため、堅牢なテレメトリアーキテクチャでは、次の点を考慮すべきです:
• ソースのタイムスタンプとクラウド受信のタイムスタンプ
• 資産またはワークロードに適した安定したパーティショニング
• 重複検出のためのメッセージ ID またはシーケンス番号
• 少なくとも 1 回の配信を扱えるべき等なコンシューマー

ネットワーク断があると、これは特に重要になります。ゲートウェイはテレメトリをバッファリングし、接続が回復したときに送信することがあるため、Azure への到着時刻は実際のマシンのタイムスタンプより大幅に遅れることがあります。

Event Grid は別の問題を解決します
Azure Event Grid は、パブリッシュ・サブスクライブ型の通知を中心に設計されています。何千もの計測値からマシンの状態を連続的に再構築する代わりに、Event Grid は関心のあるシステムに何かが変化したことを知らせ、サブスクライバーに対応の機会を与えます。
IoT 環境での例には、デバイスの作成、削除、接続、切断、あるいは慎重に選択されたテレメトリ由来の状態が含まれます。デバイス作成イベントは資産のオンボーディングプロセスを起動するかもしれません。デバイス切断イベントは技術的な調査を開始するかもしれません。検出されたエンジニアリング上の状態は保全ワークフローを起動するかもしれません。

代表的なサブスクライバーには次のものがあります:
• Azure Functions
• Logic Apps
• Webhook
• セキュリティワークフロー
• 資産管理システム
• 運用アプリケーション

根本的なアーキテクチャ上の違いは単純です。テレメトリは「資産が何をしてきたか」を問い、イベントは「何が変化したか、そして何かに反応すべきか」を問うのです。

イベントは調査を開始すべきであり、現実を定義すべきではない
Event Grid は、一般的に通知の仕組みとして扱うべきであり、物理世界の最終的な権威ある状態として扱うべきではありません。イベントの配信は繰り返されることがあり、サブスクライバーは、確認せずにイベントを最終的な現在の状態として盲目的に解釈すべきではありません。
そのため、デバイス切断イベントは通常、状態の確認を引き起こすべきです。Azure Function は、現在のデバイス状態を検証し、直近のテレメトリを調べ、関連するレジストリ情報を確認した上で、調査を継続すべきかどうかを判断するかもしれません。

ハンドラーは次の点を中心に設計すべきです:
• べき等な処理
• 現在の状態の検証
• イベントの識別子とタイムスタンプ
• 結果として生じる対応の所有者の明確な定義

これは重要です。重複したイベントによって、重複したチケット、重複したアラート、または矛盾する運用記録が作られるべきではないからです。

デバイスの切断はマシンが停止したことを意味しない
産業用 IoT における最も重要な区別の一つは、クラウド接続、データ収集の健全性、生産状態の違いです。産業用ゲートウェイが IoT Hub から切断された場合、クラウドはそのゲートウェイを把握できなくなります。しかし、それは物理的なマシンが停止したことを自動的に意味するわけではありません。

ゲートウェイの接続が一時的に失われている間も、PLC は現地で機器の制御を続けることがあります。生産は正常に続き、ゲートウェイはテレメトリをバッファリングして後でアップロードするかもしれません。逆のケースも起こり得ます。ゲートウェイは Azure への接続を維持している一方で、PLC や現地機器との接続が失敗していることがあります。

したがって、有用なアーキテクチャでは、クラウド接続の状態、ゲートウェイの健全性、マシンの生産状態、MES の作業指示の状態を分けて扱います。これらの情報源を組み合わせることで初めて、技術的な接続問題が実際に生産に影響したかどうかを事業として判断できます。

IoT Hub のフィルタリングと Event Grid のフィルタリング
両方の技術がフィルタリングをサポートしていますが、その目的は異なります。IoT Hub Message Routing のフィルタリングは、どの運用メッセージが特定のデータ経路に入るべきかを決定します。Event Grid のサブスクリプションフィルタリングは、特定のサブスクライバーがどの通知を受け取るべきかを決定します。

例えば、生産テレメトリは一つの Event Hubs ストリームへ、エネルギーデータは別の宛先へ送られるかもしれません。同時に、サポートワークフローは、特定のデバイスからの切断イベントだけを購読するかもしれません。