Microsoft Azure Service Bus и Интернет вещей. Часть 1

Межмашинные (machine-to-machine, M2M) вычисления быстро становятся технологией, которой нужно научиться пользоваться всем разработчикам и архитекторам. Во множестве исследований приходят к выводу, что к 2020 году в мире будут насчитываться десятки миллиардов устройств (по полдесятка на каждого жителя Земли) (bit.ly/M2qBII). Одна из причин появления этой технологии заключается в том, что еще никогда не было столь легко для «гаражных умельцев» и любителей создавать прототипы потребительских или коммерческих устройств для будущего производства и продаж. Стоимость начального набора аппаратно-программного обеспечения невероятно низка. Менее чем за $100 можно заказать и приобрести комплект Arduino или Raspberry PI.

Но вы действительно получаете то, за что платите, и эти устройства, особенно Arduino, представляют нижний уровень аппаратных возможностей. Обладая 32 Кб флеш-памяти и 4 Кб оперативной памяти, они не позволяют работать с чем-либо, кроме простейших аспектов веб-стека. Arduino — это микроконтроллер с открытым исходным кодом, оборудованный небольшим чипом, малым объемом памяти и хранилищем. Программное обеспечение состоит из стандартного компилятора языка программирования и начального загрузчика, выполняемого микроконтроллером. Вы можете добавить платы расширения, подключаемые к устройству, в том числе средства управления моторами, GPS, Ethernet, ЖК-дисплей, датчики, сервоприводы и др. Заплатите немного больше и вы получите более мощный Raspberry PI, который поставляется с компактной версией операционной системы GNU/Linux и 256 Кб оперативной памяти.

От этих устройств мало толку, пока вы не подключите их к чему-то другому, возможно, к облачному сервису, который принимает данные и отправляет команды. Но подключение этих устройств, взаимодействие с ними и управление ими из приложений, работающих в облаке, вызывает некоторые специфические трудности. Огромное количество устройств с ограниченными емкостями аккумуляторов и пропускной способностью вынуждает разработчиков в облаке тщательно продумывать все варианты.

В этой статье мы рассмотрим, как разработчики пытаются преодолеть основные трудности, связанные с адресацией, полосой пропускания и безопасностью. Мы развеем миф о том, что IPv6 и виртуальные частные сети (VPN) являются простыми, эффективными и безопасными и предложим идеальный продукт для элегантного преодоления эти трудностей — Microsoft Azure Service Bus. Чтобы растолковать некоторые концепции, мы представим четыре шаблона, которые можно использовать на клиентском устройстве при взаимодействии с серверной частью в облаке. Наконец, мы предложим краткое введение в поддержку Service Bus для Advanced Message Queuing Protocol (AMQP) 1.0 — межоперационного и эффективного протокола взаимодействия между устройствами и облаком.

В течение многих лет обеспечение безопасных соединений подразумевало применение TCP/IP с IPv4 в комбинации с VPN. Это неплохо работало, но теперь такое решение выказывает все признаки устаревания. Начнем с того, что получить уникальный IP-адрес в общедоступной Интернете для использования с устройством весьма трудно; пул IP-адресов почти исчерпан. Упорные приверженцы этого подхода обещают, что нас спасет IPv6. Расхожее мнение насчет того, что, если присвоить устройству уникальный IP-адрес, все ваши сложные проблемы будут решены. К сожалению, это решает лишь малую часть общей проблемы. Выдача каждому устройству уникального IP-адреса — явно не панацея, как на то многие надеялись.

Просто чтобы прояснить ситуацию, IPv6 и VPN грозят проблемами в мире, переполненном подключенными устройствами. В частности, крупной проблемой является полоса пропускания. Слишком «болтливые» соединения между устройством и сетью могут создавать избыточный трафик. Более того, использование типичных подходов на основе HTTP-запроса/ответа для всех коммуникаций быстро сажают аккумуляторы на многих устройствах. И, вероятно, самое главное в том, что безопасность не гарантирована. VPN определенно не обеспечивают защиту в некоторых сценариях. Прежде чем представить решение, давайте немного поглубже исследуем все эти проблемы.

Устройства, создающие избыточный сетевой трафик при взаимодействии с серверной частью в облаке, являются источником проблем. Полоса пропускания стоит денег — и потенциально весьма немалых, если «болтливых» устройств много. Кроме того, больший объем данных приводит к более активному использованию процессора, а значит, устройство потребляет больше электроэнергии, которая является драгоценным ресурсом на мобильном устройстве. Большинство устройств на аккумуляторах, оснащенных передатчиком Wi-Fi и SIM-картой, должны переходить в режим сна с малым энергопотреблением в те периоды, когда они не передают и не принимают данные. Эта функция опроса перехода в режим экономии определена в стандарте IEEE 802.11. Когда устройство находится в режиме сна, данные буферизуются. Как только оно просыпается, эти буферизованные данные доставляются адресату. «Болтливые» сети быстро заполняют буферы и преждевременно пробуждают спящие устройства.

Подходы с HTTP-запросом/ответом могут быть неэкономичны до абсурда, учитывая размер полезных данных по сравнению с общей инфраструктурой HTTP-запросов/ответов. Допустим, устройству нужно просто сообщить некое число в облако, например показания температуры, давления или GPS-координаты. Эти двоичные данные, по-видимому, занимают всего несколько байтов, но HTTP POST, как правило, имеет размер минимум от 500 до 1000 байтов, при этом один только заголовок запроса варьируется в диапазоне от 200 до 2000 байтов. Конечно, некоторые разработчики прибегают ко всяческим трюкам вроде размещения всех данных в HTTP-заголовке, чтобы избежать издержек, неизбежных при наличии тела HTTP-запроса. Но этого не достаточно, и размер HTTP-запроса лишь увеличивается, когда вы должны передавать удостоверения защиты.

Немного простейшей арифметики, чтобы убедить вас. Вообразите, что ваше устройство должно посылать данные по температуре через каждые пять секунд и что их объем почти 20 байтов. За сутки объем самих данных по температуре, которые надо передать с устройства в облако, составил бы около 350 000 байтов. Если к ним добавить размер конверта HTTP-запроса/ответа, объем каждой передачи возрос бы на 800 байтов (в 41 раз), и вы отправляли бы в облако 14 Мб вместо всего 350 Кб. Стоимость передачи такого объема данных может стать неприемлемо дорогостоящей, если вы поддерживаете тысячи устройств.

Вероятно, самое крупное заблуждение в том, что VPN-сетям изначально присуща безопасность. Реальность такова, что VPN-сети могут быть рискованными, особенно когда устройства, подключенные к VPN, находятся вне физической досягаемости оператора или производителя. Стоит лишь взломать одно устройство, как уязвимыми окажутся все устройства, подключенные к той же VPN. Как только постороннее лицо получает доступ к подключенному устройству, он или она может использовать это устройство для анализа ваших внутренних ресурсов и атаки на них. Несмотря на эти недостатки, VPN-сети часто являются единственным вариантом, предлагаемым многими провайдерами.

Подход с использованием Microsoft Azure Service Bus

Microsoft Azure Service Bus предлагает много превосходных решений этих трудных задач. Использование Service Bus более безопасно, потому что устройство является единственной конечной точкой в Интернете, где оно может помещать сообщения в очередь. Устройству недоступны другие защищенные ресурсы в облачных сервисах. Кроме того, применение Service Bus для подключения устройства обходится дешевле в плане энергопотребления, так как она может чаще и дольше пребывать в режиме сна, периодически пробуждаясь для извлечения сообщений, ожидающих в очереди.

Service Bus обеспечивает еще больше преимуществ, поскольку можно:

• отделить коммуникации устройства от его взаимодействия с облачным сервисом;
• включить сглаживание нагрузки (load leveling) и ее балансировку между несколькими экземплярами сервиса;
• идентифицировать дубликаты сообщений;
• собирать сообщения в логические группы (они называются Sessions);
• реализовать транзакционное поведение и атомарность операций;
• поддерживать упорядоченную доставку сообщений и задавать время жизни каждого сообщения;
• легко переходить к сценариям публикации-подписки, используя Topics и Subscriptions.

Чтобы получить более конкретное представление о том, как устройство подключается и взаимодействует с облачными сервисами, взгляните на рис. 1. Здесь показано, как устройство специального назначения может быть включено в более крупную архитектуру. Мы используем канонический пример OpenSprinkler — контроллер клапаном установки полива/разбрызгивателя (системы орошения) с открытым исходным кодом, управляемый через Интернет. Он способен проверять погодные условия и на основе этих данных принимать решение, следует ли включать воду. Контроллер построен с использованием частей Arduino. Обратите внимание на рис. 1, что Arduino управляет системой орошения, используя домашнюю сеть как интернет-соединение и взаимодействует с облачными сервисами.

Рис. 1. Эталонная архитектура системы орошения на основе Arduino

Home Network	Домашняя сеть
Arduino Sprinkler Controller	Контроллер системы орошения на основе Arduino
Sprinkler Valve	Клапан системы орошения
HTTP	HTTP
Data/State	Данные/состояние
NoSQL Database	База данных NoSQL
Blob	Blob
Service Bus	Service Bus
Worker Role	Рабочая роль
National Weather Service	Национальная метеорологическая служба
Microsoft Azure	Microsoft Azure
Linux Virtual Machine Python	Python, выполняемый в Linux VM
Admin Web Role	Административная веб-роль
Mobile Services	Мобильные сервисы

Решение проблем подключения

Microsoft Azure Service Bus отлично справляется с решением проблем адресации и сетевых подключений. Устройство Arduino, по-видимому, будет расположено за неким уровнем NAT, что затрудняет обращение к нему из облачного сервиса. К счастью, Service Bus радикально упрощает подключения, выступая в роли сервиса ретрансляции (relay service) и прокси для облачных сервисов. Более того, она может предоставить Queues, Topics и Subscriptions, которые позволяют ей действовать как концентратор событий (event hub) для сообщений, посылаемых между облаком и устройством. Отделенная природа очереди, выступающей в качестве ретранслятора, дает возможность устройству асинхронно отправлять сообщения в облако и принимать их оттуда, даже если оно подключается лишь время от времени. По соображениям безопасности устройство может аутентифицироваться с помощью SharedAccessSignature, SharedSecret, SAML или SimpleWebToken.

Заметьте, что на рис. 1 читать из очереди сообщений Service Bus может одна или более рабочих ролей. Рабочие роли могут принимать решения и выдавать команды устройству. Другие рабочие роли могут получать метеорологическую информацию от иных систем, например от Национальной метеорологической службы (National Weather Service). Кроме того, рабочие роли способны сохранять все необработанные входящие события в базе данных NoSQL, такой как MongoDB.

На рис. 1 также показано взаимодействие мобильных пользователей с веб-ролями для планирования полива. Мобильные пользователи могут получать оповещения от Microsoft Azure Mobile Services (WAMS), которая поддерживает все основные сети уведомлений, например Windows Notification Services (WNS), Microsoft Push Notification Service (MPNS), Apple Push Notification Service (APNS) и Google Cloud Messaging for Android (GCM). WAMS упрощает поддержку Windows, iOS и Android.

Вы можете даже представить себе машинно-обучаемую часть этой архитектуры. Microsoft Azure способна поддерживать Linux VM (виртуальные машины), и можно довольно легко сконфигурировать PyMongo (Python-драйвер для MongoDB) на чтение потока событий, создаваемых разнообразными устройствами, и применять методы машинного обучения в PyML, чтобы находить шаблоны или делать предсказания о данных потока событий. На основе определенных предсказаний или шаблонов облачный сервис может по своему выбору отправлять команды устройству, например включить или выключить воду.

Система обмена сообщениями (основная конечная точка для отправки и приема данных) является расширяемой, поскольку устройства могут продолжать посылать один поток сообщений, но для каждой новой системы, которая будет использовать этот поток сообщений, к Service Bus Topic можно добавлять новые Subscriptions. Эти системы могут быть предназначены для анализа в реальном времени и машинного обучения, а также для других сценариев, описанных ранее.

Коммуникация с облаком

Существует четыре шаблона, применимых на клиенте для коммуникации с облачным сервисом. Они кратко описаны в табл. 1.

Табл. 1. Четыре шаблона коммуникации между устройством и облачным сервисом

Шаблон	Краткое описание	Пример
Telemetry	Клиентское устройство посылает данные (односторонне) облачному сервису	Устройство публикует сообщения о температуре в Topics. Облачный сервис подписывается на некоторые или все эти сообщения о температуре
Inquiry	Клиентское устройство посылает запрос облачному сервису и принимает ответ	Устройство запрашивает прогнозируемые метеоусловия, помещая соответствующий запрос в Topic. Облачный сервис подписывается на эти запросы и посылает сообщение-ответ в свой Topic, на который подписывается устройство
Command	Облачный сервис выдает команду клиентскому устройству, и это устройство возвращает в ответе об успехе или неудаче выполнения команды	Облачный сервис публикует сообщение/команду по температуре в Topic, на который подписано устройство. Затем устройство включает или выключает воду и возвращает ответ облачному сервису, публикуя этот ответ в Topic
Notification	Облачный сервис выдает по вспомогательному каналу (out-of-band) одностороннее уведомление клиентскому устройству, важное для работы этого устройства	Облачный сервис посылает устройству сообщение сброса времени (time-reset message), публикуя это сообщение в Topic, на который подписано данное устройство

Все четыре шаблона используют Service Bus Topics и Subscriptions. В зависимости от направления коммуникации (от устройства к облачному сервису или от облачного сервиса к устройству) устройство может либо подписываться на темы (topics) или публиковать в них. Topics — это просто механизм для отправки сообщений, а подписки (subscriptions) служат для использования сообщений. Вы можете создать правила фильтрации для подписок, чтобы обеспечить более детализированный контроль над тем, какие сообщения будут извлекаться. Рабочие роли в облачном сервисе можно применять для публикации сообщений в темах или для использования сообщений из подписок.

Из-за нехватки места в этой статье мы не в состоянии проиллюстрировать все шаблоны, поэтому рассмотрим подробно лишь один из них. На рис. 2 показана эталонная реализация шаблона Command. Она демонстрирует, что устройства из зданий 1 и 2 могут подписываться на сообщения (Commands) и возвращать ответы в темы. Заметьте, что рабочие роли в облачном сервисе могут публиковать сообщения в Temperature and Shade Command Topic и что конкретные устройства могут раздельно подписываться на сообщения Temperature Control или Shade Control. Service Bus Topics и Subscriptions можно использовать в самых разнообразных сочетаниях для необходимого вам разделения потока сообщений.

Рис. 2. Архитектура шаблона Command

Building 1	Здание 1
Device	Устройство 1
Service Bus	Service Bus
Temperature Control Subscription	Temperature Control Subscription
Shade Control Subscription	Shade Control Subscription
Temperature and Shade Response Topic	Temperature and Shade Response Topic
Temperature and Shade Command Topic	Temperature and Shade Command Topic
Temperature Response Subscription	Temperature Response Subscription
Shade Response Subscription	Shade Response Subscription
Worker Role for Temperature Control	Рабочая роль для Temperature Control
Worker Role for Shade Control	Рабочая роль для Shade Control
Worker Role for Temperature Response	Рабочая роль для Temperature Response
Worker Role for Shade Response	Рабочая роль для Shade Response
Microsoft Azure	Microsoft Azure

AMQP и межсетевое взаимодействие

Группа Microsoft Azure Service Bus недавно объявила о поддержке Advanced Message Queuing Protocol (AMQP) 1.0, открытого стандарта с двоичным прикладным уровнем (binary application layer) для ориентированного на сообщения промежуточного ПО. Его главная ценность в том, что он обладает высокой степенью совместимости и использует двоичный формат при передаче информации по несущим средам для минимизации размера пересылаемых данных.

AMQP поддерживает надежную передачу сообщений, очереди, маршрутизацию, публикацию/подписку и др. Поскольку это протокол уровня несущей среды (wire-level protocol), ориентированный на потоковую передачу данных по сети, любое совместимое средство может взаимодействовать с данными независимо от языка реализации. Это позволяет кросс-платформенным, гибридным приложениям использовать открытый стандартный протокол. Библиотека обеспечивает смешанное применение языков, инфраструктур и операционных систем, поддерживая .NET, Java, Python и PHP. Более подробную информацию вы найдете на странице Microsoft Azure Samples по ссылке aka.ms/G3izk8. AMQP отлично подходит для многих современных устройств, которым необходимы подключения к облачным сервисам.

Однако AMQP для нынешнего Arduino — это перебор, так как подобным устройствам недостает необходимой памяти, хранилища и вычислительных ресурсов. Выполнение AMQP требует поддержки Transport Layer Security (TLS), протокола шифрования, который обеспечивает защиту коммуникаций по TCP. TLS использует сертификаты X.509 (асимметричное шифрование) для проверки идентификации сторон, взаимодействующих по сети. Кроме того, с AMQP часто интегрируется клиентская библиотека обмена сообщениями, Apache Qpid Proton; это упрощает коммуникации через маршрутизаторы, мосты и прокси. Все это вызывает вопрос: как поддерживать устройства класс «low-end», подключенные к облачным сервисам, и в то же время использовать преимущества инфраструктуры обмена сообщениями Service Bus?

Один из вариантов — заплатить больше денег и приобрести Raspberry PI. Если вы не хотите этого, вам понадобится больше креативности. Можно начать с использования кода Клеменса Вастерса (Clemens Vasters) по ссылке bit.ly/1acvLdS, который позволяет Arduino принимать команду мигнуть LED-индикатором на микроконтроллере. Этот код реализует шлюз устройства (device gateway), предоставляя конечную точку TCP, к которой подключается Arduino. Для поддержания соединения через NAT и балансировщик нагрузки Microsoft Azure облачному сервису нужно посылать Arduino команду ping через каждые 235 секунд (чуть меньше четырех минут). Детали см. в проекте Вастерса на C#, который называется LedBlinkerServer.

В следующей статье мы постараемся подробно объяснить, как работает этот код и как заставить Arduino посылать сообщения в Service Bus и принимать их от нее.

Заключение

В этой статье мы представили четыре шаблона, которые можно использовать для надежного обмена сообщениями между устройством и облачными сервисами. Мы познакомили вас с AMQP, протоколом для работы с очередями сообщений с открытым исходным кодом; он помогает повысить уровень совместимости, минимизировать занимаемую полосу пропускания и полностью поддерживается Microsoft Azure Service Bus. Наконец, мы начали обсуждать, как обеспечить подключение устройств класса «low-end» к облачным сервисам, используя инфраструктуру обмена сообщениями Service Bus, и эту тему мы продолжим в следующей статье.

Мы хотели бы поблагодарить Клеменса Вастерса и Абишека Лала за помощь в понимании совершенно нового мира подключенных устройств. Очевидно, что мир специализированных устройств, подключенных к облачным сервисам, стремительно расширяется. Традиционные подходы к взаимодействию с облачными сервисами нуждаются в переоценке. Безопасность, полоса пропускания, надежность сети и высокий уровень взаимодействия и совместимости — вот лишь некоторые из трудных задач, стоящих перед архитекторами и разработчиками специализированных устройств в M2M-мире. Применение Microsoft Azure Service Bus делает эти задачи гораздо менее устрашающими.