메시지 큐(MQ; Message Queue)

 

메시지 큐(MQ; Message Queue)

https://velog.io/@xeropise1/%EB%A9%94%EC%8B%9C%EC%A7%80-%ED%81%90%EB%9E%80

 

프로세스 혹은 프로그램 간에 데이터를 교환할 때 사용되는 통신 방법 중 하나.
메시지 지향 미들웨어(MOM; Message-Oriented middleware)를 구현한 서비스를 메시지 큐(MQ)라고 한다.

간단하게는 메시지를 임시로 저장하는 간단한 버퍼라고 생각할 수 있다.

메시지 브로커를 구현할 때 사용하는 기술이다.

 

 

 

메시지 지향 미들웨어(MOM; Message-Oriented middleware)

비동기 메세지를 사용하는 프로그램 간 데이터 송수신을 의미한다. (이후로는 MOM으로 칭함)

 

AMQP(Advanced Message Queuing Protocol)

MOM을 위한 개방형 표준 통신 프로토콜. 응용 계층의 MOM 표준이며 

메시지 브로커를 통해 메시지를 전송하고, 메시지는 생산자(Producer)와 소비자(Consumer) 간의 통신을 가능하게 한다.
프로토콜만 일치한다면 다른 AMQP를 사용한 Application과도 통신이 가능하다.

AMQP

 

 

JMS(Java Message Service)

Java에서 메시지 기반의 비동기 통신을 구현하기 위한 API.

Java로 작성된 애플리케이션이 서로 메시지를 보내고 받을 수 있도록 하는 표준화된 방법을 제공한다.

다른 Java Application 간 통신이 가능하지만, 다른 MOM(AMQP, SMTP)와는 통신이 불가능 하다.

 

 

 

메시지 큐(Message Queue)가 사용되는 예시

1. 애플리케이션 - 시스템 간 통신

• 서버가 갑자기 죽어버리거나, 서버 점검 등 다운타임이 발생하는 동안에는 요청을 주고 받을 수 없다.
• 서버에서 failover 처리를 해놓고 시스템이 정상적으로 돌아왔을 때 요청을 보내는 방법이 있지만, MQ를 사용하면 간편하게 처리가 가능

P는 메세지를 발행하는 Producer, C는 메세지를 수신하는 Consumer

1. P는 C에 직접 요청을 하는것이 아닌, MQ에 메세지를 전달한다.
2. C는 MQ를 구독(Subscribe)하며, MQ로 부터 메세지를 수신해서 처리한다.
3. C가 수신할 수 없는 상황이라면, 메세지는 MQ에 머물렀다가 C가 받을 수 있는 상황일 때 메세지를 가져간다.

 

2. 서버 부하가 많은 작업

• 이미지 처리, 비디오 인코딩, 빅데이터 등 대용량 데이터 처리와 같은 작업은 메모리, CPU를 많이 사용한다. 이러한 작업은 동시에 처리할 수 있는 양이 한정적이여서 무작정 요청을 보내 처리를 할 수 없다. 이럴경우, MQ를 사용하면 서버가 처리할 수 있는 양을 MQ에서 가져와 처리하면 된다.

 

 

 

 

• 또한 MQ의 장점인 부하분산 처리도 가능하다. 여러 C(Consumer)를 배치해, 원하는 메세지(데이터) 처리도 가능하다. 이러한 구조는 수평적 확장(Horizontal Scaling)에 유리하다.

 

 

 

 

 

메시지 큐 예시 : 톰캣

톰캣 내부 큐의 용량이 다 차게되면 이후의 요청은 실패하게 되고 큐 안의 요청들고 30초가 넘어가면 타임아웃이 발생

 

서버가 죽는 상황 해결하기(Message Queue 탄생 이유)

• Message Queue 도입

 

1. 글 작성하는 요청이 들어오면 컨트롤러에서 바로 Message Queue에 넣는다.
2. 요청을 받은 스레드는 Message Queue에 넣기만 하면 다음 요청을 받을 수 있다.
3. 애플리케이션의 다른부분 예로 서비스에서는 Message Queue에 있는 요청을 가져와 DB에 넣는 작업을 수행한다.

• 톰캣에 저장되어있는 요청은 메모리에 저장되어 있는 데이터이기 때문에 톰캣이 종료되면 모두 사라진다. 반면 Message Queue는 디스크에 저장하는 등 여러 옵션을 제공함.

 

 

Message Queue의 장점

비동기성

• 요청을 Message Queue에 저장했다가 처리하기 때문에 DB속도와는 무관하게 요청을 누락없이 처리 가능하다.
• DB에 요청을 처리하는 시간보다, Message Queue에 요청을 넣는 시간이 훨씬 짧다.

 

애플리케이션간 의존성 제거

 

위 그림에서 A는 B에게 의존성이 생긴다. 즉 B서버에 장애가 발생한다면 A가 B로 보내는 데이터는 유실된다.

 

 

 

중간에 Message Queue가 들어가게 되면 B 서버가 죽더라도 A가 보내는 데이터는 Message Queue에 저장되기 때문에, 추후에 B서버가 정상화 됐을 때 요청을 처리 할 수 있다.

 

 

확장성

서버를 스케일 아웃 해도 하나의 Message Queue만 바라보도록 할 수 있다.

하지만 Message Queue도 결국 소프트웨어이기 때문에 장애가 발생할 수 있다.

따라서 아래 그림처럼 고가용성(HA; High Availability, 이중화, 삼중화) 클러스터로 구성을 하여야 한다.

 

 

 

범용적으로 사용되는 RabbitMQ.

트래픽이 많다면 속도면에서 장점이 있는 Kafka.

각각 장단점이 존재하기 때문에 상황에 맞는 Message Queue를 선택해야 한다.

 

 

[Network] Load Balancing, Clustering (로드밸런싱, 클러스터링)