RabbitMQ란

RabbitMQ와 Kafka

등장 배경

RabbitMQ가 등장한 이유 (2007년)

동기: 애플리케이션 간 통신을 안정적이고 유연하게 하자

1. 배경:

• 2000년대 초반, 웹 서비스 간 동기 호출(REST, SOAP 등)이 많았음
• 서비스 간 API 호출은 느리고, 실패하면 전체 시스템이 멈춤 (tight coupling)
• "느려도 되니까 메시지로 보내고 비동기로 처리하자"는 니즈가 생김
• ="중요하지 않거나, 지금 당장 처리하지 않아도 되는 일을 나중에 천천히 처리하자."

2. RabbitMQ의 목적:

• 서비스 간 메시지를 안정적으로 중계 (메시지 브로커)
• 비동기 처리, 재시도, 메시지 우선순위 등 다양한 큐 기능 지원
• AMQP 프로토콜 기반으로 신뢰성과 범용성을 추구

3. RabbitMQ는 이런 문제 해결에 초점:

• 주문 완료 후 문자 발송, 포인트 적립 등 비동기 워크플로우
• 메시지 유실 없이 처리하고, 실패하면 재시도
• 다수의 Producer/Consumer 간 중재자 역할

Kafka가 등장한 이유 (2011년)

동기: 대용량 데이터 스트림을 빠르게 저장하고 분석하자

1. 배경:

• LinkedIn 같은 대형 서비스는 유저 행동 로그, 클릭, 뷰 데이터가 초당 수십만 건
• 기존 MQ(RabbitMQ 포함)는 느리고 유실 우려 있음(RabbitMQ는 메시지를한 번 소비하면 삭제됨)
  → 대규모 트래픽(초당 수십만~백만 건)에서는 병목 현상이 생김
• “이벤트(메시지)를 순서대로 다 저장하고(로그처럼), 필요한 시스템이 알아서 가져가게 하자”

2. Kafka의 목적:

• 엄청난 양의 데이터를 빠르게 수집하고 유지
• 메시지를 삭제하지 않고, 로그처럼 저장
• 여러 시스템이 다른 시점에 메시지를 읽을 수 있음(다시 읽기, 재처리, 리플레이가 가능)
• 고성능 스트리밍 처리, 실시간 분석, 이벤트 소싱 등에 강력

3. Kafka는 이런 문제 해결에 초점:

• 유저 행동 로그, 실시간 통계, 광고 분석
• 장애 회복력 높은 대용량 데이터 파이프라인
• 여러 시스템이 하나의 이벤트를 다르게 처리해야 할 때 (fan-out 구조)

요약 비교

항목	RabbitMQ	Kafka
등장 시기	2007 (AMQP 구현)	2011 (LinkedIn)
핵심 문제	느린 서비스 통신 → 비동기 큐로 해결	초고속 로그 수집/분석 시스템 필요
중심 철학	확실히 처리하자	빠르고 오래 저장하자
처리 방식	메시지 큐 (읽으면 삭제)	로그 저장소 (읽어도 남김)
설계 목적	안정적 전달, 다양한 큐 기능	초고성능, 로그 기반 이벤트 처리

 

결론

• RabbitMQ는 "기능이 다양한 큐 시스템"을 원해서 만들어짐.
• Kafka는 "초당 수십만 건 이상 쏟아지는 로그나 이벤트를 잃지 않고 저장하고, 분석하려고" 만들어졌음.

프로젝트에서 “한 번 읽고 지워도 되는 메시지”만 다룬다면 RabbitMQ가 적절하고,
“모든 이벤트를 나중에도 여러 번 처리하거나 분석하려는 목적”이 있다면 Kafka가 더 어울린다. 둘을 함께 쓰는 구조도 있음.

 

※ RabbitMQ를 Kafka 대신 선택하는 이유

항목	설명
단순하고 직관적인 구조	MQ 개념에 익숙한 개발자라면 빠르게 도입 가능 (큐, 라우팅, 교환기 등 직관적)
개발/운영이 쉬움	Kafka는 Zookeeper, 토픽 파티션 구성 등 복잡함. RabbitMQ는 설치도 간단하고 관리 쉬움
풍부한 라우팅 기능	Direct, Fanout, Topic, Header 등 다양한 메시지 전달 방식 지원 (Kafka는 Topic 기반 단순 구조)
짧은 메시지 보관에 적합	메시지를 오래 보관하지 않아도 되는 구조에 적합 (읽고 삭제되는 방식)
응답이 빠르고 지연이 적음	수 ms 단위의 빠른 응답 – 실시간 알림, 요청-응답 패턴 등에 좋음
낮은 처리량에도 효율적	Kafka는 너무 무거울 수 있음. 단순한 서비스라면 RabbitMQ가 오히려 딱 맞음
메시지 보장 정책 다양	Ack, Retry, DLQ(Dead Letter Queue) 등 정교한 실패 처리
다양한 프로토콜 지원	AMQP, MQTT, STOMP 등 – IoT, 모바일, 레거시 시스템과 호환성 좋음
테스트 및 디버깅 쉬움	대시보드에서 메시지 확인, 재전송 가능. Kafka는 CLI 기반이 많고 러닝커브 있음

 

 

향후 프로젝트 구성

최상위 인프라 관리 계층 : 쿠버네티스(Kubernetes)

내부 구성 예시

구성요소	설명
Frontend	React 앱 → 쿠버네티스에 Deployment + Service + Ingress
Backend	리뷰 작성 API 서버 (Spring, Node 등) → Pod으로 관리
MQ	RabbitMQ 또는 Kafka (비동기 메시징) → StatefulSet 또는 Helm
DB	PostgreSQL, MySQL, MongoDB 등 → StatefulSet + PVC
Mail Service	환영 메일 등 → Consumer로 따로 배포
Elasticsearch	리뷰 검색용 → 클러스터로 구성 가능
Prometheus/Grafana	모니터링
Secret	DB 비밀번호, API 키 등

 

왜 Kubernetes가 최상위 관리 계층인가?

기능	설명
배포 자동화	kubectl apply 또는 Helm으로 한 번에
장애 복구	Pod 죽으면 자동 재생성
자동 확장	CPU/메모리 기준 수평 확장 가능 (HPA)
보안 관리	Secret, ConfigMap
트래픽 제어	Ingress로 도메인/SSL 연결
스테이트풀 구성	DB나 MQ 같은 상태 저장 서비스도 관리 가능

 

쿠버네티스는 인프라의 관제탑 + 자동화 관리자(통합 운영하는 본사 총괄),

React, Spring, RabbitMQ는 각 부서로 비유할 수 있음.