1. 이해
1-1. 메시지 큐(MessageQuque : MQ)
kafka와 rabbitMQ를 이해하기 위해선 우선 메시지 큐에 대한 이해가 선제적으로 필요하다.
메시지 큐(MessageQueue : MQ)란?
프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할 때 사용하는 통신 방법. 더 큰 의미로는 메시지 지향 미들웨어(MOM)를 구현한 시스템을 의미한다.
MQ에 대한 동작원리를 그림으로 표현한다면 아래와 같다.
용어 정리
1. producer: 정보를 제공하는 자
2. consumer: 정보를 제공받아서 사용하려는 자
3. Queue: producer의 데이터를 임시 저장 및 consumer에 제공하는 곳
우리가 주목해야 할 부분은 queue 이다.
MQ에서 메시지는 End-Point 간에 직접적으로 통신하지 않고 중간에 queue를 통해 중개된다는 점이다.
메시지 흐름에 대해 다시 한번 정리하자면 아래와 같다.
메시지 흐름 순서
1. 메시지 전송
2. producer는 해당 메시지를 queue에 추가
3. 해당 메시지는 consumer가 메시지를 검색하고 이를 사용하기 위한 작업 전까지 임시 저장
4. consumer에 의해 호출
5. 해당 메시지는 queue에서 삭제
기존 방식을 떠나 위와 같은 흐름을 갖는 MQ의 장점은 아래와 같다.
MQ 장점
1. 비동기: queue라는 임시 저장소가 있기 때문에 나중에 처리 가능
2. 낮은 결합도: 애플리케이션과 분리
3. 확장성: producer or consumer 서비스를 원하는대로 확장할 수 있음
4. 탄력성: consumer 서비스가 다운되더라도 애플리케이션이 중단되는 것은 아니며 메시지는 지속하여 MQ에 남아있다.
5. 보장성: MQ에 들어간다면 결국 모든 메시지가 consumer 서비스에게 전달된다는 보장을 제공한다.
1-2. kafka
kafka는 LinkedIn에서 개발된 메시지큐 방식 기반, 분산 메시징 시스템이다.
kafka의 기본 동작 원리를 그림을 통해 이해하자면 위와 같다고 볼 수 있다.
kafka는 pub-sub 모델 기반으로 크게 보자면 publisher(=producer), subscriber(=consumer), kafka cluster로 구성된다.
위 그림을 참고하여 동작원리에 대해 간단히 정리한다면 아래와 같다.
kafka 동작원리
- publisher는 전달하고자 하는 메시지를 topic을 통해 카테고리화 한다.
- subscriber는 원하는 topic을 구독(=subscribe)함으로써 메시지를 읽어온다.
- publisher와 subscriber는 오로지 topic 정보만 알 뿐, 서로에 대해 알지 못한다.
- kafka는 broker들이 하나의 클러스터로 구성되어 동작하도록 설계
- 클러스터 내, broker에 대한 분산처리는 ZooKeeper가 담당한다.
간단히 기재한 위 내용에 대해 부가적인 용어 설명을 더 해보도록 하겠다.
먼저, topic이라는 생소한 녀석에 대해 조금 더 들여다보도록 하자.
kafka에서 하나의 메시지는 topic으로 분류된다.
그리고 하나의 topic은 다수개의 partition으로 나뉘어진다.
왜 하나의 topic을 여러개의 partition으로 분산시키는가?
병렬로 처리하기 위해 분산 저장한다.
다음으로 앞서 동작흐름으로 첨부된 이미지 상, 언급된 broker/zookeaper에 대해 간단히 설명하자면 다음과 같다.
- broker: kafka 서버 의미
- zookeaper: 분산 메시지 큐의 정보를 관리하는 역할로 필수적으로 필요한 요소
그렇다면 가장 중요한 kafka만의 차별점은 무엇일까?
kafka 차별점
1. 메시지를 파일 시스템에 저장함으로써 영속성 보장
2. subscriber(=consumer)가 broker로부터 직접 메시지를 가지고 가는 pull방식으로 동작
3. publisher(=producer) 중심적인 형태로 많은 양의 데이터를 파티셔닝하는데 초점을 맞춘 시스템
4. subscriber가 전달 상태를 기억한다.
5. 방대한 양의 데이터를 처리할 때, 사용
1-3. RabbitMQ
RabbitMQ는 AMQP 프로토콜을 구현한 메시지 브로커이다.
AMQP란?
Client와 Middleware broker간의 메시지를 주고받기 위한 프로토콜
RabbitMQ의 동작원리를 간단히 그림으로 보자면 다음과 같다.
- publisher: 메시지를 보내는 쪽
- consumer: 메시지를 받는 쪽
- exchange: publisher가 전달한 메시지를 queue에 전달하는 역할
- queue: 메시지를 저장하는 버퍼
바로 queue로 들어가기 전, exchange라는 하나의 단계를 더 거친다는 점이다.
RabbitMQ에서 메시지는 곧바로 queue에 들어가지 않고 exchage에게 전달하면 exchange가 queue에 메시지를 넣는 역할을 수행한다.
이러한 방식으로 동작하는 RabbitMQ의 차별점은 무엇인지 간단히 정리해보자.
RabbitMQ의 차별점
1. Broker 중심적인 형태로 publisher와 consumer간의 보장되는 메시지 전달에 초점
2. 클러스터 구성이 쉽고 Manage UI가 제공되며 플러그인도 제공되어 확장성 뛰어남
3. 데이터 처리보단, 관리적 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 사용
2. kafka vs RabbitMQ
앞선 내용들을 통해 각각의 정의 및 프로세스에 대해 면밀히(?) 살펴봤다.
위 내용을 통해서도 kafka와 RabbitMQ의 차이에 대해 어느정도 이해할 수 있겠지만 본 글의 주제가 주제인만큼 다시 한번 간단히 정리해보도록 하겠다.
-
kafka는 pub/sub 방식 / RabbitMQ는 메시지 브로커 방식
kafka의 pub/sub방식은 생산자 중심적인 설계로 구성. 생성자가 원하는 각 메시지를 게시할 수 있도록 하는 메시지 배포 패턴으로 진행
RabbitMQ의메시지브로커방식은 브로커 중심적인 설계로 구성. 지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메시지 전달에 초점 -
전달된 메시지에 대한 휘발성
RabbitMQ는 queue에 저장되어 있던 메시지에 대해 Event Consumer가져가게 되면 queue에서 해당 메시지를 삭제한다.
하지만, kafka는 생성자로부터 메시지가 들어오면 해당 메시지를 topic으로 분류하고 이를 event streamer에 저장한다. 그 후, 수신인이 특정 topic에 대한 메시지를 가져가더라도 event streamer는 해당 topic을 계속 유지하기 때문에 특정 상황이 발생하더라도 재생이 가능하다. -
용도의 차이
kafka는 클러스터를 통해 병렬처리가 주요 차별점인 만큼 방대한 양의 데이터를 처리할 때, 장점이 부각된다.
RabbitMQ는 데이터 처리보단 Manage UI를 제공하는 만큼 관리적인 측면이나, 다양한 기능 구현을 위한 서비스를 구축할 때, 장점이 부각된다.
참고한 사이트
https://velog.io/@cho876/%EC%B9%B4%ED%94%84%EC%B9%B4kafka-vs-RabbitMQ
