MQTT 및 CoAP는 폭발적으로 성장하는 IoT 시장을 위한 주요 경량 메시징 프로토콜로서 빠르게 부상하고 있다. 각각의 프로토콜은 고유의 장점을 가지고 있으며, 각기 다른 과제와 트레이드오프를 제기한다. 두 프로토콜은 모두 경량 최종 노드를 거의 모든 네트워크에서 필수적으로 요구되는 메쉬형 네트워킹 애플리케이션과 표준간의 통신을 가능하게 하는 게이트웨이 브리징 로직으로 구현하고 있다.
조지 워싱턴 대학(George Washington University)의 필립 하워드(Philip N. Howard)는 최근 발표한 기고문에서 2014년에 이미 커넥티드(connected) 기기의 수가 세계 인구 수를 넘어섰다고 추정하면서 2020년에는 500억 개에 달하는 기기들이 서로 연결되는 사물 인터넷(IoT) 시대를 맞이하게 될 것이라고 전망했다.
달리 말하면, 사람들이 끊임없이 점점 더 많은 기기를 인터넷에 연결함에 따라 지금껏 연결된 적이 없거나 존재하지 않았던 또는 이제 그러한 연결을 핵심 기능으로 사용하는 인터넷에 연결되는 ‘사물’들의 폭발적인 성장이 다가오는 시대가 열리고 있다는 것이다. 이제 문제는 ‘이렇게 연결된 수십 억개의 사물이 어떻게 최종 노드와 클라우드, 그리고 서비스 제공업체들 사이에서 정보를 교환할 할 것인가 ’이다.
이 글에서는 이러한 주제를 배터리로 구동하면서 수동적인 개입(배터리 교체 등) 없이 최소 7년 간 동작할 수 있는 특정 유형의 연결된 기기와 관련지어 살펴볼 것이다.
특히 이러한 ‘경량화된’ IoT 노드의 수요에 대처하기 위해 근래에 부상하고 있는 두 가지 메시징 프로토콜을 집중적으로 다루기로 한다.
첫 번째 프로토콜은 MQTT(Message Queuing Telemetry Transport)로서 오늘날 기준으로 보면 오래되었다고 볼 수 있다. 프로토콜 자체는 1999년으로 거슬러 올라간다. 두 번째는 비교적 최근에 개발되고 주목을 받고 있는 CoAP(Constrained Application Protocol)이다.
▲ 그림 1. 필립 하워드의 최근 연구에 따르면, 현재 연결된 기기 수는
세계 인구 수를 넘어섰다
IoT 통신 프로토콜 요구사항
IoT는 이전에 연결되지 않았던 인터넷에 기기를 연결하는 것을 말한다. 예를 들어 공장 소유주는 디지털 조명을 연결할 수 있으며, 3종 경기 선수는 배터리로 구동되는 심박 측정기를 연결할 수 있다. 홈 또는 빌딩 자동화 제공업체들은 배터리 구동 무선 센서 노드를 연결할 수 있다. 여기서 중요한 점은 이러한 모든 사용 용도에서 ‘사물’은 ‘IoT’ 노드로 간주되는 인터넷을 통해 통신해야 한다는 것이다.
연결된 기기는 인터넷을 사용해야 하므로 IETF(Internet Engineering Task Force)에서 제정한 인터넷 프로토콜 수트를 따라야 한다(표 1). 그러나 인터넷은 전통적으로 많은 전력과 메모리, 연결 옵션을 갖는 리소스가 풍부한 기기들을 연결해 왔다. 그와 같은 프로토콜은 떠오르는 IoT에서 전반적으로 애플리케이션에 적용하기에는 너무 무겁다.
▲ 표 1. 인터넷 프로토콜 수트는 애플리케이션, 트랜스포트 및
인터넷 계층을 포괄한다
IoT의 또 다른 측면들이 IETF의 작업에 새로운 전환을 요구하고 있다. 특히 IoT 최종 노드 네트워크는 손실이 많으며, 이러한 네트워크에 연결되는 기기들은 매우 적은 전력을 사용하면서 제한된 리소스를 갖고 있고 장시간 사용 수명을 기대한다.
네트워크와 최종 디바이스를 모두 포괄하는 요구사항은 아래의 표 2와 비슷할 것이다. 이러한 새로운 모델은 많은 양의 리소스를 요구하지 않는 새롭고 더 가벼운 프로토콜을 필요로 한다. MQTT 및 CoAP는 작은 메시지 크기, 메시지 관리 및 경량 메시지 오버헤드를 통해 이러한 요구를 충족한다. 표 2는 핵심적인 요구사항을 요약한 것이다.
▲ 표 2. 저가형, 전력이 제한된 기기와 관련 네트워크는 다양한 요구사항을 갖는다
MQTT 및 CoAP … 경량 IoT 통신 프로토콜
MQTT와 CoAP는 인터넷에 기반의 풍부한 리소스를 가진 디바이스로부터 IoT 기반의 제한된 리소스를 가진 디바이스로 통신을 지원한다.
CoAP와 MQTT는 모두 경량 애플리케이션 계층을 구현하며, 에러 보정의 많은 부분은 메시지 재시도, 간단한 신뢰성 전략에 넘기거나 최종 노드의 원데이터에 대한 후처리를 리소스가 더 풍부한 기기에 맡긴다. 자세한 내용은 그림 2를 참조할 수 있다.
▲ 그림 2. MQTT 및 CoAP는 클라우드와 스마트폰에 대한 통신을 지원한다
1. MQTT 개요
IBM은 유전 장비와의 위성 통신을 위해 MQTT를 개발했다. MQTT는 기본적으로 신뢰성과 저전력을 특징으로 하므로 IoT 네트워크에 적용하기 적합하다.
그 후 MQTT 표준은 개방형 표준을 위한 단체인 OASIS 에 의해 채택되었으며 버전 3.1.1로 발표되었다. 또한 오픈 소스 스택과 컨설팅을 제공하는 많은 상업 회사와 이클립스(Eclipse) 커뮤니티 내의 지원을 받고 있다.
MQTT는 ‘publish/subscribe’ 모델을 사용하며, MQTT 네트워크 노드 간에 메시지를 관리하고 라우팅하기 위해 중앙 MQTT 브로커(broker)를 필요로 한다. 이클립스는 MQTT를 중앙 브로커를 통해 다중 클라이언트 간에 메시지를 전달하는 ‘다대다(many-to-many)’ 통신 프로토콜로 설명하고 있다. MQTT는 TCP를 사용하여 ‘고신뢰성, 정렬, 에러 검사’를 특징으로 하는 트랜스포트 계층을 구현한다.
2. MQTT의 강점
(1) Publish/Subscribe 모델
MQTT의 ‘pub/sub’ 모델은 확장성이 뛰어나고 전력 효율적이다. 브로커와 노드는 정보를 발행하며, 다른 노드들은 메시지 내용, 종류 또는 주제에 따라 구독한다. 이들 용어는 MQTT 표준 용어이다. 일반적으로 브로커는 모든 메시지를 구독한 다음 각 노드에 대한 정보 흐름을 관리한다. publish/subscribe 모델에는 몇 가지 뚜렷한 장점이 있다.
(2) 공간 분리
노드와 브로커는 서로의 IP 주소를 가질 필요가 있지만, 노드는 정보를 발행할 수 있으며, 모든 것이 중앙 브로커를 거쳐 진행되기 때문에 서로를 전혀 모르고 있어도 다른 노드에서 발행하는 정보를 구독할 수 있다. 이는 TCP 세션과 포트에 수반될 수 있는 오버헤드를 감소시키고 최종 노드가 서로에 대해 독립적으로 동작할 수 있게 한다.
(3) 시간 분리
노드는 다른 노드의 상태와 관계없이 정보를 발행할 수 있다. 그 후에 활성화될 때 다른 노드는 브로커로부터 발행된 정보를 수신할 수 있다. 이를 통해 다른 노드가 해당 노드에 직접 관련된 메시지를 발행할 때조차 노드가 휴면 상태를 유지할 수 있게 한다.
(4) 동기화 분리
동작 중인 노드는 구독 중인 메시지가 발행되더라도 이를 수신하도록 인터럽트되지 않으며, 메시지는 수신 노드가 기존 동작을 완료할 때까지 브로커에 의해 대기열에 저장된다. 이는 진행 중인 동작 또는 휴면 상태에 대한 인터럽트를 피함으로써 동작 전류를 절약하고 반복되는 동작을 줄여준다.
(5) 보안
MQTT는 새롭게 개발된 보안 형식은 아니며, 암호화되지 않은 TCP를 사용한다. TCP를 사용하는 이유는 TLS/SSL 인터넷 보안을 사용할 수 있기 때문이다. 그러나 TLS는 필요한 핸드셰이크와 증가되는 패킷 오버헤드로 인해 경량화된 클라이언트에게 리소스 집약적이다. 에너지가 매우 높은 우선순위를 가지고 있고 보안이 훨씬 덜 중요한 네트워크의 경우 패킷 페이로드 암호화만으로 충분할 수 있다.
(6) MQTT 서비스 품질 단계
‘서비스 품질(QoS, Quality of Service)’이라는 용어는 MQTT 밖에서는 다른 것을 의미한다. MQTT에서 ‘QoS’는 0, 1, 2 단계가 있으며, 메시지 전달 보장이 증가되는 수준을 가리킨다.
(7) MQTT QoS 0
흔히 ‘Fire and forget’이라고 하며, 단 한 번의 전송으로 끝나므로 메시지 도착을 보장하지 않는다. 매우 반복적인 메시지 유형이나 업무에 중요하지 않은 메시지에 사용할 수 있다.
(8) MQTT QoS 1
이 단계는 메시지가 의도된 수신자에 의해 최소 한 번 수신되는 것을 보장한다. 발행된 메시지가 수신되고 의도된 수신자에 의해 이해되면, 발행 노드로 보내는 확인 메시지(PUBACK)를 통해 메시지의 수신을 확인한다. 발행자가 PUBACK를 수신할 때까지 메시지가 저장되고 정기적으로 재발송된다. 이러한 종류의 메시지는 중요하지 않은 노드 셧다운에 유용할 수 있다.
(9) MQTT QoS 2
이 단계는 의도된 수신자에 의해 메시지가 수신되고 해독되는 것을 보장한다. 이 단계는 가장 높은 보안의 신뢰할 수 있는 MQTT QoS 단계이다. 발행자는 메시지를 전송하면서 QoS 2 메시지를 갖고 있다는 것을 알린다. 의도된 수신자는 알림을 수집하고, 이를 해독한 다음, 메시지를 수신할 준비가 되었다는 것을 나타낸다. 발행자는 메시지를 중계한다. 수신지가 메시지를 이해하면, 수신 확인을 이용해 트랜잭션을 완료한다. 이러한 종류의 메시지는 가정에서 조명 또는 경보를 켜거나 끄는 용도에 활용할 수 있다.
(10) LWT
MQTT는 노드가 예기치 않게 네트워크로부터 연결이 끊어지는 경우 MQTT 브로커에 저장할 수 있는 ‘LWT(last will and testament)’ 메시지를 제공한다. 이 LWT는 발행하고 구독된 명령의 종류를 포함하여 노드의 상태와 목적을 보유한다.
노드가 사라지면, 브로커는 모든 구독자에게 노드의 LWT를 통지한다. 노드가 되돌아오면, 브로커는 노드에게 이전 상태를 통지한다. 이 기능은 손실이 많은 네트워크와 확장성을 수용하기에 적합하다.
(11) 토픽 구독
MQTT 노드는 주어진 기능 안에서 모든 메시지를 구독할 수 있다. 예를 들어 ‘키친 오븐 노드(kitchen oven node)’는 와일드카드로서 ‘+’와 함께 ‘kitchen/oven/+’에 대한 모든 메시지를 구독할 수 있다. 이는 최소한의 코드(메모리 및 비용)를 사용할 수 있게 한다.
또 다른 예로, 만약 키친 안의 노드가 최종 노드의 기능과 관계없이 모든 온도 정보에 관심을 갖고 있다면, ‘kitchen/+/temp’는 ‘temp’를 보고하는 모든 노드로부터 키친 안의 모든 메시지를 수집한다. MQTT 와일드카드는 코드 풋프린트를 줄이고, 그에 따라 메모리 크기와 비용을 줄일 수 있어 매우 유용하다.
3. MQTT의 문제점
(1) 중앙 브로커
중앙 브로커를 이용하는 것은 분산화된 환경의 IoT 시스템에는 단점이 될 수 있다. 예를 들어 시스템은 리모트컨트롤과 윈도우 셰이드만 갖추고 작게 시작할 수 있으며, 이때 중앙 브로커는 필요하지 않다. 그런 후 보안 센서나 전등 또는 기타 다른 윈도우 셰이드를 추가하면서 시스템이 확대되면 네트워크는 자연적으로 확장하며 중앙 브로커가 필요할 수 있다.
그러나 어떤 개별 노드도 최종 노드 기능에는 핵심적이지 않은 리소스와 소프트웨어, 복잡성을 요구하는 비용과 책임을 맡고 싶어 하지 않는다.
이미 중앙 브로커가 있는 시스템의 경우, 중앙 브로커는 완벽한 네트워크에 고장이 발생할 수 있는 단일 지점이 될 수 있다. 예를 들어 만약 브로커가 배터리 백업 없이 구동되는 노드라면, 전기 공급이 끊기는 경우 배터리로 구동되는 노드들은 계속 동작할 수 있는 반면, 브로커는 오프라인에 있게 되므로, 네트워크는 제대로 동작할 수 없게 된다.
(2) TCP
TCP는 원래 많은 메모리와 프로세싱 리소스를 갖는 기기를 위해 설계되었다. 따라서 경량 IoT 방식의 네트워크에서 사용하기에는 적합하지 않다.
TCP 프로토콜은 메시지를 교환하기 전에 다중 단계의 핸드셰이크 과정을 통해 연결을 맺어야 한다. 이러한 방식은 웨이크업 시간과 통신 시간을 늘리고, 장기적으로 배터리 수명을 단축시킨다.
또한 TCP에서는 두 통신 노드가 지속적 세션에서 연속적으로 서로에 대해 TCP 소켓을 개방하는 것이 이상적이다. 이러한 특성은 에너지와 리소스가 제한된 디바이스에는 적용하기 어려울 수 있다.
(3) 웨이크업 시간
세션의 지속 없이 TCP를 사용하는 것은 연결을 맺는 데 증가되는 전송 시간을 필요로 할 수 있다. 정기적, 반복적 트래픽을 갖는 노드의 경우 이는 동작 수명을 줄일 수 있다.
4. CoAP 개요
IoT의 중요성이 증가하면서 IETF는 경량 메시징을 위한 CoAP를 정의했다. IETF의 정의에 따르면, CoAP는 ‘제한된 노드와 제한된(즉, 저전력의 손실이 많은) 네트워크’를 위한 것이다. 이클립스(Eclipse) 커뮤니티에서도 MQTT와 마찬가지로 CoAP를 공개 표준으로 지원하고 있다. CoAP는 상용적으로 지원되며, IoT 제공업체들과 함께 빠르게 성장하고 있다.
CoAP는 클라이언트/서버 프로토콜이며, 일대일(1:1) ‘요청/보고’ 인터랙티브 모델을 제공한다. 또한 아직 IETF 표준화의 초기 단계에 있지만 멀티캐스트를 지원한다. 십여 년 전 개발된 프로토콜로부터 IoT의 요구에 맞추어 개조된 MQTT와 달리 CoAP는 IETF가 처음부터 제한된 환경에서 동작하는 제한된 기기의 경량 메시징의 IoT를 지원하기 위해 만들어졌다. CoAP는 간단한 프록시를 통해 HTTP와 RESTful 웹과 상호 운용되도록 설계되어 있어 본질적으로 인터넷에 적합하다.
5. CoAP의 강점
(1) 네이티브 UDP
CoAP는 기본적으로, 그리고 의도적으로 TCP보다 신뢰성이 낮은 UDP에서 실행되며, 일관된 연결 대신 반복적 메시징에 의존해 신뢰성을 제공한다. 예를 들어 온도 센서는 온도 변화가 없어도 한 전송에서 다음 전송으로 수 초마다 업데이트 정보를 보낼 수 있다. 수신 노드가 하나의 업데이트를 놓치더라도 다음 업데이트가 수 초 이내에 도착하며 이 업데이트는 첫 번째 업데이트보다 많이 다르지 않을 것이다. UDP의 비연결 데이터그램은 더 적은 오버헤드와 더 작은 패킷, 그리고 보다 빠른 웨이크업과 전송 사이클을 실행할 수 있게 한다. 따라서 디바이스가 보다 오랫동안 휴면 상태를 유지할 수 있으므로 배터리 전력을 절약할 수 있다.
(2) 멀티캐스트 지원
CoAP 네트워크는 기본적으로 일대일 방식이지만, 일대다 또는 다대다 멀티캐스트 요구사항을 지원한다. CoAP 네트워크는 IPv6 위에 구축되기 때문에 멀티캐스트는 CoAP 내에 본질적으로 내재한다고 볼 수 있다. 따라서 일반 IPv6 주소뿐 아니라 디바이스를 위한 멀티캐스트 주소 지정이 가능하다. 그러나 휴면 상태의 디바이스에 전달되는 멀티캐스트 메시지는 신뢰할 수 없거나, 이러한 메시지를 수신하기 위해 정기적으로 웨이크업이 발생한다면 디바이스의 배터리 수명에 영향을 미칠 수 있다.
(3) 보안
CoAP는 UDP 전송 프로토콜 상에서 DTLS를 사용한다. TCP와 마찬가지로 UDP는 암호화되지 않지만 DTLS를 이용할 수 있으며, 이를 이용해 보안을 강화해야 한다.
(4) 리소스 & 서비스 검색
CoAP는 URI를 사용하여 네트워크 노드를 위한 표준을 제시하고 상호작용을 기대한다. 타겟 노드의 기능이 URI 세부사항에 의해 부분적으로 이해되기 때문에 이것은 메시지 패킷에 어느 정도의 자율을 허용한다. 달리 말하면, 배터리 구동 센서 노드는 한 종류의 URI를 가질 수 있으며, 라인 구동 흐름 제어 액추에이터는 다른 종류의 URI를 가질 수 있다.
배터리 구동 센서 노드와 통신하는 노드는 더 긴 응답 시간, 더 많은 반복 정보, 제한된 메시지 유형을 기대하도록 프로그래밍할 수 있으며, 라인 구동 흐름 제어 액추에이터와 통신하는 노드는 풍부하고 상세한 메시지를 매우 신속히 기대하도록 프로그래밍할 수 있다.
(5) 비동기식 통신
CoAP 프로토콜 내에서 대부분의 메시지는 요청/보고 모델을 사용하여 송수신되지만, 노드를 조금 떨어뜨려놓을 수 있는 다른 동작 모드도 있다. 예를 들면 CoAP는 MQTT의 pub/sub와 유사하면서 단순한 ‘observe’ 방식을 제공한다. 이 모드에서는 노드가 실제로 참여하지 않으면서 다른 노드를 관찰할 수 있다.
‘observe’ 모드의 한 예로, 노드 1은 특정 전송 유형에 대해 노드 2를 관찰할 수 있으며, 그런 후에 노드 2가 관련 메시지를 발행하면 언제라도 노드 1은 다른 노드를 깨우고 조회하면서 그 메시지를 수신한다.
중요한 점은 네트워크 노드 중 하나는 반드시 옵저버 (observer)를 위한 메시지를 보유하고 있어야 한다는 것이다. 이러한 특성은 MQTT의 브로커 모델과 유사하지만, CoAP에는 브로커 요구사항이 없다는 점이 다르다. 따라서 이 모드가 아닌 경우 옵저버를 위한 메시지를 보유하거나 대기열에 저장하기를 기대할 수 없다.
현재 표준에 추가될 초안이 나와 있으며, 중단기에 걸쳐 MQTT의 pub/sub 모델과 유사한 CoAP 기능을 제공한다는 내용을 포함하고 있다. 현재 유력한 후보는 마이클 코스터(Michael Koster)에 의해 제안된 초안으로, CoAP 네트워크에서 MQTT의 앞서 언급한 것과 같은 pub/sub 모델을 구현할 수 있게 하는 것이다.
6. CoAP의 문제점
(1) 표준 성숙도
현재 MQTT는 CoAP보다 성숙되고 안정적인 표준이다. 많은 IoT 개발업체들은 CoAP를 사용하는 유사한 네트워크보다 더 쉽게 MQTT 네트워크를 구축하고 매우 빠르게 실행할 수 있다. 즉, CoAP는 엄청난 시장 모멘텀을 가지고 빠르게 발전하고 있어 현재 비준 단체(ratification pipeline) 에서 중요한 추가 조치가 이루어지면 표준화된 기반을 제공할 수 있을 것으로 내다보고 있다. 매우 가까운 시기에 CoAP는 MQTT와 유사한 수준의 안정도와 성숙도를 달성할 수 있을 것으로 보인다. 그러나 이 표준은 현재 발전하고 있는 중이며, 상호운용성 측면에서 몇 가지 과제를 제기한다.
(2) 메시지 신뢰성
CoAP의 신뢰성은 MQTT의 QoS에 해당된다. CoAP는 ‘확인형(confirmable)’ 메시지와 ‘비확인형(non-confirmable)’ 메시지를 갖는 매우 간단한 방법을 제공한다. 확인형 메시지는 의도된 수신자로부터 확인 메시지(ACK)를 통해 수신을 확인 받는다. 이는 메시지가 수신되었다는 것을 확인하며, 내용이 올바르게 해독되었는지 여부를 확인할 수 없는 경우 전송을 멈춘다. 비확인형 메시지는 ‘fire and forget’ 방식이다.
☆
MQTT 및 CoAP는 폭발적으로 성장하는 IoT 시장을 위한 주요 경량 메시징 프로토콜로서 빠르게 부상하고 있다. 각각의 프로토콜은 고유의 장점을 가지고 있으며, 각기 다른 과제와 트레이드오프를 제기한다.
두 프로토콜은 모두 경량 최종 노드가 거의 모든 네트워크에서 필수적으로 요구되는 메쉬형 네트워킹 애플리케이션과 표준간 통신을 가능하게 하는 게이트웨이 브리징 로직에서 구현되고 있다.
제임스 스탠스베리 _ 실리콘랩스
