[식구하자_MSA] 🚀 채팅, 알림 마이크로 서비스 개발을 위한 기술 선택: STOMP, Kafka, MongoDB, SSE - 1편

지난 포스팅(Spring Cloud Eureka, Gateway를 통한 인증/인가 처리)에 이어 드디어 마이크로서비스중 하나인 채팅 서비스를 개발하기에 앞서 선택한 기술들에 대해 깊이 있게 알아보고, 왜 이런 선택을 했는지 함께 살펴보겠습니다. (저는 Spring Cloud Eureka, Gateway를 통한 인증/인가 처리 이후 Spring Cloud BUS를 이용한 설정 정보 서버 개발을 진행했는데, 제가 이전에 작성한 포스팅이 있어 따로 해당 과정은 포스팅하지 않겠습니다. 아래 링크 참조해주세요!)

👉👉 Spring Cloud (Cloud bus,RabbitMQ 이용한 Config 정보 반영)

📚 목차

1. STOMP란?
2. WebSocket만으로는 부족한 이유
3. STOMP 메시지 브로커의 필요성
4. Kafka vs RabbitMQ: 메시지 브로커 선택
5. 채팅 데이터 저장: MongoDB vs MySQL
6. SSE(Server-Sent Events)란?
7. 알림 기능에 SSE를 선택한 이유

1. STOMP란?

STOMP(Simple Text Oriented Messaging Protocol)는 간단하면서도 강력한 텍스트 기반 메시징 프로토콜입니다. 🌈

STOMP의 주요 특징:

• 간단한 텍스트 기반 명령어: CONNECT, SUBSCRIBE, SEND 등
• 메시지 브로커 사용: 효율적인 메시지 라우팅
• 프레임 구조: 명확한 명령과 데이터 구분
• 발행/구독 모델 지원: 유연한 메시지 전달 구조

💡 왜 STOMP를 선택했나요?

1. 외부 브로커 활용: 여러 서버 간 효율적인 메시지 관리
2. 간편한 라우팅: @Controller와 @MessageMapping을 이용한 쉬운 메시지 처리
3. 표준화된 프로토콜: 다양한 언어와 플랫폼 간 호환성

2. WebSocket만으로는 부족한 이유

WebSocket은 실시간 양방향 통신을 가능하게 하지만, 채팅 서비스에는 몇 가지 한계가 있습니다:

1. 메시지 형식 정의 부재: WebSocket은 메시지 구조를 정의하지 않아 추가 작업 필요
2. 복잡한 라우팅: 각 연결마다 개별적인 핸들러 관리 필요
3. 세션 관리의 어려움: 채팅방별 접속자 정보를 수동으로 관리해야 함

STOMP는 이러한 문제를 해결하며, 더 구조화된 채팅 시스템 구현을 가능하게 합니다. 🛠️

3. STOMP 메시지 브로커의 필요성

STOMP의 메시지 브로커는 채팅 시스템의 핵심 역할을 담당합니다:

• 효율적인 메시지 라우팅: 구독자에게 정확하게 메시지 전달
• 채팅방 관리 간소화: 구독 기반으로 자동 메시지 전달
• 확장성 향상: 다수의 클라이언트 처리 용이

그러나 STOMP 내장 브로커만으로는 한계가 있어, 추가적인 솔루션이 필요했습니다. 🤔

4. Kafka vs RabbitMQ: 메시지 브로커 선택

Kafka를 선택했습니다! 그 이유는:

1. 높은 확장성:
   • 쉬운 브로커 추가
   • 파티셔닝을 통한 병렬 처리
2. 데이터 안정성:
   • 디스크에 지속적 메시지 저장
   • 데이터 복제로 유실 위험 최소화
3. 대용량 처리: 대규모 실시간 메시징에 최적화

RabbitMQ도 좋은 선택이지만, 식구하자 프로젝트의 규모와 확장성을 고려할 때 Kafka가 더 적합했습니다. 🚀

5. 채팅 데이터 저장: MongoDB vs MySQL

채팅 데이터 저장소로 MongoDB를 선택한 이유:

1. 비정형 데이터 처리: 채팅 내용의 다양한 형식 수용(ex) 이모티콘)
2. 빠른 읽기/쓰기: 실시간 채팅에 필수적인 고성능
3. 확장성: 대용량 데이터 처리에 유리
4. 유연한 스키마: 채팅 기능 확장 시 용이(ex) 샤딩)

MySQL도 좋은 선택지이지만, 채팅 서비스의 특성상 MongoDB가 더 적합하다고 판단했습니다. 📊

6. SSE(Server-Sent-Events)

이후에 채팅 알림 기능을 구현해야할 SSE에 대해서 알아보도록 하겠습니다.

SSE는 서버와 한번 연결을 맺고 나면, 일정 시간 동안 서버에서 변경이 발생할 때마다 서버에서 클라이언트로 데이터를 전송하는 방법입니다.

과정은 다음과 같습니다.

1. 클라이언트는 서버를 구독한다.(SSE Connection을 맺는다.)
2. 서버는 변동사항이 생길 때마다 구독한 클라이언트들에게 데이터를 전송한다.

SSE는 상황에 따라서 응답마다 다시 요청을 해야 하는 Long Polling 방식보다 효율적입니다. SSE는 서버에서 클라이언트로 text message를 보내는 브라우저 기반 웹 애플리케이션 기술이며 HTTP의 persistent connections을 기반으로 하는 HTML5 표준 기술입니다.

하지만 HTTP를 통한 SSE(HTTP/2가 아닐 경우)는 브라우저 당 6개의 연결로 제한되므로, 사용자가 웹 사이트의 여러 탭을 열면 첫 6개의 탭 이후에는 SSE가 작동하지 않는다는 단점도 있긴 합니다. (HTTP/2에서는 100개까지의 접속을 허용합니다.)

하지만 전반적으로 SSE는 클라이언트가 서버와 크게 통신할 필요 없이 단지 업데이트된 데이터만 받아야 하는 실시간 데이터 스트림에 대한 구현이 필요할 때는 매우 훌륭한 선택입니다.

7. 알림 기능에 SSE를 선택한 이유

알림 기능 구현에 SSE를 선택한 이유:

1. 리소스 효율성: 폴링 방식보다 서버 부하 감소
2. 실시간성: 즉각적인 알림 전달 가능
3. 단순성: WebSocket보다 구현과 관리가 용이
4. 브라우저 지원: 대부분의 최신 브라우저에서 지원

WebSocket도 고려했지만, 알림의 단방향 특성을 고려할 때 SSE가 더 적합했습니다. 🔔

---

참고

https://velog.io/@mw310/Stomp-WebSocket-%EA%B0%9C%EB%85%90-%EC%A0%95%EB%A6%ACver-Spring
https://dkswnkk.tistory.com/702
https://velog.io/@ch4570/Stomp-Kafka%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%9C-%EC%B1%84%ED%8C%85-%EA%B8%B0%EB%8A%A5-%EA%B0%9C%EB%B0%9C%ED%95%98%EA%B8%B0-with-Spring-Boot-1-Kafka%EC%99%80-Stomp%EB%8A%94-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
https://igotanoffer.com/blogs/tech/polling-sse-websockets-system-design-interview
https://jinjinyang.tistory.com/59