SMS와 HTTP를 걷어낸 신규 단말의 MQTT와 AWS IoT Core (2022-01)

구형 단말의 SMS 제어와 HTTP 수집

쏘카는 서비스 초기부터 차량에 단말을 달아 상태 정보를 모으고 차량을 제어해 왔습니다. 원문은 이를 구형 단말이라 부릅니다. 개발 당시에는 운영에 맞는 기술이 마땅치 않아, 제어는 단말의 고유번호인 전화번호로 SMS를 보내 처리했고 데이터는 웹서버로 HTTP 전송했습니다.

문제는 세 가지였습니다. SMS는 명령이 단말에 닿는 데 시간이 오래 걸리고, 서울에서 멀수록 더 걸리는 경향이 있었습니다. HTTP 수집에는 웹서버가 따로 필요했습니다. 요청이 몰려 서버에 부하가 걸리면 수집이 늦어졌습니다.

신규 단말의 요구사항과 MQTT

신규 단말은 세 가지를 원칙으로 세웠습니다. HTTP로 데이터를 수집하지 않고, SMS로 차량을 제어하지 않으며, 트래픽이 급증해도 유연하게 받을 수 있어야 한다는 것입니다. SMS는 도달 시간이 환경마다 다르고 발송할 때마다 비용이 든다는 점이 이유였습니다.

이 조건에 맞춰 MQTT를 골랐습니다. 제한된 IoT 기기에서 많은 데이터를 보내도록 설계된 프로토콜이고, 발행과 구독 구조라서 개별 단말에 일대일로 붙지 않고 브로커를 거쳐 메시지를 퍼뜨리거나 상태를 모을 수 있습니다. 국제 표준이어서 브로커를 직접 만들 필요 없이 기존 제품을 고르면 된다는 점도 이유로 들었습니다. 원문이 꼽은 후보는 mosquitto, VernaMQ, HiveMQ, RabbitMQ입니다.

직접 운영 대신 AWS IoT Core

브로커를 직접 운영하면 관리 부담이 늘고, 어떤 단말이 연결 중인지 알려 주는 기능이 브로커에 없는 경우가 많았습니다. 클러스터링을 지원하지 않는 제품도 있었고, 차량 제어에 필요한 보안 수준에는 못 미쳤습니다. 그래서 관리형 서비스인 AWS IoT Core를 쓰기로 했습니다.

원문은 시간대와 시즌에 따라 데이터량이 크게 달라지는 카셰어링의 특성을 들어, 부하가 걸려도 단말이 명령을 받고 상태를 보고할 수 있어야 한다고 설명합니다. 브로커가 불안정하면 단말과 통신 환경이 멀쩡해도 서비스 안정성이 흔들리므로 관리형의 이점이 크다는 판단입니다.

보안에서는 Fleet provisioning이 큰 도움이 됐습니다. 인증되지 않은 주체가 메시지를 발행하거나 구독하면 데이터가 새거나 차량이 잘못 제어될 수 있습니다. 수천 대가 넘는 단말에 권한을 하나씩 주는 일은 부담이 컸는데, 인증서와 보안 정책을 묶어 관리하면서 수월해졌다고 합니다.

수집 데이터를 MSK로 흘려보내는 구조

기존에는 단말 데이터를 전부 DB에 저장해 썼고, 이 방식은 DB에 부하를 줬습니다. 모비딕 팀은 AWS IoT Core가 모은 데이터를 Amazon MSK로 흘려보내는 구조로 바꿨습니다. 데이터가 필요한 각 부서는 MSK를 구독하는 컨슈머를 만들기만 하면 차량 상태 데이터를 쓸 수 있습니다.

MSK를 실제로 구축하며 겪은 문제는 다음 글에서 다룹니다. 이어지는 내용은 Kafka 파이프라인 구축기에 있고, 단말 자체의 역할은 관제 장치 소개에서 볼 수 있습니다.