Queue vs. Topic
Queue 와 Topic 은 메시지 기반 시스템에서 데이터 전달 구조의 핵심 요소로, 시스템 아키텍처와 소비자 처리 방식에 따라 선택된다. Queue 는 Point-to-Point 방식으로 하나의 소비자에게 메시지를 전달하며 작업 분산에 유리하다. 반면 Topic 은 Publish-Subscribe 모델로, 다수의 구독자가 동일한 메시지를 수신할 수 있어 이벤트 브로드캐스팅이나 실시간 알림에 적합하다. 각 방식은 메시지 순서, 중복 수신, 확장성 등 다양한 구현 요소에서 차이를 가지며, 적절한 선택이 시스템 안정성과 확장성에 큰 영향을 미친다.
핵심 개념
기본 개념
Queue (큐)
- 정의: Point-to-Point 메시징 패턴으로, 메시지가 단일 소비자에게 전달되는 통신 모델
- 특성: FIFO (First-In-First-Out) 순서 보장, 메시지 지속성, 부하 분산
- 동작 방식: 프로듀서가 큐에 메시지를 전송하면, 여러 컨슈머 중 하나만이 해당 메시지를 소비
Topic (토픽)
- 정의: Publish-Subscribe 메시징 패턴으로, 메시지가 여러 구독자에게 브로드캐스트되는 통신 모델
- 특성: 일대다 통신, 메시지 복제, 실시간 이벤트 전파
- 동작 방식: 퍼블리셔가 토픽에 메시지를 게시하면, 해당 토픽을 구독하는 모든 컨슈머가 메시지 사본을 수신
실무 구현을 위한 연관성 분석
메시지 브로커 (Message Broker) 연관성
- Apache Kafka, RabbitMQ, ActiveMQ 등에서 Queue 와 Topic 패턴 모두 지원
- 브로커는 메시지 라우팅, 지속성, 보안 기능 제공
확장성 (Scalability) 측면
- Queue: 컨슈머 그룹을 통한 수평적 확장
- Topic: 파티셔닝과 구독자 확장을 통한 대규모 처리
내결함성 (Fault Tolerance) 구현
- 메시지 복제, 확인 응답 (Acknowledgment), 재시도 메커니즘
- Dead Letter Queue/Topic 을 통한 실패 메시지 처리
Queue vs. Topic 비교
Queue 와 Topic 은 메시징 시스템 내에서 메시지 전달, 소비 방식, 신뢰성, 스케일링 방식, 활용 목적 등 다양한 기준에서 차이가 난다.
기본 특성 비교
| 구분 | Queue | Topic |
|---|---|---|
| 통신 모델 | Point-to-Point | Publish-Subscribe |
| 메시지 소비 | 단일 컨슈머 | 다중 구독자 |
| 메시지 순서 | FIFO 보장 | 파티션 내에서만 보장 |
| 메시지 지속성 | 소비 후 삭제 | 보존 기간에 따라 유지 |
| 부하 분산 | Round-robin 방식 | 구독자별 독립적 처리 |
성능 특성 비교
| 구분 | Queue | Topic |
|---|---|---|
| 처리량 (Throughput) | 중간 - 높음 | 높음 |
| 지연 시간 (Latency) | 낮음 | 중간 |
| 메모리 사용량 | 낮음 | 높음 (구독자 수에 비례) |
| 네트워크 사용량 | 효율적 | 구독자 수에 따라 증가 |
| 확장성 | 제한적 | 높음 |
사용 사례 비교
| 구분 | Queue | Topic |
|---|---|---|
| 작업 분산 | 적합 | 부적합 |
| 이벤트 브로드캐스트 | 부적합 | 적합 |
| 데이터 스트리밍 | 제한적 | 적합 |
| 마이크로서비스 통신 | 적합 | 적합 |
| 실시간 알림 | 부적합 | 적합 |
작동 방식
Queue 작동 원리
sequenceDiagram
participant P as Producer
participant Q as Queue
participant C1 as Consumer 1
participant C2 as Consumer 2
P->>Q: Send Message 1
P->>Q: Send Message 2
P->>Q: Send Message 3
Q->>C1: Deliver Message 1
C1->>Q: Acknowledge
Q->>C2: Deliver Message 2
C2->>Q: Acknowledge
Q->>C1: Deliver Message 3
C1->>Q: Acknowledge
Topic 작동 원리
sequenceDiagram
participant P as Publisher
participant T as Topic
participant S1 as Subscriber 1
participant S2 as Subscriber 2
P->>T: Publish Message
T->>S1: Broadcast Copy 1
T->>S2: Broadcast Copy 2
S1->>T: Acknowledge
S2->>T: Acknowledge
도전 과제
| 카테고리 | 도전 과제 | 원인 또는 설명 | 실무적 영향 | 대응 전략 / 해결 방안 |
|---|---|---|---|---|
| 확장성/부하 분산 | 파티션 불균형, 소비자 병목 | 키 기반 파티셔닝 불균형, 핫 파티션, 소비자 수 제한 | 특정 파티션/큐에 부하 집중, 처리량 저하 | 키 해시 분산 설계, 파티션 재조정, 컨슈머 그룹 확장, 큐 샤딩 |
| 스케일링 안정성 | 컨슈머 리밸런싱 처리 지연 | 컨슈머 동적 증가/감소, 네트워크 장애 발생 시 리밸런싱 이벤트 트리거됨 | 일시적 처리 중단, 메시지 재전송 발생 | 점진적 스케일링, 상태 기반 할당, 협력적 리밸런싱 (Cooperative Rebalancing) |
| 성능/처리량 | 직렬화 오버헤드, 백프레셔 | 무거운 메시지 포맷 (JSON 등), 빠른 생산자 - 느린 소비자 속도 불일치 | CPU 부하, 처리량 저하, 큐 적체, 시스템 불안정 | Avro/Protobuf 적용, 배치 처리, prefetch/poll 설정 조정, 회로 차단기 패턴 (Circuit Breaker) |
| 일관성/정확성 | 메시지 순서 보장 어려움 | 병렬 소비, 토픽 파티션 분산 처리, 소비자 순서 무시 | 이벤트 순서 불일치로 인한 비즈니스 로직 오류 | 파티션 키 고정, 단일 소비자 처리, Kafka FIFO 처리, Vector Clock, 이벤트 소싱 적용 |
| 신뢰성 | 메시지 유실, 중복 처리 문제 | Ack 실패, 컨슈머 장애, 중복 전송으로 인해 발생 | 데이터 누락, 중복 처리, 결과 무결성 손상 | DLQ 구성, Ack + Retry 정책, 멱등성 (ID+Hash 기반) 소비자 구현 |
| 운영/관찰성 | 메시지 흐름 및 상태 추적 어려움 | 큐는 처리 후 삭제, 토픽은 병렬 소비자 존재 → 추적 어려움 | SLA 준수 실패, 디버깅 난이도 증가 | Trace ID 삽입, 중앙 로깅 + 분산 트레이싱 도입 (OpenTelemetry, Zipkin 등) |
| 통합/마이그레이션 | 큐 ↔ 토픽 전환 시 데이터 정합성 보장 문제 | 구조 전환 시 메시지 중복/유실 가능, 중단 없는 서비스 이전 어려움 | 전환 중단 시 서비스 중단 또는 누락 이벤트 발생 가능 | 중간 브로커 구성, 양방향 브릿지 메시징, 임시 병행 구독 전략 |
| 아키텍처 복잡도 | 혼합 패턴 구성 시 복잡성 증가 | Queue/Topic 혼합 사용 시 흐름 파악, 장애 추적, 권한 설정 등 어려움 | 운영 비용 증가, 장애 확산 시 전체 영향도 증가 | 도메인별 메시징 전략 수립, 토픽 명명 일관화, 문서화 및 메시지 흐름 시각화 |
| 보안/접근 제어 | 구독자/컨슈머 인증/인가 누락 | ACL 미적용, 인증 토큰 부재, 메시지 노출 우려 | 보안 취약점, 메시지 도난 가능성 | Role 기반 RBAC, TLS 암호화, JWT/OAuth 기반 메시지 인증 적용 |
- Queue 기반 시스템은 확장성과 병렬성 한계, 처리 병목이 주요 이슈이며, 소비자 확장 전략과 작업 큐 분산 설계가 핵심.
- Topic 기반 시스템은 병렬성은 뛰어나나 순서 보장, 메시지 정합성 유지, 모니터링에서 도전 과제가 두드러짐.
- 모든 아키텍처 공통 이슈는 신뢰성 확보 (DLQ, 멱등성), 관찰성 향상 (Trace, 상태 저장), 스케일 안정화 (리밸런싱, 파티션 튜닝) 에 집중해야 한다.
실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점
| 카테고리 | 고려 항목 | Queue(큐) 고려사항 | Topic(토픽) 고려사항 | 권장 사항 및 주의점 |
|---|---|---|---|---|
| 전달 패턴 | 메시징 모델 | 1:1 처리 (Point-to-Point) | 1:N 처리 (Publish-Subscribe) | 요구 사항에 따라 메시징 패턴을 일관되게 설계 |
| 순서 보장 | FIFO 처리 | 단일 소비자 구성 시 순서 보장. FIFO Queue 또는 순차 처리 설계 필요 | Partition 내 순서 보장만 가능, 전체 순서 보장은 어려움 | 순서 요구 시 단일 파티션/소비자 설정 또는 순서 제어 로직 구현 |
| 확장성 | 소비자 수 및 병렬 처리 | 소비자 수를 늘려 작업 병렬화 (Worker Pool) | Partition + Consumer Group 구조로 병렬 소비 | Partition 수 ≥ Consumer 수 권장. 파티션 증설 시 메시지 재분배 고려 필요 |
| 장애 복원력 | 장애 및 실패 대응 | DLQ 구성 필수. 메시지 누락 대비 Ack 기반 재처리 로직 필요 | Durable Subscription, Offset 기반 재처리 및 Replay 가능 | DLQ + 재처리 전략 함께 구성. Topic 은 재생 정책 (log compaction 등) 고려 |
| 중복 방지 | Idempotency 처리 | 동일 메시지 재수신 방지를 위한 멱등성 설계 필요 | 각 구독자 단위로 중복 수신 방지 처리 필요 | 메시지 해시, UUID, Redis Lock 등 멱등성 로직 적용 |
| 모니터링 | 시스템 상태 추적 | 큐 깊이, 메시지 지연, 소비 실패 추적 | 구독자별 처리율, Offset lag, 파티션 상태 추적 | Prometheus + Grafana, DLQ 로그 추적, APM 연계 |
| 성능 최적화 | 처리량/지연 튜닝 | Batch 전송, Prefetch 설정, 워커 수 조정 | Compression, BatchSize, Zero-Copy 전송 등 | Throughput ↔ Latency 트레이드오프 균형화 설계 |
| 운영 관리 | 메시지 보존 및 재처리 | 일반적으로 소비 후 메시지 삭제 | 메시지 로그 보존 설정으로 재처리 및 분석 가능 (Kafka log.retention 등) | 장기 보관 필요 시 Topic 선택 + TTL 설정 조합 |
| 보안 | 인증/암호화/권한 관리 | TLS, 사용자 인증, 역할 기반 접근 제어 (RBAC) | TLS, 구독 필터링, ACL 및 Consumer 인증 | 민감도에 따라 차등 보안 설정, 브로커 레벨 + 애플리케이션 레벨 이중 보안 적용 |
| 운영 자동화 | 오토스케일링/백프레셔 | 메시지 증가 시 Worker 자동 확장 + 메시지 Pull 속도 조절 | 소비 속도에 따라 Backpressure 전략 도입 필요 | KEDA, Kubernetes HPA 연동, Kafka Lag 기반 스케일링 트리거 고려 |
| 설계 복잡도 | 혼합 설계 시 주의점 | Queue/Topic 혼용 시 데이터 흐름 혼란 및 유지보수 난이도 증가 가능 | 기능 분리 목적의 멀티 토픽 구성 시 구독자 설계가 복잡해질 수 있음 | 도메인 기준 메시징 구조 일관성 확보. 기능별 별도 토픽 설계로 복잡도 분리 |
| 스키마 설계 | 메시지 포맷/진화 | JSON/Protobuf/Avro 등 표준 포맷 유지 필요 | 스키마 진화 발생 시 하위 호환성 확보 필요 | Schema Registry 도입 권장, 버전 관리 포함 |
실무 설계 및 운영 팁 요약
| 항목 | 권장 전략 요약 |
|---|---|
| 순서 보장 | FIFO 가 중요한 경우 큐 사용. Topic 은 파티션 내부에서만 순서 보장 가능 |
| 확장성과 병렬 처리 | Topic + Partition + Consumer Group 조합이 가장 효율적인 병렬 처리 구조 |
| 신뢰성과 재처리 | DLQ, Retry Queue, Ack/Nack 조합을 통한 메시지 유실 방지 전략 필수 |
| 모니터링 및 자동화 | Kafka Lag, Queue Length, Failure Count 등 지표 기반 오토스케일링 및 알림 시스템 구축 권장 |
| 보안 | TLS, 인증 키, 토픽 구독 필터링, RBAC 조합으로 전방위 보안 체계 구축 가능 |
| 복합 구조 설계 시 | CQRS, Saga 등 복합 아키텍처에서 Queue 와 Topic 을 혼합 사용 시 도메인 기반 구분 및 명확한 흐름 설계 필수 |
최적화하기 위한 고려사항 및 주의할 점
| 카테고리 | 최적화 항목 | Queue(큐) 최적화 전략 | Topic(토픽) 최적화 전략 | 실무 권장사항 요약 |
|---|---|---|---|---|
| 메시지 크기/포맷 | 메시지 크기 및 직렬화 최적화 | 메시지 크기 10MB 이하 유지, JSON 대신 Avro/Protobuf 활용 | 이벤트 페이로드 최소화, 경량 직렬화 포맷 사용 | JSON → Avro 전환, Schema Registry 로 일관성 유지 |
| 처리량/지연 시간 | 병렬 처리 및 Throughput | Prefetch 조정, Consumer 수 증가, 멀티 워커 구성 | 파티션 수 증가, 컨슈머 그룹 병렬 처리 | 처리량 기준 → Partition/Consumer 수 동적 조정 |
| 백프레셔 | 소비자 부하 제어 | 메시지 rate limit 설정, reject + requeue 전략 | 구독자 수 조절, 이벤트 필터링/샤딩 적용 | 처리 병목 시 prefetch 또는 poll 조정, CPU 모니터링 필수 |
| 리소스 최적화 | 시스템 자원 할당 및 스케일링 | CPU/메모리/디스크 모니터링, 워커 오토스케일링 구성 | 브로커/컨슈머 오토스케일링, 클러스터 모니터링 | Kubernetes + HPA/KEDA 조합 권장 |
| 스토리지 최적화 | 메시지 저장소 관리 | TTL 설정, 수동/자동 배치 삭제, 디스크 압축 설정 | Retention 정책 설정, 파티션 간 균등 분산 | Kafka 는 retention.ms, RabbitMQ 는 max-length 등 관리 필요 |
| 신뢰성/오류 처리 | 장애 대응 전략 | DLQ 구성, 재시도 + 지수 백오프, manual ack 설정 | Durable Subscription, 재전송 정책, Offset commit 전략 | DLQ 는 필수 구성 요소, 오류 로깅 및 Alerting 도입 권장 |
| 확장성 설계 | 수평 확장 구조 | 큐 단위 분리, 컨슈머 워커 클러스터 구성 | 파티션 기반 구독자 병렬화, 구독자 샤딩 및 부하 분산 | 사용자 그룹별 큐 or 파티션 구성, 클러스터 수준 확장 고려 |
| 지연 최소화 | 네트워크/연결 관리 | 연결 풀링, 메시지 배치 처리, 전용 회선 구성 | 로컬 배치 처리, 고속 네트워크 구성, 메시지 필터링 적용 | 네트워크 지연 발생 시 RPC → 비동기 메시징 전환 고려 |
| 중복/멱등성 보장 | Idempotency | 메시지 해시, Unique ID, 중복 방지 DB Key 적용 | 이벤트 ID 기반 멱등성 로직, 구독자별 deduplication 처리 | 재처리에도 안전한 메시지 구조 설계 (e.g., DB Upsert 패턴) |
| 운영 편의성 | 모니터링 및 Alerting | 큐 길이, 처리 시간, 실패률 모니터링 + Alert 구성 | 토픽 오프셋 지연, 구독자 상태 모니터링 | Prometheus + Grafana, Kafka UI, RabbitMQ Management Plugin 활용 |
- Queue 는 작업 단위 (Task) 중심 처리에 최적화되어 있고, Topic 은 이벤트 브로드캐스트 처리에 강점을 가진다.
- **공통적으로 병목 구간 식별, 리소스 모니터링, 자동화된 장애 처리 (DLQ + Alert)**가 중요하다.
- Kafka, RabbitMQ, SQS/SNS 등 각 브로커에 따라 일부 설정 방식이 다르므로 시스템에 맞는 최적화 전략 수립 필요.
- 직렬화 포맷과 메시지 크기 최적화는 네트워크/스토리지 부하를 줄이는 데 핵심이다.
실무 적용 예시
| 도메인/시스템 | 사용 목적 | 메시징 방식 | 적용 방식 예시 | 기대 효과 및 특징 |
|---|---|---|---|---|
| 주문 처리 시스템 | 비동기 작업 처리 | Queue | 주문 요청 → 큐 (RabbitMQ/SQS) → 백엔드 워커 | 중복 방지, 신뢰성 확보, 부하 분산 |
| 알림 시스템 | 실시간 이벤트 브로드캐스트 | Topic | 이벤트 발생 → 토픽 (Kafka/PubSub) → 모바일/Web/Slack 등 다중 구독자 | 동시 사용자 대상 브로드캐스트, 반응 속도 향상 |
| 로그 수집 및 분석 | 로그 집계 및 전처리 | Queue | 서버 로그 → 큐 → 로그 파서/적재기 → DB/S3 등 | 안정적인 수집, 실패 메시지 재처리, 단일 소비 구조 |
| 다중 로그 시스템 연동 | Topic | 앱 로그 → 토픽 → Kibana + S3 + Data Lake 등 | 다수 분석 시스템에 병렬 전송, 유연한 로그 분기 처리 | |
| IoT/센서 데이터 | 대규모 이벤트 스트림 처리 | Topic | 센서 이벤트 → 토픽 → 실시간 분석기 + 알림 시스템 | 실시간 통계, 이벤트 기반 경고 시스템 구축 가능 |
| ETL 파이프라인 | 배치/순차 처리 | Queue | Data Ingest → 큐 → 변환 작업 순차 수행 | 처리 순서 보장, 실패 처리 용이 |
| 실시간 스트리밍 처리 | Topic | 실시간 데이터 수집 → 토픽 → 분석기, 대시보드, 저장 시스템 병렬 전달 | 고속 처리, 병렬 확장, 비동기 이벤트 기반 처리 | |
| 마이크로서비스 통신 | 명령/작업 분산 전달 | Queue | A 서비스 → 큐 → B 서비스 워커로 명령 전달 | 명령 처리의 확장성, 느슨한 결합, 트랜잭션 가능 |
| 이벤트 기반 상호 작용 | Topic | 도메인 이벤트 → 토픽 발행 → 여러 서비스 구독 (이메일, 포인트, 감사 로그 등) | CQRS/Event Sourcing 구현, 기능 확장 용이 | |
| 데이터 적재/복제 | 멀티 싱크 처리 | Topic | 원본 시스템 → 토픽 → 여러 데이터 저장소로 동시에 전송 | 일관된 데이터 적재, 리플레이/재처리 가능 |
| 지속 가능성/모니터링 | 장애 대비, 재처리 | DLQ (보조 구성) | 처리 실패 메시지 → DLQ → 재시도 큐 또는 관리자 알림 처리 | 신뢰성 향상, 재처리 전략 수립 용이 |
활용 사례
사례 1: 실시간 알림 시스템 - Topic 패턴
시스템 구성
flowchart TD
Backend[Backend Service] --> Broker[메시징 브로커]
Broker --> Topic[알림 토픽]
Topic --> User1[User App 1]
Topic --> User2[User App 2]
Topic --> User3[User App 3]
Broker -.-> DLQ
Workflow
- Backend 에서 알림 이벤트 생성 후 토픽으로 발행
- 토픽 구독 중인 모든 User App 에게 동시에 메시지 전송
- 개별 앱이 각자 알림 확인, 실패 시 DLQ 보관
주제의 역할: 동일 이벤트의 멀티 소비, 브로드캐스트, 확장성과 실시간성
유무 차이: Topic 없으면 각 대상마다 별도 메시지 송신 필요 → 시스템 과부하, 누락/지연 위험
구현 예시
| |
사례 2: 전자상거래 주문 처리 시스템
시스템 구성:
Queue 기반 주문 처리
graph LR
UI[웹 인터페이스] --> OQ[주문 큐]
OQ --> OP1[주문 처리 워커 1]
OQ --> OP2[주문 처리 워커 2]
OQ --> OP3[주문 처리 워커 3]
OP1 --> DB[(주문 DB)]
OP2 --> DB
OP3 --> DB
Topic 기반 이벤트 처리
graph TB
OP[주문 처리 완료] --> ET[이벤트 토픽]
ET --> IS[재고 서비스]
ET --> NS[알림 서비스]
ET --> AS[분석 서비스]
ET --> BS[빌링 서비스]
Workflow:
- Queue 워크플로우
- 사용자 주문 접수 → 주문 큐에 메시지 추가
- 주문 처리 워커들이 경쟁적으로 주문 획득
- 주문 검증 및 처리 → 데이터베이스 업데이트
- 처리 완료 확인 응답
- Topic 워크플로우
- 주문 처리 완료 → 이벤트 토픽에 발행
- 재고 서비스: 재고 차감
- 알림 서비스: 고객 알림 발송
- 분석 서비스: 판매 데이터 수집
- 빌링 서비스: 정산 처리
Queue vs. Topic 유무에 따른 차이점
- Queue 미사용 시
- 동기식 처리로 응답 시간 증가
- 트래픽 급증 시 시스템 과부하
- 단일 장애점 위험 증가
- Topic 미사용 시
- 서비스 간 강한 결합
- 순차적 처리로 전체 지연 발생
- 새로운 서비스 추가 시 기존 코드 수정 필요
구현 예시:
| |
사례 3: 주문 처리 시스템
시스템 구성:
| 구성 요소 | 설명 |
|---|---|
| Queue | order_queue: 작업 (Task) 전용. FIFO 처리 보장. |
| Exchange | events: fanout 타입. 모든 구독자에게 메시지를 broadcast. |
| Producer | 주문 생성 시스템. Queue 에 작업 메시지 전송 또는 이벤트 발행. |
| Consumer | 주문 처리 시스템. Queue 에서 작업 수신 후 처리. |
| Subscriber | 이벤트 처리 시스템들. 이벤트를 받아 로그 기록, 알림 등 수행. |
| |
- Queue 방식 (Point-to-Point):
order_queue라는 이름의 큐에 메시지를 하나의 소비자가 처리.- FIFO 기반으로 작업 (Task) 처리가 적합.
- Topic 방식 (Fanout Exchange 사용):
events라는 fanout exchange 를 통해 여러 소비자에게 동시에 브로드캐스트.- 이벤트 알림/상태 변경 전파에 적합.
메시지 흐름 (Workflow):
- Queue 기반 (작업 처리용)
- Producer (
producer_queue.py):order_queue에"order_id": 12345, "status": "NEW"메시지 전송.
- Consumer (
consumer_queue.py):- 큐에 메시지가 도착하면 한 명의 소비자가 처리.
- 메시지는 큐에서 제거됨.
- Producer (
- Topic 기반 (이벤트 브로드캐스트용)
- Producer (
producer_topic.py):eventsexchange 에"event": "ORDER_CREATED"메시지 전송.fanout타입으로, 라우팅 키 없이 모든 바인딩된 큐에 전송.
- Subscriber (
subscriber_topic.py):- 빈 queue 선언 후
eventsexchange 에 바인딩. - 동일한 이벤트를 여러 구독자들이 동시에 수신 가능.
- 빈 queue 선언 후
- Producer (
구현 예시:
Queue 예시 (Point-to-Point)
1 2 3 4 5 6 7 8 9 10 11 12 13 14# producer_queue.py import pika connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() channel.queue_declare(queue='order_queue') # 주문 메시지 발행 channel.basic_publish(exchange='', routing_key='order_queue', body='{"order_id": 12345, "status": "NEW"}') print("Order sent to Queue") connection.close()1 2 3 4 5 6 7 8 9 10 11 12 13# consumer_queue.py import pika def callback(ch, method, properties, body): print(f"[x] Received Order: {body}") connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() channel.queue_declare(queue='order_queue') channel.basic_consume(queue='order_queue', on_message_callback=callback, auto_ack=True) print("Waiting for orders…") channel.start_consuming()Topic 예시 (Publish-Subscribe)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15# producer_topic.py import pika connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() # Topic exchange 선언 channel.exchange_declare(exchange='events', exchange_type='fanout') # 이벤트 브로드캐스트 channel.basic_publish(exchange='events', routing_key='', body='{"event": "ORDER_CREATED"}') print("Event broadcasted") connection.close()1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20# subscriber_topic.py import pika def callback(ch, method, properties, body): print(f"[x] Received Event: {body}") connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() # 이벤트 exchange 선언 channel.exchange_declare(exchange='events', exchange_type='fanout') result = channel.queue_declare(queue='', exclusive=True) queue_name = result.method.queue # 이벤트 구독 channel.queue_bind(exchange='events', queue=queue_name) channel.basic_consume(queue=queue_name, on_message_callback=callback, auto_ack=True) print("Waiting for events…") channel.start_consuming()
사례 4: 사용자 알림 시스템 (Kafka Topic 기반)
앱에서 사용자 이벤트가 발생했을 때, 여러 컴포넌트가 이를 실시간으로 반응해야 하는 구조 구성
시스템 구성:
- Producer: 사용자 앱에서 행동 발생 시 이벤트 발행
- Topic: Kafka Topic–
user-events - Consumers:
- Notification Service (푸시알림)
- Logging Service (감사 기록)
- Analytics Engine (실시간 통계)
flowchart TD App[Mobile App] --> KafkaTopic["Kafka Topic: user-events"] KafkaTopic --> NotiService[Notification Service] KafkaTopic --> LogService[Logging Service] KafkaTopic --> AnalyticsEngine[Analytics Engine]
Workflow:
- 사용자가 앱에서 특정 행동을 수행함
- 이벤트가 Kafka Topic 에 발행됨
- 각각의 서비스가 독립적으로 해당 이벤트를 수신하고 자체 처리 수행
Kafka Topic 유무에 따른 차이:
| 구분 | 존재할 경우 | 존재하지 않을 경우 |
|---|---|---|
| 메시지 처리 구조 | 느슨한 결합, 병렬 분기 | 강결합, 동기 호출 중심 |
| 확장성 | 독립적 확장 용이 | 하나의 호출 체인에 의존 |
| 유지보수 | 각 서비스 단위 테스트 용이 | 전체 시스템 수정 필요 |
주목할 내용
| 카테고리 | 항목 | 설명 | 관련 기술 / 시스템 |
|---|---|---|---|
| 전달 방식 | Push vs Pull | Queue 는 Pull 기반 소비, Topic 은 Push 또는 Hybrid 방식 가능. | Kafka (Pull), SNS (Push), MQTT |
| 확장성 설계 | Partitioning | 메시지를 물리적으로 분할하여 트래픽을 분산하고 병렬 처리를 통해 성능을 향상시킴. | Kafka Partition, SQS Shard |
| Consumer Scaling | Consumer Group 을 통한 병렬 소비 확장. Partition 수와 균형 있게 설계되어야 함. | Kafka Consumer Group, Celery Workers | |
| 신뢰성/무결성 | Acknowledgment (Ack) | 메시지 수신 확인을 통해 손실 방지 및 재전송 제어. | Kafka Offset Commit, RabbitMQ Ack |
| Dead Letter Queue | 처리 실패 메시지를 보관하여 재처리 가능하도록 함. 장애 분석 및 경고 트리거로도 활용 가능. | Kafka DLQ, RabbitMQ DLX | |
| Idempotency | 중복된 메시지라도 같은 결과를 보장하는 소비자 처리 로직 설계. 중복 이벤트 발생 시 데이터 무결성 유지. | Webhook, Event Consumer | |
| 처리 전략 | Offset & Replay | 메시지의 소비 위치를 관리하여 리플레이, 복기, 재처리 등 고급 처리 전략을 구현 가능. | Kafka Offset, Pulsar Cursor |
| TTL (Time-To-Live) | 메시지의 생명 주기를 제한하여 오랫동안 소비되지 않는 메시지를 자동으로 정리. | SQS Message TTL, Kafka Retention | |
| 라우팅/필터링 | Message Routing | Topic/Exchange 기반의 메시지 라우팅 설계. Routing Key 와 Binding Rule 로 목적지 결정. | RabbitMQ Exchange, SNS Topic Filter |
| Attribute Filtering | 메시지 속성 기반으로 구독자가 원하는 조건만 필터링 수신. | SNS Filter Policy, JMS Selectors | |
| 패턴/조합 | CQRS + Pub/Sub | CQRS(Command/Query 분리) 구조와 Topic 기반 메시징 결합으로 읽기/쓰기 모델 최적화. | Event Sourcing with Kafka |
| 성능 최적화 | Batch & Compression | 메시지 묶음 전송과 압축 적용으로 Throughput 향상 및 전송 비용 절감. | Kafka Batch Size, GZIP Compression |
| 전송 품질 보장 | QoS Level | 메시지 전송 품질 설정: At Most Once / At Least Once / Exactly Once | MQTT QoS, Kafka Delivery Semantics |
| 장애 회복 | Backpressure Handling | 소비자가 처리 속도를 초과할 경우, 흐름 제어 및 재시도/대기 메커니즘으로 안정화 필요. | Reactive Streams, Kafka Lag Monitor |
- Queue 중심 시스템은 작업 처리 (Task Queue) 용도에 최적이며, Pull 기반, 1:1 처리, Ack/DLQ 중심의 신뢰성 보장 구조.
- Topic 중심 시스템은 이벤트 브로드캐스트 및 다수 소비자 처리에 유리하며, Push 기반 + 필터링 + 확장성 중심 설계가 필요.
- Kafka 와 RabbitMQ 는 각각의 특징을 극대화하며, 다양한 **복합 아키텍처 (CQRS, Event Sourcing, Retry Workflow)**에서 병행 사용됨.
- 실제 아키텍처 설계 시 성능, 확장성, 무결성, 복원력, 필터링, 그리고 QoS 정책까지 종합적으로 고려해야 함.
반드시 학습해야할 내용
| 카테고리 | 주제 | 핵심 개념 / 항목 | 설명 및 실무 적용 포인트 |
|---|---|---|---|
| 메시징 모델 | Queue vs. Topic | P2P (1:1), Pub/Sub (1:N) | Queue 는 단일 소비자 처리에 적합, Topic 은 다수 구독자에게 브로드캐스트 용도 |
| 메시징 프로토콜 | AMQP, MQTT | AMQP = 복잡한 라우팅, MQTT = 경량 통신 | RabbitMQ → AMQP 기반 / IoT 및 저전력 → MQTT 사용 (예: 센서 데이터) |
| 메시지 보장 | QoS (At-Least-Once 등) | At-Most-Once / At-Least-Once / Exactly-Once | 메시지 유실/중복 방지 및 시스템 신뢰성 확보. Kafka 는 At-least-once 기본, Exactly-once 지원 필요 시 구성 필요 |
| 신뢰성/순서 | Ack, Offset, Delivery Semantics | Auto/Manual Ack, Kafka Offset | 메시지 누락 방지, 재처리 가능성 확보. Ack 와 Offset 을 통해 중복 처리 방지 및 순서 보장 |
| 확장성 설계 | Partitioning | Kafka, RabbitMQ 의 파티션 설계 | 병렬 소비 및 부하 분산을 위한 핵심 요소. 파티션 수 결정 → Throughput 결정됨 |
| 에러 처리 | DLQ (Dead Letter Queue) | 처리 실패 메시지 격리 | 재처리, 로깅, 경고를 위한 DLQ 구성 필수. Kafka, RabbitMQ, AWS SQS 모두 DLQ 전략 존재 |
| 백프레셔 | Backpressure | Kafka max.poll.records, RabbitMQ prefetch | 소비자 처리 속도 제어 및 생산자 과부하 방지. 처리 병목 구간 진단 및 트래픽 제어 |
| 데이터 포맷 | Avro, Protobuf, JSON | 직렬화 포맷 선택 | Avro/Protobuf → 이진 포맷, 속도/용량 우수. JSON → 디버깅 용이하나 느리고 크다 |
| 멱등성 | Idempotency | 메시지 재처리 안전성 | 같은 메시지 중복 수신 시 결과 일관성 보장. Redis, DB transaction key 활용 등으로 보장 가능 |
| 아키텍처 설계 | Event-Driven Architecture | Loose Coupling, Scalability, Observability | 서비스 간 직접 연결 지양. Kafka/NATS 등으로 비동기 이벤트 중심 아키텍처 설계 시 고려해야 할 요소 |
| 클라우드 서비스 | AWS SQS/SNS, Azure, GCP PubSub | Serverless 메시징 서비스 비교 | SQS(Queue), SNS(Topic), EventBridge(EDA 연동) → 비용, 확장성, TTL, DLQ, 멱등성 기능 비교 필요 |
| 실시간 처리 | Kafka Streams, Flink | 메시징 + 실시간 데이터 흐름 통합 | Kafka Streams → Kafka-native 스트림 처리. Flink → 고급 상태 관리, CEP 등 포함 실시간 분석 |
| DevOps 연계 | Kubernetes + Kafka / KEDA | 메시지 기반 오토스케일링 | 메시지 수 (큐 길이) 기반 Horizontal Pod Autoscaler 구현. KEDA + Kafka/RabbitMQ 연동 가능 |
| 보안 | 인증, 암호화, 접근제어 | 메시지 암호화, IAM 인증 | TLS 전송 암호화, JWT 또는 IAM 기반 접근 제어. Kafka 는 ACL 구성, SQS 는 IAM 정책 설정 필수 |
용어 정리
| 카테고리 | 용어 | 설명 | 관련 기술/모델 |
|---|---|---|---|
| 전달 방식 | Queue (큐) | Point-to-Point 기반 구조. 단일 소비자에게 메시지를 순서대로 (FIFO) 전달. | RabbitMQ, SQS, Celery |
| Topic (토픽) | Publish-Subscribe 기반 구조. 다수 소비자가 같은 메시지를 수신. | Kafka, Pub/Sub, SNS | |
| Exchange | 메시지를 큐 또는 토픽으로 라우팅하는 라우터 역할. RabbitMQ 의 핵심 컴포넌트. | RabbitMQ (Direct/Fanout/Topic/Header) | |
| Virtual Topic | 큐와 토픽을 조합한 패턴. Pub/Sub 구조 위에 큐 기반 소비자를 추가하여 병렬성 제공. | ActiveMQ | |
| 처리 전략 | FIFO | First-In-First-Out. 메시지를 받은 순서대로 소비자에게 전달. | 대부분의 큐 시스템에서 기본값 |
| Round-Robin | 여러 소비자에게 순환 방식으로 메시지를 분배. | RabbitMQ Consumer Load Balancing | |
| Fan-out | 메시지를 여러 수신자에게 복제하여 전달하는 방식. | SNS → SQS, Kafka | |
| Partition (파티션) | 하나의 토픽 또는 큐를 병렬 처리 가능한 단위로 나눈 구조. | Kafka Partition | |
| Consumer Group | 동일 토픽을 병렬로 처리하기 위한 소비자 집합 단위. 각 파티션은 하나의 그룹 내 소비자에게만 전달됨. | Kafka | |
| 신뢰성 보장 | Acknowledgment (Ack) | 메시지 수신/처리 완료를 브로커에 알림으로써 메시지 삭제 또는 재전송 제어. | Kafka, RabbitMQ |
| Idempotency | 동일 메시지에 대한 중복 처리 방지. 재처리 시 결과가 동일하도록 설계. | Kafka Consumer, Webhook 처리 등 | |
| Durable Subscription | 구독자가 오프라인이어도 메시지를 보존하여 수신 가능하도록 하는 옵션. | JMS, MQTT | |
| 에러 처리 | DLQ (Dead Letter Queue) | 처리 실패 메시지를 별도로 저장하여 재처리하거나 로그 확인을 가능하게 하는 큐. | RabbitMQ, Kafka, SQS |
| Backpressure | 소비자가 처리 가능한 속도보다 빠르게 데이터가 도착할 경우 이를 제어하는 메커니즘. | Reactive Streams, Kafka | |
| 성능 메트릭 | Throughput | 단위 시간당 처리 가능한 메시지 수. | Kafka: TPS, RabbitMQ: msg/sec |
| Latency | 메시지 생성부터 소비까지 걸리는 시간. | 전송 시간 + 처리 시간 포함 | |
| QoS | QoS Level | 메시지 전달 보장 수준: At-most-once / At-least-once / Exactly-once | MQTT, Kafka |
| 중개자 구성 | Broker (브로커) | 메시지를 생산자에서 소비자에게 중계하는 핵심 구성 요소. | Kafka, RabbitMQ, Pulsar |
| Offset | 소비자의 메시지 읽기 위치를 나타내는 지표. 재처리 또는 순서 보장에 활용. | Kafka, Pulsar |
참고 및 출처
- Queues vs Topics: Understanding the Differences in Messaging Frameworks | Medium
- JMS Topic vs Queues - Stack Overflow
- How does a Queue compare to a Topic - ActiveMQ
- Azure Service Bus messaging - queues, topics, and subscriptions | Microsoft Learn
- Apache Kafka Architecture: What You Need to Know | Upsolver
- Amazon SQS best practices - AWS
- Apache Kafka Patterns and Anti-Patterns - DZone
- Message Queues - System Design - GeeksforGeeks
- Pub-Sub vs. Message Queues | Baeldung
- DEV Community: Queues vs Topics
- Solace Docs: Topic Endpoints and Queues
- Hevo Data: Kafka Queue vs. Topic
- System Design School: Message Queue vs Pub-Sub
- InfoQ: Choosing the Right Message Broker
- Tibco Queue vs Topic 비교
- RabbitMQ AMQP Best Practice in Microservice Architecture
- Apache Kafka 공식 문서
- RabbitMQ 공식 문서: Exchanges and Queues
- AWS SNS vs SQS 공식 문서
- Google Pub/Sub 공식 문서
- Microsoft Azure: Message Queues vs Topics vs Subscriptions (ko)
- Martin Fowler: Event Sourcing