개념의 혼돈
리액티브 프로그래밍을 접해보고, 아키텍쳐에 대해서 배우다보니 무슨무슨 드리븐에 대해서 엄청나게 많이 듣는다. 그 중에서도 헷갈리던 개념인 Message Driven, Event Driven에 대해서 정리되어 있는 글이 있길래 번역하여 이해해보고 어떻게 사용하는 게 올바른 것인지 이해해보자.
Reactive System?
일단, 배우게 된 리액티브 프로그래밍에 대해서 잠깐 봐보자.
Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation and location transparency.
리액티브 시스템은 비동기적인 메시지 패싱에 의존한다고 되어있다.
의존하는 이유는 세가지이다.
- loose coupling -> 느슨한 결합
- isolation -> 아이솔레이션
- location transparency -> 위치 투명성
이랬을 때의 장점으로는
부하관리가 가장 큰 것 같고 탄력성, message queue를 통한 모니터링 및 흐름 제어가 존재한다.
Message vs Event
Message는 특정한 주소로 data를 보내는 것이다.
Message Driven은 각각의 컴포넌트가 특정한 주소를 가지고, 다른 컴포넌트도 메세지를 보낼 수 있는 구조라고 한다.
이해하기로는 그냥 현재의 RESTful API들이다.
반면에 Event는
컴포넌트에서 데이터를 던진다. 아무나에게! 시간 괜찮은 사람이 처리해달라고.
Sending Messages vs Emitting Events
전통적인 프로그래밍 모델들은 컴포넌트 A가 컴포넌트 B의 메소드를 호출하는 식으로 동작하였다.
- 만약에 B가 현재 바쁘거나, 애초에 느렸다면 A는 기다려준다.
로맨티스트
Message Driven System에서는 컴포넌트 A는 메세지를 만들고 컴포넌트 B의 주소로 배달되어야한다.
- 컴포넌트 A는 메세지를 전송하고, control을 다시 받는다.(전통적인 방식과 다르게 컴포넌트 B에게 하라고 시킨 후에 A는 자기 할일을 하는 것이다)
- Message Driven에서의 컴포넌트는 주로 Queue를 가진다. 이러한 Queue는 들어오는 메세지들에 대해서 load spike(부하 지점)(제일 많이 신경써야하는 부분)가 되는 부분이기도 하다.
Event Driven에서 컴포넌트들은 이벤트를 expose하는 위치만을 알려준다.
- 컴포넌트 A는 이벤트를 던지지만(emit), 누가 이 이벤트를 처리하는지는 알지 못한다.
- 위치는 ordered queue를 사용한다.
- consumer(일을 처리할 사람들)들은 이미 소비된 이벤트와 보류중인 이벤트를 추적할 수 있도록 Queue를 인덱싱하는 경우도 있다.
Difference?
그래서 둘의 차이는 뭘까?
Message Driven은 누가 메세지를 받아서 처리하는지 정해져(fixed) 있다.
(아는 사람 -> 아는 사람)
Event Driven은 일단 이벤트를 던져버린다. '누군가 처리해주겠지'라는 생각으로. 그리고 consumer들은 이를 받아서 처리한다.
(아는 사람 -> 모르는 사람)
잘못이해하지마!
하지만 여전히 혼동하기 쉬운 개념들이다. 마지막으로 정리를 해본다면,
Message Driven -> 시스템의 building block을 나타내고
Event Driven -> 시스템의 상위 수준 속성(higher level property)(==architecture)
따라서, Message Driven tool들을 사용하여 Event Driven System을 만들 수 있다는 뜻이다. == kafka를 사용하여 Event Driven을 만든다고 생각한다.
내가 이해한 것
Message Driven은 도구이고, Event Driven은 구조이다.
-> 이벤트 드리븐 아키텍쳐에서 채택할 수 있는 도구 중 하나가 메세지 드리븐이라고 생각하게 되었다. 다른 도구는 무엇이 있는데? 라고한다면 아직... 모르겠다. 어떤 게 더 있는지는 좀 더 찾아봐야할 것 같다.
