# Messaging Queue

## 1. 개요

분산 환경에서 서로 다른 프로세스나 애플리케이션 간에 데이터를 비동기적으로 주고 받기 위한 통신 방식을 제공하는 소프트웨어 구성 요소입니다. 발신자와 수신자 사이(pub/sub)에서 중간 버퍼 역할을 하며, 발신자가 전송한 메시지를 큐에 저장했다가 수신자가 준비되었을 때 메시지를 꺼내 처리할 수 있도록 합니다.



## 2. 필요성

* 비동기 처리: 동기 방식은 시스템 부하를 증가시키고, 장애 상황 발생시 병목 상태가 될 수 있습니다. 필요한 작업을 큐에 넣고, 순차적으로 백엔드에서 순차적으로 처리하도록 할 수 있습니다.
* 유연한 확장성: 각 프로세스가 별도로 확장될 수 있습니다. 어떤 기능에 대해 처리율이 낮으면, 메시지를 축적했다가 워커 인스턴스를 늘려서 동시에 처리하여 부하를 능동적으로 조절 가능.
* 시스템 간 느슨한 결합: 발신자와 수신자 간의 의존성을 낮춥니다. 서로를 직접 호출하거나 상태를 알 필요가 없고, 큐에 넣는 순간, 해당 작업은 처리 되었다고 볼 수 있습니다.
* 내결함성: 장애 상황이 발생해도 메시지를 안전하게 보관할 수 있습니다.



## 3. 주요 특성과 기능

### 3.1. 주요 개념

* 프로듀서: 발신자 역할로 큐에 메시지를 publish
* 컨슈머: 수신자 역할로 큐에서 메시지를 consume
* 큐: 메시지가 임시로 저장되는 버퍼. FIFO 또는 우선순위 큐 등 사용 가능
* 토픽: 메시지를 적절한 큐에 전달하기 위한 중간 단계.
* 라우팅: 메시지를 여러 큐 중 어디로 보낼지 결정하는 과정 또는 규칙

### 3.2. 필수 기능

* 메시지 영속성: 메시지 큐 시스템에 장애가 발생하더라도 메시지가 유실되지 않게 설계해야함
* 확장성: 트래픽이 증가할 때, 큐/컨슈머/브로커 노드를 쉽게 확장할 수 있어야함
* 트랜잭션/ACK: 메시지 전송 과정에서 실패하거나 컨슈머가 메시지 처리를 못한 경우, 재시도가 가능해야하며, 정상 처리됨을 확인하는 Return값(ack)이 필요하다.
* 보안: 메시지 전송 과정에서 데이터 암호화, 접근 제어, 인증 등을 제공해야 한다.
* 모니터링 및 관리: 메시지 큐의 상태를 실시간으로 모니터링할 수 있어야한다. (큐 길이, 메시지 처리 속도, 에러 여부 등)



## 4. 장단점

### 4.1. 장점

* 비동기 작업 처리: 요청에 대한 빠른 응답 및 백그라운드 처리. 서버 과부하를 줄임
* 유연한 아키텍처 설계: 모듈간 결합을 낮춰 독립적인 확장 및 유지보수가 가능
* 장애 격리: 중간 완충 지대로 작동하므로, 일부 모듈이 장애가 발생해도 메시지는 큐에 안전하게 적재. 장애가 해결되면 다시 처리를 이어갈 수 있음
* 메시지 우선순위 및 스케줄링: 특정 메시지 우선 처리, 예약된 시간에 처리 등

### 4.2. 단점

* 운영 복잡도 증가: 메시지 큐 서버(브로커)를 별도로 운영해야해서 배포와 관리, 모니터링 부담
* 메시지 지연: 비동기 패턴이기 때문에, 즉각적인 결과 확인이 어렵다
* 메시지 중복 처리 가능성: 네트워크 장애나 ACK 실패 등 다양한 이유로 메시지가 중복 처리될 가능성. 멱등성을 고려하는 로직이 필요



## 5. 주요 프로토콜

* AMQP (Advanced Message Queuing Protocol)
  * 표준화된 메시징 프로토콜
  * 교환기와 라우팅 키를 통해 메시지를 유연하게 라우팅
  * 안정적인 메시지 전달 보장, 트랜잭션 지원
* MQTT(Message Queuing Telemetry Transport)
  * IoT 환경에서 사용되는 경량 메시지 프로토콜
  * 낮은 대역폭, 제한된 자원에서 동작하는 디바이스에 최적화
  * Pub/Sub 모델로 작동
* STOMP(Simple/Streaming Text Oriented Messaging Protocol)
  * 텍스트 기반 간단한 메시징 프로토콜
  * Frame 단위로 메시지를 주고 받으며 구현이 쉬움
  * 웹 소켓 환경과 결합해 실시간 메시징을 지원하는 경우도 많다.

## 6. 대표적인 메시지 큐

### 6.1. RabbitMQ

AMQP 프로토콜을 구현한 가장 대표적인 메시지 브로커. 교환기(Exchange), 라우팅 키(Routing Key), 바인딩(Binding) 등을 통해 유연한 메시지 라우팅을 제공. 플러그인을 통해 다양한 인증 및 모니터링 기능을 쉽게 확장 가능.

* **장점**:
  1. AMQP 기반으로 강력한 메시징 패턴 지원(Direct, Fanout, Topic, Headers).
  2. 사용자 친화적인 관리 콘솔과 모니터링 기능.
  3. 커뮤니티가 커서 정보와 예제가 풍부.
* **단점**:
  1. 고성능 대량 메시지 처리 측면에서는 다른 큐 솔루션(Kafka 등) 대비 오버헤드가 발생할 수 있다.
  2. Erlang 기반 설치와 운영에 대한 러닝 커브가 있을 수 있다.

### 6.2. Apache Kafka

대규모 실시간 로그 처리와 스트리밍(Streaming) 데이터 파이프라인 구축에 널리 쓰이는 메시지 브로커. 분산 환경에서 고성능, 고가용성, 내결함성을 제공한다.

* **장점**:
  1. 메시지를 디스크에 연속적으로 기록하는 구조로 **처리량(Throughput)이 높다**.
  2. 파티션(Partition)을 통한 수평 확장성이 뛰어나 수십만 TPS(초당 트랜잭션)까지도 가능하다.
  3. 스트리밍 플랫폼(예: Kafka Streams)으로 발전하여 실시간 데이터 처리가 용이하다.
* **단점**:
  1. 단순 큐 용도보다는 **스트림 처리**가 주목적인 경우가 많다.
  2. 운영이 다소 복잡하여 Zookeeper 관리(또는 KIP-500 이후 내부 관리)를 포함해 러닝 커브가 존재한다.
  3. 메시지를 영구 저장하는 특성상, 적절한 디스크 용량 관리와 데이터 Retention 정책 설정이 필수다.

### 6.3. AWS SQS (Simple Queue Service)

아마존 웹 서비스(AWS)에서 제공하는 완전 관리형 메시지 큐 서비스. 개발자가 인프라 운영을 걱정할 필요 없이 API를 통해 메시지 큐를 사용한다.

* **장점**:
  1. 서버리스(Serverless) 방식으로, 관리 오버헤드가 거의 없다.
  2. 자동 스케일링, 지연 큐, FIFO Queue 등 다양한 기능을 제공한다.
  3. 다른 AWS 서비스와 쉽게 연동(AWS Lambda, SNS 등).
* **단점**:
  1. AWS 클라우드 환경에 종속적이다.
  2. 고성능 처리가 필요한 경우 비용이 급격히 증가할 수 있다.
  3. 메시지 크기 제한(기본 256KB) 등의 제약이 존재.

### 6.4. ZeroMQ

매우 경량화되고 빠른 메시지 라이브러리로, “브로커리스(Brokerless)” 방식의 메시징을 지향한다. 별도의 중앙 서버 없이 애플리케이션 간에 P2P 방식으로 메시지를 교환할 수 있다.

* **장점**:
  1. 속도가 매우 빠르고, 다양한 언어 바인딩을 제공한다.
  2. 중앙 브로커가 없어서 운영 복잡도가 낮아질 수 있다.
  3. 소규모 분산 환경이나 실시간 처리가 필요한 시스템에 적합.
* **단점**:
  1. 브로커가 없으므로 메시지 영속성이나 재시도 로직을 개발자가 별도로 구성해야 한다.
  2. 구조가 단순하여 고급 기능(모니터링, 관리 콘솔 등)이 부족하다.

### 6.5. ActiveMQ / ActiveMQ Artemis

Apache 재단에서 개발한 JMS(Java Message Service) 기반의 메시지 브로커. 비교적 오래된 솔루션이지만 여전히 활발하게 사용된다. ActiveMQ Artemis는 보다 최신 아키텍처와 고성능을 지원한다.

* **장점**:
  1. JMS 표준 준수로, 자바 환경에서 쉽게 연동 가능하다.
  2. 다양한 프로토콜(AMQP, MQTT, OpenWire 등)을 지원한다.
  3. 트랜잭션, 지연 전송(Delayed Delivery), 가상 토픽(Virtual Topic) 등 유연한 기능 제공.
* **단점**:
  1. 비교적 무거울 수 있고, RabbitMQ나 Kafka에 비해 인지도가 낮아진 편.
  2. 대규모 트래픽 처리 측면에서는 성능 튜닝이 필수적이다.

## 7. 사용 주의사항

* **멱등성(Idempotency) 고려**
  * 네트워크 지연, 중복 ACK 등으로 메시지가 중복 처리될 수 있다.
  * 소비자(Consumer)는 동일 메시지가 여러 번 도착해도 결과가 변하지 않도록 로직을 설계해야 한다(예: 작업 상태 테이블에서 ‘처리 완료’ 상태 확인 후 무시).
* **적절한 재시도 정책(Retry Policy)**
  * 메시지 처리가 실패했을 때, 일정 횟수 재시도한 뒤 사별(死別) 큐(Dead Letter Queue)로 옮겨서 별도 모니터링하는 방식을 권장한다.
  * 무한 재시도로 인해 큐가 막히거나 서비스가 오동작하지 않도록 주의해야 한다.
* **큐 모니터링**
  * 메시지 누적(Backlog) 상태, 처리 속도, 소비자 상태 등을 지속적으로 모니터링해야 한다.
  * 누적된 메시지를 신속히 처리할 수 있도록 컨슈머 인스턴스 자동 확장(Auto-Scaling) 전략을 세울 수 있다.
* **메시지 크기 관리**
  * 메시지를 지나치게 크게 만들면 큐의 운영과 성능에 부담이 된다. 대용량 파일이나 이미지는 별도의 스토리지(예: S3, FTP 등)에 저장하고, 메시지에는 참조 링크나 메타데이터만 담는 것이 일반적이다.
* **배포 전략**
  * 메시지 큐 브로커를 다중화하고, 클러스터링 또는 복제(Replication) 구성으로 가용성을 높여야 한다.
  * 모든 서비스를 한꺼번에 업데이트하는 대신 점진적으로 롤링 업데이트(Rolling Update)를 적용해 다운타임을 최소화한다.
* **메트릭 기반 자동 확장**
  * AWS SQS, RabbitMQ 등은 큐 길이, 메시지 전송량, 처리 속도 등의 지표를 CloudWatch나 Prometheus 같은 모니터링 도구와 연동할 수 있다.
  * 특정 임계값(예: 큐에 1,000개 이상의 메시지가 누적)이 넘으면 자동으로 컨슈머 리소스를 확장하도록 설정한다.

## 8. 다른 아키텍처 연계

메시지 큐는 마이크로서비스 아키텍처, 이벤트 중심 아키텍처에서 중심적인 역할을 수행한다. 다음은 대표적인 연계 예시이다.

1. **이벤트 드리븐(Event-Driven) 마이크로서비스**
   * 애플리케이션 A에서 어떤 이벤트가 발생하면 메시지 큐(또는 브로커)에 이벤트를 발행(Publish)한다.
   * 애플리케이션 B, C 등은 관심 있는 이벤트 타입을 구독(Subscribe)하여 필요한 로직을 수행한다.
   * 서비스 간 결합도가 낮아지고, 확장 및 수정이 용이해진다.
2. **스트리밍 데이터 파이프라인**
   * Kafka 같은 메시지 시스템을 통해 실시간 로그, 센서 데이터, 사용자 이벤트 등을 수집한다.
   * Spark, Flink, Kafka Streams 등 스트리밍 프레임워크가 메시지 스트림을 가공하고, 분석 결과를 DB나 데이터 웨어하우스에 적재한다.
3. **서버리스(Serverless) 아키텍처**
   * AWS Lambda, Azure Functions, Google Cloud Functions 등과 SQS, SNS를 연동하면, 메시지를 트리거로 잡아 함수가 실행되도록 할 수 있다.
   * 특정 조건이 충족되면 메시지를 발행하고, 함수를 자동으로 호출하여 비즈니스 로직을 수행한다.
4. **로그 집계 및 모니터링 시스템**
   * 시스템 곳곳에서 발생하는 로그를 메시지 큐를 통해 중앙 로그 서버(예: ELK Stack, Splunk)로 전송해 분석, 모니터링에 활용할 수 있다.

## 9. 활용 사례

* **주문 처리 시스템**
  * 온라인 쇼핑몰에서 결제 완료 이벤트가 발생하면 메시지 큐에 “주문 생성” 메시지를 넣는다.
  * 재고 확인, 배송 준비, 결제 확인 등의 작업을 비동기로 처리한다.
  * 장애가 발생해도 메시지가 큐에 남아 있어 재처리가 가능하다.
* **이미지/영상 처리 파이프라인**
  * 사용자가 이미지를 업로드하면 업로드 이벤트를 메시지 큐에 등록한다.
  * 백엔드의 이미지 변환 마이크로서비스가 메시지를 구독하여 리사이징, 워터마킹, 썸네일 생성 같은 작업을 수행한다.
  * 대량의 이미지 처리가 필요한 경우, 컨슈머 마이크로서비스 인스턴스를 자동으로 늘려 빠르게 처리를 마무리할 수 있다.
* **실시간 알림 시스템**
  * 특정 트랜잭션 이벤트가 발생하면 해당 정보를 메시지 큐를 통해 알림 서비스에게 전달한다.
  * 알림 서비스는 이메일, SMS, 앱 푸시(push) 등 다양한 채널로 알림을 발송한다.
  * 다양한 채널에 동시에 알림을 보낼 수 있고, 어느 채널에서 장애가 발생하더라도 메시지 유실을 방지할 수 있다.
* **IoT 센서 데이터 수집**
  * 수많은 IoT 센서가 주기적으로 측정값을 메시지 큐로 전송한다(MQTT 프로토콜 활용).
  * 중앙 서버 혹은 클라우드 환경에서 데이터를 모아서 분석/처리를 수행한다.
  * 네트워크가 불안정해도 메시지 큐가 재전송, 저장 등을 담당하므로 데이터 손실을 줄일 수 있다.
