대용량 데이터를 전송하는 방법(1) - Message Queue

대용량 데이터를 전송할 때 사용하는 여러가지 방법이 있는데 그 중 하나가  Message Queue를 이용한 방법이 있습니다. 

 

요즘 카프카가 대세다, 대용량 데이터를 처리하는 방법 등등 이런 헤드라인으로 시선을 사로잡는 광고들이 많이 보였습니다. (이미 현업에서도 많이 사용 중이지만...) 저도 데이터를 만지는 사람으로써 이런 기술들에 대한 니즈가 있긴 하지만 당장에 내 상황에 필요한 기술인지 아닌지에 대해 판단도 못 하겠고, 왜 MQ나, Kafka 같은 것들을 도입하여 사용하는지 어떤 상황에 맞게 쓰는 게 맞는지 근본적인 의문을 풀어보고자 이 글을 작성하게 되었습니다. 이 글은 제가 공부하면서 정리하고 적어 보는 거니 완전히 믿으시면 안 됩니다....! (밑밥깔기)

 

Message Queue란 무엇인가? 

참고글 https://earlybird.kr/1489
메세지 큐의 정의에 대해 찾아 보다가 이런 블로그를 찾게 되었는데 정말 가려운 곳을 긁어주는 글이었습니다. 십 년 전 글이지만 저와 똑같은 의문점을 가지고 글을 작성하셨더라구요..! 
 저도 학교 수업이나 정처기 공부했을 때 IPC(Inter-process communication)를 들어보았었는데 이때 OS에서 관리되는 이벤트들이 메세지큐를 통해서 관리된다고 알고 있었어서 처음에는 그런 느낌의 메세지큐를 말하는 건가? 싶었는데 개념은 비슷하지만 그걸 뜻한 건 아니었었네요.

 

여기서 말하는 Queue도 우리가 알고 있는 그 큐가 맞습니다. FIFO 패턴을 따라서 데이터가 큐에 들어가게 되면, 먼저 들어간 순서대로 제거가 됩니다. 

 

Message Queue는 분산 시스템에서 데이터를 비동기적으로 전송하고 처리하는 데에 사용되는 시스템입니다. 
아키텍처는 다음과 같습니다.

1. Producer(생성자): 데이터나 이벤트를 생성하고, 메세지 큐로 보내는 역할
2. Comsumer(소비자): 메세지 큐에서 메세지를 가져와서 처리하는 역할 
3. Message Broker: 
   3-1. Queue가 정의되어 있는 third-party software
   3-2. 다양한 유형의 메세지를 다른 Queue로 라우팅하기 위한 규칙도 제공한다
   3-3. Producer와 Consumer 간의 중간 역할

--> 여기서 헷갈리면 안 되는 게, 메세지 큐는 데이터 구조로서 메세지를 보관하는 방법인 것이고 메세지 브로커는 큐를 관리하는 별도의 구성요소라고 이해하면 됩니다. 

 

 왜 Message Queue를 사용할까? 

대용량 데이터 같은 경우 일반적인 서버단에서 그냥 처리를 하게 되면 
1. 오래 걸리고 (속도)
2. 중간에 과부하가 걸려 터질 수도 있고 (트래픽 문제)
3. 안정적이지 않아 데이터가 제대로 넘어가지 않을 수 있고. (신뢰성)
4. 또한 유지보수도 힘들 수 있습니다. (확장성)

메세지큐의 통신 과정을 보게 되면 생성자가 소비자에게 직접 데이터를 받으라고 요청하는 것이 아니라, 생성자가 중간 큐 단에 xml이나 json 형식으로 데이터를 전달하게 되면 소비자는 큐로부터 요청 데이터를 받아서 처리를 하게 됩니다. 그래서 만약 소비자가 큐에서 데이터를 받을 수 없는 상황이라면 해당 데이터는 큐에 계속 남아있게 되는 것이죠. 그렇게 해서 소비자 서버가 다시 안정화가 되었을 때 큐에 요청을 해서 처리를 할 수 있게 됩니다. 

여기서 조금 더 자세하게 이야기하자면 소비자가 죽어버리는 상황에서 볼 수 있는 것이 DLQ 인데요. Dead-Letter Queue는 하나 이상의 Source Queue가 성공적으로 컨슘되지 못한 메시지들을 재전송하기 위해 사용하는 별도의 큐입니다. DLQ에 쌓인 메시지들을 보면 왜 이 메시지들이 소비자에 의해 처리되지 못했는지를 알 수 있어서 서버가 죽더라도 DLQ를 확인해 보면 이게 잘 들어갔는지 에러가 났는지 확인해 볼 수 있어요. 

각자 메세지 큐를 통해 구현하고자 하는 상황들이 다르겠지만, 공통적인 키워드는 
1. 비동기 통신을 원할 때
2. 분산 환경에서 데이터를 안전하게 전달하고 싶을 때
3. 보낸 사람과 받는 사람이 분리되어 있을 때
가 아닐까 싶네요..... 

실제 Message Queue의 사용 사례는 어떤 것이 있을까? 
 - 주문, 재고 업데이트, 배송 등의 서비스 흐름을 관리하고 싶을 때 
 - SNS 알림 관리 
 - 실시간 채팅 
 - 게임에서 유저들끼리 매칭을 진행할 때
 - 티켓팅할 때 대기인원수 표시하는 것도 아마도 메세지 큐....?!를 이용한 것 같네요 

 

Message Queue의 종류

MQ의 종류로는 여러가지가 있는데 ActiveMQ, RabbitMQ, Kafka, AWS MQ, AWS SQS  등이 있습니다. 위에서도 말했다시피 각각의 시스템마다 사용할 때 더 효율적인 상황이 존재합니다. 각각의 특성들만 간단히 정리해 보고 다음 글에서는 크게 ActiveMQ와 Kafka를 직접 설치해 보고 구현을 해 보려고 합니다.

 

ActiveMQ

- 기업 사용 사례에 최적화된 메세지 브로커입니다. 
- Java Message Service(JMS) 표준을 기반으로 한 큐 기반 모델을 사용합니다.

주요 특징: 다양한 프로토콜 지원(AMQP,MQTT,STOMP), 유연한 메세지 지속성 옵션, 고급 기능 제공
메세지 우선 순위, 일정관리, 재전송 정책 등을 통해 메세지 처리 및 전달을 더 세밀하게 제어할 수 있습니다.

 

Kafka

- 확장성이 뛰어나고 내결함성이 있는 메세지 브로커 역할을 하는 오픈 소스 분산 스트리밍 플랫폼
- LinkedIn에서 개발하였으며, 높은 처리량의 실시간 데이터 스트리밍을 처리하는 데에 적합합니다.

--> 시스템에서 이벤트를 추출하는 Kafka 기반 솔루션 
주요 특징: 로그 기반 저장, 수평 확장성, 이벤트에 실시간으로 반응함, 스트리밍 처리 지원 
대규모 데이터 볼륨을 처리하고, 실시간 데이터 변환 및 분석이 가능합니다. 

 

RabbitMQ

 AMQP(Advanced Message Queuing Protocol)을 지원하는 오픈 소스 메세지 큐 시스템
- 다양한 메시징 패턴 및 기능을 제공합니다.

주요 특징: 다양한 프로그래밍 언어 지원, 클러스터링 및 고가용성 지원
지점 간 pub-sub 같은 다양한 메시징 패턴을 지원하므로, 유연하고 확장 가능한 통신 아키텍처가 가능합니다.
메세지 안정성과 전달을 보장하면서 복잡한 워크플로우 개발을 단순화 할 수 있습니다.

 

AWS SQS

AWS에서 사용되는 완전 관리형 MOM(Message Oriented Middleware)입니다. 
여러 가용영역에 걸친 메시지를 저장하므로 높은 신뢰성과 수백만 메세지를 발송하고 수신할 수 있는 확장성과 처리 능력이 있습니다. 

 Queue에 메세지 PUT, GET에 대한 초당 처리량 제한이 없어서 거의 무제한에 가까운 처리량을 보여줍니다.
- 메세지 순서에 대한 보장이 없습니다. 즉, 느슨한 FIFO 구조를 가지고 있습니다. (무조건 선입선출이 아님)
- 적어도 한번은 메세지 전달이 보장되나 2회 이상 동일한 메세지가 전달될 수 있습니다. 이는 가용성을 위해 메시지가 여러 서버에 저장어 일부 서버가 사용할 수 없는 경우 메시지가 삭제되지 않고 다시 메시지를 수신할 수 있도록 설계되어져 있기 때문입니다. 그러므로 어플리케이션 설계시 멱등성을 보장할 수 있도록 설계되어야 합니다. 

 

메세지 큐에 대해 조사를 나름대로 했는데 큐 종류들을 보니까 정말로 적재적소에 맞게 사용을 잘해야겠다는 생각이 드네요.. 직접 구현을 해 보고 상황에 맞게 데이터 전송을 진행해 봐야 좀 더 감이 잡힐 것 같습니다. ㅎㅎ 개념만 정리한 글이라 피드백이 있을지 모르겠지만 피드백은 언제나 환영입니다! 부족한 글 봐 주셔서 감사합니다... 🙇‍♀️