Message Queue(RabbitMQ)와 AMQP

이번에 회사에서 햇수로 3년차라고(...)20년 12월에 입사하여 실제 일한 기간은 18개월이다 제품 설계부터 진행하라고 미션을 줬다.

바로 API의 비동기 처리인데, 이를 위해 Message Queue를 도입하기로 했다.
이번 포스팅에서는 그 과정의 첫 부분에 대해서 다뤄보려고 한다.

---

Why Message Queue?

위와 같이 사용자가 어떤 상품을 구매하기 위한 시스템이 있다고 하자. (생략이 많이 된 그림이다.)
서버는 주문을 받는 시스템이고, 외부연동 API는 결제 시스템이다.

이렇게 외부연동 시스템이 있을 때 Synchronous로 구성하게 되면 대기시간이 발생하여 비즈니스 처리 시간이 증가하고, 요청이 늘어나게 되면 서버 부하가 커지게 된다.

그래서 Asynchronous로 처리하는 방향으로 시스템 구성을 해야되는데, 이 때 쉽게 구현할 수 있는 것이 바로 Message Queue이다.

현재 대표적으로 쓰이는 MQ에는 Apache Kafka, ActiveMQ, RabbitMQ가 있다.
이들은 기본적으로 비동기 처리를 위해 메시징을 처리하는 브로커이다.

X	Kafka	ActiveMQ	RabbitMQ
공통	비동기 처리, Publisher(송신자)와 Consumer(수신자)를 구분함
개발 언어	Java		Erlang
처리량	대용량	상대적으로 적음
신뢰성	상대적으로 낮음	높음(AMQP)

진행하는 프로젝트에 따라 선택하면 되는데 비교해보면 처리량, 지원 프로토콜, 확장성 등에서 차이가 있기 때문에 직접 찾아보는 것이 좋다.
이번 프로젝트에선 RabbitMQ를 선택했다.

---

RabbitMQ

RabbitMQ는 AMQP를 구현한 메시지 브로커이다. (AMQP에 대한 설명은 여기서)
RabbitMQ의 Data Flow는 아래 그림과 같은 방식이다.

https://www.rabbitmq.com/tutorials/amqp-concepts.html

송신자와 수신자가 분리하여 존재하고, exchange는 설정한 방식에 따라 원하는 Queue로 Binding 된다. (이건 RabbitMQ 개념 포스팅에서 더 자세히 다룰 것이다.)

기존의 시스템 구성에서 Message Queue를 도입하면 아래와 같이 바뀐다.

기존에 Client에서 들어온 요청을 처리하는 서버는 Message Queue에 Publish 하는 작업만 담당하고, 해당 Queue에서 Consume하는 서버가 꺼내온 정보를 바탕으로 비즈니스 로직을 처리하도록 바뀌었다. 해당 작업이 끝나고 후처리 API를 호출하여 WebSocket으로 사용자 브라우저에 알림을 주는 방식으로 구현한다면 비동기 처리 후 결과 전송도 가능하다.

---

마치며

위의 예시는 정말 간단한 예시지만 목표였던 비동기 처리가 필요한 이유와 구상에 대해 나타낼 수 있었다.
실제 업무 환경에서는 케이스별로 이점이 여러가지 있을 것이고, 또한 최근의 디자인 패턴인 MSA(MicroService Architecture) 에서는 각 모듈의 역할을 분할하고 결합도를 낮추는 결과도 될 수 있다.
다음 포스팅에서는 RabbitMQ 개념에 대해 정리할 것이다.