MES와 D365 공급망 연동: Azure 미들웨어 패턴
Source: Dev.to
Dynamics 365 Supply Chain Management를 운영하는 제조업체는 거의 대부분 현장에 전용 Manufacturing Execution System(MES)을 함께 운영합니다. 생산 주문 업데이트, 재고 이동, 품질 검사, 추적성 데이터가 양 시스템 사이에서 지속적으로 흐릅니다. 이 통합은 저지연(현장은 초 단위로 동작하고, 시간 단위가 아님), 고처리량(피크 시 분당 수백 건 이벤트), 신뢰성(메시지 손실은 추적성 손실을 의미)이어야 합니다.
평가 과정에서 등장한 세 가지 통합 패턴이 있습니다. 그 중 두 가지는 이미 알려진 실패 모드가 존재합니다.
-
Data Management Framework를 이용한 야간 배치 작업
대량 데이터 이동에 최적화돼 있어 실시간 신호 전달에는 부적합합니다. 생산 주문이 완료된 지 몇 시간이 지나야 D365에 반영됩니다. 실시간 재고 뷰는 항상 지연되고, 추적성 데이터는 이미 출하된 배치 이후에 도착합니다. -
몇 초마다 MES를 조회하는 커스텀 OData 폴링
지연 시간 감소 효과 없이 폴링 오버헤드만 발생합니다. MES는 일반적으로 무거운 폴링 부하를 감당하도록 설계되지 않았으며, 유지보수가 필요한 커스텀 코드 의존성을 만들게 됩니다. -
MES 데이터베이스 수준 트리거가 직접 F&O 데이터베이스에 푸시
지원성을 완전히 무너뜨립니다. D365 F&O는 관리형 플랫폼이며, 직접 데이터베이스 쓰기는 지원되지 않고 업그레이드 시 안전하지 않으며, Microsoft가 스키마를 변경하면 바로 깨집니다. 또한 보안 문제가 심각합니다( MES가 F&O 데이터베이스에 특권 쓰기 권한을 갖는 상황).
요구 사항을 모두 만족시키는 유일한 답은 두 시스템 사이에 Azure 미들웨어를 두는 것입니다.
- Azure Service Bus – 보장된 전달과 순서 보장을 위한 메시징. 생산 주문 상태 업데이트, 재고 이동, 품질 검사 결과가 생산 주문별 FIFO 순서로 Service Bus 큐를 통해 흐릅니다.
- Azure Logic Apps – 분기와 변환이 일어나는 오케스트레이션 레이어. MES에서 “pick-complete” 이벤트가 발생하면 Logic App이 트리거되어 페이로드를 변환하고, D365의 재고를 업데이트하며, 다음 생산 흐름 메시지를 다시 MES에 전송합니다.
- F&O Business Events – D365 측에서 이벤트를 발행. 생산 주문이 생성·출시·완료될 때 비즈니스 이벤트가 Service Bus 또는 Event Grid로 전송되고, MES 구독자가 이를 받아 처리합니다.
- F&O 커스텀 서비스 – 인바운드용. MES에서 상태 변화가 발생해 D365에 기록이 필요할 때, Logic App(또는 Function)이 F&O에 있는 커스텀 서비스 엔드포인트를 호출합니다. 커스텀 서비스는 대량 최적화된 데이터 엔터티와 달리 저지연, 타깃 레코드 쓰기에 최적화돼 있습니다.
추적성(Traceability) 요구사항
제조업에서는 규제기관과 고객이 원자재가 어떤 완제품 배치에 들어갔는지를 알아야 합니다. D365의 배치 추적과 MES의 현장 배치 기록이 결합돼 전체 계보를 완성합니다. 통합을 통해 다음을 보장합니다.
- MES는 물리적 이동을 기록합니다(예: 기계 X가 시간 Z에 배치 Y를 가공).
- D365는 ERP 수준 배치를 기록합니다(예: 원자재 배치 A가 생산 주문 B에서 소비돼 완제품 배치 C를 생산).
- 두 시스템은 배치 번호와 생산 주문 참조를 통해 연계됩니다.
- 리콜 시나리오에서는 판매된 완제품에서 원재료까지 역추적하거나, 의심되는 원재료에서 영향을 받은 완제품까지 정방향 추적이 가능합니다.
통합은 단순 데이터 이동이 아니라 모든 실패 모드에서도 연계성을 유지하는 것이 핵심입니다.
대규모 제조 환경에서의 처리량 계획
- Service Bus 규모 – 대부분의 배포에서는 Standard 티어면 충분합니다. 메시지 양이 Standard 티어의 처리량 단위를 초과할 경우에만 Premium을 고려합니다.
- Logic Apps 동시 실행 – 워크플로우당 설정 가능하며 기본값은 20 동시 실행입니다. 고처리량 흐름은 더 높은 동시성을 필요로 합니다.
- F&O 쓰기 용량 – 커스텀 서비스는 단일 레코드 쓰기에 데이터 엔터티보다 빠릅니다. MES가 여러 업데이트를 한 번에 보낼 경우 배치를 활용합니다.
- Dead‑letter 모니터링 – Service Bus DLQ에 항목이 생기면 알림을 발생시킵니다. 이는 보통 변환 오류이며, 사람의 검토가 필요합니다.
메시지 손실을 허용할 수 없는 제조 현장
아키텍처는 다음을 포함합니다.
- Logic Apps에서 일시적 오류에 대비한 지수 백오프 재시도
- Poison 메시지를 위한 Dead‑letter 큐
- 재시도 시 중복 기록을 방지하는 멱등성 키(Idempotency key)
- 시스템 간 디버깅을 위한 Correlation ID 전파
- 큐당 처리량·지연 시간을 시각화하는 모니터링 대시보드
양방향 흐름 구조
MES → D365 (현장에서 ERP로 업데이트)
- MES가 Service Bus 토픽에 게시
- Logic App이 구독, 변환, F&O 커스텀 서비스 호출
- F&O가 재고, 생산 주문 상태, 품질 기록을 업데이트
D365 → MES (현장에 작업 전달)
- 생산 주문 출시 시 F&O 비즈니스 이벤트 발생
- 이벤트가 Service Bus로 흐름
- MES 구독자가 작업 패키지를 받아 라인에 배분
양방향 연계
- 헤더에 포함된 Correlation ID
- 중요한 상태 전환에 대한 핸드쉐이크 패턴(예: “주문 준비 완료” → “라인에서 주문 수락”)
Logic Apps 외에 사용되는 Azure 컴포넌트
- Azure Functions – Logic Apps가 표현하기 어려운 복잡한 변환
- Custom services in F&O – 표준 엔터티가 커버하지 않는 쓰기
- Durable Functions – 며칠에 걸친 장기 오케스트레이션
각 컴포넌트는 명확한 사용 사례가 있습니다. 선언형 도구가 한계에 부딪혔을 때만 활용하고, 기본 선택지는 아닙니다.
실제 적용 예시
- 생산 주문 또는 라인별로 파티션된 Service Bus 큐·토픽
- 각 방향 흐름마다 변환 로직을 담은 Logic Apps
- 생산 주문 라이프사이클에 맞춰 발행되는 비즈니스 이벤트
- MES에서 들어오는 쓰기를 담당하는 F&O 커스텀 서비스
- Dead‑letter 큐 모니터링 및 알림 설정
- 추적성 검증 – 분기별 리콜 시나리오 샘플링 체크
- 새로운 MES 모듈 추가 시 통합을 확장하기 위한 Runbook
이 패턴은 아키텍처 수준의 솔루션이며, 제조 시스템은 단순 옵션을 견디지 못합니다. Azure 미들웨어가 지원되고, 확장 가능하며, 유지보수가 가능한 유일한 방법입니다.