[Architecture] Event-Driven Archiecture 개요

이벤트 기반 아키텍처(EDA, Event-Driven Architecture)

서론

본 문서는 이벤트 기반 비동기 아키텍처에 대한 개념을 쉽게 이해할 수 있도록 서술했으며, 개인적인 견해가 포함되어 있습니다. 또한 구체적인 구현 방법론에 대해선 자세히 다루지 않습니다.

비동기 처리 방식의 분류에 관해

이벤트 기반 비동기 처리의 분류는 핵심 데이터 형태를 Message로 정의하느냐, Event로 정의하느냐가 그 기준이라고 생각한다.

현재는 이러한 분류에 따른 미들웨어의 역할 경계가 희미해졌다(Redis로 Stream을, RabbitMQ로 Pub/Sub를, Kafka로 Message Queue를 구현 가능). 또한 Message라는 형태의 데이터 또한 Event의 발생으로부터 발생되기 때문에 Message로 처리하든, 이벤트 자체를 기록하든 모두 이벤트 기반 비동기 처리 방식의 일종으로 볼 수 있다고 개인적으로 생각한다.

따라서 Broker 미들웨어의 동작 방식에 따라 Message Broker를 Hub, Event Broker를 Log 관점으로 분류해 정의하고, 각 분류에 적합한 패턴을 소개하는 것이 이벤트 기반 비동기 처리의 원활한 이해를 돕는다고 생각한다.

기존 동기 방식

이벤트 기반 아키텍처를 설명하기에 앞서, 기존의 동기 처리 방식에 대해 간략히 알아보자.

방식

• 연결형
  

  

  연결형 특성

  • Request → Response 과정이 끊기지 않는 연결형

한계

• 강한 결합
  • 메세지 형태(DTO, Parameter 등)가 수신자의 인터페이스와 결합되어 있어 유지보수 비용이 크고, 수신자와 호출자 간 결함이 전파될 가능성 내재
  • Request와 Response 사이에 단 하나의 결함이 프로세스 전체에 영향
• Blocking
  • 무거운 작업이나 외부 API 연동 시 서버의 Thread pool이 대기 상태로 Block 되어 고갈될 위험
• 트래픽 부하
  • 대규모 트래픽 발생 시 하부 인프라(DB, CPU 등)의 부하를 제어하기 어려움

이벤트 기반 아키텍처(EDA)

이벤트 기반 아키텍처

이벤트 기반 아키텍처는 기본적으로 비동기 방식으로 구성된다.
따라서 Producer는 메세지를 전달한 이후의 상황은 전혀 알 필요가 없기 때문에 장애 전파가 차단되어 서로 간 격리된다. (Decoupling)
또한 Producer와 Consumer는 메시지 인터페이스를 통해 느슨하게 결합된다.

주요 컴포넌트

이벤트 기반 아키텍처의 주요한 컴포넌트는 아래와 같다.

• Producer
  • 이벤트 발생에 따라 메세지를 생성, 발송하는 주체
  • 필요에 따라 At-least-once 전달을 목표로 재시도 전략을 적용할 수 있음
• Broker
  • 메세지를 저장, 관리, 전달하는 주체
  • 메세지를 적절히 전달할 수 있도록 규칙 기반 배포 수행 (Routing)
  • 필요에 따라 대규모 트래픽에 대한 완충지대 역할을 할 수 있음 (Buffer)
• Consumer
  • Broker로부터 메세지 소비 로직을 처리하는 주체
  • 메세지를 중복으로 소비하더라도 동일한 결과를 보장해야 함 (멱등성)
    • ex) 중복 결제 방지

역할에 따른 Broker 분류

Broker는 이벤트를 처리하는 방식에 따라 분류할 수 있다.
이벤트 발생 시 데이터를(Message) 소비자에게 전달한다면 Message Broker, 이벤트 자체를 물리적으로 기록(Log)하고 소비자가 직접 참조한다면 Event Broker 방식이라고 볼 수 있다.
단, Event Broker 미들웨어로도 Message Broker 패턴을 구현할 수 있고, 그 반대도 가능할 수 있다. (예로, Kafka가 아닌 Redis로도 Event Stream을 구현할 수 있다!)

• Message Broker (Hub)
  • 이벤트 발생 시 발행되는 메시지(데이터)를 중간에서 라우팅 및 전달
  • 일반적으로 메시지는 소비가 완료되면 더 이상 재사용되지 않고 제거
  • ex) RabbitMQ, Redis Pub/Sub, AWS SQS
• Event Broker (Log)
  • 이벤트 자체를 물리적 공간에 시간 순으로 적재하여 영속화
  • 소비자의 처리 여부와 관계없이 지정된 기간 동안 데이터 보존 및 재활용 가능 (비휘발성)
  • ex) Apache Kafka, AWS Kinesis

Message Broker 패턴

Message Broker 패턴에 적합한 미들웨어는 On-premise 환경에선 Redis Pub/Sub, Redis Streams, RabbitMQ, Apache Active MQ 등이 있다.
Cloud 환경에선 AWS SQS/SNS, GCP Pub/Sub 등이 있다.

미들웨어는 각각 장점이 뚜렷하게 존재하는데, 예로 Redis는 초고속/초경량 인프라이며, RabbitMQ는 정교한 Exchange와 유연한 Routing과 같은 특색이 있기 때문에 프로젝트에 적절한 미들웨어를 선택하는 것이 좋다.

Pub/Sub

Pub/Sub 패턴

• 특성
  • Publisher(발행자)가 특정 Topic에 메세지를 전달 → Broker는 해당 Topic을 구독하고 있는 모든 Subscriber(구독자)에게 메세지를 전달(Broad Casting)
• Redis
  • 구독자의 존재 여부, 메세지 정상 소비 여부에 관계 없이 네트워크로 전달 후 즉시 삭제
  • Queue 형태의 버퍼링을 사용하지 않기 때문에 리소스 효율과 성능 극대화
  • 전달 즉시 휘발되기 때문에 메세지 유실 가능성 존재
• RabbitMQ
  • 모든 Subscriber에 대해 독자적인 Queue가 할당
  • Fanout Exchange를 통해 메세지 Broad Casting
  • Ack를 통해 메세지가 소비되어야 삭제되기 때문에 메세지 유실로부터 안전

Message Queue

Message Queue 패턴

• 특성
  • Queue에 적재된 메세지는 경쟁적 소비자 패턴을 통해 하나의 Consumer만 소비
  • Consumer의 우선순위는 Round-Robin, 가용 상태, 커스텀 우선순위, 최대 적재 제한 등 복합적으로 결정됨
• 1:1 (Buffering - 완급 조절)
  

  

  1:1

  • 하나의 이벤트 흐름(Queue)에 대해 버퍼링을 적용해 Decoupling 및 부하 완화
  • ex) 무거운 백그라운드 작업(파일 변환 등)의 비동기 처리 및 역할 이관
• 1:N (Load Balancing - 분산 처리)
  

  

  1:N

  • 하나의 이벤트 흐름을 경쟁적 소비자(Competing Consumers) 패턴으로 분산 처리해 HA(고가용성)를 구성하여 안정성 및 확장성 보장
  • ex 1) 특정 Consumer에 문제 발생 시 다른 Consumer로 대체
  • ex 2) Consumer에 대한 부하 분산
• N:1 (Aggregation - 데이터 집약)
  

  

  N:1

  • N개의 Producer에서 발생한 이벤트들을 동일한 메세지 포맷으로 통합해 하나의 Queue로 집약
  • ex) 서비스 전체의 각 이벤트에 대한 로그 처리

Event Broker 패턴

Event Broker

Event Broker 방식의 미들웨어는 Message의 전달이 아닌 이벤트 자체의 시간 순 기록(Log)에 집중하는 방식이다. Broker가 메세지를 Push 하는 것이 아닌, Consumer가 직접 이벤트 기록을 Pull 해서 적절히 소비하기 때문에 Event Broker는 이벤트의 저장과 재생산(Replaying)에 더 초점을 둔다.

가장 대표적인 미들웨어로 Apache Kafka가 있다. Event Broker 분류의 미들웨어이지만 Message Broker 형태로도 활용할 수도 있다.