반응형
- 개요
2.1 Kafka와 MQTT의 핵심 차이
- MQTT는 경량 메시징 프로토콜로, IoT·엣지 디바이스(센서, 모바일)에서 저전력·저대역폭 환경에서도 안정적으로 작동하도록 설계되었습니다.
- Kafka는 분산 로그(이벤트 스트리밍) 플랫폼으로, 대규모 데이터 파이프라인·내구성·재생(replay)·스트림 처리에 최적화되어 있습니다.
- 설계 철학과 아키텍처
3.1 MQTT 아키텍처
3.1.1 브로커와 클라이언트 모델
MQTT는 클라이언트(디바이스) 와 브로커 간의 통신 구조를 기반으로 합니다.
- 토픽(예: home/livingroom/temp)을 통해 퍼블리시/구독(Pub/Sub) 구조를 구현합니다.
- 주요 기능: Retained 메시지, Last Will 메시지, Clean Session, Keepalive 등.
- 대표 브로커: Mosquitto, HiveMQ, EMQX 등.
3.2 Kafka 아키텍처
3.2.1 분산 로그 기반 구조
Kafka는 토픽을 파티션 단위로 나누어 저장하고, 각 파티션은 불변의 로그 형태로 기록됩니다.
- 프로듀서는 데이터를 쓰고, 컨슈머는 오프셋(offset)을 기준으로 데이터를 읽습니다.
- 파티션별 병렬 처리로 대규모 데이터 처리에 강합니다.
- 리플리케이션(replication) 기능으로 데이터 내구성을 보장합니다.
- 전달 보장(Delivery semantics)
4.1 MQTT의 QoS 수준
- QoS 0 (At most once) : 빠르지만 메시지 손실 가능성 있음.
- QoS 1 (At least once) : 재전송으로 인한 중복 가능성 있음.
- QoS 2 (Exactly once) : 네 단계 핸드셰이크로 정확히 한 번 전달 보장하지만 성능 부담이 큼.
참고: MQTT의 QoS는 클라이언트↔브로커 사이의 보장이며, 서버 간 전달까지 포함하려면 별도 설계가 필요합니다.
4.2 Kafka의 메시지 보장 방식
- 기본은 At least once이며, 프로듀서 재전송 및 컨슈머 커밋 정책에 따라 중복이 발생할 수 있습니다.
- **Exactly once semantics (EOS)**는 Kafka의 트랜잭션 및 Idempotent Producer 기능을 이용하면 구현 가능합니다.
- EOS는 Kafka Streams나 Connector에서도 적용할 수 있으며, 외부 시스템과의 연동 시 Outbox 패턴 사용이 일반적입니다.
- 메시지 보관(Retention)과 재생(Replay)
5.1 MQTT의 보관 특성
- MQTT는 Retained 메시지를 통해 최신 메시지만 유지할 수 있습니다.
- 일반적으로 장기 로그 저장, 대량 메시지 재생 기능은 제공하지 않으며, IoT 환경에서는 백엔드 DB나 Kafka로 데이터를 포워딩합니다.
5.2 Kafka의 보관 및 재생 기능
- Kafka는 디스크 기반 로그 저장소를 이용하며, 메시지를 일정 기간(리텐션) 동안 보존할 수 있습니다.
- 과거 데이터를 재생(replay) 하여 재처리할 수 있으며, 이는 이벤트 소싱(Event Sourcing) 구조에 유용합니다.
- 로그 컴팩션(Log Compaction) 기능으로 각 키의 최신 상태만 유지할 수도 있습니다.
- 성능과 확장성 비교
6.1 MQTT의 성능 특성
- 저전력, 저대역폭 환경에서도 효율적으로 동작.
- 최신 브로커(EMQX, HiveMQ)는 수백만~수천만 연결을 지원하며, 클러스터 모드 운영 가능.
- QoS2 사용 시 오버헤드가 있으므로 중요 제어 메시지에만 적용 권장.
6.2 Kafka의 성능 특성
- 파티션 기반 수평 확장으로 초당 수십만~수백만 건 처리 가능.
- Throughput 중심 설계이며, 대용량 스트림 데이터를 안정적으로 처리.
- 성능 결정 요인: 파티션 수, 브로커 수, 디스크 I/O, 네트워크 설정.
- 보안(인증·인가·암호화)
7.1 MQTT 보안 구성
- TLS 암호화, 사용자 인증, ACL(Access Control List) 기반 접근 제어 제공.
- MQTT 5.0에서는 토큰 기반 인증(OAuth 2.0, JWT 등)을 지원합니다.
7.2 Kafka 보안 구성
- TLS를 통한 암호화, SASL(SCRAM, GSSAPI 등) 기반 인증 지원.
- 주제(Topic) 단위 ACL로 세밀한 권한 제어 가능.
- 엔터프라이즈 환경에서 중앙 인증(예: Kerberos, LDAP)과 연계 가능.
- 운영 난이도 및 관리 비용
8.1 MQTT 브로커 운영
- 단일 브로커로 간단히 시작 가능하며, 클러스터링으로 확장 가능.
- 세션 관리 및 Keepalive 설정 주의 필요.
- 대규모 환경에서는 로드밸런서 + 세션 스티키 정책을 활용해야 함.
8.2 Kafka 클러스터 운영
- 운영 복잡도 높음: 브로커, 리플리카, 파티션, 오프셋 관리 필요.
- 모니터링 대상: ISR(In-Sync Replica), GC, 디스크, 리텐션 정책.
- Kafka Connect, Kafka Streams, ksqlDB 등 생태계를 통해 다양한 파이프라인 구성 가능.
- 실무 권장 사용 사례
9.1 MQTT 권장 시나리오
- 센서, 차량, 스마트홈, 산업 IoT 등 엣지 장비 통신.
- 모바일 푸시, 실시간 알림, 텔레메트리 데이터 전송.
- MQTT 브로커 → 데이터베이스/클라우드 분석 시스템 연동.
9.2 Kafka 권장 시나리오
- 웹 서비스 로그 수집, 이벤트 스트림 처리, 실시간 데이터 분석.
- 대규모 데이터 파이프라인(ETL), 추천 시스템, 로그 집계.
- 이벤트 소싱(Event Sourcing) 및 CQRS 패턴 적용.
9.3 하이브리드 아키텍처
- IoT 디바이스 → MQTT 브로커 → Kafka → 분석 시스템(예: Spark, Flink)
- MQTT는 엣지 통신 담당, Kafka는 데이터 저장 및 스트림 처리 담당.
- Kafka Connect의 MQTT Source Connector를 활용하면 자동 연동 가능.
- 설정 및 튜닝 팁
10.1 MQTT 설정 가이드
- 일반 텔레메트리: QoS1, 중요 제어 메시지: QoS2.
- cleanSession=false로 세션 유지, Retained 메시지로 초기 상태 제공.
- TLS 활성화 및 사용자별 ACL 정책 적용.
10.2 Kafka 설정 가이드
- acks=all, min.insync.replicas=2 이상으로 내구성 보장.
- Idempotent Producer 활성화 (enable.idempotence=true).
- 파티션 수 조정으로 처리량 및 병렬성 확보.
- log.retention.hours 설정으로 메시지 보관 기간 관리.
- 2025년 최신 트렌드
11.1 MQTT의 발전 방향
- MQTT 5.0 기반으로 Request/Response 패턴, Shared Subscription, User Properties 기능 확장.
- EMQX, HiveMQ는 브로커 내 데이터 스트리밍 엔진과 Kafka Connector를 강화하고 있습니다.
- 일부 공급사는 QUIC 프로토콜 실험 도입으로 저지연 통신 개선 시도.
11.2 Kafka의 발전 방향
- KRaft 모드로 ZooKeeper 제거, 운영 단순화.
- Exactly Once Processing (EOP) 향상, 트랜잭션 기능 안정화.
- Confluent, Redpanda 등에서 클라우드 네이티브 스트리밍 서비스 확대.
- 최종 결론 및 추천
12.1 간단 결론
- MQTT는 엣지·IoT 환경에서 최적의 경량 통신 솔루션.
- Kafka는 대규모 서버·클라우드 기반 데이터 스트림 처리에 탁월.
- 현실적인 접근: MQTT → Kafka 브리지 아키텍처로 두 기술의 장점을 결합.
12.2 요약 표
| 구분 | MQTT | Kafka |
| 목적 | IoT/엣지 메시징 | 대규모 스트림 처리 |
| 프로토콜 | TCP, WebSocket | 자체 바이너리 프로토콜 |
| 메시지 저장 | 제한적 (Retained) | 디스크 기반 리텐션 |
| 보장 수준 | QoS 0/1/2 | At least / Exactly once |
| 운영 난이도 | 낮음 | 중간~높음 |
| 확장성 | 클러스터로 확장 | 파티션 기반 확장 |
| 대표 용도 | IoT, 센서, 원격제어 | 로그, 분석, 파이프라인 |
반응형
댓글