아파치 카프카(Apache Kafka) - RabbitMQ, Redis Queue 와 차이

Apache Kafka, RabbitMQ, Redis Queue는 메시징 시스템 및 데이터 스트리밍 용도로 많이 사용되지만 각각의 아키텍처, 사용 사례, 강점, 약점이 다르다. 

 

1. 카프카(Apache Kafka)

특징

• 데이터 스트리밍 플랫폼 : 실시간 데이터 스트리밍 및 이벤트 기반 아키텍처에 최적화
• 분산 시스템 : 높은 처리량과 내결함성을 제공
• 로그 저장 : 데이터를 디스크에 저장하며 저장된 데이터를 여러 컨슈머가 독립적으로 처리 가능
• 데이터 보존 : 메시지는 소비 후에도 저장되며 데이터 보존 기간을 설정할 수 있음

장점

1. 고성능 : 대량의 데이터를 처리하며 높은 처리량을 제공
2. 내결함성 : 데이터를 복제하여 장애 발생 시에도 데이터 손실 최소화
3. 순서 보장 : 파티션 내에서는 메시지 순서가 보장됨
4. 실시간 데이터 스트리밍 : 데이터 파이프라인 및 이벤트 소싱에 최적화

단점

1. 복잡성 : 설치 및 운영이 상대적으로 어려움
2. 짧은 메시지 수명 처리에는 비효율적 : 빠르게 처리하고 제거해야 하는 메시지에는 적합하지 않음

주요 사용 사례

• 로그 수집 및 분석
• 실시간 데이터 스트리밍
• 이벤트 기반 시스템
• IoT 데이터 처리

 

2. 레빗엠큐(RabbitMQ)

특징

• 전통적인 메시지 브로커 : AMQP(Advanced Message Queuing Protocol)를 지원하는 메시징 시스템
• 플러그인 기반 : 다양한 프로토콜 및 기능을 확장 가능
• 즉시 전달 : 메시지는 큐에 들어가면 바로 전달되며 처리 후 삭제

장점

1. 유연성 : 다양한 프로토콜과 라우팅 패턴 지원(직접, 토픽, 팬아웃 등)
2. 간단한 설치 및 운영 : 카프카보다 설치와 구성이 단순
3. 우선순위 큐 : 메시지에 우선순위를 지정 가능
4. 풍부한 클라이언트 라이브러리 : 여러 언어에서 쉽게 사용 가능

단점

1. 고성능 처리 한계 : 카프카만큼 높은 처리량을 제공하지 못함
2. 복잡한 데이터 스트리밍에는 적합하지 않음 : 주로 단순 메시지 전달에 초점

주요 사용 사례

• 요청/응답 패턴
• 작업 큐(Worker Queue)
• 실시간 알림 시스템
• 메일 또는 푸시 알림 시스템

 

3. 레디스 큐(Redis Queue)

특징

• 인메모리 데이터 구조 : Redis를 기반으로 한 메시지 큐
• 경량 메시징 시스템 : 간단하고 빠른 메시지 처리에 최적화
• TTL(Time-To-Live) : 메시지에 만료 기간을 설정할 수 있음

장점

1. 속도 : 모든 데이터가 메모리에 저장되므로 매우 빠름
2. 간단한 설정 : Redis 설치 후 바로 사용 가능
3. 유연성 : Pub/Sub, Streams, List와 같은 여러 방식의 메시징 지원
4. TTL 지원 : 만료된 메시지를 자동으로 제거 가능

단점

1. 데이터 영구 저장 어려움 : 메모리 기반이므로 영구 저장은 비효율적
2. 복잡한 메시징 패턴 지원 부족 : RabbitMQ만큼의 유연한 라우팅 및 큐 관리 기능은 제공하지 않음
3. 확장성 제한 : 대량 데이터 처리나 복잡한 메시징 워크플로우에는 부적합

주요 사용 사례

• 경량 메시징 및 작업 처리
• 실시간 채팅 애플리케이션
• 캐시 기반 알림 시스템
• 빠른 작업 큐 처리

 

4. 주요 비교

특징	Apache Kafka	RabbitMQ	Redis Queue
기본 역할	데이터 스트리밍 및 로그 저장	메시지 브로커	경량 메시지 큐
처리 방식	Pub/Sub 및 로그 스트림	메시지 큐 (AMQP 기반)	인메모리 큐
속도	고속, 대량 데이터 처리 가능	적당한 속도	매우 빠름
데이터 보존	메시지 보존(삭제되지 않음)	메시지 소비 후 삭제	TTL로 제어
확장성	매우 뛰어남	제한적 (비교적 확장성 부족)	제한적 (메모리 기반)
복잡성	높은 설정 및 운영 복잡성	간단한 설정과 관리	매우 간단
주요 프로토콜	Kafka 프로토콜	AMQP	Redis Streams, Pub/Sub
사용 사례	데이터 파이프라인, 이벤트 스트림	작업 큐, 요청/응답, 알림	빠른 작업 처리, 실시간 채팅

 

5. 선택 기준

• Kafka
  • 고성능 데이터 스트리밍, 로그 수집, 실시간 분석이 필요할 때
  • 대규모 데이터 파이프라인 구축 시 적합
• RabbitMQ
  • 요청/응답 패턴과 작업 큐가 필요한 경우
  • 복잡한 라우팅 패턴을 구현해야 할 때
• Redis Queue
  • 메시징 시스템이 경량화되어야 하고, 처리 속도가 매우 중요한 경우
  • 간단한 작업 큐나 실시간 알림 서비스에 적합

 

---

참고

메시지 브로커(Message Broker)와 이벤트 브로커(Event Broker)는 데이터 전달 및 처리와 관련된 개념이지만 그 목적과 동작 방식에 차이가 있다. 이 두 용어는 종종 혼용되기도 하지만 명확한 차이가 있다.

 

1. 메시지 브로커(Message Broker)

개념

• 메시지 브로커는 생산자(Producer)와 소비자(Consumer) 간 메시지를 전달하는 시스템이다.
• 메시지의 안정적인 전달을 보장하고 생산자와 소비자의 분리를 통해 비동기 통신을 지원한다.

특징

1. 목적 : 메시지의 전달 보장(once, at-least-once, at-most-once 전달 보장 모델)
2. 구조 : 주로 큐(queue)를 사용하여 데이터를 관리
3. 패턴
   • 점대점(Point-to-Point) : 하나의 메시지는 한 소비자에게 전달
   • 퍼블리시/구독(Pub/Sub) : 메시지를 여러 소비자에게 브로드캐스트
4. 데이터 수명
   • 메시지는 소비자가 읽은 후 삭제된다.
   • 일반적으로 메시지는 상태 유지 없이 "소모성"으로 간주

주요 역할

• 소비자가 메시지를 처리하지 않으면 메시지를 재시도
• 메시지 우선순위 설정 가능
• 프로세싱 흐름을 제어(예: 작업 큐)

주요 사례

• RabbitMQ, ActiveMQ, Redis Queue 등이 메시지 브로커로 사용된다.

 

2. 이벤트 브로커(Event Broker)

개념

• 이벤트 브로커는 시스템 간의 이벤트 전달과 이벤트 흐름 관리를 지원하는 시스템이다.
• 주로 이벤트 기반 아키텍처(Event-Driven Architecture)에서 사용된다.

특징

1. 목적 : 이벤트 발생에 대한 알림 및 데이터를 여러 구독자에게 전달
2. 구조 : 토픽(Topic)을 기반으로 데이터를 관리
3. 패턴
   • 이벤트를 게시하고 여러 구독자가 해당 이벤트를 동시에 처리
   • 이벤트가 발생한 시스템과 이를 구독하는 시스템 간의 결합도를 줄임
4. 데이터 수명
   • 이벤트는 특정 기간 동안 저장되거나(카프카처럼) 소비 후 삭제되지 않을 수 있음
   • 데이터를 "저장된 로그"처럼 유지하며 여러 소비자가 개별적으로 처리 가능

주요 역할

• 이벤트 기록 : 이벤트를 로그로 저장하여 추후 분석 및 재처리에 사용
• 순서 보장 : 이벤트의 순서가 중요한 경우 이를 보장
• 실시간 데이터 스트리밍 지원

주요 사례

• Apache Kafka, AWS Kinesis, Google Pub/Sub 등이 이벤트 브로커로 사용된다.

 

3. 주요 차이점

특징	메시지 브로커(Message Broker)	이벤트 브로커(Event Broker)
목적	메시지 전달 및 처리 관리	이벤트 전달 및 이벤트 흐름 관리
데이터 모델	큐(queue) 또는 Pub/Sub	로그 기반(Event Log) 또는 Pub/Sub
데이터 수명	메시지 소비 후 삭제	데이터 보존 가능(옵션에 따라 다름)
전달 방식	메시지를 하나의 소비자가 처리	이벤트를 여러 구독자가 독립적으로 처리
주요 사용 사례	작업 큐, 요청/응답 패턴	이벤트 스트리밍, 이벤트 소싱
순서 보장	메시지 큐에 따라 순서 보장	특정 파티션 내 순서 보장
주요 시스템	RabbitMQ, ActiveMQ, Redis Queue	Apache Kafka, AWS Kinesis, Google Pub/Sub
구독 모델	소비자 기반 (큐에서 메시지 제거)	구독자 기반 (데이터는 계속 유지)

 

4. 메시지 브로커 vs 이벤트 브로커 : 주요 시나리오

메시지 브로커 사용 예시

• 작업 큐
  • 백엔드 작업을 비동기적으로 처리하기 위해 사용
  • 예 : 이메일 전송, 이미지 처리 작업
• 요청/응답 패턴
  • 클라이언트와 서버 간의 비동기 요청 처리
  • 예 : 마이크로서비스 간의 데이터 요청 및 응답

이벤트 브로커 사용 예시

• 이벤트 스트리밍
  • 실시간 데이터 처리
  • 예 : 사용자 행동 로그, IoT 센서 데이터
• 이벤트 소싱(Event Sourcing)
  • 시스템 상태를 이벤트의 흐름으로 저장
  • 예 : 금융 거래 내역, 주문 시스템 로그.
• 분산 시스템 통합
  • 여러 시스템 간의 느슨한 결합 구조 구현
  • 예 : 여러 마이크로서비스에서 데이터 변경 사항 동기화

 

5. 결론

• 메시지 브로커는 메시지 전달과 작업 처리에 중점을 둡니다. 주로 단순한 메시지 교환 및 작업 큐에 적합하다
• 이벤트 브로커는 이벤트 기반 아키텍처에서 사용되며 데이터를 기록하고 실시간으로 스트리밍하거나 여러 구독자가 데이터를 독립적으로 처리할 수 있도록 한다.

필요에 따라 두 가지를 조합하여 사용할 수도 있다. 예를 들어, RabbitMQ를 작업 큐로 사용하고 Kafka를 이벤트 스트리밍에 사용하는 식으로 활용할 수 있다.