pub/sub의 연결 객체에 대해 질문 드립니다.

작성한 질문수 87

0

안녕하세요. 😊

제가 언급한 "클라이언트 수만큼 pub/sub 연결을 하면 안된다."라는 말은 Redis 클라이언트가 아니라 브라우저를 말한 겁니다.

아래와 같은 구조에서

[사용자(브라우저) - 애플리케이션 - Redis]

새로운 사용자(브라우저)가 접속할 때마다, 애플리케이션에서 Redis로 pub/sub 연결을 하기 때문에 문제라고 한 것입니다.

그래서 정상적인 구조는

애플리케이션에서 Redis로의 pub/sub 연결은 이 애플리케이션의 생명 주기 동안 1개만 유지하고, 여러 사용자(여러 브라우저)에게는 애플리케이션 차원에서 큐(Queue)와 클라이언트 목록으로 관리해서 메시지를 나눠주는 방식(Fan-out)을 사용합니다.
(바로 다음 강의 [패턴 09-개선: FastAPI + Pub/Sub 연동 구조 개선] 에서 개선된 샘플을 제공하고 있습니다.

즉, Redis 구독 연결은 애플리케이션(서버 프로세스)당 1개로 고정하고, 그 연결로 받은 메시지를 애플리케이션 메모리 안에서 각 브라우저 연결(Queue)에 전달해주는 거죠. 그래서 브라우저가 100명이든 10,000명이든 Redis 입장에서 보는 구독 연결은 항상 1개입니다.

제가 표현을 단순히 Redis 클라이언트라고만 해서 혼란이 있었나 봅니다. 😊

0

안녕하세요, 인프런 AI 인턴입니다. bluebamus님.

질문하신 내용은 Redis Pub/Sub 연결 수와 애플리케이션 서버의 브로드캐스팅 구조에 관한 내용으로, 아래 기존 답변이 가장 유사합니다.

Redis와 Kafca의 Pub/Sub 차이

Redis Pub/Sub은 구독 중인 연결에만 실시간으로 메시지를 전달하며, 연결이 끊겨 있으면 메시지가 유실될 수 있습니다. 따라서 일반적으로는 클라이언트마다 Redis Pub/Sub 연결을 직접 생성하는 방식이 아니라, 애플리케이션 서버가 소수의 Redis 구독 연결을 유지하고 수신한 메시지를 해당 서버에 연결된 클라이언트들에게 브로드캐스트합니다.

구조를 간단히 표현하면 다음과 같습니다.

Redis Publisher
      ↓
애플리케이션 서버의 소수 Redis Subscriber 연결
      ↓
각 서버 내부의 WebSocket/SSE 클라이언트들에게 브로드캐스트

여기서 “소수의 연결”이라는 의미는 전체 서버에서 Redis 연결을 하나만 사용한다는 뜻이 아니라, 애플리케이션 서버 인스턴스마다 필요한 수의 구독 연결을 유지한다는 의미에 가깝습니다.

예를 들어 애플리케이션 서버가 10대라면 각 서버가 Redis Pub/Sub 연결을 하나씩 유지하여 총 10개의 구독 연결을 사용할 수 있습니다. 하나의 Redis 연결에서 여러 채널을 구독하는 것도 가능합니다. 클라이언트가 수천 명이라고 해서 Redis 연결도 수천 개가 되어야 하는 것은 아닙니다.

또한 애플리케이션 시작 시 구독 연결을 생성하고, 서버 종료 시 구독을 해제하는 방식이 적절합니다. Swagger 요청마다 Pub/Sub 연결을 새로 만드는 예제라면, 이는 설명을 위한 단순한 예제일 수 있으며 실제 서비스에서는 연결을 재사용하는 구조로 개선하는 것이 좋습니다.

Redis Lock이나 Redlock에서 사용하는 Redis 연결 수와 Pub/Sub 브로드캐스트 연결 수는 서로 다른 문제입니다. 분산 락은 여러 Redis 노드에 락을 요청하기 위한 연결이 필요할 수 있지만, Pub/Sub은 메시지를 수신하고 애플리케이션 서버 내부의 클라이언트에게 전달하기 위한 별도의 구독 연결 구조로 이해하시면 됩니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.