MQTT(Message Queuing Telemetry Transport) 는 대역폭이 좁거나 끊기기 쉬운 회선을 전제로 만든 경량 메시징 프로토콜이다. 이름에 큐가 들어 있지만 실제 구조는 발행·구독이다. 클라이언트가 브로커에 토픽으로 메시지를 발행하면, 그 토픽을 구독한 클라이언트들이 받는다. 발행자와 구독자는 서로를 모른다.
헤더가 아주 작고(최소 2바이트) 연결을 오래 유지하는 구조라, 배터리로 도는 센서나 이동 통신으로 붙는 장비에 적합하다. IoT 와 M2M 영역에서 사실상 표준이다. OASIS 표준이며 현행은 5.0, 여전히 널리 쓰이는 것은 3.1.1 이다.
| 기능 | 내용 |
|---|---|
| QoS 0 | 최대 한 번. 확인 없이 보낸다. 유실될 수 있다 |
| QoS 1 | 최소 한 번. 확인을 받을 때까지 재전송하므로 중복이 생길 수 있다 |
| QoS 2 | 정확히 한 번. 4단계 핸드셰이크를 쓴다. 가장 느리다 |
| Retained message | 토픽의 마지막 메시지를 브로커가 들고 있다가 새 구독자에게 바로 준다. 현재 상태를 알려 주는 용도 |
| Last Will and Testament | 클라이언트가 비정상 종료하면 브로커가 대신 지정된 메시지를 발행한다. 장비 이탈 감지에 쓴다 |
| Keep alive | 주기적으로 핑을 주고받아 연결 상태를 본다 |
| Clean session · Session expiry | 연결이 끊겼을 때 구독과 미전달 메시지를 유지할지 정한다 |
QoS 2 는 비싸다. 중복을 애플리케이션 쪽에서 걸러 낼 수 있으면 QoS 1 로 두는 편이 현실적이다.
HiveMQ 는 상용 MQTT 브로커다. MQTT 3.1.1 과 5.0 을 지원하고, 다음을 내세운다.
오픈 소스 대안으로는 Eclipse Mosquitto(가볍고 단일 노드 용도), EMQX, VerneMQ 가 있다. 선택 기준은 대체로 동시 연결 수와 클러스터 요구다. 장비가 수천 대 수준이고 단일 노드로 충분하면 Mosquitto 로 시작해도 무리가 없다. 수십만 이상 동시 연결과 무중단 운영이 요구되면 클러스터를 제대로 하는 제품을 본다.
HiveMQ 는 에디션에 따라 기능과 라이선스가 갈리므로 도입 전에 현행 정책을 확인한다 (확인 필요).
Apache Hive 와 HiveMQ 는 이름만 비슷할 뿐 관계가 없다. Hive 는 하둡 위의 데이터 웨어하우스이고, HiveMQ 는 MQTT 브로커다. 만든 곳도 다르고 쓰는 영역도 다르다.
둘 다 발행·구독이지만 겨냥하는 곳이 다르다.
| MQTT 브로커 | Kafka | |
|---|---|---|
| 겨냥하는 곳 | 수많은 장비와의 마지막 구간 연결 | 시스템 사이의 대용량 스트림 처리 |
| 연결 수 | 수십만 이상의 얇은 연결 | 상대적으로 적은 수의 두꺼운 연결 |
| 보존 | 기본적으로 전달하면 끝 (retained 는 마지막 하나) | 로그로 보존하고 되감아 읽는다 |
| 클라이언트 | 마이크로컨트롤러까지 내려간다 | JVM 등 비교적 큰 런타임 |
그래서 현장에서는 겹치지 않고 이어 붙인다. 장비는 MQTT 브로커에 붙이고, 브로커에서 Kafka 로 흘려 보내 뒤쪽의 처리·저장으로 연결하는 구성이 흔하다.