Choosing the Right MessageBroker

원본 링크(https://medium.com/@PubNub/kafka-vs-rabbitmq-choosing-the-right-messaging-broker-78ca02530e63)

백엔드 개발자로 MSA 서비스 내에서 컴포넌트 간의 통신을 위해서 api 통신도 방법이지만 메세지 브로커를 통해서 데이터를 주고받는 경우도 다반사하게 일어난다

백엔드 개발자들이 주로 사용하는 메세지 브로커는 크게 RabbitMQ 와 Kafka 2개를 많이 사용한다. 각각의 메세지 브로커들은 장단점들이 존재하고 특정 상황에 알맞게 적용해서 사용하면 된다.

구조

Kafka

카프카는 높은 처리량, 내결함성 및 실시간 데이터 처리 기능으로 유명하고, topic 에 메세지를 발행하고 - topic 을 구독하여 메세지를 받는 방식으로 사용되고 이를 pub-sub 모델이라고 이야기한다 카프카에는 메세지를 분산 커밋 로그에 저장함으로써 높은 확장성과 내결함성을 가지고 있으며 이를 통해서 높은 데이터 처리량과 메세지 재생 기능을 사용할 수 있고 이는 실시간 데이터 처리 및 이벤트 소싱(object 의 모든 상태의 변화를 기록하는 방식)에 적합하다

카프카의 구조는 크게 3개로 나뉜다 - producers, broker, consumers producers 는 카프카의 topic 에 메제시를 발생 broker 는 카프카 클러스터 구조 내에서 메세지를 저장하고 메세지를 복사하는 역할을 수행 consumers 는 하나 이상의 topic 으로부터 데이터를 읽어가는데 이 때 확장성도 제공하고 병렬처리도 가능

RabbitMQ

RabbitMQ 는 AMQP(Advanced Message Queue Protocol) 을 상속받은 오픈소스 메세지 브로커이다 이는 전통적인 메세지 큐의 모델이고 서비스들로 하여금 비동기적으로 데이터를 보내고, 데이터를 특정 정해진 consumer 에게 보내는 기능을 보유 이러한 기능들은 메세지의 순서 지정 및 메세지 라우팅의 유연성을 높힘으로써 MSA 구조에서 사용하기 가장 적합하다

RabbitMQ 의 구조는 producer 와 consumer 사이에서 중개자 역할을 하는 중앙 메세지 중개자를 중심으로 구성됨 producer 가 중개자에게 메세지를 보내면 중개자는 지정된 규칙을 기반으로 메세지를 대기열에 넣어주고 consumer 는 메세지를 대기열에서 검색해서 꺼내간다

성능

Kafka

처리율이 높고 실시간 데이터 스트리밍 방식을 사용하는 시나리오에서 사용하기 적절하고 높은 확장과 낮은 지연시간을 가진 특징 초당 수백만건의 데이터를 처리하는 것이 가능해 빠르고 지속적인 데이터 처리가 필요한 사례에 적합하다 또한 여러 broker 에게 워크로드를 분산하여 수평적 확장이 가능하고 메세지를 디스에 저장함으로써 데이터를 보장하는 것이 가능

RabbitMQ

메세지의 수신 확인 및 메세지 지속성과 같은 제공을 기반으로 신뢰 가능한 메세지를 전달받음 초당 수천개의 메세지를 처리하는 것이 가능할 수 있어 중간 수준의 처리 요구사항을 가진 서비스에 적용이 좋다

사용 사례

Kafka

• 다양한 케이스에 사용 가능

• 실시간 분석 및 스트리밍 애플리케이션

• 이벤트 소싱, 로그 수집 및 집계

• 대용량 메세지 처리를 통한 데이터 파이프라인 구축 가능

RabbitMQ

• MSA 사이의 비동기적 통신

• 메세지의 우선순위 및 특정 복잡한 라우팅을 요구하여 신뢰가능한 메세지를 전달

그래서 뭘 사용하라고?

몇 가지 케이스들에 대해서 예시를 넣어준게 있더라 높은 처리량 + 실시간 데이터 처리가 필요하다 >> 카프카 안정적인 메세지 전달 + 적당한 트래픽 + 유연한 라우팅 >> 래빗 메세지의 재생이나 로그 집계 >> 카프카

이렇게 알맞은 상황에 사용하면 되는데 kafka 는 분산아키텍처는 단순하게 대기열기반의 rabbit 보다 더 많은 지식이 필요되니 충분한 공부 이후에 접근이 필요