메시지 브로커 - RabbitMQ와 Kafka

안녕하세요. 벌써 수요일이네요. 드디어 내일 깁스를 풀기위해 병원을 갑니다. 이전에는 아마 이후에는 보호대로 재활을 하는게 좋다고 했는데...내일 병원가서 상태가 괜찮으면 좋겠네요. 그래도 완전한 여름이 되기 전에 깁스를 풀 수 있어서 다행이네요. 자 그럼 메시지 브로커에 대한 학습 시작해보겠습니다.

---

메시지 브로커

메시지 브로커는 시스템 간에 주고받는 메시지를 중간에서 전달해주는 역할을 하는 소프트웨어입니다. 일반적으로 요청을 보내는 쪽을 Producer, 메시지를 처리하는 쪽을 Consumer라고 합니다. Producer는 Consumer를 직접 호출하지 않고 메시지 브로커에 메시지를 전달합니다. 이후 Consumer는 메시지 브로커에서 메시지를 가져와 필요한 작업을 처리합니다.

 

Producer → Message Broker → Consumer

 

예를 들어 주문이 완료되었을 때 주문 서비스가 알림 서비스, 배송 서비스, 재고 서비스를 직접 호출할 수 있습니다. 하지만 이 경우 각 서비스의 장애나 응답 지연이 주문 처리 흐름에 영향을 줄 수 있습니다.

메시지 브로커를 사용하면 주문 서비스는 "주문 완료" 메시지만 브로커에 전달하고, 알림 서비스·배송 서비스·재고 서비스는 각자 필요한 메시지를 받아 처리할 수 있습니다.

주문 서비스 → 메시지 브로커 → 알림 서비스

주문 서비스 → 메시지 브로커 → 배송 서비스

주문 서비스 → 메시지 브로커 → 재고 서비스

 

즉, 메시지 브로커는 시스템 사이의 중간 전달자 역할을 하며, 서비스 간 결합도를 낮추고 비동기 처리를 가능하게 합니다.

 

메시지 브로커가 필요한 이유

메시지 브로커를 사용하는 이유는 크게 세 가지로 볼 수 있습니다.

1. 비동기 처리

사용자의 요청 중에는 응답 전에 반드시 끝나야 하는 작업도 있지만, 응답 이후에 처리해도 되는 작업도 있습니다. 예를 들어 회원가입 자체는 즉시 완료되어야 하지만, 환영 이메일 발송은 나중에 처리되어도 됩니다.

이처럼 핵심 요청과 분리할 수 있는 작업을 메시지 브로커로 넘기면, 서버는 사용자에게 더 빠르게 응답하고 부가 작업은 Consumer가 비동기로 처리할 수 있습니다.

 

2. 서비스 간 결합도 감소

주문 서비스가 알림 서비스, 배송 서비스, 재고 서비스의 API를 직접 호출하면 각 서비스의 장애나 변경이 주문 서비스에 직접적인 영향을 줄 수 있습니다. 그렇기에 메시지 브로커를 사용하면 각 서비스는 메시지를 기준으로 느슨하게 연결할 수 있습니다.

 

3. 장애 대응

Cosumer가 일시적으로 장애가 나더라도 메시지 브로커에 메시지가 남아 있다면, Consumer가 복구된 후 다시 메시지를 처리할 수 있습니다.

 

메시징 모델

메시지 브로커는 메시지를 전달하는 방식에 따라 여러 모델로 나누어 볼 수 있습니다.
대표적으로 점대점 모델(Point-to-Point) 과 게시/구독 모델(Publish/Subscribe) 이 있습니다.

두 모델은 모두 Producer가 메시지를 보내고 Consumer가 메시지를 처리한다는 공통점이 있지만, 하나의 메시지를 누가 소비하는지에서 차이가 있습니다.

1. 점대점 모델

점대점 모델은 하나의 메시지를 하나의 Consumer가 처리하는 방식입니다.

 

Producer가 메시지를 Queue에 넣으면, Consumer는 Queue에 쌓인 메시지를 가져가 처리합니다. 여러 Consumer가 같은 Queue를 바라보고 있더라도, 하나의 메시지는 보통 하나의 Consumer에게만 전달됩니다.

Producer → Queue → Consumer

여러 Consumer가 있는 경우 다음과 같이 작업을 나누어 처리할 수 있습니다.

Producer → Queue → Consumer A
                 → Consumer B
                 → Consumer C

예를 들어 이메일 발송 작업이 1,000건 쌓여있다고 가정해보겠습니다. 하나의 Consumer가 모든 이메일을 처리하면 시간이 오래 걸릴 수 있습니다. 이때 여러 Consumer가 같은 Queue에서 메시지를 하나씩 가져가 처리하면 작업을 분산해서 처리할 수 있습니다.

 

즉, 점대점 모델은 "해야 할 작업을 Queue에 쌓고, 가능한 Consumer가 하나씩 가져가 처리하는 구조"에 가깝습니다.

 

2. 게시/구독 모델

게시/구독 모델은 하나의 메시지를 여러 Consumer가 받아 처리할 수 있는 방식입니다.

 

Producer는 메시지를 특정 Topic에 발행합니다. 그리고 해당 Topic을 구독하고 있는 Consumer들이 메시지를 받아 각자의 작업을 처리합니다

Producer → Topic → Consumer A
                → Consumer B
                → Consumer C

예를 들어 주문이 완료되었을 때 "주문 완료" 이벤트가 발생했다고 가정해보겠습니다. 이 이벤트는 알림 서비스, 배송 서비스, 통계 서비스가 모두 필요로 할 수 있습니다.

주문 완료 이벤트
 → 알림 서비스: 주문 완료 알림 발송
 → 배송 서비스: 배송 준비 요청
 → 통계 서비스: 매출 통계 반영

이때 게시/구독 모델을 사용하면 주문 서비스는 "주문 완료" 이벤트를 한 번만 발행하면 됩니다. 이후 해당 이벤트를 구독하는 여러 서비스가 각자 필요한 작업을 처리합니다.

 

즉, 게시/구독 모델은 "하나의 이벤트를 여러 시스템이 각자의 목적에 맞게 소비하는 구조"에 가깝습니다.

 

동기 처리와 비동기 처리

메시지 브로커를 이해하기 위해서는 동기 처리와 비동기 처리의 차이를 먼저 이해하는 것이 좋습니다.

동기 처리는 요청을 보낸 뒤 결과가 돌아올 때까지 기다리는 방식입니다. 반면 비동기 처리는 요청을 보낸 뒤 결과를 기다리지 않고 다음 작업을 진행할 수 있는 방식입니다.

구분	동기 처리	비동기 처리
처리 방식	결과가 올 때까지 기다림	요청 후 다음 작업 진행 가능
장점	흐름이 단순하고 결과 확인이 쉬움	응답 시간을 줄이고 작업 분리가 쉬움
단점	처리 시간이 길어질 수 있음	처리 결과 추적이 필요함
예시	결제 승인 결과 확인	이메일 발송, 알림 발송, 로그 저장

모든 작업을 비동기로 처리하는 것이 좋은 것은 아닙니다. 결제 승인, 좌석 예약, 재고 차감처럼 즉시 결과가 중요하고 데이터 정합성이 필요한 작업은 동기적으로 처리하는 것이 더 적절할 수 있습니다. 반면 알림 발송, 로그 저장처럼 요청의 핵심 결과에 직접 영향을 주지 않는 작업은 비동기 처리로 분리하기 좋습니다.

 

RabbitMQ란?

RabbitMQ는 메시지를 Queue에 저장하고 Consumer에게 전달하는 방식에 강점이 있는 메시지 브로커입니다. RabbitMQ에서는 Producer가 메시지를 보내면 Exchange가 메시지를 어떤 Queue로 보낼지 결정하고, Consumer는 Queue에 쌓인 메시지를 가져가 처리합니다. 그렇기에 작업 큐, 알림 발송, 이메일처럼 메시지를 안정적으로 전달하고 작업을 분산 처리해야 하는 상황에서 자주 사용됩니다.

 

Producer → Exchange → Queue → Consumer

RabbitMQ의 특징은 메시지를 Consumer에게 전달하고, Consumer가 처리 완료를 알리면 메시지를 제거하는 방식에 가깝습니다. 따라서 특정 작업을 안정적으로 처리해야 하는 작업 큐 구조에 적합합니다.

 

Kafka란?

Kafka는 대량의 이벤트 데이터를 빠르게 저장하고 처리하는 데 강점이 있는 분산 이벤트 스트리밍 플랫폼입니다. Kafka에서는 메시지를 Topic에 저장하고, Consumer는 자신이 읽은 위치인 Offset을 기준으로 메시지를 가져갑니다. 메시지는 Consumer가 읽었다고 바로 삭제되지 않고, 설정된 보관 기간 동안 저장될 수 있습니다. 이러한 특징 때문에 Kafka는 로그 수집, 사용자 행동 이벤트 처리, 실시간 데이터 파이프라인, 대규모 이벤트 처리에 많이 사용됩니다.

Producer → Topic → Partition → Consumer

Kafka는 메시지를 단순히 전달하는 것보다 이벤트를 일정 기간 저장하고 여러 Consumer가 각자의 속도에 맞게 읽을 수 있다는 점이 특징입니다.

 

RabbitMQ와 Kafka의 차이

RabbitMQ는 "해야 할 작업을 Queue에 넣고 Consumer가 처리하는 구조"에 가깝고, Kafka는 "발생한 이벤트를 Topic에 기록하고 여러 Consumer가 필요한 시점에 읽는 구조"에 가깝습니다.

구분	RabbitMQ	Kafka
중심 개념	Queue 기반 메시지 전달	Topic 기반 이벤트 스트리밍
메시지 처리 방식	Consumer가 처리하면 메시지 제거	메시지를 일정 기간 저장
강점	작업 큐, 안정적인 메시지 전달	대량 이벤트 처리, 로그/스트리밍
Consumer 방식	메시지를 전달받아 처리	Offset 기준으로 메시지를 읽음
적합한 상황	이메일 발송, 알림 처리, 작업 분산	로그 수집, 실시간 분석, 이벤트 파이프라인
관점	메시지 브로커	이벤트 스트리밍 플랫폼

 

어떤 상황에서 사용할까?

메시지 브로커는 다음과 같은 상황에서 사용할 수 있습니다.

상황	설명
이메일 발송	회원가입 후 환영 이메일을 비동기로 발송
알림 처리	주문 완료, 댓글 작성, 좋아요 발생 시 알림 전송
이미지 처리	이미지 업로드 후 썸네일 생성 작업 분리
로그 수집	사용자 행동 로그, 서버 로그를 모아 분석
주문 후속 처리	주문 완료 후 재고, 배송, 알림 작업 분리
이벤트 기반 구조	서비스 간 직접 호출 대신 이벤트로 연결

 

예를 들어 SNS 서비스에서 사용자가 댓글을 작성했을 때, 댓글 저장은 즉시 처리되어야 하지만 알림 발송은 비동기로 분리할 수 있습니다. 댓글 저장이 성공한 뒤 "댓글 작성 이벤트"를 메시지 브로커에 전달하고, 알림 서비스가 해당 메시지를 소비해 알림을 보내는 방식입니다.

---

  다음 시간에는 컨테이노화와 가상화 그리고 Docker에 대해서 얘기해보도록 합시다. 수고하셨습니다.