이벤트 기반 아키텍처(Event Driven Architecture)란?

참고 : https://cloud.google.com/eventarc/docs/event-driven-architectures

이벤트 기반 아키텍처란?

이벤트에 대한 상태 변화에 반응하는 소프트웨어 아키텍처를 의미합니다.

 

 

이벤트란?

상태의 변경. 즉, 데이터의 변경, 생성, 삭제를 통해 발생하는 서비스의 의미 있는 변화를 뜻합니다.

 

 

이벤트 기반 아키텍처는 어떻게 작동할까?

참고 : https://cloud.google.com/eventarc/docs/event-driven-architectures

이벤트의 감지에서 시작하여 이벤트 구조의 형태로 기술적 표현의 생성으로 진행하고 비로 끝나는 네 가지 논리적 계층으로 나눠져서 데이터를 처리합니다.

 

• 이벤트 프로듀서 (Publisher, Producer, Creater)
  • 이벤트를 감지하고 감지한 이벤트를 메시지로 나타내는 역할을 합니다.
  • 예시) 이벤트 프로듀서는 고객이 전자상거래 사이트에서 주문을 하면 "Check Out" 이벤트가 발생하여 이벤트 채널에 전달됩니다.

• 이벤트 채널 (Bus, broker, Router)
  
  • 이벤트 프로듀서가 생성한 원래 이벤트에 대한 응답을 실행하고 이 응답을 다운스트림으로 적절한 소비자에게 보내는 역할을 합니다.
  • 이벤트 처리 엔진은 거의 실시간으로 이벤트를 처리해야 하기 때문에 이벤트 채널은 비동기식으로 읽습니다.
  • 이벤트는 큐에 저장되어 나중에 이벤트 처리 엔진에서 처리되기를 기다립니다.
  • 예시) "Check Out" 유형의 이벤트가 발생하기를 듣거나 기다리는 이벤트 소비자가 이벤트를 사용할 수 있도록 합니다.

• 이벤트 처리 엔진 (Consumer, Processor, Subscriber)
  
  • 수신한 이벤트를 식별한 다음 이벤트에 맞는 반응을 실행하는 논리적 계층입니다.
  • 예시) 들어오는 이벤트가 "Check Out"인 경우 "제품 ID 주문" 및 "직원에게 알림"과 같은 비즈니스 로직 수행을 합니다.

• 다운스트림 이벤트 기반 활동
  • 이벤트의 결과가 표시되는 논리적 계층입니다.
  • 싱크(이벤트 처리 엔진)가 제공하는 자동화 수준에 따라 다운스트림 활동이 필요하지 않을 수 있습니다.
  • 예시) 이메일이 누군가에게 전송되고 애플리케이션이 화면에 일종의 경고를 표시할 수 있습니다.

 

 

특징

• 입력 이벤트 처리에 대한 결정적 응답 시간이 없습니다.
• 매우 느슨하게 결합되고 잘 분산되어 있습니다.
• 이벤트 발생으로 데이터와 데이터가 느슨하게 연결되기에(coupling) 고정된 구조가 없으며, 구조 자체가 없을 때도 있습니다.
• 클라이언트는 더 이상 업데이트나 상태 변경을 계속 요청할 필요가 없습니다.

 

 

장점

• 시스템 간 느슨한 결합도를 제공
  • 약속된 Message를 통해 통신하기 때문에 다른 시스템의 정보를 알 필요가 없으므로 시스템 간 의존성이 배제되어 새 시스템의 변경과 추가를 쉽게 할 수 있습니다.

• 최적화된 네트워크 리소스 사용
  • 내보내기 기반 메시징을 쉽게 수행할 수 있으며, 클라이언트가 원격 서비스에 상태 변경을 지속적으로 폴링 하지 않고도 업데이트를 수신할 수 있습니다.
  • 폴링이 줄어들면 네트워크 I/O가 줄어들고 비용이 절감됩니다.

• 비동기성 및 복원력
  • 이벤트가 비동기식으로 생성되며 응답을 기다리지 않고 이벤트가 발생할 때 실행할 수 있습니다.
  • 구성요소가 느슨하게 결합된 경우 한 서비스가 실패해도 다른 서비스는 영향을 받지 않습니다.
  • 필요한 경우 수신 서비스가 실패 지점부터 다시 시작하거나 이전 이벤트를 재생할 수 있도록 이벤트를 로깅할 수 있습니다.

 

 

단점

• 리소스 증가
  • 많은 시스템의 리소스(메모리, CPU, 대역폭 등)를 소비하므로 하위 서비스의 유지 관리가 더 소모됩니다.
• Broker Dependency
  • 시스템 간 의존도는 낮아지지만 메시지 중개인에 대한 의존성이 발생합니다.
  • 만약 메시지 중개인의 장애가 발생하면 큰 장애로 확산될 가능성이 있습니다.
• 복잡성 증가
  • 늘어난 관리 포인트, 리소스, 통신 방식 등 고려해야 할 부분들이 많기에 구현 난이도가 높습니다.

• API 분석에서 모호성
  • REST API 호출은 API 엔드포인트에 대한 요청 적중 수를 기반으로 측정될 수 있습니다.
  • 이 메트릭은 이벤트 기반 아키텍처(예: 푸시되는 이벤트 수 파악)에 쉽게 매핑되지 않습니다.
  • API 효율성과 고정성을 측정하는 기존 방식은 이벤트 기반 API의 경우 더 이상 적용할 수 없습니다.

• 비동기 처리로 제한됩니다. 
  • EDA는 디커플링 시스템을 위한 강력한 패턴이지만 그 적용은 이벤트의 비동기 처리로 제한됩니다. 
  • EDA는 개시자가 계속하기 전에 응답을 기다려야 하는 요청-응답 상호작용을 대신하여 잘 작동하지 않습니다.

 

 

언제 사용하면 좋을까?

• 성능보다 확장성이 중요할 경우
• 병렬로 동시에 실행해야 하는 여러 서비스가 있을 경우
• 여러 하위 시스템이 동일한 이벤트를 처리해야 하는 경우.
• 최소 시간 지연의 실시간 처리를 원할 경우
• 패턴 일치 또는 일정 기간의 집계와 같은 복합 이벤트 처리할 경우

 

 

마무리

오늘은 이벤트 기반 아키텍처를 공부한 내용을 정리해봤습니다.

공부를 해보니 기존 REST 서비스보다 난이도가 높아져서 여러 가지 고민과 고통을 받을 거 같다고 생각이 드네요. 하지만 그럼에도 불구하고 구현할 가치가 있다고 생각이 들었습니다. 왜냐면 이 글에는 쓰진 않았지만 이 기술이 나온 이유가 사용자의 요구 때문에 나온 아키텍처이기 때문입니다. 개인적으로 사용자가 쓰기 좋은 서비스를 만들고 싶다고 생각했기 에 그런 생각이 들지 않았나? 생각되네요.

아직 부족하거나 틀린 부분이 있을 수도 있으니 주의하시면 좋을 거 같습니다.

이번 포스팅은 마무리하면서 다음 포스팅에서 뵙겠습니다.

 

 

 

참고

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

https://cloud.google.com/eventarc/docs/event-driven-architectures