메시지 큐, RabbitMQ, Kafka 개념

메세지란?

• 메시지(Message)는 정보를 전달하기 위한 데이터 단위

메세지큐란 ? 

• 'Non-Blocking I/O 기반의 비동기화 미들웨어로, Producer와 Consumer를 분리하고 Queue에 이벤트를 임시 저장하여 비동기 메시징을 구현.'

 

메시지 큐의 기본 개념

• Producer(생산자): 메시지를 생성하여 큐에 삽입하는 역할
• Consumer(소비자): 큐에서 메시지를 꺼내 처리하는 역할
• Broker(중개자): 메시지를 큐에 저장하고 전달하는 메시징 시스템 (예: RabbitMQ, Kafka, Redis Pub/Sub)

 

메시지 큐 도입이유

메시지 큐를 활용하여 내재된 동기기능을 외부화하고, 비동기 병렬처리를 통해 부하를 분산하며, I/O Block 방지하여 자원을 효율적으로 사용할 수 있음

  동기적으로 다른 서버에  요청을 보내면 과부하나 오류가 발생할 수 있음. 메시지 큐가 있으면 장애가 발생한 서버는 메시지를 소비하지 않으므로, 요청은 정상적인 서버가 처리할 수 있을 때까지 큐에 보관됩니다. 이를 통해 한 서버의 장애가 다른 서비스로 전파되지 않습니다.

도입이유	설명	예제
비동기 처리	요청 후 기다릴 필요 없으므로 CPU와 I/O 자원을 효율적으로 활용	이메일 발송, 주문 처리
장애 격리 (Fault Tolerance)	시스템 일부가 다운되어도 메시지가 유지됨	장애 발생 시 데이터 손실 방지
기능확장	메시지 큐를 통해 새로운 Consumer를 추가하여 시스템을 수평 확장 가능	새로운 알림 채널 추가

메세지큐 단점

단점	설명	해결방법
일관성 문제 발생 가능	메시지 큐 기반 비동기 시스템에서는 처리 순서 보장이 어려워 데이터 정합성이 깨질 수 있음	트랜잭션 처리, 메시지 상태 관리 추가
메시지 순서 보장 어려움	여러 개의 Consumer가 병렬로 메시지를 처리하면 순서가 바뀔 수 있음	메시지 FIFO 큐 또는 메시지 내 타임스탬프 활용

메시지 큐에서 사용하는 논블로킹 프로토콜

메시지 큐가 논블로킹을 지원하는 이유는 사용하는 프로토콜 자체가 비동기 통신을 위해 설계되었기 때문입니다.

메시지 큐 시스템	사용 프로토콜	논블로킹 방식
Kafka	TCP 기반, 자체 프로토콜	Consumer Polling, Async Producer
RabbitMQ	AMQP (Advanced Message Queuing Protocol)	Pub/Sub, Push 방식
Redis Pub/Sub	TCP 기반, RESP 프로토콜	비동기 이벤트 기반
AWS SQS	HTTP 기반 (Long Polling)	Polling 방식, Auto Scaling

 

메시지 큐의 통신 방식비교

① Point-to-Point (P2P) 방식

• 메시지가 하나의 큐에 저장되고, 한 개의 소비자만 해당 메시지를 가져감
• 특징:
  • 하나의 메시지가 하나의 소비자에게만 전달됨 (1:1 통신)
  • 메시지가 소비된 후 큐에서 삭제됨
  • 사용 예시: 주문 처리 시스템 (한 번만 처리되어야 하는 요청)

🛠 사용 예시: RabbitMQ의 Work Queue 패턴

 

② Publish-Subscribe (Pub/Sub) 방식

• 하나의 메시지를 여러 소비자가 동시에 받을 수 있음 (1:N 통신)
• 프로듀서는 특정 토픽(Topic) 에 메시지를 발행(Publish)하고, 구독자(Subscriber)는 관심 있는 토픽을 구독(Subscribe)하여 메시지를 받음
• 사용 예시: 실시간 알림 시스템 (하나의 이벤트를 여러 곳에서 받아야 할 때)

🛠 사용 예시: Kafka의 Topic 기반 메시징

 

 

Kafka Rabit MQ 비교

• RabbitMQ: Queue(큐) 기반 메시징
  • 메시지가 Queue에 저장되었다가 소비되면 삭제됨 (1회성 메시징)
  • P2P(1:1) 및 Pub/Sub(1:N) 방식 지원
  • Exchange → Queue → Consumer 구조
• Kafka: 로그 기반 메시징
  • 메시지가 Partition 단위로 저장되고, 여러 Consumer가 읽을 수 있음
  • 메시지가 사라지지 않고 일정 기간 저장됨
  • Pub/Sub(1:N) 구조 최적화 (멀티 컨슈머 그룹 지원)

• RabbitMQ: Push 방식 (Broker가 Consumer에게 메시지 전달)
  • 메시지가 Consumer에게 즉시 전달됨 (Consumer가 느리면 문제 발생)
  • Consumer 처리 속도에 따라 Backpressure(과부하) 문제 발생 가능
• Kafka: Pull 방식 (Consumer가 메시지를 가져감)
  • 소비자가 주기적으로 메시지 큐를 확인(polling)하면서 새로운 메시지가 있는지 체크.
    • 모든 Consumer가 같은 메시지를 받는 게 아니라, 각 Consumer Group마다 다른 메시지를 받아야 함. 그러므로  각 Consumer가 필요한 메시지만 poll() 해서 가져가도록 설계!
    • Kafka가 소비자 그룹(Consumer Group)마다 별도의 큐를 두지 않고 Polling 방식을 선택한 이유는 확장성과 성능을 극대화하기 위해서입니다.즉, 소비자 그룹마다 큐를 따로 만들면 Kafka의 장점(확장성, 성능, 메시지 처리량)이 사라지기 때문입니다.
  • Consumer가 스스로 메시지를 가져오기 때문에 속도 조절 가능
  • 대량의 데이터를 효율적으로 처리할 수 있음

 

RabbitMQ와 Kafka의 근본적인 차이

둘의 차이는 메시지 저장 방식과 소비 방식에서 발생합니다.

비교 항목🐇 RabbitMQ (Queue)🦁 Kafka (Log)

설계 철학	메시지를 전달하고 즉시 삭제	메시지를 로그(파일)로 저장
메시지 소비 방식	Push 방식 (Broker가 Consumer에게 전달)	Pull 방식 (Consumer가 Broker에서 직접 가져감)
메시지 보관 기간	메시지를 처리 후 즉시 삭제 (Queue 특성)	디스크에 저장하여 일정 기간 보관
다중 소비 가능 여부	하나의 메시지는 한 Consumer만 읽음 (P2P)	하나의 메시지를 여러 Consumer가 독립적으로 읽을 수 있음
확장성	단일 Queue가 Consumer에 의해 소모됨 → 확장성이 낮음	Partition 구조로 메시지를 분산 저장 → 대규모 확장 가능

 

 

 

 

🔥 2. RabbitMQ는 왜 즉시 메시지를 삭제할까?

RabbitMQ는 **메시지 브로커(Message Broker)**로, 트랜잭션성 메시지 처리에 초점을 맞춘 구조입니다.

✅ RabbitMQ의 동작 방식

1. **Producer(생산자)**가 메시지를 Exchange로 보냄
2. Exchange가 적절한 Queue로 라우팅
3. Queue에서 **Consumer(소비자)**가 메시지를 가져가 처리
4. 메시지가 처리되면 Queue에서 즉시 삭제됨 (메모리 절약)

💡 왜 삭제될까?

• RabbitMQ는 메시지 전송이 목적이지, 데이터를 저장하는 것이 목적이 아님
• 메시지가 Queue에 오래 남아있을 필요가 없음 → 빠르게 처리 후 삭제
• 트랜잭션 처리 (주문, 결제)에서는 한 번만 처리되는 것이 중요 → 중복 소비 방지

📌 RabbitMQ의 장점

• 빠른 메시지 전달 (Push 방식) → 실시간 처리에 적합
• 메시지가 즉시 삭제되므로 메모리 사용량이 낮음
• 트랜잭션 보장이 가능 (ex. 결제 시스템에서 메시지를 중복 소비하면 안됨)

📌 RabbitMQ가 유리한 예시

• 결제 시스템: "결제 완료" 메시지가 중복 처리되면 안됨 → 1회성 처리 후 삭제
• 비동기 작업: 이메일 발송, 주문 확인 → 메시지를 전달하면 끝

---

🔥 3. Kafka는 왜 메시지를 보관할까?

Kafka는 **이벤트 스트리밍(Event Streaming)**에 초점을 맞춘 구조입니다.

✅ Kafka의 동작 방식

1. Producer가 메시지를 특정 Topic에 발행
2. 메시지가 Partition 단위로 디스크에 저장됨
3. Consumer가 필요할 때 메시지를 읽음 (Pull 방식)
4. 메시지가 삭제되지 않고, 여러 Consumer가 같은 메시지를 읽을 수 있음

💡 왜 저장할까?

• Kafka의 목적은 데이터 전송이 아니라 "이벤트 로그 저장"
• 여러 Consumer가 같은 데이터를 독립적으로 사용할 수 있음
• 재처리 가능 → 장애 발생 시 동일한 메시지를 다시 읽을 수 있음
• 대량 데이터 처리 가능 → 수백만 TPS 처리 가능

📌 Kafka의 장점

• 메시지 재처리 가능 (장애 복구, 데이터 분석에 유리)
• 여러 Consumer가 같은 데이터를 읽을 수 있음 (데이터 공유 용이)
• 대규모 확장성 (Partition 구조로 무한 확장 가능)

📌 Kafka가 유리한 예시

• 로그 수집: 서버에서 발생하는 모든 로그를 저장하고 분석
• 실시간 데이터 분석: IoT 센서 데이터 수집 후 여러 Consumer가 가공
• 이벤트 스트리밍: 주문 이벤트가 발생하면 결제/배송/추천 서비스가 모두 같은 이벤트를 활용 가능

 

🎯 4. RabbitMQ vs Kafka 결론

🚀 RabbitMQ를 선택해야 하는 경우

1. 실시간 처리가 필요할 때
   • 주문, 결제, 알림 등 즉시 소비해야 하는 메시지
2. 트랜잭션 메시징이 필요할 때
   • 한 번만 처리해야 하는 경우 (중복 방지)
3. 비동기 작업 큐가 필요할 때
   • 이메일 전송, PDF 생성, 배치 작업 등

 

🚀 Kafka를 선택해야 하는 경우

1. 대량의 데이터를 처리해야 할 때
   • 실시간 로그 분석, 빅데이터 처리, 이벤트 스트리밍
2. 메시지를 여러 개의 Consumer가 동시에 읽어야 할 때
   • 하나의 주문 데이터를 분석, 배송, 추천 시스템에서 각각 활용
3. 메시지 재처리가 필요할 때
   • 장애 발생 시 다시 데이터를 읽어야 하는 경우

 

 

🐇 RabbitMQ란?

RabbitMQ는 오픈 소스 **메시지 브로커(Message Broker)**로, AMQP(Advanced Message Queuing Protocol) 기반으로 동작하는 메시지 큐 시스템입니다. 비동기 방식으로 데이터를 전달하여 비동기 작업 처리, 로드 밸런싱, 마이크로서비스 간 통신 등에 많이 사용됩니다.

 

RabbitMQ의 핵심 개념

 

• Producer(생산자): 메시지를 생성하여 Exchange로 보냄
• Exchange(교환기): 메시지를 받아서 적절한 Queue로 라우팅
• Queue(큐): 메시지를 저장하고, Consumer가 가져가기를 기다림
• Consumer(소비자): Queue에서 메시지를 가져와 처리

RabbitMQ의 핵심 개념

① Exchange(교환기)

• 메시지를 적절한 Queue로 라우팅(Routing) 하는 역할
• Exchange Type에 따라 메시지 분배 방식이 달라짐

② Queue(큐)

• 메시지를 임시로 저장하는 공간
• Consumer가 메시지를 가져가 처리하면 제거됨

③ Binding(바인딩)

• Exchange와 Queue를 연결하는 설정
• 어떤 Queue가 어떤 Exchange의 메시지를 받을지 정의

④ Routing Key(라우팅 키)

• 특정 Queue로 메시지를 보내기 위한 라우팅 정보
• Exchange에서 Routing Key를 기준으로 메시지를 배분

. Exchange 유형

Direct	특정 Routing Key가 일치하는 Queue에만 메시지를 전달 / 특정 로그 레벨 (error, warning, info)을 필터링하여 전
Fanout	모든 바인딩된 Queue에 메시지를 브로드캐스트 / 실시간 알림, 공지사항 전송
Topic	패턴 매칭을 이용해 특정 조건의 Queue로 메시지를 전달 /  특정 카테고리의 로그만 받기 (logs.error.#)
Headers	메시지의 Header 값을 기반으로 라우팅 / 특정 속성(type: json, format: utf-8)을 가진 메시지만 전달