📌 Messaging System 이란?
시스템 간 데이터를 비동기로 전달하기 위한 인프라
💡 참고 ) 비동기는 언제 사용해야 할까?
📌 동기 vs 비동기 선택 가이드
동기 비동기 결과가 즉시 필요한가? Yes
- 로그인 성공 여부
- 결제 승인 결과
- 잔액 조회No
- 이메일발송
- 알림
- 로그 저장실패 시 즉시 알려야 하나? Yes
- 결제 실패
- 권한 없음
- 유효성 검사No
- 통계 반영 실패
- 로그 수집 실패처리 시간이 긴가? No Yes
- 이미지 변환
- 대용량 파일 처리요청자가 결과에 의존하는가? Yes No 트래픽 폭증 가능성? No(낮음) Yes(높음)
- 주문 이벤트
📌 비동기 처리시 주의점 → 요청자와 처리자가 동시에 같은 상태를 보지 않는다 !
1. 중복 처리 (다음과 같은 장애 상황에서 중복이 발생할 수 있음)
- Consumer가 처리 중 죽음
- ACK(또는 offset commit) 못 함
- 메시지 재전송
- 같은 메시지 다시 처리
2. 순서 문제 (다음과 같은 상황에서 순서 문제가 발생할 수 있음)
- 여러 Partition
- 병렬 Consumer
- 네트워크 지연
→ 비동기 환경에서는 메시지 처리 순서가 보장되지 않기 때문에 상태 전이가 순서에 의존하는 도메인에서는 오류가 발생할 수 있다.
3. 보상 트랜잭션
- 왜 필요한가?
→ 비동기 = 분산 트랜잭션
비동기 분산 환경에서는 원자적 롤백이 불가능하므로 실패를 되돌리기 위한 보상 트랜잭션 설계가 필수
📌 종류
- Kafka
- RabbitMQ
- ActiveMQ
- Amazon SQS
- 등등 ...
Messaging System
├─ Message Broker (Queue 기반)
│ ├─ RabbitMQ
│ ├─ ActiveMQ
│ └─ Amazon SQS
│
└─ Event Streaming Platform
├─ Kafka
├─ Pulsar
└─ Kinesis
📌 분류
Message Broker vs Event Streaming Platform- Message Broker는 작업 전달
- Event Streaming Platform은 이벤트 기록과 공유
1. Message Broker (Queue 기반)
메시지를 누군가에게 정확히 전달하는 것이 목적
Producer → Queue → Consumer
(소비되면 삭제)- Broker가 메시지를 Consumer에게 전달
- Ack 기반
- 빠른 처리 중심
ACK : 메시지를 잘 받았고 처리했다는 확인 응답
2. Event Streaming Platform (Log 기반)
이벤트를 로그처럼 저장하고 공유하는 것이 목적
Producer → Topic(Log)
↑
여러 Consumer Group
- Consumer가 직접 읽음
- Offset 관리
- 처리 속도 Consumer가 제어
| 구분 | Message Broker | Event Streaming |
| 장점 | 단순, 빠름 | 확장성, 재처리 |
| 단점 | 히스토리 없음 | 설계 난이도 |
| 운영 | 쉬움 | 상대적으로 어려움 |
| 모델 | Queue | Log |
| 특징 | • Broker가 메시지를 Consumer에게 전달 • Ack 기반 • 빠른 처리 중심 |
• Consumer가 직접 읽음 • Offset 관리 • 처리 속도 Consumer가 제어 |
| 사용 예시 | 이메일 발송 이미지 변환 푸시 알림 |
주문/결제 로그 행동 분석 |
| 저장 방식 | 임시 (소비 후 삭제) → 재처리 어려움 | 로그(소비 후 유지) → 재처리 가능 |