https://www.cloudamqp.com/blog/what-is-message-queuing.html
What is message queuing? | CloudAMQP - Lovisa Johansson을 번역한 것입니다.
모든 저작권은 CloudAMQP 블로그의 Lovisa Johansson에게 있습니다. All copyrights are in Lovisa Johansson.
Introduce
메시지 큐를 통해 애플리케이션은 서로 메시지를 전송하여 통신할 수 있다. 메시지 큐는 대상 프로그램이 사용 중이거나 연결되지 않은 경우 임시 메시지 저장소 역할을 한다.
이 블로그 문서는 아키텍쳐에서 message queuing 메시지 큐잉(대기열), 메시지 큐잉의 정의, 사용 방법 및 메시지 큐잉 사용의 이점에 대해 이야기한다.
Queue, Message
queue 큐는 처리 대기중인 항목들의 줄이며, 줄의 첫 시작 부분부터 순서대로 처리한다.
메시지 큐잉은 애플리케이션 사이에서 전송되는 메시지의 대기열이다. 처리 대기 중인 일련의 작업 개체를 포함한다.
message 메시지는 발신자와 수신자 응용 프로그램 사이에서 전송되는 데이터이며, 기본적으로 맨 위에 일부 헤더가 비어 있는 바이트 배열이다. 메시지의 예로는 한 시스템이 작업 처리를 시작하도록 지시하거나, 완료된 작업에 대한 정보를 포함하거나, 혹은 단순한 메시지가 될 수 있다.
메시지 큐의 기본 아키텍쳐는 간단하다. 메시지를 만들어 메시지 큐에 전달하는 producer 생산자라 불리는 클라이언트 애플리케이션이 있다.
consumer 소비자라고 불리는 다른 응용 프로그램들은 큐에 연결하여 처리할 메시지를 받는다.
큐에 배치된 메시지는 컨슈머가 회수할 때까지 저장된다.
Message queues
메시지 큐는 비동기 통신 프로토콜을 제공하는데, 이는 메시지를 메시지 큐에 넣고 지속적인 처리에 대한 즉각적인 응답을 필요로 하지 않는 시스템이다.
비동기 통신에 가장 좋은 예로 이메일을 이야기할 수 있다.
이메일이 전송되면, 발신자는 수신자의 즉각적인 응답 없이 다른 작업들을 계속해서 처리한다.
이러한 메시지 처리 방식은 생산자를 소비자로부터 분리시켜 동시에 메시지 큐와 통신할 필요가 없게 한다.
DECOUPLING AND SCALABILITY
디커플링은 시스템의 한 부분이 시스템의 다른 부분에 얼마나 의존하는지를 설명한다. 디커플링은 기능을 분리하여 기능이 더 독립적이도록 하는 과정이다.
decoupled system 분리된 시스템은 둘 이상의 시스템이 연결되지 않고 통신할 수 있을 때 달성된다. 시스템은 다른 기능을 인식하지 못하고 완전히 자율적으로 유지될 수 있다. 디커플링은 보통 유지보수가 쉬워 잘 구성된 컴퓨터 시스템의 지표 중 하나이다.
decoupled system의 한 프로세스가 큐의 메시지를 처리하지 못하는 경우에도 다른 메시지를 대기열에 추가하고 시스템이 복구되었을 때 처리할 수 있다.
메시지 큐는 지연처리에도 사용될 수 있다.
예를 들어, producer가 메시지를 큐에 전송한다. 지정된 시간에 consumer는 대기열에 있는 메시지를 시작하고 처리한다.
대기 중인 메시지는 저장 및 전송될 수 있으며, 메시지가 처리될 때 까지 재전송될 수 있다.
하나의 큰 애플리케이션을 만드는 대신, 애플리케이션의 다른 부분을 분리하여 메시지 큐를 사용하여 비동기적으로 상호 통신하는 것이 좋은 방법이다.
이를 통해 애플리케이션의 여러 부분이 독립적으로 발전하거나, 서로 다른 언어로 작성되거나, 분리된 개발 팀에 의해 유지 관리될 수 있다.
메시지 큐는 애플리케이션의 프로세스를 서로 분리하여 독립적으로 유지한다.
첫 번째 프로세스는 다른 프로세스를 호출하거나, 다른 프로세스에 알림을 게시하거나 다른 프로세스의 프로세스 흐름을 따를 필요가 없다.
메시지를 대기열에 넣은 다음 처리를 게속할 수 있다.
다른 프로세스들도 작업을 독립적으로 처리할 수 있으며, 처리할 수 있을 때 큐에서 메시지를 가져올 수 있다.
Message queuing - a simple use case
매 초당 많은 요청을 수신하는 웹 서비스가 있다고 가정해보자. 어떠한 요청도 손실되선 안되며, 모든 요청은 처리량이 높은 funciton으로 처리되어야 한다.
즉, 웹 서비스는 이전에 수신한 요청의 처리 때문에 잠겨선 안되며, 항상 높은 가용성과 새로운 요청을 받을 준비가 되어 있어야 한다.
이 경우 웹 서비스와 processing 서비스 사이에 큐를 배치하는 것이 이상적이다.
웹 서비스는 "start processing" 메시지를 큐에 넣을 수 있고, 다른 프로세스는 메시지를 순서대로 가져와서 처리할 수 있다.
두 프로세스는 서로 분리되어 있으므로 기다리지 않아도 된다. 짧은 시간 안에 들어오는 요청이 많으면 processing 시스템에서 모두 처리할 수 있다. 큐 시스템은 요청 수가 증가하더라도 요청을 계속 처리한다.
그 다음 비즈니스와 워크로드(workload, 작업량)이 증가하고 있으며 시스템을 확장해야 한다고 생각해보자. 이 때 해야 할 일은 대기중인 큐를 더 빨리 정리할 수 있도록 더 많은 consumer를 추가하는 것이다.
RabbitMQ
queue-based solution 큐 기반 솔루션을 고려하기 시작한 경우 AMQP는 RabbitMQ로 메시지 큐를 호스팅한다.
RabbitMQ는 AMQP(Advanced Message Queuing Protocol)을 구현하는 오픈 소스 메시지 지향 미들웨어이다.
AMQP에는 큐잉, 라우팅, 안정성 및 보안과 같은 기능이 있으며, CloudAMQP에 대해 더 자세히 알고 싶다면 이곳을 참고하자.
REFERENCE
