MSA 구조 구성의 핵심: 메시지 큐(Message Queue)란? - RabbitMQ, Kafka, Redis

MSA 구조를 이용할 때 마이크로서비스 간 통신을 구현하기 위해서는 어떤 프로토콜을 많이 사용할까요? 가장 흔하게 사용되는 방법 중 하나가 바로 메시지 큐 방식입니다. 메시지 큐 방식이 마이크로서비스 간에 많은 통신이 필요할 때 효율적으로 통신하기 때문인데요. 어떤 원리로 효율적인 통신이 가능할까요?

오늘은 MSA 구조의 핵심 포인트인 메시지 큐에 대해 자세히 알아보겠습니다.

 

 

---

메시지 큐(Message Queue)란?

우선 간단한 자료구조를 이해하고 있는 분들은 당연히 큐(Queue)라는 자료구조에 대해 이미 알고 있을 것입니다. 큐 구조는 선입선출(First-In-First-Out, FIFO) 원칙을 따르는 구조로 가장 먼저 들어온 요소가 가장 먼저 처리됩니다. 이런 큐 구조를 활용한 메시지 큐는 많은 애플리케이션에서 발생하는 메시지의 처리 순서를 보장하기 위해 사용됩니다.

이때 메시지 큐 시스템은 브로커(중개인)를 활용해 구현되는데요. 더 정확하게는 메시지를 브로커에게 발행하는 프로듀서(Producer) / 메시지를 중개하는 브로커(Broker) / 메시지를 브로커에세 수신하는 컨슈머(Consumer) 총 3 개의 주체가 존재합니다. 이런 구조로 인해 생기는 메시지 큐 시스템의 장점은 다음과 같습니다.

 

메시지 큐 사용 이유(장점)

1. 비동기 처리
   프로듀서는 브로커에게 메시지를 발행하고 다른 작업을 하기 위해 떠납니다. 즉, 프로듀서는 컨슈머가 메시지를 수신할 때까지 기다리지 않죠. 이런 과정은 음식 배달을 시켰을 때 '문 앞에 놓고 가주세요~' 이런 요청과 비슷한 효과라고 생각하시면 됩니다. 배달 기사는 손님이 음식을 수령할 때까지 기다리지 않고 문 앞에 음식을 놓은 후, 바로 다음 배달을 하러 갈 수 있기 때문에 굉장히 효율적입니다.
   
   대용량 트래픽이 발생할 때는 이런 동기적인(메시지 수신되기까지 기다리기) 방식은 속도를 늦출 수 있기 때문에 비동기적 처리가 가능한 메시지 큐가 필요합니다.
   
   
2. 낮은 결합도
   MSA의 주요 설계 원칙 중 하나는 Loose Coupling, High Cohesion입니다. 즉, 각각의 마이크로서비스가 최대한 서로 영향을 주지 않아야한다(Loose Coupling)는 것인데요.
   
   메시지 큐를 이용하면 마이크로서비스 간 통신을 브로커에게 맡기기 때문에 컨슈머에서 장애가 생겼다고 프로듀서에서도 장애가 일어나지는 않는다는 낮은 결합도의 장점이 있습니다.
   
   
3. 부하 분산
   메시지 큐에서는 하나의 메시지를 여러 컨슈머가 소비할 수 있습니다. 효율적으로 다수의 컨슈머에게 메시지가 전달될 수 있는 구조를 활용해 구현되었기 때문에, 일반적으로 부하 분산이 효과적으로 이뤄집니다.

 

 

---

메시지 큐 종류

메시지 큐로 구현된 오픈소스의 종류는 꽤 다양합니다. 다음은 일반적으로 많이 사용되는 메시지 큐 서비스들입니다.

 

 

1. RabbitMQ

RabbitMQ 구조

RabbitMQ는 AMQP 프로토콜을 구현해 놓은 오픈 소스 메시지 브로커입니다. 메시지 큐의 Pub/Sub 구조를 따르지만, 여기서 라우팅 키를 이용해 원하는 메시지 큐에 메시지를 전달할 수 있다는 것이 특징입니다. RabbitMQ의 큰 특징은 메시지 신뢰성 보장, 다양한 라우팅 옵션입니다. 즉, RabbitMQ를 사용하기 좋은 상황은 안전하게 메시지가 손실 없이 수신되게 보장해야하는 경우, 상황에 따라 메시지를 수신할 주체가 바뀌는 경우라고 생각할 수 있습니다. 예를 들어 설명하겠습니다.

 

상황 별 RabbitMQ 적절성

1. 금융 시스템 (적절함)
   금융 시스템의 경우 메시지 유실의 영향은 굉장히 클 수 있습니다. 이런 경우 메시지의 안전한 전달을 보장해야 하는데, RabbitMQ의 경우 메시지 수신에 대한 확인(Ack) 및 재전송 기능이 탑재되어 있으므로 메시지를 안전하게 전달할 수 있어 금융 관련 시스템에 사용하기에 적절합니다.
2. 여러 조건에 따라 수신해야하는 메시지가 다른 경우 (적절함)
   A 조건을 만족하는 사용자는 A 메시지를 수신, B 조건을 만족하는 사용자는 B 메시지를 수신, ... 이런식으로 설계된 시스템이라면 RabbitMQ의 라우팅 옵션이 효과적으로 이용될 수 있어 적절합니다.
3. 높은 트래픽과 빠른 응답이 중요한 경우 (부적절함)
   RabbitMQ는 신뢰성 보장과 다양한 라우팅을 제공하므로 속도 면에서는 큰 메리트가 없습니다. 높은 처리량과 빠른 속도가 필요하다면 kafka 혹은 redis가 더 좋은 선택일 수 있습니다.
   
4. 간단한 메시지 큐 (부적절함)
   RabbitMQ는 구성이 복잡하기 때문에 간단한 메시지 큐를 구현하기 위해서는 적절하지 않을 수 있습니다.

 

 

2. Apache Kafka

Kafka 구조

Kafka는 대용량 데이터를 매우 빠르게 처리하기 위해 만들어진 오픈 소스 브로커 프로젝트입니다.

 

상황 별 Kafka 적절성

1. 대용량 데이터 처리해야하는 경우 (적절함)
   금융 시스템의 경우 메시지 유실의 영향은 굉장히 클 수 있습니다. 이런 경우 메시지의 안전한 전달을 보장해야 하는데, RabbitMQ의 경우 메시지 수신에 대한 확인(Ack) 및 재전송 기능이 탑재되어 있으므로 메시지를 안전하게 전달할 수 있어 금융 관련 시스템에 사용하기에 적절합니다.
2. 간단한 구조 (부적절함)
   Kafka는 설정이 굉장히 복잡합니다. 그러므로 간단한 메시지 전송이 필요한 경우 kafka는 과할 수 있습니다.

 

 

3. Redis

Redis 구조

Redis는 기본적으로 인메모리 데이터 저장소이지만 Pub/Sub 구조의 메시지 큐 기능도 제공하고 있습니다. 올리브영 기술블로그에서도 해당 기술을 이용했다는 글을 확인할 수 있었습니다.

404: Not found | 올리브영 테크블로그

 

상황 별 Redis 적절성

1. 빠른 속도가 필요할 때 (적절함)
   기본적으로 Redis는 메모리를 사용하기에 속도가 굉장히 빠릅니다. 속도가 중요하다면 Redis가 적절합니다.
2. 단순한 데이터 전송 (적절함)
   구현이 빠르고 쉬우므로 구조가 간단할 경우 사용하기에 적절합니다.
3. 금융 시스템 (부적절함)
   Redis는 높은 신뢰성을 보장하지는 않습니다. 이로 인해 신뢰성 및 안정성이 중요한 금융 관련 시스템에서는 부적절할 수 있습니다.
   
4. 메시지 순서가 중요한 경우 (부적절함)
   메시지 순서를 보장하지 않으므로 Redis는 적절하지 않습니다.

 

 

 

마치며

MSA 구조에서 메시지 큐를 사용할 때, 각 메시지 큐 서비스는 특정 요구 사항에 맞춰 장단점이 있으며 선택할 때는 시스템의 요구 사항, 팀의 기술 스택, 관리 편의성 등을 고려해야 할 것 같습니다.