빠른 통신과 중계: Pub/Sub과 실시간 접속 상태

Pub/Sub (Publish/Subscribe) 개념 이해하기

Pub/Sub(발행/구독)은 방송국과 라디오의 관계와 똑같습니다.

라디오 주파수(Channel)를 맞춰둔 청취자(Subscriber)들은 방송국(Publisher)이 전파를 쏘면 그 즉시 소리를 듣습니다. 가장 중요한 특징은 방송국은 청취자가 방송을 녹음했는지, 잘 들었는지 확인하지 않는다는 것입니다. 그냥 쏘고 잊어버립니다(Fire and Forget).

Redis는 데이터를 저장하는 기능 외에도 이런 Pub/Sub 기능을 아주 가볍고 빠르게 지원합니다.

실시간 채팅에서의 활약

웹소켓(WebSocket)을 이용해 채팅 시스템을 만들 때 가장 큰 벽은 다중 서버 환경입니다. 유저 A가 1번 서버에 붙어 있고, 유저 B가 2번 서버에 붙어 있다면, A가 보낸 메시지는 어떻게 2번 서버로 넘어가서 B에게 도달할 수 있을까요?

이때 Redis Pub/Sub이 중계소 역할을 합니다. 1번 서버는 Redis에 메시지를 쏘고, 모든 서버는 항상 Redis를 구독하고 있다가 자기에게 붙어 있는 유저에게 메시지를 배달해 줍니다. 매우 빠르고 딜레이가 없어 실시간 알림이나 채팅에 완벽합니다.

// [구독자 서버] - 채팅방 채널을 항상 듣고 대기합니다.
const subscriber = redis.duplicate();
await subscriber.subscribe('chat:room:A', (message) => {
  console.log('새 메시지 도착:', message);
  // 이 서버에 연결된 클라이언트(유저)들에게 웹소켓으로 메시지를 쏴줍니다.
  broadcastToUsers(message);
});

// [발행자 서버] - 누군가 메시지를 보내면 채널에 던집니다.
const publisher = redis.duplicate();
async function sendMessage(text) {
  // 메인 DB에 메시지 내역을 영구 저장하는 작업은 별도로 수행합니다.
  await db.saveMessage(text); 
  
  // Redis에 전파를 쏩니다. 데이터를 보관하지 않고 그냥 뿌리기만 합니다.
  await publisher.publish('chat:room:A', text);
}

주의할 점: 발송 확인이 불가능하다

Redis Pub/Sub의 가장 큰 장점인 '가벼움'은 동시에 가장 큰 단점이기도 합니다.

누군가 듣고 있지 않을 때 메시지를 쏘면, 그 메시지는 그냥 허공으로 사라집니다(증발). "내가 보낸 알림을 저 유저가 확실히 받았을까?"를 보장해야 하는 중요한 데이터(예: 결제 완료 통보)라면 Redis Pub/Sub을 쓰면 안 됩니다.

이때는 반드시 메인 DB의 트랜잭션을 활용하거나, 메시지 도달을 보장하는 전문 메시지 큐(RabbitMQ, Kafka 등)를 고려해야 합니다.