[메시지 큐] 메시지 큐에 대해서 (메시지 큐, MOM, 특징, 이점 등)

MOM (Message Oriented Middleware)

MOM은 메시지 지향 미들 웨어로서 어플리케이션의 메시지를 중간에서 관리해주는 시스템이다.

 

여기서 미들웨어란 무엇일까?

개념적으로 미들웨어는 응용프로그램과 운영체제 사이에서 두 요소간 차이에 상관없이 통신을 가능하게 해주는 계층을 말한다. 분산 컴퓨팅 환경에서 미들웨어는 분산 네트워크에서 애플리케이션 또는 애플리케이션 구성요소 간에 통신을 가능하게 하는 소프트웨어라고 한다. 미들웨어는 다음과 같은 범주로 나눌 수 있다. 

• RPC(Remote Procedure Call) 기반 미들웨어
• ORB(Object Request Broker) 기반 미들웨어
• MOM(Message Oriented Middleware) 기반 미들웨어

이 중 MOM은 분산 응용 프로그램 간에 메시지를 보내고 받으면서 데이터를 전달하고 교환할 수 있게 해준다. 즉, MOM은 비동기 메시지를 사용하는 응용 프로그램들 사이에서 데이터를 송수신하기 위한 소프트웨어이다. 여기서 말하는 메시지란 요청, 응답, 오류 메시지 혹은 단순한 정보 등의 작은 데이터를 말한다.

Message Provider : 메시지를 생성하고 전송하는 주체 (메시지 큐의 Producer)

 

MOM을 두고 여러 게층에서 표준 및 프로토콜(JMS, AMQP 등)이 등장하였으며, MOM 개념과 프로토콜을 활용한 다양한 구현체(ActiveMQ, RabbitMQ, Apache Kafka 등)가 등장했다. 이런 구현체들을 MOM 솔루션이라고도 한다.

 

 

MOM 특징

• 비동기 방식으로 메시지를 전달한다.
• 많은 메시지 지향 미들웨어는 메시지 큐 시스템을 기반으로 하지만, 브로드캐스트, 멀티캐스트 방식도 있다.
• 메시지 교환을 위한 표준화된 프로토콜을 가진다.
  • 메시지 형식, 교환 방식, 라우팅 등을 정의하여 서로 다른 애플리케이션 간의 통신을 원활하게 함
  • JMS, AMQP, MQTT

 

 

장단점

▷ 장점

• 변환 : 클라이언트 시스템 간의 종속성 및 결속성을 낮춘다.
  • 메시지를 송신자는 수신자의 주소를 몰라도 전달할 수 있다.
  • 수신자의 메시지는 송신자가 보낸 메시지와 다를 수 있다. →  송수신 측 요청에 따라 메시 변환이 가능하다.
• 라우팅 : 라우팅 규칙을 활용하여 하나의 메시지를 여러 클라이언트가 받을 수 있도록 지원한다.(멀티캐스트)
• 지속성 : 메시지의 백업을 유지하여 지속성을 제공한다.
  • 송수신 측이 동시에 네트워크에 연결되어 있을 필요가 없다. 
  • 수신측에 문제가 생겨도 메시지를 저장해놓고 수신측이 복구될 때 처리된다.

 

▷ 단점

• 메시지 전체를 관리하는 시스템이 필요하다 → 비용 증가
• 전체적인 시스템 구조가 복잡해질 수 있다. → 다수의 서버를 활용하면 구조가 복잡해지고, 오버헤드가 발생할 수 있다.

 

 

메시지 프로토콜 정리

▷ JMS(Java Message Service)

• MOM을 자바에서 지원하는 표준 API
• 자바 어플리케이션 간 통신은 가능하지만 다른 MOM끼리는 통신할 수 없음
• 다양한 형태의 메시지 지원(텍스트, 바이너리, 맵, 객체 등)
• 큐는 Point-to-Point(P2P) 모델, 토픽은 Publish-Subscribe 모델을 기반으로 함
• Connection, Session, MessageProducer, MessageConsumer 인터페이스 및 클래스 제공
• 메시지 브로커나 메시지 서버는 JMS Provider로 동작
• ex) ActiveMQ

 

▷ AMQP(Advanced Message Queuing Protocol)

• ISO 응용 계층(Application Layer)의 MOM 표준 프로토콜 
• 프로토콜만 일치하면 다른 AMQP를 사용한 애플리케이션과도 통신 가능
• 일반적인 메시지 큐와 비슷하지만 Exchange, Binding 개념 존재
  • Exchange :  메시지 수신 라우터
  • Binding : Exchange와 큐 사이의 라우팅 규칙 정의
  • Exchange가 메시지를 수신하고 Binding에 따라 메시지를 큐로 라우팅
• 메시지를 기반으로 한 통신 강조
  • 메시지 : 헤더 + 프로퍼티 + 페이로드
    • 헤더 : 메시지 기본 정보
    • 프로퍼티 : 메시지 속성
    • 페이로드 : 실제 데이터
• ex) RabbitMQ

 

▷ MQTT(Message Queuing Telemetry Transport)

• 경량 메시징 프로토콜
• 제한된 대역폭과 불안정한 네트워크 환경에서 동작하는 IoT(Internet of Things) 기기와 서버 간의 효율적이고 경제적인 통신을 지원하기 위함
• 발행-구독(Publish-Subscribe) 패턴을 기반

 

 

 

 

메시지 큐

메시지 큐 (Message Queue:MQ)

• 프로세스 또는 프로그램 간의 데이터를 교환할 때 사용하는 통신 방법
• 메시지 지향 미들웨어(MOM)을 구현한 시스템 (메시지 큐 시스템)
• 메시지 큐는 메시지를 임시로 저장하는 간단한 버퍼와 같음
• point-to-point 메시징 패턴을 사용하지만 대부분의 메시 
• 일대일 통신 → 각 메시지는 하나의 소비자에 의해 한번만 처리될 수 있음

출처 : https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/

 

 

메시지 큐 시스템 구성 요소

▷ Producer

메시지를 생성하고 메시지 큐에 전달

 

▷ Consumer

메시지 큐로부터 메시지를 수신하고 처리

 

▷ Message

데이터와 메타데이터를 포함한 메시지

 

▷ Message Queue

메시지를 안전하게 저장하고 전달하는 역할

 

▷ Channel

메시지 전송을 위한 통로 또는 경로. 메시지의 흐름을 지정하고 통신 경로를 설정한다. 메시지 큐 메시징 패턴이나 요청-응답 패턴에서 사용된다.

토픽과 채널의 차이점?

: 토픽은 메시지의 주제를 나타내고 채널을 메시지의 흐름을 지정하고 통신 경로를 설정

 

▷ Queue Manager

큐와 메시지 전달을 관리하고 제어하는 역할. 큐의 생성, 삭제, 큐에 메시지를 저장하고 관리.

 

 

 

메시지 큐 동작 방식

1. 생산자(Producer)로 취급되는 컴포넌트가 메시지를 메시지 큐에 추가
2. 소비자(Consumer)로 취급되는 또 다른 컴포넌트가 메시지를 검색하고 사용해 어떤 작업을 수행할 때까지 메시지 큐에 저장
3. 수신자의 작업이 끝나면 메시지 큐에서 메시지 삭제

 

 

메시징 패턴

메시지큐는 point-to-point 메시징 패턴을 사용한다. Producer는 메시지를 생성하여 큐에 넣고 Consumer가 큐에서 메시지를 받아 이용한다. Producer와 Consumer 사이에서는 일대일 관계가 성립하며, 각 메시지는 한번만 이용된다.

 

그럼 여러명의 Consumer에게 메시지를 보내야한다면 어떻게 해야할까? 이때 발행-구독(pub-sub) 메시징 모델을 사용할 수 있다. 대부분의 메시징 미들웨어 솔루션은 메시지 큐(point-to-point)와 pub/sub 메시징 모델 둘 다 지원한다.

 

 

발행-구독 메시징 모델

Publish-Subscribe 메시징 모델은 메시지를 생성하는 발행자(Publisher)와 이를 수신하는 하나 이상의 구독자(Subscriber)로 이루어져 있다. 발행자는 메시지를 발행하고, 여러 구독자가 해당 메시지를 구독하여 수신한다. 각 메시지는 하나의 토픽에 발행되며, 그 토픽을 구독하는 모든 구독자가 토픽에 발행된 메시지의 사본을 받는다.

 

1. 발행자가 메시지를 생성하고 특정 토픽에 발행한다.
2. 메시지는 해당 토픽의 큐에 저장된다.
3. 해당 토픽을 구독하는 구독자들은 메시지를 비동기적으로 수신하고, 각자의 구독 큐에서 메시지를 수신한다.

 

 

메시지 큐를 사용하는 이유

• 일반적인 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 처리 후 클라이언트에 응답
• 소비자가 실제로 메시지를 어느 시점에 가져가서 처리하는지는 보장하지 않음
• 메시지 큐에 넣어둔 메시지가 소비되어 처리될 것이라고 믿음
• 메시지 큐의 비동기적 특성으로 인해 서버 뒷단에서 실행되는 일부 작업을 메시지 큐에 맡김으로써 어플리케이션의 성능을 향상시킴
• 이미지 처리, 비디오 인코딩, 대용량 데이터 처리와 같은 서버 부하가 많은 작업을 할 때 MQ에서 처리
• ex) 비밀번호 변경 이메일 전송, 블로그 포스팅 시 이미지 처리

 

 

메시지 큐 이점

비동기(Asyncronous)

• 생산된 메시지의 저장, 전송에 대해 동기화 처리를 진행하지 않고 큐에 넣어두기 때문에 나중에 처리 가능
• 동기화 방식은 너무 많은 메시지가 전송될 경우 병목이 생기거나 뒤에 들어오는 요청에 대한 응답이 지연될 수 있음

비동조(Decoupling)

• 어플리케이션과 분리할 수 있음
• 생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아짐

확장성(Scalable)

• 생산자 서비스 혹은 소비자 서비스를 원하는대로 확장 가능

탄력성(Resilience)

• 소비자 서비스가 다운되더라도 메시지는 메시지 큐에 남아있음
• 일부가 실패 시 전체에 영향을 받지 않음

과잉(Redundancy)

• 실패할 경우 재실행 가능

보증(Guarantees)

• 큐에 보관되는 모든 메시지가 결국 소비자 서비스에게 전달된다는 일반적인 보장 제공

 

 

메시지 큐 단점

• 큐가 가득차서 더이상 큐에 메시지를 저장할 수 없는 상황에는 메시지를 다른 곳에 보존하거나 버려지게 됨
• 큐를 운영하기 위한 자원이 필요
• 큐의 크기가 생각보다 작기 때문에 송신측이 수신측보다 빠르다면 문제가 자주 발생할 가능성이 있음

 

 

메시지큐 종류

RabbitMQ

• AMQP 프로토콜을 구현해놓은 오픈소스 메시지 브로커

ActiveMQ

• 자바로 만든 오픈소스 메시지 브로커

Kafka

• 고성능 분산 이벤트 스트리밍 플랫폼
• 이벤트 브로커
• TCP기반 프로토콜 사용
• 파일 시스템을 이용한 고성능 디자인

Redis

• pub/sub 메시징 모델의 메시지 브로커

 

 

 

 

메시지 브로커

메시지 브로커(Message Broker)

메시지 브로커는 Producer로부터 전달받은 메시지를 Consumer에게 전달해주는 중간 역할을 한다. 정규 메시징 프로토콜 간에 메시지를 변환하여, 정형화된 메시지 교환을 한다. 일부 메시징 시스템에서는 메시지 브로커가 큐 관리자의 역할을 수행한다. 즉, 메시지브로커는 메시지를 받아 어떤 역할을 수행하는데 목적을 가진다. 메시지 브로커로는 Kafka, Redis, RabbitMQ, Celery 등이 있다.

 

 

특징

• 메시지 브로커는 메시지의 유효성 검증, 저장, 라우팅하고 이를 적절한 대상에 전달한다.
  • 토픽 기반으로 메시지를 분류하고 라우팅하여 메시지를 수신자에게 전달
• 메시지를 저장 및 전달하기 위해 메시지를 저장하고 순서화하는 메시지 큐를 사용한다. 
• point-to-point 메시징, 발행 구독 메시징을 제공

 

 

메시지 큐 VS 메시지 브로커 or 이벤트 브로커

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

 

메시지 브로커(Message Broker)

• producer가 생산한 메시지를 메시지 큐에 저장하고, 저장된 메시지를 consumer가 가져갈 수 있도록 함
• consumer가 메시지를 소비하면 짧은 시간 내에 큐에서 삭제
• RabbitMQ, ActiveMQ, AWS SQS, Redis

 

이벤트 브로커(Event Broker)

• 이벤트 브로커는 메시지 브로커의 메시지 큐 기능들을 가지고 있어 메시지 브로커의 역할을 수행할 수 있음 (반대는 불가)
• consumer가 메시지 큐에서 데이터를 가져가도 consumer가 소비한 데이터가 필요한 경우 다시 소비할 수 있음
  • publisher가 생산한 이벤트를 이벤트 처리 후에 바로 삭제하지 않고 저장하여, 이벤트 시점이 저장되어 있어서 consumer가 특정 시점부터 이벤트를 다시 소비할 수 있음
  • ex) 장애가 일어난 시점부터 그 이후의 이벤트를 다시 처리할 수 있음
• 메시지 브로커보다 대용량 데이터를 처리할 수 있는 능력이 있음
• Kafka

 

 

 

 

참고

https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/

https://goyunji.tistory.com/125

https://m.blog.naver.com/seek316/222117711303

https://dev-jwblog.tistory.com/140

https://www.ibm.com/kr-ko/topics/message-queues

https://velog.io/@vino661/MessageQueue-Messaging-Pattern