MLOps på kanten med Amazon SageMaker Edge Manager og AWS IoT Greengrass

Internet of Things (IoT) har gjort det muligt for kunder i flere industrier, såsom fremstilling, bilindustri og energi, at overvåge og kontrollere virkelige miljøer. Ved at implementere en række forskellige IoT-enheder, såsom kameraer, termostater og sensorer, kan du indsamle data, sende dem til skyen og bygge maskinlæringsmodeller (ML) til at forudsige uregelmæssigheder, fejl og mere. Men hvis brugssagen kræver forudsigelse i realtid, skal du berige din IoT-løsning med ML ved kanten (ML@Edge)-funktioner. ML@Edge er et koncept, der afkobler ML-modellens livscyklus fra appens livscyklus og giver dig mulighed for at køre en end-to-end ML-pipeline, der inkluderer dataforberedelse, modelbygning, modelkompilering og -optimering, modelimplementering (til en flåde af edge-enheder), modeludførelse, og modelovervågning og -styring. Du implementerer appen én gang og kører ML-pipeline så mange gange, du har brug for.

Som du kan forestille dig, er det ikke trivielt at implementere alle de trin, der foreslås af ML@Edge-konceptet. Der er mange spørgsmål, som udviklere skal tage stilling til for at implementere en komplet ML@Edge-løsning, for eksempel:

• Hvordan betjener jeg ML-modeller på en flåde (hundrede, tusinder eller millioner) af enheder på kanten?
• Hvordan sikrer jeg min model, mens jeg installerer og kører den i kanten?
• Hvordan overvåger jeg min models ydeevne og genoplærer den, hvis det er nødvendigt?

I dette indlæg lærer du, hvordan du besvarer alle disse spørgsmål og bygger en ende-til-ende-løsning til automatisering af din ML@Edge-pipeline. Du vil se, hvordan du bruger Amazon SageMaker Edge Manager, Amazon SageMaker Studioog AWS IoT Greengrass v2 at skabe et MLOps-miljø (ML Operations), der automatiserer processen med at bygge og implementere ML-modeller til store flåder af edge-enheder.

I de næste afsnit præsenterer vi en referencearkitektur, der beskriver alle de komponenter og arbejdsgange, der kræves for at bygge en komplet løsning til MLO'er, der fokuserer på edge-arbejdsbelastninger. Derefter dykker vi dybt ned i de trin, denne løsning kører automatisk for at bygge og forberede en ny model. Vi viser dig også, hvordan du forbereder edge-enhederne til at begynde at implementere, køre og overvåge ML-modeller og demonstrere, hvordan du overvåger og vedligeholder de ML-modeller, der er implementeret til din flåde af enheder.

Løsningsoversigt

Produktion af robuste ML-modeller kræver samarbejde mellem flere personer, såsom datavidenskabsmænd, ML-ingeniører, dataingeniører og forretningsinteressenter, under en semi-automatisk infrastruktur efter specifikke operationer (MLOps). Modulariseringen af ​​miljøet er også vigtig for at give alle disse forskellige personer fleksibiliteten og smidigheden til at udvikle eller forbedre (uafhængigt af arbejdsgangen) den komponent, som de er ansvarlige for. Et eksempel på en sådan infrastruktur består af flere AWS-konti, der muliggør dette samarbejde og produktion af ML-modellerne både i skyen og til kanten enheder. I den følgende referencearkitektur viser vi, hvordan vi organiserede de mange konti og tjenester, der udgør denne ende-til-ende MLOps-platform til at bygge ML-modeller og implementere dem på kanten.

Denne løsning består af følgende konti:

• Data sø konto – Dataingeniører indtager, lagrer og forbereder data fra flere datakilder, herunder lokale databaser og IoT-enheder.
• Værktøjskonto – IT-operatører administrerer og kontrollerer CI/CD-pipelines for automatiseret kontinuerlig levering og udrulning af ML-modelpakker på tværs af præproduktions- og produktionskonti for remote edge-enheder. Kørsler af CI/CD-pipelines automatiseres ved brug af Amazon Eventbridge, som overvåger ændringsstatushændelser for ML-modeller og -mål AWS CodePipeline.
• Eksperiment- og udviklingsregnskab – Dataforskere kan udføre forskning og eksperimentere med flere modelleringsteknikker og algoritmer for at løse forretningsproblemer baseret på ML, hvilket skaber proof of concept-løsninger. ML-ingeniører og datavidenskabsmænd samarbejder om at skalere et proof of concept og skaber automatiserede arbejdsgange ved hjælp af Amazon SageMaker Pipelines at forberede data og bygge, træne og pakke ML-modeller. Udbredelsen af ​​rørledningerne drives via CI/CD-rørledninger, mens versionsstyringen af ​​modellerne opnås ved hjælp af Amazon SageMaker-modelregistrering. Datavidenskabsmænd evaluerer metrikken for flere modelversioner og anmoder om promovering af den bedste model til produktion ved at udløse CI/CD-pipeline.
• Præproduktionskonto – Før modellen promoveres til produktionsmiljøet, skal modellen testes for at sikre robusthed i et simuleringsmiljø. Derfor er præproduktionsmiljøet en simulator af produktionsmiljøet, hvor SageMaker modelslutpunkter implementeres og testes automatisk. Testmetoder kan omfatte en integrationstest, stresstest eller ML-specifikke test på slutningsresultater. I dette tilfælde er produktionsmiljøet ikke en SageMaker-modelslutpunkt, men en edge-enhed. For at simulere en kant-enhed i præproduktion er to tilgange mulige: brug en Amazon Elastic Compute Cloud (Amazon EC2) instans med de samme hardwareegenskaber, eller brug en in-lab testbed bestående af de faktiske enheder. Med denne infrastruktur implementerer CI/CD-pipelinen modellen til den tilsvarende simulator og udfører de multiple tests automatisk. Efter at testene er gennemført med succes, kræver CI/CD-pipelinen manuel godkendelse (f.eks. fra IoT-interessenten for at fremme modellen til produktion).
• Produktionskonto – I tilfælde af hosting af modellen på AWS Cloud, implementerer CI/CD-pipelinen et SageMaker-modelslutpunkt på produktionskontoen. I dette tilfælde består produktionsmiljøet af flere flåder af kantenheder. Derfor bruger CI/CD-pipelinen Edge Manager til at implementere modellerne til den tilsvarende flåde af enheder.
• Edge-enheder – Remote edge-enheder er hardwareenheder, der kan køre ML-modeller ved hjælp af Edge Manager. Det giver applikationen på disse enheder mulighed for at administrere modellerne, køre slutninger mod modellerne og indfange data sikkert i Amazon Simple Storage Service (Amazon S3).

SageMaker projekter hjælpe dig med at automatisere processen med at klargøre ressourcer inden for hver af disse konti. Vi dykker ikke dybt ned i denne funktion, men for at lære mere om, hvordan man bygger en SageMaker-projektskabelon, der implementerer ML-modeller på tværs af konti, tjek ud Multi-konto modelimplementering med Amazon SageMaker Pipelines.

Præproduktionskonto: Digital tvilling

Efter træningsprocessen skal den resulterende model evalueres. I præproduktionskontoen har du en simuleret Edge-enhed. Det repræsenterer digital tvilling af kantanordningen, som ML-modellen kører på i produktion. Dette miljø har det dobbelte formål at udføre de klassiske tests (såsom enhed, integration og røg) og at være en legeplads for udviklingsteamet. Denne enhed simuleres ved hjælp af en EC2-instans, hvor alle de komponenter, der er nødvendige for at styre ML-modellen, blev implementeret.

De involverede tjenester er som følger:

• AWS IoT Core - Vi bruger AWS IoT Core for at oprette AWS IoT-tingobjekter, oprette en enhedsflåde, registrere enhedsflåden, så den kan interagere med skyen, oprette X.509-certifikater for at godkende edge-enheder til AWS IoT Core, tilknytte rollealiaset til AWS IoT Core, der blev genereret, da flåden har oprettet, få et AWS-kontospecifikt slutpunkt for legitimationsudbyderen, få en officiel Amazon Root CA-fil og uploade Amazon CA-filen til Amazon S3.
• Amazon Sagemaker Neo – Sagemager Neo optimerer automatisk maskinlæringsmodeller, så de kan løbe hurtigere uden tab af nøjagtighed. Den understøtter maskinlæringsmodeller, der allerede er bygget med DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX eller XGBoost og trænet i Amazon SageMaker eller andre steder. Så vælger du din målhardwareplatform, som kan være en SageMaker-hostinginstans eller en edge-enhed baseret på processorer fra Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments eller Xilinx.
• Edge Manager – Vi bruger Edge Manager til at registrere og administrere edge-enheden i Sagemaker-flåderne. Flåder er samlinger af logisk grupperede enheder, du kan bruge til at indsamle og analysere data. Derudover pakker Edge Manager-pakkeren den optimerede model og skaber en AWS IoT Greengrass V2-komponent, der kan implementeres direkte. Du kan bruge Edge Manager til at betjene ML-modeller på en flåde af smartkameraer, smarthøjttalere, robotter og andre SageMaker-enhedsflåder.
• AWS IoT Greengrass V2 - AWS IoT Greengrass giver dig mulighed for at implementere komponenter i de simulerede enheder ved hjælp af en EC2-instans. Ved at bruge AWS IoT Greengrass V2-agenten i EC2-forekomsterne kan vi forenkle adgangen, administrationen og udrulningen af ​​Edge Manager-agenten og -modellen til enheder. Uden AWS IoT Greengrass V2 kræver opsætning af enheder og flåder til brug af Edge Manager, at du manuelt kopierer agenten fra en S3 release bucket. Med AWS IoT Greengrass V2 og Edge Manager integration er det muligt at bruge AWS IoT Greengrass V2 komponenter. Komponenter er præbyggede softwaremoduler, der kan forbinde edge-enheder til AWS-tjenester eller tredjepartstjenester via AWS IoT Greengrass.
• Edge Manager agent – Edge Manager-agenten implementeres via AWS IoT Greengrass V2 i EC2-instansen. Agenten kan indlæse flere modeller ad gangen og drage konklusioner med indlæste modeller på kant-enheder. Antallet af modeller, agenten kan indlæse, bestemmes af den tilgængelige hukommelse på enheden.
• Amazon S3 – Vi bruger en S3-bøtte til at gemme de indhentede data fra Edge Manager-agenten.

Vi kan definere en præproduktionskonto som en digital tvilling til afprøvning af ML-modeller, før vi flytter dem til rigtige edge-enheder. Dette giver følgende fordele:

• Adræthed og fleksibilitet – Dataforskere og ML-ingeniører skal hurtigt validere, om ML-modellen og tilknyttede scripts (forbehandlings- og inferensscripts) vil fungere på enhedskanten. IoT- og datavidenskabsafdelinger i store virksomheder kan dog være forskellige enheder. Ved identisk at kopiere teknologistakken i skyen kan dataforskere og ML-ingeniører gentage og konsolidere artefakter før implementering.
• Accelereret risikovurdering og produktionstid – Udrulning på edge-enheden er den sidste fase af processen. Når du har valideret alt i et isoleret og selvstændigt miljø, skal du sikre, at det overholder de specifikationer, der kræves af kanten med hensyn til kvalitet, ydeevne og integration. Dette hjælper med at undgå yderligere involvering af andre personer i IoT-afdelingen for at reparere og gentage artefaktversioner.
• Forbedret teamsamarbejde og forbedret kvalitet og ydeevne – Udviklingsteamet kan øjeblikkeligt vurdere virkningen af ​​ML-modellen ved at analysere kanthardware-metrikker og måle niveauet af interaktioner med tredjepartsværktøjer (f.eks. I/O-hastighed). Så er IoT-teamet kun ansvarligt for udrulning til produktionsmiljøet og kan være sikker på, at artefakterne er nøjagtige for et produktionsmiljø.
• Integreret legeplads til test – I betragtning af målet for ML-modeller bør præproduktionsmiljøet i en traditionel arbejdsgang være repræsenteret af en edge-enhed uden for skymiljøet. Dette introducerer et andet niveau af kompleksitet. Integrationer er nødvendige for at indsamle metrics og feedback. I stedet for, ved at bruge det digitale tvillingesimulerede miljø, reduceres interaktioner, og tiden til markedet forkortes.

Produktionsregnskab og kantmiljø

Når testene er afsluttet, og artefaktstabiliteten er opnået, kan du fortsætte til produktionsinstallation gennem rørledningerne. Implementering af artefakt sker programmatisk, efter at en operatør har godkendt artefakten. Dog adgang til AWS Management Console gives til operatører i skrivebeskyttet tilstand for at kunne overvåge metadata knyttet til flåderne og derfor have indsigt i versionen af ​​den implementerede ML-model og andre målinger, der er knyttet til livscyklussen.

Edge-enhedsflåder tilhører AWS-produktionskontoen. Denne konto har specifikke sikkerheds- og netværkskonfigurationer for at tillade kommunikation mellem cloud- og edge-enhederne. De vigtigste AWS-tjenester, der er implementeret i produktionskontoen, er Edge Manager, som er ansvarlig for at administrere alle enhedsflåder, indsamle data og betjene ML-modeller, og AWS IoT Core, som administrerer IoT-tingobjekter, certifikater, rollealias og slutpunkter.

Samtidig skal vi konfigurere en edge-enhed med tjenester og komponenter til at administrere ML-modeller. Hovedkomponenterne er som følger:

• AWS IoT Greengrass V2
• En Edge Manager-agent
• AWS IoT-certifikater
• Application.py, som er ansvarlig for at orkestrere slutningsprocessen (hente information fra kantdatakilden og udføre slutning ved hjælp af Edge Manager-agenten og indlæst ML-model)
• En forbindelse til Amazon S3 eller data lake-kontoen for at gemme infererede data

Automatiseret ML pipeline

Nu hvor du ved mere om organisationen og komponenterne i referencearkitekturen, kan vi dykke dybere ned i den ML-pipeline, som vi bruger til at bygge, træne og evaluere ML-modellen inde i udviklingskontoen.

En rørledning (bygget ved hjælp af Amazon SageMaker Model Building Pipelines) er en række indbyrdes forbundne trin, der er defineret af en JSON-pipelinedefinition. Denne pipelinedefinition koder for en pipeline ved hjælp af en Directed Acyclic Graph (DAG). Denne DAG giver information om kravene til og forholdet mellem hvert trin i din pipeline. Strukturen af ​​en pipelines DAG bestemmes af dataafhængighederne mellem trinene. Disse dataafhængigheder oprettes, når egenskaberne for et trins output overføres som input til et andet trin.

For at gøre det muligt for datavidenskabsteams nemt at automatisere oprettelsen af ​​nye versioner af ML-modeller, er det vigtigt at introducere valideringstrin og automatiserede data til løbende feeding og forbedring af ML-modeller, samt modelovervågningsstrategier til at aktivere pipeline-udløsning. Følgende diagram viser et eksempel på en pipeline.

For at aktivere automatiseringer og MLOps-funktioner er det vigtigt at skabe modulære komponenter til at skabe genbrugelige kodeartefakter, der kan deles på tværs af forskellige trin og ML-brugssager. Dette giver dig mulighed for hurtigt at flytte implementeringen fra en eksperimenteringsfase til en produktionsfase ved at automatisere overgangen.

Trinene til at definere en ML-pipeline for at muliggøre kontinuerlig træning og versionering af ML-modeller er som følger:

• forbehandling – Processen med datarensning, funktionsudvikling og oprettelse af datasæt til træning af ML-algoritmen
• Kurser – Processen med at træne den udviklede ML-algoritme til at generere en ny version af ML-modelartefakten
• Evaluering – Processen med evaluering af den genererede ML-model til at udtrække nøglemålinger relateret til modeladfærd på nye data, der ikke er set i træningsfasen
• Registrering – Processen med versionering af den nye trænede ML-modelartefakt ved at forbinde de udtrukne metrikker med den genererede artefakt

Du kan se flere detaljer om, hvordan man bygger en SageMaker-pipeline i det følgende notesbog.

Udløs CI/CD-pipelines ved hjælp af EventBridge

Når du er færdig med at bygge modellen, kan du starte implementeringsprocessen. Det sidste trin i SageMaker-pipelinen defineret i det foregående afsnit registrerer en ny version af modellen i den specifikke SageMaker-modelregistreringsgruppe. Implementeringen af ​​en ny version af ML-modellen styres ved hjælp af modelregistrets status. Ved manuelt at godkende eller afvise en ML-modelversion, rejser dette trin en hændelse, der er fanget af EventBridge. Denne hændelse kan derefter starte en ny pipeline (CI/CD denne gang) til oprettelse af en ny version af AWS IoT Greengrass-komponenten, som derefter implementeres til præproduktions- og produktionskontiene. Følgende skærmbillede viser vores definerede EventBridge-regel.

Denne regel overvåger SageMaker-modelpakkegruppen ved at lede efter opdateringer af modelpakker i status Approved or Rejected.

EventBridge-reglen konfigureres derefter til at målrette CodePipeline, som starter arbejdsgangen med at oprette en ny AWS IoT Greengrass-komponent ved at bruge Amazon SageMaker Neo og Edge Manager.

Optimer ML-modeller til målarkitekturen

Neo giver dig mulighed for at optimere ML-modeller til at udføre inferens på edge-enheder (og i skyen). Den optimerer automatisk ML-modellerne til bedre ydeevne baseret på målarkitekturen og afkobler modellen fra den originale ramme, hvilket giver dig mulighed for at køre den på en let kørselstid.

Se følgende notesbog for et eksempel på, hvordan man kompilerer en PyTorch Resnet18-model ved hjælp af Neo.

Byg implementeringspakken ved at inkludere AWS IoT Greengrass-komponenten

Edge Manager giver dig mulighed for at administrere, sikre, implementere og overvåge modeller til en flåde af edge-enheder. I det følgende notesbog, kan du se flere detaljer om, hvordan du opbygger en minimalistisk flåde af edge-enheder og kører nogle eksperimenter med denne funktion.

Når du har konfigureret flåden og kompileret modellen, skal du køre et Edge Manager-pakkejob, som forbereder modellen til at blive implementeret i flåden. Du kan starte et pakkejob ved at bruge Boto3 SDK. Til vores parametre bruger vi den optimerede model og model metadata. Ved at tilføje følgende parametre til OutputConfig, forbereder jobbet også en AWS IoT Greengrass V2-komponent med modellen:

• PresetDeploymentType
• PresetDeploymentConfig

Se følgende kode:

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

Implementer ML-modeller på kanten i skala

Nu er det tid til at implementere modellen til din flåde af edge-enheder. For det første skal vi sikre, at vi har det nødvendige AWS identitets- og adgangsstyring (JEG ER) Tilladelser at klargøre vores IoT-enheder og være i stand til at implementere komponenter til det. Vi kræver to grundlæggende elementer for at begynde at onboarde enheder i vores IoT-platform:

• IAM politik – Denne politik giver mulighed for automatisk klargøring af sådanne enheder, knyttet til brugeren eller rollen, der udfører klargøringen. Den skal have IoT-skrivetilladelser til at oprette IoT-tingen og -gruppen, samt til at knytte de nødvendige politikker til enheden. For mere information, se Minimal IAM-politik for installatør til at klargøre ressourcer.
• IAM rolle – denne rolle er knyttet til de IoT-ting og -grupper, som vi skaber. Du kan oprette denne rolle på leveringstidspunktet med grundlæggende tilladelser, men den vil mangle funktioner som adgang til Amazon S3 eller AWS Key Management Service (AWS KMS), som måske bliver nødvendigt senere. Du kan oprette denne rolle på forhånd og genbruge den, når vi klargør enheden. For mere information, se Tillad kerneenheder til at interagere med AWS.

AWS IoT Greengrass installation og klargøring

Når vi har IAM-politikken og rollen på plads, er vi klar til installere AWS IoT Greengrass Core-software med automatisk ressourceforsyning. Selvom det er muligt at klargøre IoT-ressourcerne ved at følge manuelle trin, er der den praktiske procedure med automatisk klargøring af disse ressourcer under installationen af ​​AWS IoT Greengrass v2-kernen. Dette er den foretrukne mulighed for hurtigt at indsætte nye enheder på platformen. Udover default-jdk, skal andre pakker installeres, som f.eks curl, unzipog python3.

Når vi klargør vores enhed, skal IoT-tingnavnet være nøjagtigt det samme som edge-enheden, der er defineret i Edge Manager, ellers vil data ikke blive fanget til destinations S3-bøtten.

Installationsprogrammet kan oprette AWS IoT Greengrass-rollen og alias under installationen, hvis de ikke eksisterer. De vil dog blive oprettet med minimale tilladelser og vil kræve manuelt tilføjelse af flere politikker for at interagere med andre tjenester såsom Amazon S3. Vi anbefaler at oprette disse IAM-ressourcer på forhånd som vist tidligere og derefter genbruge dem, når du indsætter nye enheder på kontoen.

Model- og slutningskomponentemballage

Efter vores kode er blevet udviklet, kan vi implementere både koden (til slutning) og vores ML-modeller som komponenter i vores enheder.

Efter at ML-modellen er trænet i SageMaker, kan du optimere modellen med Neo ved hjælp af et Sagemaker-kompileringsjob. De resulterende kompilerede modelartefakter kan derefter pakkes ind i en GreenGrass V2-komponent ved hjælp af Edge Manager-pakkeren. Derefter kan det registreres som en brugerdefineret komponent i Mine komponenter afsnittet om AWS IoT Greengrass-konsollen. Denne komponent indeholder allerede de nødvendige livscykluskommandoer til at downloade og dekomprimere modelartefakten i vores enhed, så inferenskoden kan indlæse den for at sende billederne, der er taget gennem den.

Med hensyn til inferenskoden skal vi oprette en komponent ved hjælp af konsollen eller AWS kommandolinjegrænseflade (AWS CLI). Først pakker vi vores kildeslutningskode og nødvendige afhængigheder til Amazon S3. Når vi har uploadet koden, kan vi oprette vores komponent ved hjælp af en opskrift i .yaml eller JSON som følgende eksempel:

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

Denne eksempelopskrift viser navnet og beskrivelsen af ​​vores komponent, samt de nødvendige forudsætninger før vores run script-kommando. Opskriften pakker artefaktet ud i et arbejdsmappemiljø i enheden, og vi bruger den sti til at køre vores inferenskode. AWS CLI-kommandoen til at oprette en sådan opskrift er:

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

Du kan nu se denne komponent oprettet på AWS IoT Greengrass-konsollen.

Pas på, at komponentversionen har betydning, og den skal angives i opskriftsfilen. Gentagelse af det samme versionsnummer vil returnere en fejl.

Efter vores model og slutningskode er blevet sat op som komponenter, er vi klar til at implementere dem.

Implementer applikationen og modellen ved hjælp af AWS IoT Greengrass

I de foregående afsnit lærte du, hvordan du pakker inferenskoden og ML-modellerne. Nu kan vi oprette en implementering med flere komponenter, der inkluderer både komponenter og konfigurationer, der er nødvendige for, at vores inferenskode kan interagere med modellen i edge-enheden.

Edge Manager-agenten er den komponent, der skal installeres på hver edge-enhed for at aktivere alle Edge Manager-funktionerne. På SageMaker-konsollen har vi defineret en enhedsflåde, som har en tilhørende S3-spand. Alle edge-enheder tilknyttet flåden vil fange og rapportere deres data til denne S3-sti. Agenten kan implementeres som en komponent i AWS IoT Greengrass v2, hvilket gør det nemmere at installere og konfigurere, end hvis agenten var implementeret i selvstændig tilstand. Når vi implementerer agenten som en komponent, skal vi specificere dens konfigurationsparametre, nemlig enhedsflåden og S3-stien.

Vi opretter en implementeringskonfiguration med de tilpassede komponenter til den model og kode, vi lige har oprettet. Denne opsætning er defineret i en JSON-fil, der viser implementeringsnavnet og -målet samt komponenterne i implementeringen. Vi kan tilføje og opdatere konfigurationsparametrene for hver komponent, f.eks. i Edge Manager-agenten, hvor vi specificerer flådens navn og bucket.

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

Det er værd at bemærke, at vi ikke kun har tilføjet modellen, inferenskomponenterne og agenten, men også AWS IoT Greengrass CLI og kernen som komponenter. Førstnævnte kan hjælpe med at fejlsøge visse implementeringer lokalt på enheden. Sidstnævnte føjes til implementeringen for at konfigurere den nødvendige netværksadgang fra selve enheden, hvis det er nødvendigt (for eksempel proxyindstillinger), og også hvis du vil udføre en OTA-opgradering af AWS IoT Greengrass v2-kernen. Kernen er ikke installeret, fordi den er installeret i enheden, og kun konfigurationsopdateringen vil blive anvendt (medmindre en opgradering er på plads). For at implementere skal vi blot køre følgende kommando over den foregående konfiguration. Husk at konfigurere det mål-ARN, som implementeringen vil blive anvendt på (en IoT-ting eller IoT-gruppe). Vi kan også implementere disse komponenter fra konsollen.

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

Overvåg og administrer ML-modeller implementeret til kanten

Nu hvor din applikation kører på de nyeste enheder, er det tid til at forstå, hvordan man overvåger flåden for at forbedre styring, vedligeholdelse og synlighed. Vælg på SageMaker-konsollen Edge Manager i navigationsruden, og vælg derefter Edge-enhedsflåder. Herfra skal du vælge din flåde.

På flådens detaljeside kan du se nogle metadata for de modeller, der kører på hver enhed i din flåde. Flåderapport genereres hver 24 timer.

Data, der fanges af hver enhed gennem Edge Agent, sendes til en S3-bøtte i json-linjeformat (JSONL). Processen med at sende registrerede data styres fra et applikationssynspunkt. Du kan derfor frit bestemme, om du vil sende disse data, hvordan og hvor ofte.

Du kan bruge disse data til mange ting, såsom overvågning af datadrift og modelkvalitet, opbygning af et nyt datasæt, berigelse af en datasø og meget mere. Et simpelt eksempel på, hvordan du bruger disse data, er, når du identificerer en datadrift i den måde, brugerne interagerer med din applikation på, og du skal træne en ny model. Du bygger derefter et nyt datasæt med de opsamlede data og kopierer det tilbage til udviklingskontoen. Dette kan automatisk starte en ny kørsel af dit miljø, der bygger en ny model og omdistribuerer den til hele flåden for at bevare ydeevnen af ​​den implementerede løsning.

Konklusion

I dette indlæg lærte du, hvordan du bygger en komplet løsning, der kombinerer MLOps og ML@Edge ved hjælp af AWS-tjenester. At bygge sådan en løsning er ikke trivielt, men vi håber, at referencearkitekturen præsenteret i dette indlæg kan inspirere og hjælpe dig med at bygge en solid arkitektur til dine egne forretningsmæssige udfordringer. Du kan også kun bruge de dele eller moduler af denne arkitektur, der integreres med dit eksisterende MLOps-miljø. Ved at lave prototyper til et enkelt modul ad gangen og bruge de relevante AWS-tjenester til at løse hver del af denne udfordring, kan du lære, hvordan du bygger et robust MLOps-miljø og også yderligere forenkle den endelige arkitektur.

Som et næste trin opfordrer vi dig til at prøve Sagemaker Edge Manager til at administrere din ML på kanten livscyklus. For mere information om, hvordan Edge Manager fungerer, se Implementer modeller på kanten med SageMaker Edge Manager .

Om forfatterne

Bruno Pistone er en AI/ML Specialist Solutions Architect for AWS baseret i Milano. Han arbejder med kunder af enhver størrelse for at hjælpe dem med at forstå deres tekniske behov dybt og designe AI- og Machine Learning-løsninger, der gør den bedste brug af AWS Cloud og Amazon Machine Learning-stakken. Hans ekspertise er Machine Learning end to end, Machine Learning Industrialization og MLOps. Han nyder at tilbringe tid med sine venner og udforske nye steder, såvel som at rejse til nye destinationer.

Matteo Calabrese er en AI/ML Customer Delivery Architect i AWS Professional Services-team. Han arbejder med store virksomheder i EMEA på AI/ML-projekter og hjælper dem med at foreslå, designe, levere, skalere og optimere ML-produktionsarbejdsbelastninger. Hans hovedekspertise er ML Operation (MLOps) og Machine Learning at Edge. Hans mål er at forkorte deres tid til at værdsætte og fremskynde forretningsresultater ved at levere AWS bedste praksis. I sin fritid nyder han at vandre og rejse.

Raúl Díaz García er en Sr Data Scientist i AWS Professional Services team. Han arbejder med store virksomhedskunder på tværs af EMEA, hvor han hjælper dem med at muliggøre løsninger relateret til Computer Vision og Machine Learning i IoT-området.

Sokratis Kartakis er en Senior Machine Learning Specialist Solutions Architect for Amazon Web Services. Sokratis fokuserer på at gøre det muligt for virksomhedskunder at industrialisere deres Machine Learning-løsninger (ML) ved at udnytte AWS-tjenester og forme deres driftsmodel, dvs. MLOps-fundament, og transformations-køreplan, der udnytter bedste udviklingspraksis. Han har brugt mere end 15 år på at opfinde, designe, lede og implementere innovative end-to-end produktionsniveau ML og Internet of Things (IoT) løsninger inden for områderne energi, detailhandel, sundhed, finans/bank, motorsport osv. Sokratis kan lide at bruge sin fritid sammen med familie og venner, eller at køre på motorcykler.

Samir Araújo er AI/ML Solutions Architect hos AWS. Han hjælper kunder med at skabe AI/ML-løsninger, der løser deres forretningsmæssige udfordringer ved hjælp af AWS. Han har arbejdet på adskillige AI/ML-projekter relateret til computersyn, naturlig sprogbehandling, prognoser, ML ved kanten og mere. Han kan lide at lege med hardware og automatiseringsprojekter i sin fritid, og han har en særlig interesse for robotteknologi.