-
[실시간 채팅 서비스#5] Kafka vs RabbitMQ 성능 비교 - 실시간 WebSocket 메시징 테스트개발 일지 2025. 4. 17. 16:01
실시간 채팅 시스템을 설계할 때 메시지 브로커로 어떤 기술을 선택할지는 굉장히 중요한 문제입니다. 이번 포스트에서는 실제 WebSocket 기반 채팅 시스템에서 Kafka와 RabbitMQ를 각각 메시지 브로커로 활용했을 때, 어떤 성능 차이가 발생하는지에 대해 실측 테스트를 통해 비교해보았습니다.
💡 테스트 개요
- 테스트 방식:
k6
를 활용한 사용자 시뮬레이션 - 시나리오:
- 유저가 채팅방에 입장
- WebSocket 연결
- STOMP
SUBSCRIBE
요청 - 서버에서 입장 이벤트 메시지를 Kafka/RabbitMQ에 발행
- 공통 환경
- 메시지 발행만 수행 (consume 없음)
- WebSocket 연결 시 메시지 지연 시간 측정
- Prometheus + Grafana로 모든 지표 시각화
⚙️ 테스트 시스템 아키텍처
📊 측정 지표 비교
지표 항목 Kafka RabbitMQ Message Publish Rate 0 → 27.0까지 점진적 상승 0 → 54까지 상승 후 감소 Throughput (Topic/Consumer) 최대 479 msg/min 유지 최대 4 msg/min 후 감소 WebSocket 메시지 전송 속도 최대 27.1 msg/sec 도달 최대 27.3 msg/sec 도달 WebSocket 평균 지연 시간 (초) 0.00157 → 0.00107로 감소 0.000267 → 0.000110로 감소 WebSocket 최대 지연 시간 (초) 2.9 sec 0.321 sec Thread 증가량 49 → 114 57 → 127 메시지 소비 여부 Consumer 오프셋이 감지됨 (추정) 메시지 소비 없음 (queue 누적 발생)
📈 그래프 해석
Kafka
- Publish Rate가 점진적으로 증가하면서도 WebSocket 전송량과 거의 유사하게 증가 → 브로커 처리량이 안정적
- Latency 피크(2.9초)는 메시지를 실제로 소비하는 Consumer가 없어서 브로커에 머무른 채 지연이 커진 것으로 보임
RabbitMQ
- Publish 수는 Kafka 대비 적지만, Latency 피크는 더 낮음 (0.321초) → 라우팅 최적화 영향 가능
- 메시지 소비 없음 → Queue에 메시지가 쌓이면서
Ready Messages
지표 급증 - Ack 없음 → 메시지 미소비 상태 명확
🧪 오해가 있었던 지점
초기에는 Kafka에서도 메시지를 소비하지 않은 것으로 판단했지만,
consumer group offset
이 남아있어 소비된 것처럼 지표가 왜곡된 것을 확인하였습니다.
이로 인해 Kafka의 Throughput이 과도하게 측정된 점도 고려해야 합니다.
🧠 결론
항목 Kafka RabbitMQ 고속 처리 성능 ✅ 고속 처리에서 유리 ⚠️ 비교적 낮음 메시지 보장 (queue) ❌ 기본적으로 queue 없음 ✅ 메시지 큐 보장, 보존 가능 Latency 제어 ⚠️ Consumer 없음 시 지연 발생 가능 ✅ 낮은 지연 유지 가능 복잡한 라우팅 처리 ❌ 제한적 ✅ Exchange/Binding 활용 가능 운영 복잡도 ✅ 대규모에 적합 ⚠️ 구성 유연하나 운영 주의 필요
🔚 마무리하며
이번 테스트는 단순한 입장 메시지 발행이라는 제한된 상황에서의 비교였습니다.
실제로는 메시지 소비 구조, 보존 전략, 라우팅 복잡도, 분산 처리 구조 등 다양한 요소에 따라 선택이 달라질 수 있습니다.이번 테스트는 시스템 요구사항에 맞는 메시지 브로커를 선택할 수 있는 역량을 쌓은 좋은 기회가 되었습니다.
'개발 일지' 카테고리의 다른 글
[실시간 채팅 서비스#4] API-Gateway (0) 2024.10.17 [실시간 채팅 서비스#3] WebSocket + STOMP + Pub/Sub으로 실시간 채팅 구현 (0) 2024.10.07 [실시간 채팅 서비스#0] 타임라인 (0) 2024.09.20 [실시간 채팅 서비스#2] 설계 (1) 2024.09.01 [실시간 채팅 서비스#1] 개인 프로젝트 시작 (0) 2024.08.21 - 테스트 방식: