Message Queue

🚅 수백만건의 실시간 거래를 어떻게 처리하는지 궁금하지 않나?

금융 시스템, e-commerce, 소셜 미디어 등은 매 순간 수백만 건의 거래와 데이터를 실시간으로 처리해야 한다. 이처럼 막대한 양의 데이터를 효율적으로 처리하기 위해 도입이 된 것이 바로 Message Queue 이다.

적용 배경

1. 비동기의 필요성
   • 초기에는 대부분 작업이 동기적으로 이루어졌음
     • 한 작업이 완료될 때까지 다른 작업이 시작되지 않음
   • 그러나 시스템이 복잡해지고 여러 서비스가 동시에 동작해야 할 필요성이 생기면서 비동기 통신이 필요하게 됨
2. 부하 분산
   • 대규모 시스템에서 트래픽과 작업 양이 급격히 증가할 수 있음
   • 이 때 모든 요청을 동기적으로 처리하게 되면 서버의 부하가 급격히 증가하게 됨
   • 메세지 큐는 작업을 큐에 저장하고 이를 나중에 하나씩 처리해 시스템의 부하를 분산시킬 수 있음

Message Queue에 대해 본격적으로 알아보기 전 메세지 지향 미들웨어(MOM)에 대해 알아보자. 😉

Message Oriented Middleware(MOM)

• 응용 소프트웨어 간의 비동기적 데이터 통신을 위한 소프트웨어 ⇒ 비동기적 방식을 이용해 프로세스 간의 데이터를 주고 받는 기능을 위한 시스템
  
• 메세지를 전달하는 과정에서 보관하거나 라우팅 및 변환할 수 있는 장점이 있음

  • 여기서 메시지란 요청, 응답, 오류 메시지 혹은 단순한 정보 등의 작은 데이터가 될 수 있다

    보관

    • 백업 기능을 유지함으로써 지속성을 제공해 송수신 측은 동시에 네트워크 연결을 유지할 필요가 없음

    라우팅

    • 미들웨어 계층 자신이 직접 메세지 라우팅을 수행하기 때문에 하나의 메세지를 여러 수신자에게 배포가 가능함

    변환

    • 송수신 측의 요구에 따라 전달하는 메세지를 변환할 수 있음

메세지큐가 바로 이 MOM에 속한다

📬 Message Queue

• 프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법 중 하나로 메시지 지향 미들웨어를 구현한 시스템을 의미함
• 즉, Queue라는 자료구조를 채택해 메세지를 전달하는 시스템

구조

• FIFO (First in First out)

  • 선입선출 구조를 가진 자료구조

    

  • Queue는 입구와 출구가 구분된 자료구조, 새로운 데이터는 입구로 들어오고 나가는 데이터는 출구에서 나감

  • 임시저장소에 들어온 순서대로 데이터가 처리된다
    -> 예를 들어, 놀이공원 줄이 있다

    

    메세지 큐를 통해 메세지를 전달하려면 메세지를 전달하는 부분과 메세지를 받는 부분이 필요함

    이때 메세지를 발행하고 전달하는 부분을 Producer라고 하며, 메세지를 받아서 소비하는 부분을 Consumer라고 함

    즉 메세지 큐는 Producer와 Consumer의 메세지 전달 역할을 하는 매개체

메세지 브로커 VS 이벤트 브로커

Message Queue에서 데이터를 운반하는 방식에 따라 메세지 브로커와 이벤트 브로커로 나눌 수 있음

Message Queue가 메세지 또는 이벤트가 송신되고 수신되는 하나의 통신 통로라고 하면,
브로커는 메세지 큐에 메세지 혹은 이벤트를 넣어주고 중개하는 역할을 하는 주체

1. 메세지 브로커(Message Broker)
   • Producer가 생산한 메세지를 메세지 큐에 저장하고 저장된 메세지를 Consumer가 가져갈 수 있도록 함
   • Consumer가 메세지 큐에서 데이터를 가져가게 되면 짧은 시간 내에 메세지 큐에서 삭제되는 특징이 있음!

2. 이벤트 브로커(Event Broker)
   • 기본적인 메세지 브로커 역할을 할 수 있음
     • 반대로 메세지 브로커는 이벤트 브로커의 기능을 하지 못함
   • 이벤트 브로커가 관리하는 데이터를 이벤트라고 하며 Consumer가 메세지 큐에서 데이터를 가져가게 되면 짧은 시간 내에 메세지가 삭제되는 것과 달리, 이벤트 브로커 방식에서 Consumer가 소비한 데이터를 필요한 경우 다시 소비할 수 있음
   • 메세지 브로커 보다 대용량 데이터를 처리할 수 있는 능력이 있음
   • 대표적으로 RabbitMQ, ActiveMQ, amazonSQS, Redis 등이 있다

Message Queue 장점

1. 비동기(Asynchronous)
   • 만약 메세지 큐가 없다면?
     • 메세지를 발행하는 Producer 역할을 하는 애플리케이션은 자신의 메세지를 전달 받는 Consumer 역할을 하는 애플리케이션에게 직접적으로 메세지를 보내야함(End-To-End 통신)
     • 해당 과정이 완료되기 전까지는 다른 메세지 전달 과정을 이루지 못 함
     • 대용량 트래픽이 발생하는 서버에서 이런 방식은 비효율적임
   • 즉 메세지 큐를 중간에 배치해 Producer 는 메세지를 Consumer 에게 바로 보내지 않고 Queue 에 메세지를 넣어 관리. 이를 통해 Consumer 는 비동기적으로 메세지를 처리함
2. 낮은 결합도(Decoupling)
   • 애플리케이션끼리 결합도를 낮출 수 있음
   • 확장성,유연성,효율적인 유지 보수,장애 전파 방지 등에 결합도가 낮을 때 얻을 수 있는 장점이 많음 ⇒ 소프트웨어 아키텍처 디자인 패턴인 MSA(Microservice Architecture) 에서 아키텍처의 핵심적인 역할을함
     

• 모놀리식
  • 하나의 애플리케이션 안에 모든 도메인과 DB가 결합되어 있음
  • 도메인 하나의 장애가 전체 영향미침
  • 유지보수 힘듬

• MSA
  • 서비스(도메인)별로 독립적으로 구성되어 있는 구조
  • 독립적이다보니 각 기능에 대한 정보를 가져오려면 추가 리소스 요청을 보내야 함
  • 이 때 통신하는 방식 중 하나가 메시지 브로커(Kafka, RabbitMQ 등)이 있음

3. 탄력성(Resilience)
   • 시스템이 예기치 않은 상황 또는 장애에 대응하고 유연하게 대처할 수 있는 능력
   • 예를 들어, 은행 송금 시스템

     Process	Task
     A	B 프로세스에게 송금 메세지를 보냄
     B	A 프로세서에게 받은 송금 메세지를 받아 사용자 계좌에 반영함

     • 메세지 큐가 없다고 가정, B 프로세스에 장애가 발생하면 복구되는 동안 A, B 모두 동작하지 않음
     • 있다면, 같은 상황에서 프로세스는 B 프로세스의 장애 여부와 상관 없이 자신이 보내는 송금(메세지) 을 메세지 큐에게 전달만 해주면 됨
     • 송금 메세지를 받은 메세지 큐는 B 프로세스의 장애가 해결될 때까지 큐 내부에 A 에서 받아오는 송금 메세지를 보관 ⇒ B 서비스의 일시적인 불능 상태가 A 서비스에 직접적인 영향을 주지 않고, 시스템의 기능을 유지할 수 있음
       
   • 즉 , Producer 프로세스는 Consumer 프로세스가 다운되어 있어도 메세지를 정상적으로 발행할 수 있고, Consumer 는 구독한 메세지를 발행하는 Producer 프로세스가 다운되어 있어도 정상적으로 수신할 수 있음
4. 과잉(Redundancy)
   • 정상적인 메세지 송/수신이 실패하는 경우 재실행이 가능
   • 위와 같이 메세지 큐가 없다면, B 프로세스에서 장애가 발생해 A 프로세스에서 장애 기간동안 정상적으로 메세지를 송신할 수 없다면 A 프로세스를 사용하는 클라이언트는 장애 기간동안 큰 어려움을 겪을 수 있음
   • 시스템 응답성 저하,데이터 불일치 ,메세지 유실 등 다양한 문제가 발생
   • 메세지 큐를 사용한다면 이러한 문제를 완화할 수 있음. 작업을 메세지로 메세지 큐에 넣어두면 일정 장애 기간동안 송신된 메세지는 큐에 남아있어 추후 장애 복구 시 정상적으로 재시도 및 복구가 가능해짐 👍
5. 신뢰성(Guarantees)
   • 송신된 메세지의 안전하고 확실한 전달을 의미함
   • 메세지 큐라는 시스템 덕분에 장애가 발생하더라도 송신되는 메세지를 안전하고 확실하게 Consumer 가 수신할 수 있음
6. 확장성(Scalable)
   - 수평확장 Scale-Out
   - 만약 기존 메시지 큐를 이용한 통신에서 부하가 증가하거나 클라이언트의 동시다발적인 요청이 증가할 때, 메세지 큐에 Producer 와 Consumer 을 추가함으로 비교적 간단하고 쉽게 확장을 할 수 있음
   
   
   
   

🤔 그럼 언제 사용될까?

MQ를 적용하려면 RabbitMQ, Kafka, ActiveMQ등 다양한 MQ 중에서 시스템 목적에 맞는 MQ를 선정해야 하고 또 서버에 MQ를 설치해야 한다.
설치로 끝이 아니라 그 사용 방법 및 라이브러리 사용법도 익혀야 하며 MQ가 지원하는 다양한 옵션 중에 시스템 목적에 맞는 옵션을 찾아 설정해야 하고 주고 받을 메시지 구조도 정의해야 할 뿐만 아니라 다양한 전달 방식 중 시스템 목적에 맞는 방식을 선정해야 한다.

단순히 서버에서 처리하면 이런 불편함 없이 간단하게 해결할 수 있는데 왜 MQ를 사용해야 할까?

대표 예시 두 가지가 있다.

1. 이메일 전송

어떤 웹 사이트의 비밀번호를 잊어버려서 이메일을 통해 임시 비밀번호를 받거나, 새로운 회원가입을 위한 인증 코드를 받아본 경험이 있을 것이다. 우리는 이러한 상황들에서 이메일이 즉각적으로 수신되기를 기대하지는 않는다. 어느 정도의 응답 지연이 허용되며, 어플리케이션의 핵심 기능은 아닌 경우이므로 메시지 큐는 이런 경우 도움이 될 수 있다

• 비밀번호 재설정을 위해 이메일을 발급하는 서비스, 회원가입을 위해 이메일을 발급하는 서비스 등은 메시지(이메일)를 큐에 넣을 수 있다
• 이메일 전송 전용 서비스는 이메일이 어느 서비스로부터 생산되었는지와는 관계없이, 메시지 큐의 메시지를 하나씩 소비하고, 그저 이메일이 전송되어야 할 곳으로 이메일을 전송한다
• 이와 같은 접근 방식은 메시지 큐에 들어오는 메시지 수가 너무 많아지는 경우 이메일 전송 전용 서비스 인스턴스를 더 둠으로써 확장할 수 있으므로 확장성이 뛰어나다
  
  

즉, 서버 간에 데이터를 주고 받거나 어떤 작업을 요청을 할 때는 항상 시스템 장애를 염두에 두어야 한다.

서버가 갑자기 죽거나 서버 점검 등으로 다운타임이 발생하는 동안에는 요청을 보낼 수가 없다. 요청하는 서버에서 failover 처리를 해놓고 연계 시스템이 다시 살아났을 때 요청을 보내는 방법도 있지만 MQ를 이용하는 것이다.

2. 블로그 포스팅
   - 모든 블로그 사용자가 웹에 최적화되어 있거나, 용량이 작은 이미지만 업로드하진 않을 것이다.
   - 블로그 사용자가 게시글에 업로드한 이미지의 용량이 매우 큰 경우를 생각해보자.
   - 블로그 서비스의 응답 시간을 저해하지 않으면서 사용자들에게 유연성을 제공하는 방법으로, 사용자가 업로드한 모든 이미지를 게시 과정에서 즉각 처리하는 것이 아닌, 사후처리하며 최적화하는 방법이 있다.
   - 사용자 경험에 약간의 영향을 미칠 수는 있지만, 최적화는 응용 프로그램에서 가장 중요한 것은 아니며 작업을 즉시 수행할 필요도 없다. 메시지 큐는 이러한 상황에서도 사용될 수 있다.
   1. 사용자가 고용량의 이미지가 포함된 블로그 포스팅을 한다.
   2. 이미지는 저장소에 전송된다.
   3. 업로드된 이미지에 대한 정보가 포함된 메시지를 이미지 최적화 서비스의 메시지 큐에 담는다.
   4. 이미지 최적화 서비스는 저장소에서 이미지를 가져와 최적화하고, 2번에서 저장해놨던 이미지를 대체한다.
   
   
   
   

이처럼 서버 부하가 많은 작업에도 유용하다

이미지 처리, 비디오 인코딩, 대용량 데이터 처리와 같은 작업은 메모리와 CPU를 많이 사용한다. 이러한 작업은 동시에 처리할 수 있는 양이 상당히 한정적이어서 필요하다고 무작정 요청을 처리할 수는 없다. 이 때에도 MQ를 사용하면 편리한데 처리해야할 작업을 MQ에 넣어두고 서버는 자신이 동시에 처리할 수 있는 양에 따라 하나의 작업이 끝나면 다음에 처리할 작업을 MQ에서 가져와 처리하면 된다.

이 외에도, MQ를 통해 부하분산 처리도 가능하다.

여러 대의 서버가 하나의 큐를 바라보도록 구성하면 처리할 데이터가 많아져도 각 서버는 자신의 처리량에 맞게 태스크를 가져와 처리할 수 있다. 이러한 구조는  horizontal scaling에 유리하다.

또한, MQ를 사용하지 않는다면 외부에서 받은 요청을 메모리에 저장했다가 들어온 순서대로 처리하게 할 수도 있다. 하지만 어떠한 이유로 서버가 다운되어 버리면 메모리에 쌓아둔 요청은 모두 없어지고 만다. MQ를 사용하면 이를 방지할 수 있는데 MQ로부터 가져온 태스크를 일정 시간이 지나도록 처리했다고 다시 MQ에 알려주지 않으면 MQ는 이 태스크를 다시 큐에 넣어 다시 처리할 수 있도록 한다.

Message Queue 종류

1. RabbitMQ

   먼저 AMQP(Advanced Message Queue Protocol) 을 알아보자.

   [AMQP 에 대해서]

   AMQP 는 메세지 지향 미들웨어(MOM) 을 위한 개방형 표준 응용 계층 프로토콜이다.

   

   AMQP는 일반적인 메세지 큐와 비슷하지만 Exchange 라는 라우터가 존재하며 Binding 이라는 개념이 존재

   [RabbitMQ 구성요소]

   • Producer : 요청을 보내는 주체이며 보내고자 하는 메세지를 Exchange 에 Publish 합니다.
   • Consumer : Producer 로 부터 메세지를 받아 처리하는 주체입니다.
   • Exchange : Producer 로 부터 전달받은 메세지를 어떤 메세지 큐로 전송할지 결정하는 장소입니다. 이러한 기능을 라우팅 기능이라고 할 수 있습니다.
   • Queue : Consumer 가 소비하기 전까지 메세지가 보관되는 장소입니다.
   • Binding : Exchange 와 Queue 와의 관계입니다. 즉, 특정 Exchange 가 특정 Queue 에 메세지를 보내도록 정의합니다.

   [RabbitMQ 특징 및 장점]

   RabbitMQ 는 AMQP 프로토콜을 구현해 놓은 오픈 소스 메시지 브로커이며 여러가지 특성을 가짐

   • AMQP 을 구현해 놓은 메세지 큐
   • 신뢰성,안전성과 성능을 충족할 수 있도록 다양한 기능을 제공
   • Broker 중심적인 형태
   • 유연하고 복잡한 라우팅이 가능
   • 관리 UI 존재
   • 거의 모든 언어와 운영체제를 지원
   • 20kb/sec 정도의 속도
   • 데이터 처리 보단, 관리적 측면이나 다양한 기능 구현을 위한 서비스를 구축할 때 사용

   [RabbitMQ 처리 구조]

   1. Producer 가 Broker 로 메세지를 보낸다
   2. Broker 내 Exchange 에서 해당하는 Key 에 맞게 Queue 에 분배한다(Binding)
   3. 해당 Queue 를 구독하는 Consumer 가 메세지를 소비한다

   [RabbitMQ 단점]

   1. 메세지 큐 서버가 종료 후 재가동시 큐 내용은 모두 삭제(데이터 손실 위험)
   2. Producer 와 Consumer 의 결합도가 높음

   ---

2. Kafka

   • Linked-in 에서 개발한 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션을 위해 설계된 고성능 분산 이벤트 스트리밍 플랫폼

   • Pub-Sub(Publisher/Subscriber) 모델의 메시지 큐 형태로 동작하며 분산환경에 특화되어 있으며, Fortune 100개 기업 중 80% 이상이 Kafka를 사용

     

   • 대용량 실시간 로그처리에 특화되어 설계된 메시징 시스템으로 TPS가 매우 우수하고, 메시지를 메모리에 저장하는 기존 메시징 시스템과는 달리 파일에 저장을 하는데 그로 인해 카프카를 재시작해도 메시지 유실 우려가 감소

   • 기본 메시징 시스템(rabbitMQ, ActiveMQ)에서는 브로커(Broker)가 컨슈머(consumer)에게 메시지를 push해 주는 방식인데, 카프카는 컨슈머(Consumer)가 브로커(Broker)로부터 메시지를 직접 가져가는 PULL 방식으로 동작하기 때문에 컨슈머는 자신의 처리 능력만큼의 메시지만 가져와 최적의 성능을 낼 수 있음

     그렇다면, 일반적으로 파일보다 메모리가 성능이 우수한데 왜 카프카가 성능이 좋은 것일까?

     그 이유는 카프카의 파일 시스템을 활용한 고성능 디자인에 있다.

     일반적으로 하드디스크는 메모리보다 수백배 느리지만 하드디스크의 순차적 읽기에 대한 성능은 메모리보다 크게 떨어지지 않는다고 한다

   
   

결론

대용량 분산 시스템이 필요하면 Kafka 을 구축하면 되고 그 외에는 Queue 기능에서 신뢰성과 안전성을 좀 더 보장하는 ActiveMQ 혹은 RabbitMQ 을 사용하면 될 것 같다

MQ를 사용할 때 얻을 수 있는 이점은 많지만 적재적소에 사용해야 한다. 요청 결과를 즉시 응답해야할 때에는 MQ는 어울리지 않는다. 주로 요청과는 별개로 처리할 수 있는 비동기 처리에 어울린다. 또한 서버에서 간단하게 처리할 수 있는 일을 MQ를 통해 전달하면 필요없는 오버헤드될 수도 있다.