Как мы строим IoT-сети для бизнеса и города

В большинстве проектов IoT начинается не с устройств и не с платформы. Он начинается с вопроса: «а будет ли это вообще работать на масштабе?» Подключить 50 датчиков к облаку — задача на пару недель. Подключить 50 000 — это уже не про устройства, а про архитектуру, эксплуатацию и деньги, которые набегают каждый месяц. В этой статье мы разбираем, как в OneDev мы подходим к проектированию IoT-сетей для бизнеса и городской инфраструктуры в Узбекистане — без маркетинга, по существу.

Почему масштаб меняет всё

Маленький пилот прощает почти любые ошибки. Можно держать постоянное TCP-соединение на каждое устройство, слать JSON по HTTP каждые пять секунд, хранить всё в одной PostgreSQL-таблице и обновлять прошивку вручную через USB. На 50 устройствах это работает и выглядит красиво на демо. Проблема в том, что почти ни одно из этих решений не доживает до 5 000 узлов, не говоря о 50 000.

Когда количество устройств растёт на два-три порядка, линейно растут не только данные, но и совершенно новые классы проблем: одновременные переподключения после сбоя сети, стоимость трафика, нагрузка на брокер сообщений, объём «горячих» и «холодных» данных, безопасность тысяч слабозащищённых узлов и — самое болезненное — необходимость обновлять прошивку на парке, к которому физически уже не подойти. Поэтому первое, что мы делаем на старте проекта, — считаем не функциональность, а нагрузочный профиль.

• Сколько устройств в пике онлайн и какой темп их роста на горизонте 2–3 лет?
• С какой частотой каждое шлёт данные и какого они объёма?
• Что критично доставить немедленно (тревога, авария), а что можно агрегировать и отправлять раз в час?
• Какой допустимый процент потери пакетов и какая задержка приемлема для бизнес-логики?
• Что происходит, когда пропадает связь на час, на сутки, на неделю?

Ответы на эти пять вопросов определяют выбор протокола, топологии и стоимости эксплуатации больше, чем любой бренд платформы.

Связь: нет «лучшего» протокола, есть подходящий

Главная развилка любого IoT-проекта — как именно устройства попадают в сеть. В условиях Узбекистана, где есть и плотные города, и разреженная сельская местность, и промышленные объекты с экранированными помещениями, универсального ответа не существует. Мы подбираем канал под физику задачи и под стоимость владения.

На практике крупная сеть почти всегда гибридная: тысячи маломощных датчиков по LoRaWAN или NB-IoT, поверх них — шлюзы и концентраторы на 4G, а критичные узлы продублированы вторым каналом. Задача архитектора — не влюбиться в одну технологию, а собрать связку, которая переживёт реальную эксплуатацию.

Архитектура передачи данных

На уровне обмена сообщениями для большинства задач мы строим систему вокруг MQTT с брокером, рассчитанным на горизонтальное масштабирование (кластер), а не вокруг REST-запросов от каждого устройства. Причина простая: держать сотни тысяч долгоживущих лёгких сессий и доставлять сообщения по подписке дешевле и надёжнее, чем обрабатывать постоянный шквал HTTP-запросов с установкой TLS на каждый.

За брокером мы ставим слой потоковой обработки — очередь или стрим (Kafka и аналоги), который развязывает приём данных и их обработку. Это ключевой момент: устройства не должны ждать, пока база запишет строку. Они отдают сообщение брокеру, брокер кладёт его в поток, а дальше обработчики читают этот поток в своём темпе. Если база на минуту замедлилась — данные не теряются, они копятся в буфере.

Хранение и обработка телеметрии

50 000 устройств, отправляющих по одному показанию в минуту, дают более 70 миллионов записей в сутки. Обычная реляционная таблица на таком потоке деградирует за недели. Поэтому для временных рядов мы используем специализированные базы (time-series), партиционирование по времени, автоматическое прореживание старых данных (downsampling) и политики хранения, которые удаляют сырьё, но сохраняют агрегаты.

Отдельно проектируется аналитический контур. Бизнесу редко нужны сырые миллионы строк — ему нужны ответы: где аномальный расход, какой узел вот-вот выйдет из строя, как меняется нагрузка по районам города. Поэтому мы заранее закладываем агрегаты, материализованные представления и, где оправдано, предиктивные модели на исторических данных.

Безопасность: каждое устройство — потенциальная дыра

В городской и промышленной IoT-сети безопасность — не опция, а условие запуска. Каждое устройство в поле физически доступно, дёшево и потенциально может быть скомпрометировано. Мы исходим из принципа «нулевого доверия» к самому устройству.

• Уникальные ключи или сертификаты на каждое устройство, а не общий пароль на весь парк.
• Шифрование канала (TLS/DTLS) и взаимная аутентификация устройства и платформы.
• Возможность мгновенно отозвать доступ конкретного узла, не трогая остальные.
• Сегментация: скомпрометированный датчик не должен видеть весь остальной парк и тем более внутренние системы.
• Подписанные обновления прошивки — устройство принимает только то, что подписано вашим ключом.

Обновления и эксплуатация на расстоянии

Самый недооценённый риск крупной IoT-сети — невозможность обновить прошивку. Если у вас 50 000 счётчиков в подвалах по всему городу, то любая ошибка в прошивке без механизма удалённого обновления (OTA) превращается в катастрофу с выездом бригад. Поэтому OTA — не функция «на потом», а часть фундамента.

Правильный OTA — это поэтапная раскатка (сначала 1% парка, потом 10%, потом всё), автоматический откат при сбое, защита от «окирпичивания» при потере питания в момент прошивки и контроль версий по всему парку. К этому добавляется мониторинг: вы должны видеть в реальном времени, сколько узлов онлайн, у кого падает заряд, кто молчит дольше нормы, где растёт процент ошибок. Без этого вы управляете сетью вслепую.

Как мы ведём проект в OneDev

Мы не начинаем с покупки оборудования. Сначала — нагрузочный профиль и бизнес-цель, затем выбор канала связи и протокола, проектирование архитектуры данных и безопасности, и только потом пилот на ограниченном парке с честной нагрузочной проверкой. Пилот мы сознательно строим так, чтобы он масштабировался: те же протоколы, та же модель безопасности, та же логика хранения, просто меньше узлов. Это избавляет от мучительного переписывания всего при переходе от 50 устройств к 50 000.

Отдельно мы закладываем стоимость владения на годы вперёд: трафик SIM-карт, лицензии, серверные мощности, поддержку. Красивая архитектура, которая разоряет заказчика на эксплуатации, — это плохая архитектура.