MLOps i kanten med Amazon SageMaker Edge Manager och AWS IoT Greengrass

Internet of Things (IoT) har gjort det möjligt för kunder inom flera branscher, såsom tillverkning, fordonsindustri och energi, att övervaka och kontrollera verkliga miljöer. Genom att distribuera en mängd olika avancerade IoT-enheter som kameror, termostater och sensorer kan du samla in data, skicka den till molnet och bygga modeller för maskininlärning (ML) för att förutsäga anomalier, misslyckanden och mer. Men om användningsfallet kräver förutsägelse i realtid, måste du berika din IoT-lösning med ML at the edge-funktioner (ML@Edge). ML@Edge är ett koncept som frikopplar ML-modellens livscykel från appens livscykel och låter dig köra en end-to-end ML-pipeline som inkluderar dataförberedelse, modellbyggnad, modellkompilering och optimering, modellimplementering (till en flotta av edge-enheter), modellutförande och modellövervakning och styrning. Du distribuerar appen en gång och kör ML-pipeline så många gånger du behöver.

Som du kan föreställa dig är det inte trivialt att implementera alla steg som föreslagits av ML@Edge-konceptet. Det finns många frågor som utvecklare måste ta itu med för att implementera en komplett ML@Edge-lösning, till exempel:

• Hur använder jag ML-modeller på en flotta (hundratals, tusentals eller miljoner) enheter vid kanten?
• Hur säkrar jag min modell när jag distribuerar och kör den vid kanten?
• Hur övervakar jag min modells prestanda och tränar om den om det behövs?

I det här inlägget lär du dig hur du svarar på alla dessa frågor och bygger en helhetslösning för att automatisera din ML@Edge-pipeline. Du kommer att se hur du använder Amazon SageMaker Edge Manager, Amazon SageMaker Studiooch AWS IoT Greengrass v2 att skapa en MLOps-miljö (ML Operations) som automatiserar processen att bygga och distribuera ML-modeller till stora flottor av edge-enheter.

I nästa avsnitt presenterar vi en referensarkitektur som beskriver alla komponenter och arbetsflöden som krävs för att bygga en komplett lösning för MLO:er fokuserade på edge-arbetsbelastningar. Sedan dyker vi djupt ner i stegen som denna lösning körs automatiskt för att bygga och förbereda en ny modell. Vi visar dig också hur du förbereder edge-enheterna för att börja distribuera, köra och övervaka ML-modeller, och visar hur du övervakar och underhåller ML-modellerna som distribueras till din flotta av enheter.

Lösningsöversikt

Produktion av robusta ML-modeller kräver samarbete mellan flera personer, såsom datavetare, ML-ingenjörer, dataingenjörer och affärsintressenter, under en halvautomatisk infrastruktur efter specifika operationer (MLOps). Modulariseringen av miljön är också viktig för att ge alla dessa olika personer flexibiliteten och smidigheten att utveckla eller förbättra (oberoende av arbetsflödet) den komponent som de är ansvariga för. Ett exempel på en sådan infrastruktur består av flera AWS-konton som möjliggör detta samarbete och produktion av ML-modellerna både i molnet och till kantenheterna. I följande referensarkitektur visar vi hur vi organiserade de flera konton och tjänsterna som utgör denna kompletta MLOps-plattform för att bygga ML-modeller och distribuera dem vid kanten.

Denna lösning består av följande konton:

• Data lake konto – Dataingenjörer matar in, lagrar och förbereder data från flera datakällor, inklusive lokala databaser och IoT-enheter.
• Verktygskonto – IT-operatörer hanterar och kontrollerar CI/CD-pipelines för automatiserad kontinuerlig leverans och distribution av ML-modellpaket över förproduktions- och produktionskonton för externa kantenheter. Körningar av CI/CD-pipelines automatiseras genom användning av Amazon EventBridge, som övervakar förändringsstatushändelser för ML-modeller och mål AWS CodePipeline.
• Experiment- och utvecklingskonto – Dataforskare kan bedriva forskning och experimentera med flera modelleringstekniker och algoritmer för att lösa affärsproblem baserade på ML och skapa proof of concept-lösningar. ML-ingenjörer och datavetare samarbetar för att skala ett proof of concept, skapa automatiserade arbetsflöden med Amazon SageMaker-rörledningar att förbereda data och bygga, träna och paketera ML-modeller. Utplaceringen av pipelines drivs via CI/CD-pipelines, medan versionskontrollen av modellerna uppnås med hjälp av Amazon SageMaker modellregister. Dataforskare utvärderar mätvärdena för flera modellversioner och begär marknadsföring av den bästa modellen till produktion genom att trigga CI/CD-pipeline.
• Förproduktionskonto – Innan modellen marknadsförs till produktionsmiljön måste modellen testas för att säkerställa robusthet i en simuleringsmiljö. Därför är förproduktionsmiljön en simulator av produktionsmiljön, där SageMaker-modellens slutpunkter distribueras och testas automatiskt. Testmetoder kan innefatta ett integrationstest, stresstest eller ML-specifika test på slutledningsresultat. I det här fallet är produktionsmiljön inte en SageMaker-modellslutpunkt utan en kantenhet. För att simulera en kantenhet i förproduktion är två tillvägagångssätt möjliga: använd en Amazon Elastic Compute Cloud (Amazon EC2)-instans med samma hårdvaruegenskaper, eller använd en in-lab testbädd som består av de faktiska enheterna. Med den här infrastrukturen distribuerar CI/CD-pipeline modellen till motsvarande simulator och utför de multipla testerna automatiskt. Efter att testerna genomförts framgångsrikt kräver CI/CD-pipelinen manuellt godkännande (till exempel från IoT-intressenten för att marknadsföra modellen till produktion).
• Produktionskonto – I fallet med värd för modellen på AWS-molnet, distribuerar CI/CD-pipelinen en SageMaker-modellslutpunkt på produktionskontot. I det här fallet består produktionsmiljön av flera flottor av kantenheter. Därför använder CI/CD-pipeline Edge Manager för att distribuera modellerna till motsvarande enhetsflotta.
• Edge-enheter – Remote edge-enheter är hårdvaruenheter som kan köra ML-modeller med Edge Manager. Det tillåter applikationen på dessa enheter att hantera modellerna, köra slutsatser mot modellerna och fånga data säkert i Amazon enkel lagringstjänst (Amazon S3).

SageMaker-projekt hjälpa dig att automatisera processen att tillhandahålla resurser i vart och ett av dessa konton. Vi fördjupar oss inte i den här funktionen, men för att lära dig mer om hur man bygger en SageMaker-projektmall som distribuerar ML-modeller över konton, kolla in Flerkontomodelldistribution med Amazon SageMaker Pipelines.

Förproduktionskonto: Digital tvilling

Efter utbildningsprocessen måste den resulterande modellen utvärderas. I förproduktionskontot har du en simulerad Edge-enhet. Den representerar digital tvilling av kantanordningen som ML-modellen körs på i produktion. Denna miljö har det dubbla syftet att utföra de klassiska testerna (såsom enhet, integration och rök) och att vara en lekplats för utvecklingsteamet. Den här enheten simuleras med en EC2-instans där alla komponenter som behövs för att hantera ML-modellen distribuerades.

De inblandade tjänsterna är följande:

• AWS IoT Core - Vi använder AWS IoT Core för att skapa AWS IoT-objekt, skapa en enhetsflotta, registrera enhetsflottan så att den kan interagera med molnet, skapa X.509-certifikat för att autentisera edge-enheter till AWS IoT Core, associera rollaliaset med AWS IoT Core som genererades när flottan har skapat, skaffa en AWS-kontospecifik slutpunkt för behörighetsleverantören, skaffa en officiell Amazon Root CA-fil och ladda upp Amazon CA-filen till Amazon S3.
• Amazon Sagemaker Neo – Sagemaker Neo optimerar automatiskt maskininlärningsmodeller för slutsatser att köra snabbare utan förlust i noggrannhet. Den stöder maskininlärningsmodeller som redan är byggda med DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX eller XGBoost och utbildad i Amazon SageMaker eller någon annanstans. Sedan väljer du din målhårdvaruplattform, som kan vara en SageMaker-värdinstans eller en edge-enhet baserad på processorer från Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments eller Xilinx.
• Edge Manager – Vi använder Edge Manager för att registrera och hantera edge-enheten inom Sagemakers flottor. Flottor är samlingar av logiskt grupperade enheter som du kan använda för att samla in och analysera data. Dessutom paketerar Edge Manager-paketeraren den optimerade modellen och skapar en AWS IoT Greengrass V2-komponent som kan distribueras direkt. Du kan använda Edge Manager för att styra ML-modeller på en flotta av smarta kameror, smarta högtalare, robotar och andra SageMaker-enhetsflottor.
• AWS IoT Greengrass V2 - AWS IoT Greengrass låter dig distribuera komponenter i de simulerade enheterna med hjälp av en EC2-instans. Genom att använda AWS IoT Greengrass V2-agenten i EC2-instanserna kan vi förenkla åtkomst, hantering och distribution av Edge Manager-agenten och modellen till enheter. Utan AWS IoT Greengrass V2 kräver att du konfigurerar enheter och flottor för att använda Edge Manager att du manuellt kopierar agenten från en S3 release-bucket. Med AWS IoT Greengrass V2 och Edge Manager-integration är det möjligt att använda AWS IoT Greengrass V2-komponenter. Komponenter är förbyggda mjukvarumoduler som kan ansluta edge-enheter till AWS-tjänster eller tredjepartstjänster via AWS IoT Greengrass.
• Edge Manager-agent – Edge Manager-agenten distribueras via AWS IoT Greengrass V2 i EC2-instansen. Agenten kan ladda flera modeller åt gången och dra slutsatser med laddade modeller på kantenheter. Antalet modeller som agenten kan ladda bestäms av det tillgängliga minnet på enheten.
• Amazon S3 – Vi använder en S3-hink för att lagra inferensfångad data från Edge Manager-agenten.

Vi kan definiera ett förproduktionskonto som en digital tvilling för att testa ML-modeller innan vi flyttar dem till riktiga edge-enheter. Detta ger följande fördelar:

• Smidighet och flexibilitet – Dataforskare och ML-ingenjörer måste snabbt validera om ML-modellen och tillhörande skript (förbearbetnings- och slutledningsskript) kommer att fungera på enhetskanten. IoT- och datavetenskapsavdelningar i stora företag kan dock vara olika enheter. Genom att identiskt replikera teknikstacken i molnet kan datavetare och ML-ingenjörer iterera och konsolidera artefakter innan de distribueras.
• Accelererad riskbedömning och produktionstid – Utplacering på kantenheten är det sista steget i processen. När du har validerat allt i en isolerad och fristående miljö, säkerställ att det följer de specifikationer som krävs av kanten när det gäller kvalitet, prestanda och integration. Detta hjälper till att undvika ytterligare inblandning av andra personer på IoT-avdelningen för att fixa och iterera på artefaktversioner.
• Förbättrat teamsamarbete och förbättrad kvalitet och prestanda – Utvecklingsteamet kan omedelbart bedöma effekten av ML-modellen genom att analysera edge-hårdvarumått och mäta nivån på interaktioner med tredjepartsverktyg (t.ex. I/O-hastighet). Sedan är IoT-teamet endast ansvarigt för distributionen till produktionsmiljön och kan vara säker på att artefakterna är korrekta för en produktionsmiljö.
• Integrerad lekplats för testning – Med tanke på målet för ML-modeller bör förproduktionsmiljön i ett traditionellt arbetsflöde representeras av en edge-enhet utanför molnmiljön. Detta introducerar en annan nivå av komplexitet. Integrationer behövs för att samla in mätvärden och feedback. Istället, genom att använda den digitala tvillingsimulerade miljön, reduceras interaktioner och tiden till marknaden förkortas.

Produktionskonto och kantmiljö

Efter att testerna är klara och artefaktstabiliteten har uppnåtts kan du fortsätta till produktionsinstallation genom pipelines. Artefaktdistribution sker programmatiskt efter att en operatör har godkänt artefakten. Men tillgång till AWS Management Console ges till operatörer i skrivskyddat läge för att kunna övervaka metadata som är associerade med flottorna och därför ha insyn i versionen av den utplacerade ML-modellen och andra mätvärden som är kopplade till livscykeln.

Edge-enhetsflottor tillhör AWS produktionskonto. Det här kontot har specifika säkerhets- och nätverkskonfigurationer för att möjliggöra kommunikation mellan molnet och edge-enheterna. De huvudsakliga AWS-tjänsterna som distribueras i produktionskontot är Edge Manager, som ansvarar för att hantera alla enhetsflottor, samla in data och driva ML-modeller, och AWS IoT Core, som hanterar IoT-objekt, certifikat, rollalias och slutpunkter.

Samtidigt måste vi konfigurera en edge-enhet med tjänster och komponenter för att hantera ML-modeller. Huvudkomponenterna är följande:

• AWS IoT Greengrass V2
• En Edge Manager-agent
• AWS IoT-certifikat
• Application.py, som ansvarar för att orkestrera slutledningsprocessen (hämta information från kantdatakällan och utföra slutledning med hjälp av Edge Manager-agenten och laddad ML-modell)
• En anslutning till Amazon S3 eller datasjökontot för att lagra inferensdata

Automatiserad ML pipeline

Nu när du vet mer om organisationen och komponenterna i referensarkitekturen kan vi dyka djupare in i ML-pipeline som vi använder för att bygga, träna och utvärdera ML-modellen inuti utvecklingskontot.

En pipeline (byggd med Amazon SageMaker Model Building Pipelines) är en serie sammankopplade steg som definieras av en JSON-pipelinedefinition. Denna pipelinedefinition kodar en pipeline med hjälp av en Directed Acyclic Graph (DAG). Denna DAG ger information om kraven för och relationerna mellan varje steg i din pipeline. Strukturen för en pipelines DAG bestäms av databeroendena mellan stegen. Dessa databeroenden skapas när egenskaperna för ett stegs utdata skickas som indata till ett annat steg.

För att göra det möjligt för datavetenskapsteam att enkelt automatisera skapandet av nya versioner av ML-modeller är det viktigt att introducera valideringssteg och automatiserad data för att kontinuerligt mata och förbättra ML-modeller, samt modellövervakningsstrategier för att aktivera pipelineutlösning. Följande diagram visar ett exempel på en pipeline.

För att möjliggöra automatiseringar och MLOps-funktioner är det viktigt att skapa modulära komponenter för att skapa återanvändbara kodartefakter som kan delas över olika steg och ML-användningsfall. Detta gör att du snabbt kan flytta implementeringen från en experimentfas till en produktionsfas genom att automatisera övergången.

Stegen för att definiera en ML-pipeline för att möjliggöra kontinuerlig utbildning och versionshantering av ML-modeller är följande:

• förbehandling – Processen med datarensning, funktionsteknik och skapande av datauppsättningar för att träna ML-algoritmen
• Utbildning – Processen att träna den utvecklade ML-algoritmen för att generera en ny version av ML-modellartefakten
• Utvärdering – Processen för utvärdering av den genererade ML-modellen, för att extrahera nyckelmått relaterade till modellens beteende på nya data som inte setts under utbildningsfasen
• Registrering – Processen att versionera den nya tränade ML-modellartefakten genom att länka de extraherade mätvärdena med den genererade artefakten

Du kan se mer information om hur man bygger en SageMaker-pipeline nedan anteckningsbok.

Trigga CI/CD-pipelines med EventBridge

När du är klar med att bygga modellen kan du starta implementeringsprocessen. Det sista steget i SageMaker-pipelinen som definierats i föregående avsnitt registrerar en ny version av modellen i den specifika SageMaker-modellregistergruppen. Implementeringen av en ny version av ML-modellen hanteras med hjälp av modellregistrets status. Genom att manuellt godkänna eller avvisa en ML-modellversion, tar detta steg upp en händelse som fångas av EventBridge. Denna händelse kan sedan starta en ny pipeline (CI/CD den här gången) för att skapa en ny version av AWS IoT Greengrass-komponenten som sedan distribueras till förproduktions- och produktionskontona. Följande skärmdump visar vår definierade EventBridge-regel.

Denna regel övervakar SageMaker-modellpaketgruppen genom att leta efter uppdateringar av modellpaket i statusen Approved or Rejected.

EventBridge-regeln konfigureras sedan för att rikta in sig på CodePipeline, vilket startar arbetsflödet för att skapa en ny AWS IoT Greengrass-komponent genom att använda Amazon SageMaker Neo och Edge Manager.

Optimera ML-modeller för målarkitekturen

Neo låter dig optimera ML-modeller för att utföra slutledning på edge-enheter (och i molnet). Den optimerar automatiskt ML-modellerna för bättre prestanda baserat på målarkitekturen och frikopplar modellen från det ursprungliga ramverket, så att du kan köra den på en lätt körtid.

Se följande anteckningsbok för ett exempel på hur man kompilerar en PyTorch Resnet18-modell med Neo.

Bygg distributionspaketet genom att inkludera AWS IoT Greengrass-komponenten

Edge Manager låter dig hantera, säkra, distribuera och övervaka modeller till en flotta av edge-enheter. I följande anteckningsbok, kan du se mer detaljer om hur du bygger en minimalistisk flotta av edge-enheter och kör några experiment med den här funktionen.

När du har konfigurerat flottan och kompilerat modellen måste du köra ett Edge Manager-paketeringsjobb, som förbereder modellen för att distribueras till flottan. Du kan starta ett paketeringsjobb genom att använda Boto3 SDK. För våra parametrar använder vi den optimerade modellen och modellens metadata. Genom att lägga till följande parametrar till OutputConfig, förbereder jobbet också en AWS IoT Greengrass V2-komponent med modellen:

• PresetDeploymentType
• PresetDeploymentConfig

Se följande kod:

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

Distribuera ML-modeller vid kanten i skala

Nu är det dags att distribuera modellen till din flotta av edge-enheter. Först måste vi se till att vi har det nödvändiga AWS identitets- och åtkomsthantering (JAG ÄR) behörigheter att tillhandahålla våra IoT-enheter och kunna distribuera komponenter till den. Vi kräver två grundläggande element för att börja onboarding enheter i vår IoT-plattform:

• IAM-policy – Denna policy tillåter automatisk provisionering av sådana enheter, kopplade till användaren eller rollen som utför provisioneringen. Den bör ha IoT-skrivbehörighet för att skapa IoT-grejen och gruppen, samt för att bifoga nödvändiga policyer till enheten. För mer information, se Minimal IAM-policy för installatören för att tillhandahålla resurser.
• IAM-roll – Den här rollen är knuten till IoT-saker och grupper som vi skapar. Du kan skapa den här rollen vid provisionering med grundläggande behörigheter, men den kommer att sakna funktioner som tillgång till Amazon S3 eller AWS nyckelhanteringstjänst (AWS KMS) som kan behövas senare. Du kan skapa den här rollen i förväg och återanvända den när vi tillhandahåller enheten. För mer information, se Auktorisera kärnenheter att interagera med AWS.

AWS IoT Greengrass installation och provisionering

När vi har IAM-policyn och rollen på plats är vi redo att installera AWS IoT Greengrass Core-programvara med automatisk resursförsörjning. Även om det är möjligt att tillhandahålla IoT-resurserna efter manuella steg, finns det den bekväma proceduren att automatiskt tillhandahålla dessa resurser under installationen av AWS IoT Greengrass v2-kärnan. Detta är det föredragna alternativet för att snabbt ta ombord nya enheter på plattformen. Förutom default-jdk, måste andra paket installeras, som t.ex curl, unzipoch python3.

När vi tillhandahåller vår enhet måste IoT-saknamnet vara exakt detsamma som edge-enheten som definierats i Edge Manager, annars kommer inte data att fångas till destinations S3-bucket.

Installationsprogrammet kan skapa AWS IoT Greengrass-rollen och alias under installationen om de inte finns. De kommer dock att skapas med minimala behörigheter och kommer att kräva att man manuellt lägger till fler policyer för att interagera med andra tjänster som Amazon S3. Vi rekommenderar att du skapar dessa IAM-resurser i förväg som visats tidigare och sedan återanvänder dem när du lägger in nya enheter på kontot.

Modell- och slutledningskomponentförpackning

Efter att vår kod har utvecklats kan vi distribuera både koden (för slutledning) och våra ML-modeller som komponenter i våra enheter.

Efter att ML-modellen har tränats i SageMaker kan du optimera modellen med Neo med hjälp av ett Sagemaker-kompileringsjobb. De resulterande kompilerade modellartefakterna kan sedan paketeras i en GreenGrass V2-komponent med Edge Manager-paketeraren. Sedan kan den registreras som en anpassad komponent i Mina komponenter avsnitt på AWS IoT Greengrass-konsolen. Den här komponenten innehåller redan de nödvändiga livscykelkommandona för att ladda ner och dekomprimera modellartefakten i vår enhet, så att slutledningskoden kan ladda upp den för att skicka bilderna som tagits genom den.

När det gäller slutledningskoden måste vi skapa en komponent med hjälp av konsolen eller AWS-kommandoradsgränssnitt (AWS CLI). Först packar vi vår källkod och nödvändiga beroenden till Amazon S3. När vi har laddat upp koden kan vi skapa vår komponent med hjälp av ett recept i .yaml eller JSON som i följande exempel:

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

Detta exempelrecept visar namnet och beskrivningen av vår komponent, samt de nödvändiga förutsättningarna innan vårt körskriptkommando. Receptet packar upp artefakten i en arbetsmappmiljö i enheten, och vi använder den sökvägen för att köra vår slutledningskod. AWS CLI-kommandot för att skapa ett sådant recept är:

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

Du kan nu se den här komponenten skapad på AWS IoT Greengrass-konsolen.

Se upp för det faktum att komponentversionen spelar roll, och den måste anges i receptfilen. Upprepa samma versionsnummer kommer att returnera ett fel.

Efter att vår modell och slutledningskod har ställts in som komponenter är vi redo att distribuera dem.

Distribuera applikationen och modellen med AWS IoT Greengrass

I de föregående avsnitten lärde du dig hur du paketerar slutledningskoden och ML-modellerna. Nu kan vi skapa en distribution med flera komponenter som inkluderar både komponenter och konfigurationer som behövs för att vår slutledningskod ska interagera med modellen i edge-enheten.

Edge Manager-agenten är den komponent som ska installeras på varje edge-enhet för att aktivera alla Edge Manager-funktioner. På SageMaker-konsolen har vi en enhetsflotta definierad, som har en tillhörande S3-skopa. Alla edge-enheter som är associerade med flottan kommer att fånga och rapportera sina data till denna S3-väg. Agenten kan distribueras som en komponent i AWS IoT Greengrass v2, vilket gör det enklare att installera och konfigurera än om agenten var utplacerad i fristående läge. När vi distribuerar agenten som en komponent måste vi specificera dess konfigurationsparametrar, nämligen enhetsflottan och S3-vägen.

Vi skapar en distributionskonfiguration med de anpassade komponenterna för modellen och koden vi just skapade. Denna inställning definieras i en JSON-fil som listar distributionsnamnet och målet, såväl som komponenterna i distributionen. Vi kan lägga till och uppdatera konfigurationsparametrarna för varje komponent, till exempel i Edge Manager-agenten, där vi anger flottans namn och segment.

{
    "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 är värt att notera att vi har lagt till inte bara modellen, slutledningskomponenterna och agenten, utan även AWS IoT Greengrass CLI och kärnan som komponenter. Den förra kan hjälpa till att felsöka vissa distributioner lokalt på enheten. Det senare läggs till i driftsättningen för att konfigurera nödvändig nätverksåtkomst från själva enheten om det behövs (till exempel proxyinställningar), och även om du vill utföra en OTA-uppgradering av AWS IoT Greengrass v2 kärnan. Kärnan distribueras inte eftersom den är installerad i enheten, och endast konfigurationsuppdateringen kommer att tillämpas (såvida inte en uppgradering är på plats). För att distribuera behöver vi helt enkelt köra följande kommando över den föregående konfigurationen. Kom ihåg att ställa in mål-ARN som distributionen ska tillämpas på (en IoT-sak eller IoT-grupp). Vi kan även distribuera dessa komponenter från konsolen.

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

Övervaka och hantera ML-modeller som distribueras till kanten

Nu när din applikation körs på avancerade enheter är det dags att förstå hur man övervakar flottan för att förbättra styrning, underhåll och synlighet. Välj på SageMaker-konsolen Edge Manager i navigeringsfönstret och välj sedan Edge-enhetens flottor. Härifrån väljer du din flotta.

På flottans detaljsida kan du se lite metadata för de modeller som körs på varje enhet i din flotta. Flottrapport genereras var 24:e timme.

Data som fångas av varje enhet via Edge Agent skickas till en S3-bucket i json-linjersformat (JSONL). Processen att skicka infångad data hanteras från en applikationssynpunkt. Du är därför fri att bestämma om du vill skicka dessa uppgifter, hur och hur ofta.

Du kan använda denna data för många saker, som att övervaka datadrift och modellkvalitet, bygga en ny datauppsättning, berika en datasjö och mer. Ett enkelt exempel på hur man använder denna data är när du identifierar en datadrift i hur användarna interagerar med din applikation och du behöver träna en ny modell. Du bygger sedan en ny datauppsättning med den insamlade datan och kopierar tillbaka den till utvecklingskontot. Detta kan automatiskt starta en ny körning av din miljö som bygger en ny modell och omdistribuerar den till hela flottan för att behålla prestandan för den distribuerade lösningen.

Slutsats

I det här inlägget lärde du dig hur du bygger en komplett lösning som kombinerar MLOps och ML@Edge med hjälp av AWS-tjänster. Att bygga en sådan lösning är inte trivialt, men vi hoppas att referensarkitekturen som presenteras i det här inlägget kan inspirera och hjälpa dig att bygga en solid arkitektur för dina egna affärsutmaningar. Du kan också använda bara de delar eller moduler av denna arkitektur som integreras med din befintliga MLOps-miljö. Genom att prototypa en enskild modul åt gången och använda lämpliga AWS-tjänster för att ta itu med varje del av denna utmaning, kan du lära dig hur du bygger en robust MLOps-miljö och även ytterligare förenkla den slutliga arkitekturen.

Som ett nästa steg uppmuntrar vi dig att prova Sagemaker Edge Manager för att hantera din ML vid kantens livscykel. För mer information om hur Edge Manager fungerar, se Distribuera modeller vid kanten med SageMaker Edge Manager .

Om författarna

Bruno Pistone är en AI/ML Specialist Solutions Architect för AWS baserad i Milano. Han arbetar med kunder av alla storlekar för att hjälpa dem att på djupet förstå deras tekniska behov och designa AI- och Machine Learning-lösningar som utnyttjar AWS Cloud och Amazon Machine Learning-stacken på bästa sätt. Hans expertområde är Machine Learning end to end, Machine Learning Industrialization och MLOps. Han tycker om att umgås med sina vänner och utforska nya platser, samt att resa till nya destinationer.

Matteo Calabrese är en AI/ML Customer Delivery Architect i AWS Professional Services-team. Han arbetar med stora företag i EMEA i AI/ML-projekt och hjälper dem med att föreslå, designa, leverera, skala och optimera ML-produktionsarbetsbelastningar. Hans huvudsakliga expertis är ML Operation (MLOps) och Machine Learning at Edge. Hans mål är att förkorta deras tid att värdera och påskynda affärsresultat genom att tillhandahålla AWS bästa praxis. På fritiden tycker han om att vandra och resa.

Raúl Díaz García är en Sr Data Scientist i AWS Professional Services-team. Han arbetar med stora företagskunder över hela EMEA, där han hjälper dem att möjliggöra lösningar relaterade till datorseende och maskininlärning i IoT-utrymmet.

Sokratis Kartakis är en senior lösningsarkitekt för maskininlärning för Amazon Web Services. Sokratis fokuserar på att göra det möjligt för företagskunder att industrialisera sina lösningar för maskininlärning (ML) genom att utnyttja AWS-tjänster och forma deras verksamhetsmodell, dvs. MLOps-grunden, och transformationsfärdplan som utnyttjar bästa utvecklingsmetoder. Han har ägnat 15+ år åt att uppfinna, designa, leda och implementera innovativa end-to-end produktionsnivå ML och Internet of Things (IoT) lösningar inom områdena energi, detaljhandel, hälsa, finans/bank, motorsport etc. Sokratis gillar att tillbringa sin fritid med familj och vänner, eller att åka motorcykel.

Samir Araújo är AI / ML Solutions Architect på AWS. Han hjälper kunder att skapa AI / ML-lösningar som löser deras affärsutmaningar med hjälp av AWS. Han har arbetat med flera AI / ML-projekt relaterade till datorsyn, bearbetning av naturligt språk, prognoser, ML vid kanten och mer. Han gillar att spela med hårdvaru- och automatiseringsprojekt på fritiden, och han har ett särskilt intresse för robotik.