최근에 업무에서 MQTT를 도입하자는이야기가 나와 공부할 필요성을 느끼고 검색해보았다.
MQTT에 대해 검색해보면 나오는 말 중 하나가 저전력이여서 좋다고 한다.
이게 프로토콜에 불과한데 왜 저전력이라는 말까지 사용되는지 이해하고자 더 공부해았고, 그 내용을 적어보려고 한다.
1. MQTT 란?
MQTT는 Message Queue Telemetry Transport의 약자로, 메세지-큐 방식을 이용한다.
1) Message - Queue?
Message는 사용자가 전달하고 싶은 말로, 흔히 메세지를 보낸다, 받는다 말을 할때의 메세지로
컴퓨터에서는 데이터를 메세지로 볼 수 있다.
Queue(큐)는 FIFO(First Input, First Out), 선입선출, 먼저 들어온대로 나가는 구조를 말한다.
큐가 아닌 다른 자료형(Stack, Tree, Node... ) 등도 많은데 메세지를 큐로 보낸다는 말은
우리가 보는 기준에서는 시간순으로 처리하고 싶다는 의미가 될 것이다.
2) 그래서 MQTT는 뭐야?
MQTT는 위에서 설명한 메세지-큐 방식에다가 Telemetry Transport 라는 단어가 더 붙었다.
Telemetry? 검색해보면 원격 측정을 말한다.
풀어쓰면, 내가 보낸 메세지(데이터)가 전송되어서도(원격) 측정되도록 전송(Transport)되어야 한다.
이렇게 보면 뭐지? 그냥 HTTP 로도 되지 않나??
http도 있는데 이 걸 두고 MQTT를 쓰는 이유가 뭘까?? 하는 생각이 든다.
여기서 MQTT에 대한 개념을 더 알아야 한다.
MQTT에서는 발행/구독(Publish/Subscribe = Pub/Sub) 구조를 사용한다.
3) 구독/발행 ? 이건 또 뭐지?
구독/발행 구조는 어떤 발행자가 주제(Topic)을 발행하면, 그 주제(Topic)을 알고 있는 사람이
브로커(중개자)에게 데이터를 요청하면 데이터를 받아볼 수 있는 방식이다.
실생활에 접목시켜 설명해보면 이렇다.
XX신문이라는 신문사가 있다면, 그 신문은 XX신문 이라는 주제(Topic)로 기사(데이터)를 발행한다.
많은 가판대들이 많은 신문사들로부터 매일매일 신문을 받을 것이다.(브로커)
소비자(구독자)들이 가판대에 가서 XX신문(Topic) 을 요청하면, 그날의 기사(데이터)를 받아볼 수 있다. (구독)
추가로 MQTT 역시 프로토콜이다. 프로토콜은 정의된 규칙이다.
MQTT에서는 토픽을 슬래쉬로 구분하여 사용하는데, REST API 에서 보는 구조와 흡사하다.
하지만 다른 점으로 슬래쉬 사이에 +, # 을 이용할 수 있다.
+을 사용하면 해당 단계의 모든 것을 의미한다.
#을 이용하면 해당 단계 아래의 모두를 포함하는 것을 의미한다.
예를 들면 이렇다.
+는 /서울/xx구/xx동/주소지 라는 구조가 있다면, /서울/xx구/xx동/+ 로 xx동의 모든 주소지에 적용이 가능하다.
#은 /서울/# 으로 서울의 모든 주소지에 적용시킬 수 있다.
당연히 무작위로 보내는 것도 좋겠지만, 잘 갔는지 확인할 필요도 있다.
MQTT에서는 QoS(Quality of Service) 라는 파라미터로 전송 여부를 확인한다.
0은 발행 측(Publisher)에서는 성공적으로 전달되었는지 확인하지 않는다.
1은 적어도 한번 전달시킨다는 의미로 구독자가 받았다는 사인을 받을 때까지 보내는데, 중복적으로 전달될 수도 있다.
2는 정확히 한번만 된다는 의미로 구독자에게 전달되었을 때 메세지를 삭제한다.
설명만 보아도 확인 작업이 들어가다보니, 0이 전송량의 효율이 좋다.
2. 왜 쓰이게 되었을까?
MQTT라는 프로토콜을 처음 들으면서 공부하는 이유가 이거다.
MQTT로도 통신이 되는 건 마찬가지인데 왜 굳이 MQTT를 쓸까??
HTTP는 <Head><Body> 구조로 되어있다.
<head> 만 해도 내부에 <Content-Type>, <User-Agent> <...> 등 다양한 데이터가 들어간다.
<Body> 에서는 더 말할 것도 없이 일반적으로 더 많은 데이터가 들어간다.
프로토콜에 들어가는 태그 하나하나가 곧 데이터를 더 많이 사용하게 되고,
구조적으로 html을 파싱하는데에도 비용이 발생하게 되기 때문이다.
다시말해 MQTT는 HTML보다 자원 소모가 적다.
프로토콜 덕분에 +, # 문자 하나로 그룹으로 보낼 수 있으니 1:N 대응이 편리해진다.
http였으면 엔드포인트 하나마다 POST, GET을 했었어야 되거나, 전체에 보내는 코드를 추가로 구현했었어야 됐을 것이다.
그리고 QoS에 따라 반응(Response)을 고려할 수 있다는 점이다.
3. 어떨 때 쓰이면 좋을까? 왜 IoT에서 주로 쓰일까?
요즘 많이 쓰는 HTTP를 두고 굳이 MQTT를 쓰는 이유로부터 차이점을 알게 됐다.
당연히 그 차이가 있는만큼 상황에 따라 유리한 구조에서 써야할 것이다.
먼저, Pub/Sub 구조를 사용하다보니 1:N이 가능하다는 점에서 동시 제어가 필요할 때 의미가 있다.
그리고, 아까 궁금했었던 IoT에서 왜 주로 쓰일까란 말에 대해서 자연스럽게 답변이 되는 것 같다.
아까 처음에 언급한 저전력이여서 좋다고 한다는 말은 아마 이런 내용일 것이다.
IoT 디바이스들은 데크스탑에 비해 상대적으로 성능이 좋지 않기 때문에, 데이터양이 적을수록 처리하기 편리하다.
MQTT는 HTTP에 비해 파싱 비용이 적다.
같은 데이터를 비교해봤을 때 파싱하는데 비용이 줄어드므로 전력 소모가 덜해진다.
따라서 배터리 효율이 좋아지고, 저전력이라는 이야기가 나오게 되는 것 같다.
아래는 검색하다 나온 자료로 이런 차이를 설명해주는 좋은 자료인 것 같다.
참고
https://khj93.tistory.com/entry/MQTT-MQTT%EC%9D%98-%EA%B0%9C%EB%85%90
https://www.cloudamqp.com/blog/what-is-message-queuing.html
https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=changbab&logNo=221565552533
'Framework > IOT | Aduino' 카테고리의 다른 글
| [IoT] Serial 통신에 대한 이해 및 주의 사항 (0) | 2022.04.06 |
|---|