MQTT란
- MQTT (Message Queuing Telemetry Transport)는 경량의 메시지 전송 프로토콜로, IoT(사물 인터넷) 장치와 애플리케이션 간의 통신을 위해 설계되었습니다. MQTT는 최소한의 네트워크 대역폭과 리소스를 사용하여, 저전력 장치에서도 효율적으로 작동할 수 있습니다.
- 사물 통신(M2M: Machine to Machine), 사물 인터넷(IoT: Internet of Things)과 같이 대역폭이 제한된 통신 환경에 최적화하여 개발된 푸시 기술(push technology) 기반의 경량 메시지 전송 프로토콜입니다.
- 게시/구독 모델의 원칙을 기반으로 작동합니다.
왜 MQTT를 사용하는가?
- 저전력 및 저대역폭 환경에 적합: MQTT는 매우 가벼운 프로토콜로, 네트워크 대역폭과 전력을 적게 소모합니다. 따라서 배터리로 작동하는 IoT 장치나 제한된 네트워크 환경에서도 효과적으로 사용될 수 있습니다.
- 단순성: MQTT는 비교적 단순한 프로토콜로, 구현과 유지보수가 쉽습니다. 이는 개발자들이 빠르게 학습하고 사용할 수 있도록 돕습니다.
- 확장성: 수천 개의 장치가 동시에 연결되어 통신할 수 있도록 설계되었습니다. 이는 대규모 IoT 네트워크를 구축할 때 매우 유리합니다.
- 신뢰성: 다양한 품질 수준(QoS, Quality of Service)을 제공하여, 메시지가 안전하게 전송되고 수신될 수 있도록 보장합니다.
동작 원리
- 기본 동작 원리
- MQTT 프로토콜은 푸시 기술(push technology)에서 일반적으로 사용되는 클라이언트/서버 방식 대신, 메시지 매개자(broker)를 통해 송신자가 특정 메시지를 발행(publish)하고 수신자가 메시지를 구독(subscribe)하는 방식을 사용한다. 즉, 매개자(broker)를 통해 메시지가 송수신된다.
Broker(중개인) / Publisher(발행자) / Subscriber(구독자)
- Broker란 Publisher와 Subscriber 사이에 메시지를 관리하여 전송해주는 중앙 관리자이다.
- Publishr(발행자)는 특정 Topic(화제)을 통해 Broker(중개인)에 메시지를 전송한다. Broker는 Publishr가 발행한 Topic을 가지고 있고 Subscriber(구독자)는 Topic 기준으로 Broker에 구독을 요청한다. Subscriber의 polling(주기적인 체크) 방식을 이용하여 Broker에 있는 Topic을 조회해 간다.
- 해석
- 송신자 / Publisher(발행자) : 유튜버
- 메시지 브로커 : youtube
- 수신자 / Subscriber(구독자) : 유튜버 채널 구독자
- topic : 유튜브 채널
- data : 유튜브 채널에서 올린 영상 등
MQTT의 핵심 기능
- 게시/구독 모델(Publish/Subscribe Model):
- 발행(Publish): 데이터 생산자가 특정 주제(topic)에 메시지를 보냅니다.
- 구독(Subscribe): 데이터 소비자가 관심 있는 주제를 구독하고, 해당 주제에 메시지가 발행되면 이를 수신합니다.
- 메시지 유지(QoS Levels):
- QoS 0: "최소한의 한 번 전달(At most once)" - 메시지가 한 번만 전달되거나, 혹은 전혀 전달되지 않을 수 있습니다.
- QoS 1: "최소 한 번 전달(At least once)" - 메시지가 적어도 한 번은 전달됩니다.
- QoS 2: "정확히 한 번 전달(Exactly once)" - 메시지가 정확히 한 번 전달되도록 보장됩니다.
- 지속 세션(Persistent Sessions):
- 클라이언트가 연결이 끊어진 후에도 서버가 클라이언트의 구독 정보를 유지하여, 재연결 시 기존 세션을 계속할 수 있습니다.
QOS
QoS(Quality of Service)란 서비스의 질을 보장해주는 레벨을 말한다. 서비스의 종류에 따라서 적당한 QoS 레벨을 선택해야 한다.
Level 0 (At most Once / ”최대 한 번”)
- 가장 낮은 수준의 보장 서비스로 메세지는 딱 한번 전송되며 클라이언트에게 전달 여부를 확인하지 않고 바로 잊어버린다.
- “Fire and Forget” 타입이라고도 하며, 전달 여부를 확인하지 않고 딱 한번 메세지를 전송하므로 전송 퀄리티 보장 정도는 낮지만 가장 빠른 전송 레벨이다.
Level 1 (At least Once / ”적어도 한 번”)
- 중간 수준의 서비스로 메세지가 적어도 한 번은 클라이언트 측으로 전달되도록 보장한다. 이는 전달 여부를 확인해 메세지가 정상적으로 전달되지 못 했으면 다시 메세지를 보내기 위해 시도한다.
- 하지만 메세지가 중복될 수 있으며 메세지가 도착한다는 보장은 있지만 한 번만 도착한다는 보장은 없다.
Level 2 (Exactly Once / ”정확히 한 번”)
- 가장 높은 수준의 보장 서비스로 각 메세지가 의도한 클라이언트에게 한 번만 정확히 수신되도록 한다. 메세지의 핸드셰이킹 과정을 추적하며 가장 안전하고 퀄리티를 보장하지만 반대로 가장 느린 전송 레벨이다.
MQTT 설치 및 테스트
궁금한 사항
MQTT vs HTTP
| MQTT | HTTP | |
|---|---|---|
| 목적과 사용 사례 | IoT 장치 및 저전력 환경에 최적화 | 웹 애플리케이션과 서버 간의 데이터 전송에 사용 |
| 전송 모델 | 발행/구독(Publish/Subscribe) | 요청/응답(Request/Response) |
| 프로토콜 오버헤드 | 매우 적음 | 높음 |
| QoS 및 연결 유지 | 다양한 QoS 수준, 지속 세션, 유지 메시지 등 제공 | QoS 없음, 상태 비저장 프로토콜 |
| 보안 | TLS를 통한 보안 통신 | HTTPS를 통해 보안 통신 |
왜 MQTT는 브로커를 이용해 송수신을 하는 것일까?
- IoT에는 여러 센서 종류들이 있는데, 이 각 센서들이 클라이언트의 역할을 수행
- 만약 센서들이 엄청 많을 때, 각 클라이언트들끼리 직접 통신을 하려고 하면 네트워크 복잡성이 커질 위험성이 존재
- 메시지 브로커가 존재하면 이 위험성이 떨어짐
- 직접 클라이언트들끼리 통신하게 된다면?
- 네트워크 복잡성 증가
- 브로커의 역할
- 중앙 집중식 연결 관리:
- 모든 센서(클라이언트)는 브로커와만 연결합니다. 이를 통해 각 센서가 다른 모든 센서와 직접 연결할 필요가 없어집니다.
- 효율적인 메시지 라우팅:
- 브로커는 센서로부터 받은 데이터를 적절한 수신자에게 전달합니다. 이는 주제 기반 발행/구독 모델을 통해 이루어집니다.
- 예를 들어, 온도 센서가 온도 데이터를 발행하면, 온도 데이터를 구독한 모든 클라이언트가 이를 받을 수 있습니다.
- 확장성:
- 브로커를 통해 다수의 센서가 동시에 통신할 수 있어, 센서의 수가 증가해도 네트워크의 복잡성이 상대적으로 낮게 유지됩니다.
- 메시지 보존 및 신뢰성:
- 브로커는 클라이언트가 일시적으로 오프라인 상태일 때도 메시지를 보존하고, 클라이언트가 다시 온라인 상태가 되면 메시지를 전달할 수 있습니다.
- 다양한 QoS 수준을 통해 메시지의 신뢰성 있는 전달을 보장합니다.
- 보안:
- 브로커는 중앙에서 인증 및 암호화를 관리할 수 있어, 네트워크의 보안 수준을 높일 수 있습니다.
- 중앙 집중식 연결 관리:
참고
#Software Engineer #IRISH