IoT Hub Message Routing vs Event Grid — テレメトリとイベントは同じ問題ではない理由

機械は、温度の測定値、振動データ、サイクル数、消費電力、稼働状態などを数秒ごとに送信します。そして突然、ゲートウェイが切断されます。これらのメッセージはすべて単なる「イベント」なのでしょうか。技術的には、そのように表現することもできます。しかしアーキテクチャの観点では、それが深刻な問題を引き起こす可能性があります。Azure IoT Hub Message Routing と Azure Event Grid は、異なる課題を解決するためのものです。一方の経路は、運用データの保持と配布を目的として設計されています。もう一方は、何かが変化し、対応が必要かもしれないことをシステムに通知するために設計されています。両者を同じものとして扱うと、日常的なセンサーデータを処理するために高コストなワークフローを抱え込んだり、誰も積極的に監視していないテレメトリパイプラインの中に重要なシグナルが埋もれてしまったりする恐れがあります。本エピソードの M365 FM では、製造機械を追いながら実際の Azure IoT アーキテクチャをたどり、IoT Hub、Event Grid、Event Hubs、Microsoft Fabric、Power BI、MES、ERP、Functions、Logic Apps がそれぞれどこに位置づけられるのかを解説します。

本エピソードで学べること：

• 機械のテレメトリと、個別の業務イベントやライフサイクルイベントが、それぞれ異なるアーキテクチャパターンを必要とする理由
• Azure IoT Hub Message Routing がテレメトリのデータプレーンの一部としてどのように機能するか
• Azure Event Grid がイベント駆動型およびリアクティブなアーキテクチャのどこに位置するか
• 製造テレメトリにおいてメッセージの順序が重要である理由
• Event Grid を大量のテレメトリを扱う主要なバスにすべきでない理由
• すべての通知ワークフローに IoT Hub のルーティングを強制すべきでない理由
• IoT Hub と Event Grid が同じアーキテクチャの中でどのように連携できるか
• Event Hubs が独立したストリーム処理コンシューマーをどのように支えるか
• トレーサビリティや後日の調査のために、生のテレメトリを保持すべき理由
• Microsoft Fabric と Power BI が、加工済みの運用データをどのように利用できるか
• デバイスデータだけでは得られない文脈を、MES、ERP、アセットモデルがどのように提供するか
• デバイスの切断イベントを、生産が停止したと自動的に決めつけずに解釈する方法
• 重複配信、再試行、タイムスタンプ、冪等性が、信頼性の高い産業アーキテクチャにどう影響するか
• 状態監視、予知保全、品質トレーサビリティ、生産中断に対応するワークフローの設計方法
• あるメッセージをデータプレーン、対応経路、あるいはその両方のどこに置くべきかを判断する方法

テレメトリは時間の経過を記録したものです

テレメトリの価値は、温度の測定値が1件届いたことにあるのではありません。何千もの測定値が集まることで、何が起きたのかが見えてくることにあります。生産機械は継続的に次のような情報を報告することがあります：

• 温度と振動の測定値
• モーター電流と消費エネルギー
• サイクルカウントと生産カウンター
• 稼働中、待機中、停止中、故障中といった状態
• ソースタイムスタンプとシーケンス情報
• 診断情報と設備の健全性に関する情報

1つの温度値だけでは、ほとんど意味を持たないかもしれません。その前後の並びこそが、物語を語ります。機械はウォームアップ中だったのか。すでに生産していたのか。振動が同時に増加していたのか。サイクルタイムが延びはじめていたのか。直後に機械が停止したのか。したがってテレメトリには、シーケンス、保持、リプレイ、独立したコンシューマー、トレーサビリティを前提とした経路が必要になります。

イベントは対応を開始するために存在します

イベントには別の目的があります。イベントは次のことを伝えます：何かが変化した。システムや人が対応する必要があるかもしれない。例としては次のようなものがあります：

• 新しいデバイスが登録された
• ゲートウェイが IoT Hub から切断された
• デバイスが再接続された
• デバイスが削除された
• 監視プロセスが調査を必要とする状態を検出した
• 検査が完了し、次のワークフローを開始できる

通常、受信側は最初のステップを開始するために数時間分のテレメトリを必要としません。必要なのは、何が起きたかを特定し、適切な対応を判断するのに十分な情報です。その対応には次のようなものが含まれます：

• Azure Function の開始
• Logic App のトリガー
• サポート調査の起票
• アセットレコードの更新
• 現在のデバイス状態の確認
• Webhook による外部アプリケーションの呼び出し
• 影響を受けたシステムを担当するチームへの通知

イベントは調査を始めるきっかけになります。ただし、最終的な運用判断に必要なすべての事実を必ずしも含んでいるわけではありません。

「すべてがイベントである」という考え方が破綻する理由

概念実証の段階では、すべてのセンサー測定値をイベントトリガーのワークフローに流し込むことが魅力的に見えるかもしれません。しかし本番規模になると状況は一変します。測定値の1件ごとに Function が起動し、別の Logic App が何かを評価し、また別の連携が新たなメッセージを受け取ります。保守チームが独自のサブスクリプションを作り、品質チームもまた作る。エネルギー管理チームも同様です。やがて、チームごとに微妙に異なるフィルタリング、状態管理、再試行処理、ストレージロジックが乱立します。温度の測定値は、それ自体が自動的にインシデントになるわけではありません。後にインシデントの一部になるかもしれませんが、継続的な測定値は証拠として保持されるべきです。日常的なテレメトリが絶え間なく通知を生み出すようになると、システムが「ノイズ」に慣れさせてしまうため、利用者は実際に対応を要する情報であってもアラートを無視しはじめるかもしれません。

Azure IoT Hub が実際に担う役割

Azure IoT Hub は、デバイス側に向けたクラウドの境界を提供します。次のような領域をサポートします：

• 安全なデバイス ID
• デバイスからクラウドへのメッセージング
• クラウドからデバイスへの通信
• デバイス管理
• デバイスツイン
• 接続された機器と Azure サービスの間の制御されたアクセス

IoT Hub は、認証されたデバイスがメッセージを送信したことを把握します。しかし、そのメッセージが生産にとって何を意味するのかを自動的に理解するわけではありません。ゲートウェイが次のように報告したとします：state = running しかし「running」は次のことを意味しうるのです：

• 承認済みの部品を生産している
• 材料なしで空運転している
• 段取り作業を行っている
• 手直し作業を行っている
• 材料を伴わずに動いている

その文脈は通常、MES、ERP、アセットモデル、生産アプリケーションといった追加のシステムから得られます。

このポッドキャストの支援者になる： https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.