[Inside AIoT] AIoT에 딱 맞는 프로토콜, MQTT 파헤치기

안녕하세요! 
기계장비와 AI가 연결된 스마트한 제조현장을 만들어가는 엣지크로스입니다.

더 많은 분들에게 AI와  IoT 기술에 대해 쉽고 친숙하게 알려드리기 위해
어떤 기술이 어떻게 변화하고 있고, 또 그 기술이 실제로 현장에서는 어떻게 적용되면서 혁신을 가속화하고 있는지 
실제 현장의 소식을 Inside AIoT 콘텐츠를 통해 전하고자 합니다. 

그 첫 번째로 실제 AIoT 개발에서 빼놓을 수 없는 핵심 개념, MQTT을 소개합니다. 

---

Written by. 고민지 연구원 (엣지크로스 백엔드 개발)

 

안녕하세요, 저는 엣지크로스의 클라우드팀에서 백엔드 개발자로 데이터를 수집 및 적재하고 처리하는 업무를 담당하는 고민지라고 합니다.🤔

Inside AIoT의 첫 번째 글을 맡게 되어, 평소 업무를 하면서도 가장 많이 듣고 쓰는 핵심 용어인 MQTT를 소개해드리려 합니다.

 

IoT 데이터, 어떻게 전달될까요?

MQTT를 설명하기에 앞서, 먼저 IoT 센서로 수집된 온도 등의 데이터가 실제로 어떻게 사용자에게 전달되는지 알아보겠습니다. 

기기에서 데이터가 수집되어 클라우드로 전송되고, 해당 데이터가 다시 유저에게 전달되기까지의 과정을 단순하게 표현하면 아래 도식과 같을 것입니다. 

 

1. 디바이스에 내장된 온도 센서가 주변의 온도값을 측정합니다.
2. 디바이스의 펌웨어는 측정값을 사용자가 이해할 수 있는 특정 포맷으로 가공합니다.
3. 가공된 데이터는 클라우드의 중앙 집중식 데이터 수집 지점으로 전송합니다.
4. 최종적으로 클라우드는 수집된 데이터를 사용자에게 전달합니다.

 

이러한 과정을 통해 디바이스가 데이터를 목적지까지 안전하고 또 효율적으로 전송하기 위해서는 아래의 두 가지가 필수적으로 갖춰져야 합니다.

1) Wifi나 LTE와 같은 신뢰할 수 있는 네트워크 전송 기술,
2) 그리고, 이러한 네트워크 전송 기술을 통해 데이터를 전송하기 위한 IoT 메시지 전송 프로토콜 

 

IoT  메시지 전송 프로토콜, MQTT

프로토콜은 컴퓨터 내부에서 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계를 의미합니다.
그렇다면 IoT 메시지를 전송하기 위한 프로토콜에는 어떤게 있을까요?

IoT 디바이스들은 일반적으로 소형입니다. 
또한 그 특성상 도시의 빌딩 내부에서부터 농촌 지역에 이르기까지 다양한 환경에 배치되고 있습니다.
따라서 이러한 특성을 고려한다면, 안정적으로 전원을 공급하기 위해 배터리를 사용하는 경우가 많다고 합니다.

배터리로 작동하는 디바이스들은 저전력 설계를 통해 장시간 동안 배터리 수명을 연장할 수 있어야 합니다.
즉, 낮은 전력과 낮은 대역폭에서도 IoT 메시지를 전송할 수 있는 프로토콜이 필수적이라는 의미죠.
이때문에 일반적으로 웹 상에서 자주 사용하는 HTTP는 IoT 디바이스의 통신에는 적합하지 않습니다.
결론적으로 IoT 메시지 전송 프로토콜로 MQTT와 CoAP을 주로 사용하게 됩니다. 
제가 몸담고 있는 엣지크로스는 이 중 MQTT를 사용하고 있기 때문에 MQTT에 대해 본격적으로 알아보겠습니다!

 

MQTT 샅샅이 파헤치기

 

MQTT는 Publish-Subscribe 메시지 프로토콜로, Broker가 Pulisher와 Subscriber 사이를 중재합니다.
Publisher는 Broker가 관리하는 특정 토픽으로 메시지를 발행하고, Subscriber는 관심있는 특정 토픽으로 발행된 메시지를 구독하는 방식입니다.

토픽(Topic)은 메시지를 전달하는 통로로, ‘/’를 기준으로 계층적으로 표현됩니다.
예를 들어, sensor/temperature/room1, sensor/humidity/room1 과 같이 지정하여 사용합니다.
토픽을 기준으로 다수의 Publisher가 메시지를 발행할 수 있고, 다수의 Subscriber가 메시지를 구독하여 동시에 동일한 메시지를 수신할 수 있는 구조입니다.

여기서 잠깐! 만약 Publisher가 발행한 메시지가 네트워크 상의 문제로 제대로 전달되지 않으면 어떻게 되는 걸까요?
이 경우에는 QoS 설정값에 따라 달라집니다.
QoS는 메시징 품질 보장을 위한 옵션으로 MQTT는 아래와 같이 세 가지의 QoS 설정값을 제공하고 있습니다.

• QoS 0 (At most once) : 메시지는 최대 한번 전달됩니다. 전송 확인이 없기에 유실 가능성이 있습니다.
• QoS 1 (At least once) : 메시지는 최소 한번 이상 전송되게 됩니다. 전송 확인을 하지만 중복 전달될 가능이 있습니다.
• QoS 2 (Exactly once) : 정확히 1번의 전달을 보장합니다. 다만 종단간 전송 지연 가능성이 있습니다.
  
  

MQTT, HTTP와는 뭐가 다를까요?

가장 일반적으로 많이 알고 계시는 HTTP와는 어떻게 다를까요?
MQTT와 HTTP의 차이를 비교 정리해보면, 왜 IoT 환경에서 MQTT가 적합한 프로토콜인지 더욱 확실하게 이해할 수 있게 됩니다.

1. 헤더 크기: MQTT의 헤더 크기는 매우 작습니다. 최소 헤더 크기가 2바이트인 반면, HTTP의 헤더는 일반적으로 수백 바이트에 달할 수 있습니다. 이는 MQTT가 훨씬 적은 양의 데이터를 전송해도 되는 것을 의미합니다.
2. 프로토콜의 복잡성: HTTP는 텍스트 기반 프로토콜로, 상대적으로 복잡한 요청-응답 패턴을 사용합니다. 반면에 MQTT는 간단한 게시-구독 모델을 사용하며, 이는 프로토콜 처리에 필요한 계산량을 줄여줍니다.
3. 지속적 연결: MQTT는 지속적인 연결을 유지하며, 한 번의 연결 설정 후 여러 메시지를 전송할 수 있습니다. 반면에 HTTP는 일반적으로 각 요청마다 새로운 연결을 필요로 합니다(비록 HTTP/1.1과 HTTP/2가 연결 재사용과 멀티플렉싱을 지원하기는 하지만). 이러한 차이는 네트워크 오버헤드와 관련하여 MQTT가 더 효율적이라는 것을 의미합니다.
4. 메시지 전달 보증(QoS) 옵션: MQTT는 다양한 수준의 메시지 전달 보증을 제공합니다. 이는 필요에 따라 네트워크 대역폭과 전력 소비를 최적화할 수 있게 합니다. HTTP는 이런 유연성을 제공하지 않습니다. MQTT는 메시지 전달의 신뢰성을 보장하기 위해 다양한 QoS 레벨을 제공합니다. 예를 들어, QoS 0은 메시지가 최대 한 번 전달됨을 의미하고 (최소한의 오버헤드), QoS 1은 메시지가 적어도 한 번 전달됨을 보장하며, QoS 2는 메시지가 정확히 한 번 전달됨을 보장합니다 (가장 높은 오버헤드).
5. 실시간 통신: MQTT는 실시간 통신에 최적화되어 있으며, 매우 낮은 지연 시간을 제공합니다. HTTP는 폴링 방식을 사용하는 경우가 많아, 실시간 통신에 비효율적일 수 있습니다.
6. 텍스트 대 이진 프로토콜: HTTP는 기본적으로 텍스트 기반으로, 바이너리 데이터를 base64로 인코딩해야 합니다. 반면에 MQTT는 이진 프로토콜로, 같은 정보를 표현하는데 더 적은 데이터를 필요로 합니다.

 

MQTT 소개글을 마무리하며

엣지크로스는 낮은 전력과 낮은 대역폭 등의 한계를 너머 각종 IoT 데이터를 신뢰성 있는 MQTT 프로토콜을 사용하여 수집하고 있습니다.
그 중에서도 QoS 0 방식으로 최대한 경량화하여 실시간으로 데이터를 최대한 빠르게 사용자에게 전달하고 있습니다.
(물론 경우에 따라 누락 없는 전송을 위해 QoS 1 방식도 함께 사용하고 있습니다.)

엣지크로스와 함께 IoT 데이터를 쉽게 실시간으로 수집하고 확인해보는건 어떨까요? 🤗

 

엣지크로스 솔루션, 더 자세히 알아보고 싶으시다면 ✅ https://edgecross.ai

EdgeCross 엣지크로스