[퍼온글] MQTT (Message Queue Telemetry Transport) 소개
기술 이야기 2016. 1. 30. 14:22 |(출처: http://arsviator.blogspot.kr/2015/03/mqttmessage-queue-telemetry-transport.html?view=classic)
Introduction
MQTT(Message Queue Telemetry Transport) 프로토콜은 기계간 통신(M2M)/IoT를 위한 프로토콜이다. HTTP의 request/response 방식 대신 브로커를 사용한 publish/subscribe 방식으로 메시지를 주고 받는다. 물론 MQTT 역시 HTTP와 마찬가지로 TCP/IP 프로토콜 위에서 동작한다. 이 프로토콜의 첫번째 버젼은 1999년 Andy Stanford-Clark와 Arlen Nipper에 의해 발표되었다. 2013년 IBM이 OASIS 표준화 기구에 MQTT v3.1을 제출하여 승인받았다. 또한 비 TCP/IP 네트웍 상에서 동작하는 MQTT의 변종도 존재한다. MQTT-SN은 ZigBee 기반 네트웍 상에서 사용된다.
MQTT는 최소한의 프로토콜 오버헤드만으로 동작할 수 있기 때문에 임베디드 시스템같이 한정된 자원을 가진 시스템이나 저대역폭(low bandwidth) 또는 불안정한 네트웍 환경에서도 사용할 수 있다. 또한 다양한 언어를 지원하는 라이브러리들이 공개되어 있다. mbed에서라면 mbed MQTT library, 아두이노에서는 arduino client for MQTT를 사용할 수 있다.
이 기술이 특히 흥미로운 것은 모든 데이터를 단일 transport 메커니즘으로 처리한다는 것이다. 즉 특정 서비스를 위해 각각 따로 방화벽을 설정할 필요 없이, 단일 TCP 포트만으로 모든 종류의 메시지를 전달하는데 충분하다.
MQTT에서 publish/subscribe를 위한 메시지 큐를 '네트웍의 트위터'라고 생각할 수도 있다. 클라이언트는 특정 토픽에 대한 메시지를 수신하기 위해 토픽을 구독(subscribe)하고, 다른 클라이언트는 그 토픽에 대한 메시지를 발행(publish)한다. 메시지들은 토픽으로 분류된다. 예를들어 nagios/mta, nagios/disk, test/kr/private 같은 식의 토픽을 가질 수 있다. 클라이언트는 임의 갯수의 토픽을 구독할 수 있고, 구독할 토픽에 와일드카드를 포함할 수도 있다. (예: nagios/#) MQTT에서 메시지는 최대 256MB 크기의 UTF-8 BLOB이다.
Publish/Subscribe 모델
MQTT는 일반적으로 웹에서 사용되는 client/server 모델 대신 publish/subscribe(발행/구독) 모델을 사용한다. Client/server 모델에서는 클라이언트가 그 상대방이 되는 서버와 직접 통신을 하게 된다. 하지만 publish/subscribe 모델은 특정 메시지를 보내는 클라이언트(즉 publisher)와 그 메시지를 받는 다른 클라이언트들(즉 subscriber)를 분리시켜 서로는 상대방의 존재 여부를 모른다. 그러므로 통신을 하기 위해서는 publisher와 subscriber 양측이 모두 다 알고 있는 broker라 불리는 3번째 컴포넌트가 필요하게 된다. (publisher건 subscriber건) 모든 클라이언트는 브로커와 통신을 하고, 브로커는 자신이 받은 메시지들을 필터링 해 적절하게 분배하게 된다.
위의 그림에서 온도센서가 publisher, 랩탑과 스마트폰이 subscriber, HiveMQ가 MQTT 브로커가 된다. Subscriber들이 구독하길 원하는 토픽(여기서는 'temperature')이 있으면 그 토픽에 대해 브로커에게 구독신청(subscribe)을 한다. 그 후 온도센서가 측정한 온도값을 'temperature'라는 토픽으로 브로커에게 발행(publish)하게 된다. MQTT 브로커는 'temperature' 토픽에 대한 메시지를 받으면 해당 토픽을 구독하고 있는 subscriber들(여기서는 랩탑과 스마트폰)에게 이 메시지를 전달해준다. 토픽을 구독하는 클라이언트는 여러대가 될 수도 있다. 이 경우 publisher는 자신이 발행한 토픽을 구독한 subscriber가 몇개인지 신경 쓸 필요가 없다. (해당 토픽을 구독한 subscriber가 하나도 없을수도 있다.) 메시지는 브로커를 통해 전달되기 때문에 publisher와 subscriber는 서로의 IP주소와 포트를 알고 있을 필요도 없고, 서로 동시에 실행되고 있을 필요도 없다.
QoS (Quality of Service)
모든 메시지는 QoS값을 가지고 publish 된다. MQTT에는 3가지 QoS 타입이 있다.
- QoS_0 - "At most once" TCP/IP 네트웍 상에서 최대의 노력을 기울여 메시지가 전달되도록 함. 하지만 메시지가 중복되거나 분실될 수도 있음. 센서값이 한번 분실되어도 금새 다음번 값을 publish하기 때문에 분실되는 것이 큰 문제가 되지 않는 경우에 사용
- QoS_1 - "At least once" 메시지가 전달되는걸 보장. 하지만 이로 인해 중복이 발생할 수도 있음
- QoS_2 - "Exactly once" 메시지가 한번만 전달되는걸 보장. 과금 정보처럼 메시지 분실이나 중복이 문제를 발생시킬 수 있는 경우에 사용
Scalability
그리고 publish/subscribe 모델은 기존의 client/server 모델에 비해 훨씬 더 큰 확장성을 가지고 있다. 브로커의 동작이 event-driven 방식이기 때문에 쉽게 병렬화가 가능하기 때문이다. 또한 메시지 캐슁과 지능적 라우팅이 확장성을 증가시키는데 결정적이다. 하지만 publish/subscribe를 동시에 수백~수천만개를 처리하도록 확장시키는건 역시 큰 문제이다. 하지만 이 경우도 클러스터 브로커 노드를 상요해 개별 서버의 로드를 로드밸런싱 하는 것으로 해결할 수 있다.
