IoT Hub vs Event Hubs — 대부분의 제조사가 잘못된 서비스를 선택하는 이유

1. 공장 현장의 증상과 핵심 과제팀은 초기 워크숍에서 그럴듯해 보이는 서비스를 골라 플랜트 텔레메트리를 Azure로 전송하는 경우가 많으며, 이후 몇 달이 지나서야 해당 데이터 경로가 실제 플랜트 운영을 감당하지 못한다는 사실을 발견합니다. 이로 인해 같은 신호의 복사본에서 파생된 값(예: 5분 평균과 최대값 또는 알람을 비교한 값)들이 서로 충돌하는 여러 대시보드가 나타나는 경우가 흔합니다. 결국 이 기술적 단절은 단순한 소프트웨어 버그가 아니라 신뢰의 문제가 됩니다. 근본적인 실수는 수신되는 모든 기계 데이터를 일반적인 텔레메트리로 취급하고, 장치 제어, 구성 상태, 명령, 스트림 처리를 분리하지 않는 데 있습니다.

2. 공장 트래픽 분류Azure 서비스를 선택하기 전에 적절한 처리를 보장하기 위해 트래픽을 이름, 방향, 소유권 기준으로 분류해야 합니다.

• 이벤트(Events)는 특정 시점과 연결된 사실, 즉 무엇이 언제 일어났는지를 나타냅니다. 예를 들어 프레스 사이클 완료나 한계값을 넘은 진동 측정값이 여기에 해당합니다. 이는 추가만 가능한(append-only) 기록이며 하류에서 편집해서는 안 됩니다.
• 명령(Commands)은 장치나 게이트웨이에 특정 의도를 가지고 작업 수행을 지시하는 요청으로, 예를 들어 진단 정보 수집이나 연결 테스트가 있습니다. 명령은 실행 책임을 수반하며 로컬 PLC(프로그래머블 로직 컨트롤러) 및 안전 경계를 준수해야 합니다.
• 상태(State)는 장치의 완전한 시간순 이력이 아니라 현재 알려진 상태, 예를 들어 소프트웨어 버전이나 활성 레시피 매핑을 나타냅니다. 상태는 일반적으로 원하는 속성(desired)과 보고된 속성(reported)을 통해 관리됩니다.
• 비즈니스 메시지(Business messages)는 반드시 수행되고 추적되어야 하는 운영 작업으로, 품질 보류나 유지보수 요청이 포함됩니다. 이들은 원시 센서 이벤트 파이프라인에 직접 섞여서는 안 됩니다.

3. 멘탈 모델: 아이덴티티 게이트 vs. 데이터 고속도로Azure IoT Hub는 통제된 게이트 역할을 하며, 주로 아이덴티티 레지스트리, 인증, 활성/비활성 상태를 통해 장치 관계와 수명 주기를 관리합니다. 이를 통해 보안 팀은 사고 발생 시 특정 손상되었거나 의심스러운 게이트웨이(예: 4라인 게이트웨이)만 격리하거나 비활성화할 수 있으며, 플랜트 전체의 텔레메트리 경로를 중단할 필요가 없습니다. 반면 Azure Event Hubs는 데이터 고속도로 역할을 하며, 많은 독립적인 리더를 위한 스트림 처리와 대용량 데이터 이동에 전적으로 집중합니다. Event Hubs는 장치 수명 주기, 펌웨어, 원하는 구성을 관리하지 않으며, 주된 역할은 파티션과 컨슈머 그룹을 통해 트래픽을 효율적으로 흐르게 하는 것입니다.

4. 장치 관리 및 보안인증 옵션은 하드웨어 기능과 보안 아키텍처에 크게 좌우됩니다. SAS 토큰을 사용하는 대칭 키는 제약이 있는 하드웨어와 게이트웨이에 적합하지만, 키 탈취를 막기 위해 안전한 하드웨어 저장소가 필요합니다. 또는 X.509 인증서는 신뢰할 수 있는 인증 기관(CA)을 통해 더 깔끔한 인증 체인을 제공하여 대규모 장치군에 적합하지만, 견고한 교체 및 수명 주기 관리가 필요합니다. 장치 수명 주기는 등록, 변경, 비활성화, 교체의 패턴을 따르며, 이를 통해 교체된 하드웨어가 운영 역할 및 클라우드 아이덴티티와 깔끔하게 연결되어 하류 파이프라인을 깨뜨리거나 유령 자산을 만들지 않도록 합니다. 또한 장치 트윈(device twin)은 구성 관리와 상태 점검을 위해 원하는 상태와 보고된 상태를 활용하지만, 고빈도 텔레메트리는 절대 장치 트윈에 저장해서는 안 됩니다.

5. 스트림 처리 및 라우팅 메커니즘파티션은 스트림을 순서가 보장되는 차선으로 나누며, 순서 보장은 단일 파티션 내에서만 엄격하게 적용됩니다. 보통 비즈니스 로직에 따라 기계, 라인 또는 게이트웨이 ID 기준으로 파티셔닝합니다. 컨슈머 그룹은 OEE 계산기, 상태 모니터링 도구, 데이터 레이크 수집 서비스 등 여러 하류 시스템이 읽기 위치를 경쟁하지 않고 같은 스트림을 독립적으로 읽을 수 있게 합니다. 스트림 보존 기간은 단기 복구, 장애 허용, 재생을 통한 로직 수정을 위한 작업 창을 제공합니다. 그러나 스트림 보존은 장기 기록을 위한 영구 히스토리안이나 레이크하우스를 대체하지 않습니다.

6. 아키텍처 결정 요약서비스를 평가할 때 Azure IoT Hub는 관리형 엣지 게이트웨이, 원격 구성, 장치별 레지스트리와 네이티브 장치 트윈을 통한 장치 보안 격리에 가장 적합합니다. Azure Event Hubs는 네임스페이스 수준 액세스 정책을 사용해 여러 컨슈머에게 지속적이고 대용량의 텔레메트리를 분배하는 데 가장 적합하며, 네이티브 장치 수명 주기 관리는 제공하지 않습니다. 견고한 공장 아키텍처는 종종 두 가지를 결합하여, 연결 경계에서는 IoT Hub를 사용해 신뢰, 아이덴티티, 구성을 관리하고, 하류에서는 Event Hubs를 사용해 대용량 이벤트 스트림을 독립적인 컨슈머들에게 안전하게 분배합니다.






이 팟캐스트의 서포터가 되어주세요: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.