MQTT(Message Queue for Telemetry Transport)

*MQTT(Message Queue for Telemetry Transport)

- M2M 또는 IoT 기기와 게이트웨이의 연동을 위해 정의된 프로토콜

- Facebook messenger가 MQTT를 사용했다고 알려져 있음

- 경량 프로토콜, 저전력 장비, network bandwidth가 작은 곳에서도 충분히 운용 가능

 

*Connection Oriented

- MQTT broker와 연결을 요청하는 client는 TCP/IP socket 연결을 한 후 명시적으로 종료하거나 network 사정에 의해 연결이 끊어질 때까지는 연결 상태를 유지

- Topic에 발행된 message와 연결 상태 확인을 위한 live(heart-beat)를 항상 유지된 연결을 통해 전달

- 연결 상태를 유지, 연결이 끊어진 경우 재접속 등의 지원을 위한 자체 기능 보유

 

*Topic, publication, subscription

- 개설된 Topic에 message를 발행하면 해당 Topic을 구독하는 client들에게 message를 전송

- one to multi, one to one message 전송을 모두 지원 가능

 

*QoS(Quality of Service)는 0, 1, 2 세 단계를 지원

- 0 : 최대 1회 전송, Topic을 통해 message를 전송할 뿐, 꼭 받으리라는 보장은 없음

- 1 : 최소 1회 전송, 구독하는 client가 message를 받았는지 불확실하면 정해진 횟수만큼 재전송

- 2 : 등록된 client는 요구된 message를 정확히 한 번 수신할 수 있도록 보장

 

*다양한 개발 언어, 다양한 클라이언트가 지원

- C, JAVA, Node.js, Python 등의 언어로 Broker/Client Library가 존재

- 유료는 QoS-2까지 지원, 보통은 QoS-1까지 지원

 

*각각의 Action에 따른 Notification

- Client의 연결, 연결 해제, 구독, 발행 등의 event 에 대해서 MQTT broker가 대응할 수 있도록 해 줌

 

*MQTT Broker 예시

- AWS ElasticBeanstalk + Node.js

- Module : mosca

- OST-API, MQTT Broker, ELB, MQTT Broker#1, MQTT Broker#2, 주문접수 모바일앱, 주문접수 PC 클라이언트

 

*효과

- API 서버 부하 감소 및 트래픽 감소 : 각 디바이스들이 일정 시간에 한 번씩 히트하던 API polling이 없어지면서 API 서버 상태는 훨씬 쾌적

- 중계 정확성 증가 : 발생한 이벤트에 대해서 주문번호를 MQTT로 전송하고, 이를 기반으로 API에서 data를 가져오게 함으로써 좀 더 정확한 전달을 기대

- 각 채널별 디바이스의 live 상태 정확성 증가 : 항상 연결된 디바이스에서 message 수신이나 연결상태에 대한 MQTT 이벤트를 통해 훨씬 실시간에 가까운 상태 확인이 가능

- 디바이스의 통신 오류 감소 : MQTT 연결 상태에만 집중하고, 다른 추가적 연결이 필요 없어져서 코드 단순해지고 내부 관리 개선됨