CS지식

Kafka Redis RabbitMQ

두잇 두두 2025. 2. 4. 10:19
728x90

Kafka vs Redis vs RabbitMQ 비교표

주요 역할 분산 메시지 스트리밍 플랫폼 메모리 기반 메시지 브로커 & 캐시 전통적인 메시지 브로커
메시지 처리 방식 Pub/Sub (로그 저장 및 스트리밍) Pub/Sub + 메시지 큐 메시지 큐 (AMQP 프로토콜)
메시지 순서 보장 Partition 내에서 순서 보장 ❌ 기본적으로 순서 보장 안 됨 ✅ 기본적으로 순서 보장
메시지 저장 여부 ✅ 영구 저장 (디스크 저장 가능) ❌ 기본적으로 메모리 저장 (설정 필요) ✅ 영구 저장 가능 (설정 필요)
메시지 소비 방식 여러 Consumer가 같은 메시지 읽기 가능 Queue 기반 (단일 Consumer가 메시지 소비) Queue 기반 (단일 Consumer가 메시지 소비)
확장성 ✅ 매우 뛰어남 (수천 개의 Consumer 가능) ❌ 단일 노드에 종속 (클러스터링 어려움) ⚠️ 중간 정도 (Cluster 가능하지만 Kafka만큼 확장성 높지 않음)
성능 고성능 (초당 수백만 건 가능) 매우 빠름 (메모리 기반, ms 단위 처리) 빠르지만 Kafka보다는 성능 낮음
장애 발생 시 메시지 처리 Consumer가 메시지 재처리 가능 ❌ 기본적으로 메시지 유실 가능 (Persistence 필요) 메시지 Ack/Nack으로 복구 가능
주요 사용 사례 로그 처리, 이벤트 스트리밍, 빅데이터 분석 빠른 캐싱, Pub/Sub, 단순한 메시지 처리 비동기 작업 처리 (Celery, 금융 시스템 등)

Kafka 사용 추천 (대규모 데이터 스트리밍)

  • 실시간 이벤트 스트리밍, 로그 처리, 데이터 파이프라인 구축
  • 대량의 메시지를 순서대로 유지하며 저장하고 싶을 때
  • 여러 Consumer가 같은 메시지를 구독해야 할 때 (Pub/Sub)
  • **데이터 영속성(Persistence)**이 중요할 때

💡 사용 예제: 실시간 로그 분석, 주문 처리 시스템, IoT 데이터 스트리밍


Redis 사용 추천 (빠른 메시지 처리 & 캐싱)

  • 짧은 시간 유지되는 메시지를 빠르게 전달해야 할 때
  • 고성능, 저지연 메시징이 필요할 때 (ms 단위 응답)
  • 캐싱, 세션 관리, Pub/Sub, 실시간 랭킹 처리
  • 메시지 유실이 크게 중요하지 않을 때

💡 사용 예제: 채팅 시스템, 실시간 랭킹, 캐싱, 빠른 작업 큐


RabbitMQ 사용 추천 (전통적인 메시지 큐 & 안정적인 메시지 전달)

  • 신뢰성이 중요한 메시지 처리 (금융 시스템, 주문 처리 등)
  • 메시지를 한 번만 전달하고 정확한 순서로 처리해야 할 때
  • 메시지 유실을 방지하고, 작업 실패 시 재시도(Ack/Nack)가 필요할 때

💡 사용 예제: Celery 비동기 작업 처리, 금융 거래 시스템, 이메일 큐


📌 결론: Kafka, Redis, RabbitMQ의 차이점

  • Kafka대규모 데이터 스트리밍 & 이벤트 처리 (Pub/Sub)
  • Redis빠른 캐싱 & 실시간 메시지 처리 (단순 Pub/Sub & Queue)
  • RabbitMQ신뢰성이 필요한 메시지 큐 (AMQP 기반, 정확한 메시지 전달)