미니 프로젝트 - RabbitMQ 도입기

📘알림 저장과 전송 분리를 위한 구조 설계를 위한 RabbitMQ 정리

0. 메세지 큐 도입의 필요성

모임 기반 앱의 알림 시스템 구조를 설계하면서 메세지 큐 기능의 도입이 필요했다.

• 알림을 큐에 넣고 비동기로 처리할 수 있어야 한다.
• 저장과 전송을 분리해 안정성을 높일 수 있어야 한다.
• 실패한 전송은 재시도하거나 추적할 수 있어야 한다.
• 향후 푸시, 이메일 등 채널 확장에도 유리해야 한다.

---

1. 현재 알림 시스템의 구조

[도메인 이벤트 발행]
    ↓
[알림 허브 도메인: 메시지 가공]
    ↓
[알림 도메인: 알림 저장 + 사용자에게 전송]

해결해야 할 문제

• 전송 실패 시 알림 유실 위험
• 저장과 전송이 동시에 실패하면 안 됨

---

2. RabbitMQ 장점 및 필요성

전송 유실 방지

알림은 빠르게 보내는 것도 중요하지만, 전송이 실패해도 유실되지 않아야 한다.

• 메시지를 큐에 보관해서
• 실패해도 나중에 다시 보낼 수 있다

저장과 전송을 따로 처리할 수 있다

전송이 실패했다고 해서 알림 저장까지 같이 실패하면 안 된다.

• 먼저 알림을 저장하고 (컬럼 추가 필요)
• 전송은 큐에 넣어서 따로 처리할 수 있다
• 실패한 전송은 재시도하거나 추적할 수 있다

확장 가능성

지금은 WebSocket만 쓰지만, 나중에 푸시, 이메일, 문자 같은 기능이 생길 수 있다.

• 메시지를 여러 방식으로 나눠서 전송할 수 있어서
• 구조를 처음부터 확장 가능하게 설계할 수 있다

---

3. 트래픽 예측

• 주간 모임 생성 15,000건 기준 (출처: 소모임, 문토)
• fan-out 1,000명, 하루 5시간 집중 사용 가정

예상되는 알림 트래픽 (fan-out 1,000 기준, 하루 5시간 활동 기준)

알림 종류	주간 트리거 수	fan-out	MQ 메시지 수	초당 MQ 메시지 수
모임 생성	15,000	×1,000	15,000,000	119.05
모임 수정	10,000	×10	100,000	0.79
모임 참가 + 결제	50,000	×2	100,000	0.79
모임 취소/환불	10,000	×1	10,000	0.08
팔로우	70,000	×1	70,000	0.56
총합	155,000	-	15,280,000	121.27

• 하루 5시간 집중 사용 기준, 초당 약 121건의 MQ 메시지가 발생
• RabbitMQ는 초당 최대 20,000건까지 처리 가능해, 모임 생성이 초당 20건 이상 몰려야 한계에 도달
• 이 정도 트래픽은 극히 드문 예외 상황이며, 현재 구조로도 충분히 안정적으로 대응 가능

---

4. 다른 방식과의 비교

4-1 Redis Streams 와 비교시 RabbitMQ 의 장점

• 자동 재시도와 DLQ 지원
  • Redis Streams는 자동 재시도나 DLQ 기능이 없어, 실패 메시지를 직접 추적하고 재처리 로직을 구현해야 한다.
• 구현이 단순하고 안정적
  • Redis Streams에서는 재시도를 위해 XPENDING, XCLAIM, 재시도 횟수 추적, 시간 체크 등 여러 작업을 수동으로 처리해야 한다

---

4-2 Kafka와 RabbitMQ, 전송량 처리 기준 비교

• Kafka 방식이 성능은 더 좋지만 그만큼의 비용이 더 요구된다.
• 전체적으로 약 2배 ~ 5배까지 비용 발생

항목	RabbitMQ (초당 121건 기준)	Kafka (초당 121건 기준)	차이 (배수)
메모리 사용량 (MB)	300	2000	6.7
CPU 사용률 (%)	15	35	2.3
디스크 사용량 (GB/일)	1	10	10.0
네트워크 사용량 (MB/일)	200	600	3.0
최대 처리량 (msg/sec)	20,000	1,000,000	50.0
현재 트래픽 (msg/sec)	121	121	1.0
처리량 대비 활용률 (%)	0.6	0.0121	0.0

---

4-3 스케줄러 기반 방식과의 비교

일반적으로 DB에 저장하고, 주기적으로 스케줄러로 전송하는 방식도 존재한다.

그러나 이 방식은 다음과 같은 한계를 갖는다:

항목	스케줄러 방식	MQ 기반 방식
전송 지연	수초~수분 지연 발생	실시간 전송 가능
확장성	배치 단일 스레드 한계	MQ 컨슈머 병렬 확장 가능
장애 대응	실패 처리 복잡	재시도/실패 큐 자동 분리
추적 가능성	직접 로그/상태 구현	전송 상태 필드와 DLQ 활용

---

5. 구조 요약

최종적안 우리의 알림 시스템 예시

도메인 이벤트 (AFTER_COMMIT)
    ↓
알림 허브: 메시지 가공
    ↓
RabbitMQ 발행 (notification.exchange)
    ↓
[컨슈머1] 알림 저장 (DB)
    ├─ 성공: 전송 요청 발행
    └─ 실패: 재시도 큐 또는 DLQ
        ↓
[컨슈머2] 전송 (SSE/FCM)
    ├─ 성공: 상태 업데이트
    └─ 실패: 재시도 큐 또는 DLQ

---

6. 기술 선택 기준 정리

처리량 수준	추천 MQ	이유
~5,000건/초	RabbitMQ	간단하고 실시간성 우수
~10,000건/초	RabbitMQ or Kafka	Kafka는 트래픽 지속 시 고려
10,000건 이상	Kafka	분산 처리 기반, 대규모 최적화

7. 결론

• RabbitMQ를 도입하면:
  • 알림 유실 방지
  • 저장/전송 분리
  • 실시간 처리 & 부하 분산 가능
• 단, 공지사항처럼 수십만 명에게 fan-out되는 대용량 케이스는 Kafka 설계도 고려 필요