MQTT 소개

Contents

MQTT는 경량의 Publish/Subscribe(Pub/Sub) 메시징 프로토콜이다. M2M(machine-to-machine)와 IoT(Internet of things)에서의 사용하려고 만들었다. IoT를 위해서 낮은 전력, 낮은 대역폭 환경에서도 사용할 수 있도록 설계됐다.

IoT 관련 일들을 하고 있는데, 저전력/소규모 디바이스를 위한 통신 프로토콜들을 살피면서 자연스럽게 관심을 가지게 됐다.

MQTT는 저전력, 신뢰할 수 없는 네트워크, No TCP/IP 기반에서 운용할 수 있다는 장점이 있다. 소형기기의 제어와 센서정보 수집에 유리하다. 이런 특징들로 특히 IoT 영역에서 주목받고 있다.

가전기기, 빌딩, 도시, 산업, 개인 등 다양한 영역에서의 센서정보를 수집할 수 있다. 네트워크 영역으로 보자면 LAN(가정/소규모 오피스), PAN(개인 네트워크), BAN(빌딩 네트워크), MAN(도시영역 네트워크)등에서 사용할 수 있다.

개인적으로 건강과 질병관리 분야에 관심이 간다. 지금 당장 서비스를 개발하기에는 센서장비의 품질 개선이 필요한 것 같다. 지금의 헬스케어 센서들은 "건강한 사람을 위한 악세사리"정도 인것 같다. 이런 용도로 사용하기에는 센서 품질이 별로 중요하지 않겠지만 질병/건강관리를 위해서 본격적으로 사용하려면 품질개선이 필요 할 것 같다.

센서로 부터 받은 데이터를 토대로 기기들을 제어할 수 있다. 기기제어 역시 MQTT를 이용하면 된다. 이를 위해서는 각 기기에 MQTT broker를 설치하거나 혹은 중앙에 있는 MQTT broker에 bind할 수 있어야 한다.

모바일 애플리케이션을 위한 메시지 Push 서버로 사용 할 수 있다. MQTT의 특징을 살려서 낮은 전력에서 작동하는 Push 서비스를 만들 수 있다. 페이스북의 경우 MQTT를 이용해서 메시지를 push 하고 있다.

MQTT 프로토콜은 메시지를 발행(publishing) 하고, 관심 있는 주제를 구독(subscribe) 하는 것을 기본 원칙으로 한다.

Publisher과 Subscriber은 모두 Broker에 대한 클라이언트로 작동한다. Publisher는 토픽을 발행하기 위한 목적으로 Subscriber은 토픽을 구독하기 위한 목적으로 Broker 서버에 연결한다. 하나 이상의 Pub와 Sub가 브로커에 연결해서 토픽을 발행 하거나 구독할 수 있다. 또한 다수의 클라이언트가 하나의 주제를 구독할 수도 있다.

Pub와 Sub는 토픽을 기준으로 작동한다. 토픽은 슬래시(/)를 이용해서 계층적으로 구성할 수 있어서 대량의 센서 기기들을 효율적으로 관리 할 수 있다. 예를들어 컴퓨터의 다양한 상태를 측정하는 센서가 있다고 다음과 같이 구성할 수 있을 것이다.

MQTT는 메시지 버스 시스템이다. MQTT Broker가 메시지 버스를 만들고 여기에 메시지를 흘려보내면, 버스에 붙은 애플리케이션들이 메시지를 읽어가는 방식이다. 메시지 버스에는 다양한 주제의 메시지들이 흐를 수 있는데, 메시지를 구분하기 위해서 "Topic"을 이름으로 하는 메시지 채널을 만든다.

애플리케이션들은 Message Bus에 연결하고 관심있는 토픽(Topic)을 등록 해서 메시지를 구독(SUB)하거나 발행(PUB)한다.

MQTT는 3단계의 QoS(Quality of service)를 제공한다.

• 0 : 메시지는 한번만 전달하며, 전달여부를 확인하지 않는다. Fire and Forget 타입이다.
• 1 : 메시지는 반드시 한번 이상 전달된다. 하지만 메시지의 핸드셰이킹 과정을 엄밀하게 추적하지 않기 때문에, 중복전송될 수도 있다.
• 2 : 메시지는 한번만 전달된다. 메시지의 핸드셰이킹 과정을 추적한다. 높은 품질을 보장하지만 성능의 희생이 따른다.

서비스의 종류에 따라서 적당한 QoS 레벨을 선택해야 한다.

No TCP/IP와 TCP/IP가 섞여있는 로컬 네트워크에서는 QoS 1, 2를 선택하는게 좋을 것 같다. 네트워크 구간을 신뢰할 수 없으며, 메시지 전송이 실패 했을 때, 메시지 박스에 저장하는 일을 하는 소프트웨어 시스템을 구축하기가 쉽지 않기 때문이다.

원격 네트워크에서는 0번이 좋을 것 같다. QoS 1이 적당할 것 같지만, 1이나 2를 선택할 경우 메시지 관리가 힘들어진다. 예를들어 offline 모드에서의 메시징을 지원하기 위해서 메시지 박스 서비스를 제공한다고 가정해 보자. QoS 1로 설정을 하면, 다음 연결에 메시지를 보내기 위해서 자체 queue에 저장을 한다. 그러면 시스템 입장에서는 MQTT queue에 있는 메시지를 읽어야 하는데, 메시지 박스에서 읽어야 하는지를 판단해야 한다.

또한 클라이언트는 MQTT queue에 있는 메시지를 읽기 위해서 이전에 연결했던 MQTT에 연결을 해야 하는데, 이러한 요구사항은 클러스터 구성을 어렵게 한다. 설계 관점에서도 비슷한 일을 하는 두 개의 모듈을 두는 것은 좋지 않은 설계다. 그냥 QoS 레벨은 0으로 하고, 소프트웨어에서 QoS를 처리하는게 깔끔할 것 같다.

MQTT 서버라고 하지 않고 중개인(브로커)라고 하는 이유는 MQTT가 발행인과 구독자가 메시지를 주고 받을 수 있도록 다리를 놔주는 역할만을 하기 때문이다. 다른 기능들은 중계를 도와주는 부가 기능일 뿐이다. 다양한 종류의 브로커들이 있는데, 여기에서 확인하자.

내가 경험한 브로커들만 간단히 정리한다. 모스키토(Mosquitto)는 (2014년 6월 현재)MQTT 프로토콜 3.1을 구현한 BSD 라이센스 기반의 오픈소스 메시지 브로커다. 나는 모스키토를 이용해서 PUB,SUB,Broker 테스트를 진행하기로 했다.

• VirtualBox를 이용해서 PUB, SUB, Broker를 위한 3개의 게스트 운영체제를 실행했다. 호스트 이름은 각각 pub.local, sub.local, broker.local 이다.
• 게스트 운영체제 : 우분투 리눅스 14.04로 통일

설치가 끝나면 바로 bind 된다.

모스키토 클라이언트 프로그램을 설치했다.

hello/world 토픽을 subscribing 한다.

hello/world토픽에 Publishing을 했다. Sub 클라이언트는 "Hello World"를 전송 받는다.

modquitto_sub를 하나 더 실행 한다음 "Hello World"를 publishing 해보자. 토픽에 subscribing한 모든 클라이언트에 메시지가 전달되는 걸 확인할 수 있다.

MQTT 전용 브로커로 매우 가벼우며, MQTT 브로커가 가져야 할 대부분의 기능을 충실히 지원한다는 장점이 있다. 소형기기에 올려서 사용하기에 적당하다.

()현재 최신 안정 버전 1.3.5는 아직 WebSocket을 지원하지 않는다. 1.4에서 지원하는데, 지금은 직접 빌드해서 사용해야 한다. 클러스터를 지원하지 않는 것도 단점이다. 대규모의 메시징 시스템을 구축하려면 노가다를 뛰어야 한다. 메시징 서비스 인프라에 고가용성은 필수 요소이기 때문에 중요한 문제가 될 수 있다.

AMQP를 지원하는 메시지 큐 서버로 플러그인(Plug-in)방식으로 MQTT를 지원한다. AMQP를 이용한 범용 메시징 서버라서 좀 무겁기는 하지만 클러스터링을 지원하고 다양한 플러그인을 이용해서 기능을 확장할 수 있다. STOMP, 웹 소켓, HTTP(S)등 다양한 통신 프로토콜을 지원하기 때문에, 메시징 서버 인프라의 개발에 적당하다.

RabbitMQ를 설치하면 20개 정도의 플러그인들도 함께 깔린다. rabbitmq-plugins를 이용해서 간단하게 mqtt를 올릴 수 있다.

RabbitMQ는 범용 메시징 서버로 다양한 메시징 방식을 제공한다. AMQP, MQTT 프로토콜을 지원하며 HTTP(S), STOMP, 웹소켓, JSONRPC 등의 다양한 통신 방식을 지원한다. 다양한 활용이 가능하다는 것은 장점이라고 볼 수 있겠는데, 기능이 많은 만큼 무겁다. 자원이 빈약한 소형기기에 사용하기에는 무리가 있다. 메시징 인프라 구축에는 RabbitMQ, 소형기기의 메시징 브로커로는 모스키토의 사용을 고려해 봄직하다.

서비스 마다 달라질 수 있겠다. IoT를 기준으로 제안한다.

서버 인프라는 가용성과 확장성이 유리한 RabbitMQ로 구축한다. 모스키토로도 구축할 수 있기는 하지만 노가다를 뛰어야 한다. 기타 보안, 인증, 다양한 프로토콜 지원, 플러그인 개발 등을 고려해보면 RabbitMQ를 선택해야 할 것 같다.

기기들은 모스키토를 이용한다. 가볍고 간단해서 소형기기에 집어 넣기에 적당하다.

MQTT를 이용한 Pub/Sub 테스트는 끝냈으니, 이제 좀 그럴 듯한 서비스를 만들어봐야 겠다. MQTT를 이용한 chatting 프로그램을 개발할려고 한다. 이 chatting 프로그램은 아래의 기능을 지원한다.

• 채팅방 생성 : 채팅방을 Topic으로 하면 된다. Topic을 늘리는 것으로 여러 개의 채팅방을 운용할 수도 있을 거다. 채팅방을 임의로 만들게 하는 건 귀찮으니.. 그냥 "chat/public", "chat/private" 두개의 채팅방만 만들기로 했다.

채팅방 Join : 원래는 채팅방 목록을 확인해서 Join해야겠으나 귀찮으니, chat/public, chat/private 모두를 sub 하는 걸로 join을 대신하겠다. 유저는 nickname을 만들어서 두개의 topic에서 메시지를 받아본다. 채팅 클라이언트 프로그램은 Sub와 Pub를 모두 해야 하니 멀티 쓰레드로 작동해야 한다.

1. MQTT 브로커로는 앞서 다룬 모스키토를 사용했다.
2. 쓰레드 하나는 Sub 전용이다. 토픽으로 받은 정보를 화면에 출력한다.
   • chat/public : 공개 채널의 메시지를 받기 위해서 사용한다.
   • chat/public/nickname : 자신의 nicname 토픽에 메시지를 받기 위함.
3. 쓰레드 하나는 Pub 전용이다. 표준입력을 토픽에 publishing 한다.
   • chat/public : 공개 채널에 publishing 한다.
4. chat/public/other : 특정 유저에게 publishing 하기 위해서 사용한다.

개발 환경

• 우분투 리눅스 14.04
• Ruby 1.9.3
• mqtt broker : mosquitto

mqtt 모듈은 설치해야 겠다.

# gem install mqtt

지원하는 메시지 타입이다.

• 공개 메시지 : message
• 개인 메시지 : /priv nickname message
• 채팅방 나가기 : /quit message

curses 혹은 Tk, GTk, Qt등을 사용하면 예쁜 인터페이스를 만들 수 있겠으나 귀찮아서 생략

require 'rubygems'
require 'mqtt'
require 'readline'            

# nickname 설정    
nickname=ARGV[0]              

# localhost에서 테스트 했다.
mqtt = MQTT::Client.new('localhost')

mqtt.connect do |client|
    client.subscribe('chat/public')
    client.subscribe("chat/private/#{nickname}")
    enter_msg = "#{nickname} enter room!!"
    client.publish 'chat/public', enter_msg

    # Publish Thread
    Thread.new do
        while message = Readline.readline("", true)
            case message
            when /^\/priv\s*(\w*)\s*(.*)/       # 개인 메시지
                client.publish "chat/private/#{$1}", "<#{nickname}> : #{$2}"
            when /^\/quit\s*(.*)/               # 나가기 
                client.publish 'chat/public', "#{nickname} has quit (#{$1})"
                exit 1
            else                                # 공개 메시지
                client.publish 'chat/public', "#{nickname} : #{message}"
            end
        end
    end

    loop do
        topic, message = client.get    
        print message,"\n"
    end
end

MQTT 포맷 분석

헤더를 위한 2바이트가 필수 정보고, 나머지는 옵션이다. PING 메시지는 단지 2byte의 데이터만 필요하며, 메시지의 타입과 데이터의 크기에 따라서 헤더 크기가 변한다. 저전력, 낮은 대역폭에서의 작동을 위해서, 단 1 바이트의 데이터를 아끼려고 노력한 프로토콜이다.

Fixed Header

두 개의 바이트로 구성된다.

Message Type

0에서 3, 4개의 비트를 이용해서 메시지 타입을 정의 한다. 2^4, 총 16개의 데이터 타입을 정의할 수 있다.

Mnemonic	Enumeration	Description
Reserved	0	Reserved
CONNECT	1	Client request to connect to Server
CONNACK	2	Connect Acknowledgment
PUBLISH	3	Publish message
PUBACK	4	Publish Acknoledgment
PUBREC	5	Publish Received (assured delivery part 1)
PUBREL	6	Publish Received (assured delivery part 2)
PUBCOMP	7	Publish Complete (assured delivery part 3)
SUBSCRIBE	8	Client Subscribe request
SUBACK	9	Subscribe Acknoledgment
UNSUBSCRIBE	10	Unsubscribe Acknoledgment
UNSUBACK	11	Unsubscribe Acknoledgment
PINGREQ	12	PING Request
PINGRESP	13	PING Response
DISCONNECT	14	Client is Disconnecting
Reserved	15	Reserved

Flags

Bit position	Name	Description
3	DUP	Duplicate delivery
2-1	QoS	Quality of Service
0	RETAIN	RETAIN flag

QoS

MQTT는 PUBLISH 메시지를 보낼 때, QoS를 조절할 수 있다. 2개의 bit를 조합해서 QoS 레벨을 조정한다.

QoS value	bit 2	bit 1	Description
0	0	0	최대 한번	Fire and Forget	<=1
1	0	1	적어도 한번	Acknowledged delivery	>=1
2	1	0	정확히 한번	Fire and Forget	<=1
3	1	1	최대한번	Fire and Forget	<=1
4	1	1	Reserved

Remaining Length

Remaining Length는 variable header를 포함한 전체 메시지의 크기를 계산하기 위해서 사용한다. 1에서 부터 4바이트를 사용하는데, 데이터의 크기에 따라서 가변적이다. 1바이트라도 아끼기 위한 눈물겨운 노력의 결정체라고 볼 수 있겠다.

1byte는 255까지 저장할 수 있다. 이중 첫 번째 bit를 "다음 remaining byte를 사용할 건지 결정하기 위해서" 사용한다.

• Byte 2만 사용할 경우 127 byte 크기의 메시지를 다룰 수 있다. 만약 127 byte를 초과 한다면
• Byte 3를 사용해야 한다. 마찬가지로 1개 bit는 reamining byte를 사용할 건지 결정하기 위해서 남겨둬야 한다. 전체 2바이트 에서 2개의 비트를 예약 했으니 16383까지 표현할 수 있다.
• Byte 4도 같은 방법으로 계산 하면 2,097,151 까지 표현할 수 있다.
• Byte 5는 최대 268,435,455를 사용할 수 있다. 4개의 비트를 사용할 수 없으니 2^28 - 1 = 268435455이다.

MQTT가 다룰 수 있는 최대 메시지의 크기가 256M로 제한되는 이유다. 작은 크기의 센서 데이터를 다루는 MQTT의 목적에 비추어 생각해 보면, 합리적인 선택이라고 할 수 있다.

Variable header

어떤 MQTT 명령들은 가변(variable) 헤더 요소를 포함한다. 가변 헤더는 고정 헤더와 페이로드(payload) 사이에 위치한다.

protocol name

프로토콜 이름은 MQTT CONNECT메시지에서 사용한다. UTF-8 인코딩된 프로토콜 이름이 사용된다.

Protocol version

MQTT CONNECT메시지와 함께 사용한다. 8bit unsigned 값을 이용해서 프로토콜 버전을 설정할 수 있다. ()현재 프로토콜 버전은 3(0x03) 이다.

Topic name

토픽 이름은 MQTT PUBLISH 메시지에 포함된다. 토픽 이름은 payload에 포함된 데이터를 published 할 때 사용하는 채널의 이름이다. 토픽 이름은 UTF 인코딩된 값을 사용한다. 토픽 이름은 32,767의 길이 제한을 가진다.

IoT connectivity를 위한 MQTT

Local connectivity

Local에서의 기기 연결을 위한 이렇다한 표준이 없는 상태다. 퀄컴과 LG가 주도하는 Allseen 얼라이언스의 Alljoyn, 인텔과 삼성이 주도하는 OIC(Open Interconnect Consortium) 등이 경쟁하는 양상. 애플은 HomeKit이 있긴한데, Allseen과 OIC와는 적용 범위가 좀 다른 것 같고, 어차피 독고다이로 나갈 느낌이라서 제외.

나와 좀 관련이 있는 Alljoyn을 기준으로 보자면, 로컬 discovery와 통신 모두 기존의 프로토콜을 사용하지 않고 새로 구현해서 사용하고 있다. No TCP/IP영역에서의 센서수집에 MQTT를 사용 할 수는 있겠지만 주요한 프로토콜은 아니다.개인적으로 DNS-SD와 MQTT 같은 (거의)표준기술을 이용하는게 나을 것 같다. 굳이 새로운 프로토콜을 만들 필요가 있었을까라는 의문이 든다.

아래와 같은 모양이 되지 않을까 ?

1. 소형 장비의 센서를 수집하고 제어하기 위한 Gateway가 있을 수 있다.
2. AllSeen 혹은 OIC Gateway가 있다. 이들은 Local의 기기를 discovery하고, 메시지를 중계하는 브로커 역할을 한다. 그리고 IoT Internet Infra로의 연결을 위한 인터넷 게이트웨이 역할을 한다.
3. IoT Internet Infra의 연결에 MQTT를 사용한다.

실제 Alljoyn gateway에 MQTT 플러그인을 올릴 계획도 있으니, 그럭저럭 현실적인 구성이라고 볼 수 있다.

Remote connectivity

IoT기기들과 유저 모바일 기기 그리고 인터넷 서비스들은 IoT intnet infra에 연결된다. 이때 MQTT를 사용할 수 있다.

인터넷 애플리케이션과의 연동

IoT에서 인터넷 애플리케이션과의 연동은 핵심 가치 중 하나다.(IoT의 I가 internet이라는 것에 주목하자.) 따라서 인터넷 애플리케이션 혹은 인터넷 서비스와의 연동 방안을 고민해야 한다.

1. 유저 모바일 애플리케이션 : 채널을 분리한다. 메시지는 HTTP 기반으로 전송하고, 응답은 MQTT client로 받는다. 네이티브 혹은 하이브리드 앱에서 사용할 수 있다.
2. 웹 브라우저 : HTTP로 전송하는 건 동일하다. 응답은 웹 소켓을 이용한다. 많은 MQTT 브로커들이 웹 소켓 인터페이스를 제공한다.
3. 소형 디바이스 : MQTT 단일 인터페이스로 송/수신한다.
4. 웹 애플리케이션 : 그림에는 없지만, 인터넷 서비스와 Server - to - Server 방식으로 연결할 수 있다. 이 경우 양측이 OpenAPI를 제공하고, 서로 호출하는 방식을 사용한다.

페이스북은 1번 방식을 사용하는 걸로 알려져있다.

참고

• Learning on publish subscribe mqtt mosquitto
• Building FaceBook messenger
• Message Broker Technology for flexible signalling control
• MQTT 브로커 기능 비교
• MQTT V3.1 Protocol Specification
• MQTT man page