MQTT로 개발하는 것이 무조건 좋은 것인가?

본 글은 2016년 3월 29일 17시 28분에 썼던 글이며 블로그 자료 이전으로 날짜와 일부 내용이 갱신되었습니다.

현재(2020년 10월 14일)의 MQTT시장과는 상황이 전혀 다릅니다. MQTT를 써야한다면 쓰면 됩니다.

MQTT 프로토콜이 적합한 경우

환경과 시나리오, 준비된 기술에 따라서 적합한 프로토콜이 있다. MQTT의 경우 1999년 네트워크의 신뢰성이 낮고 연산과 처리속도, 메모리가 극히 제한적인 상황을 고려해서 설계가 되었기에 2016년 현재 이러한 특징을 살릴 수 있는 상황이 아니라면 MQTT가 큰 의미는 없을 수 있다.

예를 들어 사용할 수 있는 네트워크의 단위 시간당 처리량이 크고 패킷 이용로가 아주 저렴할 때 IoT 장비가 이 네트워크를 사용해서 한달동안 100MB의 패킷을 절약할 수 있다면 이것이 큰 의미가 있을까? 아래의 실험 결과가 그 예이다.

실험 결과(출처: 안정적인 사물인터넷 플랫폼을 위한 MQTT 프로토콜 기반 데이터 수집 솔루션에 관한 연구)

온도와 습도 정보를 1대의 아두이노가 유니캐스트로 보낼 때의 실험 결과이다. 패킷 크기는 MQTT가 HTTP보다 절약이 된다. 로컬 네트워크의 경우를 생각한다면 단위시간당 처리량이 굉장히 클 것이고 회선 사용료는 없을테니 큰 의미가 없는 수치라고 판단할 수 있다. 또한 전력원이 제한적인 경우가 아니라면 패킷의 양을 줄여서 배터리를 적게 소모하고자 하는 의미도 없어진다. 또한 단순히 패킷이 절약된 만큼 배터리 사용이 적을것이라고 추정할 수 있으나 관련 실험결과를 보면 배터리 소모가 이동통신망, 와이파이, 이더넷 등 상황에 따라서 HTTP가 더 적은 경우도 있다.

MQTT 로고

 

MQTT 관련 산업계 현황

현재 업계는 MQTT를 스마트폰의 푸시메시지에 주로 이용하고 있으며 다양한 분야에 접목을 시도 하고 있다. 하지만 무료 MQTT 서버 중 서버로써 신뢰성이 검증된 것은 전무한 실정이며 상용 MQTT 서버는 비용이 만만치 않은 문제가 있어서 작은 회사나 개인이 사용하기엔 부담스러운 상황이다. [1] 2월에 공개된 한 실험결과에 의하면 무료 MQTT 서버인 MQTT Mosquitto Broker는 센싱 데이터를 1,024개 이상(Publish/Subscribe 각 512개) 동시에 처리하면 에러가 발생하기 시작했으며 이와 대조적으로 HTTP Web Server는 센싱데이터를 에러 없이 약 700개까지 처리하는 것이 가능했다고 한다. 상황에 적합하게 프로토콜을 도입하여도 이런 식으로 프로그램이 불안정하면 제대로된 상용 서비스를 할 수가 없다.

 

결론

아직까지는 개발인력이 충분하고 기술력이 있는 회사가 아닌 이상 MQTT 기반의 프로그램을 제작하는건 어렵다고 생각한다. 메시징을 MQTT로 전환한 대표적인 사례로 페이스북이 있는 것을 보고 MQTT 도입을 고민하고 있는 사람이 있다면 (과장된 표현이지만) 페이스북처럼 세계 일류의 기술력 및 개발진을 가지고 있는지 고민을 해봐야할 것 같다. 현재 상황에서는 처음부터 MQTT기반으로 개발하는 것보다는 다른 검증된 것을 활용하는 것이 좋은 방향으로 판단된다. 차후에 서비스의 설계 및 품질이 어느 정도 성숙했고 개발인력이 충분하다면 MQTT가 꼭 필요한 상황이 도래했을 때 전환을 고려하면 될 것이다.

 

참고문서

[1] 박현주, "안정적인 사물인터넷 플랫폼을 위한 MQTT 프로토콜 기반 데이터 수집 솔루션에 관한 연구", 한국정보통신학회논문지, 2016년 2월. @원문보기

[2] "MQTT Specification", MQTT 홈페이지. @원문보기