Эталонная архитектура Интернета вещей Azure

Хранилище BLOB-объектов
Функции
Центр Интернета вещей
Logic Apps
Stream Analytics

В этой эталонной архитектуре показана рекомендуемая архитектура для приложений Интернета вещей в Azure, использующая компоненты платформы как услуги (PaaS).

Схема архитектуры

Приложения Интернета вещей можно описать как вещи (устройства) для передачи данных, которые создают аналитические сведения. Эти сведения создают действия для улучшения компании или процессов. Например, модуль (вещь), отправляющий данные температуры. Эти данные используются для оценки правильности работы модуля (анализ). Аналитические сведения используются, чтобы упреждающе назначить приоритет расписания обслуживания для модуля (действие).

Эта эталонная архитектура использует компоненты Azure PaaS (платформа как услуга). Еще один рекомендуемый вариант создания решений IoT в Azure:

  • IOT Central Azure. IoT Central — это полностью управляемое решение SaaS (программное обеспечение как услуга). Оно абстрагирует технические решения и позволяет сосредоточиться исключительно на собственном. Однако вместе с простотой вы получаете меньше настраиваемых решений, чем в решении на основе PaaS.

На высшем уровне существует два способа обработки данных телеметрии: "горячий" и "холодный" путь. Разница связана с требованиями к задержке и доступу к данным.

  • "Горячий" путь позволяет анализировать данные в режиме реального времени по мере их поступления. При применении этого способа данные телеметрии должны обрабатываться с очень низкой задержкой. "Горячий" путь обычно реализуется с помощью подсистемы потоковой обработки. Выходные данные могут инициировать оповещение или записываться в структурированный формат, который можно запросить с помощью средств аналитики.
  • "Холодный" путь позволяет выполнить пакетную обработку в течение более длительных интервалов (ежечасно или ежедневно). "Холодный" путь обычно работает с большими объемами данных, однако результаты не требуются также своевременно, как в "горячем" пути. В "холодном" пути собираются необработанные данные телеметрии, а затем передаются в процесс пакетной обработки.

Архитектура

Архитектура состоит из следующих компонентов. Для некоторых приложений могут требоваться лишь некоторые из перечисленных здесь компонентов.

Устройства IOT. Устройства можно безопасно зарегистрировать в облаке и подключать к нему для отправки и получения данных. Некоторые устройства могут быть пограничными устройствами, выполняющими определенную обработку данных на самом устройстве или в полевом шлюзе. Мы рекомендуем использовать Azure IoT Edge для обработки пограничных устройств.

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

Подготовка устройства. При регистрации и подключении большого набора устройств мы рекомендуем использовать Службу подготовки устройств к добавлению в Центр Интернета вещей (DPS). DPS позволяет назначать и регистрировать устройства в определенные конечные точки Центра Интернета вещей Azure в нужном масштабе.

Потоковая обработка. Потоковая передача анализирует большие потоки записей данных и оценивает правила для этих потоков. Для обработки потоков данных рекомендуем использовать Azure Stream Analytics. Stream Analytics может выполнять сложный анализ в необходимом масштабе с помощью функций ограничения окна, агрегаций потока и внешних соединителей источников данных. Кроме того, вы можете использовать Apache Spark в Azure Databricks.

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

Хранилище "горячего" пути содержит данные, которые должны быть сразу же доступны на устройстве для создания отчетов и визуализации. В качестве хранилища "горячего" пути мы рекомендуем использовать Cosmos DB. Cosmos DB — это многомодельная глобально распределенная база данных.

Хранилище "холодного" пути содержит данные, которые хранятся долгосрочно и используются в пакетной обработке. В качестве хранилища "холодного" пути мы рекомендуем использовать хранилище BLOB-объектов Azure. Данные можно заархивировать в хранилище BLOB-объектов на неопределенное время без лишних затрат. Такие данные легко доступны для пакетной обработки.

При преобразовании данных выполняются действия с потоком данных телеметрии или его объединение. Примеры включают преобразование протоколов, например, преобразование двоичных данных в JSON или объединение точек данных. Если данные необходимо преобразовать до поступления в Центр Интернета вещей, мы рекомендуем использовать шлюз протокола (не показано). В противном случае данные можно преобразовать после поступления в Центр Интернета вещей. В этом случае мы рекомендуем использовать Функции Azure. Это решение поддерживает интеграцию с Центром Интернета вещей, Cosmos DB и хранилищем BLOB-объектов.

При интеграции бизнес-процессов действия выполняются на основе аналитических сведений из данных устройства. Сюда входит хранение информационных сообщений, создание оповещений, отправка электронной почты или текстовых сообщений или интеграция с CRM. Для интеграции бизнес-процессов мы рекомендуем использовать Azure Logic Apps.

Управление пользователями позволяет настроить ограничение пользователей или групп для выполнения действий на устройствах, таких как обновление встроенного ПО. Оно также определяет возможности для пользователей в приложениях. Для аутентификации и авторизации пользователей мы рекомендуем использовать Azure Active Directory.

Средство мониторинга безопасности Azure Security Center для Интернета вещей предоставляет комплексное решение по обеспечению безопасности для рабочих нагрузок IOT и упрощает их защиту за счет унифицированной видимости и контроля, адаптивной защиты от угроз, а также интеллектуального обнаружения угроз и реагирования между рабочими нагрузками с конечных устройств через пограничные и через облака.

Вопросы масштабируемости

Приложение Интернета вещей следует создавать как отдельную службу, которую можно масштабировать независимо от других. Учитывайте следующие моменты масштабируемости:

IoTHub. Для Центра Интернета вещей необходимо учитывать следующие факторы масштабирования:

  • максимальная дневная квота сообщений в Центре Интернета вещей;
  • квота на число подключенных устройств в экземпляре Центра Интернета вещей;
  • пропускная способность приема данных — насколько быстро Центр Интернета вещей может принимать сообщения;
  • пропускная способность обработки — скорость обработки входящих сообщений.

Каждый центр Интернета вещей подготавливается с определенным количеством единиц для каждого конкретного уровня. Уровень и число единиц определяют максимальную дневную квоту сообщений, которые вы можете отправить в центр. Дополнительные сведения см. в разделе о квотах и регулировании Центра Интернета вещей. Вы можете увеличить масштаб, не прерывая имеющиеся операции.

Stream Analytics. Задания Stream Analytics лучше всего масштабируются, если они параллельны во всех точках конвейера Stream Analytics, от ввода данных до запроса и вывода данных. Полностью параллельные задания позволяют Stream Analytics разделить работу между несколькими вычислительными узлами. В противном случае Stream Analytics должен объединять данные потока в одном расположении. Дополнительные сведения см. в статье Использование параллелизации запросов в Azure Stream Analytics.

Центр Интернета вещей автоматически разбивает сообщения устройств на основе идентификатора устройства. Все сообщения с определенного устройства будут всегда доставляться в тот же раздел, однако в одном разделе всегда будут сообщения с нескольких устройств. Таким образом, единицей измерения параллелизации является идентификатор раздела.

Функции. При чтении из конечной точки Центров событий существует максимальное количество экземпляров для каждого раздела Центра событий. Максимальная скорость обработки определяется тем, как быстро один экземпляр функции может обрабатывать события из одного раздела. Функция должна обрабатывать сообщения в пакетах.

Cosmos DB. Чтобы расширить коллекцию Cosmos DB, создайте коллекцию с ключом раздела и включите его в каждый написанный вами документ. Дополнительные сведения см. в разделе с рекомендациями по выбору ключа раздела.

  • Если вы храните и обновляете один документ на каждом устройстве, идентификатор устройства будет хорошим ключом раздела. Операции записи равномерно распределяются между ключами. Размер каждой секции строго ограничен, так как для значения каждого ключа есть по одному документу.
  • Если вы храните отдельный документ для каждого сообщения устройства, использование идентификатора устройства в качестве ключа раздела быстро приведет к превышению ограничения в 10 ГБ на раздел. Идентификатор сообщения в этом случае является более оптимальным ключом раздела. Обычно вы все равно включаете идентификатор устройства в документ для индексации и запросов.

Служба "аналитика временных рядов Azure" (TSI) представляет собой аналитику, службу хранилища и визуализации для данных временных рядов, предоставляя возможности, включая фильтрацию и статистическую обработку в соответствии с SQL, устраняя необходимость в пользовательских функциях. " Аналитика временных рядов " предоставляет обозреватель данных для визуализации и запроса данных, а также интерфейсов API запросов на другие запросы. Помимо данных временных рядов, TSI также хорошо подходит для решений, которым необходимо запрашивать статистические выражения по большим наборам данных. Благодаря поддержке многоуровневого хранилища, расширенным API-интерфейсам, модели и интеграции с экосистемой Интернета вещей Azure, проводником для визуализаций и расширяемостью с помощью Power BI и т. д. TSI — это наша рекомендация по хранению и анализу данных временных рядов.

Вопросы безопасности

Надежный и безопасный обмен данными

Все данные, поступающие с устройства и отправляющиеся на него, должны быть надежными. Если устройство не может поддерживать следующие возможности шифрования, оно должно быть ограничено локальными сетями и вся межсетевая связь должна проходить через полевой шлюз:

  • Шифрование данных с помощью надежно защищенного, публично проанализированного и широко реализованного алгоритма шифрования с симметричным ключом.
  • Цифровая подпись с помощью надежно защищенного, публично проанализированного и широко реализованного алгоритма шифрования с симметричным ключом.
  • Поддержка TLS 1.2 для TCP или других путей обмена данными на основе потоковой передачи или DTLS 1.2 для путей обмена данными на основе датаграммы. Поддержка обработки сертификата X.509 является необязательной. Ее можно заменить более эффективным с точки зрения вычислений и сети режимом ключа с предварительным общим доступом для TLS, который можно реализовать с поддержкой алгоритмов AES и SHA-2.
  • Обновляемое хранилище ключей и ключи для каждого устройства. Каждое устройство должно иметь уникальный материальный ключ или маркеры, которые идентифицируют его в системе. Устройствам следует безопасно хранить ключи (например, с помощью безопасного хранилища ключей). Устройство должно иметь возможность периодически обновлять ключи или маркеры или мгновенно в аварийных ситуациях, например при нарушении системы безопасности.
  • Встроенное ПО и программное обеспечение приложения на устройстве должны позволять применение обновлений для исправления обнаруженных уязвимостей безопасности.

Тем не менее многие устройства слишком ограничены для поддержки таких требований. В этом случае следует использовать полевой шлюз. Безопасное подключение устройств к полевому шлюзу через локальную сеть и шлюз обеспечивает безопасный обмен данными с облаком.

Физическая проверка наличия незаконных изменений

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

Пример:

  • Выберите микроконтроллеры/микропроцессоры или вспомогательное оборудование, которое обеспечивает безопасное хранение и использование материала криптографического ключа, например интеграцию доверенного платформенного модуля (TPM).
  • Безопасный загрузчик и безопасная загрузка программного обеспечения, привязанная в доверенном платформенном модуле.
  • Используйте датчики, чтобы обнаружить попытки вторжения и манипуляции средой устройства путем оповещения и потенциального цифрового самоуничтожения устройства.

Дополнительные сведения о безопасности см. в статье Архитектура безопасности Интернета вещей.

Мониторинг и ведение журнала

Системы мониторинга и ведения журнала используются для определения работоспособности устройства и устранения неполадок. Они помогают ответить на следующие вопросы по операциям:

  • Есть ли в устройствах или системах ошибки?
  • Правильно ли устройства или системы настроены?
  • Создают ли устройства или системы точные данные?
  • Соответствуют ли системы ожиданиям компании и клиентов?

Средства ведения журнала и мониторинга обычно состоят из следующих четырех компонентов:

  • средства проверки производительности системы и визуализации временной шкалы для мониторинга системы и базового устранения неполадок;
  • прием данных в буфере, что позволяет поместить в буфер данные журнала;
  • постоянное хранилище для хранения данных журнала;
  • возможности поиска и запросов для просмотра данных журнала, используемых при детальном устранении неполадок.

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

Разработку системы мониторинга следует начинать с определения работоспособных операций, соблюдения нормативных требований и требований к аудиту. Собранные метрики могут включать:

  • физические устройства, пограничные устройства и компоненты инфраструктуры, сообщающие об изменениях конфигурации;
  • приложения, сообщающие об изменениях конфигурации, журналах аудита безопасности, сведения о частоте запросов, времени отклика, частоте появления ошибок и статистику сборки мусора для управляемых языков;
  • базы данных, постоянные хранилища, кэши, сообщающие о производительности запросов и записи, изменениях схемы, журналах аудита безопасности, блокировках и взаимоблокировках, производительности индекса, потреблении ЦП, памяти и диска;
  • управляемые службы (IaaS, PaaS, SaaS и FaaS), которые сообщают о метриках работоспособности и изменениях конфигурации, влияющих на работоспособность и производительность зависимой системы.

Визуализация метрик мониторинга позволяет операторам получать оповещения о нестабильности системы и облегчает реагирование на инциденты.

Трассировка данных телеметрии

Трассировка данных телеметрии позволяет оператору отслеживать перемещение фрагмента данных телеметрии по системе с момента его создания. Трассировка очень важна для отладки и устранения неполадок. В решениях Интернета вещей, которые используют Центр Интернета вещей и пакеты SDK для устройств Центра Интернета вещей, датаграммы трассировки можно создавать в качестве сообщений из облака на устройство и включать в поток телеметрии.

Logging

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

Несмотря на то что ведение журнала обычным текстом меньше влияет на первоначальные затраты на разработку, компьютеру сложнее его анализировать и читать. Мы рекомендуем использовать структурированное ведение журнала, чтобы собранная информация была доступна для анализа компьютером и удобной для чтения. Структурированное ведение журнала добавляет ситуационный контекст и метаданные к информации журнала. При структурированном ведении журнала свойства привилегированы и отформатированы по парам "ключ — значение" или имеют предопределенную схему для улучшения возможностей поиска и запросов.

Рекомендации для DevOps

Используйте инфраструктуру как код (IaC). IaC — это управление инфраструктурой (сетями, виртуальными машинами, подсистемами балансировки нагрузки и топологией подключения) с декларативным подходом. Шаблоны должны иметь версию и часть конвейера выпуска. Наиболее надежные процессы развертывания автоматизированы и идемпотентными. Один из способов — создать шаблон Azure Resource Manager для подготовки ресурсов Интернета вещей и инфраструктуры.

Чтобы автоматизировать развертывание инфраструктуры, можно использовать Azure DevOps Services, Jenkins или другие решения CI/CD. Предложение Azure Pipelines — это часть Azure DevOps Services, которая выполняет автоматизированные сборки, тесты и развертывания.

Рассмотрите возможность промежуточного хранения рабочих нагрузок путем развертывания на различных стадиях и выполнения проверок на каждом этапе перед переходом к следующему. Таким образом, вы можете принудительно отправлять обновления в рабочие среды с высоким уровнем контроля и сокращать непредвиденные проблемы развертывания. Для обновления динамических рабочих сред рекомендуются такие выпуски , как синий-зеленый и ранний. Также рекомендуется иметь хорошую стратегию отката при сбое развертывания. Например, можно автоматически повторно развернуть предыдущее успешное развертывание из журнала развертывания, в Azure CLI — хороший пример.

Рассмотрите возможность мониторинга решения с помощью Azure Monitor. Azure Monitor является основным источником мониторинга и ведения журнала для всех служб Azure, он предоставляет диагностические сведения для ресурсов Azure. Например, можно отслеживать операции, выполняемые в центре Интернета вещей. Существуют определенные метрики и события, которые Azure Monitor поддерживают, а также службы, схемы и категории для журналов диагностики Azure.

Дополнительные сведения см. в подразделе DevOps статьи Microsoft Azure Well-Architected Framework.

Рекомендации по стоимости

Как правило, для оценки затрат используйте Калькулятор цен Azure . Другие рекомендации описаны в разделе "затраты" в Microsoft Azure Well-Architected Framework.

Существуют способы оптимизации затрат, связанных со службами, используемыми в этой эталонной архитектуре.

Центр Интернета вещей Azure

В этой архитектуре центр Интернета вещей — это облачный шлюз, принимающий события от устройств. Выставление счетов за центр Интернета вещей зависит от типа операции. Создание, обновление, вставка и удаление доступны бесплатно. За успешные операции, такие как устройства в облако и сообщения, отправляемые из облака на устройство, начисляются счета.

Успешно отправленные сообщения с устройства в облако начисляются в блоках по 4 КБ на входе в центр Интернета вещей. Например, сообщение размером 6 КБ будет оплачено как два сообщения.

Центр Интернета вещей хранит сведения о состоянии каждого подключенного устройства в документе JSON двойникаа устройства. Операции чтения из документа двойникаа устройства начисляются.

Центр Интернета вещей предлагает два уровня: " базовый " и " стандартный".

Рекомендуется использовать уровень " стандартный ", если архитектура Интернета вещей использует возможности двунаправленной связи. Этот уровень также предлагает бесплатный выпуск, наиболее подходящий для тестирования.

Если вам требуется только однонаправленная связь между устройствами и облаком, используйте уровень " базовый ", который дешевле.

Дополнительные сведения см. на странице цен на центр Интернета вещей.

Azure Stream Analytics

Azure Stream Analytics используется для обработки потоков и оценки правил. Azure Stream Analytics оценивается по количеству единиц потоковой передачи (SU) в час, которое занимается вычислением, памятью и пропускной способностью, необходимой для обработки данных. За Azure Stream Analytics на IoT Edge взимается плата за каждое задание. Выставление счетов начинается при развертывании Stream Analytics задания на устройствах независимо от состояния задания, его выполнения, сбоя или остановки.

Дополнительные сведения о ценах см. на странице цен на Stream Analytics.

Функции Azure

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

Azure Logic Apps

В этой архитектуре Logic Apps используется для интеграции бизнес-процессов.

Цены на приложения логики работают в модели с оплатой по мере использования. Триггеры, действия и выполнения соединителей измеряются каждый раз при запуске приложения логики. Все успешные и неудачные действия, включая триггеры, считаются выполнением.

Например, приложение логики обрабатывает сообщения 1000 в день. Рабочий процесс, состоящий из пяти действий, будет стоить менее $6.

Дополнительные сведения см. на странице с ценами на Logic Apps.

Хранилище данных

Для хранилища "холодный путь" хранилище BLOB-объектов Azure является наиболее экономичным вариантом.

Для хранилища «горячий путь» рекомендуется использовать Azure Cosmos DB. Дополнительные сведения см. в разделе цены на Cosmos DB.

Дальнейшие действия