실시간 분산 메세지 시스템
클라이언트와 실시간으로 통신하면서, 여러 서버에서 동기화하는 방식
실시간 업데이트와 다중 서버 환경 구축
실시간성과 수평 확장성을 모두 확보
- 구현:
STOMP WebSocket+Redis Pub/Sub조합
WebSocket(STOMP):
클라이언트에게 실시간 데이터 푸시
Redis Pub/Sub:
실시간 데이터를 발생시킨 서버 간의 동기화
STOMP WebSocket + Redis Pub/Sub
다중 서버 환경(클러스터)에서 각 서버 간에 실시간 메시지를 동기화해야 할 때
클라이언트와 서버 간에는 STOMP 기반 WebSocket을 사용해 실시간 통신을 하고,
서버 간에는 Redis Pub/Sub로 메시지를 전달하여 모든 인스턴스에서 업데이트를 반영
장점
수평적 확장성:
여러 서버 인스턴스에서 클라이언트가 연결되어 있을 때
한 서버에서 발생한 이벤트가 Redis를 통해 모든 서버에 전달되어
각 서버가 연결된 클라이언트에게 실시간 업데이트를 보낼 수 있음
분산 환경 대응:
클라이언트가 어떤 서버에 연결되어 있든 일관된 실시간 데이터를 받을 수 있음
단점
구현 복잡성:
WebSocket과 Redis Pub/Sub 두 가지 기술을 동시에 관리해야 하므로 아키텍처가 복잡해짐
추가 오버헤드:
Redis Pub/Sub를 통한 메시지 중계로 인해 네트워크 레이턴시와 추가 리소스 사용
STOMP WebSocket만 사용
클라이언트는 HTTP 요청/응답 방식으로 투표 등의 작업을 처리하고,
별도의 채널(예: 다른 WebSocket 연결 또는 다른 서비스)을 통해 실시간 알림을 받을 경우
REST API 방식으로 클라이언트 요청을 받고, 그 결과를 저장 및 처리한 후
내부적으로 Redis Pub/Sub를 통해 다른 서버나 시스템에 이벤트를 전달
장점
단순한 요청 처리:
REST API 방식이라 요청/응답 로직 구현이 쉽고 테스트도 간편함
비동기 이벤트 전파:
Redis Pub/Sub를 사용하여 비동기적으로 다른 시스템(예: WebSocket 서버)이나 서버 간에 이벤트를 전달할 수 있음
단점
실시간성 부족:
REST API 자체는 단방향 요청/응답 방식이므로,
클라이언트에 실시간 푸시를 하려면 별도의 실시간 메시징(예: WebSocket)을 추가로 구성해야 함
두 시스템 관리:
클라이언트 요청은 REST API로 받고, 동시에 Redis Pub/Sub를 통한 이벤트 전달 구조를 따로 구성해야 하므로,
전체 시스템 아키텍처가 두 가지 방식의 장점을 섞어야 하므로 복잡도가 높아질 수 있음
Redis Pub/Sub만 사용
단일 서버 환경 또는 서버 간 동기화가 필요 없는 경우
모든 클라이언트가 하나의 서버에 연결되어 있고,
해당 서버에서 모든 실시간 메시지 처리를 직접 수행할 때
장점
구조 단순성:
추가적인 메시지 브로커 없이 직접 WebSocket을 통해 실시간 메시지를 처리하므로 구현과 유지보수가 상대적으로 쉬움
낮은 지연 시간:
Redis 중간 단계를 생략하므로 메시지 전달 과정에서의 추가 지연이 없음
단점
확장성 한계:
서버가 여러 개로 확장될 경우, 각 서버 인스턴스 간에 실시간 메시지 동기화가 어려워짐
(예: A 서버에서 발생한 이벤트가 B 서버에 연결된 클라이언트에 전달되지 않음)
단일 장애점:
단일 서버에 모든 실시간 처리가 집중되면 해당 서버에 문제가 생겼을 때
전체 시스템이 영향을 받을 수 있음
