MLO на межі з Amazon SageMaker Edge Manager і AWS IoT Greengrass

Інтернет речей (IoT) дає змогу клієнтам у багатьох галузях, таких як виробництво, автомобілебудування та енергетика, відстежувати та контролювати реальне середовище. Розгортаючи різні периферійні пристрої Інтернету речей, такі як камери, термостати та датчики, ви можете збирати дані, надсилати їх у хмару та створювати моделі машинного навчання (ML) для прогнозування аномалій, збоїв тощо. Однак, якщо сценарій використання вимагає прогнозування в реальному часі, вам потрібно збагатити своє рішення IoT можливостями ML at the edge (ML@Edge). ML@Edge це концепція, яка відокремлює життєвий цикл моделі ML від життєвого циклу програми та дозволяє запускати наскрізний конвеєр ML, який включає підготовку даних, побудову моделі, компіляцію та оптимізацію моделі, розгортання моделі (на групі периферійних пристроїв), виконання моделі, моніторинг і управління моделлю. Ви розгортаєте програму один раз і запускаєте конвеєр ML стільки разів, скільки вам потрібно.

Як ви можете собі уявити, реалізувати всі кроки, запропоновані концепцією ML@Edge, непросто. Існує багато запитань, на які розробники повинні відповісти, щоб реалізувати повне рішення ML@Edge, наприклад:

• Як керувати моделями ML на парку (сотнях, тисячах або мільйонах) пристроїв на межі?
• Як захистити мою модель під час розгортання та запуску на краю?
• Як контролювати продуктивність моєї моделі та перенавчати її, якщо потрібно?

У цій публікації ви дізнаєтеся, як відповісти на всі ці запитання та створити наскрізне рішення для автоматизації конвеєра ML@Edge. Ви побачите, як використовувати Amazon SageMaker Edge Manager, Студія Amazon SageMaker та AWS IoT Greengrass v2 для створення середовища MLOps (ML Operations), яке автоматизує процес побудови та розгортання моделей ML на великих групах периферійних пристроїв.

У наступних розділах ми представляємо еталонну архітектуру, яка докладно описує всі компоненти та робочі процеси, необхідні для створення повного рішення для MLO, зосередженого на межових робочих навантаженнях. Потім ми глибоко зануримося в кроки, які це рішення виконує автоматично, щоб створити та підготувати нову модель. Ми також покажемо вам, як підготувати периферійні пристрої до початку розгортання, запуску та моніторингу моделей ML, а також продемонструємо, як контролювати та підтримувати моделі ML, розгорнуті на вашому парку пристроїв.

Огляд рішення

Виробництво надійних моделей машинного навчання вимагає співпраці багатьох людей, таких як науковці з обробки даних, інженери з обробки даних, інженери з обробки даних і бізнес-стейкхолдери в рамках напівавтоматизованої інфраструктури, що виконує певні операції (MLOps). Крім того, модульність середовища важлива для того, щоб надати всім цим різним особам гнучкість і гнучкість для розробки або вдосконалення (незалежно від робочого процесу) компонента, за який вони відповідають. Прикладом такої інфраструктури є кілька облікових записів AWS, які дозволяють цю співпрацю та виробництво моделей ML як у хмарі, так і на периферійних пристроях. У наступній еталонній архітектурі ми показуємо, як ми організували кілька облікових записів і служб, які складають цю наскрізну платформу MLOps для створення моделей ML і їх розгортання на межі.

Це рішення складається з таких облікових записів:

• Обліковий запис озера даних – Інженери обробки даних приймають, зберігають і готують дані з багатьох джерел даних, включаючи локальні бази даних і пристрої IoT.
• Інструментальний рахунок – ІТ-оператори керують і перевіряють конвеєри CI/CD для автоматизованої безперервної доставки та розгортання пакетів моделі ML у попередніх і робочих облікових записах для віддалених периферійних пристроїв. Запуски конвеєрів CI/CD автоматизовані за допомогою Amazon EventBridge, який відстежує зміни стану моделей і цілей ML AWS CodePipeline.
• Облік експериментів і розробок – Науковці даних можуть проводити дослідження та експериментувати з кількома методами моделювання та алгоритмами для вирішення бізнес-завдань на основі машинного навчання, створюючи перевірені концептуальні рішення. Інженери ML і дослідники даних співпрацюють, щоб масштабувати перевірку концепції, створюючи автоматизовані робочі процеси за допомогою Трубопроводи Amazon SageMaker готувати дані та будувати, навчати та пакувати моделі ML. Розгортання конвеєрів здійснюється за допомогою конвеєрів CI/CD, тоді як керування версіями моделей здійснюється за допомогою Реєстр моделей Amazon SageMaker. Науковці даних оцінюють показники кількох версій моделі та вимагають просування найкращої моделі до виробництва, запускаючи конвеєр CI/CD.
• Рахунок перед виробництвом – Перед просуванням моделі у виробниче середовище її необхідно протестувати, щоб переконатися в надійності в середовищі моделювання. Таким чином, підготовче середовище є симулятором виробничого середовища, у якому кінцеві точки моделі SageMaker розгортаються та тестуються автоматично. Методи тестування можуть включати інтеграційний тест, стрес-тест або специфічні для ML тести результатів логічного висновку. У цьому випадку виробниче середовище — це не кінцева точка моделі SageMaker, а крайовий пристрій. Для імітації периферійного пристрою на підготовчому виробництві можливі два підходи: використання Обчислювальна хмара Amazon Elastic (Amazon EC2) з такими самими апаратними характеристиками або використайте лабораторний стенд, що складається з фактичних пристроїв. Завдяки цій інфраструктурі конвеєр CI/CD розгортає модель у відповідному симуляторі та автоматично проводить численні тести. Після успішного виконання тестів конвеєр CI/CD вимагає ручного схвалення (наприклад, від зацікавленої сторони IoT для просування моделі до виробництва).
• Виробничий рахунок – У разі розміщення моделі в хмарі AWS, конвеєр CI/CD розгортає кінцеву точку моделі SageMaker у робочому обліковому записі. У цьому випадку виробниче середовище складається з безлічі периферійних пристроїв. Тому конвеєр CI/CD використовує Edge Manager для розгортання моделей на відповідному парку пристроїв.
• Крайові пристрої – Віддалені периферійні пристрої – це апаратні пристрої, які можуть запускати моделі ML за допомогою Edge Manager. Це дозволяє програмі на цих пристроях керувати моделями, виконувати висновок щодо моделей і безпечно отримувати дані в Служба простого зберігання Amazon (Amazon S3).

Проекти SageMaker допоможе вам автоматизувати процес надання ресурсів у кожному з цих облікових записів. Ми не занурюємося глибоко в цю функцію, але щоб дізнатися більше про те, як створити шаблон проекту SageMaker, який розгортає моделі ML в облікових записах, перегляньте Розгортання моделі кількох облікових записів за допомогою Amazon SageMaker Pipelines.

Обліковий запис перед виробництвом: цифровий двійник

Після процесу навчання отриману модель потрібно оцінити. У передвиробничому обліковому записі у вас є змодельований пристрій Edge. Він представляє цифровий близнюк периферійного пристрою, на якому модель ML працює у виробництві. Це середовище має подвійну мету: виконувати класичні тести (наприклад, модульні, інтеграційні та димові) і бути майданчиком для команди розробників. Цей пристрій моделюється за допомогою екземпляра EC2, де розгорнуто всі компоненти, необхідні для керування моделлю ML.

Залучені послуги є такими:

• Ядро AWS IoT - Ми використовуємо Ядро AWS IoT створити об’єкти речей AWS IoT, створити групу пристроїв, зареєструвати групу пристроїв, щоб вона могла взаємодіяти з хмарою, створити сертифікати X.509 для автентифікації периферійних пристроїв у AWS IoT Core, пов’язати псевдонім ролі з AWS IoT Core, який було згенеровано, коли створений парком, отримати кінцеву точку для облікового запису AWS для постачальника облікових даних, отримати офіційний файл Amazon Root CA та завантажити файл Amazon CA в Amazon S3.
• Amazon Sagemaker Neo – Шалфейник Neo автоматично оптимізує моделі машинного навчання для швидшої роботи висновків без втрати точності. Він підтримує модель машинного навчання, уже створену за допомогою DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX або XGBoost і навчену в Amazon SageMaker або де-небудь ще. Потім ви обираєте свою цільову апаратну платформу, якою може бути екземпляр хостингу SageMaker або периферійний пристрій на основі процесорів Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments або Xilinx.
• Edge Manager – Ми використовуємо Edge Manager для реєстрації та керування крайовими пристроями в парках Sagemaker. Флоти — це набори логічно згрупованих пристроїв, які можна використовувати для збору та аналізу даних. Крім того, пакувальник Edge Manager пакує оптимізовану модель і створює компонент AWS IoT Greengrass V2, який можна безпосередньо розгорнути. Ви можете використовувати Edge Manager для керування моделями ML на наборі розумних камер, розумних колонок, роботів та інших пристроїв SageMaker.
• AWS IoT Greengrass V2 - AWS IoT Greengrass дозволяє розгортати компоненти в змодельованих пристроях за допомогою примірника EC2. Використовуючи агент AWS IoT Greengrass V2 в екземплярах EC2, ми можемо спростити доступ, керування та розгортання агента Edge Manager і моделі на пристроях. Без AWS IoT Greengrass V2 для налаштування пристроїв і груп для використання Edge Manager потрібно вручну скопіювати агент із сегмента випуску S3. Завдяки інтеграції AWS IoT Greengrass V2 та Edge Manager можна використовувати компоненти AWS IoT Greengrass V2. Компоненти — це готові модулі програмного забезпечення, які можуть підключати периферійні пристрої до сервісів AWS або стороннього сервісу через AWS IoT Greengrass.
• Агент Edge Manager – Агент Edge Manager розгортається через AWS IoT Greengrass V2 в екземплярі EC2. Агент може завантажувати декілька моделей одночасно та робити висновок із завантаженими моделями на периферійних пристроях. Кількість моделей, які може завантажити агент, визначається доступною пам’яттю на пристрої.
• Amazon S3 – Ми використовуємо відро S3 для зберігання даних, отриманих висновками від агента Edge Manager.

Ми можемо визначити передвиробничий обліковий запис як цифрового близнюка для тестування моделей ML перед переміщенням їх у реальні периферійні пристрої. Це забезпечує такі переваги:

• Спритність і гнучкість – Науковці даних та інженери ML повинні швидко перевірити, чи модель ML і пов’язані сценарії (попередня обробка та сценарії висновків) працюватимуть на периферії пристрою. Однак відділи IoT і data science на великих підприємствах можуть бути різними організаціями. Завдяки ідентичній реплікації технологічного стеку в хмарі науковці з даних та інженери ML можуть повторювати та консолідувати артефакти перед розгортанням.
• Прискорена оцінка ризиків і часу виробництва – Розгортання на крайньому пристрої є завершальним етапом процесу. Після того, як ви перевірите все в ізольованому та автономному середовищі, переконайтеся, що воно відповідає специфікаціям, які вимагає край з точки зору якості, продуктивності та інтеграції. Це допомагає уникнути подальшого залучення інших людей у ​​відділі IoT для виправлення та повторення версій артефактів.
• Покращена співпраця команди та підвищена якість і продуктивність – Команда розробників може негайно оцінити вплив моделі ML, проаналізувавши метрики периферійного обладнання та вимірявши рівень взаємодії зі сторонніми інструментами (наприклад, швидкість вводу-виводу). Тоді команда IoT відповідає лише за розгортання у виробничому середовищі та може бути впевнена, що артефакти точні для виробничого середовища.
• Інтегрований майданчик для тестування – Враховуючи ціль моделей ML, передвиробниче середовище в традиційному робочому процесі має бути представлене периферійним пристроєм поза хмарним середовищем. Це вводить інший рівень складності. Для збору показників і відгуків потрібні інтеграції. Натомість за допомогою моделювання середовища цифрового близнюка кількість взаємодій зменшується, а час виходу на ринок скорочується.

Виробничий рахунок і крайове середовище

Після завершення тестів і досягнення стабільності артефакту можна переходити до розгортання виробництва через конвеєри. Розгортання артефакту відбувається програмно після того, як оператор схвалить артефакт. Проте доступ до Консоль управління AWS надається операторам у режимі лише для читання, щоб мати можливість відстежувати метадані, пов’язані з парками, і, отже, мати уявлення про версію розгорнутої моделі ML та інші показники, пов’язані з життєвим циклом.

Парки пристроїв Edge належать до виробничого облікового запису AWS. Цей обліковий запис має спеціальні конфігурації безпеки та мережі, щоб забезпечити зв’язок між хмарою та периферійними пристроями. Основними службами AWS, розгорнутими в робочому обліковому записі, є Edge Manager, який відповідає за керування всіма групами пристроїв, збір даних і керування моделями ML, і AWS IoT Core, який керує речовими об’єктами IoT, сертифікатами, псевдонімами ролей і кінцевими точками.

У той же час нам потрібно налаштувати периферійний пристрій зі службами та компонентами для керування моделями ML. Основні компоненти такі:

• AWS IoT Greengrass V2
• Агент Edge Manager
• Сертифікати AWS IoT
• Application.py, який відповідає за організацію процесу висновку (отримання інформації з крайового джерела даних і виконання висновку за допомогою агента Edge Manager і завантаженої моделі ML)
• З’єднання з Amazon S3 або обліковим записом озера даних для зберігання отриманих даних

Автоматизований конвеєр ML

Тепер, коли ви знаєте більше про організацію та компоненти еталонної архітектури, ми можемо глибше зануритися в конвеєр ML, який ми використовуємо для створення, навчання та оцінки моделі ML в обліковому записі розробки.

Трубопровід (побудований з використанням Трубопроводи для створення моделей Amazon SageMaker) — це серія взаємопов’язаних кроків, які визначаються визначенням конвеєра JSON. Це визначення конвеєра кодує конвеєр за допомогою спрямованого ациклічного графа (DAG). Ця DAG надає інформацію про вимоги та зв’язки між кожним кроком вашого конвеєра. Структура DAG конвеєра визначається залежностями даних між кроками. Ці залежності даних створюються, коли властивості вихідних даних кроку передаються як вхідні дані для іншого кроку.

Щоб дати змогу групам із вивчення даних легко автоматизувати створення нових версій моделей ML, важливо запровадити етапи перевірки й автоматичні дані для постійної подачі та вдосконалення моделей ML, а також стратегії моніторингу моделей для активації конвеєрного запуску. На наступній діаграмі показано приклад конвеєра.

Для забезпечення автоматизації та можливостей MLOps важливо створити модульні компоненти для створення багаторазово використовуваних артефактів коду, які можна використовувати для різних етапів і варіантів використання ML. Це дає змогу швидко перевести впровадження з фази експерименту на фазу виробництва шляхом автоматизації переходу.

Кроки для визначення конвеєра ML для забезпечення безперервного навчання та версії моделей ML такі:

• Попередня обробка – Процес очищення даних, розробки функцій і створення набору даних для навчання алгоритму ML
• Навчання – Процес навчання розробленого алгоритму ML для генерації нової версії артефакту моделі ML
• Оцінка – Процес оцінки згенерованої моделі ML для вилучення ключових показників, пов’язаних з поведінкою моделі на нових даних, які не були помічені на етапі навчання
• Реєстрація – Процес версії нового навченого артефакту моделі ML шляхом зв’язування отриманих показників із згенерованим артефактом

Нижче ви можете побачити докладнішу інформацію про створення конвеєра SageMaker ноутбук.

Запускайте конвеєри CI/CD за допомогою EventBridge

Коли ви завершите створення моделі, ви можете почати процес розгортання. Останній крок конвеєра SageMaker, визначений у попередньому розділі, реєструє нову версію моделі в певній групі реєстру моделей SageMaker. Розгортанням нової версії моделі ML керують за допомогою статусу реєстру моделі. Під час ручного схвалення або відхилення версії моделі ML цей крок викликає подію, яка фіксується EventBridge. Потім ця подія може запустити новий конвеєр (цього разу CI/CD) для створення нової версії компонента AWS IoT Greengrass, який потім розгортається в попередніх і робочих облікових записах. На наступному знімку екрана показано наше визначене правило EventBridge.

Це правило відстежує групу пакетів моделей SageMaker, шукаючи оновлення пакетів моделей у статусі Approved or Rejected.

Потім правило EventBridge налаштовується на цільовий CodePipeline, який запускає робочий процес створення нового компонента AWS IoT Greengrass за допомогою Amazon SageMaker Neo і Edge Manager.

Оптимізація моделей ML для цільової архітектури

Neo дозволяє оптимізувати моделі ML для виконання висновків на периферійних пристроях (і в хмарі). Він автоматично оптимізує моделі ML для кращої продуктивності на основі цільової архітектури та відокремлює модель від оригінального фреймворку, дозволяючи запускати її в спрощеному середовищі виконання.

Зверніться до наступного ноутбук для прикладу компіляції моделі PyTorch Resnet18 за допомогою Neo.

Створіть пакет розгортання, включивши компонент AWS IoT Greengrass

Edge Manager дозволяє керувати, захищати, розгортати та контролювати моделі на парку периферійних пристроїв. У наступному ноутбук, ви можете дізнатися більше про те, як створити мінімалістичний парк периферійних пристроїв і провести деякі експерименти з цією функцією.

Після налаштування групи та компіляції моделі потрібно запустити завдання пакування Edge Manager, яке готує модель для розгортання у групі. Ви можете розпочати завдання пакування за допомогою Boto3 SDK. Для наших параметрів ми використовуємо оптимізовану модель і метадані моделі. Додавши наступні параметри до OutputConfig, завдання також готує компонент AWS IoT Greengrass V2 із моделлю:

• PresetDeploymentType
• PresetDeploymentConfig

Дивіться наступний код:

import boto3
import time

SageMaker_client = boto3.client('SageMaker')

SageMaker_client.create_edge_packaging_job(
    EdgePackagingJobName="mlops-edge-packaging-{}".format(int(time.time()*1000)),
    CompilationJobName=compilation_job_name,
    ModelName="PytorchMLOpsEdgeModel",
    ModelVersion="1.0.0",
    RoleArn=role,
    OutputConfig={
        'S3OutputLocation': 's3://{}/model/'.format(bucket_name),
        "PresetDeploymentType": "GreengrassV2Component",
        "PresetDeploymentConfig": json.dumps(
            {"ComponentName": component_name, "ComponentVersion": component_version}
        ),
    }
)

Розгортайте моделі ML на краю в масштабі

Тепер настав час розгорнути модель на вашому парку периферійних пристроїв. По-перше, ми повинні переконатися, що у нас є все необхідне Управління ідентифікацією та доступом AWS (Я Є) Дозволи надавати наші пристрої IoT і мати можливість розгортати на них компоненти. Нам потрібні два основні елементи, щоб розпочати підключення пристроїв до нашої платформи IoT:

• Політика IAM – Ця політика дозволяє автоматичне надання таких пристроїв, приєднаних до користувача або ролі, що виконує надання. Він повинен мати дозволи на запис в IoT, щоб створити предмет і групу IoT, а також прикріпити необхідні політики до пристрою. Для отримання додаткової інформації див Мінімальна політика IAM для встановлення ресурсів.
• Роль IAM – ця роль пов’язана з речами та групами IoT, які ми створюємо. Ви можете створити цю роль під час ініціалізації з базовими дозволами, але вона не матиме таких функцій, як доступ до Amazon S3 або Служба управління ключами AWS (AWS KMS), які можуть знадобитися пізніше. Ви можете створити цю роль заздалегідь і повторно використовувати її під час надання пристрою. Для отримання додаткової інформації див Авторизуйте основні пристрої для взаємодії з AWS.

Встановлення та надання послуг AWS IoT Greengrass

Після того як у нас є політика IAM і роль, ми будемо готові встановити програмне забезпечення AWS IoT Greengrass Core з автоматичним наданням ресурсів. Хоча можна надати ресурси IoT, виконавши кроки вручну, існує зручна процедура автоматичного надання цих ресурсів під час встановлення ядра AWS IoT Greengrass v2. Це найкращий варіант для швидкого підключення нових пристроїв до платформи. Крім того default-jdk, потрібно встановити інші пакунки, наприклад curl, unzip та python3.

Коли ми надаємо наш пристрій, ім’я речі IoT має точно збігатися з назвою периферійного пристрою, визначеного в Edge Manager, інакше дані не будуть зафіксовані в цільовому сегменті S3.

Інсталятор може створити роль і псевдонім AWS IoT Greengrass під час встановлення, якщо вони не існують. Однак вони будуть створені з мінімальними дозволами та вимагатимуть вручну додати більше політик для взаємодії з іншими службами, такими як Amazon S3. Ми рекомендуємо заздалегідь створити ці ресурси IAM, як показано раніше, а потім повторно використовувати їх під час підключення нових пристроїв до облікового запису.

Упаковка компонентів моделі та висновку

Після того, як наш код буде розроблено, ми можемо розгорнути як код (для висновку), так і наші моделі ML як компоненти в наших пристроях.

Після навчання моделі ML у SageMaker ви можете оптимізувати модель за допомогою Neo за допомогою завдання компіляції Sagemaker. Отримані скомпільовані артефакти моделі потім можна запакувати в компонент GreenGrass V2 за допомогою пакувальника Edge Manager. Потім його можна зареєструвати як спеціальний компонент у Мої компоненти на консолі AWS IoT Greengrass. Цей компонент уже містить необхідні команди життєвого циклу для завантаження та розпакування артефакту моделі в нашому пристрої, щоб код висновку міг завантажити його для надсилання зображень, отриманих через нього.

Щодо коду виведення, ми повинні створити компонент за допомогою консолі або Інтерфейс командного рядка AWS (AWS CLI). По-перше, ми запакуємо наш вихідний код висновку та необхідні залежності в Amazon S3. Після завантаження коду ми можемо створити наш компонент, використовуючи рецепт у .yaml або JSON, як у наступному прикладі:

---
RecipeFormatVersion: 2020-01-25
ComponentName: dummymodel.inference
ComponentVersion: 0.0.1
ComponentDescription: Deploys inference code to a client
ComponentPublisher: Amazon Web Services, Inc.
ComponentDependencies:
  aws.GreenGrass.TokenExchangeService:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
  dummymodel:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
Manifests:
  - Platform:
      os: linux
      architecture: "*"
    Lifecycle:
      install: |-
        apt-get install python3-pip
        pip3 install numpy
        pip3 install sysv_ipc
        pip3 install boto3
        pip3 install grpcio-tools
        pip3 install grpcio
        pip3 install protobuf
        pip3 install SageMaker
        tar xf {artifacts:path}/sourcedir.tar.gz
      run:
        script: |-
          sleep 5 && sudo python3 {work:path}/inference.py 
    Artifacts:
      - URI: s3://BUCKET-NAME/path/to/inference/sourcedir.tar.gz
        Permission:
          Execute: OWNER

Цей приклад рецепту показує ім’я та опис нашого компонента, а також необхідні передумови перед командою запуску сценарію. Рецепт розпаковує артефакт у середовищі робочої папки на пристрої, і ми використовуємо цей шлях для запуску коду висновку. Команда AWS CLI для створення такого рецепту:

aws greengrassv2 create-component-version --region $REGION 
                                          --inline-recipe fileb://path/to/recipe.yaml

Тепер ви можете побачити цей компонент, створений на консолі AWS IoT Greengrass.

Майте на увазі, що версія компонента має значення, і вона повинна бути вказана у файлі рецептів. Повторення того самого номера версії призведе до помилки.

Після того, як нашу модель і код висновку буде налаштовано як компоненти, ми готові до їх розгортання.

Розгорніть додаток і модель за допомогою AWS IoT Greengrass

У попередніх розділах ви дізналися, як пакувати код висновку та моделі ML. Тепер ми можемо створити розгортання з декількома компонентами, які включають як компоненти, так і конфігурації, необхідні для взаємодії нашого коду висновку з моделлю в периферійному пристрої.

Агент Edge Manager — це компонент, який слід інсталювати на кожному периферійному пристрої, щоб увімкнути всі можливості Edge Manager. На консолі SageMaker у нас визначено групу пристроїв, яка має пов’язане відро S3. Усі периферійні пристрої, пов’язані з парком, збиратимуть і повідомлятимуть свої дані на цей шлях S3. Агент можна розгорнути як компонент в AWS IoT Greengrass v2, що спрощує встановлення та налаштування, ніж якби агент розгортався в автономному режимі. Під час розгортання агента як компонента нам потрібно вказати параметри його конфігурації, а саме парк пристроїв і шлях S3.

Ми створюємо конфігурацію розгортання з настроюваними компонентами для щойно створеної моделі та коду. Це налаштування визначено у файлі JSON, у якому перелічено назву та ціль розгортання, а також компоненти розгортання. Ми можемо додавати та оновлювати параметри конфігурації кожного компонента, наприклад, в агенті Edge Manager, де ми вказуємо назву парку та сегмент.

{
    "targetArn": "targetArn",
    "deploymentName": "dummy-deployment",
    "components": {
        "aws.GreenGrass.Nucleus": {
            "version": "2.5.3",
        },
        "aws.GreenGrass.Cli": {
            "version": "2.5.3"
        },
        "aws.GreenGrass.SageMakerEdgeManager": {
            "version": 1.1.0,
            "configurationUpdate": {
                "merge": {
                "DeviceFleetName": "FLEET-NAME",
                "BucketName": "BUCKET-NAME-URI"
                }
            }
        },
        "dummymodel.inference": {
            "version": "0.0.1"
        },
        "dummymodel": {
            "version": "0.0.1"
        }
    }
}

Варто зазначити, що ми додали не лише модель, компоненти висновку та агента, а й AWS IoT Greengrass CLI та ядро ​​як компоненти. Перший може допомогти налагодити певні розгортання локально на пристрої. Останній додається в розгортання, щоб налаштувати необхідний доступ до мережі з самого пристрою, якщо це необхідно (наприклад, налаштування проксі), а також у випадку, якщо ви хочете виконати OTA-оновлення ядра AWS IoT Greengrass v2. Ядро не розгорнуто, оскільки його встановлено на пристрої, і буде застосовано лише оновлення конфігурації (якщо оновлення не встановлено). Для розгортання нам просто потрібно виконати наступну команду над попередньою конфігурацією. Не забудьте налаштувати цільовий ARN, до якого буде застосовано розгортання (інтернет речей або група IoT). Ми також можемо розгорнути ці компоненти з консолі.

aws greengrassv2 create-deployment --region $REGION 
                                   --cli-input-json file://path/to/deployment.json

Відстежуйте та керуйте моделями ML, розгорнутими на межі

Тепер, коли ваша програма працює на периферійних пристроях, настав час зрозуміти, як контролювати парк для покращення керування, обслуговування та видимості. На консолі SageMaker виберіть Edge Manager на панелі навігації, а потім виберіть Парк пристроїв Edge. Звідси виберіть свій автопарк.

На сторінці даних про групу ви можете побачити деякі метадані моделей, які працюють на кожному пристрої вашої групи. Звіт про автопарк створюється кожні 24 години.

Дані, отримані кожним пристроєм через Edge Agent, надсилаються до сегмента S3 у форматі рядків json (JSONL). Процес надсилання отриманих даних керується з точки зору програми. Таким чином, ви можете вирішувати, чи надсилати ці дані, як і як часто.

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

Висновок

У цій публікації ви дізналися, як створити повне рішення, яке поєднує MLOps і ML@Edge за допомогою служб AWS. Створення такого рішення не є тривіальним, але ми сподіваємося, що еталонна архітектура, представлена ​​в цій публікації, може надихнути та допомогти вам створити надійну архітектуру для ваших власних бізнес-завдань. Ви також можете використовувати лише частини або модулі цієї архітектури, які інтегруються з вашим існуючим середовищем MLOps. Створюючи прототип по одному модулю за раз і використовуючи відповідні служби AWS для вирішення кожної частини цього завдання, ви можете навчитися створювати надійне середовище MLOps, а також ще більше спростити кінцеву архітектуру.

Наступним кроком ми радимо вам випробувати Sagemaker Edge Manager, щоб керувати своїм ML на життєвому циклі edge. Додаткову інформацію про роботу Edge Manager див Розгортайте моделі на межі за допомогою SageMaker Edge Manager .

Про авторів

Бруно Пістоне є архітектором спеціалізованих рішень AI/ML для AWS у Мілані. Він працює з клієнтами будь-якого розміру, допомагаючи їм глибше зрозуміти їхні технічні потреби та розробляти рішення штучного інтелекту та машинного навчання, які найкращим чином використовують AWS Cloud і стек Amazon Machine Learning. Сферою його знань є наскрізне машинне навчання, індустріалізація машинного навчання та MLOps. Йому подобається проводити час зі своїми друзями та досліджувати нові місця, а також подорожувати в нові місця.

Маттео Калабрезе є архітектором AI/ML Customer Delivery у групі AWS Professional Services. Він працює з великими підприємствами EMEA над проектами AI/ML, допомагаючи їм пропонувати, проектувати, доставляти, масштабувати та оптимізувати робочі навантаження ML. Його основний досвід — операції машинного навчання (MLOps) і машинне навчання на межі. Його мета — скоротити їхній час для оцінки та прискорення бізнес-результатів, надаючи найкращі практики AWS. У вільний час захоплюється походами та подорожами.

Рауль Діас Гарсія є старшим спеціалістом з обробки даних у команді AWS Professional Services. Він працює з великими корпоративними клієнтами в регіоні EMEA, де він допомагає їм впроваджувати рішення, пов’язані з комп’ютерним зором і машинним навчанням у просторі IoT.

Сократіс Картакіс є старшим спеціалістом з машинного навчання архітектором рішень для веб-сервісів Amazon. Sokratis зосереджується на тому, щоб дати можливість корпоративним клієнтам індустріалізувати свої рішення з машинного навчання (ML), використовуючи послуги AWS і формуючи їх операційну модель, тобто основу MLOps, і дорожню карту трансформації, використовуючи найкращі методи розробки. Він витратив понад 15 років на винайдення, проектування, керівництво та впровадження інноваційних наскрізних рішень ML та Інтернету речей (IoT) у сферах енергетики, роздрібної торгівлі, охорони здоров’я, фінансів/банківської справи, автоспорту тощо. Сократіс любить проводити вільний час з родиною та друзями або кататися на мотоциклах.

Самір Араужо є архітектором рішень AI/ML в AWS. Він допомагає клієнтам створювати рішення AI/ML, які вирішують їхні бізнес-задачі за допомогою AWS. Він працював над кількома проектами AI/ML, пов’язаними з комп’ютерним баченням, обробкою природної мови, прогнозуванням, ML at the edge тощо. Йому подобається грати з проектами обладнання та автоматизації у вільний час, і він особливо цікавиться робототехнікою.