MSA에서 이벤트 드리븐 아키텍처를 언제 도입해야 할까

이벤트 기반 시스템이 필요한 순간

마이크로서비스 아키텍처(MSA)를 설계하다 보면 자연스럽게 다음 질문이 등장한다.

서비스 간 통신을 REST로 할 것인가, 메시지 큐로 할 것인가?

많은 시스템이 처음에는 REST 기반 통신으로 시작한다.
REST는 단순하고 이해하기 쉽기 때문이다.

하지만 서비스가 늘어나고 기능이 복잡해지면
다음과 같은 문제가 나타나기 시작한다.

• 서비스 간 호출 체인 증가
• 장애 전파
• 응답 지연 증가
• 시스템 결합도 상승

이때 등장하는 아키텍처 패턴이 바로
이벤트 드리븐 아키텍처(Event Driven Architecture, EDA)다.

---

이벤트 드리븐 아키텍처란 무엇인가

이벤트 드리븐 아키텍처는
서비스 간 통신을 이벤트 기반으로 처리하는 구조다.

기본 흐름은 다음과 같다.

 

Service A
→ 이벤트 발생
→ Message Broker
→ Service B / Service C / Service D 처리

 

즉 하나의 서비스가 상태 변화를 이벤트로 발행하고
다른 서비스들이 이를 구독해 처리한다.

예를 들어 주문 시스템을 생각해 보자.

 

Order Service
→ OrderCreated 이벤트 발행

Inventory Service
→ 재고 차감

Notification Service
→ 알림 발송

Analytics Service
→ 통계 기록

 

서비스 간 직접 호출이 아니라
이벤트를 통해 연결되는 구조다.

---

이벤트 드리븐 아키텍처가 필요한 순간

EDA는 처음부터 도입하는 경우보다
시스템이 성장하면서 필요해지는 경우가 많다.

다음 상황이 나타나면 이벤트 기반 구조를 고려할 수 있다.

 

1. 서비스 간 의존성이 높아질 때

REST 기반 통신이 많아지면
서비스 간 호출 체인이 길어질 수 있다.

예를 들어 주문 처리 과정에서 다음과 같은 흐름이 발생할 수 있다.

 

Order Service
→ Payment Service
→ Inventory Service
→ Notification Service

 

이 구조에서는 한 서비스가 실패하면
전체 요청이 실패할 수 있다.

이벤트 기반 구조에서는 다음처럼 바뀐다.

 

Order Service
→ OrderCreated 이벤트

Inventory Service 처리
Notification Service 처리
Analytics Service 처리

 

즉 서비스 간 직접 의존성이 줄어든다.

---

2. 후속 작업이 많아질 때

하나의 비즈니스 이벤트가
여러 서비스의 작업을 트리거하는 경우가 있다.

예를 들어 주문 완료 후 다음 작업이 이어질 수 있다.

• 재고 차감
• 배송 준비
• 알림 발송
• 통계 집계
• 추천 시스템 업데이트

REST 구조에서는 주문 서비스가
모든 작업을 호출해야 한다.

이벤트 구조에서는 다음처럼 단순해진다.

 

Order Service
→ OrderCompleted 이벤트 발행

 

각 서비스가 해당 이벤트를 처리한다.

---

3. 확장성이 필요한 경우

이벤트 기반 구조는 새로운 서비스를 추가하기 쉽다.

예를 들어 기존 시스템이 다음 이벤트를 발행하고 있다고 가정하자.

 

OrderCreated 이벤트

 

이 이벤트를 다음 서비스들이 사용한다.

• Inventory Service
• Notification Service

이때 새로운 서비스가 추가되어도
기존 시스템을 수정할 필요가 없다.

 

Recommendation Service
→ OrderCreated 이벤트 구독

 

이것이 이벤트 기반 아키텍처의 큰 장점이다.