Hvordan Yara bruker MLOps-funksjonene til Amazon SageMaker for å skalere energioptimalisering på tvers av ammoniakkanleggene deres

Yara er verdens ledende plantenæringsselskap og en leverandør av miljø- og landbruksløsninger. Yaras ambisjon er fokusert på å utvikle en naturpositiv matfremtid som skaper verdi for kunder, aksjonærer og samfunnet for øvrig, og leverer en mer bærekraftig matverdikjede. Yara støtter vår visjon om en verden uten sult og en planet som respekteres, og følger en strategi for bærekraftig verdivekst, fremme klimavennlig plantenæring og nullutslippsenergiløsninger. Yara er også verdens største produsent av ammoniakk, nitrater og NPK gjødsel. Produksjonssegmentet deres er derfor en integrert byggestein for å levere oppdraget deres – med en tydelig uttalt ambisjon om å bli verdensledende på beregninger som sikkerhet, miljøfotavtrykk, kvalitet og produksjonskostnader. Yaras langsiktige mål er «Fremtidens anlegg» med null utslipp og lave kostnader.

Yara bygger på en slank transformasjon og øker fokuset på digitale løsninger for å hjelpe dem med å nå ambisjonene sine. For å lede dette arbeidet etablerte Yara en global enhet kalt Digital Production. Suksessen til Digital Production og dens løsninger er en nøkkelprioritet for Yara, og Yara økte betydelig innsatsen innen dette feltet. Et kritisk fokusområde er å dra nytte av den enorme mengden data som genereres som en del av deres virksomhet. Derfor bygger Yara datadrevne produkter som hjelper dem med å optimalisere produksjonen, øke kvaliteten på produktene, øke påliteligheten til produksjonsstedene, redusere utslipp, øke sikkerheten og produktiviteten til arbeidere, automatisere manuelle prosesser og mer.

Energi er en viktig kostnadskomponent for mange produksjonsanlegg; derfor har energieffektivitet en betydelig innvirkning på lønnsomheten. Imidlertid mangler det ofte solide referanser for hvordan god ytelse ser ut og hvordan man kommer seg dit. Yaras energibelastningskurve (ELC) er en løsning som bruker den beste historiske ytelsen på energiforbruk holdt opp mot dagens ytelse. Dersom dagens forbruk avviker for mye fra det historisk beste, gir verktøyet anbefalinger til operatørene for å styre energiforbruket.

For å distribuere ELC til produksjonsanlegg og skalere den til flere steder over hele verden, trengte Yara å bygge en MLOps-plattform. Dette vil sikre at Yara vil trene, distribuere og vedlikeholde modeller pålitelig og effektivt. I tillegg, for å skalere dette til flere nettsteder, trengte Yara å automatisere distribusjons- og vedlikeholdsprosessene. I dette innlegget diskuterer vi hvordan Yara bruker Amazon SageMaker funksjoner, inkludert modellregisteret, Amazon SageMaker modellmonitorog Amazon SageMaker-rørledninger å strømlinjeforme livssyklusen for maskinlæring (ML) ved å automatisere og standardisere MLOps-praksis. Vi gir en oversikt over oppsettet, og viser frem prosessen med å bygge, trene, distribuere og overvåke ML-modeller for anlegg over hele verden.

Oversikt over løsning

ELC bruker Internet of Things (IoT) sensordata fra et anlegg. Disse sensorene måler beregninger som produksjonsgjennomstrømning, omgivelsesforhold og råmaterialeforhold osv. Disse dataene brukes til å trene opp en energiprediksjonsmodell som deretter brukes til å generere timeprediksjoner. Anleggsoperatører overvåker det faktiske energiforbruket og sammenligner det med det optimale forbruket som forutsagt av ELC. Hvis det nåværende energiforbruket avviker for mye fra det optimale punktet, gir ELC en handling for å justere interne prosessvariabler for å optimalisere energieffektiviteten basert på analytiske modeller.

ELC er vert i skyen. For å streame sensordata fra et anlegg i sanntid, bruker Yara AWS IoT Greengrass å kommunisere sikkert med AWS IoT-kjerne og eksporter IoT-data til AWS-skyen. AWS IoT SiteWise er en administrert tjeneste som kan samle inn, organisere, søke i og konsumere utstyrsdata fra industrielt utstyr i stor skala. Yara har bygget APIer ved hjelp av Amazon API-gateway å eksponere sensordataene for applikasjoner som ELC.

ELC-applikasjonens backend distribueres via Amazon ECS og driver ELC-dashbord på frontenden som brukes av anleggsoperatører. ELC-applikasjonen er ansvarlig for å gi timebaserte prediktive energiforbruksmålinger til anleggsoperatører. Hvert anlegg er utstyrt med sin egen modell, fordi deres energiforbruksegenskaper er forskjellige. Videre er planter gruppert i forskjellige AWS-regioner basert på deres plassering.

Følgende diagram illustrerer denne arkitekturen.

For å bygge ELC og skalere til flere anlegg, trengte vi en MLOps-løsning som støtter følgende:

• skalerbarhet – Den kan skaleres som svar på datamengder. Noen planter produserer mer data enn andre; hvert anlegg kan produsere flere gigabyte med data per dag.
• Utvidbarhet – Den kan distribueres til nye regioner og kontoer.
• Repeterbarhet – Den har vanlige maler som vi kan bruke for å ombord på et nytt anlegg.
• fleksibilitet – Den kan endre utplasseringskonfigurasjonen basert på hvert anleggs behov.
• Pålitelighet og overvåking – Den kan kjøre tester og ha en klar innsyn i statusen til alle aktive anlegg. I tilfelle feil kan den rulle tilbake til forrige stabile tilstand.
• Vedlikehold – Løsningen bør ha lave vedlikeholdskostnader. Den bør bruke serverløse tjenester der det er mulig for å redusere infrastrukturens fotavtrykk.

For ML bestemte Yara seg for å bruke SageMaker. SageMaker er en fullt administrert tjeneste som dekker hele ML-arbeidsflyten. Følgende funksjoner var avgjørende for å velge SageMaker:

• SageMaker rammebeholdere – Yara hadde trent ELC-prediktive modeller på TensorFlow, og med SageMaker-rammebeholdere var Yara i stand til å løfte og flytte disse modellene med minimale kodeendringer til SageMaker.
• SageMaker-rørledninger – SageMaker Pipelines tilbyr et Python-grensesnitt for dataforskere for å skrive ML-pipelines. En stor del av ELC-koden består av en trenings- og en slutningspipeline, som er definert i Python.
• SageMaker modellregister – SageMaker modellregisteret gjør det mulig å katalogisere og versjonskontrollere modeller. I tillegg gjør det det enkelt å administrere modellmetadata, for eksempel treningsmålinger.
• SageMaker modellmonitor – Yara ønsket å overvåke kvaliteten og distribusjonen av de innkommende dataene samt ytelsen til ELC-modellen. SageMaker Model Monitor APIer tilbyr data- og modellkvalitetsovervåking.

For å administrere den kontinuerlige integrasjonen og den kontinuerlige leveringen (CI/CD) for ML-rørledningene, bruker Yara Amazon Deployment Framework (ADF). ADF er et åpen kildekode-rammeverk utviklet av AWS for å administrere og distribuere ressurser på tvers av flere AWS-kontoer og regioner i en AWS-organisasjon. ADF tillater trinnvise, parallelle, multi-kontoer og tverrregionale distribusjoner av applikasjoner eller ressurser via strukturen definert i AWS organisasjoner, mens du drar nytte av tjenester som f.eks AWS CodePipeline, AWS CodeBuild, AWS CodeCommitog AWS skyformasjon for å lette de tunge løftene og håndteringen sammenlignet med et tradisjonelt CI/CD-oppsett.

Løsningsoversikt

Hele løsningen for MLOps-plattformen ble bygget i løpet av to måneder i et samarbeid med AWS profesjonelle tjenester. Teamet som jobbet med prosjektet besto av dataforskere, dataingeniører og DevOps-spesialister. For å tilrettelegge for raskere utvikling i et flerlagsmiljø, valgte Yara å bruke AWS Landing Zone og organisasjoner for sentralt å opprette, administrere og styre forskjellige AWS-kontoer. Yara har for eksempel en sentral distribusjonskonto, og bruker arbeidsbelastningskontoer til å være vert for forretningsapplikasjoner. ELC er en brukscase for prosessoptimalisering og er distribuert for å optimalisere arbeidsbelastningskontoer. Yara Digital Production-teamet jobber også med ML-brukssaker på andre områder enn optimalisering. MLOps-rammeverket støtter distribusjon til alle arbeidsbelastningskontoer så lenge kontoene opprettes via organisasjoner.

Følgende diagram illustrerer denne arkitekturen.

Ved å bruke en sentral distribusjonskonto blir det enkelt å administrere vanlige artefakter og CI/CD-pipelines. Når det gjelder tilgangsadministrasjon og sikkerhet for disse vanlige artefaktene, er det en enklere design fordi tillatelsesgrenser og krypteringsnøkler administreres sentralt på ett sted. I de følgende delene leder vi deg gjennom trinnene som kreves for å sette inn en ny brukssak til Yaras MLOps-plattform.

Når det gjelder kontostrategi, har Yara et oppsett av sandkasse, DEV, TEST og PROD. Sandkassekontoen brukes til å eksperimentere og prøve ut nye ideer. DEV-kontoen er utgangspunktet for CI/CD-rørledningene, og all utvikling starter her. Distribusjonskontoen inneholder CI/CD-pipelinedefinisjonen og er i stand til å distribuere til DEV-, TEST- og PROD-kontoene. Dette kontooppsettet er avbildet i følgende figur.

Introduserer en ny brukssak

For dette innlegget antar vi at vi har en fungerende prototype av en brukssak, og nå ønsker vi å operasjonalisere den. I tilfelle denne brukssaken tilhører et nytt produktområde, må vi først klargjøre kontoene ved hjelp av Organisasjoner, som automatisk utløser ADF for å starte opp disse kontoene for distribusjon. Yara følger en DEV>TEST>PROD-kontostrategi; denne konfigurasjonen er imidlertid ikke obligatorisk. Datakontoer avslører APIer for datatilgang, og for en ny brukstilfelle må roller gis de nødvendige AWS identitets- og tilgangsadministrasjon (IAM) tillatelser slik at de kan få tilgang til data-API-ene.

Deretter må vi definere hvilke kontoer denne brukssaken er distribuert til. Dette gjøres ved hjelp av et distribusjonskart i ADF. Utplasseringskartet er en konfigurasjonsfil som inneholder kartleggingen av stadier og mål for rørledningen. For å kjøre distribusjonskartet bruker ADF CodePipeline. ADF gir fleksibiliteten til å administrere parametere per målmiljø stabelen er distribuert til. Dette gjør det enkelt å administrere distribusjoner og teste med mindre forekomster.

For å kryptere alle artefakter, som kode, data og modellfiler, genererer vi en AWS nøkkelstyringstjeneste (AWS KMS)-tast. Du kan også bruke kryptering på serversiden. Men fordi noen av de genererte artefaktene er tilgjengelig på tvers av kontoer, må vi generere vår egen nøkkel og administrere tillatelsespolicyene for å gi tilgang på tvers av kontoer.

Til slutt må vi lage en modellpakkegruppe for å gruppere forskjellige versjoner av en modell ved å bruke SageMaker-modellregisteret, som er SageMakers evne til å spore og administrere modeller mens de beveger seg gjennom ML-livssyklusen.

Modell treningspipeline

For hvert nytt anlegg som er ombord for ELC, oppretter vi en ny SageMaker-treningspipeline. Denne pipelinen består av dataforbehandling og modelltreningstrinn. SageMaker-rørledninger passer godt for Yara fordi de tilbyr et Python-grensesnitt for å definere en ML-arbeidsflyt. Videre kan ulike trinn i arbeidsflyten konfigureres til å skalere forskjellig. Du kan for eksempel definere en mye større instans for opplæring enn for modellevalueringstrinnet. Inn- og utdataparametere for hvert trinn i rørledningen er lagret, noe som gjør det enkelt å spore hver kjøring og dens utganger. Oversikten over treningsarbeidsflyten på høyt nivå er som følger.

Som en del av modellevalueringsstadiet brukes et evalueringsdatasett for å generere beregninger, for eksempel nøyaktighet og root-mean-squared error (RMSE) avvik på den trente modellen. Disse beregningene legges til modellens metadata før modellen registreres i modellregisteret. For øyeblikket markedsføres modellene manuelt til høyere miljøer, og modellgodkjenneren kan se modellberegningene for å sikre at den nye versjonen gir bedre resultater enn den nåværende modellen.

Modeller er versjonsstyrt med modellregisteret, hvor hvert anlegg har sin egen modellpakkegruppe. I tillegg kan du bruke modellregisteret til å spore hvilke modellversjoner som er distribuert til hvilke miljøer. En modell kan være i en Avvist, Venter på manuell godkjenningeller Godkjent stat, og kun modeller som er i Godkjent staten kan utplasseres. Dette gir også beskyttelse mot utilsiktet bruk av en ikke-godkjent versjon av modellen.

Modellinferens og overvåkingsrørledning

For å distribuere modellen og sette opp modellovervåking, satte vi opp en andre SageMaker-pipeline. ELC-applikasjonen gir anleggsoperatører spådommer på etterspørsel, derfor får modellene tilgang via API-anrop fra ELC-backend. SageMaker inferens-endepunkter gir en fullstendig administrert modellvertsløsning med et API-lag; endepunkter tar modellinndata som nyttelast og returforutsigelser. Fordi latens også er en avgjørende faktor for sluttbrukerne som ikke ønsker å vente lenge før de får oppdaterte spådommer, valgte Yara SageMaker sanntidsslutningsendepunkter, som er spesielt egnet for arbeidsbelastninger med svært lave latenskrav. Til slutt, fordi ELC-applikasjonen ikke kan ha nedetid mens oppdaterte modeller distribueres, er den avhengig av den blå/grønne distribusjonsevnen til SageMaker sanntidsendepunkter for å sikre at den gamle modellversjonen fortsetter å tjene prediksjon til den nye versjonen er distribuert .

Følgende diagram illustrerer distribusjons- og overvåkingsoppsettet.

For modellovervåking driver Yara SageMaker datakvalitet, modellkvalitetog modellforklarlighet overvåkning. Datakvalitetsovervåkingen sjekker for konsistens og genererer datadistribusjonsstatistikk. Modellkvalitetsovervåking sjekker modellens ytelse og sammenligner modellens nøyaktighet med treningsmålingene. Modellovervåkingsrapporter genereres på timebasis. Disse rapportene brukes til å overvåke modellens ytelse i produksjonen. Modellforklaringsovervåking brukes for å forstå hvilke funksjoner som bidrar mest til en prediksjon.

Disse resultatene av modellforklaring deles på ELC-dashbordet for å gi anleggsoperatører mer kontekst om hva som driver energiforbruket. Dette støtter også å bestemme handlingen for å justere den interne prosessen i tilfelle energiforbruket avviker fra det optimale punktet.

CI/CD flyt

CI/CD-flyten for treningsrørledningene starter i DEV-kontoen. Yara følger en funksjonsbasert utviklingsmodell og når en ny funksjon utvikles, blir funksjonsgrenen slått sammen i stammen, som starter utrullingen. ELC-modeller trenes i DEV-kontoen, og etter at modellen er opplært og evaluert, registreres den i modellregisteret. En modellgodkjenner utfører fornuftskontroller før den oppdaterer modellstatusen til Godkjent. Denne handlingen genererer en hendelse som utløser distribusjonen av modellslutningsrørledningen. Modellinferensrørledningen distribuerer den nye modellversjonen til et SageMaker-endepunkt i DEV.

Etter utplasseringen av endepunktet startes tester for å sjekke atferden til oppsettet. Til testing bruker Yara CodeBuild testrapporter. Denne funksjonen lar utviklere kjøre enhetstester, konfigurasjonstester og funksjonstester før og etter distribusjon. I dette tilfellet kjører Yara funksjonelle tester ved å sende testnyttelaster til SageMaker-endepunkter og evaluere responsen. Etter at disse testene er bestått, fortsetter rørledningen med å distribuere SageMaker-endepunktene for å TEST. ELC-backend er også distribuert til TEST, som gjør ende-til-ende-testing for appen mulig i dette miljøet. I tillegg kjører Yara brukeraksepttesting i TEST. Utløseren fra TEST til PROD-distribusjon er en manuell godkjenningshandling. Etter at den nye modellversjonen har bestått både funksjons- og brukeraksepttesting i TEST, godkjenner ingeniørteamet modelldistribusjonen til PROD.

Følgende figur illustrerer denne arbeidsflyten.

Vanlige komponenter

For ELC bruker vi flere komponenter som er felles for alle distribusjonstrinn (DEV, TEST, PROD) og modeller. Disse komponentene ligger i distribusjonskontoen vår, og inkluderer modellversjonskontroll, et beholderbildelager, en krypteringsnøkkel og en bøtte for å lagre vanlige artefakter.

Det er flere fordeler ved å bruke vanlige artefakter. For eksempel trenger ikke ressursene opprettes for hver konto, noe som fremtvinger kompatibilitet mellom kontoene. Det betyr at vi bygger containerbilder én gang og gjenbruker dem i alle målkontoer, noe som reduserer byggetiden.

Denne pipelinen lagrer de forskjellige modellversjonene i et felles modellregister i distribusjonskontoen. Fra denne sentrale plasseringen kan modeller distribueres i alle kontoer uten å overføre dem. På samme måte gjør bruken av en sentralt lagret krypteringsnøkkel det enklere å administrere nøkkelen og tillatelsene på tvers av kontoer.

En ulempe med å bruke vanlige artefakter er at innføringstrinnet for en ny brukssak kan bli mer forseggjort. For å ta med en ny brukssak, må det opprettes et nytt modellregister og om nødvendig et nytt beholderbildelager. Vi anbefaler også å opprette en ny krypteringsnøkkel for å strengt skille ressurser og lagrede data.

konklusjonen

I dette innlegget demonstrerte vi hvordan Yara brukte SageMaker og ADF for å bygge en svært skalerbar MLOps-plattform. ML er en tverrfunksjonell funksjon, og team distribuerer modeller til forskjellige forretningsenhetskontoer. Derfor gjør ADF, som tilbyr innebygd integrasjon med organisasjoner, det til en ideell kandidat for å starte opp kontoer for å sette opp CI/CD-pipelines. Operativt kjører ADF-rørledninger i den sentrale distribusjonskontoen, noe som gjør det enkelt å få et samlet helsebilde av distribusjoner. Til slutt bruker ADF AWS-administrerte tjenester som CodeBuild, CodeDeploy, CodePipeline og CloudFormation, noe som gjør det enkelt å konfigurere og vedlikeholde.

SageMaker tilbyr et bredt spekter av ML-funksjoner, som gjør det mulig for team å fokusere mer på å løse forretningsproblemer og mindre på å bygge og vedlikeholde infrastruktur. I tillegg gir SageMaker Pipelines et rikt sett med API-er for å lage, oppdatere og distribuere ML-arbeidsflyter, noe som gjør den perfekt for MLOps.

Til slutt gir MLOps den beste praksisen for å distribuere og vedlikeholde ML-modeller i produksjon pålitelig og effektivt. Det er avgjørende for team som lager og distribuerer ML-løsninger i stor skala for å implementere MLOps. I Yaras tilfelle reduserer MLOps betydelig innsatsen som kreves for å ombord på et nytt anlegg, rulle ut oppdateringer til ELC og sikre at modellene overvåkes for kvalitet.

For mer informasjon om hvordan du distribuerer programmer ved hjelp av ADF, se eksempler.

---

Om forfatterne

Shaheer Mansoor er dataforsker ved AWS. Fokuset hans er å bygge maskinlæringsplattformer som kan være vert for AI-løsninger i stor skala. Hans interesseområder er MLOps, funksjonsbutikker, modellhosting og modellovervåking.

Tim Becker er senior dataforsker ved Yara International. Innen Digital Production er hans fokus på prosessoptimalisering av ammoniakk- og salpetersyreproduksjon. Han har en doktorgrad i termodynamikk og brenner for å bringe sammen prosessteknikk og maskinlæring.

Yongyos Kaewpitakkun er senior dataforsker i Digital Production-teamet hos Yara International. Han har en doktorgrad i AI/maskinlæring og mange års praktisk erfaring med å utnytte maskinlæring, datasyn og prosesseringsmodeller for naturlig språk for å løse utfordrende forretningsproblemer.