В продуктовой разработке нередко случается, что из кастомного проекта для конкретной компании рождается самостоятельный продукт. Так случилось и с Cloud IoT Platform: из небольшого пилотного проекта мы создали облачную промышленную платформу интернета вещей.
Я Андрей Сергеев, руководитель группы разработки в VK Cloud. Расскажу, как мы разработали платформу, с какими трудностями столкнулись и что в итоге получили.
Главное о Cloud IoT Platform
Cloud IoT Platform от VK Cloud — масштабируемая и аппаратно-независимая платформа интернета вещей для сбора, обработки, анализа и визуализации данных почти в реальном времени, а также для управления устройствами.
Платформа ориентирована на разработчиков IoT-решений в разных отраслях: от умного здания до умного предприятия. Она позволяет собирать данные одновременно с сотен тысяч устройств, поддерживает основные протоколы обмена данными и помогает быстро писать интеграционный слой подключения устройств к платформе с помощью SDK. В терминах Cloud IoT Platform этот компонент называется «агент».
История создания
История Cloud IoT Platform начинается с разработки проекта для одной из нефтедобывающих компаний. Прототип решения построили на Single Instance Tarantool, который использовали в качестве базы данных и сервера приложений (Application Server). Приложение принимало данные, обрабатывало их и вызывало пользовательские скрипты на входящих данных. Я рассказывал более детально про основание платформы в своей предыдущей статье.
Поскольку проект был пилотным, он поддерживал минимальный набор функциональности, стандартный для промышленных систем начального класса:
получение данных от OPC-сервера (Open Platform Communications);
обработка полученных событий в реальном времени;
мониторинг ключевых показателей на основе полученных событий;
генерация событий и алертов в вышестоящие системы.
Прототип успешно прошёл обкатку в боевых условиях — работал на нефтедобывающей платформе в Персидском заливе.
После теста стало очевидно, что прототип жизнеспособен, и мы увидели для себя возможность разработки полноценной IoT-платформы. Для её создания функциональность и возможности существующего решения нужно было расширять.
От прототипа к IoT-платформе
При разработке собственных продуктов мы стремимся сделать сервис Enterprise-уровня доступным для компаний любого размера. Поэтому при доработке прототипа было важно привести решение в соответствие с нашими требованиями к промышленной IoT-платформе. Для этого было нужно реализовать возможности:
одновременного подключения тысяч устройств;
приёма до миллиона событий в секунду;
потоковой обработки, аналитики и визуализации данных;
обеспечения максимальной отказоустойчивости.
Также было важно усилить функциональность платформы, а для этого требовалось изменить архитектуру. Мы перешли к микросервисной архитектуре с разделением сервисов. Всю бизнес-логику из Tarantool вынесли в Stateless-приложения, а базы данных — в Stateful. Задачу упрощения эксплуатации и масштабирования Stateless-сервисов мы решили с помощью контейнеризации и Kubernetes.
Кроме того, предусмотрели возможность оптимальной работы с разными типами данных — для каждого нужна была БД со своими характеристиками. Мы выделили три типа:
метаинформация — устройства, настройки, правила и другие данные, кроме тех, что передают конечные устройства;
сырые данные от устройств: показания датчиков, телеметрия и служебная информация от устройств;
состояние — данные о текущем состоянии устройств и датчиков, а также разные глобальные переменные для правил потоковой аналитики.
Метаинформация
Метаданные реляционны. Часто они имеют небольшой объём и редко изменяются. Но для безопасности их хранения нужна консистентность, хотя бы в рамках асинхронной репликации, ACID-транзакции и горизонтальное масштабирование на чтение.
Под эти критерии подходит любая классическая реляционная база данных с поддержкой кластеров с асинхронной репликацией, например PostgreSQL или MySQL. Но только не в нашем случае: в прототипе была фича из систем класса БДРВ (баз данных реального времени). Они позволяют объединять все устройства клиента в одну древовидную структуру, что облегчает управление большим количеством устройств и их отображение. Проблема в том, что классические реляционные базы данных не подходят для работы с «деревьями» произвольной ширины и глубины.
Чтобы получить нужную БД под свои запросы, мы решили скомбинировать реляционную и графовую базу данных с помощью примитивов Tarantool. Используя доступные примитивы из коробки, мы собрали хранилище метаинформации, в котором предусмотрены:
спейсы для хранения данных;
ACID-транзакции;
асинхронная репликация;
Relations;
деревья.
Кластерная инсталляция классическое решение для подобных систем: один Master для записи и несколько Slave с асинхронной репликацией для масштабирования на чтение.
В результате мы получили собственный быстрый масштабируемый гибрид реляционной и графовой базы данных, способный обрабатывать тысячи запросов на чтение.
Сырые данные от устройств
Данные от IoT-устройств — важный актив для аналитики: в результате их обработки и анализа можно получить инсайты и оценки. IoT-устройства генерируют большой поток данных, к которым важно обеспечить доступность. Для таких данных нужна хорошо масштабируемая база данных с механизмами обеспечения отказоустойчивости и аналитическими инструментами, позволяющими находить закономерности и инсайты. Были и дополнительные требования к решению:
Time Series — данные от датчиков являются временными рядами, хотелось получить специализированную базу;
Open Source — плюсы открытого исходного кода не нуждаются в комментариях;
бесплатный кластер — у многих современных БД кластер обычно платный;
хорошее сжатие — учитывая объёмы данных и их однородность, важно эффективно их сжимать;
успешная эксплуатация — мы хотели стартовать на базе данных, которую уже кто-то активно эксплуатирует на близких к нашим нагрузках, чтобы минимизировать риски.
Под эти требования подходил ClickHouse. Но под нашу IoT-платформу его тоже понадобилось «допиливать». Причины две.
Низкая производительность на запись. ClickHouse недостаточно хорошо работает с множественными одиночными инсертами, но отлично справляется с записью больших пачек данных (батчей) на миллионы строк. Мы буферизовали входящий поток, чтобы передавать данные в ClickHouse пачками.
Низкая производительность на чтение. Для потоковой аналитики к данным из БД поступают десятки тысяч запросов. Но нода ClickHouse держит не более 100 запросов одновременно, то есть требуется доработка. Чтобы снизить нагрузку, мы решили сконструировать на базе примитивов Tarantool собственное решение и установили перед ClickHouse кэш, в котором хранятся все данные за 24 часа. В итоге один инстанс созданного решения держит 10 000 RPC на чтение, в том числе до десятков тысяч аналитических запросов.
Состояние
Данные о состоянии устройств записываются и постоянно запрашиваются, причём они занимают небольшой объём. Для таких типов данных не подходит стандартное хранилище метаинформации: состояние может меняться, а возможности записи ограничены. Не подходит и долговременное хранилище: нужен быстрый доступ на чтение.
Исходя из требований, всё свелось к выбору между Key Value и документными БД: Redis, MongoDB, Tarantool. Мы выбрали Tarantool по нескольким причинам:
регулярная запись и запрос данных — самый популярный сценарий использования Tarantool;
есть асинхронная репликация и шардирование;
есть консистентность на уровне документа.
При переходе от прототипа к полноценной IoT-платформе мы полностью переработали её архитектуру и задействовали Tarantool для трех разных задач: хранение метаинформации, кэш для быстрого чтения данных с устройств и хранение данных состояния.
После всех доработок мы получили масштабируемую и аппаратно-независимую промышленную платформу для построения решений интернета вещей. Она позволяет собирать данные одновременно с сотен тысяч устройств и обрабатывать этот поток в режиме Near real-time (то есть квазиреального времени), в том числе с помощью пользовательских правил — скриптов на Python.
Платформа может хранить неограниченный объём сырых данных от источников, есть набор готовых компонентов для визуализации и анализа данных, встроенные инструменты для предиктивной аналитики и создания приложений на базе платформы.
На базе Сloud IoT Platform уже разработаны масштабные проекты и ряд пилотных проектов:
для Минцифры России запущена государственная платформа сбора данных (ГПСД), предназначенная для дистанционного контроля охраняемых законом объектов культурного наследия, а также мониторинга экологической сферы в российских регионах;
разработан пилотный проект по изучению геологической среды и обработке высокоплотных сейсмических данных.
Изначально IoT-платформа внедрялась On-premise на базе инфраструктуры клиентов. Но мы хотели сделать её частью облачной платформы. Как только IoT-платформа была доделана и прошла обкатку на реальных задачах, мы начали адаптировать её под сервис в публичном облаке.
Перенос платформы в облако
Очевидно, что перед запуском IoT-платформы как сервиса в публичном облаке её надо адаптировать — уйти от ситуационных решений и обеспечить возможность работы как с любыми IoT-устройствами, так и с разными сервисами хранения и аналитики. Для этого мы взяли за основу существующую архитектуру IoT-платформы и вновь доработали её. Расскажу подробнее об основных моментах и особенностях получившегося облачного сервиса.
Для сбора данных от объектов мониторинга в Cloud IoT Platform нужна «прокладка» в виде агента — специализированного ПО, которое обеспечивает связь между IoT-устройством и платформой. Благодаря агентам платформе не нужно самостоятельно реализовывать тысячи протоколов IoT — по сути, агенты конвертируют исходный протокол устройства в стандартизированный протокол платформы. Это позволяет вынести все сложности из ядра; как результат, совместимость Cloud IoT Platform практически не ограничена, если правильно написать агент.
Входящие и исходящие очереди представляют собой пункты приёма и передачи данных или сигналов от IoT-устройств к платформе и отправки команд от платформы на устройства. Они реализованы на базе Kafka.
Модуль взаимодействия с устройствами (самописный сервис на Golang) предназначен для валидации и обработки данных, а также запуска на них правил. Через него актуальные данные передаются в оперативное хранилище (оперативный кэш, в котором хранятся данные от устройств за последние сутки), долговременное хранилище (аналитическое хранилище ClickHouse) и цифровые двойники (хранилище актуальных состояний).
Очередь экспорта позволяет перенаправлять входящий поток данных во внешнюю систему. С её помощью можно настроить реэкспорт в S3-совместимые хранилища, системы мониторинга, логирования и другие.
Публичный API представляет собой пользовательский интерфейс, через который можно управлять всей платформой.
Надо сказать, что с точки зрения разработки архитектура Cloud IoT Platform получилась сложной — в ядро IoT-платформы мы поместили модули маршрутизации, хранилища, инструменты визуализации и другие сервисы. Для пользователей это большое преимущество: они получают многофункциональный инструмент для разработки прикладных систем.
Кроме изменения архитектуры, мы разработали безопасный Sandbox. Она критически важна для защиты в облаке от возможных рисков. Мы доработали имеющееся решение и сделали песочницу на основе Docker-контейнеров и gVisor для изоляции ядра хостовой операционной системы от пользовательского кода — это отвечает всем требованиям работы в облаке.
В настоящее время работа над расширением функциональности платформы продолжается, но уже сейчас на её основе можно разрабатывать масштабные IoT-системы. Бесплатный тестовый период для работы с Cloud IoT Platform доступен для всех желающих.
Главное из нашего опыта:
Полноценную IoT-платформу можно создать даже на основе простого прототипа, изначально имеющего ограниченный набор функций и базовую архитектуру.
Если у тебя в руках молоток, это не значит, что всё вокруг становится гвоздями: под разные задачи нужны разные инструменты. Мы в этом убедились на этапе подбора баз данных для своей платформы.
Миграция в облако потребует адаптировать решение для работы в облачной инфраструктуре. Мы решали задачи по обеспечению безопасности работы в облаке и устранению своих прошлых недоработок.
Сложная архитектура IoT-платформы — боль для разработчиков. Но именно усложнение с помощью добавления новой функциональности позволило нам создать полноценный инструмент с широкими возможностями.
На протяжении развития продукта мы учитывали запросы клиентов и расширяли функциональность платформы, в том числе с учётом их требований.
Сейчас Cloud IoT Platform находится на этапе бета-тестирования, в рамках которого мы собираем новые сценарии работы с платформой. Приглашаем всех поучаствовать в бете и оценить наше решение.
