콘텐츠로 이동

Pub/Sub 메시징

개요

Pub/Sub은 발행(publish)과 구독(subscribe) 모델로 메시지를 주고받는 방식을 말해요. 메시지를 보내는 쪽(발행자)과 받는 쪽(구독자)이 서로를 몰라도 되는 구조예요. 발행자는 특정 채널(channel)에 메시지를 던지고, 그 채널을 구독한 클라이언트들이 메시지를 받아요. 발행자가 누가 듣는지 알 필요도, 구독자가 누가 보냈는지 알 필요도 없죠.

Redis의 Pub/Sub은 이런 느슨한 결합 덕에 한 이벤트를 여러 소비자에게 동시에 전파하거나, 서로 다른 서비스 사이에서 메시지를 흘려보내는 데 잘 어울려요.

핵심 개념

구독과 발행

클라이언트는 SUBSCRIBE 명령으로 하나 이상의 채널을 구독해요. 다른 클라이언트가 그 채널에 PUBLISH로 메시지를 보내면, 구독 중인 클라이언트는 그 메시지를 받아요.

SUBSCRIBE first second        # 채널 first, second 구독
PUBLISH second Hello          # 다른 클라이언트가 채널 second에 발행
# → 구독자는 "second" 채널의 "Hello" 메시지를 수신

이처럼 발행과 구독은 시간적으로 겹칠 필요가 없듯 보이지만, 실제로는 구독자가 그 순간 연결되어 있어야만 메시지를 받아요.

키 스페이스와 무관

Pub/Sub은 키 스페이스와 아무 관계가 없어요. 데이터베이스 번호에 간섭하지 않도록 설계되었어요. 예를 들어 db 10에 발행해도 db 1의 구독자가 들을 수 있어요. 이는 Pub/Sub 메시지가 저장되는 데이터(key)가 아니라 통로이기 때문이에요.

채널 스코핑 — 환경별 채널 이름

Pub/Sub은 데이터베이스로 구획이 나뉘지 않으므로, 환경(test, staging, production)을 채널 이름에 접두사로 붙이는 게 일반적인 방법이에요. 예를 들어 production:notify, staging:notify처럼 나눠 동일한 채널명이 서로 다른 환경에서 섞이지 않게 해요.

중요한 한계 — 전달 보장 없음

Redis Pub/Sub은 메시지를 한 번 구독자에게 전달하면 저장하지 않아요. 즉 연결이 끊긴 구독자는 그 사이의 메시지를 받지 못해요. 메시지를 잃지 않고 보관하면서 처리해야 한다면, 큐 역할을 하는 다른 방식(예: 작업 큐)과 구분해서 써야 해요.

실제 적용 (데이터스케쳐스)

Pub/Sub은 Redis가 캐시·큐와는 또 다른 역할을 맡을 수 있게 해줘요.

  • 이벤트 전파 — 콘텐츠 변경·알림 같은 이벤트를 여러 서비스(캐시 갱신, 알림, 로그)에 동시에 흘려보내요.
  • 채널 스코핑 — 채널 이름에 환경 접두사를 붙여 테스트·운영이 서로 간섭하지 않게 해요.
  • 큐와의 구분 — 작업을 잃으면 안 되는 경우는 Pub/Sub이 아니라 작업 큐(Bull)를 써요. Pub/Sub은 "지금 연결된 구독자에게 알리는" 용도로 쓰죠.

메시지를 저장 없이 실시간으로 전파하는 Pub/Sub과, 메시지를 보관하며 처리하는 큐를 역할에 맞게 나눠 쓰는 게 핵심이에요.

더 알아보기