Оптимизация затрат в рабочей нагрузке Интернета вещей

Статья
04/27/2023

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

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

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

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

Оценка оптимизации затрат в рабочей нагрузке Интернета вещей

Чтобы оценить рабочую нагрузку Интернета вещей с помощью основных принципов оптимизации затрат Well-Architected Framework, пройдите вопросы по оптимизации затрат для рабочих нагрузок Интернета вещей в Обзоре Well-Architected Azure. После того как оценка определит ключевые рекомендации по оптимизации затрат для решения Интернета вещей, используйте следующее содержимое для реализации рекомендаций.

Принципы проектирования

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

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

Совокупная стоимость владения

Затраты на Интернет вещей являются компромиссом между различными вариантами технологий. Иногда это не простое сравнение, так как IoT — это сквозная система. Учитывайте преимущества взаимодействия с затратами при согласовании нескольких служб и технологий. Например, вы можете использовать Центр Интернета вещей Azure двойников устройств для обработки событий в Azure Digital Twins. Двойники устройств в Центр Интернета вещей доступны только на стандартном уровне Центр Интернета вещей.

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

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

Оценка затрат на решение на основе масштабного выполнения в рабочей среде, а не архитектуры подтверждения концепции ( PoC). Архитектура и затраты быстро развиваются после poC. Согласно отчету IoT Signals EDITION 3, основной причиной сбоя poC является высокая стоимость масштабирования. Высокая стоимость масштабирования проектов Интернета вещей объясняется сложностью интеграции между уровнями, такими как устройства, пограничное подключение и совместимость между приложениями.

Модель затрат должна включать следующие области:

Устройства. Начиная с ограниченного числа подключенных устройств, оцените рост числа развернутых устройств и их шаблонов обмена сообщениями. Как устройства, так и сообщения могут иметь линейный или нелинейный рост с течением времени.
Инфраструктура. Чтобы оценить затраты на инфраструктуру, сначала учитывайте основные понятия: хранилище, вычисления и сеть. Затем укажите все службы, необходимые вашему решению для приема, исходящего трафика и подготовки данных.
Операции. Включают долгосрочные эксплуатационные расходы, которые увеличиваются параллельно с затратами на инфраструктуру, например на работу операторов, поставщиков и групп поддержки клиентов.
Мониторинг. Непрерывный мониторинг и анализ затрат для выявления разрывов между запланированными и фактическими затратами. Регулярное собрание по проверке затрат помогает оптимизировать затраты.

Уровни архитектуры Интернета вещей

Принципы проектирования оптимизации затрат помогают уточнить рекомендации по обеспечению соответствия рабочей нагрузки Интернета вещей требованиям на базовых уровнях архитектуры Интернета вещей.

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

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

Схема, на которую показаны уровни и сквозные действия в архитектуре Интернета вещей.

Уровень устройства и шлюза

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

Схема жизненного цикла устройства.

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

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

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

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

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

Выбор оборудования

Большая часть процесса разработки устройств зависит от выбора оборудования. При принятии решения о покупке устройств учитываются качественные факторы, такие как сертификация Wi-Fi, и количественные факторы, такие как стоимость материалов и время вывода на рынок. Выбор между готовым оборудованием или пользовательским дизайном влияет на стоимость устройств Интернета вещей и время вывода на рынок.

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

Каталог сертифицированных устройств Azure предлагает устройства, которые хорошо работают с Интернетом вещей Azure и помогают сократить затраты и время вывода на рынок. Вы сосредоточитесь на проектировании и проектировании решения Интернета вещей с возможностью выбора оборудования из обширного списка сертифицированных устройств. IoT Plug and Play устройствах могут снизить затраты как на разработку устройств, так и на облачные решения. При выборе сертифицированного устройства Azure вы можете пропустить настройку устройства и интеграцию непосредственно к подключению к Решению Интернета вещей.

Рисунок, показывающий экономию за счет Plug and Play подхода.

Архитектурный шаблон лямбда-выражения

Решения Интернета вещей обычно используют лямбда-шаблон "горячий", "теплый", "холодный" в облаке. Этот шаблон также применяется к пограничным устройствам при использовании более производительных пограничных устройств или среды выполнения IoT Edge Azure. Оптимизация этого шаблона на пограничных устройствах снижает общие затраты на решение. Вы можете выбрать наиболее экономически эффективную службу для приема и обработки облачных данных.

Обработка горячих путей включает обработку практически в реальном времени, обработку оповещений или пограничные уведомления. Вы можете использовать Центр Интернета вещей Azure потоки событий для обработки оповещений в облаке.
Обработка теплого пути включает в себя использование решений хранилища на границе, таких как базы данных временных рядов с открытым кодом или Azure SQL Edge. Azure SQL Edge включает функции обработки пограничных потоков и оптимизированное для временных рядов хранилище.
Обработка холодного пути включает пакетную обработку событий с более низкой важностью и использование параметра передачи файлов через модуль Хранилище BLOB-объектов Azure. В этом подходе используется механизм передачи данных с более низкой стоимостью по сравнению с потоковой передачей через Центр Интернета вещей. После поступления холодных данных в хранилище BLOB-объектов Azure существует множество вариантов обработки данных в облаке.

Безопасность устройств

Оба Центр Интернета вещей со службой подготовки устройств (DPS) и IoT Central поддерживают проверку подлинности устройств с симметричными ключами, аттестацией доверенного платформенного модуля (TPM) и сертификатами X.509. С каждым вариантом связан фактор затрат.

Сертификаты X.509 являются наиболее безопасным вариантом проверки подлинности в Центр Интернета вещей Azure, но управление сертификатами может быть дорогостоящим. Отсутствие планирования управления жизненным циклом сертификатов может сделать сертификаты еще более дорогостоящими. Как правило, вы работаете со сторонними поставщиками, которые предлагают ЦС и решения для управления сертификатами. Для этого параметра требуется использовать инфраструктуру открытых ключей (PKI). Возможные варианты включают самоуправляемую PKI, стороннюю PKI или службу безопасности Azure Sphere, которая доступна только на устройствах Azure Sphere.
Доверенные платформенные модули с сертификатами X.509 обеспечивают дополнительный уровень безопасности. DPS также поддерживает проверку подлинности с помощью ключей подтверждения доверенного платформенного модуля. Затраты на main связаны с оборудованием, потенциальным перепроектированием платы и сложностью.
Проверка подлинности с помощью симметричного ключа — это самый простой и минимальный вариант, но необходимо оценить влияние на безопасность. Необходимо защитить ключи на устройстве и в облаке, а для безопасного хранения ключа на устройстве часто требуется более безопасный вариант.

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

Дополнительные сведения см. в статье Рекомендации по обеспечению безопасности для производителей устройств Интернета вещей Azure.

ОСРВ Azure

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

ОСРВ Azure предоставляется бесплатно для коммерческого развертывания с использованием предварительно лицензированного оборудования. ОСРВ Azure поставляется с облачными возможностями и функциями Azure IoT, такими как обновление устройств и безопасность. Эти функции помогают сократить затраты на разработку устройств и облаков.

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

Устройства LPWAN

Если устройства LPWAN, такие как LoRaWAN, NB-IoT или LTE-M, уже подключены к другому облаку Интернета вещей, мост устройств Azure IoT Central может помочь выполнить мост с Azure IoT Central. Мост устройств Azure IoT Central позволяет сосредоточиться на добавлении отраслевых знаний и оценке решения без затрат на изменение существующих устройств.

При создании корпоративного готового решения необходимо учитывать затраты на интеграцию устройств LPWAN с Центр Интернета вещей Azure.

Azure Sphere

Azure Sphere — это безопасная, сквозная платформа решения Интернета вещей со встроенными функциями связи и безопасности для устройств, подключенных к Интернету. Azure Sphere включает в себя защищенный подключенный кроссоверный микроконтроллер (MCU), пользовательскую высокоуровневую операционную систему на основе Linux и облачную службу безопасности, которая обеспечивает непрерывную и возобновляемую безопасность. Azure Sphere сокращает усилия по созданию и обслуживанию безопасной среды с устройства на облако.

Azure Sphere предоставляет обновления ОС и систему безопасности нулевого дня в течение 10 лет на основе PKI на основе X.509, обновлений пользовательских приложений, отчетов об ошибках и управления устройствами за 10 лет без дополнительных затрат. Azure Sphere снижает эксплуатационные затраты на поддержание миллионов устройств в актуальном состоянии с помощью новейших средств безопасности.

Azure Stack

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

Azure Stack Edge — это управляемый Azure (модуль), который идеально подходит для рабочих нагрузок машинного обучения с аппаратным ускорением в пограничных расположениях. Azure Stack Edge работает на современных технологических стеках, таких как контейнеры, поэтому Azure Stack Edge, развернутый в пограничном расположении, может обслуживать несколько рабочих нагрузок. Совместное использование вычислительной мощности между рабочими нагрузками снижает общую стоимость владения.
Azure Stack HCI — это специальное гиперконвергентное решение с собственной интеграцией Azure. Azure Stack HCI предлагает масштабируемую виртуализацию для размещения решений Интернета вещей. Виртуализация обеспечивает дополнительные преимущества, такие как безопасность, масштабируемость и гибкие среды, которые могут снизить стоимость владения за счет совместного использования оборудования с другими рабочими нагрузками. Azure Stack HCI предлагает больше вычислительных ресурсов, чем Azure Stack Edge, и идеально подходит для преобразования отраслевых процессов.

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

Общедоступный или частный MEC Azure

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

Общедоступные или частные пограничные вычисления Azure с несколькими доступами (MEC) и 5G помогают оптимизировать затраты на разгрузку данных с устройств. Решения Интернета вещей на основе MEC обеспечивают обработку данных с низкой задержкой на границе, а не на устройствах или в облаке. Задержка составляет 1–5 мс вместо обычных 100–150 мс для облака. Решения Интернета вещей на основе MEC являются гибкими, а сами устройства являются недорогими, работают с минимальным обслуживанием и используют меньшие, дешевые и долговечные батареи. MEC поддерживает функции аналитики данных, искусственного интеллекта и оптимизации на границе, что обеспечивает простоту и экономичность решений Интернета вещей.

Помимо работы в качестве пограничного устройства обработки, вычислений и связи 5G для рабочих нагрузок Интернета вещей, MEC использует другие рабочие нагрузки в качестве устройства связи для установки высокоскоростных подключений к общедоступному облаку или удаленным сайтам.

Azure IoT Edge

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

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

Чтобы снизить затраты на обмен данными, можно развернуть службы Azure, такие как Azure Stream Analytics и Функции Azure, для IoT Edge. Azure Stream Analytics и Функции Azure могут агрегировать и фильтровать большие объемы данных на границе и отправлять в облако только важные данные. Хранилище BLOB-объектов Azure IoT Edge может снизить потребность в передаче больших объемов данных по сети. Пограничное хранилище полезно для преобразования и оптимизации больших объемов данных перед их отправкой в облако.

Бесплатные модули Azure IoT Edge для открытых протоколов, таких как OPC Publisher и Modbus, помогают подключать различные устройства с минимальной разработкой. Если производительность отправки имеет решающее значение, выбор проверенного модуля IoT Edge от поставщика может оказаться более экономичным, чем создание пользовательского модуля. На Azure Marketplace можно найти и скачать модули IoT Edge.

Уровень приема и связи

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

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

Для подключения устройства важно указать тип сети. При выборе решения для частной локальной сети или глобальной сети, например Wi-Fi или LoraWAN, совокупная стоимость владения сети считается частью общей стоимости. При использовании сетей-операторов, таких как 4G, 5G или LPWAN, укажите повторяющиеся затраты на подключение.

Платформа решения Интернета вещей

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

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

уровни Центр Интернета вещей

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

размер и частота сообщений Центр Интернета вещей

Затраты на обмен сообщениями в значительной степени зависят от объема сообщений и объема сообщений на устройстве. Чатные устройства отправляют много сообщений в облако каждую минуту, в то время как относительно тихие устройства отправляют данные только каждый час или более. Избегайте взаимодействия между устройствами и облаком, которые используют множество небольших сообщений. Clarity о чате устройства и размере сообщений помогает снизить вероятность чрезмерной подготовки, что приводит к неиспользуемой облачной емкости или недостаточной подготовке, что приводит к проблемам масштабирования. Учитывайте размер и частоту полезных данных сообщений, чтобы убедиться, что инфраструктура имеет правильный размер и готова к масштабированию.

Избегайте взаимодействия между облаком и устройством, которые используют множество небольших сообщений. Например, сгруппировать несколько обновлений двойника устройства или модуля в одно обновление, которое имеет собственное регулирование. Учитывайте размер сообщения, используемый для ежедневной квоты, 4K-байт для несвободных Центр Интернета вещей уровней. При отправке небольших сообщений некоторая емкость остается неиспользуемой, а плата за большие сообщения взимается блоками размером 4 КБ.

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

Совет

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

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

Используйте более короткий идентификатор устройства, идентификатор модуля, имя двойника и раздел сообщения, чтобы уменьшить полезные данные в пакетах MQTT. Полезные данные MQTT выглядят следующим образом devices/{device_id}/modules/{module_id}/messages/events/: .
Сокращение накладных расходов фиксированной длины и сообщения.
Сожмите полезные данные, например с помощью Gzip.

Центр Интернета вещей квоты сообщений и ограничения регулирования

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

Например, уровень "Стандартный" S1 имеет ежедневную квоту в 400 000 сообщений. Плата увеличивается на 4-КБ блоков в зависимости от нескольких факторов:

Одно сообщение от устройства в облако (D2C) может быть размером до 4 КБ.
Плата за сообщения D2C, размер которых превышает 4 КБ, взимается блоками по 4 КБ.
Сообщения размером менее 4 КБ могут использовать метод пакета SDK SendEventBatchAsync для Интернета вещей Azure для оптимизации пакетной обработки на стороне устройства. Например, объединение до четырех сообщений по 1 КБ на границе увеличивает ежедневное количество сообщений только на одно сообщение. Пакетная обработка применяется только для AMQP или HTTPS.
Большинство операций, таких как сообщения из облака на устройство или операции двойника устройства, также заряжают сообщения блоками по 4 КБ. Все эти операции добавляют к ежедневной пропускной способности и максимальной квоте сообщений.

Подробные примеры цен см. в документации по сведениям о ценах Центр Интернета вещей Azure.

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

К различным операциям Центр Интернета вещей применяются различные ограничения регулирования. Операции с устройства в облако имеют регулирование операций в секунду, которое зависит от уровня. Помимо размера сообщения, который измеряется блоками размером 4 КБ, учитывайте количество операций. Пакетная обработка на границе позволяет отправлять больше сообщений за одну операцию.

Одно сообщение размером 2 КБ, пакетное сообщение размером 10 КБ или пакетное сообщение размером 256 КБ считается одной операцией, позволяя отправлять дополнительные данные в конечную точку без достижения ограничений регулирования.

автомасштабирование Центр Интернета вещей

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

Метки развертывания для масштабирования

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

Уровень управления устройствами и моделирования

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

IoT Plug and Play

Для сокращения стоимости владения рассмотрите расширенные варианты использования в рамках выбора платформы. IoT Plug and Play позволяет разработчикам решений интегрировать устройства с Центр Интернета вещей или Azure Digital Twins без настройки вручную. IoT Plug and Play использует DTDL версии 2. Обе они основаны на открытых стандартах W3C, например JSON-LD и RDF, что упрощает внедрение в разные службы и средства.

Использование IoT Plug and Play и DTDL не взимается. Стандартные тарифы для Центр Интернета вещей, Azure Digital Twins и других служб Azure остаются неизменными.

Дополнительные сведения см. в статье Преобразование существующего устройства в IoT Plug and Play устройство.

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

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

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

DPS поддерживает управление жизненным циклом устройств с помощью Центр Интернета вещей с помощью политик выделения для регистрации, нулевой подготовки, начальной настройки конфигурации, повторной подготовки и отзыва. Дополнительные сведения см. в разделе:

Моделирование состояния ресурсов и устройств

Сравните различия в затратах между несколькими топологиями устройств и хранилищами сущностей, такими как Azure Cosmos DB, Azure Digital Twins и база данных Azure SQL. Каждая служба имеет разную структуру затрат и предоставляет различные возможности для решения Интернета вещей. В зависимости от требуемого использования выберите наиболее экономичный сервис.

Azure Digital Twins может реализовать графовую модель среды Интернета вещей для управления ресурсами, состояния устройства и данных телеметрии. Azure Digital Twins можно использовать в качестве инструмента для моделирования целых сред с потоковой передачей данных Интернета вещей в реальном времени и объединения бизнес-данных из источников, отличных от Интернета вещей. Вы можете создавать пользовательские онтологии или использовать основанные на стандартах онтологии, такие как RealEstateCore, CIM или NGSI-LD, чтобы упростить обмен данными с третьими лицами. Azure Digital Twins имеет модель ценообразования с оплатой за использование без фиксированной платы.
Azure Cosmos DB — это многомодельная глобально распределенная база данных. На стоимость влияет хранилище и пропускная способность с региональными или глобально распределенными и реплицированными данными.
Azure SQL База данных может быть эффективным решением для моделирования устройств и ресурсов. База данных SQL имеет несколько моделей ценообразования, которые помогают оптимизировать затраты.

Модель развертывания ресурсов

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

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

Калькулятор цен Azure — это полезный инструмент для сравнения этих вариантов.

Уровень обработки и аналитики событий

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

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

Чтобы приступить к работе, определите, какие типы данных проходят горячий, теплый или холодный путь:

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

Схема, показывающая пути

Уровень хранения

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

Типы хранилищ

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

Хранилище и базы данных не являются взаимоисключающими. Обе службы могут работать вместе, особенно с четко определенными горячими, теплыми и холодными способами аналитики. Data Explorer и базы данных Azure обычно используются для сценариев горячего и теплого пути.

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

Решения для баз данных

Для возможностей баз данных часто можно выбирать между решениями SQL и no-SQL. Базы данных SQL лучше всего подходят для телеметрии фиксированной схемы с простыми требованиями к преобразованию данных или агрегации данных. Дополнительные сведения см. в статье Типы баз данных в Azure.

Azure SQL База данных и TimescaleDB для PostgreSQL — это распространенные варианты для базы данных SQL. Дополнительные сведения см. в следующих статьях:

Если данные лучше всего представить в виде объекта или документа без фиксированной схемы, лучше всего использовать no-SQL. Azure Cosmos DB предоставляет несколько API, таких как SQL или MongoDB. Для любой базы данных стратегии секционирования и индексирования важны для оптимизации производительности и сокращения ненужных затрат. Дополнительные сведения см. в разделе:

Partitioning and horizontal scaling in Azure Cosmos DB (Секционирование и горизонтальное масштабирование в Azure Cosmos DB)
Планирование затрат на Azure Cosmos DB и управление ими

Azure Synapse Analytics — это современное хранилище данных Azure. Synapse Analytics масштабируется по единицам Data Warehouse (DWU), и вам следует выбрать подходящую емкость для удовлетворения требований к решению. В зависимости от варианта использования можно приостановить вычисление, если задание не выполняется, чтобы снизить эксплуатационные затраты.

Уровень транспорта

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

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

Клиенты устройств регулярно отправляют сообщения проверки активности в Центр Интернета вещей. В соответствии с расходами за операцию плата за поддержание активности сообщений не взимается. Но вам не нужно добавлять свойство keep-alive в телеметрию, если для него нет особых требований. Для обеспечения гибкости некоторые пакеты SDK для устройств Azure IoT предоставляют возможность задать временной диапазон для этих сообщений, если вы используете протоколы AMQP или MQTT.

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

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

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

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

Уровень взаимодействия и создания отчетов

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

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

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

Уровень интеграции

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

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

При использовании API запросов Azure Digital Twins взимает плату за единицу запроса (QU). Количество единиц запросов, использованных запросом, можно отследить в заголовке ответа. Сократите сложность запросов и количество результатов для оптимизации затрат. Дополнительные сведения см. в статье Поиск потребления QU в Azure Digital Twins.

Уровень DevOps

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

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

Среды разработки

Разработчики могут воспользоваться преимуществами гибкости, которую предоставляет Azure для оптимизации затрат на разработку. Центр Интернета вещей бесплатный уровень, ограниченный одним экземпляром на подписку, предоставляет стандартные возможности, но ограничен 8000 сообщений в день. Этого уровня достаточно для ранней разработки с ограниченным количеством устройств и сообщений.

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

Интегрированная среда разработки (IDE) ускоряет разработку и развертывание. Некоторые среды разработки с открытым кодом, такие как Visual Studio Code предоставляют расширения Интернета вещей Azure, которые позволяют разработчикам бесплатно разрабатывать и развертывать код в службах Интернета вещей Azure.

Azure IoT предоставляет бесплатные примеры кода GitHub с рекомендациями. Эти примеры помогают разработчикам расширить возможности устройств, IoT Edge, Центр Интернета вещей и приложений Azure Digital Twins. GitHub также предоставляет функции для реализации бесшовных сред непрерывной интеграции и непрерывного развертывания (CI/CD) с низкими затратами и усилиями. GitHub Actions бесплатны для проектов с открытым кодом. Дополнительные сведения см. в разделе Планы и функции GitHub.

Нагрузочное тестирование для оценки затрат

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

Среды развертывания

Обычно рабочие нагрузки развертываются в нескольких средах, таких как разработка и рабочая среда. Благодаря инфраструктуре как коду (IaC) можно ускорить развертывание и сократить время выхода на рынок, повторно используя код. IaC помогает избежать непреднамеренных развертываний, таких как неправильные уровни. Службы Azure, такие как Azure Resource Manager и Azure Bicep, или сторонние службы, такие как Terraform и Pulumi, являются распространенными вариантами IaC.

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

Поддержка и обслуживание

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

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

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

Система управления облаком

Управление облаком имеет важное значение для обеспечения соответствия требованиям, безопасности и предотвращения ненужных затрат.

API-интерфейсы управления затратами позволяют изучать данные о затратах и использовании с помощью многомерного анализа. Вы можете создавать настраиваемые фильтры и выражения, которые помогут ответить на вопросы, связанные с потреблением ресурсов Azure. API управления затратами могут создавать оповещения, когда потребление достигает настроенных пороговых значений. API управления затратами доступны для IoT Central, Центр Интернета вещей и DPS.
Добавление тегов к ресурсам применяет метки к развернутыми ресурсам. Наряду с управлением затратами Майкрософт теги предоставляют аналитические сведения о текущих затратах на основе меток. Дополнительные сведения см. в статье Распространенные способы анализа затрат.
Политика Azure поставляется со встроенными политиками для автоматической маркировки ресурсов или помечать ресурсы без тегов. Дополнительные сведения см. в статье Назначение определений политик для соответствия тегам. Другим вариантом использования Политика Azure является предотвращение подготовки определенных уровней, что помогает предотвратить чрезмерную подготовку в средах разработки или рабочей среды.

Наблюдение

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

Ведение журнала телеметрии обычно использует рабочие области Log Analytics в Azure Monitor. Log Analytics включает 5 ГБ хранилища, а первые 30 дней хранения бесплатны. В зависимости от бизнес-потребностей может потребоваться более длительный срок хранения. Проверьте и определите правильный срок хранения, чтобы избежать непреднамеренных затрат.

Log Analytics предоставляет среду рабочей области для интерактивного запроса журналов. Вы можете периодически экспортировать журналы во внешние расположения, такие как Azure Data Explorer, или архивировать журналы в учетной записи хранения для менее дорогостоящего варианта хранения. Дополнительные сведения см. в статье Мониторинг использования и предполагаемых затрат в Azure Monitor.

Помощник по Azure

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

Помощник помогает оптимизировать и сократить общие расходы на Azure, выявляя неактивные и недостаточно используемые ресурсы. Рекомендации по затратам можно получить на вкладке затрат на панели мониторинга Помощника.

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

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

Эффективность работы в рабочей нагрузке Интернета вещей

Поделиться через