채팅 서버 만들기 : 통신 구조 파악하기

🧭 전체 구조 요약 (채팅 시스템 예시 기준)

[클라이언트 브라우저]
    |
    | ① WebSocket 연결 (실시간 통신 채널)
    ↓
[Spring WebSocket 서버] ─────────────────────────────┬───────────────────────────┐
    |                                               |                           |
    | ② 메시지 수신                                   |                           |
    ↓                                               ↓                           ↓
[Message Broker]                             [MongoDB] (채팅 로그 저장)   [Redis] (세션 공유용)
(예: Kafka / Redis Streams / RabbitMQ)                                           
  └ 저장: 메시지 임시 보관 + 재전송
  └ 라우팅: 소비자 서버에 전달
  └ 보험: 서버 장애 시 메시지 손실 방지
    |
    | ③ 메시지 전달 (Consumer: 메시지 처리자)
    ↓
[Spring Consumer 서버] ──────┐
    |                       |
    |                       ↓
    |                 [MongoDB 저장]
    |
    ↓
[WebSocket을 통해 다른 유저에게 메시지 전송]

 

📌 각 컴포넌트 역할 요약

컴포넌트	역할
WebSocket	클라이언트와 서버 간 실시간 양방향 통신 채널
Spring 서버	WebSocket 관리 + 메시지 브로커로 메시지 전달
메시지 브로커	임시 저장 + 재전송 + 라우팅 + 장애 대응 역할(Kafka, Redis Streams, RabbitMQ 등)
MongoDB	채팅 로그 등 영구 저장소
Redis	세션 공유, pub/sub, 캐시 등 다양한 용도로 사용 가능
Consumer 서버	메시지를 꺼내서 처리하는 백엔드 작업 처리 담당자

🔄 데이터 흐름 순서 (채팅 예시)

1. 클라이언트가 WebSocket을 통해 메시지 전송
2. Spring 서버가 메시지를 받고, 메시지 브로커로 push
3. 브로커는 메시지를 임시 저장하고, Consumer에게 전달
4. Consumer가 메시지를 꺼내서 MongoDB에 저장 + ACK
5. 서버는 WebSocket으로 다른 유저에게 메시지 전달

 

🔐 보완 포인트

포인트	설명
WebSocket만 쓰면	세션 공유 어려움, 서버 죽으면 유실 가능
MongoDB만 쓰면	큐잉/재시도 불가, 타이밍 맞추기 어려움
브로커 도입 시	메시지 안전 확보, 재전송, 분산 처리, 느슨한 결합 가능

✅ [1] Kafka 기반 채팅 시스템 구조

 [클라이언트 브라우저]
        ⇅ 
  WebSocket 연결
        ↓
[Spring WebSocket 서버]
        └─▶ Kafka 토픽에 메시지 전송 (Producer 역할)
                        ↓
     ┌──────────── Kafka Broker ────────────┐
     │      메시지 임시 저장 (디스크 기반 로그)     │
     │       Consumer 그룹별로 메시지 분배       │
     └──────────────────────────────────────┘
                        ↓
     [Spring Kafka Consumer] (Consumer 역할)
          └─▶ MongoDB 저장 (채팅 로그, DB)
          └─▶ 다른 유저에게 WebSocket으로 메시지 전송

 

🔍 특징 요약

• Kafka는 고속 대용량 처리에 적합
• 토픽 단위로 구독, 여러 Consumer 그룹에서 병렬 처리 가능
• 메시지는 디스크에 저장됨, 유실 위험 낮음

✅ [2] Redis Streams 기반 채팅 시스템 구조

 [클라이언트 브라우저]
        ⇅ 
  WebSocket 연결
        ↓
[Spring WebSocket 서버]
    └─▶ Redis Streams에 메시지 XADD (Producer 역할)
                      ↓
     ┌────────── Redis Streams ──────────┐
     │    메시지를 Stream으로 저장 (ID 기반)   │
     │    Consumer Group으로 읽고 ACK 필요  │
     └───────────────────────────────────┘
                      ↓
       [Spring Redis Stream Consumer]
            └─▶ MongoDB 저장
            └─▶ 다른 유저에게 WebSocket 메시지 전송

 

🔍 특징 요약

• Redis 기반으로 빠르고 가볍게 운영 가능
• Kafka보다 세팅 간단, 메시지 ID/ACK 구조로 신뢰성 확보
• 메시지는 기본적으로 메모리에 저장되며, AOF 켜면 디스크 백업 가능

🎯 공통 핵심 흐름 요약

[WebSocket 클라이언트] ⇄ [Spring 서버] → [브로커] → [Consumer] → [MongoDB + WebSocket 재전송]

• WebSocket은 실시간 통신 채널
• 브로커는 중간 다리/버퍼/보험 역할
• MongoDB는 채팅 로그 등 영구 저장소
• Redis Streams/Kafka는 용량, 처리량, 신뢰도, 구조 복잡도에 따라 선택