IoT 데이터를 D365 공급망에 연동: Azure 네이티브 패턴
출처: Dev.to
Dynamics 365 Supply Chain Management를 운영하는 물류·유통 업체들은 실시간 운영 데이터, 즉 GPS로 추적되는 선적, RFID에서 읽어들인 재고, 텔레메트리에서 얻는 차량 상태와 같은 데이터를 점점 더 필요로 합니다. 문제는 “해야 할까?”가 아니라 “맞춤형 파이프라인을 직접 구축할까, 아니면 Microsoft가 이미 제공하는 서비스를 사용할까?” 입니다.
논의에서 등장하는 세 가지 아키텍처가 있습니다. 그 중 두 가지는 규모에 맞지 않습니다.
Azure 텔레메트리 스택에 익숙하지 않은 팀은 종종 다음 중 하나를 초안합니다:
- Excel + 배치 가져오기: 센서 데이터를 스프레드시트에 저장하고, 매시간 DMF를 통해 F&O에 가져옵니다. 센서 볼륨(플릿 전체에서 초당 수천 건)이 Excel을 금방 한계에 도달하게 하므로 F&O 배치 창에 도달하기도 전에 실패합니다.
- 타사 통합 플랫폼 + 일일 푸시: 문제를 외부에 넘겨버리고 팀의 통제 밖으로 밀어냅니다. 실시간 예측 인사이트가 어제의 스냅샷이 됩니다.
- SharePoint 수동 로깅: 초기 아키텍처 워크숍에서 놀랍게도 자주 제안됩니다. 파일럿 트럭 한 대를 넘어서는 규모로 확장되지 못합니다.
이들 방법은 어느 것도 근실시간 데이터를 제공하지 못하고, 플릿 규모로 확장되지도 못합니다.
Microsoft가 권장하는 시나리오용 레퍼런스 아키텍처는 다음과 같습니다:
- 수집 레이어: Azure IoT Hub가 모든 디바이스(센서, RFID 리더, 차량 텔레메트리)로부터 텔레메트리를 수신합니다. 디바이스 종류당 하나의 MQTT 또는 AMQP 엔드포인트를 두고, IoT Hub 유닛으로 확장합니다.
- 스트림 처리: Azure Stream Analytics가 IoT Hub에서 데이터를 읽어, 윈도우(예: 차량 위치는 1분 롤링 윈도우, 재고 읽기는 5분 윈도우)로 묶고, 집계와 이상 탐지를 인라인으로 수행합니다.
- 보강 및 라우팅: Stream Analytics는 여러 싱크로 출력합니다 – 운영 데이터를 소비하는 Power Apps용 Dataverse, 워크플로 트리거용 Azure Service Bus, 콜드 스토리지·분석용 Azure Blob.
- D365로 전달: Dataverse 변경(또는 Service Bus 메시지)으로 트리거되는 Power Automate 흐름이 데이터 엔터티 또는 비즈니스 이벤트를 통해 F&O를 업데이트합니다. 매우 높은 처리량이 필요하면 Power Automate를 우회하고 맞춤형 서비스로 직접 F&O에 호출합니다.
- 분석 레이어: 콜드 Blob 스토어는 Azure Synapse에 연결돼 예측 모델을 학습하고, 예측 결과는 Dataverse를 통해 다시 F&O의 마스터 플래닝 입력으로 돌아갑니다.
이 스택은 맞춤 인프라 없이도 하루에 수백만 건의 이벤트를 처리할 수 있습니다.
아키텍처 선택 시 고려사항:
- Stream Analytics vs Azure Functions: Stream Analytics는 선언형 SQL‑유사 구문과 내장 윈도우 기능을 제공하고, Functions는 더 큰 유연성을 제공하지만 코드량이 늘어납니다. 먼저 Stream Analytics를 사용하고, 한계에 부딪히면 Functions를 도입합니다.
- Dataverse를 핫 스토어로 사용할지, F&O에 직접 기록할지: Dataverse는 빈번한 쓰기를 F&O 테이블보다 잘 감당합니다. Dataverse에 쓰고, Dual‑write 또는 맞춤형 동기화가 F&O가 소화할 수 있는 일정에 맞춰 푸시하도록 합니다.
- Power Automate vs 맞춤 서비스: Power Automate는 분당 수백 건의 트리거까지는 충분합니다. 그 이상이면 F&O 측 맞춤 서비스가 탈출구가 됩니다.
- F&O 내 데이터 볼륨: 모든 센서 읽기를 F&O에 넣지 마세요. Stream Analytics에서 집계(예: “차량 X가 위치 Y에 15분 동안 머물렀다”)하고, 집계 결과만 쓰면 플래너가 실제로 조회하는 데이터만 보관하게 됩니다.
대부분의 프로젝트가 마지막 포인트에서 난관에 봉착합니다. “모든 데이터를 F&O에 보관한다”는 직관이 F&O 성능을 급격히 저하시킵니다.
추가 고려사항:
- 디바이스 아이덴티티: 각 디바이스에 X.509 인증서 또는 SAS 키를 가진 IoT Hub 아이덴티티를 부여합니다. 폐기는 IoT Hub 디바이스 레지스트리를 통해 관리합니다.
- 네트워크 격리: IoT Hub, Stream Analytics, F&O 경계 사이에 Private Link를 설정합니다. 불가피한 경우에만 퍼블릭 엔드포인트를 사용합니다.
- 모니터링: Azure Monitor 대시보드에 IoT Hub 처리량, Stream Analytics 지연 시간, Dataverse 쓰기량을 표시합니다. 어느 싱크가 뒤처지면 알림을 받도록 설정합니다.
- 비용 관리: IoT Hub 유닛과 Stream Analytics 스트리밍 유닛이 주요 비용 요인입니다. 가상의 볼륨이 아니라 측정된 피크 처리량을 기준으로 규모를 정합니다.
실제 작동하는 IoT‑to‑F&O 통합은 다음 요소를 포함합니다: 디바이스 프로비저닝 자동화가 포함된 IoT Hub, 데이터 클래스별 버전 관리된 SQL 쿼리를 가진 Stream Analytics 작업, 운영 예측을 위한 Dataverse 맞춤 테이블, F&O에 쓰는 Power Automate 혹은 맞춤 서비스, 그리고 새로운 디바이스 유형을 추가할 때마다 아키텍처 검토 없이 진행할 수 있는 런북.
구축 비용은 초기 단계에 집중됩니다. 반복 비용은 맞춤형 통합 플랫폼보다 훨씬 낮습니다. 왜냐하면 접착층(IoT Hub, Stream Analytics, Dataverse, Power Automate)이 Microsoft가 관리하기 때문입니다. 이것이 권장 사항입니다: 관리형 서비스에 의존하고, 영원히 유지해야 할 인프라 구축은 피하세요.