Message Broker - Kafka와 RabbitMQ

 

Message Broker (RabbitMQ)

• 보내는 쪾은 프로듀서, 받는 쪾은 컨슈머로 불린다.
• 프로듀서는 전달할 것이 있을 때마다 택배함에 데이터를 넣기만 하면 된다.
• 컨슈머는 필요할 때마다 데이터 골라서 가져가면 된다.
• 지정된 시점까지 데이터를 보관한다. -> 데이터 유실 걱정할 필요 없음.
• 프로듀서와 컨슈머의 수가 많아지더라도 모든 전달이 Message Broker를 통해 이뤄지기 때문에 설계가 수월해진다.
• 보내는 쪽과 받는 쪽의 소통을 유연하게 만들고, 데이터의 유실을 방지하며, 수평적 확장이 용이하도록 만들어준다.
• 안전한 메시지 전달, 노드 간의 독립성, 확장성을 필요로 하는 서비스들에 매우 유용하게 활용된다.
• 요청에 대한 즉각적 응답에는 적합하지 않다.

Event Broker (Kafka)

RabbitMQ

• MessageBroker는 프로듀서와 컨슈머와는 별개의 서버에 구동된다.
• 개발자가 직접 서버를 마련한 뒤 RabbitMQ 또는 Kafka를 설치하여 운영 or 클라우드 기업에서 제공하는 서비스 사용할 수도 있음.
• RabbitMQ는 하나 또는 비교적 적은 수의 서버에 설치되는 반면, Kafka는 일반적으로 큰 규모의 클러스터로 운영된다.
• 프로듀서와 Message Broker, Message Broker와 컨슈머 사이의 통신으로는 RabbitMQ의 경우 주로 AMQP라는 프로토콜을 사용.
• KAFKA는 TCP를 기반으로 한 자체적인 프로토콜을 사용한다.

---

RabbitMQ vs. Kafka

• RabbitMQ는 메시지들을 큐 형태로, Kafka는 이들을 로그 형태로 저장한다.

RabbitMQ

• 선입선출의 큐 형태
• RabbitMQ 브로커는 프로듀서가 보낸 순서대로 이 메시지들을 큐 형태로 저장한 다음, 컨슈머가 이들을 요청하는대로 이들을 큐에서 빼내어 전송하게 된다.
• RabbitMQ에서 브로커는 프로듀서로부터 메시지를 받아와 저장하는 일 뿐 아니라 컨슈머가 메시지를 받아갈 때마다 이를 큐에서 제거하는 일도 담당하게 된다.
• RabbitMQ에서 컨슈머는 다른 것을 고려할 필요 없이 브로커에게 메시지를 요청하기만 하면 된다.`
• smart broker, dumb consumer*
• RabbitMQ에서 메시지들은 주로 메모리에 저장되기 때문에 처리가 빠르지만, 유실의 위험성도 있다.
• 시간이 걸리는 작업을 여러 워커들이 분산 처리하는 작업 큐를 지원한다,

Kafka

• 메시지들을 디스크에 로그 형태로 저장한다. 컨슈머가 받아간다고 해서 로그에서 지워지지 않는다.
• 로그 안의 메시지들은 배열 안의 요소들이 인덱스를 갖는 것처럼 각각의 오프셋을 갖는데, 컨슈머들은 각자 자기가 받아간 마지막 오프셋을 기억함으로써 중복 없이 다음 메시지를 요청하게 된다.
• dumb broker, smart consumer
  => consumer를 구현하는 일이 RabbitMQ에 비해 까다로울 수 있다. 그러나 브로커의 경우에는 컨슈머의 요청에 따른 작업이 필요 없기 때문에 부담이 줄어들고 메시지들을 디스크에 저장하기 때문에 유실로부터 안전하다.
• 컨슈머가 특정 메시지를 여러 번 받아갈 수 있고, 장애가 발생했을 시 문제가 있었던 부분부터 다시 받아갈 수도 있음.
• 디스크는 메모리보다 속도가 느리다. 그렇지만, Kafka와 같이 순차적으로 저장하면 성능을 극대화할 수 있습니다.
• 기본적으로 배치(batch) 기능을 제공하기 때문에 메시지들을 여럿씩 받아오거나 보내주는 일도 RabbitMQ에 비해 빠르고 간편하게 처리된다.

Kafka의 방식은 브로커를 여러 서버에 분산하여 운영하는 클러스터링에 보다 유리하다.
컨슈머가 오프셋을 사용해서 메시지들에 접근하기 때문에, 각 노드는 받아온 메시지들만 제 때 동기화되면 된다.

RabbitMQ에서는 컨슈머가 받아간 메시지가 삭제되는 것까지 다른 노드들에 실시간으로 적용되어야하기 때문에 클러스터링이 까다롭다.

Kafka와 같은 제품들은 분산 시스템의 높은 처리량을 필요로 하는 대용량 실시간 스트리밍, 데이터 파이프라인, 로그 집계 및 분석 등에 유리하다.

• Kafka에서는 메시지들은 토픽이라는 그룹으로, RabbitMQ에서는 큐라는 그룹으로 묶일 수 있다.
• RabbitMQ는 조건에 따라 각 메시지를 특정 큐로 보내거나 모든 큐로 보내기 위한 다양한 방식들을 제공 -> 복잡한 메시지 라우팅이 필요한 서비스의 경우 Kafka보다 유리하다.
• RabbitMQ는 컨슈머가 메시지를 성공적으로 처리했는지 여부를 브로커에게 전달함으로써 신뢰성 있는 전달을 보장할 수 있다. => 브로커가 메시지의 처리 여부를 확인할 수 있기 떄문에 트랜젝션과 같이 안정적인 처리가 필요한 작업에 적합함.
• RabbitMQ에서도 메시지의 우선순위를 두는 기능과, 메시지가 일정 시간 후 자동 만료되도록 설정하는 기능 또한 기본적으로 제공된다.

 

아래부터는 우아콘 2023 영상을 보고 자유롭게 정리한 내용입니다.

Kafka

이벤트 기반 아키텍처 구축
배달이 변경되었을 때, 관련 기능이 "언젠가" 반영되면 된다.
이벤트는 시스템에서 일어난 행위이다.
배달의 변경사항은 이벤트를 통해 전달하도록 변경 -> 알림, 통계등의 배달관련 기능은 이벤트만을 수신해서 변경 관리 가능.

이벤트는 어떤 정보를 가지고 있어야 할까?

이벤트의 구성 요소

• 도메인 이벤트
  도메인의 영향을 주는 관심 정보
  대상, 발생한 시간, 행동
• 배달이벤트에 주문 식별자를 포함하여 전달

장점

• 요구사항 추가 되더라도 배달 시스템 복잡도에 영향이 없음.
• 소비처와 결합도 감소. 배달변경 사항을 이벤트로 파악 가능
• 데이터 분석 (또메인 히스토리 파악이 용이해짐.)

주의할점

• 이벤트 데이터 무분별한 추가 주의
  • 행위자 기반의 데이터 정의 필요
  • 소비처 요구사항에 대한 무분별한 데이터 추가 주의
• 이벤트의 순서가 중요하다.

---

이벤트 파이프라인

이벤트를 발행하려면 메시지 브로커가 필요하다.

Kafka

• 순서 보장
  • 토픽의 파티션을 통해 Key별로 순서 보장
• 고성능, 고가용성
  • 실시간 이벤트를 처리할 고성능 고가용성 제공
• 통합 도구
  • Kafka Streams, Kafka Connect 등 다양한 통합 도구 제공

도메인 상태 != 이벤트 발행 결과

• Transactional outbox Pattern`
  Message Relay
  이벤트 순서유지, 소실 방지

https://www.youtube.com/watch?v=0lyrd5FlETQ

얄코의 Message Broker

 

https://www.youtube.com/watch?v=DY3sUeGu74M

우아콘2023 - Kafka를 활용한 이벤트 기반 아키텍처 구축