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

Internet of Things (IoT) har gjort det mulig for kunder i flere bransjer, som produksjon, bilindustri og energi, å overvåke og kontrollere virkelige miljøer. Ved å distribuere en rekke avanserte IoT-enheter som kameraer, termostater og sensorer, kan du samle inn data, sende dem til skyen og bygge maskinlæringsmodeller (ML) for å forutsi uregelmessigheter, feil og mer. Imidlertid, hvis brukssaken krever sanntidsprediksjon, må du berike IoT-løsningen din med ML at the edge-funksjoner (ML@Edge). ML@Edge er et konsept som kobler ML-modellens livssyklus fra appens livssyklus og lar deg kjøre en ende-til-ende ML-pipeline som inkluderer dataforberedelse, modellbygging, modellkompilering og -optimalisering, modellimplementering (til en flåte av edge-enheter), modellutførelse, og modellovervåking og styring. Du distribuerer appen én gang og kjører ML-rørledningen så mange ganger du trenger.

Som du kan forestille deg, er det ikke trivielt å implementere alle trinnene som foreslås av ML@Edge-konseptet. Det er mange spørsmål som utviklere må ta tak i for å implementere en komplett ML@Edge-løsning, for eksempel:

• Hvordan betjener jeg ML-modeller på en flåte (hundrevis, tusenvis eller millioner) av enheter på kanten?
• Hvordan sikrer jeg modellen min mens jeg distribuerer og kjører den på kanten?
• Hvordan overvåker jeg modellens ytelse og omskoler den om nødvendig?

I dette innlegget lærer du hvordan du svarer på alle disse spørsmålene og bygger en ende-til-ende-løsning for å automatisere ML@Edge-pipeline. Du vil se hvordan du bruker Amazon SageMaker Edge Manager, Amazon SageMaker Studioog AWS IoT Greengrass v2 å lage et MLOps-miljø (ML Operations) som automatiserer prosessen med å bygge og distribuere ML-modeller til store flåter av edge-enheter.

I de neste avsnittene presenterer vi en referansearkitektur som beskriver alle komponentene og arbeidsflytene som kreves for å bygge en komplett løsning for MLO-er fokusert på kantarbeidsbelastninger. Deretter dykker vi dypt ned i trinnene denne løsningen kjører automatisk for å bygge og klargjøre en ny modell. Vi viser deg også hvordan du forbereder edge-enhetene til å begynne å distribuere, kjøre og overvåke ML-modeller, og demonstrere hvordan du overvåker og vedlikeholder ML-modellene som er distribuert til din flåte av enheter.

Løsningsoversikt

Produksjon av robuste ML-modeller krever samarbeid mellom flere personas, for eksempel dataforskere, ML-ingeniører, dataingeniører og forretningsinteressenter, under en halvautomatisk infrastruktur etter spesifikke operasjoner (MLOps). Modulariseringen av miljøet er også viktig for å gi alle disse forskjellige personene fleksibiliteten og smidigheten til å utvikle eller forbedre (uavhengig av arbeidsflyten) komponenten de er ansvarlige for. Et eksempel på en slik infrastruktur består av flere AWS-kontoer som muliggjør dette samarbeidet og produksjonen av ML-modellene både i skyen og til kantene. I den følgende referansearkitekturen viser vi hvordan vi organiserte de mange kontoene og tjenestene som utgjør denne ende-til-ende MLOps-plattformen for å bygge ML-modeller og distribuere dem på kanten.

Denne løsningen består av følgende kontoer:

• Data Lake-konto – Dataingeniører inntar, lagrer og forbereder data fra flere datakilder, inkludert lokale databaser og IoT-enheter.
• Verktøykonto – IT-operatører administrerer og sjekker CI/CD-pipelines for automatisert kontinuerlig levering og distribusjon av ML-modellpakker på tvers av pre-produksjons- og produksjonskontoene for eksterne kantenheter. Kjøringer av CI/CD-rørledninger automatiseres ved bruk av Amazon EventBridge, som overvåker endringsstatushendelser for ML-modeller og -mål AWS CodePipeline.
• Eksperiment- og utviklingsregnskap – Dataforskere kan utføre forskning og eksperimentere med flere modelleringsteknikker og algoritmer for å løse forretningsproblemer basert på ML, og skape proof of concept-løsninger. ML-ingeniører og dataforskere samarbeider for å skalere et proof of concept, og skaper automatiserte arbeidsflyter ved hjelp av Amazon SageMaker-rørledninger å forberede data og bygge, trene og pakke ML-modeller. Utplasseringen av rørledningene drives via CI/CD-rørledninger, mens versjonskontrollen av modellene oppnås ved hjelp av Amazon SageMaker modellregister. Dataforskere evaluerer beregningene for flere modellversjoner og ber om markedsføring av den beste modellen til produksjon ved å utløse CI/CD-rørledningen.
• Forproduksjonskonto – Før markedsføringen av modellen til produksjonsmiljøet, må modellen testes for å sikre robusthet i et simuleringsmiljø. Derfor er pre-produksjonsmiljøet en simulator av produksjonsmiljøet, der SageMaker-modellens endepunkter distribueres og testes automatisk. Testmetoder kan inkludere en integrasjonstest, stresstest eller ML-spesifikke tester på slutningsresultater. I dette tilfellet er ikke produksjonsmiljøet et SageMaker-endepunkt, men en kantenhet. For å simulere en kantenhet i pre-produksjon, er to tilnærminger mulige: bruk en Amazon Elastic Compute Cloud (Amazon EC2)-forekomst med de samme maskinvarekarakteristikkene, eller bruk en testbed i laboratoriet som består av de faktiske enhetene. Med denne infrastrukturen distribuerer CI/CD-rørledningen modellen til den tilsvarende simulatoren og utfører flere tester automatisk. Etter at testene er gjennomført, krever CI/CD-rørledningen manuell godkjenning (for eksempel fra IoT-interessenten for å markedsføre modellen til produksjon).
• Produksjonskonto – Når det gjelder å være vert for modellen på AWS Cloud, distribuerer CI/CD-pipelinen et SageMaker-modellendepunkt på produksjonskontoen. I dette tilfellet består produksjonsmiljøet av flere flåter av kantenheter. Derfor bruker CI/CD-pipelinen Edge Manager til å distribuere modellene til den tilsvarende flåten av enheter.
• Edge-enheter – Remote edge-enheter er maskinvareenheter som kan kjøre ML-modeller ved hjelp av Edge Manager. Det lar applikasjonen på disse enhetene administrere modellene, kjøre slutninger mot modellene og fange data sikkert inn i Amazon enkel lagringstjeneste (Amazon S3).

SageMaker-prosjekter hjelpe deg med å automatisere prosessen med å klargjøre ressurser i hver av disse kontoene. Vi dykker ikke dypt inn i denne funksjonen, men for å lære mer om hvordan du bygger en SageMaker-prosjektmal som distribuerer ML-modeller på tvers av kontoer, sjekk ut Multikontomodell distribusjon med Amazon SageMaker Pipelines.

Forproduksjonskonto: Digital tvilling

Etter opplæringsprosessen må den resulterende modellen evalueres. I pre-produksjonskontoen har du en simulert Edge-enhet. Den representerer digital tvilling av kantenheten som ML-modellen kjører på i produksjon. Dette miljøet har det doble formålet å utføre de klassiske testene (som enhet, integrasjon og røyk) og å være en lekeplass for utviklingsteamet. Denne enheten er simulert ved hjelp av en EC2-instans der alle komponentene som trengs for å administrere ML-modellen ble distribuert.

De involverte tjenestene er som følger:

• AWS IoT-kjerne - Vi bruker AWS IoT-kjerne for å lage AWS IoT-tingobjekter, opprette en enhetsflåte, registrere enhetsflåten slik at den kan samhandle med skyen, lage X.509-sertifikater for å autentisere edge-enheter til AWS IoT Core, knytte rollealiaset til AWS IoT Core som ble generert da flåten har opprettet, få et AWS-kontospesifikt endepunkt for legitimasjonsleverandøren, få en offisiell Amazon Root CA-fil, og last opp Amazon CA-filen til Amazon S3.
• Amazon Sagemaker Neo – Sagemaker Neo optimerer automatisk maskinlæringsmodeller slik at de kan løpe raskere uten tap av nøyaktighet. Den støtter maskinlæringsmodeller som allerede er bygget med DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX eller XGBoost og trent i Amazon SageMaker eller andre steder. Deretter velger du din målmaskinvareplattform, som kan være en SageMaker-vertsinstans eller en edge-enhet basert på prosessorer fra Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments eller Xilinx.
• Edge Manager – Vi bruker Edge Manager til å registrere og administrere edge-enheten i Sagemaker-flåtene. Flåter er samlinger av logisk grupperte enheter du kan bruke til å samle inn og analysere data. Dessuten pakker Edge Manager-pakker den optimaliserte modellen og lager en AWS IoT Greengrass V2-komponent som kan distribueres direkte. Du kan bruke Edge Manager til å betjene ML-modeller på en flåte av smartkameraer, smarthøyttalere, roboter og andre SageMaker-enhetsflåter.
• AWS IoT Greengrass V2 - AWS IoT Greengrass lar deg distribuere komponenter i de simulerte enhetene ved hjelp av en EC2-forekomst. Ved å bruke AWS IoT Greengrass V2-agenten i EC2-forekomstene, kan vi forenkle tilgangen, administrasjonen og distribusjonen av Edge Manager-agenten og modellen til enheter. Uten AWS IoT Greengrass V2 krever å sette opp enheter og flåter for å bruke Edge Manager at du manuelt kopierer agenten fra en S3-utgivelsesbøtte. Med AWS IoT Greengrass V2 og Edge Manager-integrasjon er det mulig å bruke AWS IoT Greengrass V2-komponenter. Komponenter er forhåndsbygde programvaremoduler som kan koble edge-enheter til AWS-tjenester eller tredjepartstjenester via AWS IoT Greengrass.
• Edge Manager-agent – Edge Manager-agenten distribueres via AWS IoT Greengrass V2 i EC2-forekomsten. Agenten kan laste inn flere modeller om gangen og trekke slutninger med lastede modeller på kantenheter. Antall modeller agenten kan laste, bestemmes av tilgjengelig minne på enheten.
• Amazon S3 – Vi bruker en S3-bøtte for å lagre slutningsdataene fra Edge Manager-agenten.

Vi kan definere en pre-produksjonskonto som en digital tvilling for å teste ML-modeller før vi flytter dem til virkelige edge-enheter. Dette gir følgende fordeler:

• Smidighet og fleksibilitet – Dataforskere og ML-ingeniører må raskt validere om ML-modellen og tilhørende skript (forbehandlings- og slutningsskript) vil fungere på enhetskanten. Imidlertid kan IoT- og datavitenskapsavdelinger i store bedrifter være forskjellige enheter. Ved å identisk replikere teknologistabelen i skyen, kan dataforskere og ML-ingeniører iterere og konsolidere artefakter før distribusjon.
• Akselerert risikovurdering og produksjonstid – Utplassering på kantenheten er den siste fasen av prosessen. Etter at du har validert alt i et isolert og selvstendig miljø, sørg for at det overholder spesifikasjonene som kreves av edge når det gjelder kvalitet, ytelse og integrasjon. Dette bidrar til å unngå ytterligere involvering av andre personer i IoT-avdelingen for å fikse og iterere på artefaktversjoner.
• Forbedret teamsamarbeid og forbedret kvalitet og ytelse – Utviklingsteamet kan umiddelbart vurdere virkningen av ML-modellen ved å analysere grenseverdier for maskinvare og måle nivået av interaksjoner med tredjepartsverktøy (f.eks. I/O-hastighet). Da er IoT-teamet kun ansvarlig for distribusjon til produksjonsmiljøet, og kan være trygg på at artefaktene er nøyaktige for et produksjonsmiljø.
• Integrert lekeplass for testing – Gitt målet for ML-modeller, bør pre-produksjonsmiljøet i en tradisjonell arbeidsflyt representeres av en edge-enhet utenfor skymiljøet. Dette introduserer et annet nivå av kompleksitet. Integrasjoner er nødvendig for å samle inn beregninger og tilbakemeldinger. I stedet, ved å bruke det digitale tvillingsimulerte miljøet, reduseres interaksjoner og tiden til markedet forkortes.

Produksjonskonto og kantmiljø

Etter at testene er fullført og artefaktstabiliteten er oppnådd, kan du fortsette til produksjonsdistribusjon gjennom rørledningene. Artefaktdistribusjon skjer programmatisk etter at en operatør har godkjent artefakten. Imidlertid tilgang til AWS-administrasjonskonsoll er gitt til operatører i skrivebeskyttet modus for å kunne overvåke metadata knyttet til flåtene og derfor ha innsikt i versjonen av den utplasserte ML-modellen og andre målinger knyttet til livssyklusen.

Edge-enhetsflåter tilhører AWS-produksjonskontoen. Denne kontoen har spesifikke sikkerhets- og nettverkskonfigurasjoner for å tillate kommunikasjon mellom sky- og edge-enheter. De viktigste AWS-tjenestene som er distribuert i produksjonskontoen er Edge Manager, som er ansvarlig for å administrere alle enhetsflåtene, samle inn data og drifte ML-modeller, og AWS IoT Core, som administrerer IoT-tingobjekter, sertifikater, rollealias og endepunkter.

Samtidig må vi konfigurere en edge-enhet med tjenestene og komponentene for å administrere ML-modeller. Hovedkomponentene er som følger:

• AWS IoT Greengrass V2
• En Edge Manager-agent
• AWS IoT-sertifikater
• Application.py, som er ansvarlig for å orkestrere inferensprosessen (hente informasjon fra kantdatakilden og utføre inferens ved hjelp av Edge Manager-agenten og innlastet ML-modell)
• En tilkobling til Amazon S3 eller data lake-kontoen for å lagre infererte data

Automatisert ML-rørledning

Nå som du vet mer om organisasjonen og komponentene i referansearkitekturen, kan vi dykke dypere inn i ML-pipelinen som vi bruker til å bygge, trene og evaluere ML-modellen inne i utviklingskontoen.

En rørledning (bygget ved hjelp av Amazon SageMaker Model Building Pipelines) er en serie sammenkoblede trinn som er definert av en JSON-rørledningsdefinisjon. Denne rørledningsdefinisjonen koder for en rørledning ved hjelp av en rettet asyklisk graf (DAG). Denne DAG gir informasjon om kravene til og forholdet mellom hvert trinn i rørledningen din. Strukturen til en rørlednings DAG bestemmes av dataavhengighetene mellom trinnene. Disse dataavhengighetene opprettes når egenskapene til et trinns utdata overføres som input til et annet trinn.

For å gjøre datavitenskapsteam i stand til enkelt å automatisere opprettelsen av nye versjoner av ML-modeller, er det viktig å introdusere valideringstrinn og automatiserte data for kontinuerlig mating og forbedring av ML-modeller, samt modellovervåkingsstrategier for å aktivere pipeline-utløsning. Følgende diagram viser et eksempel på en rørledning.

For å aktivere automatisering og MLOps-funksjoner, er det viktig å lage modulære komponenter for å lage gjenbrukbare kodeartefakter som kan deles på tvers av forskjellige trinn og ML-brukstilfeller. Dette gjør at du raskt kan flytte implementeringen fra en eksperimenteringsfase til en produksjonsfase ved å automatisere overgangen.

Trinnene for å definere en ML-pipeline for å muliggjøre kontinuerlig opplæring og versjonering av ML-modeller er som følger:

• forbehandling – Prosessen med datarensing, funksjonsutvikling og datasettoppretting for opplæring av ML-algoritmen
• Kurs – Prosessen med å trene den utviklede ML-algoritmen for å generere en ny versjon av ML-modellartefakten
• Evaluering – Prosessen med evaluering av den genererte ML-modellen, for å trekke ut nøkkelberegninger relatert til modellens oppførsel på nye data som ikke er sett under opplæringsfasen
• Registrering – Prosessen med å versjonere den nye trente ML-modellartefakten ved å koble ut beregningene med den genererte artefakten

Du kan se flere detaljer om hvordan du bygger en SageMaker-rørledning i det følgende bærbare.

Utløs CI/CD-pipelines ved hjelp av EventBridge

Når du er ferdig med å bygge modellen, kan du starte distribusjonsprosessen. Det siste trinnet i SageMaker-rørledningen definert i forrige avsnitt registrerer en ny versjon av modellen i den spesifikke SageMaker-modellregistergruppen. Utrullingen av en ny versjon av ML-modellen administreres ved hjelp av modellregisterstatusen. Ved å manuelt godkjenne eller avvise en ML-modellversjon, reiser dette trinnet en hendelse som fanges opp av EventBridge. Denne hendelsen kan deretter starte en ny pipeline (CI/CD denne gangen) for å lage en ny versjon av AWS IoT Greengrass-komponenten som deretter distribueres til pre-produksjons- og produksjonskontoene. Følgende skjermbilde viser vår definerte EventBridge-regel.

Denne regelen overvåker SageMaker-modellpakkegruppen ved å se etter oppdateringer av modellpakker i statusen Approved or Rejected.

EventBridge-regelen konfigureres deretter til å målrette CodePipeline, som starter arbeidsflyten for å lage en ny AWS IoT Greengrass-komponent ved å bruke Amazon SageMaker Neo og Edge Manager.

Optimaliser ML-modeller for målarkitekturen

Neo lar deg optimalisere ML-modeller for å utføre inferens på kantenheter (og i skyen). Den optimerer automatisk ML-modellene for bedre ytelse basert på målarkitekturen, og kobler modellen fra det originale rammeverket, slik at du kan kjøre den på en lett kjøretid.

Se følgende bærbare for et eksempel på hvordan man kompilerer en PyTorch Resnet18-modell ved hjelp av Neo.

Bygg distribusjonspakken ved å inkludere AWS IoT Greengrass-komponenten

Edge Manager lar deg administrere, sikre, distribuere og overvåke modeller til en flåte av edge-enheter. I følgende bærbare, kan du se flere detaljer om hvordan du bygger en minimalistisk flåte av edge-enheter og kjører noen eksperimenter med denne funksjonen.

Etter at du har konfigurert flåten og kompilert modellen, må du kjøre en Edge Manager-pakkejobb, som forbereder modellen til å distribueres til flåten. Du kan starte en pakkejobb ved å bruke Boto3 SDK. For våre parametere bruker vi den optimaliserte modellen og modellens metadata. Ved å legge til følgende parametere til OutputConfig, forbereder jobben 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}
        ),
    }
)

Distribuer ML-modeller på kanten i skala

Nå er det på tide å distribuere modellen til flåten av edge-enheter. Først må vi sørge for at vi har det nødvendige AWS identitets- og tilgangsadministrasjon (JEG ER) tillatelser for å klargjøre våre IoT-enheter og være i stand til å distribuere komponenter til den. Vi krever to grunnleggende elementer for å starte onboarding av enheter i vår IoT-plattform:

• IAM-policy – Denne policyen tillater automatisk klargjøring av slike enheter, knyttet til brukeren eller rollen som utfører klargjøringen. Den bør ha IoT-skrivetillatelser for å lage IoT-tingen og -gruppen, samt å legge ved nødvendige retningslinjer til enheten. For mer informasjon, se Minimal IAM-policy for installatør for å klargjøre ressurser.
• IAM-rolle – denne rollen er knyttet til IoT-tingene og -gruppene vi lager. Du kan opprette denne rollen på klargjøringstidspunktet med grunnleggende tillatelser, men den vil mangle funksjoner som tilgang til Amazon S3 eller AWS nøkkelstyringstjeneste (AWS KMS) som kan være nødvendig senere. Du kan opprette denne rollen på forhånd og bruke den på nytt når vi klargjør enheten. For mer informasjon, se Autoriser kjerneenheter til å samhandle med AWS.

AWS IoT Greengrass installasjon og klargjøring

Etter at vi har IAM-policyen og rollen på plass, er vi klare til å installer AWS IoT Greengrass Core-programvare med automatisk ressursforsyning. Selv om det er mulig å klargjøre IoT-ressursene ved å følge manuelle trinn, er det den praktiske prosedyren med å automatisk klargjøre disse ressursene under installasjonen av AWS IoT Greengrass v2-kjernen. Dette er det foretrukne alternativet for raskt å sette inn nye enheter på plattformen. I tillegg default-jdk, andre pakker kreves installert, for eksempel curl, unzipog python3.

Når vi klargjør enheten vår, må IoT-tingnavnet være nøyaktig det samme som edge-enheten som er definert i Edge Manager, ellers vil ikke data fanges opp til S3-destinasjonsbøtten.

Installasjonsprogrammet kan opprette AWS IoT Greengrass-rollen og aliaset under installasjonen hvis de ikke eksisterer. Imidlertid vil de bli opprettet med minimale tillatelser og vil kreve manuelt legge til flere retningslinjer for å samhandle med andre tjenester som Amazon S3. Vi anbefaler å opprette disse IAM-ressursene på forhånd som vist tidligere, og deretter bruke dem på nytt når du setter nye enheter inn på kontoen.

Modell- og slutningskomponentemballasje

Etter at koden vår er utviklet, kan vi distribuere både koden (for slutning) og ML-modellene våre som komponenter i enhetene våre.

Etter at ML-modellen er opplært i SageMaker, kan du optimalisere modellen med Neo ved å bruke en Sagemaker-kompileringsjobb. De resulterende kompilerte modellartefaktene kan deretter pakkes inn i en GreenGrass V2-komponent ved å bruke Edge Manager-pakkeren. Deretter kan den registreres som en tilpasset komponent i Mine komponenter delen på AWS IoT Greengrass-konsollen. Denne komponenten inneholder allerede de nødvendige livssykluskommandoene for å laste ned og dekomprimere modellartefakten i enheten vår, slik at slutningskoden kan laste den opp for å sende bildene som er tatt gjennom den.

Når det gjelder slutningskoden, må vi lage en komponent ved å bruke konsollen eller AWS kommandolinjegrensesnitt (AWS CLI). Først pakker vi vår kildeslutningskode og nødvendige avhengigheter til Amazon S3. Etter at vi har lastet opp koden, kan vi lage komponenten vår ved å bruke en oppskrift 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 eksempeloppskriften viser navnet og beskrivelsen av komponenten vår, så vel som de nødvendige forutsetningene før vår run script-kommando. Oppskriften pakker ut artefakten i et arbeidsmappemiljø på enheten, og vi bruker den banen til å kjøre slutningskoden vår. AWS CLI-kommandoen for å lage en slik oppskrift er:

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

Du kan nå se denne komponenten opprettet på AWS IoT Greengrass-konsollen.

Vær oppmerksom på at komponentversjonen har betydning, og den må spesifiseres i oppskriftsfilen. Å gjenta samme versjonsnummer vil returnere en feil.

Etter at modellen og slutningskoden vår er satt opp som komponenter, er vi klare til å distribuere dem.

Distribuer applikasjonen og modellen ved å bruke AWS IoT Greengrass

I de forrige avsnittene lærte du hvordan du pakker slutningskoden og ML-modellene. Nå kan vi lage en distribusjon med flere komponenter som inkluderer både komponenter og konfigurasjoner som trengs for at slutningskoden vår skal samhandle med modellen i edge-enheten.

Edge Manager-agenten er komponenten som skal installeres på hver edge-enhet for å aktivere alle Edge Manager-funksjonene. På SageMaker-konsollen har vi definert en enhetsflåte, som har en tilhørende S3-bøtte. Alle kantenheter knyttet til flåten vil fange opp og rapportere dataene deres til denne S3-banen. Agenten kan distribueres som en komponent i AWS IoT Greengrass v2, noe som gjør det enklere å installere og konfigurere enn om agenten var distribuert i frittstående modus. Når vi distribuerer agenten som en komponent, må vi spesifisere konfigurasjonsparametrene, nemlig enhetsparken og S3-banen.

Vi oppretter en distribusjonskonfigurasjon med de tilpassede komponentene for modellen og koden vi nettopp opprettet. Dette oppsettet er definert i en JSON-fil som viser distribusjonsnavnet og målet, samt komponentene i distribusjonen. Vi kan legge til og oppdatere konfigurasjonsparametrene for hver komponent, for eksempel i Edge Manager-agenten, der vi spesifiserer flåtenavnet og bøtte.

{
    "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 verdt å merke seg at vi har lagt til ikke bare modellen, slutningskomponentene og agenten, men også AWS IoT Greengrass CLI og kjernen som komponenter. Førstnevnte kan hjelpe med å feilsøke visse distribusjoner lokalt på enheten. Sistnevnte legges til i distribusjonen for å konfigurere nødvendig nettverkstilgang fra selve enheten om nødvendig (for eksempel proxy-innstillinger), og også i tilfelle du ønsker å utføre en OTA-oppgradering av AWS IoT Greengrass v2-kjernen. Kjernen blir ikke distribuert fordi den er installert i enheten, og bare konfigurasjonsoppdateringen vil bli brukt (med mindre en oppgradering er på plass). For å distribuere, trenger vi bare å kjøre følgende kommando over den foregående konfigurasjonen. Husk å sette opp mål-ARN som distribusjonen skal brukes på (en IoT-ting eller IoT-gruppe). Vi kan også distribuere disse komponentene fra konsollen.

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

Overvåk og administrer ML-modeller distribuert til kanten

Nå som applikasjonen din kjører på avanserte enheter, er det på tide å forstå hvordan du kan overvåke flåten for å forbedre styring, vedlikehold og synlighet. Velg på SageMaker-konsollen Edge Manager i navigasjonsruten, og velg deretter Edge enhetsflåter. Herfra velger du flåten din.

På flåtens detaljside kan du se noen metadata for modellene som kjører på hver enhet i flåten din. Flåterapport genereres hver 24. time.

Data som fanges opp av hver enhet gjennom Edge Agent sendes til en S3-bøtte i json-linjeformat (JSONL). Prosessen med å sende innfangede data styres fra et applikasjonsstandpunkt. Du står derfor fritt til å bestemme om du vil sende disse dataene, hvordan og hvor ofte.

Du kan bruke disse dataene til mange ting, for eksempel å overvåke datadrift og modellkvalitet, bygge et nytt datasett, berike en datainnsjø og mer. Et enkelt eksempel på hvordan du kan bruke disse dataene er når du identifiserer datadrift i måten brukerne samhandler med applikasjonen din på, og du må trene en ny modell. Du bygger deretter et nytt datasett med de fangede dataene og kopierer det tilbake til utviklingskontoen. Dette kan automatisk starte en ny kjøring av miljøet ditt som bygger en ny modell og omdistribuerer den til hele flåten for å beholde ytelsen til den distribuerte løsningen.

konklusjonen

I dette innlegget lærte du hvordan du bygger en komplett løsning som kombinerer MLOps og ML@Edge ved å bruke AWS-tjenester. Å bygge en slik løsning er ikke trivielt, men vi håper referansearkitekturen presentert i dette innlegget kan inspirere og hjelpe deg med å bygge en solid arkitektur for dine egne forretningsutfordringer. Du kan også bruke bare delene eller modulene til denne arkitekturen som integreres med ditt eksisterende MLOps-miljø. Ved å lage en enkelt modul om gangen og bruke de riktige AWS-tjenestene for å møte hver del av denne utfordringen, kan du lære hvordan du bygger et robust MLOps-miljø og også forenkle den endelige arkitekturen ytterligere.

Som et neste trinn oppfordrer vi deg til å prøve ut Sagemaker Edge Manager for å administrere ML på kantens livssyklus. For mer informasjon om hvordan Edge Manager fungerer, se Distribuer modeller på kanten med SageMaker Edge Manager .

Om forfatterne

Bruno Pistone er en AI/ML Specialist Solutions Architect for AWS basert i Milano. Han jobber med kunder av alle størrelser for å hjelpe dem til å forstå deres tekniske behov dypt og utforme AI- og maskinlæringsløsninger som utnytter AWS Cloud og Amazon Machine Learning-stabel på best mulig måte. Hans ekspertisefelt er Machine Learning ende til ende, Machine Learning Industrialization og MLOps. Han liker å tilbringe tid med vennene sine og utforske nye steder, i tillegg til å reise til nye destinasjoner.

Matteo Calabrese er en AI/ML Customer Delivery Architect i AWS Professional Services-team. Han jobber med store bedrifter i EMEA på AI/ML-prosjekter, og hjelper dem med å foreslå, designe, levere, skalere og optimalisere ML-produksjonsarbeidsmengder. Hans hovedekspertise er ML Operation (MLOps) og Machine Learning at Edge. Målet hans er å forkorte tiden deres til å verdsette og akselerere forretningsresultater ved å tilby AWS beste praksis. På fritiden liker han å gå tur og reise.

Raúl Díaz García er en Sr Data Scientist i AWS Professional Services-teamet. Han jobber med store bedriftskunder på tvers av EMEA, hvor han hjelper dem med å muliggjøre løsninger relatert til Computer Vision og Machine Learning i IoT-området.

Sokratis Kartakis er en senior løsningsarkitekt for maskinlæring for Amazon Web Services. Sokratis fokuserer på å gjøre bedriftskunder i stand til å industrialisere sine Machine Learning-løsninger (ML) ved å utnytte AWS-tjenester og forme deres driftsmodell, dvs. MLOps-grunnlag, og transformasjonsveikart ved å utnytte beste utviklingspraksis. Han har brukt 15+ år på å finne opp, designe, lede og implementere innovative ende-til-ende produksjonsnivå ML og Internet of Things (IoT) løsninger innen energi, detaljhandel, helse, finans/bank, motorsport etc. Sokratis liker å tilbringe fritiden med familie og venner, eller å kjøre motorsykkel.

Samir Araújo er AI/ML Solutions Architect hos AWS. Han hjelper kunder med å lage AI/ML-løsninger som løser deres forretningsutfordringer ved hjelp av AWS. Han har jobbet med flere AI/ML-prosjekter relatert til datasyn, naturlig språkbehandling, prognoser, ML på kanten og mer. Han liker å leke med maskinvare og automatiseringsprosjekter på fritiden, og han har en spesiell interesse for robotikk.