Здравствуйте, коллеги.
Сегодня хотим обсудить с вами такую нетривиальную тему как архитектура IoT для больших предприятий. Популяризация IoT на русском языке идет полным ходом, однако на английском языке уже выходят первые серьезные книги об архитектуре таких решений в масштабе (больших) предприятий. Нас изрядно заинтересовала следующая книга Перри Ли (Perry Lea):
Просим вас активно высказываться насчет актуальности этой книги. Если кто-то хочет поделиться реальным опытом реализации промышленного IoT в России и/или отрецензировать перевод книги — также пишите.
Под катом предлагаем перевод публикации Red Hat, где рассмотрены вопросы грамотного и безопасного проектирования API для IoT-систем
Суть IoT – в управлении данными. Интернет вещей получает данные с устройств, отправляет команды на устройства, интегрирует данные IoT с другой информацией, на основании чего делает выводы. Источники данных – это, в частности, устройства, корпоративные системы, системы поставщиков и партнеров, а также информация от провайдеров и клиентов. Интегрировать все эти системы по принципу «точка-точка» невозможно, поэтому основным механизмом связи между этими разрозненными системами станут API. Чистый архитектурный подход, который пригодился бы в данном случае – гибкая интеграция. Центральную роль в нем играют именно API, обеспечивающие безопасное разделяемое использование данных между внутренними и внешними системами. Открывая доступ к API, компания может предоставить унифицированные интерфейсы для обмена данными и транзакциями внештатным и штатным разработчикам, партнерам и клиентам. Так оптимизируется доступ к данным и управление удаленными ресурсами. Предоставляя четко определенные API, разработчики могут программно использовать данные: например, разработчик приложений может обратиться к данным с устройств IoT, не вникая, на каких аппаратных интерфейсах базируются эти системы. Учитывая, как важны API при работе с IoT, организация просто обязана эффективно управлять этими API. Да, API считаются основополагающим фактором внедрения IoT, однако, ими нужно разумно управлять; без такого управления бесконтрольное размножение API может легко привести к катастрофе.
Управление API обеспечивает их единообразие в различных приложениях, бизнес-моделях, а также у разных заинтересованных сторон. Кроме того, при мониторинге API можно выявить аномалии в различных практических ситуациях и принять корректирующие меры в реальном времени.
Компоненты управления API
Наиболее заметный компонент, участвующий в управлении API — это шлюз, слушающий трафик с API. Это должен быть хорошо масштабируемый обратный прокси-сервер с высокой пропускной способностью, например, Nginx. Шлюз может быть расположен на предприятии или в облаке, но в идеале – там же, где и машинный интерфейс.
Менее заметные, но не менее важные компоненты решения для управления API – это аспекты безопасности, политики использования, регулирующие такие вопросы как ограничение частоты, аналитика, отчетность, портал разработчика и монетизация.
Для поддержки систем с отличающимися возможностями необходимо поддерживать самые разные механизмы усиления безопасности, управления доступом и контроля, в частности: ключ API, токены, OAuth или внешнее управление идентификационными данными. Например, подойдет механизм OpenID Connect, который может хранить эталонный идентификатор и играть роль брокера, обслуживающего различные учетные записи в социальных сетях или в корпоративных приложениях (скажем, Google, LDAP, Active Directory и Kerberos).
Используя API без аутентификации, мы рискуем потерять данные или столкнуться с проблемами безопасности – как в недавнем эпизоде, когда был взломан API Nissan Leaf. В автомобильном приложении Nissan Leaf для вызова различных сервисов, к которым подключена машина, использовался только идентификационный номер транспортного средства (VIN). Представьте себе, каковы риски, если применить подобный метод – то есть, доступ к машинному интерфейсу через API, не предусматривающий аутентификации – будет применен в модуле управления автомобилем или в другом критически важном узле IoT-инфраструктуры. Следовательно, доступ ко всем устройствам Интернета вещей, даже к тем, что расположены за корпоративным брандмауэром, должны регулироваться четко прописанными политиками безопасности.
Компания должна уметь выставлять различные уровни доступа и ограничения частоты для различных категорий пользователей, типов устройств и типов данных. Так обеспечивается дополнительный уровень безопасности в инфраструктуре IoT. Например, если взломанное устройство начинает пересылать аномальные объемы данных (как в случае DDoS-атаки), то такое инфицированное устройство можно быстро обнаружить, изолировать и вывести из сети, прежде чем оно успеет навредить всей системе. Учитывая, что во многих IoT-устройствах нет никаких механизмов безопасности, а также не проводится регулярных обновлений, разумно не допускать к этим устройствам никакого непосредственного доступа, кроме как через API-шлюз, служащий брандмауэром.
Благодаря аналитике и отчетности можно отслеживать и наблюдать использование API и принимать меры, когда пользователь достигает некоторых критических значений. Так можно определить, какие API и терминалы наиболее популярны, а какие не используются. Мониторинг использования API также способствует монетизации: можно тарифицировать доступ пользователей к API или фактическое потребление этого API.
Портал разработчика позволяет зарегистрироваться на использование API, извлечь учетные данные API, в том числе, ключи, найти документацию по этому API и отслеживать его производительность. Данные об обращении разработчиков к устройствам и системам можно динамически обновлять в ходе жизненного цикла проекта – например, на этапе разработки предоставлять неограниченный доступ ко всем устройствам IoT, а после того, как устройства развернуты в продакшен – ограничивать такой доступ.
Важные замечания
Чтобы не возникало единой точки отказа, решение для управления API должно быть распределенным, отлично масштабироваться и развертываться в разнообразных средах (как на предприятии, так и в облаке). В этом решении следует размежевывать управляющие узлы и управление политиками. Для достижения желаемой гибкости решение также должно поддаваться автоматизации; в данном случае удобно использовать популярные свободные инструменты, например, Ansible, Puppet и Chef.
При работе с данными IoT с ограниченным сроком действия задержки должны быть минимальными; поэтому нужно организовать локальное кэширование ключей/токенов на шлюзе API, чтобы вызов мог проходить напрямую через API. Менеджер политик API можно вызывать асинхронно, в соответствии с требованиями Соглашений об уровне предоставления услуг (SLA).
Такой подход позволяет поддерживать высокую производительность и минимальные задержки, что очень важно для решений в сфере IoT.
Что касается оснащения шлюза дополнительными функциями, например, адаптерами протоколов, рекомендуется не смешивать реализации этих возможностей (интеграция, опосредование или преобразование данных) и помещать их на уровне интеграции, расположенном за шлюзом API. На этом уровне должны использоваться такие свободные проекты как Apache Camel или Red Hat JBoss Fuse (в продакшене).
В качестве примера управления API в бизнес-модели с использованием IoT можно назвать проект Kapua, которым занимается рабочая группа Eclipse по внедрению IoT. Kapua демонстрирует, как опенсорсные инновации открывают доступ к управлению IoT-шлюзами и граничными устройствами. Здесь предоставляется не только базовый фреймворк для интеграции, но и набор IoT-сервисов, в том числе, реестр устройств, сервисы для управления устройствами, сервисы обмена сообщениями, управления данными и активации приложений. Для интеграции с существующими приложениями Eclipse Kapua предусматривает REST API, предоставляющий весь функционал платформы.
Этот REST API также предлагает выход на брокер MQTT, обеспечивающий маршрутизацию команд от приложений на устройства и не требующий специфичного соединения с брокером сообщений. Здесь задействуются такие технологии как REST/Comet/WebSockets, позволяющие в реальном времени публиковать данные, публикуемые устройствами на веб-страницах и мобильных информационных панелях.
Благодаря управлению на уровне API, сервисы Eclipse Kapua можно публично предоставлять через шлюз API. Применяя метод гибкой интеграции, можно предложить все решение в виде набора контейнерных микросервисов. Работая с платформой для оркестрации контейнеров, например, с Kubernetes, мы дополнительно выигрываем, поскольку приобретаем возможность автоматического масштабирования ресурсов по мере того, как растет наша конфигурация IoT.
Заключение
API – один из основных механизмов, обеспечивающих работу крупного цифрового предприятия и один из ключевых аспектов в концепции гибкой интеграции. API были популяризованы благодаря широкому применению таких сервисов как карты Google, а теперь образуют фундамент пользовательских взаимодействий в цифровом мире. Быстрые адаптивные решения из области IoT особенно выигрывают от гибкой интеграции с применением современных платформ, процессов и технологий. API превращаются в основной механизм коммуникации между разрозненными IoT-системами и удобны как штатным, так и внештатным разработчикам, а также партнерам и клиентам. Учитывая, как важны API для IoT, организация просто обязана управлять этими API эффективно.
Автор: ph_piter
