메시징 시스템 비교: Kafka, Redis, 그리고 전통적 MQ

1. 서론

현대의 분산 시스템에서는 다양한 메시징 시스템이 존재하며, 각 시스템은 특정 요구사항에 따라 장점과 단점을 보입니다.
이 글에서는 대표적인 세 가지 메시징 솔루션—Kafka, Redis Pub/Sub, 그리고 전통적인 메시지 큐(RabbitMQ, ActiveMQ 등)를 비교하면서,
어떤 상황에서 어떤 시스템을 선택하는 것이 유리한지 실제 구현 예제와 테스트 결과를 통해 살펴보겠습니다.

---

2. 메시징 시스템 개요 및 특징

2.1 Kafka

• 특징 및 아키텍처:
  • 고처리량, 확장성, 내구성(영속적인 로그 저장)
  • 토픽, 파티션, 오프셋 관리 방식을 통해 메시지 순서와 병렬 처리를 효과적으로 지원
  • 단일 파티션 내에서는 메시지 순서가 보장됨 (동일 키 사용 시)
• 장점:
  • 대규모 데이터 스트림 처리에 적합
  • 높은 처리량과 확장성, 장애 발생 시 데이터 복구 용이
• 한계:
  • 초기 설정과 운영이 상대적으로 복잡할 수 있음
  • 실시간성이 중요하면서 메시지의 영속성이 반드시 필요하지 않은 경우 오버헤드가 있을 수 있음

2.2 Redis Pub/Sub

• 특징 및 아키텍처:
  • 메모리 기반의 빠른 실시간 메시징 기능 제공
  • Pub/Sub 모델을 사용해 단순하고 빠른 메시지 전달
  • 다양한 데이터 구조(List, Set, Hash, Sorted Set) 지원
• 장점:
  • 낮은 지연시간으로 빠른 응답 제공
  • 설정과 사용이 간편, 캐싱 기능과 결합하여 활용 가능
• 한계:
  • 메시지 영속성이 없어서 서버 재시작 시 데이터 소실
  • 다수의 생산자가 동시에 메시지를 발행할 경우 순서 보장이 어려울 수 있음

2.3 전통적 MQ (RabbitMQ, ActiveMQ 등)

• 특징 및 아키텍처:
  • 메시지 브로커를 통한 정교한 라우팅, 주제 기반 구독, 요청-응답 패턴 등 다양한 메시징 패턴 지원
  • 메시지 신뢰성(ack, 트랜잭션 지원) 보장
• 장점:
  • 복잡한 워크플로우와 신뢰성이 중요한 애플리케이션에 적합
  • 레거시 시스템과의 연동, JMS 표준 준수
• 한계:
  • Kafka에 비해 처리량 및 확장성에서 한계가 있을 수 있음
  • 시스템 설정과 운영이 상대적으로 복잡한 경우도 존재

---

3. 실제 구현 사례: Kafka vs Redis Pub/Sub

3.1 Kafka를 이용한 메시징 시스템

• 구현 예제:
  • Spring Boot 기반 Kafka Producer와 Consumer를 설정하고, 단일 파티션 내에서 동일한 키를 사용해 순서를 보장하는 구조
  • Producer가 /notify API를 통해 메시지를 발행하면, Consumer가 해당 토픽을 구독하고 메시지를 소비
• 테스트 결과:
  • 부하 테스트(예: Locust를 통한 다수의 동시 요청)에서 Kafka는 단일 파티션을 활용할 경우 메시지 순서가 잘 유지되는 것을 확인할 수 있음
  • 메시지의 영속성과 오프셋 관리 덕분에 메시지 순서와 재처리(재전송) 기능이 뛰어남

3.2 Redis Pub/Sub를 이용한 메시징 시스템

• 구현 예제:
  • Redis Pub/Sub 기능을 활용해 간단하게 메시지를 발행하고 구독하는 구조
  • 메시지는 빠르게 전송되지만, Redis 서버 재시작 시 데이터가 소실되며, 다수의 생산자 환경에서 순서 보장이 어려울 수 있음
• 테스트 결과:
  • 소규모, 실시간 알림이나 캐싱에 적합하며, 지연시간이 매우 짧음
  • 단일 생산자 환경에서는 순서가 어느 정도 유지되지만, 동시 다발적인 요청 상황에서는 순서 보장이 어려울 수 있음

---

4. Kafka와 WebSocket 연동: 실시간 알림 전달

4.1 시스템 구성

• Kafka Producer를 통해 메시지를 전송하고, Kafka Consumer가 해당 메시지를 수신
• 수신한 메시지를 WebSocket(STOMP)으로 프론트엔드에 전달하여 실시간 알림을 구현

4.2 구현 상세

• WebSocket 설정 (WebSocketConfig):
  STOMP 엔드포인트(/ws)와 메시지 브로커(/topic)를 설정하여 클라이언트와 서버 간의 실시간 연결 구축
• Kafka Consumer와 WebSocket 연동:
  Kafka Consumer가 메시지를 수신하면, SimpMessagingTemplate을 통해 "/topic/notifications" destination으로 메시지를 전송
• 프론트엔드:
  SockJS와 STOMP.js를 사용하여 WebSocket에 연결하고, "/topic/notifications"를 구독하여 화면에 메시지를 출력

4.3 장점 및 결과

• Kafka의 내구성과 순서 보장 기능 덕분에, 프론트엔드에 실시간 알림을 순서대로 전달할 수 있음
• Redis와 비교했을 때, 동시 다발적인 요청에서도 메시지 순서가 더 안정적으로 유지됨

---

5. 전통적 MQ의 사용 상황

• 메시징 패턴:
  복잡한 라우팅, 트랜잭션, 요청-응답 패턴이 중요한 경우에는 RabbitMQ, ActiveMQ 등이 적합
• 신뢰성:
  메시지의 확실한 전달과 재전송, 트랜잭션 지원이 필요한 애플리케이션에 유리함
• 연동:
  기존 JMS 기반 시스템이나 레거시 시스템과의 통합 시 전통적 MQ가 더 익숙하고 표준화된 솔루션 제공

---

6. 결론 및 학습 포인트

결론

• Kafka: 대규모 데이터 처리와 순서 보장이 중요한 경우 적합하며, WebSocket과 연동해 실시간 알림 시스템을 구현하는 데 매우 유리합니다.
• Redis Pub/Sub: 빠른 실시간 처리와 간단한 구현이 필요할 때 사용하지만, 메시지 영속성 및 순서 보장에는 한계가 있습니다.
• 전통적 MQ: 신뢰성, 트랜잭션, 복잡한 메시징 패턴이 요구되는 환경에서 적합하며, 레거시 시스템과의 연동 시 유리합니다.

학습 포인트

1. 메시징 시스템의 기본 개념 및 아키텍처 이해:
   각 시스템의 내부 동작 방식(토픽, 파티션, 오프셋, Pub/Sub 모델 등)
2. Spring Boot를 통한 실제 구현:
   Kafka, Redis, 전통적 MQ 각각의 Producer/Consumer 설정 방법
3. 실시간 알림 시스템 구성:
   Kafka와 WebSocket(STOMP)을 통합해 프론트엔드에 실시간으로 메시지를 전달하는 방법
4. 부하 테스트 및 운영:
   Locust 등 부하 테스트 도구를 통해 다수의 동시 요청 환경에서 시스템이 어떻게 동작하는지 분석
5. 실제 환경에 맞는 시스템 선택:
   요구사항에 따라 높은 처리량, 순서 보장, 신뢰성, 실시간성이 어떻게 달라지는지 비교 분석

---