WebSocket과 STOMP만을 이용한 채팅 구현은 몇가지 문제 존재.
-
서버 시작마다 정보 리셋 -> DB로 Redis 이용.
-
채팅 서버 여러대일 경우, 서버간 채팅방 공유 불가능
채팅방을 WebSocket과 STOMP pub/sub으로 구현한 경우 pub/sub이 발생한 서버 내에서만 메시지 주고받기 가능.
즉 구독 대상인 채팅방(topic)이 생성된 서버 안에서 만 유효 -> 다른 서버로 접속한 클라는 볼수없고, 채팅방(topic) 구독 불가능.
해당 문제 해결 위해서 공통으로 사용 가능한 pub/sub 시스템 구축하고, 모든 서버가 해당 시스템 통해서 pub/sub 메시지 주고받도록 해야 함.
Redis의 특징과 실시간 채팅 구현에 적합한 이유
-
In-memory 데이터 저장: Redis는 모든 데이터를 메모리에 저장하므로 매우 빠른 읽기 및 쓰기 성능을 제공 -> 실시간 채팅에서 중요한 요소.
사용자들 간의 실시간 메시지 전달을 위해서는 최소한의 지연 시간과 높은 처리량이 필요하기 때문에 메모리에서 데이터를 읽고 쓰는 Redis는 이에 적합하다. -
Pub/Sub 메커니즘: Redis는 발행/구독(Publish/Subscribe) 메커니즘을 제공하여 이를 통해 실시간 메시지를 구독하고 발행할 수 있다.
실시간 채팅 애플리케이션에서는 사용자들이 채팅 메시지를 발행하고 다른 사용자들이 해당 메시지를 구독하여 실시간으로 수신할 수 있다.
Pub/Sub 메커니즘은 실시간 채팅에 필수적인 구성 요소! -
데이터 구조 저장소: Redis는 문자열, 해시, 리스트, 셋, 정렬된 집합 등 다양한 데이터 구조를 지원.
실시간 채팅에서는 대화 기록을 저장하고 관리하는 데에 리스트나 정렬된 집합 등의 데이터 구조를 활용할 수 있다. -
높은 확장성: Redis는 클러스터링을 지원하여 애플리케이션의 확장성을 높일 수 있다.
클러스터링은 여러 대의 서버로 Redis를 분산시키고 데이터를 복제하여 처리량과 가용성을 향상시킴.
실시간 채팅 애플리케이션은 대량의 사용자 및 메시지 처리에 대한 확장성이 중요하기 때문에 Redis의 클러스터링 기능은 유용하다. -
지속성 옵션: Redis는 영구 저장을 위한 스냅샷 및 로그 기반의 백업 메커니즘을 제공 -> Redis가 다운되거나 재시작되는 경우에도 데이터를 보호 가능.
채팅 메시지 기록을 지속적으로 관리하고 복구할 수 있는데 도움이 된다.
- jwt로 통신 보안 강화 -> 검증된 토큰 보낸 클라이언트만 통신 가능하도록.
- 기존 stomp 핸들러에 토큰 유효성 체크 추가
- chatController에도 추가
- 기존 신규 채팅방 생성 시 -> 토픽 생성 후
<참고>
https://inpa.tistory.com/entry/REDIS-📚-PUBSUB-기능-소개-채팅-구독-알림
https://devoong2.tistory.com/entry/Springboot-Redis-테스트-환경-구축하기-Embedded-Redis-TestContainer
