IoT Hub 메시지 라우팅 vs Event Grid — 텔레메트리와 이벤트는 같은 문제가 아닌 이유

기계는 몇 초마다 온도 측정값, 진동 데이터, 사이클 카운트, 전력 소비량, 그리고 작동 상태를 전송합니다. 그러다 갑자기 게이트웨이 연결이 끊어집니다. 이 모든 메시지를 단순히 "이벤트"라고 부를 수 있을까요? 기술적으로는 그렇게 설명할 수 있습니다. 하지만 아키텍처 관점에서는 심각한 문제를 일으킬 수 있습니다. Azure IoT Hub 메시지 라우팅과 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 메시지 라우팅이 텔레메트리 데이터 플레인의 일부로 작동하는 방식
• Azure Event Grid가 이벤트 기반 및 반응형 아키텍처에서 맡는 역할
• 제조 텔레메트리에서 메시지 순서가 중요한 이유
• Event Grid를 고용량 텔레메트리의 주 버스로 사용하면 안 되는 이유
• 모든 알림 워크플로에 IoT Hub 라우팅을 억지로 적용하면 안 되는 이유
• IoT Hub와 Event Grid가 같은 아키텍처에서 함께 작동하는 방식
• Event Hubs가 독립적인 스트림 처리 소비자를 어떻게 지원할 수 있는지
• 추적성과 이후 조사를 위해 원시 텔레메트리를 보존해야 하는 이유
• Microsoft Fabric과 Power BI가 가공된 운영 데이터를 어떻게 소비할 수 있는지
• MES, ERP, 자산 모델이 기기 데이터만으로는 제공할 수 없는 맥락을 제공하는 이유
• 기기 연결 끊김 이벤트를 생산 중단으로 자동 가정하지 않고 해석해야 하는 이유
• 중복 전달, 재시도, 타임스탬프, 멱등성이 신뢰할 수 있는 산업 아키텍처에 미치는 영향
• 상태 모니터링, 예지 보전, 품질 추적성, 생산 중단 워크플로를 설계하는 방법
• 메시지가 데이터 플레인, 응답 경로, 또는 둘 다에 속해야 하는지 결정하는 방법

텔레메트리는 시간에 따른 기록입니다
텔레메트리는 온도 측정값 하나가 도착했기 때문에 가치가 있는 것이 아닙니다. 수천 개의 측정값이 함께 무슨 일이 일어났는지를 설명하기 때문에 가치가 생깁니다. 생산 설비는 지속적으로 다음을 보고할 수 있습니다.

• 온도 및 진동 측정값
• 모터 전류 및 에너지 소비량
• 사이클 카운트 및 생산 카운터
• 운전, 유휴, 정지, 고장 상태
• 원천 타임스탬프 및 순서 정보
• 진단 및 설비 상태 정보

온도 측정값 하나만으로는 거의 의미가 없을 수 있습니다. 그 전후의 순서가 이야기를 들려줍니다. 설비가 예열 중이었나? 이미 생산 중이었나? 같은 시간에 진동이 증가하고 있었나? 사이클 시간이 늘어나기 시작했나? 그 직후 설비가 멈췄나? 따라서 텔레메트리에는 순서, 보존, 재생, 독립적인 소비자, 추적성을 중심으로 설계된 경로가 필요합니다.

이벤트는 응답을 시작하기 위해 존재합니다
이벤트는 다른 목적을 가집니다. 이벤트는 "무언가 변경되었다"고 알립니다. 시스템이나 사람이 반응해야 할 수도 있습니다. 예를 들면 다음과 같습니다.

• 새 기기가 등록되었을 때
• 게이트웨이가 IoT Hub에서 연결이 끊겼을 때
• 기기가 다시 연결되었을 때
• 기기가 삭제되었을 때
• 모니터링 프로세스가 조사가 필요한 상태를 감지했을 때
• 검사가 완료되어 다른 워크플로를 시작할 수 있을 때

수신자는 보통 첫 단계를 시작하기 전에 몇 시간 분량의 텔레메트리가 필요하지 않습니다. 무슨 일이 일어났는지 식별하고 적절한 대응을 결정할 만큼의 정보만 필요합니다. 그 대응에는 다음이 포함될 수 있습니다.

• Azure Function 시작
• Logic App 트리거
• 지원 조사 열기
• 자산 레코드 업데이트
• 현재 기기 상태 확인
• 웹훅을 통한 외부 애플리케이션 호출
• 영향을 받는 시스템을 담당하는 팀에 알림

이벤트는 조사를 시작합니다. 반드시 최종 운영 결정을 내리는 데 필요한 모든 사실을 담고 있을 필요는 없습니다.

"모든 것은 이벤트다"라는 접근이 무너지는 이유
모든 센서 측정값을 이벤트 트리거 워크플로로 보내는 것은 개념 증명 단계에서는 매력적으로 보일 수 있습니다. 그러나 운영 규모에 이르면 상황이 달라집니다. 모든 측정값이 또 다른 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.