1.What is EDA?
EDA(Event-driven architecture)라는 용어에 대한 정의는 약간씩 다르지만, 공통적으로 거론되는 키워드들을 중심으로 정리하면 다음과 같이 말할 수 있다.
분산된 시스템 간에 이벤트를 생성, 발행하고 발행된 이벤트를 필요로하는 수신자에게 전송, 필요에 따라 처리하는 시스템 아키텍쳐
따라서 EDA를 이해하려면 이벤트 대한 정의, 시스템 구성, 각 구성 요소에 대한 이해가 필요하다.
- 이벤트란 무엇인가?
EDA에서의 이벤트란 시스템의 내,외부에서 발생한 '주목할 만한 상태의 변화(a significant change in state)'를 뜻한다. 자동차라는 컴포넌트를 예로 들면
1. 초기 상태가 '판매중(for sale)' 인 자동차가
2. 고객의 구매로 인하여
3. '판매됨(sold)' 상태로 바뀌게 되며
자동차의 상태 변화를 감지한 판매 시스템은 이 이벤트를 발행하고 이벤트 중개자에 의해 재무, 마케팅 등 판매 이벤트를 필요로 하는 시스템으로 자동 전송된다. 이렇게 전송된 이벤트는 각 시스템의 요구에 따라 적절한 처리 과정을 수행하게 된다.
- EDA의 구성 요소
EDA는 크게 3개의 구성 요소로 나누어 볼 수 있다.
-
Event generator : 시스템 내,외부의 상태 변화를 감지하여 표준화된 형식의 이벤트를 생성
-
Event channel : 이벤트를 필요로 하는 시스템까지 발송
-
Event processing engine : 수신한 이벤트를 식별, 적절한 처리를 함. 때에 따라 이벤트 처리의 결과로 또 다른 이벤트를 발생시킬 수 있음.
앞의 예에서 판매 시스템은 Event generator, 중개자는 Event channel, 재무, 마케팅 시스템은 Event processing engine에 해당한다.
- Event processing styles
수신한 이벤트를 처리하는 방법에는 세가지 종류가 있다.
각각의 이벤트가 직접적으로 수행해야할 action과 매핑되어 처리 됨. 실시간으로 작업의 흐름을 처리할 때 사용되며, 이벤트 처리 시간과 비용의 손실이 적다.
이벤트를 중요도에 따라 필터링하여 걸러진 이벤트만을 수신자에게 전송. 실시간으로 정보의 흐름을 처리할 때 사용되며, 기업에 적용될 경우 신속한 의사 결정을 가능케한다.(BAM)
일상적인 이벤트의 패턴을 감지하여 더 복잡한 이벤트의 발생을 추론하는 것. 예를 들어 '주식의 등락'이라는 일상적인 이벤트의 패턴을 감지하여 '투자 적기'라는 상위의 이벤트를 추론해 낼 수 있다.
2.EDA & SOA
얼핏 보면 두 아키텍쳐 간에 큰 차이가 없어 보이지만 둘 사이에는 근본적 차이가 존재한다.
-
SOA : 동기화된 요청/응답 방식
-
EDA : 비동기화된 배포/구독 방식
더 자세히 설명하자면 SOA의 경우 1.필요한 서비스를 찾고, 2서비스 제공자에게 서비스를 요청하고, 3 요청에 대한 응답을 받는 단계를 순차적으로 처리한다. 즉 서비스 요청자와 제공자가 사전에 '표준화 된 호출 규약'을 합의해야하며, 하나의 서비스가 다른 서비스의 상태에 의존성을 가지게 된다.
반면 EDA는 불특정 다수에게 이벤트를 발송하기만 하면 되며, 이벤트의 처리에 대한 내용은 발송자가 전혀 관여하지 않는다. 즉 발송자와 수신자가 서로에 대한 규약 없이 독립적으로 수행된다. 따라서 EDA는 보다 향상된 유연성(loosely coupled)을 제공 한다.
Outsourcing, M&A, 잦은 구조 조정 등으로 인해 기업의 구조가 자주 바뀌는 상황에서 IT 시스템을 구축하고자 한다면 EDA가 더 나은 선택일 수 있다. 그러나 EDA는 SOA의 대체제가 아니라 보충물의 역할을 한다는 견해가 지배적이다.
이런 경우 SOA의 사용이 적합하다. 반면 process chain 상에서의 수평적 관계에는 EDA의 사용이 적합하다.

이 글은 스프링노트에서 작성되었습니다.
댓글을 달아 주세요
안녕하세요.