이전 블로그 링크: https://velog.io/@chan9yu/mqtt-protocol-overview

서론

현재 재직 중인 회사에서는 PNS(Push Notification Server, Push Server)라는 서버가 있습니다. 이 PNS 서버는 사내 주요 서비스의 메시징 기능을 담당하고 있으며, 실시간 메시지 전송과 알림을 처리하는 중요한 역할을 하고 있습니다.

이렇게 핵심 기능인 PNS는 사실 MQTT 브로커의 구현체이며, MQTT 프로토콜을 사용하여 메시지를 주고받는 구조로 이루어져 있습니다.

이번 글에서는 실시간 메세지 전송의 기반이 되는 MQTT에 대해 정리해보고자 합니다.

MQTT란?

MQTT는 Message Queuing Telemetry Transport의 약자로, 원격 장치들 간의 데이터 전송을 위한 경량 메시징 프로토콜입니다.

1990년대 IBM과 Eurotech에 의해 개발되어, 원격 감시 시스템(telemetry) 및 산업용 장치의 데이터 수집을 효율적으로 처리하기 위해 만들어졌습니다.

석유, 가스 등의 대형 산업에서는 수많은 센서들이 다양한 데이터를 보내오는데, 중앙 시스템에서 이러한 데이터를 수집하고 관리하는 것은 매우 중요합니다. 이러한 통신 환경을 간소화하기 위해 MQTT가 설계되었습니다.

MQTT의 장점

그렇다면 왜 MQTT는 다양한 곳에서 사용되고 있을까요? 그 이유는 다음과 같은 주요 특징과 장점에 있습니다

• 저전력: 배터리로 작동하는 장치에서도 적은 전력으로 동작하도록 설계
• 비동기 메시징: Publisher와 Subscriber 간 비동기 통신을 지원해 실시간 메시지 전송이 가능
• 신뢰성: 다양한 QoS(Quality of Service) 레벨을 제공하여 메시지 전송의 신뢰성을 보장
• 경량성: 제한된 네트워크 환경에서도 원활히 동작할 수 있도록 프로토콜이 가볍게 설계됨
• 다양한 사용자와 장치 지원: 다양한 장치와 호환 가능
• 간단한 메커니즘: 매우 단순한 구조로 쉽게 구현 가능

MQTT의 역사

• 1990년대: IBM과 Eurotech가 MQTT를 설계
• 2004년: mqtt.org 사이트가 만들어지며, 커뮤니티가 형성됨
• 2012년: Eclipse 재단에서 Paho 프로젝트로 오픈소스화
• 2013년: OASIS에서 IoT의 표준 프로토콜로 채택

MQTT의 동작 원리

MQTT에서 클라이언트는 특정 Topic에 메시지를 Publish하거나 Subscribe하며, Broker는 이러한 메시지를 받아 구독한 다른 클라이언트에게 전달하는 중개 역할을 합니다.

Publish/Subscribe

MQTT는 Publish/Subscribe(발행/구독) 모델을 기반으로 동작합니다.

이 구조는 다음과 같이 요약할 수 있습니다

1. Publisher: 데이터를 생성하고 특정 Topic에 메시지를 발행하는 역할
2. Broker: Publisher가 보낸 메시지를 받아 적절한 Subscriber에게 전달하는 중개자 역할
3. Subscriber: 메시지를 받을 Topic를 브로커에 등록해 두고, 해당 Topic에 대한 메시지를 수신

💡 클라이언트와 브로커

• MQTT의 클라이언트는 Publisher와 Subscriber 역할을 동시에 수행할 수 있습니다.
• 클라이언트는 메시지를 발행하거나 구독하거나, 두 가지를 모두 할 수 있습니다.
• 브로커(Broker)는 클라이언트 간 메시지를 라우팅하고, 메시지 큐잉과 QoS 관리 등 MQTT 시스템에서 중추적인 역할을 담당합니다

Topic

MQTT에서 토픽(Topic)은 Publisher와 Subscriber 간 메시지 교환의 기준입니다. 클라이언트는 자신이 구독할 토픽을 지정하고, 해당 토픽의 메시지를 수신합니다.

토픽은 대소문자를 구분하는 UTF-8 문자열이며, /로 구분된 계층적 구조를 가집니다.

토픽의 특징

• UTF-8 인코딩
• 길이 1 이상의 문자열
• 대소문자 구분

예시: home/kitchen/fridge, vehicles/car/status

Topic Wildcard

MQTT는 와일드카드 기능을 통해 특정 주제 범위에 걸쳐 메시지를 받을 수 있습니다.

• +: 하나의 레벨에 대응하는 와일드카드 (예: foo/+/bar)
• #: 여러 레벨에 대응하는 와일드카드 (예: foo/#)
• $: $로 시작하는 토픽은 예약된 토픽으로, 애플리케이션에서는 사용하지 못함

Topic 필터 사용 예시

토픽 필터는 특정 패턴에 맞는 토픽을 구독하는 기능입니다.

QoS(Quality of Service) 레벨

MQTT는 메시지 전송의 신뢰성을 보장하기 위해 세 가지 QoS 레벨을 제공합니다

QoS 0 (At most once, 최대 한 번)

• 전송 실패 시 메시지를 잃을 수 있음
• 확인 응답 없이 메시지를 최대 한 번만 전송한다. (한 번만 전송한다)

QoS 1 (At least once, 최소 한 번)

• 메시지가 최소 한 번 이상 전송되며, 중복된 메시지가 수신될 가능성이 있음
• 응답(PUBACK)을 받지 못하면 재전송

QoS 2 (Exactly once, 정확히 한 번)

• 메시지가 정확히 한 번 전송되도록 보장
• 여러 단계의 확인 과정이 필요하여 네트워크 오버헤드가 증가하지만, 메시지 신뢰성이 극대화됨

QoS Downgrade 현상

QoS Downgrade는 MQTT 프로토콜에서 발생하는 현상으로, Publisher가 메시지를 높은 QoS로 전송하더라도, Subscriber가 낮은 QoS로 구독하면 메시지가 더 낮은 QoS로 전송되는 것을 말합니다.

즉, Publisher와 Subscriber가 서로 다른 QoS를 설정할 경우, 항상 더 낮은 QoS가 적용됩니다.

예를들면?

1. Publisher QoS 0 → Subscriber QoS 1 또는 2: 메시지가 QoS 0으로 전송
2. Publisher QoS 1 또는 2 → Subscriber QoS 0: 메시지가 QoS 0으로 전송
3. Publisher QoS 2 → Subscriber QoS 1: 메시지가 QoS 1으로 다운그레이드

💡 QoS Downgrade 현상은 메시지 신뢰성과 네트워크 부하 간의 균형을 맞추기 위한 설계입니다.

Last Will 메시지

LWT(Last Will and Testament)

클라이언트가 비정상적으로 연결이 끊어졌을 때, 미리 설정된 "유언 메시지"가 브로커를 통해 다른 구독자에게 발송됩니다.

이를 통해 클라이언트의 상태를 추적하거나 긴급 상황을 알릴 수 있습니다. 장치 상태 모니터링이나 장애 알림에 매우 유용한 기능입니다.

MQTT의 실제 사용 사례

MQTT는 다양한 산업 분야에서 널리 사용되고 있습니다.

대표적인 사례

• Facebook Messenger: 2011년에 MQTT를 도입하여, 기존에 비해 네트워크 대역폭과 배터리 소모량을 크게 절감
• AWS IoT, Azure IoT Hub, Google Cloud IoT: 대형 클라우드 서비스 제공업체들도 MQTT를 채택하여 IoT 장치 간의 효율적인 통신을 지원
• 스마트홈, 산업용 센서 네트워크, 실시간 알림 서비스 등

대표적인 MQTT 브로커들

• Mosquitto: 경량 브로커로, 다양한 플랫폼에서 실행 가능, 범용성 높음
• EMQX: 고성능 브로커로, 클러스터링과 멀티 프로토콜 지원
• HiveMQ: 대규모 IoT 솔루션에 적합한 상용 브로커
• Aedes: Node.js 기반의 경량 MQTT 브로커

MQTT의 한계 및 보완점

주요 한계점

• 브로커 의존성: 브로커가 중단되면 전체 메시징 시스템에 영향을 미칠 수 있음
• 보안 이슈: 기본적으로 MQTT는 보안 기능을 제공하지 않음
• 확장성: 단일 브로커에 의존하기 때문에 대규모 시스템에서는 제약이 있음

보완 방법

• 브로커 클러스터링: 고가용성 확보
• TLS 보안 설정: 데이터 암호화 및 인증
• 분산 시스템 구조: 확장성 문제 해결

정리

MQTT는 경량 메시징 프로토콜로, 저전력 및 제한된 네트워크 환경에서 효율적으로 작동하며, 주로 IoT 장치 간 실시간 데이터 전송에 사용됩니다.

핵심 특징

• Publish/Subscribe 모델 기반으로 동작
• Topic 기반 메시지 라우팅
• QoS 레벨을 통한 신뢰성 보장
• LWT 기능으로 장애 상황 대응

한계점과 보완

• 브로커 의존성, 기본 보안 기능 부재, 확장성 문제가 존재
• TLS 보안 설정 및 브로커 클러스터링을 통해 보완 필요

정리하자면 MQTT는 IoT와 실시간 메시징에서 정말 유용한 프로토콜입니다.