메시지 큐 차이 (Redis Queue, Kafka, RabbitMQ)

1. 메시지큐 별 차이점

메시지 큐로 사용할 수 있는 대표적인 미들웨어들이다.

추가적으로 설명이 필요한 부분은 추가설명에 기입하도록 하겠다.

항목	Redis Queue	Kafka	RabbitMQ
목적	인메모리 데이터 저장소, 메시지 큐 가능	분산 메시지 스트리밍 플랫폼	고급 메시지 브로커 (AMQP 표준)
데이터 저장	기본적으로 메모리 기반 (디스크 옵션 있음)	디스크 기반으로 데이터 영속성 보장	디스크 기반으로 영속성 보장 (옵션 조정 가능)
속도	매우 빠름 (메모리 기반)	빠름 (디스크 기반이지만 고효율 설계)	빠름 (AMQP 프로토콜의 추가 오버헤드 존재)
라우팅 기능*	제한적 (List와 Pub/Sub 활용)	없음 (토픽 기반, 라우팅은 소비자에서 결정)	고급 라우팅 가능 (Exchange, Binding 등)
메시지 처리량	초당 수백만	초당 수백만	초당 수천~수십만
소비자 관리	단순 큐, 소비자는 직접 메시지 확인 필요	소비자별 메시지 오프셋 제공	메시지 ACK/NACK으로 상태 관리
데이터 유실	휘발성 (옵션으로 디스크 저장 가능) *2.2 레디스 데이터 유실 방지	매우 낮음 (디스크 기반 + 복제 지원)	낮음 (ACK/NACK 및 영속성 옵션)
사용 사례	- 실시간 작업 큐 - 캐싱 - 단순 메시지 전달	- 로그 수집 - 이벤트 스트리밍 - 대규모 데이터 처리	- 고급 라우팅 필요 - 메시지 큐 - 비동기 작업 처리
확장 및 분산	Redis Cluster로 확장 가능	파티션 기반으로 대규모 확장 가능	클러스터링과 페더레이션으로 확장 가능
설정 및 운영	매우 간단	비교적 복잡	중간 수준의 복잡도 (AMQP 프로토콜 학습 필요)
재전송 여부	Pub/Sub - 불가능 Redis Stream - 가능 (유실가능성)	가능	가능
메시지 소비 후, 재전송	불가능	가능 (소비자 오프셋 변경)	불가능

 

2. 추가설명

2.1 라우팅 기능?

메시지를 어떤 소비자로 전달할지 결정하는 방식

• 레디스 큐
  •  Pub/Sub과 Stream을 사용하여 메시지 전달 

  • 	Pub/Sub	Streams
    메시지 소비	한 소비자가 메시지를 읽으면 다른 소비자는 읽을 수 없음.
    소비자 그룹	없음	소비자 그룹 기능을 지원, 여러 소비자가 각각 다른 메시지를 처리.
    메시지 순서	메시지 순서 보장하지 않음	메시지 순서 보장

• RabbitMQ
  • AMQP를 기반으로 한 메시지 큐 시스템입니다.
  • RabbitMQ에서의 라우팅은 주로 Exchange와 Queue의 조합.
• Kafka
  • 토픽을 중심으로 메시지 관리, 직접 소비자를 선택하진 않고 소비자가 어디까지 읽었는지 신경쓰지 않음.(소비자 오프셋 관리는 가능)
    => 소비자가 자신의 오프셋을 기준으로 메시지를 읽음

 

2.2 레디스 데이터 유실 방지

• AOF 활성화:
  • 데이터를 디스크에 기록하여 서버가 재시작할 때 데이터 복구 가능.
  • appendfsync everysec을 설정하면 매 초마다 데이터를 디스크에 저장하므로 유실을 최소화.
• 마스터-슬레이브 복제:
  • 데이터 복제를 통해 장애 발생 시 서비스 중단을 최소화합니다.
  • 슬레이브 서버가 마스터 서버의 데이터를 실시간으로 복제하여 장애 발생 시 빠르게 복구.=> 슬레이브에 복제되지 않은 경우에 장애 시, 유실 가능성으로 AOF 활성화 필요
• Redis Sentinel:
  • 장애를 감지하고 자동으로 슬레이브를 마스터로 승격시켜 서비스의 연속성을 유지.
  • 마스터 서버가 장애를 겪으면 Sentinel이 새로운 마스터를 자동으로 선택하여 시스템을 복구.

 

 

---

참고

https://aws.amazon.com/ko/compare/the-difference-between-rabbitmq-and-kafka/