본문 바로가기
IT 개인 공부/Server

메시지 큐(Message Queue)란?

by Libi 2021. 8. 26.
반응형

최근 백엔드 직무를 지원하다 보면 자격 요건이나 우대사항에 메시지 큐(Message Queue)라는 역량이 적혀있는 것을 자주 볼 수 있다.

메시지 큐, 말 그대로 메시지들을 큐라는 자료구조에 담아서 관리한다는 의미인 것 같다. 이에 대해서 알아보도록 하자.

우선 메시지 큐는 메시지 지향 미들웨어를 구현한 시스템이기 때문에 메시지 지향 미들웨어가 무엇인지부터 알고 넘어가자.

 

메시지 지향 미들웨어(MOM)

 

응용 소프트웨어 간의 데이터(비동기 메시지) 통신을 위한 소프트웨어

메시지 지향 미들웨어는 메시지를 전달하는 과정에서 보관하거나 라우팅 및 변환할 수 있다는 장점을 가진다.

  • 보관 : 메시지의 백업을 유지함으로써 지속성을 제공, 덕분에 송수신 측은 동시에 네트워크 연결을 유지할 필요 없음
  • 라우팅 : 미들웨어 계층 자신이 직접 메시지 라우팅이 가능하기 때문에, 하나의 메시지를 여러 수신자에게 배포가 가능해짐(멀티캐스트)
  • 변환 : 송수신 측의 요구에 따라 메시지를 변환할 수 있음

 

하지만 다음과 같은 단점도 존재한다.

  • 아키텍처에 외부 구성 요소인 메시지 전송 에이전트가 필요, 일반적으로 새로운 요소를 추가할 경우 시스템 성능이 저하되고, 신뢰성이 떨어짐
  • 또한, 시스템이 복잡해지기 때문에 관리가 어렵고 비용이 발생
  • 애플리케이션 간의 통신은 본질적으로 동기지만, 메시지 기반 통신은 본질적으로 비동기이기 때문에 메커니즘 불일치가 발생
  • 이를 위해 요청을 그룹화하여 하나의 의사 동기 트랜잭션으로 응답하는 기능을 가짐
  • 표준이라고 부를 규격이 존재하지 않기 때문에 호환이 안될 수도 있음

 

그럼 본격적으로 메시지 큐에 대해서 알아보자.

 

메시지 큐(Message Queue)

 

메시지 큐는 메시지 지향 미들웨어(MOM : Message Oriented Middleware)를 구현한 시스템으로 프로그램(프로세스) 간의 데이터를 교환할 때 사용하는 기술이다.

 

메시지 큐를 사용하면 다음과 같은 장점을 가질 수 있다.

  • 비동기(Asynchronous) : 데이터를 수신자에게 바로 보내지 않고 큐에 넣고 관리하기 때문에 나중에 처리 가능
  • 비동조(Decoupling) : 애플리케이션과 분리할 수 있기 때문에 확장이 용이해짐
  • 탄력성(Resilience) : 일부가 실패하더라도 전체에 영향을 주지 않음
  • 과잉(Redundancy) : 실패할 경우 재실행 가능
  • 보증(Guarantees) : 작업이 처리된 걸 확인할 수 있음
  • 확장성(Scalable) : N:1:M 구조로 다수의 프로세스들이 큐에 메시지를 보낼 수 있음

 

이러한 장점 때문에 메시지 큐는 대용량 데이터를 처리하기 위한 배치 작업이나, 채팅 서비스, 비동기 데이터를 처리할 때 활용된다.

1만 개의 요청이 발생했을 때 모든 요청을 서버로 보내는 것이 아니라 메시지 큐에 보내고, 서버 측에서는 처리하는데 이상 없을 정도의 요청들만 메시지 큐에서 가져와서 처리해준다면 서버의 부담을 줄일 수 있다.

이처럼 메시지 큐는 다양한 곳에서 활용될 수 있다.

  • 다른 곳의 API로부터 데이터 송수신 가능
  • 다양한 애플리케이션에서 비동기 통신 가능
  • 이메일 발송 및 문서 업로드 가능
  • 많은 양의 프로세스들을 처리 가능

 

메시지 큐의 개념은 이해했는데 실제로 사용하려고 하려면 어떻게 해야 할까? 훌륭한 개발자들이 이미 오픈 소스로 다양한 메시지 큐를 구현해놨다.

다양한 메시지 큐들 중 대표적인 메시지 큐인 RabbitMQ, ActiveMQ, Kafka에 대해서 알아보자.

일반적으로 RabbitMQ, ActiveMQ는 신뢰성 있는 메시지 브로커가 필요한 경우 사용하고, Kafka는 처리량이 많은 분산 메시징 시스템에 사용된다.

 

RabbitMQ

  • AMQP 프로토콜을 구현해 놓은 메시지 큐
  • 신뢰성, 안정성과 성능을 충족할 수 있도록 다양한 기능을 제공
  • 유연한 라우팅 : 메시지 큐가 도착하기 전에 라우팅 되며 플러그인을 통해 더 복잡한 라우팅도 가능
  • 클러스터링 : 로컬 네트워크에 있는 여러 RabbitMQ 서버를 논리적으로 클러스터링 할 수 있고 논리적인 브로커도 가능
  • 관리 UI가 있어서 편하게 관리 가능
  • 거의 모든 언어와 운영체제를 지원

 

 

ActiveMQ

    • Java로 만든 오픈소스 메시지 브로커
    • JMS 1.1을 통해 다양한 언어와 프로토콜 지원(Java, C, C++, C#, Ruby, Perl, Python, PHP 클라이언트 지원)
    • OpenWire를 통해 고성능의 Java, C, C++, C# 클라이언트 지원
    • Stomp를 통해 C, Ruby, Perl, Python, PHP 클라이언트가 ActiveMQ에 접근 가능
    • Message Groups, Virtual Destinations, Wildcards와 Composite Destinations 지원
    • JMS 1.1과 J2EE 1.4를 완벽하게 지원하며, transient, persistent, transactional, 그리고 XA 메시징 지원
    • Spring 지원으로 ActiveMQ는 Spring 애플리케이션에 매우 쉽게 임베딩 될 수 있으며, Spring의 XML 설정 메커니즘에 의해 쉽게 설정 가능
    • Geronimo, JBoss 4, GlassFish, 그리고 WebLogic과 같은 인기 있는 J2EE 서버들과 함께 테스트됨
    • Inbound와 Outbound 메시징을 위한 JCA 1.5 Resource Adapter를 포함하여 ActiveMQ가 J2EE 1.4 호환 서버에 자동 배치됩니다.
    • In-VM, TCP, SSL, NIO, UDP, Multicast, JGroups, 그리고 JXTA Transport들과 같은 플러그인 가능한 전송 프로토콜들을 지원합니다.
    • 고성능의 저널을 사용할 때에 JDBC를 사용하여 매우 빠른 Persistnece를 지원
    • 고성능의 클러스터링, 클라이언트-서버, Peer 기반 통신을 지원을 위한 설계가 되어 있음
    • REST API를 통해 웹 기반 메시징 API를 지원
    • 웹브라우저가 메시징 도구가 될 수 있도록, Ajax를 통해 순수한 DHTML을 사용한 웹 스트리밍 지원
    • In-memory JMS Provider로 사용될 수 있으며, 이는 JMS를 사용한 단위 테스트에 적합한 솔루션을 제공
    • STOMP, AMQP, MQTT, Openwire, SSL, and WebSockets

 

 

AMQP vs JMS

  • AMQP는 ISO 응용 계층의 MOM 표준이며, JMS는 MOM을 Java에서 지원하는 표준 API이다.
  • JMS는 다른 Java 애플리케이션끼리 통신이 가능하지만, 다른 MOM의 통신을 불가능(AMQP, SMTP 등)
  • AMQP는 프로토콜만 맞다면 다른 AMQP를 사용한 애플리케이션끼리 통신이 가능

 

 

Kafka

  • 대용량의 실시간 로그 처리에 특화되어 설계된 메시징 시스템
  • AMQP 프로토콜이나 JMS API를 사용하지 않고 단순한 메시지 헤더를 지닌 TCP 기반의 프로토콜을 사용하여 프로토콜에 의한 오버헤드를 감소시킴
  • Producer가 Broker에게 다수의 메시지를 전송할 때 각 메시지를 개별적으로 전송해야 하는 기본 메시징 시스템과 달리, 다수의 메시지를 Batch형태로 Broker에게 한 번에 전달할 수 있어 TCP/IP 라운드 트립 횟수를 줄임
  • 메시지를 파일 시스템에 저장하기 때문에 데이터의 영속성을 보장
  • 기존의 메시징 시스템은 메시지 큐에 적재된 메시지 양이 많을수록 성능이 크게 감소하였지만, Kafka는 메시지를 파일 시스템에 저장하기 때문에 성능이 크게 감소하지 않음
  • Consumer에 의해 처리된 메시지를 곧바로 삭제하는 기존 메시징 시스템과 달리 Kafka는 메시지를 바로 삭제하지 않고 파일 시스템에서 수명이 지나면 삭제하도록 처리
  • 기존의 메시징 시스템은 Broker가 Consumer에게 메시지를 Push 해주는 방식인 반면, Kafka는 Consumer가 Broker로부터 직접 메시지를 가지고 가는 Pull 방식으로 동작
  • 즉, 기존 메시지 큐의 다양한 기능을 포기하고 대용량 메시지를 처리하기 위한 기능을 제공하는 메시지 큐

 

 

 

 

[ Reference ]

· https://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C%EC%A7%80_%EC%A7%80%ED%96%A5_%EB%AF%B8%EB%93%A4%EC%9B%A8%EC%96%B4

· https://12bme.tistory.com/176

반응형

댓글