Hoe Yara MLOps-functies van Amazon SageMaker gebruikt om energie-optimalisatie in hun ammoniakfabrieken op te schalen

Yara is 's werelds toonaangevende gewasvoedingsbedrijf en leverancier van milieu- en landbouwoplossingen. Yara's ambitie is gericht op het ontwikkelen van een natuur-positieve voedseltoekomst die waarde creëert voor klanten, aandeelhouders en de samenleving als geheel, en zorgt voor een duurzamere voedselwaardeketen. Yara ondersteunt onze visie van een wereld zonder honger en een gerespecteerde planeet en volgt een strategie van duurzame waardegroei, bevordering van klimaatvriendelijke gewasvoeding en emissievrije energieoplossingen. Yara is ook 's werelds grootste producent van ammoniak, nitraten en NPK meststoffen. Hun productiesegment is daarom een ​​integrale bouwsteen voor het realiseren van hun missie - met een duidelijk uitgesproken ambitie om wereldleider te worden op het gebied van veiligheid, ecologische voetafdruk, kwaliteit en productiekosten. Yara's langetermijndoelstelling is de "Plant of the Future" met nulemissie en lage kosten.

Voortbouwend op een lean-transformatie, vergroot Yara hun focus op digitale oplossingen om hen te helpen hun ambities waar te maken. Om deze inspanning te leiden, heeft Yara een wereldwijde eenheid opgericht met de naam Digital Production. Het succes van digitale productie en de bijbehorende oplossingen is een topprioriteit voor Yara, en Yara heeft haar inspanningen op dit gebied aanzienlijk uitgebreid. Een cruciaal aandachtsgebied is om te profiteren van de enorme hoeveelheid gegevens die wordt gegenereerd als onderdeel van hun activiteiten. Daarom bouwt Yara datagestuurde producten die hen helpen de productie te optimaliseren, de kwaliteit van producten te verhogen, de betrouwbaarheid van productielocaties te vergroten, emissies te verminderen, de veiligheid en productiviteit van werknemers te verhogen, handmatige processen te automatiseren en meer.

Energie is voor veel productie-installaties een belangrijke kostenpost; daarom heeft energie-efficiëntie een substantiële invloed op de winstgevendheid. Er is echter vaak een gebrek aan solide referenties voor hoe goede prestaties eruit zien en hoe daar te komen. Yara's Energy Load Curve (ELC) is een oplossing die gebruik maakt van de beste historische prestaties op het gebied van energieverbruik afgezet tegen de huidige prestaties. Als het huidige verbruik te veel afwijkt van het historische beste, geeft de tool aanbevelingen aan de operators om het energieverbruik te sturen.

Om ELC te implementeren in productiefaciliteiten en te schalen naar meerdere locaties over de hele wereld, moest Yara een MLOps-platform bouwen. Dit zou ervoor zorgen dat Yara modellen betrouwbaar en efficiënt zou trainen, inzetten en onderhouden. Om dit naar meerdere locaties te schalen, moest Yara bovendien de implementatie- en onderhoudsprocessen automatiseren. In dit bericht bespreken we hoe Yara gebruikt Amazon Sage Maker functies, waaronder het modelregister, Amazon SageMaker-modelmonitor en Amazon SageMaker-pijpleidingen om de levenscyclus van machine learning (ML) te stroomlijnen door MLOps-praktijken te automatiseren en te standaardiseren. We bieden een overzicht van de opzet en laten het proces zien van het bouwen, trainen, implementeren en bewaken van ML-modellen voor fabrieken over de hele wereld.

Overzicht van de oplossing

ELC maakt gebruik van Internet of Things (IoT)-sensorgegevens van een fabriek. Deze sensoren meten statistieken zoals productiedoorvoer, omgevingscondities en grondstofcondities, enz. Deze gegevens worden gebruikt om een ​​energievoorspellingsmodel te trainen dat vervolgens wordt gebruikt om uurlijkse voorspellingen te genereren. Operators van installaties monitoren het werkelijke energieverbruik en vergelijken dit met het optimale verbruik zoals voorspeld door ELC. Als het huidige energieverbruik te veel afwijkt van het optimale punt, biedt ELC een actie om interne procesvariabelen aan te passen om de energie-efficiëntie te optimaliseren op basis van analytische modellen.

ELC wordt gehost in de cloud. Om in realtime sensorgegevens van een plant te streamen, gebruikt Yara AWS IoT Greengrass om veilig mee te communiceren AWS IoT-kern en exporteer IoT-gegevens naar de AWS-cloud. AWS IoT SiteWise is een beheerde service die apparatuurgegevens van industriële apparatuur op grote schaal kan verzamelen, organiseren, doorzoeken en gebruiken. Yara heeft API's gebouwd met behulp van Amazon API-gateway om de sensorgegevens bloot te stellen aan toepassingen zoals ELC.

De backend van de ELC-applicatie wordt geïmplementeerd via Amazon ECS en stuurt ELC-dashboards aan de voorkant aan die worden gebruikt door fabrieksoperators. De ELC-applicatie is verantwoordelijk voor het leveren van uurlijkse voorspellende energieverbruiksstatistieken aan exploitanten van installaties. Elke plant heeft een eigen model, omdat hun kenmerken van energieverbruik verschillen. Bovendien zijn fabrieken geclusterd in verschillende AWS-regio's op basis van hun locatie.

Het volgende diagram illustreert deze architectuur.

Voor het bouwen van ELC en het opschalen naar meerdere fabrieken hadden we een MLOps-oplossing nodig die het volgende ondersteunt:

• Schaalbaarheid - Het kan worden geschaald als reactie op datavolumes. Sommige planten produceren meer data dan andere; elke plant kan meerdere gigabytes aan data per dag produceren.
• Uitbreidbaarheid - Het kan worden geïmplementeerd in nieuwe regio's en accounts.
• Herhaalbaarheid – Het heeft gemeenschappelijke sjablonen die we kunnen gebruiken om een ​​nieuwe fabriek aan boord te krijgen.
• Flexibiliteit – Het kan de implementatieconfiguratie wijzigen op basis van de behoeften van elke fabriek.
• Betrouwbaarheid en monitoring – Het kan tests uitvoeren en heeft een duidelijk zicht op de status van alle actieve planten. In geval van een storing kan het worden teruggedraaid naar de vorige stabiele toestand.
• Onderhoud – De oplossing moet weinig onderhoudskosten hebben. Het moet waar mogelijk serverloze services gebruiken om de voetafdruk van de infrastructuur te verkleinen.

Voor ML besloot Yara om SageMaker te gebruiken. SageMaker is een volledig beheerde service die de volledige ML-workflow dekt. De volgende functies waren van cruciaal belang bij het selecteren van SageMaker:

• SageMaker-raamwerkcontainers – Yara had ELC-voorspellingsmodellen getraind op TensorFlow, en met SageMaker-frameworkcontainers was Yara in staat om deze modellen met minimale codewijzigingen op te tillen en te verplaatsen naar SageMaker.
• SageMaker-pijpleidingen – SageMaker Pipelines bieden een Python-interface voor datawetenschappers om ML-pijplijnen te schrijven. Een groot deel van de ELC-code bestaat uit een training en een inferentiepijplijn, die zijn gedefinieerd in Python.
• SageMaker-modelregister – Het SageMaker-modelregister maakt het mogelijk om modellen te catalogiseren en versiebeheer uit te voeren. Bovendien maakt het het eenvoudig om metadata van modellen te beheren, zoals trainingsstatistieken.
• SageMaker-modelmonitor – Yara wilde de kwaliteit en distributie van de binnenkomende gegevens bewaken, evenals de prestaties van het ELC-model. SageMaker Model Monitor API's bieden monitoring van gegevens en modelkwaliteit.

Om de continue integratie en continue levering (CI/CD) voor de ML-pijplijnen te beheren, gebruikt Yara Amazon-implementatiekader (ADF). ADF is een open-source framework ontwikkeld door AWS om bronnen te beheren en in te zetten voor meerdere AWS-accounts en regio's binnen een AWS-organisatie. ADF maakt gefaseerde, parallelle, multi-account en interregionale implementaties van applicaties of bronnen mogelijk via de structuur die is gedefinieerd in AWS-organisaties, terwijl u profiteert van diensten zoals AWS CodePipeline, AWS CodeBuild, AWS Codecommit en AWS CloudFormatie om het zware werk en beheer te verlichten in vergelijking met een traditionele CI/CD-configuratie.

Overzicht oplossingen

De volledige oplossing voor het MLOps-platform is binnen twee maanden gebouwd in samenwerking met AWS professionele services. Het team dat aan het project werkte, bestond uit datawetenschappers, data-engineers en DevOps-specialisten. Om een ​​snellere ontwikkeling in een omgeving met meerdere teams mogelijk te maken, koos Yara ervoor om te gebruiken AWS Landing Zone en organisaties om verschillende AWS-accounts centraal aan te maken, te beheren en te beheren. Yara heeft bijvoorbeeld een centraal implementatieaccount en gebruikt workloadaccounts om bedrijfsapplicaties te hosten. ELC is een use-case voor procesoptimalisatie en wordt ingezet om workload-accounts te optimaliseren. Het Yara Digital Production-team werkt ook aan ML-use cases op andere gebieden dan optimalisatie. Het MLOps-framework ondersteunt implementatie naar alle workload-accounts, zolang de accounts zijn gemaakt via organisaties.

Het volgende diagram illustreert deze architectuur.

Het gebruik van een centraal implementatieaccount maakt het eenvoudig om algemene artefacten en CI/CD-pijplijnen te beheren. In termen van toegangsbeheer en beveiliging van deze veelvoorkomende artefacten is het een eenvoudiger ontwerp omdat machtigingsgrenzen en coderingssleutels centraal op één plek worden beheerd. In de volgende secties leiden we u door de stappen die nodig zijn om een ​​nieuwe use case aan te sluiten op het MLOps-platform van Yara.

Qua accountstrategie heeft Yara een sandbox-, DEV-, TEST- en PROD-configuratie. Het sandbox-account wordt gebruikt om te experimenteren en nieuwe ideeën uit te proberen. Het DEV-account is het startpunt van de CI/CD-pijplijnen en alle ontwikkeling begint hier. Het implementatieaccount bevat de CI/CD-pijplijndefinitie en kan worden geïmplementeerd op de DEV-, TEST- en PROD-accounts. Deze accountconfiguratie wordt weergegeven in de volgende afbeelding.

Onboarding van een nieuwe use-case

Voor deze post gaan we ervan uit dat we een werkend prototype van een use case hebben, en nu willen we het operationaliseren. In het geval dat deze use case tot een nieuw productgebied behoort, moeten we eerst de accounts inrichten met behulp van organisaties, waardoor ADF automatisch wordt geactiveerd om deze accounts op te starten voor implementatie. Yara volgt een DEV>TEST>PROD-accountstrategie; deze configuratie is echter niet verplicht. Data-accounts stellen API's bloot voor gegevenstoegang, en voor een nieuwe use-case moeten de nodige rollen worden toegekend AWS Identiteits- en toegangsbeheer (IAM) machtigingen zodat ze toegang hebben tot de gegevens-API's.

Vervolgens moeten we definiëren naar welke accounts deze use case wordt geïmplementeerd. Dit wordt gedaan met behulp van een implementatiekaart in ADF. De implementatiekaart is een configuratiebestand dat de toewijzing van stadia en doelen voor de pijplijn bevat. Om de implementatiekaart uit te voeren, gebruikt ADF CodePipeline. ADF biedt de flexibiliteit om parameters te beheren per doelomgeving waarin de stack wordt geïmplementeerd. Dit maakt het eenvoudig om implementaties te beheren en te testen met kleinere instanties.

Voor het versleutelen van alle artefacten, zoals code, gegevens en modelbestanden, genereren we een AWS Sleutelbeheerservice (AWS KMS) sleutel. U kunt ook versleuteling aan de serverzijde gebruiken. Omdat sommige van de gegenereerde artefacten echter toegankelijk zijn voor verschillende accounts, moeten we onze eigen sleutel genereren en het machtigingsbeleid beheren om toegang voor meerdere accounts te verlenen.

Ten slotte moeten we een modelpakketgroep maken om verschillende versies van een model te groeperen met behulp van het SageMaker-modelregister, de SageMaker-mogelijkheid om modellen te volgen en te beheren terwijl ze door de ML-levenscyclus gaan.

Model trainingspijplijn

Voor elke nieuwe fabriek die voor ELC aan boord komt, creëren we een nieuwe SageMaker-trainingspijplijn. Deze pijplijn bestaat uit gegevensvoorverwerking en modeltrainingsstappen. SageMaker-pijplijnen passen goed bij Yara omdat ze een Python-interface bieden voor het definiëren van een ML-workflow. Bovendien kunnen verschillende stappen van de workflow worden geconfigureerd om anders te schalen. U kunt bijvoorbeeld een veel grotere instantie definiëren voor training dan voor de modelevaluatiestap. Invoer- en uitvoerparameters voor elke stap van de pijplijn worden opgeslagen, waardoor het gemakkelijk is om elke uitvoering en de bijbehorende uitvoer te volgen. De hoofdlijnen van de trainingsworkflow zijn als volgt.

Als onderdeel van de modelevaluatiefase wordt een evaluatiedataset gebruikt om statistieken te genereren, zoals nauwkeurigheid en RMSE-afwijking (root-mean-squared error) op het getrainde model. Deze statistieken worden toegevoegd aan de metagegevens van het model voordat het model wordt geregistreerd bij het modelregister. Momenteel worden modellen handmatig gepromoveerd naar hogere omgevingen en kan de goedkeurder van het model de modelstatistieken bekijken om ervoor te zorgen dat de nieuwe versie beter presteert dan het huidige model.

Modellen worden versiebeheerd met het modelregister, waarbij elke fabriek zijn eigen modelpakketgroep heeft. Bovendien kunt u het modelregister gebruiken om bij te houden welke modelversies in welke omgevingen zijn geïmplementeerd. Een model kan in een Verworpen, In afwachting van handmatige goedkeuringof aangenomen staat, en alleen modellen die in de aangenomen staat kan worden ingezet. Dit biedt ook bescherming tegen het per ongeluk implementeren van een niet-goedgekeurde versie van het model.

Model inferentie en monitoring pijplijn

Om het model te implementeren en modelmonitoring in te richten, hebben we een tweede SageMaker-pijplijn opgezet. De ELC-applicatie biedt op verzoek voorspellingen van installatie-operators, daarom zijn de modellen toegankelijk via API-aanroepen vanuit de ELC-backend. SageMaker-inferentie-eindpunten bieden een volledig beheerde modelhostingoplossing met een API-laag; eindpunten nemen modelinvoer als payload en retourneren voorspellingen. Omdat latentie ook een cruciale factor is voor de eindgebruikers die niet lang willen wachten voordat ze bijgewerkte voorspellingen krijgen, koos Yara voor real-time inferentie-eindpunten van SageMaker, die met name geschikt zijn voor workloads met zeer lage latentie-eisen. Ten slotte, omdat de ELC-applicatie geen downtime kan hebben terwijl bijgewerkte modellen worden geïmplementeerd, vertrouwt deze op de blauw/groene implementatiemogelijkheden van SageMaker real-time endpoints om ervoor te zorgen dat de oude modelversie voorspelling blijft geven totdat de nieuwe versie wordt geïmplementeerd .

Het volgende diagram illustreert de installatie van implementatie en bewaking.

Voor modelbewaking voert Yara SageMaker uit data kwaliteit, modelkwaliteit en modelleerbaarheid toezicht houden. De monitoring van de gegevenskwaliteit controleert op consistentie en genereert gegevensdistributiestatistieken. Modelkwaliteitsbewaking controleert de modelprestaties en vergelijkt de modelnauwkeurigheid met de trainingsstatistieken. Modelbewakingsrapporten worden op uurbasis gegenereerd. Deze rapporten worden gebruikt om de modelprestaties in productie te bewaken. Monitoring van de uitlegbaarheid van modellen wordt gebruikt om te begrijpen welke functies het meest bijdragen aan een voorspelling.

Deze resultaten van de uitlegbaarheid van het model worden gedeeld op het ELC-dashboard om operators van installaties meer context te geven over wat het energieverbruik bepaalt. Dit ondersteunt ook het bepalen van de actie om het interne proces bij te sturen als het energieverbruik afwijkt van het optimale punt.

CI/CD-stroom

De CI/CD-stroom voor de trainingspijplijnen begint in het DEV-account. Yara volgt een op functies gebaseerd ontwikkelingsmodel en wanneer een nieuwe functie wordt ontwikkeld, wordt de functietak samengevoegd in de trunk, waarmee de implementatie wordt gestart. ELC-modellen worden getraind in het DEV-account en nadat het model is getraind en geëvalueerd, wordt het geregistreerd in het modelregister. Een modelgoedkeurder voert sanity checks uit voordat de modelstatus wordt bijgewerkt naar aangenomen. Deze actie genereert een gebeurtenis die de implementatie van de pijpleiding voor modeldeductie activeert. De model-inferentiepijplijn implementeert de nieuwe modelversie op een SageMaker-eindpunt in DEV.

Na de implementatie van het eindpunt worden tests gestart om het gedrag van de installatie te controleren. Voor testen gebruikt Yara CodeBuild-testrapporten. Met deze functie kunnen ontwikkelaars vóór en na de implementatie unittests, configuratietests en functionele tests uitvoeren. In dit geval voert Yara functionele tests uit door testpayloads door te geven aan SageMaker-eindpunten en de respons te evalueren. Nadat deze tests zijn geslaagd, gaat de pijplijn verder met het implementeren van de SageMaker-eindpunten voor TEST. De ELC-backend wordt ook ingezet op TEST, waardoor in deze omgeving end-to-end-testen voor de app mogelijk is. Daarnaast voert Yara gebruikersacceptatietesten uit in TEST. De trigger van TEST naar PROD-implementatie is een handmatige goedkeuringsactie. Nadat de nieuwe modelversie zowel functionele als gebruikersacceptatietests in TEST heeft doorstaan, keurt het technische team de modelimplementatie aan PROD goed.

De volgende afbeelding illustreert deze workflow.

Gemeenschappelijke componenten

Voor ELC gebruiken we verschillende componenten die gemeenschappelijk zijn voor alle implementatiestadia (DEV, TEST, PROD) en modellen. Deze componenten bevinden zich in ons implementatieaccount en omvatten modelversiebeheer, een opslagplaats voor containerafbeeldingen, een coderingssleutel en een bucket om algemene artefacten op te slaan.

Er zijn verschillende voordelen van het gebruik van gemeenschappelijke artefacten. De bronnen hoeven bijvoorbeeld niet voor elk account te worden gemaakt, waardoor compatibiliteit tussen de accounts wordt afgedwongen. Dat betekent dat we container-images één keer bouwen en deze hergebruiken in alle doelaccounts, waardoor de bouwtijd wordt verkort.

Deze pijplijn slaat de verschillende modelversies op in een gemeenschappelijk modelregister in het implementatieaccount. Vanaf deze centrale locatie kunnen modellen in alle accounts worden ingezet zonder deze over te zetten. Evenzo maakt het gebruik van een centraal opgeslagen coderingssleutel het gemakkelijker om de sleutel en machtigingen voor meerdere accounts te beheren.

Een nadeel van het gebruik van algemene artefacten is dat de onboarding-stap van een nieuwe use-case ingewikkelder kan worden. Om een ​​nieuwe use-case aan boord te krijgen, moet een nieuw modelregister worden gemaakt en, indien nodig, een nieuwe opslagplaats voor containerimages. We raden ook aan een nieuwe coderingssleutel te maken om bronnen en opgeslagen gegevens strikt te scheiden.

Conclusie

In dit bericht hebben we laten zien hoe Yara SageMaker en ADF gebruikte om een ​​zeer schaalbaar MLOps-platform te bouwen. ML is een cross-functionele mogelijkheid en teams implementeren modellen voor verschillende business unit-accounts. Daarom maakt ADF, dat native integratie met organisaties biedt, het een ideale kandidaat om accounts op te starten om CI/CD-pijplijnen op te zetten. Operationeel worden ADF-pijplijnen uitgevoerd in het centrale implementatieaccount, waardoor het eenvoudig is om een ​​algemeen overzicht van de status van implementaties te krijgen. Ten slotte maakt ADF gebruik van door AWS beheerde services zoals CodeBuild, CodeDeploy, CodePipeline en CloudFormation, waardoor het eenvoudig te configureren en te onderhouden is.

SageMaker biedt een breed spectrum aan ML-mogelijkheden, waardoor teams zich meer kunnen richten op het oplossen van zakelijke problemen en minder op het bouwen en onderhouden van infrastructuur. Bovendien biedt SageMaker Pipelines een uitgebreide set API's om ML-workflows te maken, bij te werken en te implementeren, waardoor het uitstekend geschikt is voor MLOps.

Ten slotte biedt MLOps de best practices om ML-modellen betrouwbaar en efficiënt in productie te nemen en te onderhouden. Het is van cruciaal belang voor teams die ML-oplossingen op schaal maken en implementeren om MLOps te implementeren. In het geval van Yara zorgt MLOps voor een aanzienlijke vermindering van de inspanning die nodig is om een ​​nieuwe fabriek aan boord te krijgen, updates voor ELC uit te rollen en ervoor te zorgen dat de kwaliteit van de modellen wordt gecontroleerd.

Voor meer informatie over het implementeren van applicaties met behulp van ADF, zie de voorbeelden.

---

Over de auteurs

Shaher Mansoor is een datawetenschapper bij AWS. Zijn focus ligt op het bouwen van platforms voor machine learning die AI-oplossingen op schaal kunnen hosten. Zijn interessegebieden zijn MLOps, feature stores, modelhosting en modelmonitoring.

Tim Becker is Senior Data Scientist bij Yara International. Binnen Digital Production ligt zijn focus op procesoptimalisatie van de productie van ammoniak en salpeterzuur. Hij is gepromoveerd in de thermodynamica en heeft een passie voor het samenbrengen van procestechniek en machine learning.

Yongyos Kaewpitakkun is een senior datawetenschapper in het Digital Production-team bij Yara International. Hij heeft een doctoraat in AI/machine learning en vele jaren praktijkervaring met het gebruik van machine learning, computervisie en natuurlijke taalverwerkingsmodellen om uitdagende zakelijke problemen op te lossen.