Event Driven Architecture는 왜 필요할까?

졸작 미팅을 진행하는 도중에 종인님께서 이벤트 드리븐 디자인에 대해 언급하셨다.

다른 용어들은 그래도 어디선가 들어봤던 개념들이었는데 이 용어는 정말 생소했다. 종인님이 이 내용은 꼭 공부해보라고 하셔서 팀원들과 같이 공유해보고자 블로깅하게 되었따🙌

 

예전에도 AWS컨퍼런스를 들은 경험이 여러 번 있었는데 항상 도움을 많이 받았기 때문에 이번에도 AWS강연(AWS Summit Online Korea 2020)의 도움을 받아 학습하였다. (믿보AWS)

인용구문 안의 내용은 강연자님이 말씀하시는 내용을 그대로 적어놓은 것이니 일부 내용 중복이 있을 수 있다. 일단 따라 적고 내가 이해한대로 다시 적는 방식으로 진행하는데, 혹시나 내가 이해한 내용에 오류가 있을 수 있어 원본 내용도 같이 첨부하기 때문💁‍♀️

 

https://www.youtube.com/watch?v=BIm8E6XnXmQ 

---

 

이벤트 드리븐 아키텍처의 필요성은 동기식 처리와 비교할 때 확인할 수 있다.

동기식 처리와 이벤트 기반 처리를 비교하기 위해 이커머스를 예로 들어보자.

사용자가 구매 버튼을 누르는 순간, 시스템 내부에서는 연관된 여러 서비스들이 작업을 수행하게 된다. 

 

동기식 처리

동기적 처리

동기식 처리는 주문 서비스로부터 사용자의 주문이 들어오면,

주문 서비스가 물류 통합 서비스에게 주문 처리 요청을 보내고, 회신받고.

주문 서비스가 재고 관리 서비스로부터 재고 감소 메시지를 보내고, 회신받고.

주문 서비스가 계정 서비스에게 구매 이력 갱신 요청을 보내고, 회신받고. 하는 과정을 반복하게 된다.

 

 

동기식 처리의 문제점

근데 만약 물류 통합 서비스에 장애가 발생했다면? 연관된 주문서비스 또한 장애가 발생하게 된다.

(마이크로서비스로 구성된 시스템의 경우라고 생각한다면, 물류 통합 서비스가 호출한 하위 서비스들 모두 연결되어있기 때문에 장애가 발생할 수 밖에 없다. 아무튼 스노우볼이 구른다는 얘기)

 

갑자기 주문이 많이 들어와서 주문 서비스 확장이 필요한 경우라면, 물류 통합 서비스도 그에 맞게 확장이 필요하게 되고, 또한 새로운 관련 서비스가 추가되는 상황이라면 추가/변경 시 마다 어플리케이션을 수정해야하는 번거로움이 있을 수 있다.

 

 

 

 

이벤트 기반 처리

이벤트 기반 처리

 

이벤트 기반 처리는 동기식 처리의 문제점에 대해 해결할 수 있다. 

주문 서비스가 연관 서비스를 직접 호출하는 것이 아니라, 고가용성이 유지되는 서비스 스트림에 이벤트성 스트림을 전달한 후, 고객에게 빠르게 주문 완료 응답을 보낸다. 이벤트 처리를 희망하는 서비스는 해당 이벤트를 구독하고 전달받은 이벤트를 소비하게 된다. 이벤트를 생성한 서비스는 어떤 서비스가 이벤트를 소비할지에 대해 신경쓰지 않아도 된다는 장점을 가진다.

 

이벤트 기반 처리는 주문 서비스가 다른 서비스들을 신경쓰지 않아도 된다는 장점을 가진다.

주문 서비스가 연관서비스들을 직접 호출하는 것이 아니라, 서비스 스트림에 이벤트를 전달하고(이벤트 내용을 공지사항에 게시해놨다고 생각하면 이해하기 쉬울 것 같다.) 그저 주문에 관련된 자기 할 일 하러 가는 것이다. (다른 서비스가 일을 처리하든 말든 관심 없음) 그럼 그 이벤트를 처리해야하는 서비스에서 반응해서 선택적으로 동작한다. 이벤트를 소비한다는 표현과 같은 의미이다.

(내 머리 속에서는 알바모집글 올리면 구직자가 확인해서 사장한테 연락하는 그런 장면이 펼쳐지고 있음)

 

이 부분은 아래에 이벤트에 대한 개념을 먼저 숙지한 뒤에 다시 읽어보면 수월하게 이해가 될 것 같다!

 

서비스 간에는 독립적으로 작동하기 때문에 만약 새로운 서비스가 생기더라도 기존에 존재하는 서비스를 수정할 일이 없다.

 

---

이벤트

시스템의 비즈니스 도메인에서 중요한 의미를 가지는 상태 변경을 의미한다.

예를 들어, 이메일 서비스의 경우 새 이메일 수신이 이벤트가 되는 것!

 

이벤트는 '명령'이 아니라 '관찰'의 의미를 가진다.

 

• 명령 : 이벤트 생성 주체가 상대방에게 특정 동작을 하는 것을 기대함

(네트워크에서 TCP의 신뢰기반통신을 떠올리면 될 듯 하다.)

특정 상대한테 메시지를 전달하고 메시지에 대한 회신이 오는 것을 확인하는 경우를 말한다.

 

• 관찰 : 이벤트 생성 주체가 상대방에게 특정 동작을 하는 것을 기대하지 않거나, 관심이 없음

이벤트 생성자가 이벤트에 대한 정보를 게시하면 그에 관심이 있는 다른 이벤트 소비자들이 선택적으로 이벤트에 대해 동작하는 것을 말한다. 생성자는 누가 어떻게 반응하던 관심이 없는 상태인 것이다.

 

 

이벤트의 특성

• 발생한 사건을 표현하는 메시지 형식이다.
• 이벤트 자체에만으로도 중요한 내용에 대한 충분한 정보를 포함한다.
• 과거에 생성한 이벤트는 변경할 수 없음을 보장해야 한다. (이전 이벤트 수정X, 새로운 이벤트 발생O)
• 과거 시제의 동사로 표현된다. (ex. 새로운 주문이 생성되었다.)
• 이벤트 생성 시스템은 이벤트가 어떻게 처리되는지에 대해서는 관여하지 않는다.

 

---

 

강연에 대해 정리한 내용은 여기까지이다.

사실 이런거구나~하고 이해하고만 넘어갈 주제이기 때문에 더 깊게 구성요소가 어떻고, 이벤트 버스는 어떻고.. 이런 내용에 대해서는 추가하지 않도록 하겠다. 더 자세한 설명이 필요하다면 아래의 첨부 글에서 확인해보면 좋을 것 같다.

 

👇 EDA의 구성요소 및 동작 방식에 대해 자세히 설명한 블로그글

https://akasai.space/architecture/about_event_driven_architecture/

EDA(Event Driven Architecture)이란? | devlog.akasai

 

 

아래의 첨부글은 MSA에 더 집중한 EDM의 내용을 다루고 있는데, 위의 내용에 대해 확인했다면 첨부글 이해에 도움이 될 것 같다!

 

👇MSA가 적용된 시스템에서 사용할 수 있는 EDM 아키텍처에 관한 글 (확장된 개념)

https://www.samsungsds.com/kr/insights/msa_architecture_edm.html

당신의 MSA는 안녕하신가요? MSA를 보완하는 아키텍처: EDM(Event Driven MicroService)