본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.
강의 요약
오늘 강의에서는 메시지 브로커와 카프카에 대해서 간단히 학습했다. 메시지 브로커와 이벤트 브로커는 두 용어를 혼용하여 사용하는 경우가 많지만, 하지만 두 용어는 서로 다른 설계 철학과 사용 목적을 가지고 있다. 특히 이벤트 브로커의 경우 오프셋(offset) 개념이 핵심이며, 이는 메시지 소비 위치를 추적하고 재처리를 가능하게 하는 중요한 메커니즘이다. Apache Kafka를 중심으로 이벤트 브로커의 기본 개념과 아키텍처를 살펴보자.
Message Broker vs Event Broker
메시지 브로커와 이벤트 브로커는 비동기 분산 시스템에서 서로 다른 문제를 해결하기 위해 설계되었다. 두 패러다임을 이해하고 적절히 선택하는 것이 시스템 아키텍처의 핵심이다.
Event Broker의 특징
Event Broker는 이벤트 시퀀스를 저장하는 구조로 설계되었다. 이벤트는 도착한 순서대로 큐 또는 토픽에 추가되며, 한번 기록된 이벤트는 불변(immutable)이다. 순서 변경이 불가능하며, 브로커는 토픽이나 큐를 구독하는 여러 타입의 구독자에게 이벤트를 전달한다.
프로듀서와 컨슈머는 서로를 알 필요가 없으며, 이벤트는 성공적으로 소비된 후에도 큐나 토픽에서 삭제되지 않고 수일에서 수주간 보관될 수 있다. 이는 이벤트 재처리나 새로운 컨슈머의 히스토리컬 데이터 처리를 가능하게 한다.
Message Broker의 특징
Message Broker는 서비스 또는 컴포넌트 간 통신을 위해 사용된다. 프로듀서로부터 받은 메시지를 컨슈머에게 비동기로 전달하여 애플리케이션 간 정보 교환을 제공한다.
큐 개념을 지원하며, 메시지는 일반적으로 짧은 시간 동안만 저장된다. 큐의 메시지는 컨슈머가 처리 가능해지는 즉시 소비되고, 성공적으로 처리된 후 삭제되는 것이 목적이다. 큐에서 메시지 처리 순서는 보장되지 않으며 변경될 수 있다.
Message Broker 적합 케이스
단기성 커맨드나 태스크 지향 처리에는 메시지 브로커가 적합하다. 아래 다이어그램은 RabbitMQ의 fanout 메시지 분산 방식을 보여주며, 각 서비스는 fanout 교환기에 연결된 자체 큐를 갖는다. 특히 RabbitMQ는 amqp 기반으로 신뢰성 높은 메시지 전달을 보장한다.
- 이커머스에서 새 제품을 웹사이트에 추가하는 경우를 예로 들면, 제품 서비스는 새 제품 정보를 fanout 교환기로 전송하고, 교환기는 연결된 모든 큐(재고 서비스 큐, 검색 서비스 큐, 추천 서비스 큐)에 메시지를 전달한다.
- 메시지가 성공적으로 소비되면 큐에서 삭제되며, 서비스는 메시지를 재처리하거나 보관할 필요가 없다.
Event Broker 적합 케이스
현재 또는 과거 이벤트와 같이 대량의 데이터를 처리해야 하는 경우, 즉 단일 또는 배치 방식으로 처리해야 할 때 이벤트 브로커가 적합하다.
- 엔터테인먼트 평점 웹사이트에서 영화 작가와 감독 정보를 추가하는 경우, Kafka는 짧은 시간에 수억 건의 영화 데이터를 데이터 웨어하우스에서 추출할 수 있다.
- 각 컨슈머 그룹은 영화 토픽 스트림을 독립적으로 처리하며, 필요시 과거 데이터를 재처리할 수 있다.
Poll vs Push 메커니즘
적절한 브로커를 선택하기 위해서는 다음 사항들을 고려하여 결정 하는 것이 좋다.
Kafka (Event Broker)
- 컨슈머가 파티션으로 나뉜 토픽에서 메시지를 순서대로 bulk polling
- 각 컨슈머는 하나 이상의 파티션 담당 (암묵적 스레딩 모델)
- 파티션 레벨에서 메시지 처리 순서 보장
- 컨슈머가 성공/실패 시나리오 모두 처리
RabbitMQ (Message Broker)
- 브로커가 메시지를 컨슈머에게 push
- 각 메시지를 원자적으로 처리 (명시적 스레딩 모델)
- 브로커가 메시지 분산 관리
- delayed 메시지, 우선순위 기본 제공
Error Handling
Kafka의 컨슈머 중심 접근
- 에러 핸들링 책임이 컨슈머에게 있음
- 메시지가 여러번 처리에 실패하는 poison pill 발생 시 컨슈머가 처리 시도 횟수 추적 필요
- DLQ 토픽으로 메시지 전송 시 컨슈머가 프로듀서 역할 수행
- 일부 엣지 케이스에서 메시지 손실 가능성 존재
RabbitMQ의 브로커 중심 접근
- 브로커가 메시지 처리 실패 추적
- poison pill은 자동으로 DLQ 교환기로 라우팅
- 메시지 재큐잉 또는 검사용 DLQ 라우팅 지원
- 처리 실패한 메시지 손실 방지 보장
Consumer Acknowledgment
Kafka
- 컨슈머가 bulk 메시지의 offset 커밋
- 기본값: 처리 성공 여부와 무관하게 자동 커밋 (메시지 손실 가능)
- 수동 커밋 설정으로 변경 가능하지만 컨슈머가 실패 처리 구현 필요
RabbitMQ
- 메시지 단위로 ack/nack 처리
- 브로커가 재시도 정책 및 DLQ 관리
- 수동 acknowledgment 설정 시 실패/타임아웃에 자동 재처리
기술 선택 시 고려사항
비동기 처리 시스템 선택 시 다음 질문에 답해야 한다. 두 패러다임 모두 at-least-once 전달을 보장하므로, 컨슈머는 멱등성을 고려하여 설계해야 한다. 즉 선택은 해결하려는 문제의 본질과 시스템 요구사항에 달려있다.
메시지 손실 허용 여부
- 손실 불가: RabbitMQ의 브로커 중심 에러 핸들링이 유리
- 손실 허용 가능하고 높은 처리량 필요: Kafka 고려
처리 순서 보장 필요성
- 엄격한 순서 보장: Kafka의 파티션 기반 순서 보장 활용
- 순서 무관: RabbitMQ의 유연한 메시지 분산 활용
과거 데이터 재처리
- 필요: Event Broker (메시지 보관 및 offset 기반 재처리)
- 불필요: Message Broker (처리 후 즉시 삭제)
운영 복잡도
- 단순한 에러 핸들링 필요: RabbitMQ (브로커가 DLQ 관리)
- 세밀한 제어 필요: Kafka (컨슈머가 모든 로직 구현)
참고 출처
