[MQ] Message Queue 관련 기본 개념 정리 (2)

📌 메세지 지향 미들웨어(MOM)

응용 소프트웨어 간의 비동기적 데이터 통신을 도와주는 소프트웨어
여러 프로그램들이 서로 메시지를 주고받을 수 있도록 해주는 중간 다리 역할
메시지를 보관 / 라우팅 / 변환 할 수 있는 기능을 제공

 

▪️보관 (Message Storage)

MOM은 메세지를 백업하거나 보관할 수 있다.

• 백업 기능을 제공함으로써 지속성을 제공한다.
  ▶️ 송신자와 수신자가 동시에 네트워크 연결을 유지할 필요가 없게 된다.
• 예를 들어 송신자가 메세지를 보냈을 때 수신자가 네트워크 문제로 잠시 받을 수 없더라도,
  메세지는 미들웨어에서 보관되며 나중에 수신자가 메세지를 받으면 된다.
  이렇게 해서 메세지의 지속성을 보장할 수 있다.

▪️라우팅 (Message Routing)

MOM은 메세지를 라우팅하는 역할을 한다.

• 라우팅이란 하나의 메세지를 여러 수신자에게 전달하는 것이다.
• 예를 들어 하나의 메세지가 여러 사람에게 동시에 전달되도록 하는 것처럼,
  미들웨어 계층이 직접 어디로, 어떻게 메세지를 보낼지 결정하고 처리한다.
• 이렇게 하면 송신자는 메세지를 보낼 때 여러 수신자에 대해 별도로 처리할 필요 없이,
  ▶️ 미들웨어가 자동으로 라우팅을 해주므로 효율적이다.

▪️변환 (Message Transformation)

MOM은 메세지 변환 기능을 제공한다.

• 송신자와 수신자가 요구하는 형식이 다를 수 있기 때문에,
  미들웨어는 송신자가 보낸 메세지를 수신자가 이해할 수 있는 형태로 변환할 수 있다.
• 예를 들어 송신자가 보내는 메세지가 JSON 형식이고, 수신자가 요구하는 형식이 XML일 경우,
  미들웨어가 이 두 형식을 자동으로 변환해준다.
  ▶️ 송수신 측에서 각기 다른 시스템을 사용하더라도 문제가 되지 않는다.

 

메세지 큐와 메세지 지향 미들웨어

메시지 큐는 송신자가 메시지를 보낸 후, 수신자가 메시지를 처리할 때까지 임시로 메시지를 보관하는 큐를 제공한다.

• 메시지를 보관하여 네트워크 연결이 끊어져도 메시지가 손실되지 않도록 한다.
• 메시지를 라우팅하여 한 메시지를 여러 수신자에게 전달한다.
• 메시지를 변환하여 송수신자 간의 형식 차이를 해결한다.

➡️ 메시지 큐는 이런 기능들을 제공하는 메세지 지향 미들웨어에 속한다.
 

---

📌 메세지 큐

메세지 큐(Message Queue)는 큐라는 자료구조를 사용하여 메시지를 송수신하는 시스템이다.
메세지 지향 미들웨어(MOM)를 구현한 시스템이다.
이 시스템은 주로 마이크로서비스 아키텍처(MSA)에서 핵심적인 역할을 한다.

 

▪️메시지 큐의 구성 요소

• Producer (생산자): 메세지를 생성하고, 큐에 메세지를 넣는 역할
• Consumer (소비자): 큐에서 메세지를 꺼내서 처리하는 역할
• 메세지 큐: Producer와 Consumer 사이에서 메세지를 전달하는 매개체 역할

 

▪️MSA에서의 핵심 역할

서버가 죽어버린다면 클라이언트의 요청은 증발한다.
하지만 중간에 메세지 큐를 둔다면 서버가 죽은 경우에도 요청이 메세지 큐에 존재하기 때문에
서버의 alive 여부에 관계 없이 요청들을 가지고 있을 수 있다.

---

메세지 큐와 브로커

메세지 큐의 데이터 운반 방식에 따라 메세지 브로커와 이벤트 브로커로 구분할 수 있다.

▪️메세지 브로커 (Message Broker)

• Producer가 메세지를 생성해 메세지 큐에 저장하고, Consumer가 이를 가져간다.
• 메세지 큐에서 데이터를 가져가면, 그 메세지는 짧은 시간 내에 큐에서 삭제된다.
• 예시) RabbitMQ, ActiveMQ, AWS SQS, Redis

▪️이벤트 브로커 (Event Broker)

• 이벤트 브로커는 기본적으로 메세지 브로커의 역할을 하면서도, 메세지 브로커가 하지 못하는 기능이 있다.
• 이벤트 브로커가 관리하는 데이터를 이벤트라고 한다.
• 이벤트 브로커는 Consumer가 데이터를 소비해도 해당 데이터를 다시 소비할 수 있게 한다.
  즉, 메세지가 삭제되지 않고 필요 시 다시 사용할 수 있다.
• 따라서 메세지 브로커보다 대용량 데이터를 처리할 수 있다.
• 예시) Kafka

---

메세지 큐의 장점

▪️비동기 (Asynchronous)

• 메세지 큐가 없으면, Producer는 Consumer가 메세지를 받을 때까지 다른 메세지를 전달 못하고 기다려야하는
  동기 방식으로 메세지가 처리된다.
• 동기 방식은 전송이 빠르고 결과를 바로 알 수 있지만 서버에 과부하를 줄 수 있기에 대용량 트래픽이 발생하는 서버에선 비효율적이다.
• 반면, 메세지 큐는 비동기적으로 작동해서 Producer는 메세지를 큐에 보내고 다음 작업을 계속할 수 있다. 이로 인해 대용량 트래픽에도 효율적으로 처리할 수 있다.

➡️ 메세지 큐를 사용하면 송신자와 수신자가 동시에 작업을 할 수 있다.
 

▪️낮은 결합도 (Decoupling)

• 메세지 큐를 사용하면, Producer와 Consumer가 분리된다.
• 예를 들어 AI 프로필 서비스에서 백엔드와 AI 시스템이 메세지 큐를 통해 연결되면,
  둘 사이의 의존성이 줄어들어 시스템이 더 유연하게 동작한다.
• 알림이나 메일을 보내는 시스템에서 알림 요청 request와 알림 서버의 response 사이 결합이
  일대일로 강한 상황에서 메세지 큐를 도입하면 결합도를 줄일 수 있다.

➡️ 시스템 간의 결합을 줄여서 유연한 아키텍처를 만들 수 있다.

▪️탄력성 (Resilience)

• 탄력성은 시스템이 장애에 대응하고 복구할 수 있는 능력이다.
• 메세지 큐는 비동기적으로 작동하기 때문에, 시스템의 장애가 발생하더라도 송신자는 계속 메세지를 발행할 수 있다.
• 예를 들어 은행 시스템에서 송금이 이루어질 때 수금 시스템에 문제가 생긴 상황에서
  1️⃣ 메시지 큐가 없다면, 문제가 송금 쪽에도 영향을 끼쳐
  복구되는 동안 송/수금 둘 다 원활하지 못한 채 Blocking
  
  2️⃣ 메세지 큐가 있다면, 송금 메세지를 보관해 두었다가
  수금 시스템이 복구되면 그 메세지를 소비하여 처리할 수 있다.
  이렇게 하면 시스템이 복구될 때까지 송금 시스템은 멈추지 않고 계속 메세지를 보낼 수 있다.

➡️ 시스템 장애가 발생해도 메세지 큐는 계속해서 메세지를 보관하고, 장애 복구 후 메세지를 처리할 수 있다.
 

---