×Закрыть

Особливості розробки IoT-проекту: вибір технологій, проблеми та правильна оптимізація

Привіт, мене звати Денис, останні кілька років я займаюся розробкою високонавантажених систем на базі Node.js. Ключова особливість — це використання IoT для розв’язання низки складних завдань, які ставить проект. AWS дуже допомагає мені в налаштуванні й підтриманні IoT-проектів з достатньо потужним SDK, що я успішно зінтегрував у чималу кількість своїх проектів.

У статті я розповідаю про початок розробки на IoT-платформі як для тих, хто ні разу не стикався з IoT, так і для тих, хто вже закінчив декілька проектів. Інформації на цю тему дуже багато, але навіть досвідчені розробники часто припускаються простих помилок у коді проекту. Ми розглянемо питання, які постають на етапі побудови архітектури, проблеми в безпеці IoT-платформ, яке програмне забезпечення краще використовувати, і розглянемо проблеми оптимізації Big Data.

Чому Node.js — найкраще рішення для IoT

У повсякденному житті ми дедалі частіше зустрічаємо розумні пристрої, як-от розумні годинники, мікрохвильовки, пральні машини, навіть будинки. Це все гармонічно пов’язано з вашим смартфоном, через який ви, установивши на нього мобільний додаток, можете контролювати десятки процесів, що виконують ваші розумні пристрої. Тут і починається магія IoT, що дає змогу в режимі реального часу з’єднати ваш мобільний додаток зі всією розумною технікою будинку.

Для розв’язання таких завдань ми маємо низку мов програмування, зокрема Python, Java, C++ і Ruby, які загалом зможуть це виконати й навіть досить непогано. Але вже є мова програмування, яка чудово може працювати з IoT, — це JavaScript. Але навіть вона — не еталон. І тут до гри долучається Node.js зі своїм багатомільйонним community, із чималою кількістю бібліотек і можливістю стабільної роботи на високонавантажених проектах з мінімальним використанням ресурсів сервера.

Node.js — це середовище виконання JavaScript-коду на боці сервера, яке зазвичай використовують для розробки великих і багатофункційних проектів. Це надзвичайно потужний і водночас дуже простий у вивченні інструмент, який легко зрозуміти розробнику, далекому від JavaScript. Найперше хочу розвіяти низку міфів про Node.js, що створили ті користувачі, які, очевидно, давно не передивлялися Changelog Git-репозиторія й уявлення не мають, як розвинули нині цю технологію.

Найчастіше трапляється твердження, що JavaScript — не об’єктно-орієнтована мова. Це визначення було б правильним років 10 тому. З релізом ECMAScript 6 ми отримали повноцінну підтримку класів і наслідування. Звичайно, це не таке саме ООП, яке ми звикли бачити в інших мовах програмування, але й ніхто не планував (поки що) типізації в JavaScript або модифікаторів доступу. Звичайно, для тих, хто все-таки хоче мати такі можливості за замовчуванням, є TypeScript.

Один з міфів свідчить про те, що JavaScript не має архітектури й розробники пишуть код, як хочуть. На жаль, це можна сказати не лише про JavaScript, а й про деякі досить потужні мови програмування. Так чи інакше розробники вже давно підтримують патерни програмування та проектування й із задоволенням використовують їх у своїх проектах. Для Node.js є низка доволі популярних фреймворків з власними архітектурою та правилами, тому розробник так чи інакше дотримується принципів розробки на базі цих фреймворків.

Також хотілося б перелічити причини, чому саме Node.js — найкраще рішення для розробки IoT-проектів:

  1. Більшість проектів IoT використовують протокол MQTT і стандартні WebSockets, які чудово підтримує Node.js.
  2. Пакетний менеджер (NPM) має чималу кількість бібліотек для розробки IoT-проектів і чималу кількість модулів для роботи з пристроями, зокрема: Intel IoT Edison, Raspberry Pi або Arduino.
  3. Оскільки IoT-пристрої — це давачі, сенсори, передавачі тощо, то вони зазвичай генерують велику кількість даних і в такий спосіб велику кількість запитів. Із цим завданням Node.js легко впорається завдяки можливості підтримки потоків як для читання, так і для запису.

Основні проблеми, з якими стикається IoT-розробник

Основна концепція Internet of Things — це зв’язок між мільярдами автономних пристроїв. Дані порталу Statista 2017 року свідчать про кількість більше ніж 20 млрд пристроїв, а до 2025 вже понад 70 млрд. Їх усі під’єднано до мережі, і вони передають або отримують дані, потрібні для їхнього правильного функціонування. Ці дані — здобич для інших недобросовісних розробників, які намагаються так чи інакше перехопити потік даних і використати його для власних цілей.

Для IoT-пристроїв безпека полягає в правильній і продуманій архітектурі коду, праві доступу до різноманітного функціонала й перевірці автентичності пристроїв або користувачів. Одним з рішень, що дають змогу запобігти виникненню таких проблем, є грамотна сертифікація. Сервіси, наприклад AWS або подібні до нього, мають максимально гнучкий спосіб налаштування сертифікатів і права доступу. Зазвичай розробник нехтує цим через потребу з’ясовувати, як це працює, і використовує один сертифікат для всього. До того ж цей сертифікат має необмежений доступ до ресурсів і можливість перехоплювати будь-які дані в системі.

Сертифікація повинна бути першим пунктом на початку розробки IoT-проектів. Це просте завдання, яке не потребує чимало часу. Але якщо неправильно продумати цей етап, то з безпекою будуть великі проблеми, що виявляться після того, як минула кібератака й більшість пристроїв вийшла з ладу.

Великою проблемою, як би дивно це не звучало, є AI. Через потребу обробляти велику кількість даних і на їхній основі виконувати певні автоматизовані дії розробники схиляються до AI та написання алгоритмів, які можуть виконувати покладені на систему завдання для IoT-платформи. У такому разі ми стикаємося із ситуацією, коли потрібно постійно модифікувати ці алгоритми, і так чи інакше розробник не може передбачити всі наслідки того коду, який він щойно завантажив у систему. За невеликого втручання людини деякі змінні можуть виявляти зовсім випадково сильну кореляцію з невеликим фактичним прогнозним ефектом.

Не менш вагома проблема — це неправильне розуміння принципів роботи IoT. Розробник іноді вивчає лише основні властивості IoT і вже починає розробку доволі великого IoT-проекту, який наприкінці зможе як істотно нашкодити компанії, так і підірвати авторитет розробника.

Із чого почати розробку IoT-проекту на Node.js

Найперше запитання, яке завжди виникає: із чого почати? Розробити архітектуру або вибрати всі потрібні модулі? Або розпочати з бази даних? Насправді все набагато простіше, ніж здається. Передусім потрібно намалювати загальну архітектуру бази даних і всі поля. Це потрібно для максимальної оптимізації проекту, без якої розробник ризикує отримати повільні запити або взагалі зупинитися на середині розробки через неякісну архітектуру системи.

База даних в IoT-проектах — це найвразливіше місце, яке потім буде важко виправити. Архітектура повинна бути максимально гнучкою й не менш зоптимізованою для інтеграції нового функціонала. Найкраще рішення для цього завдання — використати патерн HMVC (Hierarchical Model—View—Controller), де кожен компонент системи виконує в ній свою роль і має знайому для всіх MVC-архітектуру.

Після того як придумали архітектуру бази даних, потрібно продумати, як оновлюватимуться дані, з якою частотою і яка їхня кількість. Зазвичай IoT-сервіси мають відповіді на це запитання, наприклад, в AWS IoT є функція, як-от Rules, за допомогою якої розробник чи DevOps може запросто налаштувати, куди зберігати дані, у яку базу даних і який скрипт потрібно запускати для додаткової обробки цих даних. Дуже важливо розуміти весь функціонал сервісу, який використовуєте, щоб надалі не розробляти те, що вже давно написано та надається для спрощення й так занадто складного проекту.

Як правильно вибрати базу даних для IoT

Сучасні бази даних так чи інакше можуть підтримувати IoT-проекти, тож усе залежить від того, як розробник зреалізує цей зв’язок. Перш ніж обрати базу даних, потрібно зрозуміти, чи підійде саме ця система під функціонал, який передадуть користувачам. Нижче я спробував перелічити основний функціонал, який повинна мати IoT-база даних:

  • гнучка архітектура й підтримка індексів;
  • витримування великого навантаження;
  • user-friendly схема;
  • підтримка експорту й імпорту даних;
  • багатофункційний пошук за різними параметрами;
  • безпека;
  • співвідношення ціни і якості.

Коли настає етап початку роботи над IoT-проектом, кожен вибирає для себе, які пункти будуть найважливіші для розробки високонавантажених проектів. Ніхто не забороняє використати кілька баз даних, і насправді це не є поганою практикою. Проекти можуть містити таку складну архітектуру, що одна база не в змозі дати весь набір необхідного функціонала. Проте варто розуміти, що використовувати достатньо потужну базу даних для одного простого завдання не потрібно, а варто знайти вузькоспеціалізованішу базу й використати її.

InfluxDB з’явилася 2013 року й нині залишається однією з найкращих баз даних для IoT. Це time-series база даних з відкритим вихідним кодом, яку написано мовою програмування Go. Це рішення чудово зоптимізовано під IoT, що й робить його таким популярним нині.

CrateDB — це дистрибутив SQL-бази даних. Вона з відкритим кодом і працює на Java. Її основна особливість у тому, що вона вже має набір бібліотек: Facebook Presto, Apache Lucene або Elasticsearch, які полегшують роботу з базою даних і не потребують додаткових налаштувань. Цю базу спеціально розроблено для того, щоб її можна було зінтегрувати в IoT-платформи різної складності.

MongoDB — це NoSQL-база даних з відкритим кодом. Для кожного розробника, який написав хоча б один проект на Node.js, MongoDB стала найкращим товаришем для розв’язання сотні різних проблем з даними. Вона проста для вивчення й у неї JSON-подібна архітектура, що чудово комбінується з кодом JavaScript. Ця база не так підходить для IoT, як для інтеграції в IoT-платформи, що написано на Node.js.

Amazon DynamoDB — це time series-база даних із закритим кодом, що належить до веб-сервісів Amazon. Як і решту схожих аналогів, зокрема Cloud Bigtable або IBM Informix, її варто використовувати разом з іншими сервісами, що пропонує компанія. У такому разі AWS IoT разом з DynamoDB створює максимально ефективну платформу для розробки високонавантажених IoT-проектів. Окремо використовувати цю базу даних теж непогане рішення, але на ринку чимало дешевших аналогів, що дадуть такий самий результат.

Який ми можемо зробити висновок, розглянувши різні приклади сучасних IoT-баз даних? Усі вони чудово підходять для розробки IoT-платформ, але кожна із запропонованих баз даних має свої фішки, що дають змогу розробнику вибрати ту, яка йому найбільше до вподоби чи підходить для потреб IoT-проекту.

Правильна оптимізація Big Data в IoT-проектах

Ми вибрали основний стек технологій у нашому IoT-проекті й продумали архітектуру що бази даних, що серверної частини. Час починати розробку. Найперше слід визначити, на яку частину проекту буде максимальне навантаження і як максимально зоптимізувати цю частину. Якщо ми використовуємо комплексне рішення, наприклад AWS IoT і DynamoDB, у цьому разі навантаження бере на себе AWS, що дає змогу не думати про неможливість обробити велику кількість даних. З іншого боку, якщо ми самі будуємо архітектуру на власному сервері, тут є кілька рішень, які допоможуть нам у цьому.

Передусім є змога розширювати нашу майбутню архітектуру відповідно до росту проекту, і зазвичай розробник схиляється до використання Docker-контейнерів та Load Balancer, який автоматично допоможе масштабувати проект. Не важливо, що ви виберете — чи то буде Amazon ECS, чи HAProxy, — ви повинні знати, як ця технологія працює, як її налаштувати і як підтримувати. Основні проблеми, з якими стикається розробник, — налаштування та стабільна робота системи, яку він вибрав через те, що рекомендувало community. Кожен вибирає для себе, що йому використати, головне, щоб це відповідало потребам розробника.

Надалі робота над оптимізацією — це робота з кодом проекту. Розробник повинен розуміти, як працює Node.js і які в нього слабкі й сильні сторони. Найкраще для Big Data — це розробити архітектуру, що відповідатиме лише за свою частину роботи й більше ні за що. Проект повинен логувати свій результат і мати змогу перевіряти функціонал у закритих пісочницях. Варто розуміти, що Node.js пропонує розробнику різні способи розв’язання тих чи тих завдань, тому найоптимальнішим рішенням буде дотримуватися найкращих практик розробки високонавантажених систем. Зокрема код повинен обробляти складні операції через черги, кешувати дані й писати максимально зоптимізовані запити до бази даних.

Якщо дотримуватися максимально простої архітектури й реалізувати лише найкращі практики розробки проектів для Node.js, IoT-платформа має всі шанси працювати швидко й стабільно з будь-якою кількістю даних.

IoT-аналітика в режимі реального часу

Зазвичай основна мета IoT-платформи — це збирати аналітику сотень або навіть десятків тисяч сенсорів чи інших пристроїв і показувати цю інформацію користувачам. У сучасному світі все повинно працювати в режимі реального часу й мати зручний інтерфейс обробки цих даних. Розробка аналітики є значним викликом для розробника, який балансує між швидкістю роботи й простотою реалізації. Чимало хто дотримується думки, що краще використати готове рішення й підлаштувати його під свій проект. Якщо проект не містить дуже специфічного функціонала, тоді це загалом правильний підхід тому, що так чи інакше хтось стикався із цією проблемою й уже, найімовірніше, її успішно розв’язав. З іншого боку, розробник має низку завдань, які мають свою специфіку, і проект не зовсім звичайний.

Якщо постало завдання розробки аналітики в режимі реального часу, до того ж розробник дуже обмежений у часі, то краще це завдання перекинути на сервіси, хоча б AWS чи подібні. Також на просторах Інтернету знайдеться чимала кількість готових рішень із відкритим кодом, що дають змогу швидко зінтегрувати модуль у систему й використовувати її.

Звичайно, розробник може відразу під’єднати веб-клієнта до IoT і просто виводити дані, але тут з’являється низка небезпечних нюансів. Важливо розуміти, що ти передаєш користувачеві, як він повинен авторизуватися й чи система може контролювати користувачів і їхній рівень доступу. Найкраще рішення — це розділити IoT з WebSocket на сервері, який фільтруватиме потік даних і не матиме змоги безпосередньо впливати на IoT. Далеко не останнім є той факт, що під час розробки передачі IoT через WebSocket потрібно остерігатися memory leak і не ускладнювати операції щодо підготовки й надсилання даних для аналітики.

Нам відомо, що всі операції в браузері JavaScript пов’язані з потужностями пристрою, на якому цей браузер працює, тож якщо потік даних буде занадто великий, то є ризик зависання або взагалі припинення роботи браузера. Для досвідчених розробників це не проблема, оскільки вони дуже вміло використовують черги й кешування та правильно фільтрують потік даних. Розробник повинен орієнтуватися на аудиторію, яка буде основною в роботі із цим проектом, й оптимізувати найперше під потреби користувачів. Більшість розробників реалізовують SPA (Single Page Application) веб-додатки на базі популярних фреймворків чи бібліотек, наприклад Angular чи React.

Висновок

У цій статті я намагався пояснити чималу кількість особливостей розробки IoT-проектів, які так чи інакше можна використати для інших високонавантажених проектів. Розробник передусім повинен поставити собі завдання якнайкраще зреалізувати ту кількість функціонала, якої потребує IoT-платформа, й уміти правильно оперувати тими можливостями, що йому доступні. Світ програмування не стоїть на місці, і щодня з’являються нові й ліпші підходи для розв’язання завдань, тож потрібно завжди бути в курсі цього розвитку. IoT-платформа навчає дисципліни правильного написання коду й не пробачає помилок. Утрата даних чи неправильна їхня обробка може спричинити чималі наслідки для компанії й користувачів, які довірилися цьому рішенню.

Від команди розробників завжди вимагають якісного підходу в розробці IoT-платформи й змогу передбачити всі проблеми, з якими може зіткнутися система обробки даних. Спершу завжди потрібно визначити для себе, якою буде майбутня архітектура, які інші рішення використовуватимуться і як із цим працювати. Неможливо забезпечити себе повністю робочим рішенням, але краще кілька разів пересвідчитися, що це буде правильно, ніж тестувати проект із реальними даними. Звичайно, це не завжди відповідає дійсності, є моменти, що змушують розробників порушувати правила й робити ризиковані дії в IoT, але вони повинні виправдовувати мету, яку ви поставили перед собою.

Ніколи не дотримуйтеся однієї технології чи одного сервісу, а натомість завжди будьте відкриті до нових технологій і пробуйте щось нове. Можливо, саме нові бібліотека чи фреймворк зможуть розв’язати майже всі проблеми, які досі розробник реалізовував у своєму проекті за допомогою старого й перевіреного рішення. Так чи інакше з Big Data непросто розробляти й перевіряти, чи все правильно працює, але це можливо, якщо вміти підійти до завдання раціонально.

LinkedIn

20 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Для розв’язання таких завдань ми маємо низку мов програмування, зокрема Python, Java, C++ і Ruby, які загалом зможуть це виконати й навіть досить непогано. Але вже є мова програмування, яка чудово може працювати з IoT, — це JavaScript. Але навіть вона — не еталон. І тут до гри долучається Node.js зі своїм багатомільйонним community, із чималою кількістю бібліотек і можливістю стабільної роботи на високонавантажених проектах з мінімальним використанням ресурсів сервера.

Коли в тебе у руках молоток, усе навколо здається цвяхами... Залиште той JavaScript разом з нодою собі для фронту. Не треба нам цього на бекенді. А то знову хтось завалить весь інтернет, видаливши один пакет qz.com/...​ing-a-tiny-piece-of-code

Так, можливо ти правий і є суттєві мінуси ноди. Для фронта є реакт і ангуляр, для мене дивно коли деви використовують ноду на фронті як і використання флеш в 2019 чи джава. По пакетам так погоджуюсь тут може трапитись проблема, тому для цього використовують кеш пакетів і контроль версії. Це якби давно пофіксали і деви які не розбираються як правильно встановити залежності так і будуть стукатись головою :)

для мене дивно коли деви використовують ноду на фронті як і використання флеш в 2019 чи джава

Так ніхто не використовує ноду на фронті... або я ніколи не зустрічав таких збоченців :) Ноду юзають щоб збілдити фронт ну і для роботи різних тулзів.
Просто основний мінус статті в тому, що нема нормальних порівнянь з іншими платформами.

Але вже є мова програмування, яка чудово може працювати з IoT, — це JavaScript

 — от чому саме JS, а не, наприклад, Python чи Java чи C#? Може це переконлива стаття для якогось стартапера, який раніше продавав якийсь оріфлейм, накопичив грошей і хоче зараз хайпанути вистрелити з IoT стартапом (тобто повний 0 в IT технологіях). Та для мене, як розробника, тут нема аргументів, чим нода краща за інші платформи. В мене є досвід програмування на різних мовах, окрім С#, в тому числі і JavaScript і TypeScript... так от, нода не кращий вибір для бекенду. Як мінімум тому, що на бек з нодою будуть хайритись одні лише фронтендщики (але це не зовсім точно) І в них куди більше шансів, ніж у досвідчених бекендщиків інших парафій, натворити в цьому вашому IoT такої херні, що падіння Cloudflare і CDN фейсбучику, разом з усіма зломами LastPass, будуть здаватись лише дитячими забавками...

Оскільки IoT-пристрої — це давачі, сенсори, передавачі тощо,

youtu.be/Os-E0g96cxE

Чому Node.js — найкраще рішення для IoT

порівняно з чим?

Особливості розробки IoT-проекту

Я нарахував 52 рази використання слова IoT в тілі тексту, але якшо замінити його на «меседжер/чатік/ватева» нічого не зміниться, а особливості так і не описані. Ну хіба що про MQTT згадали в одному реченні...

Угу. В нашем случае IoT — это зарядки для электроавто, данные передаются в json сообщениях поверх вебсокетов, ну так публичный стандарт велит, в чём тут принципиальное преимущество ноды — нипанятно.

Дякую за вступ.
Чекатиму конкретики

Я обов’язково в наступній статті більш конкретніше розкрию тему

СПОЙЛЕРЫ
Завжди треба пам’ятати про безпеку продукта. Потрібно добре розуміти, що ти робиш, та розбиратись у технологіях, які використовуєш. Де специфіка продута не заважає, краще використовувати готові рішення, ніж городити власні велосипеди.

Стаття, загалом, непогана, але нащо так багато води та мало конкретики?

Стаття планувалась для широкої аудиторії, але я врахую це в майбутній статті, дякую

Чому Node.js — найкраще рішення для IoT

Смішно

Чому? на ноді іот проект піднімав?

Тому що нода на бекенді — це смішно.

Можете трохи розповісти як Credentials Provider визначає що запит Request Security Token іде від автентичного пристрою а не від якогось зловмисника?

В цьому запиті ідеться виключно на отримання тимчасового, лімітованого токена. Він видається виключно якщо девайс передає сертифікат. На цьому етапі відсіюється всі крім користувачів які мають валідний сертифікат. Але навіть в комплексі це рішення не дає 100 відсоткової гарантії на повну безпеку, треба ще додатково реалізувати це на стороні сервера і девайсів. Тут вже розробникам дається великий вибір, від передачі додаткових сигнатур, шифрування даних і т.д.

Дякую, зрозуміло. А в тому проекті про який ви розказували як зроблено?

Ми додатково використовували шифрування даних. А основна частина безпеки це стандартний підхід від AWS IoT, IAM і AWS STS.

Дякую за пост. Але я не бачу ніякої конкретики, а саме:

Скільки девайсів хендлить ваш проект?
Яке навантаження на вашу систему (трафік, реквест рейт, кількість конекшенів одночасних)?
Як конкретно Ви балансуєте навантаження?
Як синхронізуєте дані коли девайси в різних регіонах?
Скільки даних генерите в день?
Які саме девайси обслуговуються?
Ну і саме головне — скільки коштує ваше рішення в грошах на 1 девайс?

Вибачайте, але без цього це просто водичка.

Дякую за питання.

Скільки девайсів хендлить ваш проект?

<< Від 10 тис. до 100+ тис. приблизно

Яке навантаження на вашу систему (трафік, реквест рейт, кількість конекшенів одночасних)?

<< середній показник трафіку ~1-10Gb/день, запити ~80млн.-200млн. запитів/день, кількість конекшенів залежить від якості інтернету і деякі сессії тримаються деякий час навіть якщо зв’язок перервався тому в межах 20тис.-200тис./день. Але ці показники залежать від складності проекту тому це дуже приблизні значення

Як конкретно Ви балансуєте навантаження?

<< Ми використовуємо сервіси які беруть на себе навантаження(це як одне з простих рішень), але якщо самому піднімати архітектуру тоді треба дивитись в сторону auto scaling наприклад HAProxy чи подібне.

Як синхронізуєте дані коли девайси в різних регіонах?

<< Розробляємо інтерфейс під окремий регіон, але зазвичай в нас пристрої знаходяться в межах одного регіону. Або я не так зрозумів питання)

Скільки даних генерите в день?

<< Один девайс може згенерувати приблизно 8640 точок в день, це дуже залежить від частоти відправки даних, тому тут просто порахувати

Які саме девайси обслуговуються?

<< зазвичай сенсори приєднуються до gateway типу RF50, ESP32 чи RPi і обслуговування ведеться як раз з gateway девайсами

Ну і саме головне — скільки коштує ваше рішення в грошах на 1 девайс?

<< Ну це дуже цікаве питання на яке тяжко відповісти без конкретики) для AWS є такий приклад: For example, in the US East (N. Virginia) region you pay $0.042 per device per year (1 connection * $0.08/1,000,000 minutes of connection * 525,600 minutes/year) for 24/7 connectivity. Але врахувати ще треба оплату за сервер, БД якщо використовується наприклад AWS DynamoDB і допоміжні сервіси. Якщо проект має 10тис девайсів з високою частотою передачі даних то це може коштувати кілька тисяч долларів на місяць або більше.

В статті я не хотів дуже сильно заглибитись в деталі тому що треба розглядати багато різних ситуацій. Треба розглядати кожен випадок індивідуально і як би мені я сильно не хотів більше внести конкретики але на жаль це дуже велика стаття буде) Але дякую за критику, я спробую в наступних статтях більше розкривати тему і підготувати куди більше конкретики

Дякую за відповіді. Це не критика, просто це саме цікаве і цього немає в статті.
FYI — в нас 100к девайсів обслуговуються за 100$.
FYI — в китаї є такий оператор ТУЯ. Вони беруть 1.5$ за 1 девайс як one time payment і все.

Подписаться на комментарии