[MSA] Event Driven Architecture

정의

시스템 컴포넌트 간의 통신을 위해 이벤트를 생성하고 감지하는 아키텍처

• 이벤트: 무언가 발생한 것
  • 시스템의 상태 변화
  • Event Notification으로 전달
  • 명령과 관련된 데이터를 포함할 수도 있고, 단지 무언가 발생했다는 알림일수도 있다
  • 불변(immutable) 이다
    • ⇒ Event Sourcing의 원천이 된다
• 명령(Command): 다른 시스템에게 응답을 요청하는 것

Event Sourcing

데이터 변경 이벤트를 저장하고 시스템의 상태를 재구축하는 방식

• 데이터 변경 히스토리 추적
• 데이터 일관성 보장

구성 요소

• Producer: 이벤트 생성
• Broker: 이벤트를 적절한 Consumer로 라우팅
• Consumer: 이벤트를 수신하고 처리

이벤트 기반 아키텍처나 메세지 기반 아키텍처에서는 Publisher-Subscriber 모델로 부르기도 한다

장점

• 컴포넌트 간의 결합을 낮출 수 있다
  • 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

https://en.wikipedia.org/wiki/Event-driven_architecture

https://en.wikipedia.org/wiki/Loose_coupling

1. 구체적인 구현이 아닌 추상화된 인터페이스에 의존한다는 것 [본문으로]
2. 1. 끊어질 수 있는 관계. 한 컴포넌트의 변경이 다른 컴포넌트의 존재 또는 성능에 거의 영향을 미치지 않는 경우. 2. 각 컴포넌트가 다른 컴포넌트에 대한 지식이 없거나 활용하지 않는 경우 [본문으로]