[트러블슈팅] 실시간 알림 전송하기

 

 

📪 Redis Pub / Sub 설계

실시간 알림 시스템을 설계할 때 가장 중요한 요소 중 하나는

사용자에게 즉각적으로 메세지를 전달하는 방법을 선택하는 것이다.

 

이를 위해서는 다양한 기술이 존재하겠지만,

내가 진행했던 프로젝트에서는 Redis의 Pub / Sub 기능을 이용해서 서버 간 메시지를 중계하고,

클라이언트에게는 WeSocket을 통해 실시간 알림을 전달하는 구조를 사용했다.

 

여기서 핵심이 되는 설계 요소는 Redis 채널의 구성 방식이었는데,

내 프로젝트에서는 notification:{userId} 형식을 채택했다.

 

---

🏷️ 사용자 단위 채널 네이밍

Redis의 Pub / Sub 에서 메시지를 전송하기 위해서는 채널을 지정해야 하는데,

이때 채널은 일종의 라우팅 경로 역할을 하며, 메시지를 수신할 주제를 의미한다.

 

내 프로젝트에서는 사용자마다 개별 채널을 만들어주기 위해서 notification:{userId} 형태의 네이밍 규칙을 적용했다.

 

 

 

이렇게 채널 이름을 구성한 이유는 아래와 같다.

 

먼저, notification이라는 접두사는 Redis에 저장되는 키들 중에서 알림과 관련된 채널이라는 것을 명확하게 구분해줄 수 있기 때문이다.

Redis에는 종종 다양한 도메인의 키들이 함께 저장되기 때문에,

명시적인 prefix를 두는 것이 관리와 디버깅 측면에서 도움이 된다고 배웠기 때문이다.

 

그 다음 : 기호는, Redis 키 네이밍 관례에 따라 계층을 분리하는 용도로 사용한 것이며,

 

{userId}는 특정 사용자의 고유 식별자이다.

 

 

 

이 방식을 사용하면 개별 사용자에게만 알림을 전송할 수 있으며,

불필요한 브로드캐스트를 피할 수 있어서 성능적으로도 유리하다고 판단했다.

 

이제 서버는 알림을 전송할 때 notification:42 와 같이 수신 대상이 되는 사용자 ID를 포함한 채널을 지정하여 메시지를 발행하게 되는 것이다.

 

---

📭 메시지 발행과 수신: Redis와 WebSocket 연결 구조

실제로 알림을 전송하는 과정은 아래와 같이 동작한다.

 

사용자 A에게 알림을 보내야 할 상황이 발생하면,

서버에서는 해당 알림 정보를 담은 메시지를 JSON 형식으로 직렬화하고,

notification:{userId} 채널에 메시지를 publish한다.

 

서버는 Redis의 RedisMessageListenerContainer를 통해 이 채널들을 구독하고 있는데,

채널이 사용자 ID에 따라 동적으로 구성되기 때문에

서버는 특정 채널만 구독하는 것이 아니라

패턴 구독 (notification:*)을 통해 모든 사용자 알림 채널을 한 번에 구독하도록 설정해주었다.

 

이 구조 덕분에 서버 인스턴스가 여러 개로 늘어나더라도,

모든 인스턴스가 동일한 채널에 대해 메시지를 받을 수 있으며,

이를 통해 수평 확장성을 확보할 수 있었다.

 

이제 각 서버는 자신에게 연결된 클라이언트 WebSocket 세션 중에서

수신 대상 사용자와 일치하는 세션이 있을 경우

해당 사용자에게 WebSocket 메시지를 전송한다.

 

---

⌛ 메시지 보존성: Redis에 메시지를 저장하지 않은 이유

Redis Pub / Sub은 메시지를 수신자에게 전달한 후, 해당 메시지를 저장하지 않는다.

즉, 발행 당시 구독 중인 클라이언트에게만 메시지가 전달되고, 이후에는 메시지가 Redis 내부에 남지 않는 것이다.

 

이는 Redis Pub / Sub의 설계 철학이 실시간성에 집중되어있기 때문이다.

 

 

따라서 나는 알림 자체는 먼저 RDB에 영구적으로 저장되고,

Redis는 단순히 이를 실시간으로 전달하는 중계 역할을 하도록 설계하였다.

 

 

이를 통해서 클라이언트가 오프라인이거나 메시지를 수신하지 못한 경우에도,

사용자는 나중에 전송하여 RDB에서 자신에게 온 알림 목록을 확인할 수 있다.

 

 

이렇게 영속성과 실시간성을 각각 다른 기술로 분리함으로써

시스템은 안정성과 성능을 모두 확보할 수 있었다 ✨

 

---

⚒️ 수평 확장을 위한 구조 설계

이 구조는 서버가 여러 인스턴스로 확장되더라도 메시지 전달이 단일 노드에 의존하지 않도록 설계되어 있다.

 

모든 서버 인스턴스는 동일하게 notification:* 패턴을 통해 Redis 채널을 구독하고 있기 때문에

알림을 발행한 인스턴스와 상관없이, 사용자에게 WebSocket 세션이 연결된 인스턴스에서 메시지를 받아 최종 전달하게 된다.

 

이 방식은 서버 간에 별도의 세션 동기화나 브로커를 두지 않고도,

자연스럽게 분산 메시징 환경을 구성할 수 있다는 장점이 있다.

 

예를 들어, 어떤 사용자가 인스턴스 A에 연결된 상태에서, 인스턴스 B가 알림을 발행하더라도,

Redis가 메시지를 모든 구독자에게 전파해주기 때문에

인스턴스 A가 메시지를 수신하고, 사용자의 WebSocket으로 전달하는 것이 가능한 것이다.

 

---

🖥️ 구현 방법 요약

앞서 설명한 구조로 구현한 방식은 대략 아래와 같다.

 

메시지 발행

redisTemplate.convertAndSend("notification:" + userId, jsonMessage);

 

메시지 수신

container.addMessageListener(listener, new PatternTopic("notification:*"));

 

WebSocket 전송

messagingTemplate.convertAndSendToUser(userId.toString(), "/notification", messageDto);

 

---

🗨️ Redis Streams가 아닌 Pub / Sub을 선택한 이유

실시간 메시지 전달을 위한 Redis 기술로는 Pub / Sub 외에도 Redis Streams가 존재한다.

 

그러나 Redis Streams는 메시지 보존, 소비자 그룹 관리, 수동 offset 제어 등 많은 기능을 제공하는 대신에

구현이 복잡하고 운영 비용이 증가한다고 들었다.

 

내 프로젝트에서 구현한 알림 시스템은

"실시간으로 즉시 전달되되, 메시지 유실 시에는 DB를 통해 복원 가능한 구조"였다.

 

따라서 메시지 누락 가능성은 시스템 전체적으로 보완할 수 있었고, 복잡한 offset 관리가 불필요했다.

 

이러한 요구사항에는 구조가 단순하고 처리 속도가 빠른 Pub / Sub이 훨씬 적합하다고 판단했기에 이를 적용하기로 결정했다.

 

---

📚 결론

이처럼 Redis Pub / Sub에서 notification:{userId} 형식의 채널 네이밍을 사용한 것은,

사용자 단위로 알림을 정확하게 전달하기 위한 설계였다.

 

메시지를 Redis에 보존하지 않고 실시간으로만 전달하는 구조는 메모리 사용을 최소화하며,

알림의 영속성은 별도의 RDB에서 책임지도록 역할을 분리했다.

 

또한, 패턴 기반 구독 (notification:*)을 사용함으로써

서버가 수평 확장되어도 모든 인스턴스가 동일한 방식으로 메시지를 수신하고 처리할 수 있도록 구성하였으며,

WebSocket과 결합하여 효율적이고 실시간성이 높은 알림 시스템을 완성할 수 있었다.

 

이러한 구조는 실시간성과 확장성, 단순성을 모두 고려한 설계이며,

우리처럼 팀 단위의 중소 규모 서비스에서 빠르게 도입하기에 적합한 방식이라고 판단된다.

 

내 아이디어를 너무나도 멋지게 실제 코드로 구현해준 팀원에게 다시 한 번 너무나도 감사하다 ,, ㅎㅎ 👏🏻