메세지 큐 (Message Queue) 란 메시지 기반의 미들웨어로 메시지를 이용하여 여러 어플리케이션, 시스템, 서비스들을 연결해주는 솔루션이다.
서비스를 구축하고 운영하다 보면 성능에대해서 고려하게 된다. 그러나 데이터 처리를 하다 보면 너무 많은 데이터 처리로 인하여 서버 성능이 낮아지고 심각할 경우 서버 마비 현상이 와 야근을 하게 된다...
이러한 방법을 해결하기위해 클라이언트단에서는 DB구성을 최적화 하지만 비용이 많이들며 한계도 많다. 이를 해결하기위해 비동기 메세지 처리방식을 선택하였고 그게 바로 메세지 큐 이다.
간단하게 메시지큐를 설명하기에 앞서 그와 관련된 개념들을 정리하자면 .
- 메시지 지향 미들웨어(Message Oriented Middleware : MOM)
: 분산 시스템 간 메시지를 주고 받는 기능을 지원하는 소프트웨어나 하드웨어 인프라
- 메시지 큐(Message Queue : MQ)
: MOM을 구현한 시스템
- 브로커(Broker)
: Message Queue 시스템
- AMQP(Advanced Message Queueing Protocol)
: 메시지 지향 미들웨어를 위한 프로토콜
Producer(생산자)가 Message를 Queue에 넣어두면, Consumer가 Message를 가져와 처리하는 방식이다.
이렇게 중간에 큐를 둬서 데이터 처리를 향상시킬 수 있을까라는 의문이 들지만 데이터 처리방식을 살펴보면 Client와 동기방식으로 많은 데이터 통신을 하게 되면 병목현상이 생기게괴고 서버의 성능이 저하 된다. 이러한 현상을 막고자 중간에 미들웨어에 메시지를 위임하여 순차적으로 처리하게끔 한다.
가장 대표적인 예시를 들자면
카프카(Kafka)
대용량 실시간 로그 처리에 특화된 메시지 큐 시스템
장점
1. 단순 메시지 헤더를 지닌 TCP 통신
2. 개별 전송이 아닌 다수 전송 가능(Batch 처리 가능)
3. 파일 시스템에 저장(데이터의 영속성 보장)
4. 대기 중인 메시지로 인한 시스템 성능 감소 줄임
5. 분산 시스템이 기본적으로 설계
단점
1. 큐의 기능은 기존 JMS나 Broker보다 부족
대용량 데이터처리에 특화된 Kafka이다.
결론
이러한 메세지 큐 시스템은 데이터 처리에 특화되있고 최근 GCP에서 Pub/Sub이라는 메세지 큐 시스템을 클라우드 서비스로 제공한다. 아마도 이러한 클라우드 서비스가 대중화 될 날이 얼마 남지 않았기 때문에 Pub/Sub이 유행을 탈것으로 예상되고 기대된다.
