메시지 큐 시스템 완전 정복: Pub/Sub과 Producer/Consumer 패턴의 차이와 활용법

메시지 큐 시스템의 2가지 패턴에 대해서 설명해보세요.

메시지 큐란 무엇인가요?

메시지 큐는 publisher(게시자)와 Consumner(소비자)로 구성됩니다.

통신은 일반적으로 게시자가 소비자에게 명령을 내리는 방법인데요.

생산자가 일반적으로 큐에 메시지를 넣고 소비자는 이 메시지를 소비하고 작업을 수행하는 역할을 합니다.

여기에서 'm n+1'을 큐에 넣는 publisher 서비스를 확인하실 수 있죠.

이미 큐에 여러개의 메시지가 존재해 소비되기를 기다리고 있는 것을 볼 수 있습니다. 

오른쪽에는 큐에서 메시지를 수신 대기하는 consumber A, B가 존재합니다.

먼저 Publisher의 메시지가 대기열 끝으로 이동한 것을 확인할 수 있는데요.

소비자 A가 메시지 'm1'을 읽었으므로 다른 서비스 'B'가 더이상 대기열에서 'm1'을 사용할 수 없게됩니다.

메시지 큐를 사용하는 위치

MSA 아키텍처

메시지 큐는 서비스에서 작업을 위임할 때 자주 사용되는데요. 

이 경우 작업이 1번만 실행되도록 해야합니다.

메시지 큐는 보통 MSA(마이크로 서비스 아키텍처)에서 인기가 있어요. 

클라우드 기반 또는 서버리스 애플리케이션을 개발할 때 부하에 따라 앱을 수평적으로 확장할 수 있기 때문이죠.

예를 들어 큐에 처리 대기중인 메시지가 많은 경우, 동일한 메시지 큐를 수신 대기하고 메시지 유입을 처리하는 여러 소비자 서비스를 구축할 수 있습니다.

메시지가 처리되면 트래픽이 최소화될 때 서비스를 종료하여 운영 비용을 절감할 수 있어요!

Pub-Sub이란 무엇인가요?

메시지 큐에 대해 알아보았으니 이제 Pub-Sub에 대해서 알아보겠습니다.

메시지 큐와 반대로 Pub-Sub 아키텍처에서는 모든 소비(구독) 애플리케이션이 Publisher가 게시하는 메시지를 최소 1개이상 받도록 해야합니다.

왼쪽에 게시자가 "m n+1" 메시지를 토픽에 전송합니다.

이 토픽은 이 메시지를 자신의 구독자에게 브로드캐스트 합니다.

이러한 구독은 대기열에 바인딩됩니다.

각 대기열에는 메시지를 기다리는 구독자 서비스가 존재합니다. (=A, B)

두 구독 서비스는 이 메시지에 사본을 수신하여 "m 1"을 소비하고 있습니다.

또한 토픽은 모든 구독자에게 새 메시지 "m n+1"를 배포하고 있습니다.

각 구독자가 메시지 사본을 받는다는 보장이 필요한 경우 Pub Sub를 사용해야 합니다.

참고로 채널(Channel)과 토픽(Topic)은 거의 같은 의미로 사용이 됩니다.

둘 다 메시지를 주고받는  분류 단위를 뜻해요.

어떤 시스템에서는 채널이라고 부르고, 다른 시스템에서는 토픽이라고 부르지만 역할은 같습니다.

예를 들어:

• Redis Pub/Sub에서는 보통 "채널(channel)"이라 하고,
• Kafka, MQTT, Google Pub/Sub 같은 시스템에서는 "토픽(topic)"이라 부른다고 하네요.

구분	Pub/Sub	메시지 큐
동작 방식	실시간 메시지 브로드캐스트 (비동기적 실시간 전달)	비동기 작업 처리 (작업이 큐에 저장되고 소비자가 처리)
메시지 전달 대상	모든 구독자에게 메시지 전달	오직 한 명의 소비자(워커)에게 메시지 전달
메시지 보존 여부	대부분 메시지 비보존 (예: Redis Pub/Sub) * 메시지 못받아도 재전송 X	메시지 큐에 저장 → 신뢰성 높은 처리 가능 * 만약 ACK 못받으면 큐에 다시 저장
처리 방식	구독자들이 동시에 처리 (병렬 처리 아님)	소비자가 하나씩 꺼내 순차 또는 병렬 처리 가능
사용 목적	이벤트 알림, 실시간 데이터 전송	이메일, 결제, 이미지 처리 등 비동기 작업 분배
확장성	구독자 수에 따라 부하 증가 가능	소비자 수에 따라 작업 처리량 확장 가능
실시간성	매우 높음	처리 시간은 소비자 처리 속도에 따라 달라짐
메시지 중복 가능성	메시지 중복 수신 가능 (모든 구독자에게 전송)	중복 처리되지 않도록 보장 (한 메시지는 한 소비자만 처리)
예시 기술	Redis Pub/Sub, MQTT, WebSocket 이벤트	Redis List/Stream, RabbitMQ, Kafka
장애 대응	구독자 장애 시 메시지 손실 가능	메시지 재처리, 장애 복구 기능 내장
메시지 소비 확인	보통 없음	ACK(확인 응답) 기반 처리

Pub Sub 간접 체험 후기 (?)

제가 개발한건 아니고 pub sub 개발하신 팀원분의 코드 리뷰를 해본 적이 있는데,

이때 pub sub을 공부하면서 블로그에 공유해야 겠다는 다짐을 했었어요.

저희 팀에서는 해당 페이지에 변경사항이 생기면, 그 페이지를 보던 사람에게 변경사항이 있으니 새로고침 하라는

알림 컴포넌트를 띄워주는 기능을 작업하며 redis의 pub sub을 사용했었습니다. 

각 페이지별로 Redis 채널(channel)을 생성해서 해당 페이지에 들어온 사람은 무조건 구독을 하도록 했었기 때문에

해당 페이지에 접속한 사용자는 해당 채널을 구독하여 실시간 알림을 수신할 수 있도록 했었어요.

메시지 큐 간접 체험 후기

또 이건 예전 코드를 그냥 지나치며 봤던건데 갑자기 생각이 나서 이해하시는데 도움이 될까 풀어봅니다.

파일을 내보내는 기능이 있었는데, 이 기능은 해당 문서 html을 pdf로 바꿔서 이메일로 전송해주는 기능이었어요.

html을 pdf로 변환해주는 변환서버가 따로 있었고 (외부서버임) 생성되면 메시지 큐에 넣어서

consumer (소비자) 가 이메일을 발송해주는 형태였습니다.

 

확실히 코드를 같이 봤어서 그런지 이해가 더 잘가네요 !

이걸 간접 체험..? 이라고 할 수 있나 싶지만 어쨌든 이해하시는데에 도움이 조금이나마 되었기를 바라며 다음에 또 만나요