Amazon MQ: 온프레미스 메시지 브로커를 AWS로 마이그레이션하는 방법
Amazon MQ의 ActiveMQ/RabbitMQ 엔진, SQS/SNS와 차이점, 마이그레이션 시나리오와 SAA-C03 시험 핵심 정리.
관련 시험 도메인
- Domain 3: Design High-Performing Architectures
핵심 요약
Amazon MQ는 Apache ActiveMQ와 RabbitMQ를 지원하는 관리형 메시지 브로커입니다. 기존 애플리케이션을 코드 변경 없이 AWS로 마이그레이션할 때 사용하며, 새 애플리케이션은 SQS/SNS를 권장합니다.
시험 팁
시험 핵심: "JMS, AMQP, MQTT 프로토콜 사용" → Amazon MQ, "새 애플리케이션 + 무제한 확장" → SQS/SNS, "온프레미스 ActiveMQ 마이그레이션" → Amazon MQ
Amazon MQ는 언제 사용해야 할까?
적합한 경우
Amazon MQ 적합 시나리오:
├── 온프레미스 메시지 브로커 마이그레이션
│ └── ActiveMQ, RabbitMQ 사용 중인 기존 시스템
├── 표준 프로토콜 필요
│ └── JMS, AMQP, MQTT, STOMP, OpenWire
├── 기존 코드 변경 최소화
│ └── 엔드포인트만 변경하고 프로토콜 유지
└── 양방향 통신 필요
└── 요청-응답 패턴, 임시 큐
부적합한 경우
Amazon MQ가 최선이 아닌 상황:
├── 새로 구축하는 클라우드 네이티브 앱
│ → SQS/SNS 사용 (더 단순, 더 확장성)
├── 무제한 확장이 필요한 경우
│ → SQS (사실상 무제한 처리량)
├── 서버리스 아키텍처
│ → SQS + Lambda 조합
└── 단순 Pub/Sub 패턴
→ SNS 사용
Amazon MQ 엔진 비교
ActiveMQ vs RabbitMQ
┌─────────────────────────────────────────────────────────────┐
│ Amazon MQ 엔진 비교 │
├──────────────────────────┬──────────────────────────────────┤
│ ActiveMQ │ RabbitMQ │
├──────────────────────────┼──────────────────────────────────┤
│ │ │
│ 프로토콜: │ 프로토콜: │
│ • JMS (Java 표준) │ • AMQP 0-9-1 │
│ • AMQP 1.0 │ • MQTT │
│ • MQTT │ • STOMP │
│ • STOMP │ │
│ • OpenWire │ │
│ │ │
│ 특징: │ 특징: │
│ • Java 생태계 친화적 │ • 다양한 언어 지원 │
│ • 엔터프라이즈 기능 │ • 유연한 라우팅 │
│ • 복잡한 라우팅 지원 │ • 클러스터 확장 용이 │
│ │ │
│ 배포 옵션: │ 배포 옵션: │
│ • Single-instance │ • Single-instance │
│ • Active/Standby │ • Cluster (3노드) │
│ • Network of brokers │ │
│ │ │
└──────────────────────────┴──────────────────────────────────┘
언제 어떤 엔진을 선택?
| 상황 | 권장 엔진 |
|---|---|
| Java/JMS 기반 레거시 앱 | ActiveMQ |
| 다양한 언어 클라이언트 | RabbitMQ |
| 복잡한 메시지 라우팅 | ActiveMQ |
| 클러스터 고가용성 필요 | RabbitMQ |
| AMQP 0-9-1 프로토콜 필요 | RabbitMQ |
Amazon MQ vs SQS/SNS
비교표
| 비교 항목 | Amazon MQ | SQS | SNS |
|---|---|---|---|
| 유형 | 관리형 브로커 | 메시지 큐 | Pub/Sub |
| 프로토콜 | JMS, AMQP, MQTT | AWS API | AWS API |
| 확장성 | 브로커 크기 제한 | 사실상 무제한 | 사실상 무제한 |
| 관리 | 브로커 인스턴스 관리 | 완전 서버리스 | 완전 서버리스 |
| 비용 | 인스턴스 + 스토리지 | 요청당 과금 | 발행당 과금 |
| 마이그레이션 | 코드 변경 최소 | 코드 재작성 필요 | 코드 재작성 필요 |
선택 플로우
메시징 서비스 선택:
│
▼
기존 온프레미스 메시지 브로커를 마이그레이션하는가?
│
Yes → 어떤 프로토콜을 사용 중인가?
│ │
│ JMS, AMQP, MQTT → [Amazon MQ]
│ │
│ AWS API 가능 → [SQS/SNS로 재설계 고려]
│
No
│
▼
새로운 클라우드 네이티브 애플리케이션인가?
│
Yes → 메시지 패턴은?
│ │
│ Point-to-Point (1:1) → [SQS]
│ │
│ Pub/Sub (1:N) → [SNS]
│ │
│ 이벤트 라우팅 → [EventBridge]
│
No → [상황에 따라 선택]
시험 팁
시험 핵심 문장: "기존 애플리케이션을 코드 변경 없이 마이그레이션" → Amazon MQ가 정답!
Amazon MQ 아키텍처
고가용성 배포
┌─────────────────────────────────────────────────────────────┐
│ Amazon MQ Active/Standby (ActiveMQ) │
├─────────────────────────────────────────────────────────────┤
│ │
│ [클라이언트 애플리케이션] │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Wire-level 엔드포인트 │ │
│ │ (페일오버 URL) │ │
│ └─────────────────────┘ │
│ │ │
│ ┌──────┴──────┐ │
│ ▼ ▼ │
│ ┌────────┐ ┌────────┐ │
│ │ Active │ │Standby │ │
│ │ Broker │ │ Broker │ │
│ │ (AZ-a) │ │ (AZ-b) │ │
│ └────────┘ └────────┘ │
│ │ │ │
│ └──────┬──────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Amazon EFS │ ← 메시지 저장소 공유 │
│ │ (공유 스토리지) │ │
│ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
RabbitMQ 클러스터
┌─────────────────────────────────────────────────────────────┐
│ Amazon MQ RabbitMQ Cluster │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Node 1 │──│ Node 2 │──│ Node 3 │ │
│ │ (AZ-a) │ │ (AZ-b) │ │ (AZ-c) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ └─────────────┼─────────────┘ │
│ │ │
│ ┌───────┴───────┐ │
│ │ 클러스터 │ │
│ │ 자동 복제 │ │
│ └───────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
비용 구조
가격 구성 (US East 기준)
| 항목 | ActiveMQ | RabbitMQ |
|---|---|---|
| mq.t3.micro | $0.027/시간 | $0.027/시간 |
| mq.m5.large | $0.182/시간 | $0.182/시간 |
| 스토리지 | $0.10/GB/월 | $0.10/GB/월 |
| 데이터 전송 | 표준 EC2 요금 | 표준 EC2 요금 |
비용 최적화 팁
비용 절감 전략:
├── 개발/테스트 환경
│ └── Single-instance, 작은 인스턴스 사용
├── 프로덕션 환경
│ └── 필요한 용량만 프로비저닝 (오버프로비저닝 주의)
├── 새 프로젝트
│ └── SQS/SNS로 시작 (인스턴스 비용 없음)
└── 마이그레이션 후
└── 점진적으로 SQS/SNS로 전환 검토
SAA-C03 시험 출제 포인트
자주 나오는 시나리오
- ✅ 마이그레이션: "온프레미스 ActiveMQ → AWS" → Amazon MQ
- ✅ 프로토콜 요구사항: "JMS, AMQP 필요" → Amazon MQ
- ✅ 신규 앱 vs 레거시 앱: 신규 → SQS/SNS, 레거시 → Amazon MQ
- ✅ 확장성 요구사항: "무제한 확장" → SQS (Amazon MQ 아님)
- ✅ 코드 변경 최소화: "애플리케이션 수정 없이" → Amazon MQ
예상 문제
시험 팁
예상 문제 1: "온프레미스에서 Apache ActiveMQ를 사용하는 애플리케이션을 AWS로 마이그레이션해야 합니다. 애플리케이션 코드 변경을 최소화하려면?"
→ 정답: Amazon MQ (ActiveMQ 엔진) (기존 JMS 코드 유지 가능)
시험 팁
예상 문제 2: "새로운 서버리스 애플리케이션에서 메시지 큐잉이 필요합니다. 어떤 서비스를 사용해야 할까요?"
→ 정답: Amazon SQS (서버리스, 무제한 확장, Lambda 통합)
시험 팁
예상 문제 3: "MQTT 프로토콜을 사용하는 IoT 디바이스의 메시지를 처리해야 합니다. 기존 MQTT 클라이언트 코드를 변경하지 않으려면?"
→ 정답: Amazon MQ (RabbitMQ 엔진) 또는 AWS IoT Core (MQTT 네이티브 지원)
자주 묻는 질문 (FAQ)
Q: Amazon MQ와 AWS IoT Core의 차이점은?
Amazon MQ는 범용 메시지 브로커이고, AWS IoT Core는 IoT 디바이스 전용입니다. IoT 디바이스 관리, 디바이스 섀도우, 규칙 엔진이 필요하면 IoT Core를 사용하세요.
Q: Amazon MQ에서 SQS로 마이그레이션할 수 있나요?
네, 가능하지만 코드 변경이 필요합니다. JMS API를 AWS SDK로, AMQP를 HTTP API로 변경해야 합니다. 점진적 마이그레이션을 위해 두 시스템을 병렬로 운영할 수 있습니다.
Q: Amazon MQ의 메시지 보관 기간은?
ActiveMQ와 RabbitMQ 모두 영구 보관이 가능합니다. 브로커 스토리지에 메시지가 저장되며, 소비될 때까지 보관됩니다. SQS의 최대 14일과 다릅니다.
Q: 브로커 크기를 변경할 수 있나요?
예, 하지만 다운타임이 발생합니다. Active/Standby 배포에서는 페일오버를 통해 최소화할 수 있습니다. 사전에 적절한 크기로 프로비저닝하는 것이 중요합니다.
Q: Amazon MQ는 VPC 내에서만 접근 가능한가요?
기본적으로 퍼블릭 액세스와 프라이빗 액세스 모두 지원합니다. 보안을 위해 VPC 내 프라이빗 서브넷에 배포하고 VPN/Direct Connect로 접근하는 것을 권장합니다.