MQTT가 알고싶다

MQTT 프로토콜을 기반으로 만들어진 자사의 서비스 애플리케이션을 시작으로 MQTT에 대한 궁금증이 생겨났다.

다짜고짜 구글링을 해보았다.

그 결과, IOT 관련 최고의 네트워크 프로토콜 중 하나라고 하는 글들을 여럿 보았다.

네트워크를 통해 메시지를 주고 받아야하는 device에서 사용하기 유용하다고 한다. 왜? 어떻게?.... 궁금증이 증폭됬다.

MQTT

MQTT는 1999년 IBM과 Eurotech에 의해 개발되었으며, 저전력 배터리나 네트워크 상태가 좋지 않은 제한적인 환경에서 동작하게 하기 위한 용도로 만들어 졌다. 때문에 낮은 전력과 낮은 대역폭 환경에서 사용 할 수 있도록 설계 되었고 이러한 점 때문에 IoT device에서 사용하기 유용하다고 한다.

풀네임으로는 Message Queue for Telemetry Transport ( Telemetry 란 원격 대상을 관측하고 그 데이터를 취득하는 기술이다. ) 이며 publish / subscribe / MQTT-broker를 사용하는 프로토콜이다.

HTTP 와 다른 점

HTTP는 비교적 높은 대역폭을 사용하고 고전력을 필요로 하며 요청 - 응답 기반이다. 즉 클라이언트가 먼저 요청을 보내야 서버와 통신이 가능하다. 반면 MQTT는 클라이언트 혹은 서버 둘 중 누구나 통신을 시작 할 수 있다.

MQTT header / payload

MQTT 프로토콜의 헤더의 크기는 매우 작고 message payload는 byte array로 되어 있어 낮은 대역폭 환경에서도 사용하기 용이하다.

MQTT의 헤더는 2 byte의 고정 헤더와 최대 12 bytes의 가변 헤더로 이루어져있다. 12 bytes의 가변적인 헤더는 subscriber들과 연결을 위한 정보를 담고 있고 2byte의 고정 헤더는 publisher를 위한 정보를 담고 있다.

Publisher / Subscriber

Publisher 은 토픽을 발행하고 subscriber은 토픽을 구독하는 구조 이다. 토픽에 변화가 생겼을때 브로커를 통해 구독자에게 변화를 즉각 알려준다. 브로커는 publisher와 subscriber 사이에서 토픽을 구독하는 클라이언트 전체에게 관련 정보를 푸시해주는 브로커 이다.

Topic

계층형 자료구조로 디렉토리를 표기하는 것 처럼 / 를 기준으로 계층적으로 데이터를 표현한다. 하나의 엔드포인트라고도 할 수 있다. 이 토픽은 MQTT 브로커를 통해 subscribers 에게 전달된다.

MQTT-Broker

MQTT 브로커는 Publisher 와 Subscriber들간의 메시지를 주고 받을 수 있는 중개인 역할을 하기 때문에 '브로커'라고 불린다.

다양한 종류의 오픈 소스 브로커가 있으며 대표적으로 Mosquitto, Mosca, RabbitMQ, EMQ, VerneMQ 등이 있다

Three qualities of service

MQTT 는 Three qualities of service (QoS) 를 지원한다.

1. fire and forget 또는 QoS=0

가장 빠른 전송 방법으로 메시지는 한번만 전달하며 전달 성공 여부는 확인하지 않는다.

2. at least once 또는 QoS=1

통신의 디폴트 모드이며 최소 한번을 보낸다. 전송 성공 여부가 확인되지 않으면 DUP flag 와 함께 메시지를 재전송 하기 때문에

중복으로받을 수 있다.

3. exactly once 또는 QoS=2

무조건 한번만 전송한다. 메시지를 받는 대상에게서 확인을 받을때까지 로컬 저장소에 저장해놓는다. 가장 안전하지만 느린 방식이다.

발행자와 구독자 모두 QoS를 지정할 수 있으나 발행자가 지정한 최대 QoS가 우선시 된다.

데이터의 최신성이 중요한 토픽은 QoS를 낮게 설정하여 최신성을 보장 할 수 있고

구독자에게 반드시 전달 되어야 하는 정보라면 전송 시간이 다소 걸리더라도 QoS를 높게 설정하여 개발할 수 있다.

MQTT를 사용하는 기업

우아한 형제들

우아한 형제들 기술 블로그 2017년 글 중에 MQTT 적용을 통한 중계시스템 개선 이라는 제목으로 올라온 글이 있는데

실제로 해당 기술을 잘 적용해서 사용하고 있는지, 이후 어떻게 됬는지 잘 모르겠다..

Facebook Messenger

2011년 페이스북은 Facebook Messenger에서 메시지를 전달하기 위해 MQTT 기반의 푸시 서비스를 적용했다고 한다.

수 많은 사용자를 보유한 페이스북은 서버에 세션을 만들고 관리 하는 것만으로도 상당한 부하가 발생 하기 때문에 MQTT를 도입했다. MQTT는 채팅방을 하나의 토픽으로 지정하고, 채팅에 참여한 사용자를 각각 발행자와 구독자로 메시지를 전달하게 한 뒤 MQTT 브로커가 메시지를 전달하는 구조로 세션 관리에 대한 부하를 분산 시킨다.

Facebook Messenger Service의 publish/subscribe 구조

채팅 참여자는 채팅방 토픽을 subscribe하고 채팅을 시작하면 토픽을 publish한다. 그리고 채팅을 떠날때는 unsubscribe 하기만 하면 된다.

완벽해 보이지만 단점 또한 있다. 이러한 방식은 메시지의 순서를 관리하기 위해 브로커 구현에 많은 신경을 써야한다.

하지만 이런 단점에도 불구하고 페이스북은 수 억명의 사용자가 웹과 모바일 환경 양쪽에서 채팅을 할 수 있는 서비스를 목표로 삼은 것으로 보인다. 이에 따라 성능 향상을 위한 최우선 방안으로 발행/구독 구조를 선택한 것으로 보인다.

결론

프론트엔드 개발자로써 자사 서비스의 MQTT를 직접적으로 다룰 일을 없으나 어떤 이유로 MQTT를 도입했는지 아주 조금은(?) 알 수 있을 것 같다. 다양한 사용자 디바이스 환경을 고려함과 동시에 성능을 목표로 하는 글로벌 서비스라면 MQTT의 Publish/Subscribe 구조의 도입을 생각해 볼만 한것 같다.

참고 자료 :

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.pro.doc/q002870_.htm

https://www.oracle.com/corporate/features/simple-messaging-with-mqtt.html

https://mqtt.org/mqtt-specification/

https://d2.naver.com/helloworld/1846

https://dydtjr1128.github.io/mqtt/2018/01/31/MQTT-and-MQTT-brokers.html

https://woowabros.github.io/experience/2017/08/11/ost_mqtt_broker.html