카테고리 없음

[Kafka] 메시지큐(Message Queue)와 메시지 브로커(Message Broker)

늘이 2023. 12. 6. 09:31

 

Q. 메시지 큐와 메시지 브로커는 같은 말 일까?
A. 비슷하지만 다른 말!

 

1. 메시지 큐(Message Queue)

  • 메시지를 순차적으로 저장하고 전달하는 큐 시스템
  • 메시지를 줄 세워 놓는 큐 구조
  • 송신자가 메시지를 넣고, 수신자가 순서대로 꺼내가는 구조
  • FIFO(선입선출) 방식이 일반적
  • 단순히 메시지를 안전하게 전달하고 순서를 보장하는데 초점
  • 대표예시: RabbitMQ, Amazon SQS

 

👇🏻 자세한 설명

더보기

메시지 큐(Message Queue)는 분산 시스템에서 다양한 컴포넌트 간에 비동기적으로 데이터를 교환할 수 있게 해주는 중간 매개체입니다. 메시지 큐는 송신자(Sender)가 메시지를 생성하고, 이를 메시지 큐에 전송하며, 수신자(Receiver)가 메시지 큐에서 메시지를 받아 처리하는 형태로 동작합니다. 이는 각 컴포넌트가 독립적으로 작동하고, 서로 간섭 없이 통신할 수 있도록 도와줍니다.

  1. 메시지(Message): 데이터 교환의 단위입니다. 메시지는 텍스트, JSON, 바이너리 등 다양한 형식일 수 있습니다. 메시지에는 컴포넌트 간 통신에 필요한 정보가 포함되어 있습니다.
  2. 메시지 큐(Message Queue): 메시지를 저장하고 전달하는 시스템입니다. 이는 일종의 중간 매개체로서, 송신자와 수신자 간의 결합도를 낮추고 확장성을 높입니다.
  3. 송신자(Sender): 메시지를 생성하고 메시지 큐에 전송하는 역할을 하는 컴포넌트입니다.
  4. 수신자(Receiver): 메시지 큐에서 메시지를 받아와서 처리하는 역할을 하는 컴포넌트입니다.
  5. 큐(Queue): 메시지가 저장되는 장소입니다. 일반적으로 선입선출(FIFO) 원칙에 따라 동작하며, 새로운 메시지는 뒤에 추가되고, 앞에서부터 하나씩 꺼내져 처리됩니다.

메시지 큐의 장점 중 하나는 통신의 비동기성을 통해 컴포넌트 간의 의존성을 낮추고, 확장성을 향상시킬 수 있다는 것입니다. 또한, 시스템 장애 시에도 메시지는 여전히 큐에 남아 있어 중요한 데이터의 유실을 방지할 수 있습니다. 예를 들어, 대규모 웹 애플리케이션에서 로깅, 이벤트 처리, 통계 수집 등에 활용됩니다.

대표적인 메시지 큐 시스템에는 RabbitMQ, Amazon SQS 등이 있습니다.

 

 

메시지 큐를 사용하는 이유

  • 단순한 동기식 방식에 비해서 더 뛰어난 응답 속도를 보여줌
  • 기존의 동기식 통신 방식은 사용자로부터 요청을 받아서 요청을 다 처리할 때 까지 블로킹 상태에 빠지게 됨(요청이 전부 처리 되어야 사용자에게 응답을줌)
  • 메시지 큐를 이용하는 경우 사용자에게 요청을 받으면 큐에 집어 넣기만하면 바로 다음 사용자의 요청을 받아들일 수 있기 때문에 응답 속도가 향상되게 됨(실제 처리는 쌓여진 큐에서 다른 워커 프로세스가 1개씩 가져가서 처리하는 방식)
  • Node.js와 같은 비동기 방식 아키텍처를 적용한 시스템과 같은 경우 내부적으로 이벤트 큐를 이용하여 비동기를 구현함
  • 또한 메시지 큐를 이용해서 메시지를 주고 받을 수 있다는 사실과 객체지향에서의 메서드 호출이 다른 객체에게 해당 동작을 수행하라고 부탁하는 메시지를 보내는거라는 의미를 조합할 수 있음

 

 

2. 메시지 브로커(Message Broker)

  • 메시지를 주고받는 전체 통신을 중개하고 관리하는 시스템
  • 메시지 큐를 포함하는 더 큰 개념
  • 큐뿐 아니라 퍼블리시/서브스크라이브(pub/sub) 구조, 라우팅, 필터링, 포맷 변환 등 다양한 기능을 포함할 수 있음
  • 대표 예시: Kafka, RabbitMQ, ActiveMQ, Redis Pub/Sub

 

 

 

Q. Kafka는 왜 메시지 큐가 아닌가?
A. Kafka도 메시지를 순차적으로 저장하고 전달하기 때문에 메시지 큐처럼 동작하지만, 일반적인 메시지 큐와는 개념과 동작 방식이 다르다. Kafka의 설계 철학과 내부 구조는 분산 로그 시스템에 가깝다.

 

1. Kafka와 전통적인 메시지큐 비교

구분 Kafka 전통적인 메시지 큐
메시지 처리 방식 로그처럼 저장 (append-only) 큐처럼 저장 (FIFO + 제거)
메시지 삭제 시점 읽어도 삭제 안 됨 (보존 주기 설정 가능) 읽으면 즉시 삭제
메시지 재처리 오프셋만 조정하면 다시 읽을 수 있음 불가능 또는 복잡한 설정 필요
다수 Consumer Consumer Group 기준으로 분산 처리 일반적으로 하나의 Consumer만 읽음
저장 방식  디스크 기반 저장(내구성 보장) 메모리 기반, 디스크 옵션 존재
목적 실시간 스트리밍 & 이벤트 로그 저장 비동기 메시지 처리/작업 큐

 

2. Kafka와 RabbitMQ 비교

항목 Kafka RabbitMQ
개발 목적 실시간 스트리밍 데이터 처리 (대용량 이벤트 로그 저장 및 처리) 메시지 전달의 안정성과 보장 (비동기 통신, 작업 큐 중심)
메시지 저장 디스크 기반 저장 + 오프셋 기반 조회 기본적으로 메모리 기반 + 수신 확인 후 삭제
처리량 매우 높은 처리량 (수십만~수백만 TPS) 상대적으로 낮음 (수천~수만 TPS)
메시지 소비 Pull 방식 (Consumer가 직접 오프셋 관리) Push 방식 (브로커가 메시지 전달)
메시지 순서 파티션 단위로 순서 보장 큐 단위로 순서 보장 (여러 Consumer에선 순서 깨질 수 있음)
메시지 유지 오프셋 기준으로 데이터 유지 가능 (읽었는지와 무관) 읽은 메시지는 삭제 (기본값 기준)
내장 기능 Kafka Connect, Kafka Streams 등 데이터 파이프라인 전용 기능 풍부 다양한 플러그인 및 프로토콜 지원 (AMQP 등)
복잡도 설정과 구조가 상대적으로 복잡 초기 설정과 구조는 단순
사용 예 로그 수집, 실시간 모니터링, 데이터 레이크 연동, 이벤트 소싱 백엔드 작업 큐, 마이크로서비스 간 메시지 전송, RPC 스타일 처리

 

저작자표시 비영리 변경금지 (새창열림)