L'Internet des objets (IoT) a permis à des clients de plusieurs secteurs, tels que la fabrication, l'automobile et l'énergie, de surveiller et de contrôler des environnements réels. En déployant une variété d'appareils IoT de pointe tels que des caméras, des thermostats et des capteurs, vous pouvez collecter des données, les envoyer vers le cloud et créer des modèles d'apprentissage automatique (ML) pour prédire les anomalies, les pannes, etc. Toutefois, si le cas d'utilisation nécessite une prédiction en temps réel, vous devez enrichir votre solution IoT avec des fonctionnalités de ML at the Edge (ML@Edge). ML@Edge est un concept qui dissocie le cycle de vie du modèle ML du cycle de vie de l'application et vous permet d'exécuter un pipeline ML de bout en bout qui comprend la préparation des données, la création de modèles, la compilation et l'optimisation de modèles, le déploiement de modèles (sur une flotte d'appareils de périphérie), l’exécution du modèle, ainsi que la surveillance et la gouvernance du modèle. Vous déployez l'application une fois et exécutez le pipeline ML autant de fois que nécessaire.

Comme vous vous en doutez, mettre en œuvre toutes les étapes proposées par le concept ML@Edge n’est pas anodin. Les développeurs doivent répondre à de nombreuses questions afin de mettre en œuvre une solution ML@Edge complète, par exemple :

• Comment exploiter des modèles ML sur une flotte (des centaines, des milliers ou des millions) d'appareils en périphérie ?
• Comment sécuriser mon modèle lors de son déploiement et de son exécution en périphérie ?
• Comment surveiller les performances de mon modèle et le réentraîner, si nécessaire ?

Dans cet article, vous apprendrez à répondre à toutes ces questions et à créer une solution de bout en bout pour automatiser votre pipeline ML@Edge. Vous verrez comment utiliser Gestionnaire de périphérie Amazon SageMaker, Amazon SageMakerStudioet AWS IoT Greengrass v2 pour créer un environnement MLOps (ML Operations) qui automatise le processus de création et de déploiement de modèles ML sur de grandes flottes d'appareils de périphérie.

Dans les sections suivantes, nous présentons une architecture de référence qui détaille tous les composants et flux de travail requis pour créer une solution complète pour les MLOps axée sur les charges de travail de périphérie. Ensuite, nous approfondissons les étapes que cette solution exécute automatiquement pour créer et préparer un nouveau modèle. Nous vous montrons également comment préparer les appareils Edge pour commencer à déployer, exécuter et surveiller des modèles ML, et vous montrerons comment surveiller et maintenir les modèles ML déployés sur votre flotte d'appareils.

Vue d'ensemble de la solution

La production de modèles ML robustes nécessite la collaboration de plusieurs personnes, telles que des scientifiques de données, des ingénieurs ML, des ingénieurs de données et des parties prenantes commerciales, dans le cadre d'une infrastructure semi-automatisée suivant des opérations spécifiques (MLOps). Aussi, la modularisation de l’environnement est importante afin de donner à tous ces différents personnages la flexibilité et l’agilité pour développer ou améliorer (indépendamment du workflow) le composant dont ils sont responsables. Un exemple d'une telle infrastructure consiste en plusieurs comptes AWS qui permettent cette collaboration et cette production des modèles ML à la fois dans le cloud et sur les appareils périphériques. Dans l'architecture de référence suivante, nous montrons comment nous avons organisé les multiples comptes et services qui composent cette plateforme MLOps de bout en bout pour créer des modèles ML et les déployer en périphérie.

Cette solution est composée des comptes suivants :

• Compte de lac de données – Les ingénieurs de données ingèrent, stockent et préparent des données provenant de plusieurs sources de données, y compris des bases de données sur site et des appareils IoT.
• Compte outillage – Les opérateurs informatiques gèrent et vérifient les pipelines CI/CD pour la livraison et le déploiement continus et automatisés de packages de modèles ML sur les comptes de pré-production et de production pour les appareils périphériques distants. Les exécutions de pipelines CI/CD sont automatisées grâce à l'utilisation de Amazon Event Bridge, qui surveille les événements de changement d'état des modèles et des cibles ML AWS CodePipeline.
• Compte d'expérimentation et de développement – Les data scientists peuvent mener des recherches et expérimenter plusieurs techniques et algorithmes de modélisation pour résoudre des problèmes commerciaux basés sur le ML, créant ainsi des solutions de preuve de concept. Les ingénieurs ML et les data scientists collaborent pour mettre à l'échelle une preuve de concept, créant des flux de travail automatisés à l'aide Pipelines Amazon SageMaker pour préparer les données et créer, entraîner et empaqueter des modèles ML. Le déploiement des pipelines est piloté via des pipelines CI/CD, tandis que le contrôle de version des modèles est réalisé à l'aide du Registre de modèles Amazon SageMaker. Les data scientists évaluent les métriques de plusieurs versions de modèle et demandent la promotion du meilleur modèle en production en déclenchant le pipeline CI/CD.
• Compte de pré-production – Avant la promotion du modèle dans l'environnement de production, le modèle doit être testé pour garantir sa robustesse dans un environnement de simulation. Par conséquent, l'environnement de pré-production est un simulateur de l'environnement de production, dans lequel les points de terminaison du modèle SageMaker sont déployés et testés automatiquement. Les méthodes de test peuvent inclure un test d'intégration, un test de résistance ou des tests spécifiques au ML sur les résultats d'inférence. Dans ce cas, l'environnement de production n'est pas un point de terminaison du modèle SageMaker mais un périphérique périphérique. Pour simuler un périphérique Edge en pré-production, deux approches sont possibles : utiliser un Cloud de calcul élastique Amazon (Amazon EC2) avec les mêmes caractéristiques matérielles, ou utilisez un banc de test en laboratoire composé des appareils réels. Avec cette infrastructure, le pipeline CI/CD déploie le modèle sur le simulateur correspondant et effectue automatiquement les multiples tests. Une fois les tests exécutés avec succès, le pipeline CI/CD nécessite une approbation manuelle (par exemple, de la part de la partie prenante IoT pour promouvoir le modèle en production).
• Compte de production – Dans le cas de l'hébergement du modèle sur le Cloud AWS, le pipeline CI/CD déploie un point de terminaison du modèle SageMaker sur le compte de production. Dans ce cas, l’environnement de production se compose de plusieurs flottes d’appareils de pointe. Par conséquent, le pipeline CI/CD utilise Edge Manager pour déployer les modèles sur la flotte d'appareils correspondante.
• Appareils Edge – Les périphériques Edge distants sont des périphériques matériels qui peuvent exécuter des modèles ML à l'aide d'Edge Manager. Il permet à l'application sur ces appareils de gérer les modèles, d'exécuter des inférences sur les modèles et de capturer des données en toute sécurité dans Service de stockage simple Amazon (Amazon S3).

Projets SageMaker vous aider à automatiser le processus de provisionnement des ressources dans chacun de ces comptes. Nous n'abordons pas en profondeur cette fonctionnalité, mais pour en savoir plus sur la façon de créer un modèle de projet SageMaker qui déploie des modèles ML sur plusieurs comptes, consultez Déploiement de modèle multicompte avec Amazon SageMaker Pipelines.

Compte de pré-production : jumeau numérique

Après le processus de formation, le modèle résultant doit être évalué. Dans le compte de pré-production, vous disposez d’un appareil Edge simulé. Il représente le jumeau numérique du périphérique Edge sur lequel le modèle ML s’exécute en production. Cet environnement a le double objectif d'effectuer les tests classiques (tels que les tests unitaires, d'intégration et de fumée) et d'être un terrain de jeu pour l'équipe de développement. Cet appareil est simulé à l'aide d'une instance EC2 où tous les composants nécessaires à la gestion du modèle ML ont été déployés.

Les services concernés sont les suivants :

• Noyau AWS IoT - Nous utilisons Noyau AWS IoT pour créer des objets d'objet AWS IoT, créer un parc d'appareils, enregistrer le parc d'appareils afin qu'il puisse interagir avec le cloud, créer des certificats X.509 pour authentifier les appareils de périphérie auprès d'AWS IoT Core, associer l'alias de rôle à AWS IoT Core qui a été généré lorsque la flotte a créé, obtenez un point de terminaison spécifique au compte AWS pour le fournisseur d'informations d'identification, obtenez un fichier Amazon Root CA officiel et téléchargez le fichier Amazon CA sur Amazon S3.
• Amazon Sagemaker Néo – Faiseur de sauge Neo optimise automatiquement les modèles d'apprentissage automatique pour que l'inférence s'exécute plus rapidement sans perte de précision. Il prend en charge le modèle d'apprentissage automatique déjà construit avec DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX ou XGBoost et formé sur Amazon SageMaker ou ailleurs. Ensuite, vous choisissez votre plate-forme matérielle cible, qui peut être une instance d'hébergement SageMaker ou un périphérique Edge basé sur des processeurs d'Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments ou Xilinx.
• Gestionnaire de périphérie – Nous utilisons Edge Manager pour enregistrer et gérer l'appareil Edge au sein des flottes Sagemaker. Les flottes sont des ensembles d'appareils regroupés logiquement que vous pouvez utiliser pour collecter et analyser des données. En outre, le packager Edge Manager emballe le modèle optimisé et crée un composant AWS IoT Greengrass V2 qui peut être directement déployé. Vous pouvez utiliser Edge Manager pour faire fonctionner des modèles ML sur une flotte de caméras intelligentes, de haut-parleurs intelligents, de robots et d'autres flottes d'appareils SageMaker.
• AWS IoT Greengrass V2 - AWS IoT Greengrass vous permet de déployer des composants dans les appareils simulés à l'aide d'une instance EC2. En utilisant l'agent AWS IoT Greengrass V2 dans les instances EC2, nous pouvons simplifier l'accès, la gestion et le déploiement de l'agent et du modèle Edge Manager sur les appareils. Sans AWS IoT Greengrass V2, la configuration des appareils et des flottes pour utiliser Edge Manager nécessite que vous copiez manuellement l'agent à partir d'un compartiment de version S3. Avec l'intégration d'AWS IoT Greengrass V2 et Edge Manager, il est possible d'utiliser les composants AWS IoT Greengrass V2. Les composants sont des modules logiciels prédéfinis qui peuvent connecter des appareils périphériques aux services AWS ou à un service tiers via AWS IoT Greengrass.
• Agent Edge Manager – L'agent Edge Manager est déployé via AWS IoT Greengrass V2 dans l'instance EC2. L'agent peut charger plusieurs modèles à la fois et effectuer des inférences avec les modèles chargés sur les appareils Edge. Le nombre de modèles que l'agent peut charger est déterminé par la mémoire disponible sur l'appareil.
• Amazon S3 – Nous utilisons un compartiment S3 pour stocker les données d'inférence capturées par l'agent Edge Manager.

Nous pouvons définir un compte de pré-production comme un jumeau numérique pour tester les modèles ML avant de les déplacer vers de véritables appareils de pointe. Cela offre les avantages suivants :

• Agilité et flexibilité – Les data scientists et les ingénieurs ML doivent rapidement valider si le modèle ML et les scripts associés (scripts de prétraitement et d'inférence) fonctionneront à la périphérie de l'appareil. Cependant, les départements IoT et science des données des grandes entreprises peuvent être des entités différentes. En répliquant à l'identique la pile technologique dans le cloud, les data scientists et les ingénieurs ML peuvent itérer et consolider les artefacts avant le déploiement.
• Évaluation des risques et délais de production accélérés – Le déploiement sur le périphérique Edge est la dernière étape du processus. Après avoir tout validé dans un environnement isolé et autonome, sécurisez-le pour qu'il respecte les spécifications requises par la périphérie en termes de qualité, de performances et d'intégration. Cela permet d'éviter l'implication supplémentaire d'autres personnes du département IoT pour corriger et itérer sur les versions d'artefacts.
• Collaboration d’équipe améliorée et amélioration de la qualité et des performances – L'équipe de développement peut immédiatement évaluer l'impact du modèle ML en analysant les métriques matérielles de pointe et en mesurant le niveau d'interactions avec des outils tiers (par exemple, taux d'E/S). Ensuite, l’équipe IoT est uniquement responsable du déploiement dans l’environnement de production et peut être sûre que les artefacts sont précis pour un environnement de production.
• Aire de jeux intégrée pour les tests – Compte tenu de la cible des modèles ML, l'environnement de pré-production dans un flux de travail traditionnel doit être représenté par un périphérique périphérique en dehors de l'environnement cloud. Cela introduit un autre niveau de complexité. Des intégrations sont nécessaires pour collecter des métriques et des commentaires. Au lieu de cela, en utilisant l’environnement simulé du jumeau numérique, les interactions sont réduites et les délais de mise sur le marché sont raccourcis.

Compte de production et environnement Edge

Une fois les tests terminés et la stabilité des artefacts atteinte, vous pouvez procéder au déploiement en production via les pipelines. Le déploiement de l'artefact s'effectue par programme après qu'un opérateur a approuvé l'artefact. Cependant, l'accès au Console de gestion AWS est accordé aux opérateurs en mode lecture seule pour pouvoir surveiller les métadonnées associées aux flottes et donc avoir un aperçu de la version du modèle ML déployé et d'autres métriques associées au cycle de vie.

Les flottes d'appareils Edge appartiennent au compte de production AWS. Ce compte dispose de configurations de sécurité et de mise en réseau spécifiques pour permettre la communication entre le cloud et les appareils périphériques. Les principaux services AWS déployés dans le compte de production sont Edge Manager, qui est responsable de la gestion de toutes les flottes d'appareils, de la collecte des données et de l'exploitation des modèles ML, et AWS IoT Core, qui gère les objets IoT, les certificats, les alias de rôle et les points de terminaison.

Dans le même temps, nous devons configurer un appareil périphérique avec les services et les composants nécessaires pour gérer les modèles ML. Les principaux composants sont les suivants :

• AWS IoT Greengrass V2
• Un agent Edge Manager
• Certificats AWS IoT
• Application.py, qui est responsable de l'orchestration du processus d'inférence (récupération des informations de la source de données Edge et réalisation de l'inférence à l'aide de l'agent Edge Manager et du modèle ML chargé)
• Une connexion à Amazon S3 ou au compte Data Lake pour stocker les données inférées

Pipeline de ML automatisé

Maintenant que vous en savez plus sur l'organisation et les composants de l'architecture de référence, nous pouvons approfondir le pipeline ML que nous utilisons pour créer, entraîner et évaluer le modèle ML dans le compte de développement.

Un pipeline (construit à l'aide de Pipelines de création de modèles Amazon SageMaker) est une série d'étapes interconnectées définies par une définition de pipeline JSON. Cette définition de pipeline code un pipeline à l'aide d'un graphique acyclique dirigé (DAG). Ce DAG donne des informations sur les exigences et les relations entre chaque étape de votre pipeline. La structure du DAG d'un pipeline est déterminée par les dépendances de données entre les étapes. Ces dépendances de données sont créées lorsque les propriétés de la sortie d'une étape sont transmises comme entrée à une autre étape.

Pour permettre aux équipes de science des données d'automatiser facilement la création de nouvelles versions de modèles ML, il est important d'introduire des étapes de validation et des données automatisées pour alimenter et améliorer continuellement les modèles ML, ainsi que des stratégies de surveillance des modèles pour permettre le déclenchement du pipeline. Le diagramme suivant montre un exemple de pipeline.

Pour activer les automatisations et les fonctionnalités MLOps, il est important de créer des composants modulaires permettant de créer des artefacts de code réutilisables qui peuvent être partagés entre différentes étapes et cas d'utilisation du ML. Cela vous permet de faire passer rapidement la mise en œuvre d’une phase d’expérimentation à une phase de production en automatisant la transition.

Les étapes de définition d'un pipeline ML pour permettre la formation continue et la gestion des versions des modèles ML sont les suivantes :

• Prétraitement – Le processus de nettoyage des données, d’ingénierie des fonctionnalités et de création d’ensembles de données pour la formation de l’algorithme ML
• Formation – Le processus de formation de l’algorithme ML développé pour générer une nouvelle version de l’artefact du modèle ML
• Evaluation – Le processus d'évaluation du modèle ML généré, pour extraire des métriques clés liées au comportement du modèle sur de nouvelles données non vues lors de la phase de formation
• Inscription – Le processus de versionnage du nouvel artefact de modèle ML formé en liant les métriques extraites à l'artefact généré

Vous pouvez voir plus de détails sur la façon de créer un pipeline SageMaker dans ce qui suit cahier.

Déclencher des pipelines CI/CD à l'aide d'EventBridge

Lorsque vous avez terminé de créer le modèle, vous pouvez démarrer le processus de déploiement. La dernière étape du pipeline SageMaker défini dans la section précédente enregistre une nouvelle version du modèle dans le groupe de registre de modèles SageMaker spécifique. Le déploiement d'une nouvelle version du modèle ML est géré à l'aide du statut du registre des modèles. En approuvant ou en rejetant manuellement une version de modèle ML, cette étape déclenche un événement qui est capturé par EventBridge. Cet événement peut ensuite démarrer un nouveau pipeline (CI/CD cette fois) pour créer une nouvelle version du composant AWS IoT Greengrass qui est ensuite déployée sur les comptes de pré-production et de production. La capture d'écran suivante montre notre règle EventBridge définie.

Cette règle surveille le groupe de packages de modèles SageMaker en recherchant les mises à jour des packages de modèles dans l'état Approved or Rejected.

La règle EventBridge est ensuite configurée pour cibler CodePipeline, qui démarre le flux de travail de création d'un nouveau composant AWS IoT Greengrass à l'aide de Amazon Sage Maker Neo et Gestionnaire de bords.

Optimiser les modèles ML pour l'architecture cible

Neo vous permet d'optimiser les modèles ML pour effectuer des inférences sur les appareils Edge (et dans le cloud). Il optimise automatiquement les modèles ML pour de meilleures performances en fonction de l'architecture cible et dissocie le modèle du framework d'origine, vous permettant de l'exécuter sur un environnement d'exécution léger.

Reportez-vous à ce qui suit cahier pour un exemple de comment compiler un modèle PyTorch Resnet18 à l'aide de Neo.

Créez le package de déploiement en incluant le composant AWS IoT Greengrass

Edge Manager vous permet de gérer, sécuriser, déployer et surveiller des modèles sur une flotte d'appareils Edge. Dans ce qui suit cahier, vous pouvez voir plus de détails sur la façon de créer une flotte minimaliste d'appareils de périphérie et effectuer quelques expériences avec cette fonctionnalité.

Après avoir configuré la flotte et compilé le modèle, vous devez exécuter une tâche de packaging Edge Manager, qui prépare le modèle à déployer sur la flotte. Vous pouvez démarrer une tâche de packaging à l'aide du SDK Boto3. Pour nos paramètres, nous utilisons le modèle optimisé et les métadonnées du modèle. En ajoutant les paramètres suivants à OutputConfig, la tâche prépare également un composant AWS IoT Greengrass V2 avec le modèle :

• PresetDeploymentType
• PresetDeploymentConfig

Voir le code suivant:

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}
        ),
    }
)

Déployez des modèles ML à la périphérie et à grande échelle

Il est maintenant temps de déployer le modèle sur votre flotte d'appareils Edge. Premièrement, nous devons nous assurer que nous disposons des ressources nécessaires Gestion des identités et des accès AWS (JE SUIS) autorisations pour provisionner nos appareils IoT et pouvoir y déployer des composants. Nous avons besoin de deux éléments de base pour commencer à intégrer des appareils dans notre plateforme IoT :

• Stratégie IAM – Cette politique permet le provisionnement automatique de ces appareils, attachés à l’utilisateur ou au rôle effectuant le provisionnement. Il doit disposer des autorisations d’écriture IoT pour créer l’objet et le groupe IoT, ainsi que pour attacher les stratégies nécessaires à l’appareil. Pour plus d'informations, reportez-vous à Politique IAM minimale permettant au programme d'installation de provisionner les ressources.
• Rôle IAM – ce rôle est attaché aux objets et groupes IoT que nous créons. Vous pouvez créer ce rôle au moment du provisionnement avec des autorisations de base, mais il lui manquera des fonctionnalités telles que l'accès à Amazon S3 ou Service de gestion des clés AWS (AWS KMS) qui pourrait être nécessaire ultérieurement. Vous pouvez créer ce rôle au préalable et le réutiliser lorsque nous provisionnons l'appareil. Pour plus d'informations, reportez-vous à Autoriser les appareils principaux à interagir avec AWS.

Installation et provisionnement d'AWS IoT Greengrass

Une fois la politique et le rôle IAM en place, nous sommes prêts à installer le logiciel AWS IoT Greengrass Core avec provisionnement automatique des ressources. Bien qu'il soit possible de provisionner les ressources IoT en suivant des étapes manuelles, il existe une procédure pratique permettant de provisionner automatiquement ces ressources lors de l'installation du noyau AWS IoT Greengrass v2. Il s’agit de l’option privilégiée pour intégrer rapidement de nouveaux appareils sur la plateforme. En plus default-jdk, d'autres packages doivent être installés, tels que curl, unzipet python3.

Lorsque nous provisionnons notre appareil, le nom de l'objet IoT doit être exactement le même que celui de l'appareil périphérique défini dans Edge Manager, sinon les données ne seront pas capturées dans le compartiment S3 de destination.

Le programme d'installation peut créer le rôle et l'alias AWS IoT Greengrass lors de l'installation s'ils n'existent pas. Cependant, ils seront créés avec des autorisations minimales et nécessiteront l'ajout manuel de stratégies supplémentaires pour interagir avec d'autres services tels qu'Amazon S3. Nous vous recommandons de créer ces ressources IAM au préalable, comme indiqué précédemment, puis de les réutiliser lorsque vous intégrez de nouveaux appareils dans le compte.

Conditionnement des composants de modèle et d'inférence

Une fois notre code développé, nous pouvons déployer à la fois le code (à des fins d'inférence) et nos modèles ML en tant que composants dans nos appareils.

Une fois le modèle ML formé dans SageMaker, vous pouvez optimiser le modèle avec Neo à l'aide d'une tâche de compilation Sagemaker. Les artefacts de modèle compilés résultants peuvent ensuite être regroupés dans un composant GreenGrass V2 à l'aide du packager Edge Manager. Ensuite, il peut être enregistré en tant que composant personnalisé dans le Mes composants sur la console AWS IoT Greengrass. Ce composant contient déjà les commandes de cycle de vie nécessaires pour télécharger et décompresser l'artefact de modèle dans notre appareil, afin que le code d'inférence puisse le charger pour envoyer les images capturées via celui-ci.

Concernant le code d'inférence, il faut créer un composant à l'aide de la console ou Interface de ligne de commande AWS (AWS CLI). Tout d'abord, nous emballons notre code d'inférence source et les dépendances nécessaires dans Amazon S3. Après avoir téléchargé le code, nous pouvons créer notre composant à l'aide d'une recette en .yaml ou JSON comme dans l'exemple suivant :

---
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

Cet exemple de recette montre le nom et la description de notre composant, ainsi que les prérequis nécessaires avant notre commande d'exécution de script. La recette décompresse l'artefact dans un environnement de dossier de travail sur l'appareil, et nous utilisons ce chemin pour exécuter notre code d'inférence. La commande AWS CLI pour créer une telle recette est :

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

Vous pouvez maintenant voir ce composant créé sur la console AWS IoT Greengrass.

Attention au fait que la version du composant est importante et qu'elle doit être spécifiée dans le fichier de recette. Répéter le même numéro de version renverra une erreur.

Une fois notre modèle et notre code d'inférence configurés en tant que composants, nous sommes prêts à les déployer.

Déployer l'application et le modèle à l'aide d'AWS IoT Greengrass

Dans les sections précédentes, vous avez appris à empaqueter le code d'inférence et les modèles ML. Nous pouvons désormais créer un déploiement avec plusieurs composants qui incluent à la fois les composants et les configurations nécessaires pour que notre code d'inférence interagisse avec le modèle dans le périphérique périphérique.

L'agent Edge Manager est le composant qui doit être installé sur chaque périphérique Edge afin d'activer toutes les fonctionnalités Edge Manager. Sur la console SageMaker, nous avons défini une flotte d'appareils, à laquelle est associé un compartiment S3. Tous les appareils Edge associés à la flotte captureront et rapporteront leurs données à ce chemin S3. L'agent peut être déployé en tant que composant dans AWS IoT Greengrass v2, ce qui facilite son installation et sa configuration que si l'agent était déployé en mode autonome. Lors du déploiement de l'agent en tant que composant, nous devons spécifier ses paramètres de configuration, à savoir le parc d'appareils et le chemin S3.

Nous créons une configuration de déploiement avec les composants personnalisés pour le modèle et le code que nous venons de créer. Cette configuration est définie dans un fichier JSON qui répertorie le nom et la cible du déploiement, ainsi que les composants du déploiement. Nous pouvons ajouter et mettre à jour les paramètres de configuration de chaque composant, comme dans l'agent Edge Manager, où nous spécifions le nom de la flotte et le compartiment.

{
    "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"
        }
    }
}

Il convient de noter que nous avons ajouté non seulement le modèle, les composants d'inférence et l'agent, mais également la CLI et le noyau AWS IoT Greengrass en tant que composants. Le premier peut aider à déboguer certains déploiements localement sur l'appareil. Ce dernier est ajouté au déploiement pour configurer l'accès réseau nécessaire depuis l'appareil lui-même si nécessaire (par exemple, paramètres de proxy), et également au cas où vous souhaiteriez effectuer une mise à niveau OTA du noyau AWS IoT Greengrass v2. Le noyau n'est pas déployé car il est installé dans l'appareil, et seule la mise à jour de la configuration sera appliquée (sauf si une mise à niveau est en place). Pour déployer, nous devons simplement exécuter la commande suivante sur la configuration précédente. N'oubliez pas de configurer l'ARN cible auquel le déploiement sera appliqué (un objet IoT ou un groupe IoT). Nous pouvons également déployer ces composants depuis la console.

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

Surveiller et gérer les modèles ML déployés en périphérie

Maintenant que votre application s'exécute sur les appareils de périphérie, il est temps de comprendre comment surveiller la flotte pour améliorer la gouvernance, la maintenance et la visibilité. Sur la console SageMaker, choisissez Gestionnaire de périphérie dans le volet de navigation, puis choisissez Flottes d'appareils Edge. À partir de là, choisissez votre flotte.

Sur la page de détail de la flotte, vous pouvez voir certaines métadonnées des modèles exécutés sur chaque appareil de votre flotte. Le rapport de flotte est généré toutes les 24 heures.

Les données capturées par chaque appareil via Edge Agent sont envoyées à un compartiment S3 au format de lignes json (JSONL). Le processus d'envoi des données capturées est géré du point de vue de l'application. Vous êtes donc libre de décider si vous souhaitez envoyer ces données, comment et à quelle fréquence.

Vous pouvez utiliser ces données pour de nombreuses choses, comme surveiller la dérive des données et la qualité du modèle, créer un nouvel ensemble de données, enrichir un lac de données, etc. Un exemple simple de la façon d'utiliser ces données est lorsque vous identifiez une dérive des données dans la façon dont les utilisateurs interagissent avec votre application et que vous devez former un nouveau modèle. Vous créez ensuite un nouvel ensemble de données avec les données capturées et le recopiez sur le compte de développement. Cela peut démarrer automatiquement une nouvelle exécution de votre environnement qui crée un nouveau modèle et le redéploye sur l'ensemble du parc pour conserver les performances de la solution déployée.

Conclusion

Dans cet article, vous avez appris à créer une solution complète combinant MLOps et ML@Edge à l'aide des services AWS. Construire une telle solution n’est pas anodin, mais nous espérons que l’architecture de référence présentée dans cet article pourra vous inspirer et vous aider à construire une architecture solide pour vos propres défis commerciaux. Vous pouvez également utiliser uniquement les parties ou modules de cette architecture qui s'intègrent à votre environnement MLOps existant. En prototypant un seul module à la fois et en utilisant les services AWS appropriés pour relever chaque élément de ce défi, vous pouvez apprendre à créer un environnement MLOps robuste et également simplifier davantage l'architecture finale.

Dans la prochaine étape, nous vous encourageons à essayer Sagemaker Edge Manager pour gérer votre ML au cycle de vie Edge. Pour plus d'informations sur le fonctionnement d'Edge Manager, voir Déployez des modèles en périphérie avec SageMaker Edge Manager .

À propos des auteurs

Bruno Piston est un architecte de solutions spécialisé AI/ML pour AWS basé à Milan. Il travaille avec des clients de toutes tailles pour les aider à comprendre en profondeur leurs besoins techniques et à concevoir des solutions d'IA et d'apprentissage automatique qui tirent le meilleur parti du cloud AWS et de la pile Amazon Machine Learning. Son domaine d'expertise est l'apprentissage automatique de bout en bout, l'industrialisation de l'apprentissage automatique et les MLOps. Il aime passer du temps avec ses amis et explorer de nouveaux endroits, ainsi que voyager vers de nouvelles destinations.

Matteo Calabrese est un architecte de livraison client IA/ML au sein de l'équipe AWS Professional Services. Il travaille avec de grandes entreprises de la région EMEA sur des projets d'IA/ML, les aidant à proposer, concevoir, livrer, mettre à l'échelle et optimiser les charges de travail de production ML. Ses principales expertises sont le ML Operation (MLOps) et le Machine Learning at Edge. Son objectif est de réduire leur délai de valorisation et d'accélérer les résultats commerciaux en fournissant les meilleures pratiques AWS. Dans ses temps libres, il aime faire de la randonnée et voyager.

Raúl Díaz García est un Sr Data Scientist au sein de l'équipe AWS Professional Services. Il travaille avec de grandes entreprises clientes dans la région EMEA, où il les aide à mettre en œuvre des solutions liées à la vision par ordinateur et à l'apprentissage automatique dans l'espace IoT.

Socrate Kartakis est un architecte principal de solutions spécialisées en apprentissage automatique pour Amazon Web Services. Sokratis vise à permettre aux entreprises clientes d'industrialiser leurs solutions d'apprentissage automatique (ML) en exploitant les services AWS et en façonnant leur modèle d'exploitation, c'est-à-dire la base MLOps, et la feuille de route de transformation en exploitant les meilleures pratiques de développement. Il a passé plus de 15 ans à inventer, concevoir, diriger et mettre en œuvre des solutions innovantes de ML et d'Internet des objets (IoT) au niveau de la production dans les domaines de l'énergie, de la vente au détail, de la santé, de la finance/banque, du sport automobile, etc. Sokratis aime passer son temps libre avec sa famille et ses amis, ou faire de la moto.

Samir Araújo est un architecte de solutions AI / ML chez AWS. Il aide les clients à créer des solutions d'IA / ML qui résolvent leurs défis commerciaux à l'aide d'AWS. Il a travaillé sur plusieurs projets d'IA / ML liés à la vision par ordinateur, au traitement du langage naturel, à la prévision, au ML à la périphérie, etc. Il aime jouer avec des projets de matériel et d'automatisation pendant son temps libre, et il a un intérêt particulier pour la robotique.