[Messaging] RabbitMQ 도입 구상편

RabbitMQ

 

관련 나의 블로그 글
분산 메세지 큐 1편 - 읽은 책	https://jm-baek.tistory.com/325
분산 메세지 큐 2편 - 읽은 책	https://jm-baek.tistory.com/330
[Messaging] RabbitMQ 개념편	https://jm-baek.tistory.com/363
✅ [Messaging] RabbitMQ 도입 구상편	https://jm-baek.tistory.com/358
[Messaging] RabbitMQ 도입편	https://jm-baek.tistory.com/392

 

 

 

혼자 고민하고 정리해서 서툴고 틀린 방향이 있을 수 있습니다.

좋은 충고와 질문은 어제든 감사드립니다.

 

 

🎯 빠른 정리

아래 순서대로 고민하고 내용을 정리했습니다.

 

🙋 메세지를 전송하기 위해 어떠한 아키텍처(구조)를 가질 수 있을까?

🙋 알림 생성하는 로직은 할까?

🙋 실시간으로 사용자들에게 어떻게 알림(메세지)를 보낼 수 있을까?

 

🎯 빠른 결론

• 단일 큐(mail.queue)를 사용하고 Consumer에서 userId를 필터링하여 SSE로 전달하는 방식이 더 효율적
• RabbitMQ의 리소스를 아낄 수 있고, 대규모 사용자 처리에도 적합

결론
사용자별 큐 생성 (Direct Exchange)	특정 사용자만 메시지를 받을 수 있음	큐 개수가 많아질 경우 리소스 낭비
단일 큐 + userId 포함 후, Consumer에서 필터링	큐 관리를 최소화할 수 있음, 확장성이 뛰어남	Consumer에서 userId 필터링 작업이 필요함

 

---

알림 서비스 구상

1️⃣ 첫 번째 고민 

결론: 개발하고 있는 서비스 규모 등을 비교했을 때, 1번 방법이 구현 가능이 높다고 판단.

 

🙋 메세지를 전송하기 위해 어떠한 아키텍처 구조를 가질 수 있을까?

 

1. 다른 서버에서 직접 메시지를 생성해서 메세지 큐로 보내는 방식
→  내가 생각한 구조

 

프로세스 순서

1. 알림이 필요한 서비스는 메세지를 생성하고 메세지 큐로 보낸다.
2. 알림 서비스는 메세지 큐를 소비하고 있는다.
3. 알림 서비스는 메세지에 맞는 특정 기능으로 알림을 전송 한다.
4. 수신 여부와 상관없이 데이터베이스에 해당 알림을 기록한다.

내가 생각한 구조

 

2. 다른 서버가 알림 생성 서버 API에 요청하고, 알림 생성 서버가 메시지 큐로 보내는 방식 
→ 카카오 알림 서비스 구성 2020

 

프로세스

1. 왼쪽에 있는 여러 서비스 서버들이 알림 생성 서버로 요청을 날림
2. 알림 생성 서버는 요청에 따른 메세지를 생성하고
3. 메세지 큐의 장애를 대응하기 위해 DB에도 요청 내용을 저장한다.
4. 알림 조회 서버(?)는 메세지 큐를 받고 DB에 저장한다.

카카오 알림 서비스 2020

---

2️⃣ 두 번째 고민

🙋 알림 생성하는 로직은 어떻게 작성할까?

 

1. 구독 서비스 형태

로그인을 하면 Queue가 생성되고 필요한 서비스와 Binding되게 된다.

즉, 동적으로 Queue와 Binding 가 생성 될 수 있다는 얘기이다.
(다른 블로그에서 그렇게 본 것 같다.)

 

프로세스

1. 사용자가 서비스 A를 통해 특정 서비스를 구독한다.
2. 서비스 A는 사용자의 ID 또는 사번 등 사용자를 나타낼 수 있는 키 값을  메세지 큐로 전달한다.
3. 서비스 B는 키 값으로 Queue와 Binding 생성해서 연결한다.
4. 만약, 구독 취소하면 관련된 Queue와 Binding은 삭제한다.

 

 

 

2. 특정 이벤트가 발생 시, 대상에게 알림 전송

해당 방법은 Message 방식 외에도 다른 서드 파티 등이 붙어서 알려주는 역할을 하는 방법이다.

즉, 이벤트 감지를 메세지 큐에서 하고 해당 이벤트에 대한 정보를 여러 툴(tool)로 알려준다.

 

프로세스

1. 이벤트 발생 (Event Producer) → 데이터베이스 변경, 비즈니스 로직 처리, 외부 API 요청 등
2. 이벤트 감지 (Event Listener) → 특정 조건 충족 시 이벤트를 트리거
3. 알림 전송 (Event Consumer) → WebSocket, 푸시 알림, 이메일 등 다양한 채널로 자동 전송

---

3️⃣ 세 번째 고민

🙋 실시간으로 사용자들에게 어떻게 알림(메세지)를 보낼 수 있을까?

해당 고민은 두 번째 고민에서 거의 90프로는 해결이 됐다고 볼 수 있다.

두 번째 고민의 2번 방법을 채택하면서 메세지 큐는 이벤트 감지를 목적으로 사용되고 실시간으로 전달하기 위한 서드 파티 등을 찾으면 된다.

 

본 서비스에서는 알림(toast) 기능을 목적으로 하기 때문에 단방향 Stateful 통신으로 적합한 SSE 방식을 선택했다.

 

통신 방법

1. WebSocket
2. Server-Sent Events(SSE)
3. TCP Socket
4. API 통신

---

참고 사이트

• https://velog.io/@juhyeon1114/RabbitMQ-%ED%94%84%EB%A1%9C%EB%93%80%EC%84%9C-%EC%BB%A8%EC%8A%88%EB%A8%B8-%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EB%A7%8C%EB%93%A4%EA%B8%B0-w.-Spring-boot

RabbitMQ 프로듀서, 컨슈머 애플리케이션 만들기 (w. Spring boot)

 

• https://minholee93.tistory.com/entry/RabbitMQ-Jackson2JsonMessageConvertor

[RabbitMQ] Jackson2JsonMessageConvertor

 

• https://aws.amazon.com/ko/what-is/dead-letter-queue/

DLQ(Dead Letter Queue)란 무엇인가요? - DLQ(Dead Letter Queue) 설명 - AWS

 

• https://velog.io/@paduck-96/%EC%B9%B4%EC%B9%B4%EC%98%A4-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-RabbitMQ-%EA%B5%AC%ED%98%84

[카카오 프로젝트] RabbitMQ 구현

• https://www.rabbitmq.com/

RabbitMQ: One broker to queue them all | RabbitMQ

 

 

 

 

---