Distribuer en MLOps-løsning som er vert for modellendepunktene dine i AWS Lambda

I 2019 var Amazon med å grunnlegge klima løftet. Løftets mål er å oppnå netto null karbon innen 2040. Dette er 10 år tidligere enn Paris-avtalen skisserer. Bedrifter som registrerer seg er forpliktet til regelmessig rapportering, karbon-eliminering og troverdige kompensasjoner. I skrivende stund har 377 bedrifter signert klimaløftet, og antallet vokser fortsatt.

Fordi AWS er ​​forpliktet til å hjelpe deg med å nå ditt netto nullmål gjennom skyløsninger og maskinlæring (ML), har mange prosjekter allerede blitt utviklet og implementert som reduserer karbonutslipp. Produksjon er en av næringene som kan ha stor nytte av slike prosjekter. Gjennom optimalisert energistyring av maskiner i produksjonsfabrikker, som kompressorer eller kjølere, kan bedrifter redusere sitt karbonavtrykk med ML.

Effektiv overgang fra en ML-eksperimentfase til produksjon er utfordrende. Automatisering av modellopplæring og omskolering, å ha et modellregister og sporing av eksperimenter og utplassering er noen av hovedutfordringene. For produksjonsbedrifter er det et annet lag med kompleksitet, nemlig hvordan disse utplasserte modellene kan kjøre på kanten.

I dette innlegget adresserer vi disse utfordringene ved å tilby en mal for maskinlæringsoperasjoner (MLOps) som er vert for en bærekraftig energistyringsløsning. Løsningen er agnostisk å bruke tilfeller, noe som betyr at du kan tilpasse den til dine brukstilfeller ved å endre modell og data. Vi viser deg hvordan du integrerer modeller i Amazon SageMaker-rørledninger, et naturlig orkestreringsverktøy for arbeidsflyt for å bygge ML-rørledninger, som kjører en treningsjobb og eventuelt en prosesseringsjobb med en Monte Carlo-simulering. Eksperimenter spores inn Amazon SageMaker-eksperimenter. Modeller spores og registreres i Amazon SageMaker modellregister. Til slutt gir vi kode for distribusjon av din endelige modell i en AWS Lambda funksjon.

Lambda er en databehandlingstjeneste som lar deg kjøre kode uten å administrere eller klargjøre servere. Lambdas automatiske skalering, fakturering per forespørsel og brukervennlighet gjør det til et vanlig distribusjonsvalg for datavitenskapsteam. Med dette innlegget kan dataforskere gjøre modellen om til en kostnadseffektiv og skalerbar Lambda-funksjon. Videre åpner Lambda for integrasjon med AWS IoT Greengrass, som hjelper deg med å bygge programvare som gjør at enhetene dine kan handle på kanten av dataene de genererer, slik tilfellet ville vært for en bærekraftig energistyringsløsning.

Løsningsoversikt

Arkitekturen vi implementerer (se følgende figur) er en fullstendig CI/CD-drevet tilnærming til maskinlæring. Elementer er frakoblet for å unngå å ha én monolittisk løsning.

La oss starte med øverst til venstre i diagrammet. De Behandling – Bildebygging komponenten er en CI/CD-drevet AWS CodeCommit repository som hjelper til med å bygge og presse en Docker beholder til Amazon Elastic Container Registry (Amazon ECR). Denne behandlingsbeholderen fungerer som det første trinnet i vår ML-pipeline, men den blir også gjenbrukt for etterbehandlingstrinn. I vårt tilfelle bruker vi en Monte Carlo-simulering som etterbehandling. De Opplæring – Bildebygging depotet skissert nederst til venstre har samme mekanisme som i prosess blokk over den. Hovedforskjellen er at den bygger containeren for modelltrening.

Hovedrørledningen, Modellbygging (rørledning), er et annet CodeCommit-depot som automatiserer kjøringen av SageMaker-rørledningene dine. Denne rørledningen automatiserer og kobler sammen dataforbehandling, modelltrening, modellberegningssporing i SageMaker-eksperimenter, dataetterbehandling og modellkatalogisering i SageMaker-modellregisteret.

Den siste komponenten er nederst til høyre: Modellutplassering. Hvis du følger eksemplene i Amazon SageMaker-prosjekter, får du en mal som er vert for modellen din ved hjelp av et SageMaker-endepunkt. Vårt distribusjonslager er i stedet vert for modellen i en Lambda-funksjon. Vi viser en tilnærming for å distribuere Lambda-funksjonen som kan kjøre sanntidsprediksjoner.

Forutsetninger

For å implementere løsningen vår på en vellykket måte, trenger du følgende:

Last ned GitHub-depotet

Som et første skritt, klone GitHub repository til din lokale maskin. Den inneholder følgende mappestruktur:

• distribusjon – Inneholder kode som er relevant for distribusjon
• mllib — Inneholder ML-kode for forbehandling, opplæring, servering og simulering
• tester — Inneholder enhets- og integrasjonstester

Nøkkelfilen for distribusjon er shell-skriptet deployment/deploy.sh. Du bruker denne filen til å distribuere ressursene i kontoen din. Før vi kan kjøre shell-skriptet, fullfør følgende trinn:

1. Åpne deployment/app.py og endre bøttenavnet under SageMakerPipelineSourceCodeStack. De bucket_name må være globalt unikt (legg for eksempel til hele navnet ditt).
2. In deployment/pipeline/assets/modelbuild/pipelines/energy_management/pipeline.py, endre default_bucket etter get_pipeline til samme navn som spesifisert i trinn 1.

Distribuer løsning med AWS CDK

Først konfigurer din AWS CLI med kontoen og regionen du vil distribuere i. Kjør deretter følgende kommandoer for å endre til distribusjonskatalogen, opprett et virtuelt miljø, aktiver det, installer de nødvendige pip-pakkene spesifisert i setup.py, og kjør deploy.sh:

cd deployment
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
pre-commit install
chmod u+x deploy.sh
./deploy.sh

deploy.sh utfører følgende handlinger:

1. Oppretter et virtuelt miljø i Python.
2. Kilder til det virtuelle miljøaktiveringsskriptet.
3. Installerer AWS CDK og kravene skissert i setup.py.
4. Bootstraps miljøet.
5. Zipper og kopierer de nødvendige filene du har utviklet, for eksempel din mllib filer, inn i de tilsvarende mappene der disse ressursene er nødvendige.
6. Kjører cdk deploy —require-approval never.
7. Oppretter en AWS skyformasjon stable gjennom AWS CDK.

Den første fasen av utplasseringen bør ta mindre enn 5 minutter. Du bør nå ha fire depoter i CodeCommit i regionen du spesifiserte gjennom AWS CLI, som skissert i arkitekturdiagrammet. De AWS CodePipeline rørledninger kjøres samtidig. De modelbuild og modeldeploy rørledninger avhenger av en vellykket kjøring av prosesserings- og opplæringsbildet. De modeldeploy pipeline avhenger av en vellykket modellbygging. Utrullingen av modellen skal være fullført på mindre enn 1.5 time.

Klon modelllagrene i Studio

For å tilpasse SageMaker-rørledningene opprettet gjennom AWS CDK-distribusjonen i Studio-grensesnittet, må du først klone depotene inn i Studio. Start systemterminalen i Studio og kjør følgende kommandoer etter å ha oppgitt prosjektnavn og ID:

git clone https://git-codecommit.REGION.amazonaws.com/v1/repos/sagemaker-PROJECT_NAME-PROJECT_ID-modelbuild
git clone https://git-codecommit.REGION.amazonaws.com/v1/repos/sagemaker-PROJECT_NAME-PROJECT_ID-modeldeploy
git clone https://git-codecommit.REGION.amazonaws.com/v1/repos/sagemaker-PROJECT_NAME-PROJECT_ID-processing-imagebuild
git clone https://git-codecommit.REGION.amazonaws.com/v1/repos/sagemaker-PROJECT_NAME-PROJECT_ID-training-imagebuild

Etter å ha klonet depotene, kan du sende en commit til depotene. Disse forpliktelsene utløser en CodePipeline-kjøring for de relaterte rørledningene.

Du kan også tilpasse løsningen på din lokale maskin og jobbe på din foretrukne IDE.

Naviger i SageMaker Pipelines og SageMaker Experiments UI

En SageMaker-rørledning er en serie sammenkoblede trinn som er definert ved hjelp av Amazon SageMaker Python SDK. Denne pipelinedefinisjonen koder for en pipeline ved hjelp av en Directed Acyclic Graph (DAG) som kan eksporteres som en JSON-definisjon. For å lære mer om strukturen til slike rørledninger, se SageMaker Pipelines Oversikt.

naviger til SageMaker-ressurser og velg Rørledningsressursen du vil vise. Under Navn, du bør se PROJECT_NAME-PROJECT_ID. I kjøregrensesnittet skal det være en vellykket kjøring som forventes å ta litt over 1 time. Rørledningen skal se ut som vist i følgende skjermbilde.

Kjøringen ble automatisk utløst etter at AWS CDK-stakken ble distribuert. Du kan starte en kjøring manuelt ved å velge Opprett henrettelse. Derfra kan du velge dine egne pipeline-parametere som forekomsttype og antall forekomster for behandlings- og opplæringstrinn. Videre kan du gi løpet navn og beskrivelse. Rørledningen er svært konfigurerbar gjennom pipelineparametere som du kan referere til og definere gjennom hele pipelinedefinisjonen.

Start gjerne en ny pipeline-kjøring med dine parametere etter ønske. Etterpå, naviger til SageMaker-ressurser ruten igjen og velg Eksperimenter og forsøk. Der skal du igjen se en linje med navn som f.eks PROJECT_NAME-PROJECT_ID. Naviger til eksperimentet og velg den eneste kjøringen med en tilfeldig ID. Derfra velger du SageMaker-treningsjobben for å utforske beregningene knyttet til treningsjobben.

Målet med SageMaker Experiments er å gjøre det så enkelt som mulig å lage eksperimenter, fylle dem med forsøk og kjøre analyser på tvers av forsøk og eksperimenter. SageMaker Pipelines er tett integrert med SageMaker-eksperimenter, og oppretter som standard et eksperiment, prøve- og prøvekomponenter for hver kjøring i tilfelle de ikke eksisterer.

Godkjenn Lambda-distribusjon i modellregisteret

Som et neste trinn, naviger til modellregisteret under SageMaker-ressurser. Her kan du igjen finne en linje med navn som f.eks PROJECT_NAME-PROJECT_ID. Naviger til den eneste modellen som finnes og godkjenn den. Dette distribuerer automatisk modellartefakten i en container i Lambda.

Etter at du har godkjent modellen i modellregisteret, vil en Amazon EventBridge hendelsesregelen utløses. Denne regelen kjører CodePipeline-pipeline med slutten *-modeldeploy. I denne delen diskuterer vi hvordan denne løsningen bruker den godkjente modellen og er vert for den i en Lambda-funksjon. CodePipeline tar det eksisterende CodeCommit-depotet som også slutter med *-modeldeploy og bruker den koden til å kjøre i CodeBuild. Hovedinngangen for CodeBuild er buildspec.yml fil. La oss se på dette først:

version: 0.2

env:
  shell: bash

phases:
  install:
    runtime_versions:
      python: 3.8
    commands:
      - python3 -m ensurepip --upgrade
      - python3 -m pip install --upgrade pip
      - python3 -m pip install --upgrade virtualenv
      - python3 -m venv .venv
      - source .venv/bin/activate
      - npm install -g aws-cdk@2.26.0
      - pip install -r requirements.txt
      - cdk bootstrap
  build:
    commands:
      - python build.py --model-package-group-name "$SOURCE_MODEL_PACKAGE_GROUP_NAME"
      - tar -xf model.tar.gz
      - cp model.joblib lambda/digital_twin
      - rm model.tar.gz
      - rm model.joblib
      - cdk deploy --require-approval never

Under installasjonsfasen sørger vi for at Python-bibliotekene er oppdatert, lager et virtuelt miljø, installerer AWS CDK v2.26.0 og installerer aws-cdk Python-biblioteket sammen med andre som bruker kravfilen. Vi også bootstrap AWS-kontoen. I byggefasen kjører vi build.py, som vi diskuterer videre. Den filen laster ned den siste godkjente SageMaker-modellartefakten fra Amazon enkel lagringstjeneste (Amazon S3) til din lokale CodeBuild-forekomst. Dette .tar.gz filen pakkes ut og innholdet kopieres til mappen som også inneholder vår viktigste Lambda-kode. Lambda-funksjonen distribueres ved hjelp av AWS CDK, og koden går ut av en Docker-beholder fra Amazon ECR. Dette gjøres automatisk av AWS CDK.

De build.py filen er en Python-fil som stort sett bruker AWS SDK for Python (Boto3) for å liste opp modellpakkene som er tilgjengelige.

Funksjonen get_approved_package returnerer Amazon S3 URI for artefakten som deretter lastes ned, som beskrevet tidligere.

Etter å ha implementert modellen, kan du test den direkte på Lambda-konsollen i regionen du valgte å distribuere i. Navnet på funksjonen skal inneholde DigitalTwinStack-DigitalTwin*. Åpne funksjonen og naviger til Test fanen. Du kan bruke følgende hendelse til å kjøre en testanrop:

{
  "flow": "[280, 300]",
  "pressure": "[69, 70]",
  "simulations": "10",
  "no_of_trials": "10",
  "train_error_weight": "1.0"
}

Etter å ha kjørt testhendelsen, får du et svar som ligner på det som vises i følgende skjermbilde.

Hvis du vil kjøre flere simuleringer eller forsøk, kan du øke Lambda-tidsavbruddsgrensen og eksperimentere med koden! Eller du vil kanskje plukke opp dataene som genereres og visualisere det samme inn Amazon QuickSight. Nedenfor er et eksempel. Det er din tur nå!

Rydd opp

For å unngå ytterligere kostnader, fullfør følgende trinn:

• På AWS CloudFormation-konsollen sletter du EnergyOptimization stable.
  Dette sletter hele løsningen.
• Slett stabelen DigitalTwinStack, som implementerte Lambda-funksjonen din.

konklusjonen

I dette innlegget viste vi deg en CI/CD-drevet MLOps-pipeline av en energistyringsløsning der vi holder hvert trinn frakoblet. Du kan spore ML-pipelines og eksperimenter i Studio-grensesnittet. Vi demonstrerte også en annen distribusjonstilnærming: ved godkjenning av en modell i modellregisteret, bygges en Lambda-funksjon som er vert for den godkjente modellen automatisk gjennom CodePipeline.

Hvis du er interessert i å utforske enten MLOps-rørledningen på AWS eller den bærekraftige energistyringsløsningen, sjekk ut GitHub repository og distribuer stabelen i ditt eget AWS-miljø!

Om forfatterne

Laurens van der Maas er dataforsker ved AWS Professional Services. Han jobber tett med kunder som bygger sine maskinlæringsløsninger på AWS, og brenner for hvordan maskinlæring endrer verden slik vi kjenner den.

Kangkang Wang er AI/ML-konsulent hos AWS Professional Services. Hun har lang erfaring med å implementere AI/ML-løsninger innen helsevesen og biovitenskap. Hun liker også å hjelpe bedriftskunder med å bygge skalerbare AI/ML-plattformer for å akselerere skyreisen til dataforskerne deres.

Selena Tabbara er dataforsker ved AWS Professional Services. Hun jobber hver dag med kundene sine for å oppnå forretningsresultatene deres ved å innovere på AWS-plattformer. På fritiden liker Selena å spille piano, gå tur og se på basketball.

Michael Wallner er seniorkonsulent med fokus på AI/ML med AWS Professional Services. Michael brenner for å gjøre det mulig for kunder på deres skyreise å bli AWSome. Han er begeistret for produksjon og liker å hjelpe til med å transformere produksjonsområdet gjennom data.