1. Message Queue Solutions 비교
| AWS SQS | RabbitMQ | Apache Kafka | Apache ActiveMQ | Eclipse Mosquitto | |
|---|---|---|---|---|---|
| 도입 구분 | 관리형 (Amazon SQS) | 설치형 오픈소스, 관리형 (Amazon MQ) | 설치형 오픈소스, 관리형 (Amazon MSK) | 설치형 오픈소스, 관리형 (Amazon MQ) | 설치형 오픈소스, 관리형 (Amazon IoT Core) |
| 메시지 모델 | 일반 Queue, FIFO Queue | Queue | Topic | Topic, Queue | Topic |
| 주요 특징 | Proprietary 프로토콜, AWS 완전 관리형, 높은 가용성 및 확장성 | AMQP 프로토콜 구현, 다양한 메시지 패턴 지원 (direct/fanout/topic 등), 풍부한 기능과 확장성 | Proprietary 프로토콜, 분산 스트리밍 플랫폼, 대용량 고성능 내결함성 확장성 | JMS 표준 구현, 다양한 메시지 라우팅 패턴 지원, Java 기반 | 경량 메시지 브로커로 MQTT 프로토콜 구현, 자원 소모 적음, IoT/M2M 환경 주로 사용 |
비교 / 우위 및 장점
| AWS SQS | RabbitMQ | Apache Kafka | Apache ActiveMQ | Eclipse Mosquitto | |
|---|---|---|---|---|---|
| 우위 및 장점 | 완전 관리형, 러닝커브 낮음, 신속한 배포/확장, DLQ로 실패 메시지 확인 편리, 서버리스 및 AWS 기반 통합 용이, FIFO 큐 메시지 순서 보장 | 다양한 언어 지원, 엔터프라이즈 환경 적합, 다양한 기능, 높은 성능 및 안정성, 다양한 확장 옵션 | 오픈소스 중 가장 풍부한 에코시스템, 대규모 이벤트 스트리밍, 브로커 클러스터링 Scale Out/In, 메시지 영속 저장 및 분산 데이터 처리 중점 | 클러스터링 및 다양한 라우팅 패턴, JMS/OpenWire/MQTT/STOMP 프로토콜 지원, Java 애플리케이션과 상호운용성 우수, 메시지 필터링/선택/변환/그루핑 기능 | 단순한 구조, 경량으로 빠른 메시지 전달, QoS 설정 가능 |
| 성능 및 운영 이슈 | 메시지당 256KB 용량 제한, FIFO 큐 초당 3,000개 제한, 일반 큐 순서 보장 안됨, 대용량 데이터 스트리밍 부적합 | 설정/관리 복잡, 다수 Consumer 간 순서 보장 안됨, 대용량 시 자원 사용량 증가 | 설정/관리 복잡, Topic 내 메시지 순서 보장 안됨 (같은 파티션 내에서는 보장), 대용량 시 자원 사용량 크게 증가 | 특정 Queue 순서 보장 설정 가능하나 Topic은 보장 안됨, 대규모 고성능 시나리오에서 Kafka보다 확장성 낮음 | 대규모/높은 처리량 요구사항에 부적합, IoT 이외에는 레퍼런스 빈약 |
분산 처리 구조
| AWS SQS | RabbitMQ | Apache Kafka | Apache ActiveMQ | Eclipse Mosquitto | |
|---|---|---|---|---|---|
| 분산 처리 | Queue에 메시지는 단 한번 소비되고 삭제 | Exchange에서 Fanout/Topic 타입 바인딩으로 여러 Queue에 발행 가능, 메시지 단 한번 소비 후 삭제 | Consumer Group 단위로 소비, 같은 Group 내 중복 없음, 여러 Group이 동일 메시지 수신 가능 | Queue: 단 한번 소비 후 삭제, Topic: 구독하는 모든 Consumer에 전달 | 발행된 메시지는 Topic 구독하는 모든 Consumer에서 소비 |
2. AWS SQS 메시지 처리 구조
- Queue(대기열)를 생성하고 Producer가 Queue에 메시지 전송 → Consumer가 Pull 수신 처리
- Point-to-Point만 지원: 하나의 메시지를 여러 Consumer가 동시에 중복 수신 불가
- 메시지는 단 한번 소비되며 처리 완료 시 삭제
- 처리 실패한 메시지는 삭제되지 않고 Dead-Letter Queue(DLQ) 로 Redrive되어 재처리 대기
3. RabbitMQ 메시지 처리 구조
- Broker는 Exchange와 Message Queue로 구성
- Producer → Exchange → (Routing Key & Binding 규칙) → Queue → Consumer
- 메시지는 단 한번 소비 후 삭제
Exchange 3가지 타입
Direct
- Routing Key와 Binding Key가 정확히 일치하는 경우에만 Queue로 송신
- 1개의 Queue를 수신하는 Consumer가 여러 개면 번갈아 수신
Fanout
- Routing Key 관계없이 Exchange에 Binding된 모든 Queue에 메시지 송신
Topic
- 와일드카드를 이용해 Binding, Routing Key 매핑으로 메시지 라우팅
*= 1개 단어,#= 0개 이상 단어
4. Apache Kafka 메시지 처리 구조
- Producer → Topic (여러 Partition으로 구성, 기본 Round Robin 분산) → Consumer Group
- 같은 Partition 내에서는 순서 보장, 다른 Partition 간에는 순서 보장 안됨
- Consumer Group 단위로 메시지 수신: 다른 MQ와 달리 같은 메시지를 여러 Group이 각각 수신 가능
- Consumer 인스턴스 추가/제거 시 자동 Rebalancing → Scale In/Out 용이
5. Apache ActiveMQ 메시지 처리 구조
- P2P: Queue의 메시지는 단 하나의 Consumer 인스턴스에서만 소비, 처리 후 삭제
- Pub/Sub: Topic의 메시지는 구독하는 모든 Consumer에 동시 전달
6. Eclipse Mosquitto 메시지 처리 구조
- Producer → Broker의 Topic → 해당 Topic을 구독하는 모든 Device에 메시지 전달
7. Pub/Sub 패턴 분산처리 가상 개발 시나리오
시나리오: Producer에서 인버터 장비 상태 메시지를 발행 → User / Equipment / Event / Contents 4개 도메인 시스템이 구독하여 각자 비즈니스 처리
SQS
- 도메인 시스템 갯수별로 Queue 생성
- Queue당 메시지 한번 소비 후 삭제 → Scale Out 시 중복 처리 부담 적음
- Producer가 복수의 Queue 대상으로 메시지를 발행해야 하므로 트랜잭션 처리 유념 필요
RabbitMQ
- 도메인 시스템 갯수별로 Queue 생성 (SQS와 동일 Flow)
- Exchange가 복수 Queue 라우팅을 담당 → Producer는 Routing Key만 맞춰 Broker에 한번만 전송
- Exchange의 라우팅/바인딩 규칙 관리가 운영 이슈
Apache Kafka
- Topic 1개 생성, 데이터 처리량 기준으로 Partition 설정 (보통 3개)
- 도메인 시스템별 Consumer Group 설정, 구독 Topic에 연결
- Consumer Group 단위로 메시지 수신 → 같은 Group 내 중복 처리 부담 적음
Apache ActiveMQ
- 일부 도메인에만 전송할 경우: 시스템 갯수별 Queue 생성 후 Producer 발행
- 모든 시스템에 전송할 경우: Topic을 통해 발행
- Topic은 모든 Consumer 인스턴스에 메시지 수신 → Scale Out 시 중복 메시지 처리 방안 강구 필요
8. 솔루션 채택 기준
평가표
| AWS SQS | RabbitMQ | Apache Kafka | Apache ActiveMQ | Eclipse Mosquitto | |
|---|---|---|---|---|---|
| 애플리케이션 적합성 | ▲ | ▲ | ▲ | ▲ | ▼ |
| 가용성 | ▼ | ▲ | ▲▲ | ▲ | ▼▼ |
| 분산처리 성능 | ▼ | ▲ | ▲▲▲ | ▲▲ | - |
| 유지보수성 | ▲ | ▼ | ▼ | ▼ | ▼ |
| 자원소비량 | ▲ | ▼ | ▼ | ▼ | ▲ |
분산처리 성능 순위
Apache Kafka > Apache ActiveMQ > RabbitMQ > SQS
자원소비량 순위
Apache Kafka > RabbitMQ = Apache ActiveMQ > MQTT > SQS
9. SQS vs MSK vs EC2-Kafka 비교
| SQS | MSK | EC2-Kafka | |
|---|---|---|---|
| 데이터 영속성 | 삭제 시까지 유지 | 삭제 시까지 유지 | |
| 보관 기간 | 60초~14일 | default 7일 (수정 가능) | |
| 프로토콜 | HTTP/HTTPS, SDK | Kafka 프로토콜 | |
| 기본 전달방식 | FIFO 순서보장 | 동일 파티션 내 순서 보장 (키 미지정 시 round robin) | |
| 성능 | 초당 최대 300개 | 무제한 (비용만큼 처리) | |
| 메시지 size limit | 256KB | 8MB | default 1MB |
| 보안 | IAM | IAM | SSL/TLS |
| 모니터링 | CloudWatch | CloudWatch | 없음 (OS 모니터링만) |
| 비용 | 백만건 프리티어, 이후 백만건당 $0.4 | 월 $72.85 + 네트워크 비용 (kafka.t3.small×2, 50GB) | 월 $58.20 + 네트워크 비용 (t4g.small×3, 50GB) |
| 설정 복잡도 | 상대적으로 낮음 | 중간 | 상대적으로 높음 |
| 선택 기준 | 1:1 메시지 큐잉 | M:N 메시지 큐잉 |
10. 분산처리 구조 제안
-
고가용성 / 분산처리 효율성 최우선 → Apache Kafka
- 오픈소스 중 가장 풍부한 레퍼런스
- 자원 사용량은 타 솔루션과 현격한 차이 없음
- 운영 러닝커브와 복잡성은 감안 필요
-
유지보수성 / 편리성 최우선 → AWS SQS
- 성능 제약과 분산처리 시 개발 부담이 있으나 유지보수성과 비용 측면에서 유리
-
MQTT(Mosquitto) 는 서버 애플리케이션 간 인터페이스에는 적합하지 않음
최종 제안
다중 분산처리 니즈가 크지 않고 Monolithic에 가깝다면 → SQS
대용량 데이터 분산처리와 시스템 확장성/고가용성을 고려한다면 → Apache Kafka
서버 애플리케이션 간 인터페이스는 Apache Kafka 또는 SQS, Mobile Device 대상 메시지 발행 시는 AWS IoT 일부 도입
- Case 1
Case 1 - Case 2
Case 2
