[Protocol] MQTT : IoT를 위한 경량 메시징 프로토콜

프로젝트를 진행하며 센서 데이터를 활용하기 위해 아두이노를 도입한 경험이 있습니다.
​
실시간으로 변화하는 센서 데이터를 웹을 통해 모니터링하는 기능을 구현하며 MQTT 프로토콜에 대해 학습할 기회도 얻었습니다.
​
MQTT는 pub/sub기반의 머신 대 머신메시징 프로토콜 인데요,
이번 글에서는 MQTT에 대해 알아보고, 다음에는 프로젝트에 도입했던 내용과 관련하여 공유하고자 합니다.
​

---

​

1. MQTT란?

​
MQTT(Message Queuing Telemetry Transport)는 사물 인터넷(IoT) 디바이스 간의 통신을 위해 설계된 경량 메시징 프로토콜입니다. 발행-구독(pub/sub) 모델을 기반으로 하며, 낮은 대역폭 환경에서도 안정적으로 작동하도록 설계되었습니다.1999년 IBM에서 개발된 후 2010년 오픈 소스로 공개되었으며, 현재는 OASIS 표준으로 관리되고 ISO 국제 표준(ISO/IEC 20922)으로도 인정받고 있습니다.
MQTT는 리소스 제약이 있는 환경에서도 안정적으로 작동하며, 낮은 대역폭과 전력 소비로 효율적인 통신을 지원합니다.
이런 MQTT의 효율성과 경량성을 바탕으로 여러 기업에서도 채택했던 적이 있습니다.


예를들어:
​

• Facebook은 초기 메시징 앱의 전송 속도 개선을 위해 MQTT를 도입했었습니다.(참고)
• 우아한형제들은 배달의민족의 주문 중계 시스템에서 운영 비용을 줄이고 효율성을 높이기 위해 기존 설계 방식(API Polling)을 MQTT 기반으로 개선한 경험이 있습니다.(참고)
  ​

  2. MQTT의 주요 특징

  ​

  경량성 및 효율성

  ​
• MQTT는 작은 데이터 패킷을 전송하여 통신 효율성이 뛰어납니다.
• 헤더 크기가 작아 HTTP와 비교할 때 매우 가벼운 프로토콜입니다. (모두 L7에 속하나, MQTT는 TCP연결을 유지하며고 가변헤더와 페이로드를 포함해도 HTTP보다 헤더가 작다.)
• 오버헤드와 전력 소비가 적어 리소스 제약 디바이스에 적합합니다.
  ​

  브로커를 통한 발행-구독(pub/sub) 기반 통신

  ​
  일반적인 서버-클라이언트 구조와 달리, MQTT는 브로커(Broker) 서버를 통해 통신하며, 토픽(Topic)을 기준으로 메시지를 주고받습니다.
  ​
• MQTT는 브로커를 통해 메시지를 중계합니다.
• 메시지는 개설된 특정 Topic에 발행(publish)되고, 해당 토픽을 구독(subscribe)하는 클라이언트에게 전달됩니다.
• 이를 통해 일대일, 일대다 통신이 가능합니다.
  ​

  QoS(Quality of Service) 지원

  ​
  MQTT는 세 가지 QoS Level을 통해 메시지 전송 신뢰성을 보장합니다.
  QoS는 mqtt 프로토콜만 아니라 다양한 네트워크 및 통신의 영역(ISP, VoIP 등)에서 메세지 전송 quality를 보장하는 서비스 입니다.
  ​
• 1. QoS 0 (At most once delivery):* 최대 1회 전송 보장 (메시지 누락 가능성 있음)
  ​
  
  ​
  Topic을 통해 메시지를 전송할 뿐 전송을 보장하지 않습니다.
  ​
  더 자세히 보기

  수신자(Broker)가 응답을 보낼 필요가 없기에 발신자(Publisher)는 수신자가 메시지를 제대로 받았는지 확인하지 않습니다. 응답을 받지 않기에 발신자는 재전송도 하지 않습니다. 수신자는 받은 메시지를 저장하지 않고 바로 구독자에게 발송합니다. 메시지가 누락될 가능성이 있기에 메시지는 0번 또는 1번만 전달될 수 있습니다.
  
  

2. QoS 1 (At least once delivery): 최소 1회 이상 전송 보장 (중복 수신 가능성 있음).
​

​
구독하는 클라이언트가 메시지를 받았는지 불확실하면 정한 횟수만큼 재전송 합니다. 다만, 메시지의 핸드셰이킹을 엄밀하게 추적하지 않아 중복 수신 가능성 있습니다.
​

더 자세히

메시지 전송 시 발신자(Publisher)는 Packet ID를 포함하여 메시지를 전송합니다. 수신자(Broker)는 메시지를 받으면, 메시지를 저장한 뒤 구독자에게 전달하고 메시지를 삭제합니다. 이후 수신자는 받은 Packet ID를 사용해 PUBACK 메시지를 발신자에게 전송하며 메시지 전달을 완료합니다. 송신 측은 PUBACK 메시지를 통해 수신 측이 메시지를 받았는지 확인할 수 있습니다. 하지만 PUBACK 단계에서 Network 이슈 등으로 지연이 발생하면 발신자는 응답이 없다고 판단하여 메시지를 재전송할 수 있습니다. 이 경우, 수신자가 메시지를 구독자에게 이미 발송하고 삭제한 상태라면 중복 여부를 판단하지 못해 동일한 메시지를 다시 보낼 수 있습니다. 따라서 QoS 1은 메시지 누락은 방지할 수 있으나, 메시지가 중복으로 전달될 가능성이 존재합니다.

3. QoS 2 (Exactly once delivery): 정확히 1회 전송 보장 (리소스 소모가 크지만 가장 신뢰성 있음).
​

​
QoS 1에서와 같이 발신자(Publisher)는 메시지 전송 후 응답을 받아 메시지 전송성공 여부를 판단합니다. 다만 QoS 2에서는 4-way handshaking 를 사용하여 정확히 한번의 메시지 전송을 보장합니다.
​

더 자세히 보기

QoS 1에서처럼 발신자(Publisher)는 메시지를 전송한 후 응답을 받아 전송 성공 여부를 판단합니다. QoS 2에서는 4-way 핸드셰이킹 방식을 사용해 정확히 1번의 메시지 전송을 보장합니다. 수신자(Broker)는 메시지를 삭제하기 전에 구독자에게 메시지를 전달했음을 발신자에게 알립니다. 발신자는 수신자로부터 확인 메시지를 받은 후에만 메시지 전송을 완료 처리합니다. Network 지연으로 메시지가 재전송되더라도, 수신자는 이전에 받은 메시지 정보를 가지고 있어 중복 전송을 방지할 수 있습니다. PUBCOMP 단계에서 지연이 발생하더라도 수신자는 이미 이전 단계에서 메시지를 처리했으므로 구독자에게 메시지를 다시 보내지 않습니다. QoS 2는 처리 리소스 소모가 크지만, 메시지 중복이나 누락에 민감한 데이터를 다룰 때 적합합니다.

​ ## 3\. 주요 용어 ​ - **Broker(Server)** : Application Message를 발행하는 Client와 구독 한 Client간의 중재자 역할을 하는 프로그램 또는 디바이스입니다. - **Application Message** : MQTT 프로토콜을 통해 네트워크를 통해 전달되는 메시지, QoS 및 Topic과 연관되어 처리됩니다. - **Subscription** : 특정 토픽에 연결하여 메시지를 수신하는 행위. Topic Filter와 Maximum QoS를 포함하여 Server에 요청하게 되며, 구독 시 특정 Topic Name을 가진 Application Message를 전달 받을 수 있습니다. - **Topic Name** : Application Message에 부여되는 고유 식별자. 이를 통해 메시지가 발행되고 구독됩니다.. Server는 일치하는 Topic을 Subscription한 Client에게 Application Message을 전달합니다. - **Topic Filter** : Subscription 요청 시 포함되는 일종의 표현식. 하나 또는 여러 개의 Topic을 구독할 수 있습니다. Topic Filter는 Wildcard 문자가 포함될 수 있습니다. - **MQTT Control Packet** : 네트워크를 통해 전달되는 정보 Packet, MQTT 규격에서는 총 14개의 타입으로 Control Packet을 생성하여 전달할 수 있습니다. - **QoS(Quality of Service)**: 메시지 전송 신뢰성을 보장하는 서비스 수준.

4. MQTT의 작동 원리

​

작동 방식

​
1. 클라이언트가 토픽을 구독하거나 발행할 수 있는 네트워크에 연결
client와 broker가 연결을 위해 클라이언트는 브로커의 ip address와 port 번호를 사전에 알고 있어야 하며 TCP/IP 연결이 되면 프로세스가 시작된다. 클라이언트는 CONNECT 패킷을 보내고 브로커는 이에 대한 대답으로 CONNACK 패킷을 전송한다.(CONNACK 패킷에 연결 수락/거부를 표현하는 반환코드가 포함)
2. MQTT 클라이언트가 토픽을 게시하면 MQTT 브로커와의 연결을 설정
3. 연결 성공하면 클라이언트는 브로커에 메시지를 게시하거나 특정 Topic을 구독하거나 둘 다 수행할 수 있다.
4. MQTT 브로커는 클라이언트로부터 메시지를 수신한 후 해당 Topic을 구독자한 클라이언트들에게 메시지를 전달
​

브로커 기반 통신

​
MQTT는 pub/sub 모델을 기반으로 동작하며 메시지를 발행하는 클라이언트와 구독하는 클라이언트는 직접 연결되지 않으며, 브로커가 이를 중계
​

토픽 기반 구조

​

• MQTT는 디렉터리와 유사한 계층적 토픽 구조를 사용하여 메시지를 분류

• 토픽이름에 공백이 들어가면 안되고 최상위 토픽은 /로 시작하면 안됨

• 예: home/firstfloor/kitchen/temperature
  ​

  게시(발행)와 구독

• 게시자는 특정 토픽에 데이터를 게시하고, 구독자는 해당 데이터를 수신

• 구독자는 데이터를 받을 준비가 되어 있지 않아도 이후에 메시지를 수신 가능

• '#' 문자를 이용해서 토픽 전체를 구독하면 오버헤드가 심해질 수 있음
  ​

  브로커 기반 통신의 장점

• 공간 분리: 클라이언트는 서로의 네트워크 위치나 주소를 몰라도 통신 가능

• 시간 분리: 게시자와 구독자가 동시에 연결될 필요 없음

• 동기화 분리: 양쪽이 서로를 중단시키지 않고 메시지를 전송하거나 수신할 수 있음. 예를 들어 구독자는 게시자가 메시지를 전송할 때까지 기다리지 않아도 됨

  
  

5. MQTT의 활용 사례

스마트 홈 자동화
스마트폰에서 open door 메시지를 발행하면, 해당 토픽을 구독 중인 도어 디바이스가 이를 처리하여 문을 여는 시스템을 구현할 수 있습니다.

Example: Smart door opening with a mobile device using MQTT (출처: https://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt/)

산업 IoT
정유 및 가스 산업에서 저대역폭 환경을 통해 원격 모니터링을 수행합니다. 원격지에서 실시간 데이터를 전송하여 운영을 효율화합니다.

모바일 및 POS 시스템
테이블 오더 시스템에서 고객이 주문한 내역을 POS 장치로 자동 전달하여 주문 과정을 간소화할 수 있습니다.

6. 마무리

(pub은 발행과 게시 두 단어중에 어느것이 더 적절한지 모르겠습니다. 뜻은 발행이 맞는 것 같긴한데 한국어로 들으면 게시가 좀 더 익숙하네요)

MQTT는 IoT 환경에서 효율적인 데이터 전송을 위해 설계된 발행-구독 메시징 프로토콜입니다. 경량성과 확장성을 바탕으로 스마트 홈, 산업 IoT, 실시간 데이터 전송 등 다양한 분야에서 널리 사용되고 있는것 같습니다. 다음에는 프로젝트에서 MQTT를 적용했던 내용 관련하여 작성할 예정입니다.
MQTT를 활용하면 리소스 제약이 있는 환경에서도 안정적이고 신뢰성 있는 통신을 구현할 수 있습니다. 특히 오픈소스 생태계 덕분에 활용 가능한 라이브러리와 예제들도 풍부해서 처음 접하도라도 금방 결과물을 만들 수 있습니다. 여러분의 IoT 프로젝트에 MQTT를 도입해보세요!

참고: https://aws.amazon.com/ko/what-is/mqtt/