메세지 큐(Message Queue)❓

beluga000·2024년 8월 16일

메세지 큐 Message Queue

메세지 큐는 분산 시스템, 마이크로서비스 아키텍처, 대규모 데이터 처리 환경에서 중요한 역할을 하는 개념으로 소프트웨어 시스템에서 메세지를 비동기적으로 송수신하기 위한 통신 방식이다.

메세지(Message)

메세지는 데이터를 표한하는 단위로, 송신자에서 수신자로 전달되는 정보

메세지 헤더(Massage Header) : 메세지의 메타데이터로, 메세지의 크기, 형식, 우선순위, 송신자 정보 등을 포함할 수 있습니다.
메세지 바디(Message Body) : 실제 데이터가 담긴 부분으로, 예를 들어 JSON, XML, 또는 이진 데이터 형식이 될 수 있습니다.
속성(Properties) : 메세지에 추가적인 정보를 포함할 수 있으며, 메세지 처리에 필요한 정보를 담습니다.

큐(Queue)

메세지 큐는 데이터를 일시적으로 저장하는 구조로 일반적인 큐와 유사하게 메세지 큐는 선입선출(FIFO)방식으로 동작합니다.

비동기성 : 송신자는 메세지를 큐에 넣고, 수신자는 필요할 때 큐에서 메세지를 꺼내 처리합니다. 이렇게 하면 송신자와 수신자가 동시에 동작할 필요가 없으므로, 시스템의 유연성이 향상됩니다.
내구성(Durability) : 메세지 큐는 메세지를 안전하게 저장하고, 수신자가 메세지를 처리할 준비가 될 때까지 메세지를 보관합니다. 이를 위헤 메세지를 디스크에 기록하거나 복제하여 내구성을 보장할 수 있습니다.
우선순위 큐 : 메세지에 우선순위를 부여하여 특정 메세지가 먼저 처리되도록 할 수 있습니다.

메세지 브로커(Message Broker)

메세지 브로커는 메세지 큐를 관리하고, 송신자와 수신자 간의 메세지를 전달하는 시스템입니다.

라우팅(Routing) : 특정 규칙에 따라 메세지를 적절한 큐로 라우팅합니다. 예를 들어 토픽(topic) 기반 라우팅에서는 메세지가 특정 주체에 따라 분류됩니다.
메세지 전달 보장(Delivery Guarantee) : 메세지가 한 번만 또는 적어도 한 번 전달되는 것을 보장하는 메커니즘을 제공합니다.
메세지 변환(Message Transformation) : 메세지 형식을 변환하거나, 메세지에 대한 간단한 처리를 수행할 수 있습니다.

대표적인 메세지 브로커는 RabbitMQ와 Apache Kafka가 있습니다.
RabbitMQ는 주로 AMQP 프로토콜을 사용하며, 다양한 라우팅 옵션을 제공하여 복잡한 메세지 전달 시나리오를 처리할 수 있습니다.
Apache Kafka는 높은 처리량과 내구성을 제공하며, 대규모 데이터 스트리밍과 실시간 로그 분석 등에 많이 사용됩니다.

메세지 큐의 동작 방식

메세지 큐의 기본 동작은 송신자가 메세지를 큐에 넣고, 수신자가 큐에서 메세지를 꺼내 처리하는 방식입니다. 하지만 실제 환경에서는 다양한 패턴과 구성 요소가 추가될 수 있습니다.

출판-구독(Publish-Subscribe)모델 : 여러 수신자가 특정 토픽에 구독하여, 하나의 메세지를 여러 수신자가 동시에 받을 수 있는 모델
작업 대기열(Task Queue) : 시간이 많이 소요되는 작업을 비동기로 처리하기 위해 작업을 큐에 넣고, 수신자가 이 작업을 처리합니다. 예를 들어, 이미지 처리나 데이터베이스 업데이트 등의 작업이 여기에 해당합니다.
지속성 메세지(Persistent Message) : 메세지가 손실되지 않도록 디스크에 저장되는 메세지로, 시스템 장애 시에도 메세지가 보존됩니다.
확인(Acknowledgement) : 수신자가 메세지를 성공적으로 처리했음을 송신자에게 알리는 메커니즘입니다. 이 확ㅇ니 메세지는 메세지가 성공적으로 처리되었을 때만 삭제되도록 보장합니다.

메세지 큐 작동 방식의 예시

예를 들어 온라인 쇼핑몰의 주문 처리를 진행한다고 하면 아래와 같은 작업을 수행해야합니다.
1. 주문 데이터를 데이터베이스에 저장
2. 결제 처리
3. 재고 확인
4. 고객에게 주문 확인 이메일 발송
5. 배송 준비 및 추저 번호 생성

이러한 패턴을 메세지 큐를 사용한 비동기 처리와 메세지 큐 없이 동기 처리로 구분해보겠습니다.

1️⃣ 메세지 큐 없이 동기 처리

메세지 큐 없이 모든 작업을 동기적으로 처리하는 상황을 가정
1. 고객이 주문 버튼을 클릭하면 서버는 모든 작업을 순차적으로 처리
2. 주문 데이터 저장 -> 결제 처리 -> 재고 확인 -> 이메일 발송 -> 배송 준비
3. 이 모든 과정이 끝날 떄까지 고객은 웹 페이지에서 대기해야 합니다.

이러한 경우 만약 결제 처리 단계에서 네트워크 지연이 발생하면 전체 프로세스가 지연되고, 고객 경험에는 나쁜 영향일 미칠 수 있습니다. 또한 만약 하나의 작업이 실패하면 이후 작업들이 모두 중단됩니다.

2️⃣ 메세지 큐를 사용한 비동기 처리

주문 메세지 생성
고객이 주문 버튼을 클릭하면, 서버는 "주문 생성" 메세지를 생성하여 메세지 큐에 넣습니다. 이 메세지는 주문에 대한 모든 필요한 정보가 포함됩니다.
메세지 큐에 메세지 저장
"주문 생성" 메세지는 메세지 큐에 저장됩니다. 이 메세지는 순차적으로 처리할 수신자에게 전달될 준비가 되었습니다.
비동기 작업 처리

결제 서비스 : 메세지 큐에서 "주문 생성" 메세지를 가져와 결제를 처리합니다. 결제가 완료되면 "결제 완료" 메세지를 또 다른 큐에 넣습니다.
재고 서비스 : 메세지 큐에서 "주문 생성" 메세지를 가져와 재고를 확인합니다. 재고가 충분하면 "재고 확인 완료" 메세지를 큐에 넣습니다.
이메일 서비스 : 메세지 큐에서 "주문 생성" 메세지를 가져와고객에게 주문 확인 이메일을 보냅니다.
배송 서비스 : "결제 완료" 메세지를 가져와 배송 준비를 합니다. 배송 준비가 완료되면 "배송 준비 완료" 메세지를 큐에 넣습니다.

고객 반응
서버는 메세지를 큐에 넣은 후 즉시 고객에게 주문이 접수되었음을 알립니다. 고객은 모든 작업이 백그라운드에서 처리되는 동안 대기할 필요가 없습니다.
각 작업의 독립성
결제, 재고 확인, 이메일 발송, 배송 준비 등 모든 작업은 서로 독립적을 처리됩니다. 만약 결제 단계에서 문제가 발생해도, 다른 작업들은 계속 진행될 수 있으며, 결제 서비스가 다시 작동할 때 결제 처리를 재시도할 수 있습니다.