반응형
개요
애플리케이션에서 다른 애플리케이션이 이용할 수 있는 데이터 패킷을 수신 애플리케이션이 준비가 되었을 때 발송해줌
(네트워크나 수신 애플리케이션의 장애가 발생하더라도 메시지 큐는 보존됨)
흐름도
Producer → 메시지(작업) 지시 → Queue(적재 & 반출) → 메시지(작업) 진행 → Consumer
적용 분야
메시지 큐의 사용 목적은 큐에 적재한 작업이 언젠가 소비(실행) 될거라고 믿기 때문이다.
일반적인 HTTP 요청일 경우 (Client ↔ Sever) 소비자는 응답을 기다려야 하므로 메시지 큐는 바람직하지 않다.
아래 분야에 적용하기 적합
- 블로그 포스팅 : 용량이 큰 이미지의 경우 업로드 시 이미지 최적화 서비스의 큐를 사용
- 이메일 : 애플리케이션의 핵심 기능이 아닐 경우 메시지 큐를 통해 메일 발송이 가능
- API 호출 : 다른 곳의 API로부터 데이터 송수신
장점
- 비동기 (Asynchronous) : 사용자와 동기화하지 않고 메시지 큐를 통해 비동기로 처리
- 낮은 결합도(Decoupling) : 메시지 큐를 이용한 생산자 서비스와 소비자 서비스는 독립적
- 확장성(Scalable) : 원하는 대로 확장이 가능
- 회복성(Resilience) : 소비자 서비스가 중단되더라고 메시지는 보존됨
- 보장성(Guarantees) : 메시지 큐에 저장된 모든 메시지는 결국 소비자에게 전달됨
데이터베이스와 비교
- DB는 저장소로 같은 정보에대한 반복 접근이 가능하지만 메시지 큐는 저장소가 아니며 이용된 메시지는 큐에서 삭제됨
- 메시지 큐와 비슷하게 DB 설계는 가능하지만, 단순한 큐 구조 복제 용도로 사용가능하며 대규모 애플리케이션에서는 상황에 맞게 확장이 불가능
- 결론 : 데이터베이스는 경우에 따라 메시지 큐 대신 쓸 수 있으나, 각각의 특징상 서로의 대안이 될 수 없음
종류
- ActiveMQ(JMS)
- RabbitMQ
- Apache Kafka
반응형
