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 프로토콜 활용).

  • 중앙 서버 혹은 클라우드 환경에서 데이터를 모아서 분석/처리를 수행한다.

  • 네트워크가 불안정해도 메시지 큐가 재전송, 저장 등을 담당하므로 데이터 손실을 줄일 수 있다.