RabbitMQ vs Kafka 과 알림 서버 분리에 따른 메세지 큐 반영 고민

📚 RabbitMQ

특징

• 프로토콜: AMQP (표준 메시징 프로토콜 지원)
• 메시지 전달: Push 모델 기반. 브로커가 소비자에게 메시지를 적극적으로 전달.
• 큐 중심 설계: 메시지가 큐에 저장되고, 소비자가 이를 처리하는 전통적인 방식. 메시지 삭제는 소비자가 처리 후 ACK(확인 응답)를 보내면 이루어짐.
• 라우팅: Exchange를 통해 Direct, Topic, Fanout, Headers 방식으로 유연하게 메시지 라우팅 가능.
• 구성: 단일 노드에서 동작 가능하며, 클러스터링 지원은 있지만 Kafka만큼 분산 시스템에 특화되지 않음.
  메시지 보장: 메시지 확인 및 재전송 메커니즘으로 높은 신뢰성 제공한다.

사용 사례

• 작업 큐 관리: 예를 들어, 사용자 등록 후 환영 이메일 전송, 이미지 변환 작업 등 비동기 작업 처리.
• 실시간 알림: 채팅 앱의 메시지 전달, 웹소켓 기반 푸시 알림.
• 마이크로서비스 통신: 서비스 간 간단한 요청-응답 패턴에서 메시지 교환.

장점

• 직관적인 설정: 관리 UI 제공, 설치 및 운영이 비교적 간단.
• 언어 호환성: Python, Java, Node.js 등 다양한 언어의 클라이언트 라이브러리 지원.
• 소규모 적합: 초당 수백~수천 메시지 처리에 적합.
• 유연한 라우팅: 복잡한 메시지 배달 규칙을 쉽게 구현 가능.

단점

• 성능 한계: 초당 수십만 메시지 이상의 대규모 트래픽에서는 병목 발생 가능.
• 확장성 제한: 클러스터링은 가능하지만, Kafka처럼 대규모 분산 시스템에 비해 효율성 낮음.
• 복잡한 스트리밍 부적합: 데이터 스트림 처리보다는 개별 메시지 처리에 초점.

---

📚 Kafka

 

특징

• 프로토콜: 자체 바이너리 TCP 프로토콜 사용, 경량화 및 고성능에 초점.
• 메시지 전달: Pull 모델 기반. 소비자가 필요할 때 메시지를 가져오는 방식으로, 소비자 속도에 따라 유연하게 처리 가능.
• 로그 중심 설계: 메시지를 분산 로그 형태로 저장하며, 소비자가 과거 데이터를 다시 읽을 수 있음(보존 기간 설정 가능)
• 파티셔닝: 토픽을 여러 파티션으로 나누어 병렬 처리 및 확장성 극대화.
• 고가용성: ZooKeeper와 함께 클러스터링을 통해 장애 복구 및 데이터 복제 지원.
• 처리량: 초당 수백만 메시지 처리 가능.

 

사용 사례

• 이벤트 스트리밍: 웹사이트 사용자 행동 로그 실시간 분석, IoT 디바이스 데이터 수집.
• 데이터 파이프라인: 데이터베이스 변경 사항 캡처(CDC), ETL(Extract, Transform, Load) 프로세스.
• 대규모 알림 시스템: SNS 플랫폼의 알림 전송, 광고 클릭 데이터 처리.

장점

• 높은 처리량: 대규모 트래픽에서도 안정적인 성능(예: 초당 100만 메시지 이상).
• 영구 저장: 메시지를 디스크에 저장하여 재처리 가능(보존 기간 설정 가능, 기본 7일).
• 확장성: 파티션과 클러스터를 통해 수평 확장 용이.
• 에코시스템: Apache Spark, Flink, Storm 등 데이터 스트리밍 도구와 통합 가능.

단점

• 복잡한 운영: ZooKeeper 의존성, 클러스터 관리 필요로 초기 설정 및 유지보수 비용 높음.
• 리소스 소모: 소규모 시스템에서는 과도한 메모리/디스크 사용 가능.
• 메시지 순서 보장 제한: 파티션 내에서만 순서 보장, 전체 토픽 수준에서는 보장 안 됨.

---

비교 요약

항목	RabbitMQ	Kafka
모델	Push	Pull
주요 초점	큐 기반 메시지 전달	분산 로그 기반 스트리밍
처리량	중소규모(수천~수만/초)	대규모(수십만~수백만/초)
설정 난이도	쉬움	복잡
확장성	제한적	뛰어남
사용 사례	작업 큐, 간단한 알림	스트리밍, 대규모 데이터 처리

 

📚 알림서버 도입 고민

프로젝트 규모상 알림의 복잡도가 크지 않고 처리량이 제한적이기 때문에 구조가 단순하고 설정이 쉬운 RabbitMQ 가 더 적합하다고 판단했다.

하지만 필자는 메세지 보존, 재처리, 대규모 동시 알림 처리 등 Kafka 의 강점들을 직접 경험해보고자, 특히 Kafka 는 메세지를 디스크에 저장하고 offset 기반으로 소비를 관리하기 때문에 유저가 오프라인일 경우에도 알림을 잃지 않고 복구할 수 있다는 점에서 활용해보고 싶었기 때문에 Kafka 도입을 선택했다.

 

---

📚 Kafka 용어 정리

 

• Broker: Kafka 메시지를 저장하고 클라이언트 요청을 처리하는 서버 (Kafka 서버 단위).
• Topic: 메시지를 분류하는 단위, 발행자(Publisher)와 구독자(Consumer) 간 통신 경로.
• Producer: 메시지를 Kafka Topic에 발행(전송)하는 역할.
• Consumer: Kafka Topic에서 메시지를 구독(읽기)하는 역할.
• Partition: Topic을 물리적으로 분할한 단위, 병렬 처리와 확장성에 도움을 줌.
  • Partition 이 병렬 처리에 도움이 되는 이유:
    • 하나의 파티션은 하나의 메세지 큐 처럼 작동한다. 파티션이 1개면 메세지 소비가 직렬로만 일어나지만, 파티션이 여러 개면 각각 동시에 병렬로 처리를 할 수 있다. 각 하나의 Partition 은 하나의 Consumer 만 읽을 수 있기 때문에 동시에 처리가 가능하게 된다.
  • 그럼 Partition 을 무조건 많이 만들면 좋나?
    • Kafka 는 각 Partiton 마다 메타데이터와 파일 시스템 리소스를 관리하기 때문에 Partition 이 많아질수록 메모리 사용량, I/O, 네트워크 리소스 소비 증가에 따라 브로커에 부담이 간다.
    • 많이 만들면 병렬처리에는 도움이 되지만 리소스 낭비, 복제 비용, 관리 복잡도, 순서 보장 문제가 생기기 때문에 모니터링을 하면서 조정을 해야한다.
• Offset: 각 Partition 내에서 메시지의 고유 순서 번호, 메시지 위치 추적에 사용됨.
• Consumer Group: 여러 Consumer가 협력하여 메시지를 병렬로 소비하는 그룹 단위.
• ZooKeeper (구버전 기준): Kafka 클러스터의 메타데이터와 브로커 상태를 관리.
• Retention: 메시지를 Kafka에 저장해두는 기간, 시간이 지나면 삭제됨.
• Replication: 메시지를 여러 Broker에 복제해 장애 발생 시 데이터 유실을 방지하는 기능.