IoT Hub 메시지 라우팅 vs 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 또는 시퀀스 번호
• 최소 한 번 전달(at-least-once delivery)을 처리할 수 있는 멱등성 소비자

네트워크 중단은 이 문제를 특히 중요하게 만듭니다. 게이트웨이는 텔레메트리를 버퍼링했다가 연결이 복구되면 전송할 수 있으므로, Azure 도착 시간이 실제 기계 타임스탬프보다 훨씬 늦을 수 있습니다.

Event Grid는 다른 문제를 해결합니다
Azure Event Grid는 게시-구독 방식의 알림을 중심으로 설계되었습니다. 수천 개의 측정값으로부터 기계 상태를 지속적으로 재구성하는 대신, Event Grid는 관심 있는 시스템에 무언가 변경되었음을 알리고 구독자가 반응할 기회를 제공합니다.
IoT 환경의 예로는 장치 생성, 장치 삭제, 연결, 연결 해제, 또는 신중하게 선택된 텔레메트리 기반 조건 등이 있습니다. 장치 생성 이벤트는 자산 온보딩 프로세스를 시작할 수 있습니다. 장치 연결 해제 이벤트는 기술 조사를 시작할 수 있습니다. 감지된 엔지니어링 조건은 유지보수 워크플로를 트리거할 수 있습니다.

일반적인 구독자는 다음과 같습니다.
• Azure Functions
• Logic Apps
• 웹훅
• 보안 워크플로
• 자산 관리 시스템
• 운영 애플리케이션

근본적인 아키텍처 차이는 간단합니다. 텔레메트리는 자산이 무엇을 해왔는지 묻고, 이벤트는 무엇이 변경되었는지, 그리고 무언가 반응해야 하는지를 묻습니다.

이벤트는 현실을 정의하는 것이 아니라 조사를 시작해야 합니다
Event Grid는 일반적으로 알림 메커니즘으로 취급해야 하며, 물리적 세계의 최종 권위 있는 상태로 취급해서는 안 됩니다. 이벤트 전달은 반복될 수 있으며, 구독자는 확인 없이 이벤트를 최종 현재 상태로 맹목적으로 해석해서는 안 됩니다.
따라서 장치 연결 해제 이벤트는 보통 상태 확인을 트리거해야 합니다. Azure Function은 현재 장치 상태를 확인하고, 최근 텔레메트리를 검사하고, 관련 레지스트리 정보를 확인한 뒤 조사가 계속 열려 있어야 하는지 결정할 수 있습니다.

핸들러는 다음을 기준으로 설계해야 합니다.
• 멱등성 처리
• 현재 상태 검증
• 이벤트 식별자와 타임스탬프
• 결과 조치의 명확히 정의된 소유권

이것이 중요한 이유는 중복 이벤트가 중복 티켓, 중복 경보, 또는 상충하는 운영 기록을 만들어서는 안 되기 때문입니다.

장치 연결 해제가 기계 정지를 의미하지는 않습니다
산업용 IoT에서 가장 중요한 구분 중 하나는 클라우드 연결 상태, 데이터 수집 상태, 생산 상태의 차이입니다. 산업용 게이트웨이가 IoT Hub 연결을 잃으면, 클라우드는 그 게이트웨이에 대한 가시성을 잃은 것입니다. 이것이 자동으로 물리적 기계가 정지했음을 의미하지는 않습니다.

게이트웨이 연결이 일시적으로 끊겨도 PLC는 현장에서 장비를 계속 제어할 수 있습니다. 생산은 정상적으로 계속될 수 있고, 게이트웨이는 텔레메트리를 버퍼링했다가 나중에 업로드할 수도 있습니다. 반대의 경우도 발생할 수 있습니다. 게이트웨이가 Azure에는 계속 연결되어 있어도 PLC나 현장 장비와의 연결이 실패할 수 있습니다.

따라서 유용한 아키텍처는 클라우드 연결 상태, 게이트웨이 상태, 기계 생산 상태, MES 작업 지시 상태를 분리합니다. 이러한 소스들을 결합해야만 기술적 연결 문제가 실제로 생산에 영향을 주었는지 비즈니스가 판단할 수 있습니다.

IoT Hub 필터링과 Event Grid 필터링의 차이
두 기술 모두 필터링을 지원하지만 목적은 다릅니다. IoT Hub Message Routing 필터링은 어떤 운영 메시지가 특정 데이터 경로로 들어가야 하는지를 결정합니다. Event Grid 구독 필터링은 특정 구독자가 어떤 알림을 받아야 하는지를 결정합니다.

예를 들어, 생산 텔레메트리는 하나의 Event Hubs 스트림으로 보내고, 에너지 데이터는 다른 대상으로 보낼 수 있습니다. 동시에 지원 워크플로는 특정 장치에서 발생한 연결 해제 이벤트만 구독할 수 있습니다.