Недавно в пресс-релизе мы рассказали о том, что запустили Tarantool IIoT — платформу для промышленного интернета вещей. Новость облетела многие электронные издания. Но что такое Tarantool IIoT и как он работает — тема оставалась не до конца раскрытой. Мы решили это исправить. Подробности под катом.
А что вообще такое IIoT?
Сначала я напомню, что IIoT — это industrial internet of things (промышленный интернет вещей). Это такая концепция, когда у объектов промышленности появляется доступ в интернет как в сеть и доступ к интернет-сервисам (которые работают в центрах обработки данных — ЦОДах). Давайте посмотрим на рисунок:
Что мы тут видим? Рисунок поделен на две части — «центр» и «на местах».
«Центр» — это ЦОД или облако, т. е. любой облачный IaaS-сервис, в котором можно разворачивать IT-инфраструктуру: Amazon, Azure и т. д.
«На местах» — я, если честно, не знаю, какой правильный термин тут использовать. Уверен, читатели меня поправят и предложат красивое определение. Я лучше расскажу, что имею в виду под «на местах»: в поле (в прямом смысле слова — на агрокультурном поле), на производственной площадке (на заводе, фабрике, металлообрабатывающих, горнодобывающих и нефтегазовых объектах), на ремонтной площадке, на транспорте (в автомобиле, грузовике, ж/д вагоне, локомотиве), на объектах городской инфраструктуры (в местах сбора информации о потреблении электричества и воды, в канализации, вдоль улиц, в объектах освещения), на объектах междугородной инфраструктуры (вдоль шоссе, железных дорог, возможно, линий электропередач). В общем, «на местах» — это везде, куда рука интернета только начинает добираться. Еще можно сказать «в поле», но тогда появляется риск сузить круг промышленного интернета вещей только до агрокультурного поля.
А что такое Tarantool IIoT? Какие проблемы он призван решать?
Tarantool IIoT — это распределенная софтверная платформа для сбора информации с датчиков и отправки ее в центр и на локальные системы управления. Tarantool IIoT работает и «в центре», и «на местах», соединяя их в единую информационную сеть. В этой сети максимум логики унесено в софт, поэтому с точки зрения железа она может быть собрана из commodity-компонентов, т. е. не нуждается в специальных поставщиках закрытых проприетарных программно-аппаратных платформ. Стало понятнее? Если нет, то читайте дальше :-)
Под commodity-компонентами имеются в виду легко заменяемые дешевые компоненты. Например, если мы вспомним дата-центры, то с точки зрения их железа commodity — это недорогие серверы, например supermicro или даже полностью самосборные серверы. С точки зрения железа «на местах» это могут быть самые дешевые датчики и IoT-хабы (т. е. маленькие компьютеры на основе ARM).
Внутри своих дата-центров в Mail.Ru Group мы уже достаточно давно почти полностью перешли на commodity-железо. Иногда без фирменной брендовой гарантии и саппорта, зато недорогое и взаимозаменяемое. При этом надежность и производительность обеспечиваются на уровне софта. Если что-то ломается, то это не критично для сервисов, потому что все задублировано и зареплицировано на уровне софта — мы просто спокойно отправляем железо в ремонт. Сроки и вообще возможность починки железа не влияют на непрерывность бизнеса. По такому же пути давно прошли крупные американские IT-корпорации: вся сложность переносится на софт, при этом железо максимально стандартизируется и удешевляется. И теперь мы предлагаем распространить этот подход и на мир IoT.
Спрашивается, зачем места и центр соединять в единую информационную сеть? Ответ такой:
- На местах есть источники информации (о температуре, вибрации, геопозиции, влажности, напряжении, давлении и т. д.). Эту информацию хорошо бы собирать, агрегировать и передавать в центр для аналитики, чтобы потом делать выводы о количестве и точках потерь при производстве продукции, потреблении сырья и топлива, эффективности работы на местах, периодах обслуживания, вероятности поломки станков и приборов и пр.
- На местах есть инфраструктура, которой иногда удобно управлять из центра, в том числе на основе ранее полученной аналитики. Управлять означает посылать из центра на места команды (вызывать API), которые будут активировать (выключать, включать, уменьшать, увеличивать, замедлять, ускорять) локальные объекты. На мой взгляд, пока рано говорить о полном и повсеместном управлении производством из центра (никто не хочет, чтобы из-за зависшего сетевого соединения упал 15-тонный пресс), но многие некритичные вещи можно делать. Например, если на основе анализа данных от датчиков вибрации оборудования стало ясно, что оборудование скоро выйдет из строя, то можно отправить из центра на завод команду, которая зажжет красную мигающую лампочку (да-да, именно так: если пушнуть это событие на планшет местному работнику, то он его попросту не заметит, ведь будет занят). Увидев мигание лампочки, сотрудники остановят сломанный станок и закажут досрочное проведение технического обслуживания.
На местах, как вы понимаете, есть своя специфика, отличная от ЦОДа. Оговорюсь сразу, что мы в Mail.Ru Group только в начале пути развития своей IIoT-стратегии и не так давно прощупываем рынок IIoT, поэтому, возможно, пока не до конца понимаем все тонкости. Вот что мы сейчас думаем о специфике. Это:
- огромные площади (возьмите средней руки завод — по площади он может в сотни раз превосходить даже большой дата-центр);
- суровые условия (жар, холод, влажность);
- повышенный риск повреждения объектов IT-инфраструктуры;
- высокая стоимость замены объектов IT-инфраструктуры (добраться в поле за тысячу верст по бездорожью и объехать там сотню квадратных километров — это вам не в ЦОД в Москве смотаться);
- внешняя по отношению к IT-инфраструктуре информация, которую нужно собирать с помощью датчиков температуры, влажности, плотности, геопозиции, веса, напряжения и т. д.
Что вся эта специфика означает? Что мы не можем строить на заводах, полях, кораблях, городских улицах и прочих объектах то, что мы строим в ЦОДах: ряды одинаковых стоек с серверами внутри, скоммутированные через оптоволокно. Это будет безумно дорого.
А что мы еще не можем? В мире IoT роль серверов играют IoT Hubs — микрокомпьютеры (промышленные аналоги Raspberry PI), которые разбросаны на многих километрах площадок. Между ними оптоволокно тянуть — дорого. И в стойки собирать их тоже дорого, потому что из-за огромных расстояний IoT Hubs слишком много, и предприятия, ограниченные финансово, не могут формировать локальные кластеры из большого количества IoT Hubs. То есть нет локализованных стоек. Есть разбросанное по местности железо. Далее, у предприятий/объектов есть миллионы разбросанных повсюду датчиков (см. выше, о каких датчиках речь), с которых IoT Hubs собирают информацию. Опять же — как ее собирать? Если датчиков мало, то по проводам. А если их миллион, то через радиоканалы (миллион проводов, по проводу от датчика — представляете, какой клубок?).
В итоге, чтобы решение было более-менее cost-effective, вся эта конструкция может выглядеть вот так:
Датчики собирают информацию и отправляют ее на хабы (это не сетевые хабы, просто называются так же: это микрокомпьютеры с маленькой материнкой, процем, памятью и операционкой), хабы передают информацию в интернет (через мобильную связь, Wi-Fi, спутниковую связь, Ethernet и т.п.), и она долетает до ЦОДа. Ровно так же путешествует обратный поток — из ЦОДа на хабы, с хабов на датчики (или на локальные программируемые логические контроллеры).
Идем далее. Еще помните о специфике мира IIoT? Чтобы вся эта конструкция не стоила космических денег, хочется, чтобы:
- IoT Hubs состояли из потенциально заменяемого железа, это снизит вероятность vendor lock-in и цену железа, которого нужно ой как много из-за огромных расстояний;
- поверх была открытая операционка (например, разновидность Linux — OpenWrt);
- вся логика взаимодействия с любыми видами датчиков и разбором их протоколов ушла на уровень софта поверх операционки (чтобы не зависеть от дорогих черных брендовых ящиков);
- вся логика отправки сигналов в сторону датчиков и оборудования также ушла на уровень локального софта на IoT Hub, а не была захардкожена в вендорских железных коробках (имеется в виду логика обработки, а не физическая передача данных);
- софт, работающий на IoT Hubs, был очень быстрый. IoT Hubs медленные, а медленные, потому что дешевые, а дешевые, потому что их надо очень много, а очень много надо из-за специфики (см. выше). А еще вспомните про специфику в виде жары-холода-влажности-вибрации, т. е. этим хабам нужны специальные корпуса. А цену-то наращивать нельзя. Значит, надо делать техническую начинку еще дешевле, стало быть, еще медленнее. Представляете, как быстро должен шуршать софт, чтобы дебет с кредитом сходился?
То есть хорошо бы, иными словами, иметь то, что мы привыкли видеть в ЦОДах: заменяемое недорогое железо, вся логика на уровне софта и весь fault-tolerance на уровне софта.
А теперь давайте обратим взгляд на софт в ЦОДе. Там, кроме операционки, почти всегда используется много других компонентов — СУБД, серверы приложений, системы мониторинга, DevOps-скрипты и системы. И уже поверх этой инфраструктуры пишется бизнес-логика. По-хорошему, вся описанная инфраструктура конфигурируется так, чтобы автоматически (ну или полуавтоматически) брать на себя основные проблемы сбоев на стороне железа (переключать нагрузку на реплику базы данных, если мастер-копия недоступна, распределять нагрузку между несколькими нодами серверов приложений, автоматом наливать чистую машину, которая подключена в кластер, и т. д.).
То есть появилось несколько специализаций. Разработчики бизнес-логики (продуктовые разработчики), по-хорошему, думают в основном о бизнес-логике и фокусируются на бизнес-проблемах. А еще имеются инженеры и разработчики остальной, огромной подводной части айсберга — DevOps, системные администраторы, разработчики СУБД, разработчики серверов приложений, систем мониторинга и других (назовем их инфраструктурными) компонентов.
Вот бы и на местах так было. Круто же? Вот бы разработка на IoT Hubs была такой же специализированной.
Tarantool IIoT — под капотом
И тут мы плавно подходим к Tarantool IIoT. Я не скажу, что он призван заменить всю вышеуказанную инфраструктуру на IoT Hubs, но он может сделать это частично. Посмотрите на рисунок:
Tarantool IIoT — это обычный Tarantool, но собранный и оттестированный под ARM и под x86 (версия для MIPS сейчас создается). Кроме того, внутрь него встроена автоматическая поддержка протоколов MQTT и MRAA — это основные протоколы для работы с датчиками. Tarantool IIoT инсталлируется непосредственно на IoT Hubs. Еще можно тут добавить, что для передачи данных между датчиками и хабом (на схеме «на местах») нужно специальное оборудование LORA1 или 6LoWPAN. Что, казалось бы, плохо (помните, мы не хотим уникальных вендорских коробок). Но вся соль в том, что это оборудование не обязано понимать протоколы множества датчиков. Его задача — только завернуть протокол в понятный для хаба протокол (обычно это наш любимый старый добрый TCP/IP). Весь остальной разбор можно делать на Tarantool IIoT с помощью скриптов, которые работают прямо на IoT Hub.
В этом преимущества программной платформы над железной — любое оборудование и любые протоколы можно поддержать самостоятельно, без вендора. Технические детали, как это все устроено и как программируется с помощью Tarantool, можно почитать в статье «Master-master репликация и масштабирование приложений между всеми IoT-устройствами и облаком».
Во всем остальном Tarantool IIoT — это полнофункциональный Tarantool, т. е. СУБД со встроенным сервером приложений, синхронным логом транзакций, репликацией между узлами, двумя движками (in-memory — memtx и on-disk — vinyl), хранимыми процедурами, асинхронными джобами, поддержкой очередей и прочими пирогами.
Что Tarantool IIoT дает разработчику?
Tarantool IIoT инсталлируется на IoT Hubs. Что это дает?
- На Tarantool IIoT можно писать скрипты, которые принимают информацию с датчиков, парсят ее и сохраняют в локальную базу данных прямо внутри Tarantool IIoT (она персистится на флеш-памяти IoT хаба).
- Информация, сохраненная на IoT Hub, локально реплицируется между несколькими IoT Hub для надежности (чтобы вся система продолжала работать даже после выхода одного или нескольких хабов из строя). Репликация у Tarantool есть сразу из коробки, т. е. не надо писать свою систему очередей. Вот тут, кстати, важный момент: Tarantool — это не только сервер приложений, но и СУБД. А значит, в нем можно персистить данные и реплицировать данные между узлами. Очень важные свойства в свете сказанного выше. И очень важно, что оно работает из коробки и протестировано годами (ибо ядро Tarantool ровно такое же, как и для обычных не IoT сервисов).
- Информация, сохраненная на IoT-хабах, реплицируется в ЦОД встроенными средствами Tarantool. Причем только та ее часть или агрегация, которую вы хотите реплицировать (настройка программируется и работает прямо на IoT Hub).
- Можно автоматом загружать код и хранимые процедуры в Тарантулы на местах, т. е. менять логику локальной агрегации из ЦОДа (т. е. отовсюду, откуда есть доступ в ЦОД: из офиса или из дома через VPN) без выезда на места.
- Можно по одной кнопке из ЦОДа (а значит, и из веб-интерфейса, доступ к которому есть у авторизованных людей с любого устройства из любой точки мира) менять степень детализации доставки информации в центр, при этом локально, на местах, получать столько информации, сколько надо, и обрабатывать ее без передачи в ЦОД.
Как итог — продуктовый разработчик получает шажок в сторону той степени комфорта, которая присутствует при создании софта, работающего в ЦОДе. Не приходится думать о том, что каналы между хабами локально и между хабом и ЦОДом ненадежны и рвутся: репликация все равно доставит данные в обе стороны без потерь и без задвоения. У разработчика меньше болит голова о клиент-серверной архитектуре, о файликах, о потере данных, о выходе из строя хабов — все это хендлит Tarantool IIoT ровно так же, как это происходит в ЦОДе при использовании обычного Tarantool. Разработчик может больше сконцентрироваться на бизнес-логике.
Еще добавлю тут, что доставкой данных занимается штатный механизм репликации между узлами, который тестируется в Tarantool на протяжении уже девяти лет. То есть надежность механизма достаточно высока.
По сути, Tarantool IIoT — это полностью программируемая открытая платформа, которая позволяет не только разрабатывать приложения под IIoT на локальных устройствах (без выезда на места!), но и переносить best practices из ЦОДа на IoT-устройства на местах.
И еще эта платформа развязывает вам руки в том смысле, в котором производители оборудования вам их ранее связали. Например, у вас уже есть готовая и работающая железная IoT-инфраструктура, которая автоматом доставляет все из датчиков в ЦОД. Вы закупили новую партию более дешевых датчиков, которые не поддерживаются вашим текущим оборудованием. Вам придется валяться в ногах у вендора оборудования, чтобы он за большие деньги внес туда изменения. Ну или просто закупить новую версию оборудования. Или отказаться от дешевых датчиков. И все эти изменения — железные, не софтверные, т. е. с downtime, выездом на места, монтажом и прочими неприятностями.
С помощью Tarantool IIoT же можно без проблем получать данные с этих новых дешевых датчиков, парсить их и далее выдавать в ваше оборудование или в локальный софт в нужном формате. Без downtime и без больших затрат.
Понятно, что самого по себе Tarantool IIoT мало. Для полного комфорта нужны и остальные инфраструктурные системы — мониторинг, удаленный апгрейд софта (тот же Tarantool надо апгрейдить), автоматическая наливка Linux и прочие радости. Но, как нам кажется, это уже шаг в нужном направлении.
Почему вообще Tarantool IIoT, а не $любая_другая_технология IIoT?
В заключение я хочу рассказать, почему в качестве основы для нашего IIoT-продукта мы взяли именно Tarantool. Давайте на секунду вернемся к специфике IoT Hubs: у этих устройств медленные процессоры с малым количеством ядер (обычно одно-два ядра), мало оперативной памяти, мало флеш-памяти, которая к тому же медленная и ненадежная. Почему? Устройства должны быть очень дешевыми (ценовой диапазон приблизительно такой: 30—100 долларов), потому что их очень много, потому что инфраструктура разбросана на многие километры — и еще по ряду причин, см. выше. Помните, я говорил о специфике? От нее не уйти. Это с одной стороны. А с другой стороны, датчики генерируют огромное количество информации (с одного датчика могут поступать десятки и сотни параметров в секунду, а количество датчиков на хаб иногда исчисляется сотнями и тысячами). Всю информацию надо успевать обрабатывать, несмотря на жесткие условия и не очень быстрое оборудование.
Соответственно, для таких устройств нужны о-о-очень быстрый софт, очень быстрая СУБД и очень быстрый сервер приложений, способный работать на одном ядре процессора, максимально эффективно использующий память и не напрягающий диск.
И в условиях всех этих ограничений Tarantool на наших тестах показал лучшие результаты. Ближайшим конкурентом по скорости может быть Redis (с CouchBase и Aerospike, к сожалению, у нас ничего не получилось: они очень медленные на одноядерных машинах, но, возможно, мы просто не умеем их готовить). Главные минусы Redis с точки зрения применимости в IoT: в нем недостаточно развит сервер приложений, нет хранимых процедур (и нельзя в рантайме обновлять код внутри СУБД), нет джобов, нет мастер-мастер репликации, нет транзакций — больше вероятность потери данных. Плюс непонятно, планируют ли авторы продукта вообще развиваться в эту сторону. Вот тут пример сравнения двух продуктов: Tarantool vs Redis. Связка Python и Redis может в каком-то смысле заменить Tarantool, но по скорости, скорее всего, сильно проиграет. Сразу оговорюсь — сравнительных тестов пока нет, плюс мы рекомендуем скорость работы сравнивать в каждом случае, case by case.
Еще один важный нюанс: на IoT-девайсах, когда СУБД и сервер приложений объединены (а в Tarantool они объединены и работают в одном процессе), накладных расходов на их общение друг с другом, очевидно, будет сильно меньше (вот тут о накладных расходах, которые огромны даже при взаимодействии с быстрыми СУБД: Asynchronous processing with in-memory databases or how to handle one million transactions per second on a single CPU core). При этом любые накладные расходы на передачу информации между разными процессами получаются очень большими в свете невысокой производительности устройств и огромного количества информации, которую нужно обрабатывать.
Еще есть такая неплохая штука — SQLite, он хороший и быстрый, но, к сожалению, у него нет репликации и сервера приложений из коробки — т. е. поверх него надо еще поплясать с бубном. Остальные традиционные СУБД (не буду называть, тут большой список уважаемых продуктов, все их прекрасно знают) у нас просто не завелись нормально на маленьких железочках IoT или даже близко не справились с той нагрузкой, которая идет от датчиков. Однако если у вас есть положительный опыт применения других СУБД на IoT-девайсах, то мы будем рады, если вы поделитесь им!
Это все, что я хотел рассказать о Tarantool IIoT. У нас уже в процессе пилоты с различными производственными, транспортными и другими компаниями. Как только будет продакшн, мы обязательно про это детально напишем. Следите за новостями!
Автор: Mail.Ru Group
