Message Queue

Message Queue

메시지 큐(Message Queue) : 애플리케이션 간에 비동기적으로 메시지를 교환하는 소프트웨어 패턴.
메신저 특성 상 사용자 많아지고 채팅 양 늘어나면 대용량 데이터 실시간으로 전달해야 하는데 기존의 동기식 요청-응답 방식에서의 문제점을 해결하기 위해 pub/sub 방식을 메시지 큐를 사용.

메시지 큐에서 메시지는 end-point 간 직접 통신x, 중간에 큐를 통해 중개.

메시지 흐름 순서
1. 메시지 전송
2. producer는 해당 메시지 큐에 추가
3. 메시지 임시 저장
4. consumer가 호출
5. 큐에서 삭제

대부분의 마이크로 서비스 아키텍쳐(MSA) 에서 메시지 큐를 활용한 비동기 패턴을 사용한다.
그 이유는? -> MSA에서는 시스템 간 호출 많기 때문에 서비스 간 결합도 낮춰야 함. 비동기 요청, 성능, 안정정 때문 + DB 활용의 이점.

장점
1. 비동기 : 임시 저장소(큐) 있기 때문에 나중에 처리 가능
2. 낮은 결합도 : 어플리케이션과 분리
3. 확장성
4. 탄력성 : 소비자 서비스 다운되어도 어플리케이션 중단x, 메시지는 mq에 남아있음.
5. 보장성 : mq에 들어가면 결국 모든 메시지 소비자 서비스에 전달된다는 보장 제공.

메시지 큐 지정 하지 않을 시

메시지 큐 지정

유저 서비스의 사용자 많아져 컨테이너 오케스트레이션 툴(쿠버네티스 등)에 의해 scale-out하여 두개의 컨테이너를 생성.

이때 동일 서비스의 데이터 분산되어 저장됨 -> 동기화 어떻게?
사용자는 API gateaway 요청에 따라 다른(무결하지 않은) 데이터 가져올 수 있음.

해결 방안 1 : 하나의 서비스 인스턴스가 Scale-Out 된다 하더라도 동일한 데이터베이스를 사용

여러 인스턴스가 동일 DB 보고 작업하게 된다면 트랜잭션과 Isolation Level (고립 수준) 에 관한 문제가 발생!

해결 방안 2 : Message Queue 사용

트랜잭션, 고립 수준 관리보다 간단한 방식인 DB 동기화로 쉽게 해결 가능.

메시지 큐잉 서비스 : 마이크로 서비스 구조에서 인스턴스 확장돼도 분산 시스템, 데이터 동기화 문제 간단하게 해결 돕는 메시지 대기열 미들웨어.

주로 Kafka, RabbitMQ와 같은 메시지 브로커 사용해 메시지 구현.
메시지 브로커 : pub(송신자)로부터 전달받은 메시지 sub(송신자)에게 정달해주는 중간 역할로 메시지 교환 도움. 이때 메시지 적재되는 공간을 메시지 큐라고 하고 메시지의 그룹을 topic 이라고 한다.

메시지 큐 서버 구성하는 방법 1 : 인스턴스 각각 다른 DB 운영하여 큐잉 서버에 구독

메시지 큐 서버 구성하는 방법 2 : DB 하나 운영하여 중간에 큐잉 서버 두는 방식

kafka, RabbitMQ

kafka : LinkedIn에서 개발된 mq 방식 기반의 분산 메시징 시스템.
but Apache Kafka is not a traditional message queue. 분산 스트리밍 플랫폼.
You can think of Kafka as a message queuing system with a few tweaks.

pub/sub 모델로 봤을 때 publisher(producer) , subscriber(consumer), kafka cluster로 구성됨.

Kafka 동작 원리
1. pub은 전달하려는 메시지를 topic 통해 카테고리화.
2. sub은 원하는 topic을 구독해 메시지를 읽음.
3. pub, sub은 topic 정보만 알고 서로에 대해서는 x.
4. kafka는 broker들이 하나의 클러스터로 구성되어 동작하도록 설계
5. 클러스터 내 broker에 대한 분산처리는 ZooKeeper가 담당.

카프카에서 하나의 메시지는 topic으로 분류됨.
하나의 topic은 여러개의 partition으로 분산. 왜? -> 병렬로 처리 위해.

broker : kafka 서버 의미.
zookeaper : 분산 mq의 정보를 관리하는 역할로 필수적인 요소.

카프카는 큐 구현하지 않고 대신에 토픽(topic)라고 불리는 카테고리에 데이터 집합을 저장.
각각의 topic에 Kafka는 분할된 메세지 로그를 가지고 있음.
하나의 topic에 하나의 파티션 혹은 여러개의 파티션을 가질 수 있음.
각 파티션은 메세지가 지속적으로 추가되며 데이터 순서가 정해져있고, 내용이 바뀌지 않는다.

topic은 파일 시스템의 폴더와 유사하고, 파티션은 메세지를 저장하는 물리적 파일.
producer는 어떤 토픽에 저장할지 선택하고, consumer는 어떤 토픽을 구독할지 정함. 즉 pub/sub은 토픽을 기준으로 메세지 교환.

RabbitMQ : AMQP 프로토콜을 구현한 메시지 브로커. Message Broker의 구현체로 기본적으로 전통적인 Message Queue 방식 지원.
AMQP (Advanced Message Queuing Protocol) : 메시지 지향 미들웨어를 위한 개방형 표준 응용 계층 프로토콜

exchange : pub이 전달한 메시지를 큐에 전달하는 역할.
RabbitMQ에서 메시지는 바로 큐에 들어가지 않고 exchage에게 전달 -> exchange가 큐에 메시지를 넣는 역할을 수행.

kafka vs RabbitMQ

큐와 exchange를 기반으로 메시지 브로커의 구현체인 RabbitMQ와 달리 Kafka는 분산 스트리밍 플랫폼.

1. kafka는 pub/sub 방식, RabbitMQ는 메시지 브로커 방식
   kafka의 pub/sub 방식은 생산자 중심적 설계로 구성. 생성자가 원하는 각 메시지를 게시할 수 있도록 하는 메시지 배포 패턴으로 진행.
   
   RabbitMQ의 메시지 브로커 방식은 브로커 중심적인 설계로 구성. 지정된 수신인에게 메시지를 확인, 라우팅, 저장 및 배달하는 역할을 수행하며 보장되는 메시지 전달에 초점.

2. 전달 메시지의 휘발성
   RabbitMQ는 큐에 저장되어 있던 메시지를 소비자가 가져가면 큐에서 해당 메시지 삭제.
   
   but kafka는 생성자로부터 메시지가 들어오면 해당 메시지를 topic으로 분류하고 이를 event streamer에 저장.
   수신자이 특정 topic에 대한 메시지 가져가도 event streamer는 해당 topic을 계속 유지하기 때문에 특정 상황이 발생해도 재생이 가능.

3. 용도의 차이
   kafka는 클러스터를 통해 병렬처리가 주요 차별점인 만큼 방대한 양의 데이터를 처리에 장점.
   Kafka의 메시지 보존은 메시지 로거 또는 거대하고 빠른 데이터 스트리밍 서버에 적합. 실패 후 메시지를 다시 시도해야 하는 책임은 소비자에게 있으므로 Kafka는 메시지가 성공적으로 전달되었는지 여부를 신경 쓰지 않음. -> 추가 구현을 덜어주고 데이터 재생 및 쿼리에 중점.
   
   RabbitMQ는 메시지 보존이 부족하고 소비자의 확인 메시지가 보장되므로 강력한 메시지 브로커인 응용 프로그램 중재자에 더 적합

메시지 브로커와 Publish/Subscribe 메시징 시스템 방식의 차이

둘 다 메시지 전달 패턴을 구현하는 데 사용되지만, 다음과 같은 차이점이 존재.

1. 메시지 전달 방식
메시지 브로커 : 메시지 브로커는 송신자가 메시지를 직접 브로커에게 전송하고, 수신자는 해당 브로커에서 메시지를 가져옴. 송신자와 수신자 사이에 직접적인 통신은 없고 브로커를 통해 중개되는 방식.

pub/sub : pub/sub은 송신자가 메시지를 특정 주제(topic)에 발행(pub)하고, 이를 구독(sub)한 수신자들이 해당 주제의 메시지를 수신. 송신자와 수신자 간에는 직접적인 통신 없고, 중앙 조정 없이 메시지를 구독한 모든 수신자들에게 전달됨.

2. 구독자 관리
메시지 브로커 : 메시지 브로커는 메시지를 받을 구독자를 관리. 송신자는 메시지를 브로커에게 보내면, 브로커는 해당 메시지를 구독한 구독자들에게 전달.

pub/sub : pub/sub에서 송신자는 메시지를 특정 주제에 발행하고 해당 주제를 구독한 수신자들은 메시지 수신. 송신자는 구독자를 관리 x, 단순히 주제에 메시지 발행만 하면 됨.

3. 유연성
메시지 브로커 : 메시지 브로커는 일반적으로 발행자와 구독자 간의 결합도가 낮고 중개자 역할을 수행하기 때문에 유연성이 높다.
메시지를 중앙 집중적으로 관리하고 전달 -> 다양한 송신자와 수신자 간의 통신을 쉽게 구성할 수 있음.
pub/sub : pub/sub은 topic에 기반한 구독 관계 -> 메시지 발행과 구독의 결합도가 높다.
구독자는 특정 주제 구독하고 해당 주제에 대한 메시지만 수신.
따라서 구독자가 변경되거나 새로운 주제가 추가되는 경우 구독 관계를 조정해야 함.

정리
메시지 브로커는 메시지를 중앙 집중적으로 관리하고 전달하는 역할을 수행하는 시스템.
pub/sub은 topic에 기반한 구독 관계를 가지고 메시지를 수신하는 패턴.
메시지 브로커는 송신자와 수신자 사이에 중개 역할을 하고, 유연한 구성 가능.
pub/sub은 구독자가 특정 주제를 구독하고 해당 주제의 메시지만 수신하는 방식. 주제와 구독 관계에 집중.

Message brokers validate, route, store, and deliver messages to the designated recipients. 즉 브로커는 중개자 역할.
pub/sub은 broadcast-style distribution method. pub과 sub 사이에서 one-to-many 관계 갖는다.

<참고>
https://wonit.tistory.com/491
https://velog.io/@cho876/카프카kafka-vs-RabbitMQ
https://www.simplilearn.com/kafka-vs-rabbitmq-article
https://escapefromcoding.tistory.com/705