What is the message queue?
메시지 큐(Message Queue)는 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중의 하나로, 메시지 지향 미들웨어(Message Oriented Middleware:MOM)를 구현한 시스템을 의미한다.
메시지 지향 미들웨어란 비동기 메시지를 사용하는 응용 프로그램들 사이에서 데이터를 송수신하는 것을 의미한다.
메시지는 처리되고 삭제되기 전까지 대기열에 저장되며, 각 메시지는 하나의 소비자가 한 번만 처리한다.
MessageQueue를 사용하면 서로 다른 시스템 간에 비동기식으로 작업을 처리할 수 있습니다. MQ는 메시지를 임시로 저장하는 간단한 버퍼를 제공하고, 메시지를 전송 및 수신하기 위해 소프트웨어 구성 요소가 대기열에 연결하도록 허용하는 엔드포인트를 제공한다.
메시지를 전송하려면 Producer라고 부르는 구성요소가 메시지를 Queue에 추가한다. 해당 메시지는 Consumer라고 부르는 또 다른 구성요소가 메시지를 검색하고 메시지를 사용해 어떤 작업을 수행할 때 까지 대기열에 저장된다.
많은 생산자와 소비자가 대기열을 사용할 수 있지만, 각 메시지는 하나의 소비자에 의해 한 번만 처리된다.
이러한 이유로 메시징 패턴을 일대일 또는 지점 간 통신이라 부른다.
둘 이상의 소비자가 메시지를 처리해야 하는 경우, 메시지 대기열을 Pub/Sub 메시징과 결합할 수 있다. --> Kafka
Message Queue의 이점
- 비동기(Asynchronous)
메시지 큐는 메시지의 저장, 전송에 대해 동기화 처리를 하지 않고, 큐에 넣어 두기 때문에 컨슈머는 메시지를 필요할 때 처리할 수 있다. 기존 동기화 방식은 많은 메시지(데이터)가 전송될 경우 병목이 생길 수 있고, 뒤에 들어오는 요청에 대한 응답이 지연될 수 있다. - 낮은 결합도(Decoupling)
생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아진다. - 확장성(Scalable)
생산자 서비스 혹은 소비자 서비스를 원하는 대로 확장할 수 있기 때문에 확장성이 좋다. - 회복 탄력성(Resilience)
소비자 서비스가 다운되더라도 어플리케이션이 중단되는 것은 아니다. 메시지는 메시지 큐에 남아 있다. 소비자 서비스가 다시 시작될 때마다 추가 설정이나 작업을 수행하지 않고도 메시지 처리를 시작할 수 있다. - 보장성(Guarantees)
메시지 큐는 큐에 보관되는 모든 메시지가 결국 소비자 서비스에게 전달된다는 일반적인 보장을 제공한다.
Message Broker와 Pub/Sub Messaging System의 차이
메시지 브로커는 응용 프로그램, 서비스 및 시스템이 정보를 통신하고 교환할 수 있도록 하는 소프트웨어 모듈입니다. 메시지 브로커는 공식 메시징 프로토콜 간에 메시지를 번역하여 상호 의존적인 서비스들이 서로 다른 언어로 작성되거나 다른 플랫폼에서 실행되는 경우에도 서로 직접 "대화"할 수 있도록 한다.
메시지 브로커는 지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달한다. 브로커들은 다른 응용 프로그램들 사이의 중개자로서 작동하며, 송신자들이 소비자의 위치, 활성 상태 또는 얼마나 많은 소비자가 존재하는지 알지 못한 채 메시지를 발행하도록 한다.
반면에 Pub/Sub Messaging System의 Publish/Subscribe는 프로듀서가 원하는 각 메시지를 게시할 수 있는 메시지 배포 패턴이다.
broadcast-style distribution method라고도 하며, publisher와 consumer간의 일대다 관계를 특징으로 한다.
* RabbieMQ?
AMQP 프로토콜을 구현한 메시지 브로커이다.
** AMQP : Client와 Middleware broker간에 메시지를 주고받기 위한 프로토콜
Kafka와 다르게 Queue로 들어가기 전 Exchange(2번)라는 하나의 단계를 더 거친다.
RabbitMQ에서 메시지는 바로 queue에 들어가지 않고 exchange를 통해 queue에 들어간다.
Exchange는 전달받은 메시지들을 어떤 queue들에게 발송할지 정하는 객체로 일종의 라우터 개념이다.
Binding은 exchange에게 메시지를 라우팅할 규칙을 지정하는 행위이다. 특정 조건에 해당하는 메시지를 특정 큐에 전송하도록 설정할 수 있는데, 이는 해당 exchange 타입에 맞게 설정되어야 한다. (Exchange:Queue=M:N binding)
** Exchange 참고 : https://blog.dudaji.com/general/2020/05/25/rabbitmq.html
RabbitMQ는 백그라운드 작업이나 PDF 변환, 파일 검색 또는 이미지 확장과 같은 장기 실행 작업도 처리할 수 있다.
MessageBroker(RabbitMQ) vs Pub/Sub Messaging System(Kafka)
- kafka는 pub/sub 방식 / RabbitMQ는 메시지 브로커 방식
kafka의 pub/sub방식은 생산자 중심적인 설계로 구성되어 생성자가 원하는 각 메시지를 게시할 수 있도록 하는 메시지 배포 패턴으로 진행한다.
RabbitMQ의 메시지브로커방식은 브로커 중심적인 설계로 구성되어 지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메시지 전달에 초점 - 전달된 메시지에 대한 휘발성
RabbitMQ는 queue에 저장되어 있던 메시지를 Event Consumer가져가게 되면 queue에서 해당 메시지를 삭제한다.
하지만, kafka는 생성자로부터 메시지가 들어오면 해당 메시지를 topic에 저장한다. consumer가 topic을 구독하여 메시지를 컨슈밍하더라도 해당 topic의 메시지는 삭제되지 않는다. (한 토픽에 여러 consumer가 구독 가능) - 용도의 차이
kafka는 클러스터를 통한 병렬처리가 주요 차별점인 만큼 방대한 양의 데이터를 처리할 때 장점이 부각된다.
RabbitMQ는 데이터 처리보단 Manage UI를 제공하는 만큼 관리적인 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 장점이 부각된다.
RabbitMQ vs Kafka
RabbitMQ
- 구성이 쉽다.
- 유연한 라우팅이 가능하면 관리 UI 가 편리하다.
- 제품 성숙도가 높다.
- 개방형 프로토콜을 위한 AMQP 를 구현 위해 개발
- 필요에 따라 동기/비동기식이 가능하다.
- 소비자중심의 설계
- 20k/sec 처리를 보장
Apache Kafka
- 구독방식의 비동기식 구성
- 고성능 고가용성
- 분산처리에 효과적으로 설계 되었음
- 생산자 중심의 설계
- 범용 메세징 시스템에서 제공되는 다양한 기능은 제공되지 않는다.
- 100k/sec 처리를 보장
출처: https://ellune.tistory.com/29 [Ellune's Spadework:티스토리]
Conclusion
분산과 고성능을 추구한다면 카프카를 사용하는 것이 좋고 굳이 분산까지 해가며 트래픽을 감당할 규모가 아니라면 RabbitMQ가 나을 수 있다. 무조건 Kafka를 사용하는 것은 오버스팩일 수 있으니 잘 알아보고 용도에 맞게 사용하는 것이 필요하다.
References
https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/
https://aws.amazon.com/ko/message-queue/
https://www.simplilearn.com/kafka-vs-rabbitmq-article
https://velog.io/@cho876/%EC%B9%B4%ED%94%84%EC%B9%B4kafka-vs-RabbitMQ
'데이터 엔지니어링' 카테고리의 다른 글
| Kafka exactly-once delivery 지원 (0) | 2022.09.03 |
|---|---|
| Zookeeper ZNode란 무엇인가? (0) | 2022.08.30 |
| MapReduce vs Spark | 맵리듀스와 스파크의 차이점 (0) | 2022.08.13 |
| Spark RDD, DAG란? (0) | 2022.08.12 |
| Data Lifecycle Management(DLM) 란? (0) | 2022.08.11 |
댓글