메시지 큐란?
메시지 큐(Message Queue)는
프로세스 또는 프로그램 간에 데이터를 교환할 때 사용하는 통신 방법으로, 메시지란 요청, 응답, 오류 메시지 혹은 단순한 정보 등의 작은 데이터들을 모아 버퍼로서의 큐에 중간 브로커를 두고 일대일, 비동기적으로 통신한다.
그림을 통해 쉽게 이해해보자. 메시지를 전송 및 수신하기 위해 중간에 메시지 큐를 두는 것을 볼 수 있다.
메시지 전송 시 생산자(Producer)로 취급되는 컴포넌트가 메시지를 메시지 큐에 추가한다. 해당 메시지는 소비자(Consumer)로 취급되는 또 다른 컴포넌트가 메시지를 검색하고 이를 사용해 어떤 작업을 수행할 때까지 메시지 큐에 저장된다.
각 메시지는 하나의 소비자에 의해 한 번만 처리될 수 있는데, 이러한 이유로 메시지 큐를 이용하는 방식을 일대일 통신이라고 부르는 것이다.
메시지 큐 사용 예
일반적인 통신 방식 HTTP
일반적인 클라이언트-서버 구조에서는 사용자가 요청을 하면 서버는 그에 대한 처리를 한 후 클라이언트에게 응답을 한다.
간단한 서버 구조에서는 굳이 메시지 큐를 사용할 필요가 없다.
사용자가 응답을 기다려야 하는 HTTP 요청을 바로 처리하지 않고 중간에 메시지 큐를 두는 경우는 썩 바람직하지 않아 보인다.
메시지 큐를 적용하려면 시스템의 목적에 맞는 것을 선정해야 한다.
이후 선정된 메시지 큐의 사용 방법도 익혀야 하며, 지원하는 다양한 옵션 중에 시스템이 추구하는 목적에 맞는 옵션을 찾아 설정해야 한다. 상상만 해도 번거로운 작업들이 수반되는데, 왜 메시지 큐를 사용하며, 어떤 경우에 도입하는 걸까?
메시지 큐는 소비자(Consumer)가 실제로 메시지를 어느 시점에 가져가서 처리하는 지는 보장하지 않는다.(비동기의 특징) 언젠가는 큐에 넣어둔 메시지가 소비되어 처리될 것이라고 믿는 것이다.
이러한 비동기적 특성 때문에 메시지 큐는 실패하면 치명적인 핵심 작업보다는 어플리케이션의 부가적인 기능에 사용하는 것이 적합하다.
실제로 어떤 작업들에 메시지 큐를 사용하는지 예시를 통해 살펴보자.
이메일 전송
- 비밀번호 재설정을 위해 이메일을 발급하는 서비스, 회원가입을 위해 이메일을 발급하는 서비스 등은 메시지(이메일)를 큐에 넣을 수 있다.
- 이메일 전송 전용 서비스는 이메일이 어느 서비스로부터 생산되었는지와는 관계없이, 메시지 큐의 메시지를 하나씩 소비하고, 그저 이메일이 전송되어야 할 곳으로 이메일을 전송한다.
- 이와 같은 접근 방식은 메시지 큐에 들어오는 메시지 수가 너무 많아지는 경우 이메일 전송 전용 서비스 인스턴스를 더 둠으로써 확장할 수 있으므로 확장성이 뛰어나다.
블로그 포스팅
모든 블로그 사용자가 웹에 최적화되어 있거나, 용량이 작은 이미지만 업로드하진 않을 것이다. 블로그 사용자가 게시글에 업로드한 이미지의 용량이 매우 큰 경우를 생각해보자. 블로그 서비스의 응답 시간을 저해하지 않으면서 사용자들에게 유연성을 제공하는 방법으로, 사용자가 업로드한 모든 이미지를 게시 과정에서 즉각 처리하는 것이 아닌, 사후처리하며 최적화하는 방법이 있다. 사용자 경험에 약간의 영향을 미칠 수는 있지만, 최적화는 응용 프로그램에서 가장 중요한 것은 아니며 작업을 즉시 수행할 필요도 없다. 메시지 큐는 이러한 상황에서도 사용될 수 있다.
- 사용자가 고용량의 이미지가 포함된 블로그 포스팅을 한다.
- 이미지는 저장소에 전송된다.
- 업로드된 이미지에 대한 정보가 포함된 메시지를 이미지 최적화 서비스의 메시지 큐에 담는다.
- 이미지 최적화 서비스는 저장소에서 이미지를 가져와 최적화하고, 2번에서 저장해놨던 이미지를 대체한다.
메시지 큐의 이점
메시지 큐를 사용함으로써 얻을 수 있는 이점은 다음과 같다.
비동기(Asynchronous)
메시지 큐는 생산된 메시지의 저장, 전송에 대해 동기화 처리를 진행하지 않고, 큐에 넣어 두기 때문에 나중에 처리할 수 있다. 여기서, 기존 동기화 방식은 많은 메시지(데이터)가 전송될 경우 병목이 생길 수 있고, 뒤에 들어오는 요청에 대한 응답이 지연될 것이다.
낮은 결합도(Decoupling)
생산자 서비스와 소비자 서비스가 독립적으로 행동하게 됨으로써 서비스 간 결합도가 낮아진다.
확장성(Scalable)
생산자 서비스 혹은 소비자 서비스를 원하는 대로 확장할 수 있기 때문에 확장성이 좋다.
탄력성(Resilience)
소비자 서비스가 다운되더라도 어플리케이션이 중단되는 것은 아니다. 메시지는 메시지 큐에 남아 있다. 소비자 서비스가 다시 시작될 때마다 추가 설정이나 작업을 수행하지 않고도 메시지 처리를 시작할 수 있다.
보장성(Guarantees)
메시지 큐는 큐에 보관되는 모든 메시지가 결국 소비자 서비스에게 전달된다는 일반적인 보장을 제공한다.
정리
결국은 서버가 사용자에게 얼마나 빠르고 안정적으로 정보를 전달할 수 있는 지에 초점을 맞춘 기술이라고 생각한다.
모든 어플리케이션에 메시지 큐가 필요한 것은 아니지만, 서버의 뒷단에서 실행되는 일부 작업을 메시지 큐에 맡김으로써 웹 어플리케이션의 성능을 향상시키는 것에 대해 생각해보는 것도 좋을 것이다.
또한 메시지 큐에도 RabbitMQ, Kafka, ActiveMQ 등과 같은 다양한 오픈소스 시스템이 존재하는데, 각 시스템별 비교 분석 후 현재 도입하고자 하는 서비스에 적합한 시스템을 선정하는 것이 좋다.
출처
