IT 인프라는 공급망 관리 프로세스의 중추로서, 고객의 경험과 회사의 수익에 영향을 미치는 활동을 가능하게 하거나 제한할 수 있습니다. 공급망 관리에서의 디지털 전환 추진은 대개 비용, 고객 경험, 민첩성의 3가지 요소로 구성됩니다. 이들 모두 실시간 커뮤니케이션과 실시간 데이터 액세스 용이성의 영향을 크게 받습니다. 아울러, 새로운 10년의 시작과 더불어 우리가 나아가야 할 방향을 제시합니다.
이미 많은 기업들이 공급망을 활성화하여 Amazon, Allibaba, Shopify와 같은 거대 기업들과 경쟁하고, 국제 운송을 선도하며, 가격을 정확히 통제하고, AI, IoT 및 스트리밍 분석과 같은 새로운 도구를 이용하여 배송 지연을 예측 및 방지하기 위해 노력하고 있습니다. 이들 기업들은 IT 인프라가 실시간 데이터에 적응하는 데 필요하다는 인식을 바탕으로, 공급망 관리에 디지털 전환을 수용하여 운영 효율성을 최적화하고 더 나은 고객 경험을 창출하고 있습니다.
이 주제에 대한 수준 높은 웨비나에 관심이 있는 경우 다음 동영상을 확인하십시오.
공급망 및 전통적 통합 솔루션
해상 운송이 날씨, 기계적 문제, 항구에서의 지연으로 인해 지연되는 일은 흔히 일어납니다. 또한 각각의 지연이 공급망에 파급효과를 가져오는 것도 놀랄 일이 아닙니다. 예를 들어, 허리케인은 이번 주에 항구에 도착할 예정이었던 선적물 운송을 지연시킵니다. 그러면 컨테이너를 집하하기 위해 예정되었던 운송 트럭/로리의 일정은 변경되어야 하고, 그 선적물을 필요로 하는 생산 작업도 지연됩니다.
전통적인 통합 솔루션은 폴링 및 점대점 통합 방식을 사용하여 공급망의 이 부분을 관리합니다. 사용자는 선박 관리 서비스(보통 ClearMetal, OceanIT 등의 SaaS)를 폴링하여 모든 선적물의 상태를 확인합니다. 보고할 내용이 없는 경우에는 회신 메시지에 표시됩니다. 또한 REST API 등을 사용하여 항구의 운송 관리자 애플리케이션(예: Oracle OTM)과 항구의 스케줄링 애플리케이션을 점대점 통합으로 연결해야 합니다. 생산 관리 또는 ERP(전사적 자원 관리)를 추가하려면 다른 점대점 통합을 추가해야 합니다.
이벤트 중심 아키텍처는 공급망 관리 시스템과 같은 분산 시스템에 대한 다른 사고 방식입니다. 자체적인 어려움이 없지는 않지만, 기존의 통합 솔루션에서는 얻을 수 없었던 확장성, 유연성 및 민첩성의 이점을 누릴 수 있습니다.
위의 공급망 관리 예시의 IT 인프라가 이벤트 중심 아키텍처를 사용하여 구축되었다면, 지연은 해당 토픽을 나타내는 이벤트 브로커에 ‘게시’되고 이벤트 브로커는 이벤트를 ‘구독’하여 해당 토픽이 있는 이벤트를 수신하도록 모든 애플리케이션에 이벤트를 전달했을 것입니다. 이는 애플리케이션들이 서로 직접 연결되지 않고 일반적으로 서로의 존재를 인지하지도 못하는 느슨하게 결합된 아키텍처로 이어집니다.
공급망 관리에 대한 느슨한 결합의 이점
이벤트 중심 아키텍처에서는 응답을 예상하지 않고 이벤트가 전송됩니다. 이것이 공급망 관리에 있어 IT 인프라에 좋은 아이디어인 이유는 무엇일까요? 바로 전송자와 수신자 간에 종속성이 없다는 것을 의미하기 때문입니다.
앞서 설명한 예에서, 선박 관리 애플리케이션은 배송 지연과 관련된 이벤트를 청취하고 있는 다른 애플리케이션을 알지 못합니다. 따라서 선박 관리 시스템에 수정하거나 통지할 필요 없이, 특정 ERP 애플리케이션을 혼합 구성에 추가하여 지연에 관한 이벤트를 구독시킬 수 있습니다. 이렇게 하면 동일한 이벤트로 새로운 작업을 수행하는 새 애플리케이션을 더욱 빠르고 쉽게 추가, 설계 및 배치할 수 있습니다. 이러한 비결합은 이미 존재하는 애플리케이션에 종속되거나, 애플리케이션의 추가 또는 변경을 걱정할 필요 없이 새 코드를 작성하거나 기존 시스템을 수정할 수 있다는 점에서 비즈니스 의사 결정을 개선합니다.
또한 폴링 간격이 만료될 때까지 기다릴 필요가 없으므로 실시간으로 작업을 처리하고 조치를 취할 수 있습니다. 변경되지 않은 데이터의 처리 대역폭과 처리 능력을 더 이상 낭비하지 않아도 되며, 잦은 폴링으로 인해 생산/배송 기간을 놓칠 위험도 없어집니다.
이벤트의 원활한 흐름: 이벤트 브로커의 책임
이벤트 중심 아키텍처에서, 토픽 계층 우수 사례와 결합된 이벤트 브로커는 애플리케이션이 위치한 위치(클라우드, 사내)에 관계없이 원하는 애플리케이션으로 이벤트를 수신, 필터링 및 라우팅하는 역할을 수행합니다. 모든 애플리케이션은 이벤트 브로커에 연결되고 브로커는 이미터에서 이벤트를 가져와 청취자에게 제공합니다.
토픽 라우팅 및 필터링
이벤트 브로커를 IT 인프라에 추가하려면 이벤트가 올바른 애플리케이션으로 전달되도록 메타데이터로 태깅되었는지 확인해야 합니다. 이 ‘태그’를 토픽이라고 하며, 이벤트가 참조하는 내용을 설명합니다. 토픽은 이벤트 자체를 설명하지는 않습니다. 이는 이벤트 데이터 또는 페이로드의 일입니다.•토픽은 이벤트에 포함된 내용을 설명하는 계층적 폴더 구조와 약간 비슷합니다. 이벤트 제작자는 이벤트를 보낼 주제를 알고 이벤트 브로커가 나머지를 처리하기만 하면 됩니다. 이벤트 컨슈머는 어떤 토픽을 청취해야 하는지만 알면 됩니다.
애플리케이션이 이벤트를 가져와야 하는 경우, 토픽에 구독하여 관심사를 등록하며, 이를 게시-구독 메시징 패턴이라 합니다. 이 구독은 와일드카드를 사용하여 수신해야 하는 이벤트를 선택합니다.
토픽 분류 및 구독을 사용하면 다음과 같은 이벤트 중심 아키텍처의 두 가지 규칙을 충족시킬 수 있습니다.
- 구독자는 필요한 이벤트만 구독해야 합니다. 구독은 비즈니스 로직이 아닌 필터링을 수행해야 합니다.
- 게시자는 하나의 토픽에 대해 한 번만 이벤트를 전송해야 합니다.
공급망 관리 예시
운송 예시를 살펴보겠습니다. 위젯 컨테이너(1개의 울트라 위젯을 구축해야 함)가 폭풍으로 인해 지연됩니다. 컨테이너 선박 관리 시스템은 다음과 같은 이벤트를 방출합니다.
widgetCo/supplyChain/shipping/v1/delayed/<container ID>/widget
이 이벤트에는 기존 및 새 도착 시간과 같은 변경 세부사항과 문서 번호 등과 같은 위젯 세부사항이 기록된 페이로드가 있습니다.
운송 관리 시스템은 지연을 인지해야 하므로, 이 이벤트를 구독합니다.
widgetCo/supplyChain/shipping/v1/delayed/>
와일드카드 ‘/>
’에 주목하십시오. 이는 운송 관리가 모든 운송 지연 통지를 수신함을 의미합니다.
공급망 관리 디지털 전환을 위한 이벤트 중심 개념
공급망 관리 디지털 전환을 진행하기 전에 고려해야 할 몇 가지 주요 아키텍처 개념이 있습니다. 이 개념은 다음과 같습니다.
- Event mesh
- 게시-구독 메시징 패턴
- 코리오그래피와 오케스트레이션의 차이
- 이벤트 관리
- 이벤트 중심 디지털 트윈
공급망 관리를 위한 이벤트 메시
위 예시에서는 이벤트의 이용자가 와일드카드로 구독을 사용하여 관심 있는 이벤트만으로 이벤트를 필터링하는 방법을 보여 주었습니다. 하지만 이벤트 라우팅은 어떨까요?
애플리케이션은 여러 환경(온프레미스, 복수의 클라우드)과 여러 지역에서 호스팅될 수 있습니다. 공급망 관리에서 회사는 국제적으로 물건을 발송할 가능성이 매우 높습니다. 전 세계에 이벤트를 전송하거나 모든 것을 하나의 중심점에 연결할 필요성을 없애기 위해서는 어느 이벤트를 어디에 보내야 하는지 결정해야 하며, 이를 이벤트 라우팅이라 합니다. 싱가포르행 컨테이너 지연에 대한 이벤트를 캐나다의 운송 관리 애플리케이션으로 보내는 것은 이러한 이벤트가 캐나다에 직접적인 영향을 미치는 경우가 아닌 한 의미가 없습니다.
다행스럽게도 쉬운 방법이 있습니다. 토픽을 보기만 하면 됩니다. 다양한 위치에 있는 이벤트 브로커들이 어디에서 어떤 토픽을 소비하고 있는지 정보를 공유하기만 하면 브로커가 이벤트를 어떻게 어디로 전달해야 하는지를 결정합니다. 이벤트 브로커가 사용자의 토픽 구독 정보를 공유하고 동적으로 메시지를 라우팅할 수 있도록 네트워크에서 이벤트 브로커들을 연결한 것을 이벤트 메시(event mesh)라고 합니다.
위의 예에서 싱가포르 이벤트 브로커는 다른 브로커들에게 싱가포르의 컨테이너 지연 이벤트를 청취하고 있다고 말합니다. 아래 예시는 이벤트 메시(연결된 이벤트 브로커들)가 지리적 경계와 다양한 환경이나 클라우드 서비스에 의해 이전에 부과된 경계를 어떻게 효과적으로 제거하는지를 보여 줍니다.
- 위젯과 기업의 조립 라인이 소재하는 중국의 온프레미스 ERP
- 중국 내 클라우드 서비스 형태의 운송 관리 애플리케이션 SaaS
- 유럽에서 호스팅되는 유럽 선적 라인의 컨테이너 관리 SaaS
게시-구독을 사용한 공급망 성능에 대한 실시간 통찰력
이벤트 스트림이 구축되면 청취자가 방문할 것입니다. 일부 비즈니스 리더는 공급망 성능에 대해 자신의 권리이기도 한 최신 정보를 원할 것입니다. 고급 차량을 주문하기 위한 중요한 경로 중 하나가 세관 검사를 통과하여 고객에게 인도하는 데 걸리는 시간일 경우, 운송, 항만, 세관 및 육상 운송을 통해 진행되는 차량 주문 현황에 대한 대시보드가 필요합니다. 이벤트 메시가 있으면 데이터가 이미 흐르고 있는(게시된) 상태이므로 대시보드에서 캡처(구독)하기만 하면 됩니다.
대시보드는 다음 이벤트를 구독합니다(참고: ‘EventMesh01’은 차량의 사용자 지정 등록 번호판입니다).
…/shipping/…/vehicle/EventMesh01/loadedOnBoard
…/shipping/…/vehicle/EventMesh01/unloaded
…/port/…/vehicle/EventMesh01/atCustoms
…/port/…/vehicle/EventMesh01/awaitingOnward
…/logistics/…/vehicle/EventMesh01/collected
…/logistics/…/vehicle/EventMesh01/deliveredToDealer
…/dealer/…/vehicle/EventMesh01/customerNotified
실시간 이벤트(세관에서 딜러에게 인도됨)가 대시보드에 제공되므로 비즈니스 리더는 원할 경우 고급 차량에 관한 비즈니스 상태를 한번에 파악할 수 있습니다.
한 걸음 더 나아가면 고급 자동차 제조업체는 고객이 다운로드할 수 있는 모바일 애플리케이션을 …/*/…/vehicle/EventMesh01/> 에 구독시켜 고객에게 실시간으로 배송 상태를 알릴 수 있습니다.
유통을 통한 공급망 조정
짐작하시겠지만, 수천 개의 서비스를 제공하는 글로벌 기업의 공급망 관리에는 상당한 조정이 필요합니다. 오류가 발생하면 하나의 서비스를 선택하여 나머지 서비스를 추적하고 조치를 취하는 방법이 있습니다. 이를 하나의 조정 지점인 오케스트레이션으로 간주하여, 문제 추적을 위한 단일 참조 지점이자, 단일 장애 및 병목 지점으로 삼을 수 있습니다.
이벤트 중심의 아키텍처에서 서비스는 들어오는 이벤트로 무엇을 하는지에 대한 이해에 기반하며, 추가 이벤트를 생성할 수도 있습니다. 이는 개별 서비스의 경우에는 각자의 일을 수행하는 ‘춤’이 되지만, 결합되면 암묵적으로 조정된 반응을 만들어 내므로, ‘안무(코리오그래피)’라는 용어로 정의됩니다. 제 동료 Jonathan Schabowsky가 이 주제에 관해 알찬 블로그 게시물을 작성했으니, ’마이크로서비스의 코리오그래피와 오케스트레이션의 차이: 코리오그래피의 이점’을 읽어 보시기를 권합니다.
이제 ‘오류 조건은 어떻게 되는지’ 궁금하실 겁니다. 오류도 하나의 이벤트이기 때문에 이러한 오류의 영향을 받는 서비스는 오류를 소비하고 그에 따라 적절히 대응하도록 설정됩니다. 이는 공급망 관리 사용 사례에서 특히 중요합니다. 공급망의 시작 부분에서 시작되는 다른 예시를 살펴보겠습니다.
한 농부가 고급 브랜드 아이스크림의 원료로 공급되는 바닐라콩을 재배하고 있습니다. 바닐라콩은 정해진 날짜에 수확될 예정이었지만, 수확 전날의 악천후로 인해 수확이 지연됩니다. 오케스트레이션을 사용하는 아이스크림 회사의 바닐라콩 수확 서비스는 다음을 수행해야 합니다.
- 바닐라콩 집하를 위한 도로 운송을 연기시킵니다.
- 선박을 평상시와 같이 입거시킬지, 아니면 항구 밖에서 대기시킬지 결정하여 바닐라콩 집하가 예정된 선박을 연기시킵니다.
- 항구 슬롯을 다시 예약합니다.
- 각 공장 위치에서 공장으로 이어지는 구간에 대해 동일한 작업을 수행해야 합니다.
- 우유와 기타 원료의 배송과 다운스트림 물류를 연기시킵니다.
- 공장 생산 슬롯이 업데이트되도록 ERP를 업데이트합니다.
움직이는 부분이 많습니다. 이 복잡한 서비스에서는 서비스 전반의 SLA 시간을 위반하는 지연이나 중단에 대한 걱정 없이 새로운 서비스를 변경하거나 추가하는 것을 어렵게 하는 수많은 상호작용이 이루어집니다.
이제 코리오그래피 접근법을 살펴보겠습니다. 수확 관리 애플리케이션이 ‘바닐라콩 지연’ 이벤트를 브로드캐스트합니다. 이것으로 할 일은 모두 끝났습니다. 다른 애플리케이션이 이벤트를 소비하고 그에 따라 다음과 같은 조치를 취할 것입니다.
- 도로 운송 관리 애플리케이션은 운송 트럭/로리 일정을 적절하게 재조정하고 ‘바닐라콩 컨테이너 지연’ 이벤트를 방출합니다.
- 선박 선적 관리 애플리케이션과 항만 관리 애플리케이션은 컨테이너 지연 이벤트를 수신하고 비즈니스 로직으로 일정에 미치는 영향을 결정합니다. 다음 선박과 항구 지연 이벤트가 생성됩니다.
- ERP를 업데이트하여 생산 일정을 재조정합니다.
이벤트에 대한 책임을 오케스트레이터 서비스에 의존하지 않고 이벤트 컨슈머 자체에 국한시킴으로써 문제를 보다 효율적으로 비결합하고 분리할 수 있습니다. 또한 성능 측면과 민첩성/복잡성 측면에서 오케스트레이터의 병목 현상을 제거합니다.
아직까지는 이해하고 조정하기 힘들어보일 수 있지만, 다음과 같이 정리해 보겠습니다. 이벤트 스트림을 관리, 시각화, 설계, 공유할 수 있는 도구가 있으며, 이를 이벤트 포털이라 합니다.
이벤트 포털을 통한 공급망 이벤트 관리
바닐라콩 예시에서 보았듯이, 지연을 해결하기 위한 최상의 방법을 찾는 것은 어려울 수 있습니다. 지연된 바닐라콩 컨테이너의 운송을 관리하는 방법에 대한 최적의 해결책을 이해하기 위해서는 포트와 컨테이너 둘 다에 관한 정보가 필요합니다..
이벤트 포털은 이벤트와 이벤트 중심 애플리케이션을 생성, 카탈로그화, 공유 및 관리할 수 있는 솔루션입니다. 이벤트 포털은 팀이 설계 검토를 진행할 수 있는 상호 연결된 네트워크 다이어그램으로 편리하게 시각화할 수 있습니다. 이렇게 하면 이벤트 및 이벤트 중심 애플리케이션을 구축할 때 설계가 런타임 실상황과 동기화되는지 여부를 쉽게 확인할 수 있으며 변경 사항이 모두 제어 및 추적됩니다.
이벤트 중심 디지털 트윈
여기서 디지털 트윈의 개념이 도움이 될 수 있습니다. 즉, 비즈니스 프로세스의 행위자들의 시뮬레이션 모델을 통해 시나리오를 구현하고 그 결과를 이해할 수 있습니다. 예를 들어, 농장에서 바닐라콩 컨테이너를 적재할 수 있도록 선박을 연기시키고 싶을 수 있습니다. 이러한 경우, 이미 선적된 다른 컨테이너의 지연으로 발생하는 비용은 어떻게 될까요?
현재 비즈니스 상태를 정확하게 반영하기 위해서는 시뮬레이션 모델(용기, 선박 등의 디지털 트윈)로 비즈니스 현황을 최신 상태로 유지해야 합니다. 짐을 많이 싣는 선박은 짐을 적게 싣는 선박보다 날씨에 의해 더 지연될 수 있습니다. 이는 디지털 트윈이 다수의 비즈니스 소스로부터 상태 업데이트를 받아들여야 한다는 것을 의미합니다.
관련된 오케스트레이션 프로세스를 모두 업데이트하여 디지털 트윈을 업데이트하시겠습니까? 아마 아니실 겁니다. 이벤트 중심 디지털 트윈을 생성하면 이벤트 메시를 사용하여 모든 관련 이벤트를 구독하고 트윈을 개발하면서 모델링을 점차 구체화할 수 있습니다.
결론: 공급망 관리 디지털 전환에 EDA가 중요한 이유
이벤트 중심 아키텍처에 귀사의 공급망 관리 인프라를 개선할 만한 가치가 있다는 점을 효과적으로 보여 드렸기를 바랍니다. 그러면 요약해 보겠습니다. 다음은 공급망 관리에 적용되는•이벤트 중심 아키텍처의 주요 원리입니다.
- 게시/구독 메시징 패턴을 활용합니다.
- 이벤트 브로커를 사용하여 올바른 서비스 및 애플리케이션으로 올바른 이벤트를 가져옵니다.
- 이벤트 메시를 생성하여 비결합 애플리케이션, 클라우드 서비스, 장치 간에 이벤트를 분배합니다.
- 이벤트가 한 번만 전송되고 애플리케이션이 필요한 항목만 수신하도록 토픽을 사용합니다.
- 오케스트레이션을 통해 단일 장애 원인을 도입하는 대신, 이벤트 스트림으로 서비스를 코리오그래피합니다.
- 시각화, 설계 및 발견을 위한 이벤트 포털로 이벤트 중심 아키텍처를 관리합니다.
- 이벤트 중심 디지털 트윈을 생성하여 보다 나은 비즈니스 결정을 내리기 위한 시뮬레이션 모델을 개발합니다.
이런 과정을 수행해야 하는 이유는 무엇일까요?
- 대응력: 모든 일은 최대한 빨리 돌아가고 누구도 기다려주지 않습니다. 이러한 상황에서 이벤트 중심 아키텍처는 가능한 가장 빠른 응답 시간을 제공합니다.
- 확장성: 다운스트림에서 발생하는 작업을 고려할 필요없이 서비스 인스턴스를 확장할 수 있습니다. 토픽 라우팅 및 필터링으로 명령 쿼리로 책임을 분리하고 빠르고 쉽게 서비스를 나눌 수 있습니다.
- 민첩성: 다른 서비스를 추가하려는 경우 이벤트를 구독하여 자체적으로 새 이벤트를 생성할 수 있습니다. 기존 서비스는 이러한 상황이 발생했는지 알지 못하거나 구애받지 않으므로 영향을 받지 않습니다..
- 민첩성: 이벤트 메시를 사용하면 클라우드, 온프레미스, 다른 국가 등 어디든 원하는 위치에 서비스를 배포할 수 있습니다. 이벤트 메시는 가입자가 있는 위치를 학습하므로 다른 서비스에 통지할 필요 없이 서비스를 옮길 수 있습니다.
이러한 장점들은 특히 한 번의 변경으로 인해 연쇄적으로 큰 파장이 일어날 수 있는 공급망 관리 활용 사례에서 중요합니다. 실시간 정보에 대응하고 새로운 서비스와 분석을 빠르고 쉽게 추가할 수 있으므로 공급망 운영 및 관리가 대폭 향상됩니다.
자세한 내용을 원하시면 저의 기술 웨비나에서 확인하시기 바랍니다.
공급망 관리의 디지털 전환에 대해 자세히 알아보고 이벤트 메시를 구축하여 효율성과 고객 경험을 개선하는 방법을 알아보십시오.