동기 호출의 한계
MSA 도입했는데 오히려 느려졌다면, 동기 호출 체이닝이 원인일 가능성이 높습니다.
주문 서비스 → 결제 서비스 → 재고 서비스 → 배송 서비스이 구조에서 배송 서비스가 3초 걸리면? 전체 응답도 3초 이상.
배송 서비스가 죽으면? 주문 자체가 실패.
이게 바로 분산 모놀리스 문제입니다.
이벤트 기반으로 전환
이벤트 기반 아키텍처는 서비스 간 결합도를 낮춥니다.
주문 서비스 → [주문 완료 이벤트 발행] → 즉시 응답
결제 서비스 ← 이벤트 구독 → 처리
재고 서비스 ← 이벤트 구독 → 처리
배송 서비스 ← 이벤트 구독 → 처리주문 서비스는 이벤트만 발행하고 끝. 나머지는 각자 비동기로 처리합니다.
배송 서비스가 느려도, 죽어도 주문 응답엔 영향 없습니다.
핵심 구성 요소
1. Event Broker
이벤트를 저장하고 전달하는 중앙 허브.
| 옵션 | 특징 |
|---|---|
| Kafka | 대용량, 내구성, 순서 보장 |
| RabbitMQ | 유연한 라우팅, 낮은 지연 |
| AWS SNS/SQS | 관리형, 빠른 구축 |
2. Event Schema
이벤트 구조를 명확히 정의해야 합니다.
{
"eventId": "uuid",
"eventType": "ORDER_COMPLETED",
"timestamp": "2026-01-27T10:00:00Z",
"payload": {
"orderId": "12345",
"userId": "user-001",
"amount": 50000
}
}3. Consumer Group
같은 이벤트를 여러 서비스가 독립적으로 소비합니다.
ORDER_COMPLETED 이벤트
├── 결제 서비스 (Consumer Group A)
├── 재고 서비스 (Consumer Group B)
└── 알림 서비스 (Consumer Group C)
주의할 점
1. 멱등성 처리
네트워크 문제로 같은 이벤트가 중복 전달될 수 있습니다.
해결책:
- eventId로 중복 체크
- DB에 처리 완료 기록
- Upsert 패턴 사용2. 순서 보장
Kafka는 파티션 내 순서만 보장합니다.
같은 주문의 이벤트는 같은 파티션으로:
partition key = orderId3. 장애 처리
Consumer 장애 시 Dead Letter Queue로 이동.
정상 처리 실패 → 재시도 (3회)
→ 계속 실패 → DLQ로 이동
→ 나중에 수동 처리도입 효과
실제 프로덕션 환경에서 이벤트 기반으로 전환 후:
| 지표 | Before | After |
|---|---|---|
| 응답 시간 (p99) | 4.2초 | 800ms |
| 가용성 | 99.2% | 99.95% |
| 서비스 간 장애 전파 | 높음 | 거의 없음 |
마무리
이벤트 기반 아키텍처는 MSA의 핵심 패턴입니다.
도입 전 체크:
- 서비스 간 동기 호출이 많은가?
- 장애 전파가 문제인가?
- 확장성이 필요한가?
하나라도 해당되면 검토해볼 가치가 있습니다.
더 자세한 구현 가이드는 아래 문서를 참고하세요.
