Search

EDA(Event Driven Architecture)

EDA의 개념과 범위

Event Driven Architecture

서비스 간 이벤트를 이용해 비동기로 통신하는 구조

Martin Fowler 가 정의 한 Event-Driven

Event Notification : 이벤트 알림

어떤 변경 사항이 일어났음을 알리는 트리거 역할
이벤트에 포함되는 데이터는 id 등의 최소 정보가 포함 된다.

Event-Carried State Transfer : 이벤트 기반 상태 전송

이벤트에 변경 사항의 상세 내용을 포함
수신자는 해당 데이터의 사본을 유지 할 수 있음
customer 에 대한 상세 정보가 같이 오기 때문에 정보를 따로 요청하지 않고도 빠르게 서빙이 가능하다는 장점이 있다.

Event-Sourcing : 이벤트 소싱

데이터의 최종 상태 대신 모든 변경 내역을 이벤트로 저장 하는 방식
Event Store for Account는 모든 이벤트를 저장한다. 이 방식은 감사와 상태 변화 추적을 용이하게 하며, 특정 시점으로의 롤백을 가능케 한다. 최신 데이터 조회 시 리플레이가 수행되지만, 성능 최적화를 위해 주기적으로 최신 상태의 스냅샷이 저장된다. 단, 이 스냅샷은 원본 데이터가 아닌 파생 데이터로 간주된다.
운영 메커니즘: 스냅샷이 매시간 생성된다고 가정할 때, 데이터 조회 요청 시 시스템은 최신 스냅샷을 참조한다. 그 후, 해당 스냅샷 이후 발생한 이벤트만을 Event Store에서 추출하여 최종 상태를 산출한다. 이로써 전체 이벤트 이력을 처리하는 대신 효율적으로 최신 상태를 재구성할 수 있다.

CQRS : Command and Qurey Responsibility Segregation

데이터의 쓰기와 읽기가 분리되어 다른 모델, 다른 서비스를 통하게 됨
읽기 쓰기 성능이 다르기 때문에 분리하여 다른 요구사항에 적응할 수 있게 하는 패턴
이벤트 소싱을 사용하면 데이터의 쓰기와 읽기가 자연스럽게 분리된다. 읽기 작업은 스냅샷 DB와 이벤트 스토어의 계산된 결과를 활용한다.
이러한 특성으로 인해 이벤트 소싱은 CQRS(Command Query Responsibility Segregation) 패턴과 잘 어울린다. CQRS의 핵심은 명령(쓰기)과 쿼리(읽기) 서비스를 분리하는 것이다. CQRS의 주요 특징은 다음과 같다:
•
내부적으로 서로 다른 모델을 사용한다.
•
시스템의 구성요소가 명확히 분리된다.
•
클라이언트는 데이터 접근 시 명령과 쿼리를 구분하여 사용한다.
이 패턴의 주요 장점은 쿼리 서비스의 성능을 독립적으로 최적화할 수 있다는 점이다.
그러나 CQRS는 시스템의 복잡도를 증가시키므로, 필요한 경우에만 선택적으로 적용하는 것이 바람직하다.

EDA 의 장단점

장점

느슨한 결합(유연성)

확장성

실시간 처리

분산 아키텍처(MSA)

단점

복잡성

디버깅 어려움

일관성 관리

이벤트 소실 및 중복

EDA 사용 시나리오

이커머스 MSA 상태계
IoT 센서로 부터 데이터 스트림을 실시간으로 처리

EDA 구성 요소

이벤트 생산자

•
이벤트를 발행하는 주체
•
특정 이벤트의 발생 또는 상태 변경을 발행
•
소비자를 특정 하지 않는다
◦
특정 사건의 발생을 이벤트 브로커를 통해 알릴 때, 어떤 소비자가 이 데이터를 소비할지 알 필요가 없다. 이는 느슨한 결합의 핵심 개념이다. 이러한 특성은 API 서비스와 대조적이다.

이벤트 소비자

•
이벤트를 소비하는 주체
•
특정 이벤트에 다수의 소비자가 존재할 수 있다.
•
한 이벤트에 대해 여러 소비자가 작업을 시작하는 병렬 처리 가능
◦
이를 "fan-out"이라고 한다. API 호출의 경우, A 서비스가 다수의 처리를 해야 할 때 여러 다른 서비스를 호출해야 하므로 A 서비스에 부하가 발생한다.

이벤트 브로커

•
이벤트 생산자, 소비자를 연결하는 핵심 요소
•
일종의 큐(Queue) 역할
•
일정 기간 이벤트를 저장할 수 있는 기능 필요
•
단일 장애 포인트가 될 수 있음
•
다수의 연결(생산자, 소비자)을 처리할 수 있는 확장성 필요
•
오류 처리(Dead Letter Queue) 기능 필요
◦
Dead Letter Queue : 제대로 처리되지 않은 이벤트를 보관해준다
▪
특정 이벤트 처리 중 오류가 발생해 서비스가 중단되면, 해당 이벤트의 실행 여부를 확인할 수 없다. 이 경우, 이벤트 처리 상태를 표시하는 메커니즘이 필요하다. 그러나 지속적으로 오류가 발생할 수 있으므로, 이러한 문제가 있는 이벤트는 별도로 보관한다.