Хабрахабр

[Перевод] Промышленный IoT: изучение спроса

Здравствуйте, коллеги.

Популяризация IoT на русском языке идет полным ходом, однако на английском языке уже выходят первые серьезные книги об архитектуре таких решений в масштабе (больших) предприятий. Сегодня хотим обсудить с вами такую нетривиальную тему как архитектура IoT для больших предприятий. Нас изрядно заинтересовала следующая книга Перри Ли (Perry Lea):

Просим вас активно высказываться насчет актуальности этой книги. Если кто-то хочет поделиться реальным опытом реализации промышленного IoT в России и/или отрецензировать перевод книги — также пишите.

Интернет вещей получает данные с устройств, отправляет команды на устройства, интегрирует данные IoT с другой информацией, на основании чего делает выводы. Под катом предлагаем перевод публикации Red Hat, где рассмотрены вопросы грамотного и безопасного проектирования API для IoT-систем
Суть IoT – в управлении данными. Интегрировать все эти системы по принципу «точка-точка» невозможно, поэтому основным механизмом связи между этими разрозненными системами станут API. Источники данных – это, в частности, устройства, корпоративные системы, системы поставщиков и партнеров, а также информация от провайдеров и клиентов. Центральную роль в нем играют именно API, обеспечивающие безопасное разделяемое использование данных между внутренними и внешними системами. Чистый архитектурный подход, который пригодился бы в данном случае – гибкая интеграция. Так оптимизируется доступ к данным и управление удаленными ресурсами. Открывая доступ к API, компания может предоставить унифицированные интерфейсы для обмена данными и транзакциями внештатным и штатным разработчикам, партнерам и клиентам. Учитывая, как важны API при работе с IoT, организация просто обязана эффективно управлять этими API. Предоставляя четко определенные API, разработчики могут программно использовать данные: например, разработчик приложений может обратиться к данным с устройств IoT, не вникая, на каких аппаратных интерфейсах базируются эти системы. Да, API считаются основополагающим фактором внедрения IoT, однако, ими нужно разумно управлять; без такого управления бесконтрольное размножение API может легко привести к катастрофе.

Кроме того, при мониторинге API можно выявить аномалии в различных практических ситуациях и принять корректирующие меры в реальном времени. Управление API обеспечивает их единообразие в различных приложениях, бизнес-моделях, а также у разных заинтересованных сторон.

Компоненты управления API

Это должен быть хорошо масштабируемый обратный прокси-сервер с высокой пропускной способностью, например, Nginx. Наиболее заметный компонент, участвующий в управлении API — это шлюз, слушающий трафик с API. Шлюз может быть расположен на предприятии или в облаке, но в идеале – там же, где и машинный интерфейс.

Менее заметные, но не менее важные компоненты решения для управления API – это аспекты безопасности, политики использования, регулирующие такие вопросы как ограничение частоты, аналитика, отчетность, портал разработчика и монетизация.

Например, подойдет механизм OpenID Connect, который может хранить эталонный идентификатор и играть роль брокера, обслуживающего различные учетные записи в социальных сетях или в корпоративных приложениях (скажем, Google, LDAP, Active Directory и Kerberos). Для поддержки систем с отличающимися возможностями необходимо поддерживать самые разные механизмы усиления безопасности, управления доступом и контроля, в частности: ключ API, токены, OAuth или внешнее управление идентификационными данными.

В автомобильном приложении Nissan Leaf для вызова различных сервисов, к которым подключена машина, использовался только идентификационный номер транспортного средства (VIN). Используя API без аутентификации, мы рискуем потерять данные или столкнуться с проблемами безопасности – как в недавнем эпизоде, когда был взломан API Nissan Leaf. Следовательно, доступ ко всем устройствам Интернета вещей, даже к тем, что расположены за корпоративным брандмауэром, должны регулироваться четко прописанными политиками безопасности. Представьте себе, каковы риски, если применить подобный метод – то есть, доступ к машинному интерфейсу через API, не предусматривающий аутентификации – будет применен в модуле управления автомобилем или в другом критически важном узле IoT-инфраструктуры.

Так обеспечивается дополнительный уровень безопасности в инфраструктуре IoT. Компания должна уметь выставлять различные уровни доступа и ограничения частоты для различных категорий пользователей, типов устройств и типов данных. Учитывая, что во многих IoT-устройствах нет никаких механизмов безопасности, а также не проводится регулярных обновлений, разумно не допускать к этим устройствам никакого непосредственного доступа, кроме как через API-шлюз, служащий брандмауэром. Например, если взломанное устройство начинает пересылать аномальные объемы данных (как в случае DDoS-атаки), то такое инфицированное устройство можно быстро обнаружить, изолировать и вывести из сети, прежде чем оно успеет навредить всей системе.

Так можно определить, какие API и терминалы наиболее популярны, а какие не используются. Благодаря аналитике и отчетности можно отслеживать и наблюдать использование API и принимать меры, когда пользователь достигает некоторых критических значений. Мониторинг использования API также способствует монетизации: можно тарифицировать доступ пользователей к API или фактическое потребление этого API.

Данные об обращении разработчиков к устройствам и системам можно динамически обновлять в ходе жизненного цикла проекта – например, на этапе разработки предоставлять неограниченный доступ ко всем устройствам IoT, а после того, как устройства развернуты в продакшен – ограничивать такой доступ. Портал разработчика позволяет зарегистрироваться на использование API, извлечь учетные данные API, в том числе, ключи, найти документацию по этому API и отслеживать его производительность.

Важные замечания

В этом решении следует размежевывать управляющие узлы и управление политиками. Чтобы не возникало единой точки отказа, решение для управления API должно быть распределенным, отлично масштабироваться и развертываться в разнообразных средах (как на предприятии, так и в облаке). Для достижения желаемой гибкости решение также должно поддаваться автоматизации; в данном случае удобно использовать популярные свободные инструменты, например, Ansible, Puppet и Chef.

Менеджер политик API можно вызывать асинхронно, в соответствии с требованиями Соглашений об уровне предоставления услуг (SLA).
Такой подход позволяет поддерживать высокую производительность и минимальные задержки, что очень важно для решений в сфере IoT. При работе с данными IoT с ограниченным сроком действия задержки должны быть минимальными; поэтому нужно организовать локальное кэширование ключей/токенов на шлюзе API, чтобы вызов мог проходить напрямую через API.

На этом уровне должны использоваться такие свободные проекты как Apache Camel или Red Hat JBoss Fuse (в продакшене). Что касается оснащения шлюза дополнительными функциями, например, адаптерами протоколов, рекомендуется не смешивать реализации этих возможностей (интеграция, опосредование или преобразование данных) и помещать их на уровне интеграции, расположенном за шлюзом API.

Kapua демонстрирует, как опенсорсные инновации открывают доступ к управлению IoT-шлюзами и граничными устройствами. В качестве примера управления API в бизнес-модели с использованием IoT можно назвать проект Kapua, которым занимается рабочая группа Eclipse по внедрению IoT. Для интеграции с существующими приложениями Eclipse Kapua предусматривает REST API, предоставляющий весь функционал платформы. Здесь предоставляется не только базовый фреймворк для интеграции, но и набор IoT-сервисов, в том числе, реестр устройств, сервисы для управления устройствами, сервисы обмена сообщениями, управления данными и активации приложений.

Здесь задействуются такие технологии как REST/Comet/WebSockets, позволяющие в реальном времени публиковать данные, публикуемые устройствами на веб-страницах и мобильных информационных панелях. Этот REST API также предлагает выход на брокер MQTT, обеспечивающий маршрутизацию команд от приложений на устройства и не требующий специфичного соединения с брокером сообщений.

Применяя метод гибкой интеграции, можно предложить все решение в виде набора контейнерных микросервисов. Благодаря управлению на уровне API, сервисы Eclipse Kapua можно публично предоставлять через шлюз API. Работая с платформой для оркестрации контейнеров, например, с Kubernetes, мы дополнительно выигрываем, поскольку приобретаем возможность автоматического масштабирования ресурсов по мере того, как растет наша конфигурация IoT.

Заключение

API были популяризованы благодаря широкому применению таких сервисов как карты Google, а теперь образуют фундамент пользовательских взаимодействий в цифровом мире. API – один из основных механизмов, обеспечивающих работу крупного цифрового предприятия и один из ключевых аспектов в концепции гибкой интеграции. API превращаются в основной механизм коммуникации между разрозненными IoT-системами и удобны как штатным, так и внештатным разработчикам, а также партнерам и клиентам. Быстрые адаптивные решения из области IoT особенно выигрывают от гибкой интеграции с применением современных платформ, процессов и технологий. Учитывая, как важны API для IoT, организация просто обязана управлять этими API эффективно.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть