Event Driven Architecture - 이벤트 드리븐 아키텍처

개발을 하면서 정말 많이 쓰이는 아키텍처 패턴이라고 생각하는 이벤트 드리븐 아키텍처에 대한 내용을 간단하게 요약해보고자 합니다. 해당 내용을 파고들면 정말 끝이없는... 내용인 것 같습니다. C언어로 프로덕션 코드를 구현할 때도 직접 Queue로 구현해서 사용하곤 했었는데, Spring이나 NestJS등 고수준 프레임워크에서는 애너테이션 등으로 아주 간편하게 제공하고 있습니다. 무튼 그런 내용들은 각설하고 아키텍처의 개념에 대해서만 요약 정리를 해보겠습니다.

---

용어 정의
ED ( Event-driven )

• 이벤트를 생성, 발생하고 발행된 이벤트를 필요로하는 수신자에게 전송되는 구조
• 이벤트를 수신한 수신자가 이벤트를 처리하는 형태의 구조
• programming, architecture와 연결되어 다양한 정의로 표현됨

EDP ( Event-driven pattern )

• 특정 행동이 자송으로/순서에 따라 한 흐름으로 처리되는 것이 아닌 일에 대한 반응으로 동작하는 디자인 패턴
• 개인적으로 센서로부터 유입되는 데이터 스트리밍 기반의 동작을 처리하면서 해당 패턴을 반영한 경험이 있음
• 하나의 어플리케이션을 개발하는 관점에서 사용하는 패턴

 

EDA ( Event-driven architecture )

• 분산된 시스템 간에 이벤트를 생성, 발생하고 처리하는 구조.
• 대게 Message Broker와 결합하여 시스템을 구성한다.
• 최근 거의 대부분의 회사들에서 kafka를 적극 도입해서 사용한다고 합니다.

EDA의 구성요소

• Event Generator : 시스템 내,외부의 상태 변화를 감지하여 표준화된 형식의 이벤트를 생성
• Event Channel : 이벤트를 필요로 하는 시스템까지 발송
• Event Processing Engine : 수신한 이벤트를 식별, 적절한 처리를 함. 때에 따라 이벤트 처리의 결과로 또 다른 이벤트를 발생시킬 수 있습니다.

대게 현업에서는 'Event Driven 구조를 적용했다.' '아키텍처를 적용했다.' 이렇게 표현들을 많이 하는것 같습니다. 사실 저도 C언어로 프로덕션 개발을 안했으면 EDP라는 개념은 사용하지 않았을 것 같습니다.

---

이벤트 처리 스타일

• Simple Event Processing : 각각의 이벤트가 직접적으로 수행해야할 action과 매핑되어 처리 된다. 실시간으로 작업의 흐름을 처리할 때 사용되며, 이벤트 처리 시간과 비용의 손실이 적다.
• Event Stream Processing : 이벤트를 중요도에 따라 필터링하여 걸러진 이벤트만을 수신자에게 전송. 실시간으로 정보의 흐름을 처리할 때
• Complex Event Processing : 일상적인 이벤트의 패턴을 감지하여 더 복잡한 이벤트의 발생을 추론하는 것

이벤트 소비 방식

이벤트를 소비하는 방식은 크게 두가지가 있을 것 같습니다.

• 서버가 클라이언트로 지속 송신하는 방법
• 클라이언트가 서버에 요청을하거나 조회를 해서 가져가는 방법
  • polling 방식 : 서버에 주기적으로 요청하는 것
  • pulling 방식 : 서버의 데이터를 클라이언트가 직접 주기적으로 가져가는 방법.

대게 서버가 클라이언트로 지속적으로 데이터를 던지는 구조는 잘 사용하지 않습니다. 비동기 처리 및 클라이언트가 처리할 상황에 대해서 크게 고려를 하지 않고 송신을 하기에 side effect가 많습니다.

 

보통은 클라이언트가 서버에 요청을하거나 조회를 해서 가져가는 방법을 많이 사용합니다.

 

 

---

아키텍처의 장단점

장점

• 디커플링 : 시스템간 느슨한 결합이 가능함으로 분산 시스템에서 시스템 간 의존성을 줄일 수 있습니다.
• 약속된 Event Message 기반으로 상호 정보를 교환하기에 타 시스템에 대해 알 필요가 없습니다.
• 서비스 단위로 시스템을 분리하기 때문에 확장성과 탄력성이 뛰어납니다.

단점

• 이벤트 브로커에 대한 의존성이 커지게 됩니다. 메시지 브로커의 장애 상황에 대응하는 부분이 필요합니다. 또한 브로커 서버를 잘 못띄우는 경우 데이터의 흐름이 무너집니다.
• 시스템 전체 Flow를 파악하기 어렵고 비동기 처리에 따른 디버깅이 어렵습니다.
• Transaction 단위로 격리되기 때문에 장애 시 retry/rollback에 대한 정책을 고려해야 합니다.

 

---

아키텍처 특징

위 내용을 기반으로 주요 특징을 정리하면 아래와 같습니다.

• 멀티캐스트 통신 : 한개의 publisher는 다양한 Consumer에게 이벤트 송신이 가능합니다.
• 실시간 전송 : 실시간으로 발생하는 이벤트에 대한 처리가 가능합니다.
• 비동기 통신 : 비동기로 통신이 이루어지므로 publisher는 처리 결과를 기다릴 필요 없이 원래 작업을 진행할 수 있습니다.
• 이벤트 온톨로지 : 이벤트들은 확실하게 구분된 특징을 가지고, 그에 상응하는 컨슈머에게 전달되는 특성이 있습니다.
• 자유로운 배포 : 느슨한 결합도를 제공하므로 브로커가 데이터만 잘 가지고 있으면, 프로듀서와 컨슈머 서비스의 배포가 자유로울 수 있습니다.