메시지큐에 대하여

메시지큐는 왜 필요하며 여러가지 종류가 있다. 우리는 무엇을 어떻게 사용해야할까?

MSA에서 필요하다

이걸 메시지 지향 미들웨어(MOM)가 해준다

MOM이란?

메시지큐와 그 두 방식(메시지 부로커와 이벤트 브로커)

MSA에 필수적 요소, 메시지큐

MSA란?

• Micro Service Architecture는 작은 서비스이 모여 이루어진 구조로 느슨하게 결합된 서비스들로 애플리케이션을 구조화하는 개발 기법
• 전통적인 방식의 단일 구조(Monolithic)와 비교하였을 때 각 모듈들이 작은 단위의 Microservice로 나뉘어진 구조
• 위와 같은 구성 요소들이 있는데 이를 하나씩 성취하기 위해서는 서비스들끼리의 소통 필요
  • 중앙 관리 모듈과 서비스의 소통 (오토스케일링, Config 관리, 로깅)
  • 서비스와 서비스의 소통 (연계 서비스간 정보/산출물 전달)
• 그리고 이렇게 세분화된 서비스간의 소통에는 메시지 지향 미들웨어인 메시지큐가 주로 사용됨

---

메시지 지향 미들웨어 (MOM)

• Message Oriented Middleware는 응용 소프트웨어 간의 데이터 통신을 위한 소프트웨어이며 비동기 메시지 전달에 기초한다.

  장점

• 메시지 기반 통신 프로토콜의 장점은 메시지를 전달하는 과정에서 보관하거나 라우팅(일대다) 및 변환할 수 있다는 점이다.
  • 저장: 메시지의 백업을 유지함으로써 지속성을 제공한다. 즉, 송신 측과 수신 측이 동시에 네트워크에 연결되어 있을 필요가 없다. 메시지가 큐에 제대로 전달되면 송신측은 네트워크 연결이 끊겨도 되고 마찬가지로 수신측이 메시지를 가져올 때를 제외하면 네트워크 필요없다.
  • 라우팅: 메시지를 받아 여기저기로 라우팅할 수 있기 때문에 하나의 메시지를 여러 수신자에게 보낼 수도 있다. (멀티캐스트)
  • 변환: 미들웨어기 때문에 중간에서 메시지를 변환하여 송신할 수도 있다. (prefix를 박아 넣는다던지 등의 변환 규칙 지정 가능)

    단점

• 서비스 아키텍쳐에 외부 구성 요소인 메시지 전송 에이전트(프로세스)를 필요로 한다는 점이다. 별도의 관리 포인트가 추가로 필요하다.
• 메시지 기반 통신은 본질적으로 비동기라서 불일치가 발생할 수 있다. (A -> B, B -> C 순서의 작업이 있을 때 A -> B -> C가 연속적인 동기작업이 아니기 때문에 B -> C 작업에서 B가 제대로 이루어진 것이 보장되지 않음)
• 예시 주문 처리 시스템(wrote by gpt-4o)
  • 상황: 한 온라인 쇼핑몰에서는 주문 처리 시스템을 운영하고 있습니다. 이 시스템은 다음과 같은 여러 서비스로 구성되어 있습니다:
    1. 주문 서비스(Order Service): 주문 요청을 받는 서비스
    2. 결제 서비스(Payment Service): 결제를 처리하는 서비스
    3. 재고 서비스(Inventory Service): 재고를 확인하고 관리하는 서비스
    4. 배송 서비스(Shipping Service): 주문이 완료되면 배송을 준비하는 서비스
  • 비동기 메시지 기반 통신
    1. 주문 생성: 고객이 주문을 하면 주문 서비스는 주문 정보를 메시지 큐에 보냅니다.
    2. 결제 처리: 결제 서비스는 메시지 큐에서 주문 메시지를 읽고 결제를 처리한 후, 결과를 다른 큐에 보냅니다.
    3. 재고 확인: 재고 서비스는 결제가 성공하면 재고를 확인하고, 재고가 충분한지 여부를 메시지 큐에 보냅니다.
    4. 배송 준비: 재고가 확인되면 배송 서비스는 배송 준비를 시작하고, 완료 메시지를 큐에 보냅니다.
  • 불일치 문제 각 서비스는 비동기적으로 동작하므로, 시스템의 상태는 일시적으로 일관되지 않을 수 있습니다. 예를 들어:
    • 결제는 성공했지만 재고가 부족한 경우
    • 재고는 충분하지만 결제가 실패한 경우

    이러한 불일치를 해결하기 위해 메시지 지향 미들웨어는 여러 개의 요청을 그룹화하여 하나의 의사 동기 트랜잭션으로 처리할 수 있습니다.

  • 의사 동기 트랜잭션 예시
    1. 트랜잭션 시작: 주문 서비스는 주문 생성, 결제, 재고 확인, 배송 준비를 하나의 트랜잭션으로 그룹화합니다.
    2. 메시지 그룹화: 각 서비스는 트랜잭션 ID를 포함하여 메시지를 전송합니다. 미들웨어는 이 트랜잭션 ID를 사용하여 관련 메시지를 그룹화합니다.
    3. 상태 추적: 미들웨어는 각 단계의 상태를 추적하여, 모든 단계가 성공적으로 완료되었는지 확인합니다.
    4. 의사 동기 응답: 모든 단계가 완료되면, 미들웨어는 최종 결과를 하나의 응답으로 묶어 주문 서비스에 전달합니다.

---

메시지의 전달 방식에 따른 분류 (메세지 브로커 vs 이벤트 브로커)

• 메시지 큐에 메시지 혹은 이벤트를 넣어주고 중개하는 것을 브로커라고 한다.

  메시지 브로커

• Producer가 생성한 메시지를 큐에 저장하고, Consumer가 저장된 메시지를 가져갈 수 있도록 한다.
• 메시지가 소모(consume)되면 메시지 큐에서 사라집니다.
  • ex) RabbitMQ, ActiveMQ, AWS SQS, Redis

    이벤트 브로커

• 이벤트 브로커는 메시지 브로커 역할을 수행할 수 있다. 하지만 반대로는 불가능 (메시지 브로커가 이벤트 브로커 기능 x)
• 큐에서 Consume된 데이터는 삭제되지 않고 필요에 따라 다시 Consume할 수 있다.
• 메시지 브로커보다 큰 규모의 데이터를 처리할 수 있다.
  • ex) Kafka

사용 후보군: RabbitMQ와 ZeroMQ

• 둘 다 AMQP를 구현한 오픈소스 메시지큐 관련 소프트웨어이다. 둘 제외하고도 많지만 무엇을 써야하나 고민이 될 수 있으니 천천히 알아보자.
• 하지만 위키백과에서 찾아보면 둘의 차이점은 메시지 지향 미들웨어 , 메시지 브로커 에 있다.
  • 메시지 브로커를 중심으로 메시지를 주고받는 RabbitMQ와 달리 zeromq는 메시지 브로커가 없고 분산/동시성 애플리케이션을 타게팅한 메시지큐이다.

    RabbitMQ

• producer/publisher가 consumer에게 메시지를 전달(요청)할 때 중간에서 브로커 역할을 한다.
• 웹 형태로 메시지 브로커를 제공하여 큐와 메시지들의 현황을 모니터링할 수 있다.
• 메시지 브로커가 있기 때문에 메시지 송수신 사이에 ACK을 넣어 신뢰도가 높다.

  ZeroMQ

• 브로커가 없어 더 빠른 비동기 통신 성능을 제공한다.
• 다양한 방식을 제공한다.
  • pub-sub (publisher/subscriber인데 생산자/소비자와 동일하다)
  • push-pull (단방향 통신, 부하 분산 가능)
  • client-server

---

+참고 https://velog.io/@choidongkuen/%EC%84%9C%EB%B2%84-%EB%A9%94%EC%84%B8%EC%A7%80-%ED%81%90Message-Queue-%EC%9D%84-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90