Message Queue & PUB/SUB - Kafka, Redis, RabbitMQ
Kafka, Redis, RabbitMQ
Kafka
출처 https://cloud.google.com/pubsub/docs/migrating-from-kafka-to-pubsub?hl=ko
Kafka는 LinkedIn에서 개발된 pub-sub 모델의 메시지큐 방식 기반, 분산 메시징 시스템이다.
구성 요소
- Event : kafka에서 producer 와 consumer가 데이터를 주고받는 단위. 메세지
- Producer : kafka에 이벤트를 게시(post, pop)하는 클라이언트 어플리케이션
- Consumer : Topic을 구독하고 이로부터 얻어낸 이벤트를 받아(Sub) 처리하는 클라이언트 어플리케이션
- Topic : 이벤트가 모이는 곳. producer는 topic에 이벤트를 게시하고, consumer는 - topic을 구독해 이로부터 이벤트를 가져와 처리. 게시판 같은 개념
- Partition : Topic은 여러 Broker에 분산되어 저장되며, 이렇게 분산된 topic을 partition이라고 함
- Zookeeper : 분산 메세지의 큐의 정보를 관리
동작
- Publisher는 전달하고자 하는 메세지를 topic을 통해 카테고리화 한다.
- Subscriber는 원하는 topic을 구독(Subscribe)함으로써 메시지를 읽어온다.
- Publisher와 Subscriber는 오로지 topic의 정보만 알 뿐, 서로에 대해 알지 못한다.
- Kafka는 Broker들이 하나의 클러스터로 구성되어 동작하도록 설계되어 있다.
- 클러스터 내, broker에 대한 분산처리는 ZooKeeper가 담당한다.
장점
- 대규모 트래픽 처리 및 분산 처리에 효과적
- 클러스터 구성, Fail-over, Replication 같은 기능이 있음
- 100Kb/sec 정도의 속도 (다른 메세지 큐 보다 빠름)
- 디스크에 메세지를 특정 보관 주기동안 저장하여 데이터의 영속성이 보장되고 유실 위험이 적다. 또한 Consumer 장애 시 재처리가 가능하다.
단점
- 구성 복잡도: 아파치 카프카는 구성이 복잡하며, 사용하기 위해서는 일정 수준의 기술적 이해와 노하우가 필요하다.
- 설정 오류의 위험성: 아파치 카프카는 다양한 설정 옵션을 제공하며, 설정을 잘못하면 시스템 동작에 오류를 유발할 수 있다.
- 서버 및 용량 비용: 아파치 카프카는 서버의 수와 스토리지의 용량에 따라 비용이 증가할 수 있다.
Redis
출처 https://medium.com/@saurabh.singh0829/redis-pub-sub-implementation-f3208e4625c7
Redis는 데이터베이스, 캐시, 메시지 브로커 및 스트리밍 엔진으로 사용되는 인메모리 데이터 구조 저장소이다.
구성 요소
- Publisher : 메세지를 게시(pub)
- Channel : 메세지를 쌓아두는 queue
- Subscriber: 메세지를 구독(sub)
동작
- Publisher가 Channel에 메세지 게시
- 해당 채널을 구독하고 있는 Subscriber가 메세지를 sub해서 처리
특징
- Channel은 이벤트를 저장하지 않음.
- Channel에 이벤트가 도착 했을 때 해당 채널의 Subscriber가 존재하지 않는다면 이벤트가 사라짐
- Subscriber는 동시에 여러 Channel을 구독할 수 있으며, 특정한 Channel을 지정하지 않고 패턴을 설정하여 해당 패턴에 맞는 채널을 구독할 수 있다
장점
- 처리 속도가 빠름
- 캐시의 역할도 가능
- 명시적으로 데이터 삭제 가능
단점
- 메모리 기반이므로 서버가 다운되면 Redis 내의 모든 데이터가 사라짐
- 이벤트 도착 보장을 못함
RabbitMQ
출처 https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html
RabbitMQ는 AMQP 프로토콜을 구현한 메세지 브로커이다.
AMQP(Advanced Message Queuing Protocol) : 메세지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜
구성 요소
- Producer : 메세지를 보냄
- Exchange : 메세지를 목적지(큐)에 맞게 전달
- Queue : 메세지를 쌓아둠
- Consumer : 메세지를 받음
동작
- Producer 가 Broker로 메세지를 보냄
- Broker 내 Exchange(메세지 교환기) 에서 해당하는 key에 맞게 큐에 분배한다. (Binding or Routing 이라고 함)
- topic 모드 : Routing Key가 정확히 일치하는 Queue에 메세지 전송 (Unicast)
- direct 모드 : Routing Key 패턴이 일치하는 Queue에 메세지 전송 (Multicast)
- headers 모드 : [Key:Value] 로 이루어진 header값을 기준으로 일치하는 Queue에 메세지 전송 (Multicast)
- fanout 모드 : 해당 Exchange에 등록도니 모든 Queue에 메세지 전송 (Broadcast)
- 해당 큐에서 Consumer가 메세지를 받는다.
장점
- Broker 중심적인 형태로 publisher와 consumer 간의 보장되는 메세지 전달에 초점을 맞추고, 복잡한 라우팅 지원
- 클러스터 구성이 쉽고 Manage UI 가 제공되며 플러그인도 제공되어 확장성이 뛰어남
- 20kb/sec 정도의 속도
- 데이터 처리 보단, 관리적 측면이다 다양한 기능 구현을 위한 서비스를 구축할 때 사용
단점
- MQ Server가 종류 후 재기동되면 기본적으로 Queue 내용은 모두 제거되어 데이터 손실의 위험성이 있다.
- Producer와 Consumer 간의 결합도가 높다