채팅 구조에 대한 고민 - boostcampwm2023/web07-GBS GitHub Wiki

고민

이번 프로젝트에서도 채팅 기능이 필요한데 채팅은 WebSocket으로 구현 가능하다고 알고 있다.

그런데 전에 네이버 스포츠의 문자 중계를 분석한 글을 본 적이 있다.

글에서 이야기했던 문자 중계에 WebSocket이 부적합한 이유는 아래와 같다.

• 동시접속자가 많은 경우에 각 사용자마다 연결을 유지해야 된다. (비용)
• 양방향 통신은 불필요하다.

스트리밍 서비스에서 사용자 수의 제한이 없거나 사용자가 상당히 많기 때문에 모든 사용자를 WebSocket으로 연결하는 건 비용이 많이 들고 물리적인 한계가 있을 것 같다.

그래서 GPT에게 물어봤더니 Kafka, RabbitMQ 등의 Pub/Sub 모델을 사용하는 게 가장 좋다는 답변을 받았다.

전에도 WebSocket + STOMP를 사용한 Pub/Sub 모델로 채팅을 구현해본 적이 있었는데

이게 부적절한 이유는 Pub/Sub 모델이 한 서버에 종속돼있는 것이라서 Kafka, RabbitMQ 등을 사용해 Pub/Sub 모델을 외부로 분리하고 WebSocket 연결을 여러 서버로 나누면 된다.

스트리밍 서비스에는 채팅을 보기만 하는 시청자들도 있을텐데 전부 WebSocket을 연결해두는 건 낭비가 아닌가?

기본적으로 Polling 방식으로 채팅을 불러오고 채팅을 처음 전송했을 때 부터 WebSocket을 연결하는 방법도 가능하겠다.

선택

그럼 Kafka, RabbitMQ, Redis 중 어떤 걸 사용하는 게 좋을까?

Message Broker	Scale	Data Persistency
Redis	초당 최대 백만 개	기본적으로는 불가능
Kafka	초당 최대 수백만 개	영속성 지원
RabbitMQ	초당 약 5만개	둘 다 가능

스트리밍 플랫폼의 대규모 트래픽을 처리하기 위해서는 성능이 가장 뛰어난 Kafka가 적절하다.

하지만 Kafka의 러닝 커브가 좀 높기 때문에 고민이 된다.