반응형 Spring/WebSocket&STOMP4 [Stomp] 다중 서버 웹소켓 환경을 지원할 Redis Pub/Sub 기반 실시간 채팅 서버 구축 가이드 1. 도입부: 다중 서버 환경에서 웹소켓의 뼈아픈 한계실시간 채팅 서비스를 개발할 때 가장 먼저 선택하는 기술은 단연 웹소켓(WebSocket)과 STOMP 프레임워크다. 로컬 개발 환경에서 단일 서버로 구동할 때는 스프링 내부 메모리에 로드되는 SimpleBroker만으로도 실시간 메시지가 완벽하게 공유된다.하지만 실제 서비스 배포 단계로 넘어가 트래픽을 감당하기 위해 서버를 2대 이상으로 스케일 아웃(Scale-out)하는 순간, 예상치 못한 치명적인 결함이 발생한다. ⚠️ 웹소켓 세션의 치명적인 한계웹소켓은 HTTP와 달리 Stateful(연결 지향형) 프로토콜이다. 클라이언트가 특정 서버에 한 번 웹소켓 연결을 수립하면, 계속 그 서버와 연결 세션을 유지하게 된다.이 문제를 해결하기 위해 여러 W.. 2026. 6. 10. [Stomp] Spring 채팅 서버 설계: STOMP 보안 제어부터 JPA 다중 참여자 읽음 상태(ReadStatus) 추적까지 1. 도입부 (Introduction)현대의 웹 서비스에서 실시간성(Real-time)은 사용자 경험을 결정짓는 핵심 요소 중 하나다. 사용자가 브라우저를 새로고침하지 않고도 새로운 메시지를 즉시 수신하는 채팅 서비스는 가장 대표적인 실시간 기능이다. 일반적으로 무상태(Stateless) 방식의 HTTP 단방향 통신만으로는 지속적인 실시간 양방향 데이터 송수신을 구현하는 데 큰 제약이 따른다. 매번 TCP 연결을 맺고 끊는 폴링(Polling)이나 롱폴링(Long-Polling)은 불필요한 네트워크 오버헤드와 심각한 레이턴시(Latency)를 유발하기 때문이다.이러한 한계를 극복하기 위해 등장한 것이 바로 웹소켓(WebSocket)이다. 웹소켓은 최초 1회 HTTP 핸드셰이크를 통해 TCP 연결을 성공적.. 2026. 6. 8. [Stomp] 스프링 부트 STOMP 웹소켓 채팅 서버: 기본 설정부터 메시지 브로커 라우팅까지 1. 도입부: 왜 단순 웹소켓(WebSocket)이 아니라 STOMP인가?우리는 이전 포스팅에서 HTTP 프로토콜의 단방향 통신 한계를 극복하기 위해 웹소켓(WebSocket)을 도입했다. 웹소켓은 최초 1회 핸드셰이크(Handshake) 과정을 거쳐 HTTP 프로토콜을 TCP 연결로 업그레이드(Upgrade)한 뒤, 지속적인 양방향 통신을 가능하게 해준다.하지만 순수 웹소켓(Raw WebSocket)만을 사용하여 채팅 서비스를 만들려고 하면 다음과 같은 중대한 장벽에 직면하게 된다.메시지 규격의 부재: 들어오고 나가는 메시지가 단순 텍스트(문자열) 혹은 바이너리 형태이기 때문에, 개발자가 직접 메시지 포맷(예: JSON 구조)을 파싱하고 해석하는 파이프라인을 매번 직접 구현해야 한다.구독 및 발행(Pu.. 2026. 6. 6. [Spring WebSocket] 웹소켓(WebSocket)과 STOMP, 그리고 Redis로 구현하는 실시간 채팅 정리 1. 도입부: 실시간 웹이라는 거대한 도전전통적인 웹은 "클라이언트가 요청(Request)을 보내면, 서버가 그에 맞는 응답(Response)을 주는" 단방향의 정적인 통신을 기반으로 설계되었다. 이 구조는 웹서버의 자원을 효율적으로 관리하는 데 매우 유리했지만, "실시간(Real-time) 상호작용"이 필수적인 현대 웹 애플리케이션(채팅, 실시간 주식 차트, 협업 도구 등)을 구현하기에는 근본적인 한계가 존재했다.서버가 클라이언트에게 먼저 이벤트를 보낼 수는 없을까? 클라이언트와 서버가 한 번 연결을 맺고 끊임없이 가볍게 데이터를 주고받는 방법은 없을까?이러한 물음에서 실시간 통신 기술들의 진화가 시작되었다. 초기 개발자들이 우회책으로 쓰던 Polling 방식부터 시작하여, 반이중 단방향 스트리밍인 S.. 2026. 5. 31. 이전 1 다음 반응형
