WebSocket 채팅, 왜 MongoDB와 Redis를 함께 쓰는가?

결론부터 말하자면 "MongoDB로 영구 저장 + Redis로 실시간 동기화"를 위해서이다.

채팅 서버를 개발할 때 스프링 WebSocket만 사용하면 충분하지 않을까라는 생각을 했다.
가능해 보이지만, 실제 서비스에서 몇 가지 치명적인 문제가 발생할 수 있다.

1️⃣ 스프링 WebSocket만 사용할 때 발생하는 문제점

(1) 서버가 재시작되면 채팅 기록이 사라짐
WebSocket은 기본적으로 메모리 세션 방식을 사용한다.
즉, 서버를 재시작하거나 장애가 발생하면 채팅 데이터가 사라진다.

✅ 해결 방법:

채팅 데이터를 DB에 저장하여 영구적으로 보관해야 한다.
빠른 성능을 고려하여 MongoDB 같은 NoSQL DB를 사용하면 적절하다.

(2) 서버가 여러 대일 경우 채팅 데이터가 공유되지 않음
서버가 1대만 있다면 문제 없음 (모든 사용자가 같은 서버에 접속)
하지만 서버가 여러 대라면?
A 유저는 1번 서버에 접속
B 유저는 2번 서버에 접속
👉 A가 보낸 메시지를 B가 받을 수 없음

✅ 해결 방법:

서버 간 메시지를 공유할 수 있도록 "Message Queue"를 도입해야 한다.
대표적인 MQ(Message Queue)로는 Kafka와 Redis Pub/Sub이 있다.

2️⃣ 문제 해결을 위한 솔루션 (DB + Message Queue 도입)

✅ (1) 채팅 데이터를 저장할 DB 선택 (MongoDB)
💡 왜 MongoDB를 선택해야 할까?
데이터를 디스크에 저장하고, 복제(replication) 기능을 지원하기 때문!

✅ MongoDB가 서버 장애에도 데이터를 유지할 수 있는 이유

데이터를 디스크에 저장하여, 서버가 꺼져도 데이터가 사라지지 않음.
Replication(복제) 기능을 제공하여, 장애 발생 시에도 데이터를 보호할 수 있음.
Primary → Secondary로 자동 복제
Primary 장애 시 Secondary가 자동 승격
NoSQL 방식이라 빠르고 유연하게 데이터 저장 가능
빠른 읽기/쓰기 성능
JSON(Document) 기반이라 구조가 직관적
즉, MongoDB를 사용하면 서버 재시작 후에도 채팅 기록이 유지됨

✅ (2) 서버 간 메시지를 공유할 Message Queue 선택
💡 Kafka vs Redis Pub/Sub 비교

즉, 서비스 특성에 따라 선택해야 한다!

✅ Kafka가 적합한 경우:

메시지 순서가 중요한 서비스 (카카오톡, 라인)
데이터 유실 없이 모든 메시지를 저장해야 하는 경우
느려도 안정성이 중요한 경우

✅ Redis Pub/Sub이 적합한 경우:

실시간 반응 속도가 중요한 서비스 (디스코드, 줌, 라이브 스트리밍)
메시지 순서가 중요하지 않은 경우
중간에 메시지 유실이 되어도 큰 문제가 없는 경우

3️⃣ 최종 결론: 채팅 서버를 위한 아키텍처 설계

✅ 채팅 데이터를 DB(MongoDB)에 저장하여 영구 보관
✅ 서버 간 메시지 공유를 위해 Kafka 또는 Redis Pub/Sub 사용
✅ 서비스의 특성에 맞는 Message Queue 선택

메시지 순서 보장이 중요하면 Kafka
속도가 중요하면 Redis Pub/Sub

정리

1️⃣ 스프링 WebSocket만 사용하면 서버 재시작 시 채팅 기록이 사라지고, 서버가 여러 대일 경우 메시지가 공유되지 않음
2️⃣ MongoDB를 사용하여 채팅 데이터를 저장하면 서버 장애가 발생해도 데이터가 유지됨 (디스크 저장 + 복제 기능 덕분!)
3️⃣ Kafka 또는 Redis Pub/Sub을 사용하여 여러 서버 간 메시지를 공유할 수 있음
4️⃣ 서비스 특성에 따라 Kafka(안정성) 또는 Redis(빠른 속도)를 선택하면 된다