이벤트 기반 MSA 개요

요약 (5–7줄)

이벤트 기반 아키텍처(EDA)는 “비동기 이벤트 계약”을 중심으로 서비스 간 결합을 낮추는 마이크로서비스 운영 전략이다.
모놀리식 → MSA 전환에서 발생하는 핵심 문제는 배포·확장·데이터 일관성의 세 축으로 정리된다.
REST 중심 MSA는 요청-응답 결합으로 장애 전파와 확장 비용이 커진다.
EDA는 직접 호출을 제거하는 대신 이벤트 로그와 소비자 그룹으로 확장을 분산한다.
단, 순서·중복·관측성 문제는 EDA가 자동으로 해결하지 못한다.
이 강의의 핵심은 “완전 단절”이 아니라 “이벤트 계약으로 결합을 이동”시키는 사고 전환이다.

---

1. 정의

이벤트 기반 마이크로서비스 아키텍처(EDA)는 서비스가 상태 변화를 이벤트로 발행하고, 다른 서비스가 이를 비동기로 구독·처리하는 구조다. 핵심 자산은 API가 아니라 이벤트 계약(event contract)과 이벤트 로그다.

---

2. 직관

REST MSA는 “누가 누구를 호출한다”를 설계한다.
EDA는 “무슨 일이 일어났는가”만 기록한다.
호출 주체가 사라지고, 사건(event)만 남는다.

---

3. 작동 원리

1) 서비스는 자신의 트랜잭션 경계에서 상태 변경을 이벤트로 발행
2) 이벤트는 중앙 로그에 순차적으로 적재
3) 소비자 그룹 단위로 병렬 처리
4) 각 소비자는 자체 상태를 갱신하거나 추가 이벤트를 발행

이때 동기 응답은 없다. 성공/실패는 소비자 내부의 재시도·보상으로 해결한다.

---

4. 모놀리식 → MSA 전환 시 문제 분해

4.1 배포

• 모놀리식: 단일 배포 → 작은 변경도 전체 재배포
• REST MSA: 개별 배포 가능하나 호출 체인 영향
• EDA MSA: 발행자 배포가 소비자 배포를 막지 않음

4.2 확장

• 모놀리식: 수직 확장 중심
• REST MSA: 핫스팟 API가 병목
• EDA MSA: 소비자 수평 확장으로 부하 분산

4.3 데이터 일관성

• 모놀리식: 강한 일관성
• REST MSA: 분산 트랜잭션 복잡
• EDA MSA: 최종 일관성을 전제로 설계

---

5. REST 중심 MSA vs EDA 중심 MSA

관점	REST 중심	EDA 중심
결합도	호출 시점 결합	이벤트 계약 결합
장애 전파	연쇄 실패	소비자 단위 격리
확장 전략	API 스케일링	소비자 병렬 처리
운영 비용	트래픽 급증 시 비용 상승	로그 기반 선형 확장

---

6. “서비스가 직접 통신하지 않는다”의 정확한 의미

• ❌ 완전 단절 아님
• ✅ 이벤트 스키마에 대한 계약으로 결합

즉, 런타임 호출은 사라지지만 스키마 변경 리스크는 남는다.
EDA는 결합을 제거하는 것이 아니라 이동시킨다.

---

7. EDA가 해결하지 못하는 문제 3가지

7.1 순서 보장

• 동일 키 내 순서만 보장 가능
• 해결 원칙: 키 설계가 곧 비즈니스 규칙

7.2 중복 처리

• 최소 1회 전달이 기본
• 해결 원칙: 소비자는 멱등성 보장

7.3 관측성

• 호출 스택 부재
• 해결 원칙: 상관관계 ID + 이벤트 추적

---

8. 트레이드오프

• 장점: 확장성, 장애 격리, 느슨한 결합
• 비용: 디버깅 난이도, 운영 복잡성, 데이터 지연 허용

EDA는 “단순한 시스템을 복잡하게 만드는 도구”가 아니라
“이미 복잡한 시스템을 관리 가능하게 만드는 선택지”다.

---

9. 최소 예시

9.1 Toy 예시

• 주문 생성 → OrderCreated 이벤트 발행
• 이메일 서비스는 이벤트만 구독해 발송
• 주문 서비스는 이메일 실패를 모른다

9.2 실무형 예시

• 결제 완료 이벤트
• 정산/포인트/알림 서비스가 각자 소비
• 한 서비스 장애가 전체 결제 흐름을 멈추지 않음

---

10. 실무 함정 → 해결 패턴

함정	결과	해결 패턴
이벤트 남용	의미 불명	도메인 이벤트만 허용
스키마 무계획 변경	소비자 장애	버저닝
재시도 무한 루프	비용 폭증	DLQ + 제한 재시도

---

11. 오해/실수 3개 + 교정

1) “EDA면 동기 API 필요 없다” → 경계 API는 여전히 필요
2) “이벤트는 로그일 뿐” → 이벤트는 계약
3) “한 번 쓰면 끝” → 운영 비용이 본질

---

12. 판단 기준

사용해야 할 때

• 비동기 처리 비중이 높음
• 서비스 수가 빠르게 증가
• 장애 격리가 핵심 가치

쓰지 말아야 할 때

• 강한 즉시 일관성 필수
• 소규모 팀·단순 도메인
• 운영 인력이 부족

---

13. 재학습 체크리스트 (10–14)

• 이벤트는 상태 변화인가?
• 소비자는 멱등한가?
• 스키마 변경 전략이 있는가?
• 순서 보장이 필요한가?
• 재시도 한계가 정의됐는가?
• DLQ 기준은 명확한가?
• 상관관계 ID가 전파되는가?
• 이벤트 보존 기간은?
• 소비자 스케일 전략은?
• 장애 시 관측 가능한가?
• 데이터 지연 허용 범위는?
• 도메인 경계가 명확한가?

---

14. 용어 지도 (필수 산출물)

용어	의미
EDA	이벤트 기반 아키텍처
CQRS	명령/조회 분리
이벤트 소싱	이벤트 로그가 상태의 근원
이벤트 로그	불변 이벤트 스트림
소비자 그룹	병렬 처리 단위

---

• 참고: 이벤트 기반 마이크로서비스 아키텍쳐: Spring Boot, Kafka, Elastic