메시지 큐(Message Queue) 훑어보기

이번글은 메시지 큐에 대한 개념과 여러가지 미들웨어를 훑어보기 위한 글 입니다.

 

웹 서버를 구성하게 되면 성능에 대한 고려는 빼먹을 수 없습니다. 데이터 처리를 하다보면 너무 많은 처리로 인해 대기하는 요청이 쌓이게 됩니다. 그리곤 서버의 성능이 저하되는데, 최악의 경우에는 서버가 다운되는 상황까지 직면하게 됩니다. (많이 안타까운 상황이죠...ㅠ)

 

이런 상황을 방지하기 위해 서버사이드에서는 로드밸런싱도 하고, DB사이드에서는 H/A, A/A 방식으로 구성도 하고 합니다. 하지만 여러가지 측면에서 볼 때, 비용도 많이 들고 DB사이드에서의 구성은 쉽지도 않습니다. 또한 DB 접속에 대한 한계도 있기 때문에 다른 방법을 택하게 될지도 모릅니다. 그래서 그나마 빠르고 좀 더 원활한 서비스(?)를 위해 비동기 메시지 처리 방식을 구성하게 됩니다.

 

간단하게 메시지큐를 설명하기에 앞서 그와 관련된 개념들을 정리하고자 합니다.

 

- 메시지 지향 미들웨어(Message Oriented Middleware : MOM) 

: 분산 시스템 간 메시지를 주고 받는 기능을 지원하는 소프트웨어나 하드웨어 인프라

 

- 메시지 큐(Message Queue : MQ)

: MOM을 구현한 시스템

 

- 브로커(Broker)

: Message Queue 시스템

 

- AMQP(Advanced Message Queueing Protocol)

: 메시지 지향 미들웨어를 위한 프로토콜

---

기본적인 원리는 이렇습니다.

Producer(생산자)가 Message를 Queue에 넣어두면, Consumer가 Message를 가져와 처리하는 방식입니다.

굳이 이런 시스템이 필요할까..? 한번 더 거치게 되면 더 느려지는게 아닌가? 라는 의문이 들 수 있습니다. 위에서도 언급한바 있지만 다시 한번 말씀드리자면, Client와 동기방식으로 많은 데이터 통신을 하게 되면 병목현상이 생기게되고, 서버의 성능이 저하됩니다. 이런 현상을 막고자하여 또 하나의 미들웨어에 메시지를 위임하여 순차적으로 처리를 하는 것 입니다.

그래서 메시지큐가 짱이다..?!

사실상, 무조건적인 것은 없다고 봅니다. 

단점으로 보자면, 즉각적인 서비스를 불가능합니다. 최대한 텀을 줄이기 위해 MQ를 튜닝 한다던지, Consumer를 늘린다던지(일부 MQ에 해당), Consumer에서 병목현상을 찾고 리팩토링으로 좀 더 빠른 서비스를 제공 할 순 있습니다. 반대로 Consumer 역할에서 서버사이드나 DB사이드에서 제대로 받춰주지 못한다면, 브로커 자체 성능이 저하될 수 있습니다.

메시지큐를 지원하는 API와 미들웨어들을 간략하게 정리 해보겠습니다.

Spring Intergration

- 스프링 기반의 메시지 처리 모듈

장점

1. 스프링 기반이기 때문에, 스프링에 쉽게 적용 가능

2. TaskExcutor를 이용한 단순한 구조

단점

1. 확장성 부족(로드밸런싱, 클러스터링 불가능)

2. 시스템 에러시, 데이터 유실

3. 모니터링 도구 없음

JMS

- J2EE에서 지원하는 메시지 처리 API

단점

1. JAVA 전용(AMQP 지원 하지 않음)

2. 모니터링 도구 없음

 

ActiveMQ

- JAVA로 만든 오픈 소스 메시지 브로커(JMS 확장형?)

장점

1. 다양한 언어 지원

2.  STOMP를 통해서도 접근 가능

3. JDBC를 사용하여 매우 빠른 Persitence 지원

4. 클러스터링 가능

5. REST API를 통해 웹기반 메시징 지원

6. AJAX를 통해 순수한 DHTML를 사용한  웹스트리밍 지원

단점

1. 모니터링 도구 없음

RabbitMq

- AMQP를 지원하는 오픈소스 메시징 시스템

장점

1. 실시간 모니터링 및 관리 용이

2. 다양한 언어 지원

3. 클러스터링 가능

단점

1. Window OS 시, Erlang, OpenSSL 설치 필요

항목	RabbitMQ	ActiveMQ
TOPIC/QUEUE 방식	O	O
RPC 방식	O	O
JMS 또는 AMQP	O	O
Binding 기능	O	X
MQTT	O	O
Embedded Broker	X	O
모니터링	Very Good	Bad
웹컨트롤	Very Good	Bad
Publisher Flow-Control	O	O(설정시)
Broker Clustering	O	O
Installation	윈도우 설치시 OpenSSL, Erlang 필요	Java Wrapper 사용

<RabbitMQ 와 ActiceMQ 비교(출처 : http://blog.ryanjin.net/blog/rabbitmq/)>

Kafka

: 대용량 실시간 로그 처리에 특화되어 설계된 메시지 시스템

장점

1. AMQP나 JMS를 사용하지 않고 단순 메시지 헤더를 지닌 TCP 통신

2. 개별 전송이 아닌 다수 전송 가능(Batch 처리 가능)

3. 파일 시스템에 저장(데이터의 영속성 보장)

4. 대기 중인 메시지로 인한 시스템 성능 감소 줄임

5. 분산 시스템이 기본적으로 설계

단점

1. 큐의 기능은 기존 JMS나 Broker 보다 부족

※ 대용량 CEP엔진에서는 Kafka를 사용하고, 일반적으로는 ActiveMQ, RabbitMQ급의 미들웨어로만 으로도 성능은 충분합니다.

참고

- http://zzong.net/post/3

- http://epicdevs.com/17

다음 편에서는 RabbitMQ를 가지고 간단한 예제를 적용해보도록 하겠습니다.