MSA/Event Driven Architecture
[MSA] Event Driven Architecture
개발자 이우진
2024. 4. 21. 02:06
정의
시스템 컴포넌트 간의 통신을 위해 이벤트를 생성하고 감지하는 아키텍처
- 이벤트: 무언가 발생한 것
- 시스템의 상태 변화
- Event Notification으로 전달
- 명령과 관련된 데이터를 포함할 수도 있고, 단지 무언가 발생했다는 알림일수도 있다
- 불변(immutable) 이다
- ⇒ Event Sourcing의 원천이 된다
- 명령(Command): 다른 시스템에게 응답을 요청하는 것
Event Sourcing
데이터 변경 이벤트를 저장하고 시스템의 상태를 재구축하는 방식
- 데이터 변경 히스토리 추적
- 데이터 일관성 보장
구성 요소
- Producer: 이벤트 생성
- Broker: 이벤트를 적절한 Consumer로 라우팅
- Consumer: 이벤트를 수신하고 처리
이벤트 기반 아키텍처나 메세지 기반 아키텍처에서는 Publisher-Subscriber 모델로 부르기도 한다
장점
- 컴포넌트 간의 결합을 낮출 수 있다
- vs 직접 호출
- 다른 서비스를 호출하기 위해서 그 서비스의 존재를 알아야 한다
- ⇒ 의존성 발생
- vs 직접 호출
- 의존성 역전 (Dependency Inverision)1
- 다른 서비스를 아는 대신 이벤트의 생성과 소비에 대해서만 알면 됨
- ⇒ 다른 서비스 대신 이벤트라는 인터페이스에 의존
- 메세지 형식을 유지하면 구체적인 서비스는 교체할 수 있다
- 다른 서비스를 아는 대신 이벤트의 생성과 소비에 대해서만 알면 됨
- 병렬 처리와 확장성이 뛰어나다
- 불변이기 때문에 다른 시스템에서 병렬적으로 처리될 수 있다
- 하나의 이벤트를 여러 서비스에서 소비 가능
- 지속성이 있어 이벤트를 나중에 처리할 수 있다
- 나중에 정보 검색 가능
- 비동기 처리 가능
- 단일 장애 지점이 없어 견고하다
- Consumer가 다운되어 이벤트를 읽지 못해도 Broker가 이벤트를 가지고 있다
단점
- 성능 저하
- 다른 서비스를 직접 호출하는 대신 메세지를 전달하는 Broker가 있어서 성능 저하가 발생
- 대가로 확장성 증가
- 최종 일관성
- 이벤트 전송과 수신 사이에 지연(delay) 발생
- 동일한 이벤트를 여러 서비스가 소비하면 각각 다른 시간에 읽을 수 있음
- 서비스 간 동기화 문제 발생
- 복잡성 증가
- 무슨 일이 발생했는지, 언제 발생했는지, 어떤 서비스를 호출했는 지 추적하기 어렵다
어떤 경우에 유용한가?
- 확장성이 성능보다 중요할 때
- 데이터 복제가 필요할 때
- 이벤트를 공통 소스로 각 서비스에서 정보를 복사할 수 있음
- 병렬 처리가 필요할 때
- 느슨한 결합2이 중요하고 다른 시스템 간 통신할 때
- 이벤트 형식만 맞추면 전체 시스템이 작동한다
활용 사례
- Saga Pattern
- Redis pub/sub
- 브라우저 이벤트
- Redux (React)
- React - React Native 간 메세지
출처
https://www.youtube.com/watch?v=DQ5Cbt8DQbM