Aangezien grote ondernemingen machine learning (ML) in hun hele organisatie omarmen, worden handmatige workflows voor het bouwen, trainen en implementeren van ML-modellen vaak knelpunten voor innovatie. Om dit te verhelpen, moeten ondernemingen een duidelijk bedrijfsmodel vormgeven dat definieert hoe meerdere persona's, zoals datawetenschappers, data-ingenieurs, ML-ingenieurs, IT en zakelijke belanghebbenden, moeten samenwerken en communiceren; hoe de zorgen, verantwoordelijkheden en vaardigheden te scheiden; en hoe u AWS-services optimaal kunt gebruiken. Deze combinatie van ML en operations (MLOps) helpt bedrijven hun end-to-end ML-levenscyclus te stroomlijnen en de productiviteit van datawetenschappers te verhogen, terwijl de hoge modelnauwkeurigheid behouden blijft en de beveiliging en compliance worden verbeterd.

In dit bericht leer je over de belangrijkste fasen van het bouwen van een MLOps-basis, hoe meerdere persona's samenwerken aan deze basis en de Amazon Sage Maker speciaal gebouwde tools en ingebouwde integraties met andere AWS-services die de acceptatie van ML in een onderneming kunnen versnellen.

MLOps-volwassenheidsmodel

Het is een uitdaging om een ​​MLOps-basis te bouwen die de activiteiten, mensen en technologiebehoeften van zakelijke klanten kan dekken. Daarom definiëren we het volgende volwassenheidsmodel dat de noodzakelijke mogelijkheden van MLOps definieert in vier belangrijke fasen.

1. Begin fase: Tijdens deze fase kunnen de datawetenschappers experimenteren en modellen bouwen, trainen en implementeren op AWS met behulp van SageMaker-services. De voorgestelde ontwikkelomgeving is: Amazon SageMaker Studio, waarin de datawetenschappers kunnen experimenteren en samenwerken op basis van Studio-notebooks.
2. Herhaalbare fase – Met de mogelijkheid om te experimenteren op AWS, is de volgende stap het creëren van automatische workflows om gegevens voor te verwerken en modellen te bouwen en te trainen (ML-pijplijnen). Datawetenschappers werken samen met ML-engineers in een aparte omgeving om robuuste en productieklare algoritmen en broncode te bouwen, georkestreerd met Amazon SageMaker-pijpleidingen. De gegenereerde modellen worden opgeslagen en gebenchmarkt in het Amazon SageMaker-modelregister.
3. Betrouwbare fase – Hoewel de modellen zijn gegenereerd via de ML-pijplijnen, moeten ze worden getest voordat ze worden gepromoveerd tot productie. Daarom wordt in deze fase de automatische testmethodologie geïntroduceerd, voor zowel het model als de triggerende infrastructuur, in een geïsoleerde staging (pre-productie) omgeving die de productie simuleert. Na een succesvolle uitvoering van de test worden de modellen ingezet in de geïsoleerde productieomgeving. Om de modellen onder de meerdere omgevingen te promoten, zijn handmatige evaluatie en goedkeuringen vereist.
4. Schaalbare fase – Na de productie van de eerste ML-oplossing is schaalvergroting van de MLOps-basis nodig om meerdere datawetenschapsteams te ondersteunen om samen te werken en tientallen of honderden ML-gebruikscasussen te produceren. In deze fase introduceren we de templatisatie van de oplossingen, wat snelheid naar waarde brengt door de ontwikkeltijd van nieuwe productieoplossingen te verkorten van weken naar dagen. Daarnaast automatiseren we het opzetten van veilige MLOps-omgevingen zodat meerdere teams kunnen werken met hun gegevens, waardoor de afhankelijkheid en overhead voor IT wordt verminderd.

In de volgende secties laten we zien hoe u een MLOps-basis bouwt op basis van het voorgaande volwassenheidsmodel en de volgende principes:

• Flexibiliteit – Datawetenschappers kunnen elk raamwerk accommoderen (zoals TensorFlow of PyTorch)
• reproduceerbaarheid – Datawetenschappers kunnen eerdere experimenten (code, data en resultaten) nabootsen of observeren
• herbruikbaarheid – Datawetenschappers en ML-ingenieurs kunnen broncode en ML-pijplijnen hergebruiken, waardoor inconsistenties en kosten worden vermeden
• Schaalbaarheid – Datawetenschappers en ML-engineers kunnen resources en services op aanvraag schalen
• controleerbaarheid – Gegevenswetenschappers, IT en juridische afdelingen kunnen logboeken, versies en afhankelijkheden van artefacten en gegevens controleren
• Consistentie – Omdat MLOps uit meerdere omgevingen bestaat, moet de basis verschillen tussen omgevingen elimineren

Begin fase

In de beginfase is het doel om een ​​veilige experimenteeromgeving te creëren waarin de datawetenschapper snapshots van gegevens en experimenten ontvangt met behulp van SageMaker-notebooks om te bewijzen dat ML een specifiek zakelijk probleem kan oplossen. Om dit te bereiken wordt een Studio-omgeving aanbevolen met toegang op maat tot services via VPC-endpoints. De broncode van de referentie-architectuur is beschikbaar in de voorbeelden van het SageMaker-team op de Beveilig datawetenschap met Amazon SageMaker Studio Reference Architecture GitHub-opslagplaats.

Naast SageMaker-services kunnen datawetenschappers andere services gebruiken om de gegevens te verwerken, zoals: Amazon EMR, Amazone Athene en AWS lijm, met notebooks opgeslagen en geversied in AWS Codecommit opslagplaatsen (zie de volgende afbeelding).

Herhaalbare fase

Nadat de datawetenschappers hebben bewezen dat ML het bedrijfsprobleem kan oplossen en bekend zijn met SageMaker-experimenten, training en implementatie van modellen, is de volgende stap om de ML-oplossing in productie te nemen. De volgende afbeelding illustreert deze architectuur.

In dit stadium is scheiding van zorg noodzakelijk. We splitsen de omgeving op in meerdere AWS-accounts:

1. Datameer – Slaat alle opgenomen gegevens van on-premises (of andere systemen) op in de cloud. Data-engineers kunnen ETL-pijplijnen (extract, transform en load) maken door meerdere gegevensbronnen te combineren en de benodigde datasets voor de ML-gebruiksscenario's voor te bereiden. De gegevens worden gecatalogiseerd via de AWS Glue Data Catalog en gedeeld met andere gebruikers en accounts via AWS Lake-formatie (de data governance-laag). Op dezelfde rekening, Amazon SageMaker Feature Store kan worden gehost, maar we behandelen het niet in dit bericht. Voor meer informatie, zie: Schakel het hergebruik van functies in verschillende accounts en teams in met Amazon SageMaker Feature Store.
2. proefneming – Stelt datawetenschappers in staat hun onderzoek uit te voeren. Het enige verschil is dat de oorsprong van de data snapshots het data lake is. Datawetenschappers hebben alleen toegang tot specifieke datasets, die kunnen worden geanonimiseerd in het geval van AVG of andere gegevensprivacybeperkingen. Bovendien heeft het experimentaccount mogelijk toegang tot internet om datawetenschappers in staat te stellen nieuwe datawetenschapskaders of open-sourcebibliotheken van derden te gebruiken. Daarom wordt het experimentaccount beschouwd als onderdeel van de niet-productieomgeving.
3. Ontwikkeling (ontwikkelaar) – De eerste fase van de productieomgeving. De datawetenschappers stappen van notebooks naar de wereld van automatische workflows en SageMaker Pipelines. Ze moeten samenwerken met ML-ingenieurs om hun code te abstraheren en te zorgen voor dekking van testen, foutafhandeling en codekwaliteit. Het doel is om ML-pijplijnen te ontwikkelen, dit zijn automatische workflows die modellen voorbewerken, trainen, evalueren en registreren in het SageMaker-modelregister. De inzet van de ML-pijplijnen wordt alleen aangestuurd via CI/CD-pijplijnen en de toegang tot de AWS-beheerconsole is beperkt. Internetverbinding is niet toegestaan ​​omdat de ML-pijplijn toegang heeft tot productiegegevens in het datameer (alleen-lezen).
4. Tooling (of automatisering) – Host de CodeCommit-repositories, AWS CodePipeline CI/CD-pijplijnen, SageMaker-modelregister en Amazon ECR om aangepaste containers te hosten. Omdat het datameer het enige waarheidspunt voor de gegevens is, is het tooling-account voor de code, containers en geproduceerde artefacten.

Houd er rekening mee dat deze naamgevingsconventie voor accounts en de strategie voor meerdere accounts kunnen variëren, afhankelijk van uw zakelijke behoeften, maar deze structuur is bedoeld om de aanbevolen isolatieniveaus weer te geven. U kunt bijvoorbeeld het ontwikkelaccount hernoemen naar het modeltraining- of buildaccount.

Om automatische implementatie te bereiken, is het belangrijk om te begrijpen hoe u van notebooks naar ML-pijplijnen kunt gaan en de code-opslagplaatsen en gegevensstructuur kunt standaardiseren, die we in de volgende secties bespreken.

Van notebooks tot ML-pipelines

Het doel van de ontwikkelomgeving is om de code in notebooks te herstructureren, aan te vullen, te verbeteren en te schalen en deze naar de ML-pipelines te verplaatsen. Een ML-pijplijn is een reeks stappen die verantwoordelijk zijn voor het voorbewerken van de gegevens, het trainen of gebruiken van modellen en het nabewerken van de resultaten. Elke stap moet precies één taak uitvoeren (een specifieke transformatie) en abstract genoeg zijn (bijvoorbeeld kolomnamen doorgeven als invoerparameters) om herbruikbaarheid mogelijk te maken. In het volgende diagram ziet u een voorbeeld van een pijplijn.

Om ML-pijplijnen te implementeren, gebruiken datawetenschappers (of ML-ingenieurs) SageMaker-pijplijnen. Een SageMaker-pijplijn is een reeks onderling verbonden stappen (SageMaker-verwerkingstaken, training, HPO) die wordt gedefinieerd door een JSON-pijplijndefinitie met behulp van een Python SDK. Deze pijplijndefinitie codeert een pijplijn met behulp van een Directed Acyclic Graph (DAG). Deze DAG geeft informatie over de vereisten voor en relaties tussen elke stap van uw ML-pijplijn.

Afhankelijk van de gebruikssituatie kunt u de ML-pijplijn opsplitsen in twee hoofdtypen: training en batchinferentie.

De volgende afbeelding illustreert de training ML-pijplijnstroom.

De voorbewerkingsfase kan uit meerdere stappen bestaan. Veelvoorkomende datawetenschapstransformaties zijn het splitsen en bemonsteren van gegevens (trein, validatie, testset), one-hot codering of vectorisatie, binning en schalen. De modeltrainingsstap kan ofwel één trainingstaak zijn, als de datawetenschapper op de hoogte is van de beste modelconfiguratie, of een hyperparameteroptimalisatietaak (HPO), waarin AWS de beste hyperparameters voor het model definieert (Bayesiaanse methode) en de bijbehorende model artefact. In de evaluatiestap wordt het geproduceerde modelartefact gebruikt om gevolgtrekkingen uit te voeren naar de validatiegegevensset. Vervolgens controleert de ML-pijplijn of de geproduceerde nauwkeurigheidsmetrieken (zoals F1, precisie en versterkingsdecielen) de noodzakelijke drempels overschrijden. Als deze stap succesvol is, worden de modelartefacten en metagegevens verplaatst naar het modelregister voor productie. Merk op dat de export baseline step exploits Amazon SageMaker-modelmonitor functionaliteit, het produceren van een JSON-object met de statistieken die later worden gebruikt voor detectie van modelafwijkingen en die als modelmetadata kunnen worden gehost in het SageMaker-modelregister.

In het geval van batchinferentie kunnen de datawetenschappers vergelijkbare pijplijnen maken, zoals geïllustreerd in de volgende afbeelding.

De voorbewerkingsstap van batchinferentie is vaak hetzelfde als training door gegevensbemonstering en de kolom met grondwaarheid uit te sluiten. Batch-inferentie is de stap die gegevens in batches verzendt voor gevolgtrekking naar het corresponderende eindpunt, en kan worden geïmplementeerd met behulp van batch-transformatie. De nabewerkingsstap produceert aanvullende statistieken, zoals de distributie van resultaten, of voegt de resultaten samen met externe ID's. Vervolgens kan een modelmonitorstap de basislijnstatistieken van de gegevens die voor training worden gebruikt (model-JSON-metagegevens in het modelregister) vergelijken met de nieuwe binnenkomende gegevens voor gevolgtrekking.

U kunt de voorbewerkingsstappen overslaan als de gegevenswetenschappers pijplijnmodellen maken die kunnen worden opgeslagen in het SageMaker-modelregister. Voor meer details, zie: Hostmodellen samen met voorverwerkingslogica als seriële inferentiepijplijn achter één eindpunt.

Repository's standaardiseren

Om de samenwerking tussen datawetenschappers en ML-engineers mogelijk te maken, is standaardisatie van de coderepository-structuur noodzakelijk. Bovendien is standaardisatie gunstig voor de CI/CD-pijplijnstructuur, omdat het de integratie van automatische validatie-, bouw- (zoals aangepaste containerbouw) en teststappen mogelijk maakt.

Het volgende voorbeeld illustreert de scheiding van de ML-oplossingen in twee opslagplaatsen: een bouw- en trainingsopslag voor training (en optioneel een pijplijnmodel) en implementatie om de pijplijnmodellen voor batchinferentie te promoten of de realtime eindpunten te instantiëren:

Repository bouwen/trainen

# Building/Training Repository
algorithms/
    shared_libraries/
        test/
            input/ # (optional)
            output/ # (optional)
            test_<step>.py
        <help_functions1>.py
        <help_functions2>.py
        README.md
    preprocessing/ # 1 folder per pre-processing job, order is defined in the ml pipeline logic
        <preprocessing_job_name1> # e.g classic ml: one hot encoding
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
            __main__.py
            dockerfile # (optional) define dockerfile in case of custom containers
            README.md
       <preprocessing_job_name2> # e.g classic ml: one hot encoding
        ...
    training/ # (optional) each one is a training job in SageMaker
        <training_job_name>/
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
            __main__.py
            README.md
    inference/ # (optional) for batch inference
        <batch_inference_job_name>/ # one job per training job name if we're building multiple models
            __main__.py
            README.md
    postprocessing/ # each one is a processing job in SageMaker
        <postprocessing_job_name1>/
            test/
                input/ # (optional)
                output/ # (optional)
                test_<step>.py
           __main__.py
            README.md
        <postprocessing_job_name2>/
        ...
ml_pipelines/
    training/ # (note) Multiple training ML pipelines can be defined
        ml-pipeline-training.py # Define training ML pipelines using SageMaker Pipeline SDK
        input.json # (optinal - json or yaml) ML pipeline configuration to enable reusability
    README.md
notebooks/
    *.ipynb # the original notebooks as has been created by the data scientists
    README.md
build_spec.yml
README.md

Opslagplaats voor implementatie

# Deployment Repository
inference_config/
    staging/
        inference_config.json # Batch inference ML pipeline or real-time model endpoint configuration to enable reusability
    prod/
        inference_config.json # Batch inference ML pipeline or real-time model endpoint configuration to enable reusability
    README.md
app_infra/
    api_gateway/...
    lambda/...
    event_bridge/...
    batch_inference/ml-pipeline-inference.py # Define batch inference SageMaker Pipeline
tests/
    integration_test/
        test_<description>.py
        test_<description>.py
        # …
    stress_test/
        test_<description>.py
    other_test/
        test_<description>.py
    README.md
README.md

De gebouwen- en trainingsrepository is onderverdeeld in drie hoofdmappen:

• Algoritmen – Datawetenschappers ontwikkelen de code voor elke stap van de ML-pijplijnen in de hoofdmap van de algoritmen. De stappen kunnen worden gegroepeerd in preprocessing, training, batchinferentie en postprocessing (evaluatie). In elke groep kunnen meerdere stappen worden gedefinieerd in bijbehorende submappen, die een map bevatten voor de unit-tests (inclusief optionele inputs en outputs), de hoofdfuncties, het leesmij-bestand en een Docker-bestand in geval van een aangepaste containerbehoefte. Naast de hoofdmap kunnen meerdere codebestanden in dezelfde map worden gehost. Gemeenschappelijke helperbibliotheken voor alle stappen kunnen worden gehost in een gedeelde bibliotheekmap. De datawetenschappers zijn verantwoordelijk voor de ontwikkeling van de unittests omdat zij eigenaar zijn van de logica van de stappen, en ML-engineers zijn verantwoordelijk voor de verbetering van de foutafhandeling en de aanbeveling voor testdekking. De CI/CD-pijplijn is verantwoordelijk voor het uitvoeren van de tests, het automatisch bouwen van de containers (indien nodig) en het verpakken van de meerdere broncodebestanden.
• ML-pijplijnen – Nadat u de broncode en tests van elke stap hebt ontwikkeld, is de volgende stap het definiëren van de SageMaker-pijplijnen in een andere hoofdmap. Elke ML-pijplijndefinitie wordt in een submap geplaatst die het .py-bestand en een JSON- of .yaml-bestand bevat voor invoerparameters, zoals hyperparameterbereiken. Er is een leesmij-bestand nodig om de ML-pijplijnen te beschrijven.
• Notitieboekjes – Deze map bevat de oorspronkelijke notitieboeken die de datawetenschapper tijdens het experimenteren heeft gebruikt.

De implementatierepository bestaat uit drie hoofdonderdelen:

• Inferentieconfiguratie – Bevat de configuratie van realtime endpoints of batch-inferentie per ontwikkelomgeving, zoals instancetypes.
• Applicatie-infrastructuur – Host de broncode van de infrastructuur die nodig is om de inferentie uit te voeren, indien nodig. Dit kan een triggermechanisme zijn via Amazon EventBridge, Amazon API-gateway, AWS Lambda functies of SageMaker-pijplijnen.
• Tests – Bestaat uit meerdere submappen, afhankelijk van de testmethode van de klant. Als de minimale set tests raden we een integratietest aan (end-to-end-run van de inferentie inclusief applicatie-infrastructuur), stresstest (randgevallen onderzoeken) en ML-tests (zoals de verdeling van betrouwbaarheidsscores of waarschijnlijkheden).

Door wijzigingen door te voeren in de bouw- en trainingsrepository, is een CI/CD-pipeline verantwoordelijk voor het valideren van de repositorystructuur, het uitvoeren van de tests en het implementeren en uitvoeren van de ML-pipelines. Een andere CI/CD-pijplijn is verantwoordelijk voor het promoten van de modellen, die we in de volgende sectie onderzoeken.

Standaardiseren van repository-vertakkingen en CI/CD

Om de robuustheid van de ML-pijplijnen in het dev-account te garanderen, wordt een strategie voor opslag met meerdere vertakkingen voorgesteld, terwijl de implementatie alleen via CI/CD-pijplijnen wordt uitgevoerd. Datawetenschappers zouden een feature branch moeten gebruiken om hun nieuwe functionaliteit (broncode) te ontwikkelen. Wanneer ze klaar zijn om de bijbehorende ML-pijplijnen te implementeren, kunnen ze dit naar de ontwikkeltak pushen. Een alternatief voor deze benadering is om de inzet van ML-pijplijnen per functietak toe te staan. Voor meer informatie, zie: Verbeter uw data science-workflow met een multi-branch training MLOps-pijplijn met behulp van AWS.

De volgende afbeelding illustreert de vertakkingsstrategie en de noodzakelijke CI/CD-pijplijnstappen die we uitvoeren in de ontwikkelomgeving voor ML-pijplijn en modelbouw.

Het codevoorbeeld van de multi-branch-aanpak is beschikbaar in: Multi-Branch MLOps-trainingspijplijn. We kunnen de modellen die zijn geproduceerd door een op feature-branch gebaseerde ML-pipeline in een aparte featuremodelgroep opslaan en ze buiten gebruik stellen tijdens een samenvoegverzoek met de hoofdtak. De modellen in de hoofdmodelgroep zijn degenen die tot productie worden gepromoveerd.

Standaardiseren van datastructuur

Even belangrijk voor broncodestandaardisatie is de structuurstandaardisatie van de gegevens, waardoor datawetenschappers en ML-ingenieurs de oorsprong en geschiedenis van de modellen en ML-pijplijnen kunnen debuggen, controleren en bewaken. Het volgende diagram illustreert een dergelijk voorbeeld.

Laten we voor de eenvoud aannemen dat de ingevoerde historische gegevens in een emmer van het ontwikkelaccount onder de invoersubsleutel terechtkomen (normaal bevindt deze zich in het datameer). Voor elke ML-use case moet een aparte subsleutel worden gemaakt. Om een ​​nieuwe ML-pijplijn te activeren, moet de datawetenschapper een git-commit en push uitvoeren, waardoor de CI/CD-pijplijn wordt geactiveerd. Vervolgens maakt de CI/CD-pijplijn een subsleutel door de codeartefacten te kopiëren (de code subsleutel) en invoergegevens (de input subsleutel) onder een subpartitie van de build-ID. Als voorbeeld, de build-ID ceen combinatie zijn van datum-tijd en git hash, of een SageMaker-pijplijnuitvoerings-ID. Met deze structuur kan de datawetenschapper eerdere implementaties en uitvoeringen controleren en opvragen. Hierna implementeert en activeert de CI/CD-pijplijn de ML-pijplijn. Terwijl de ML-pijplijn actief is, exporteert elke stap de tussenresultaten naar: ml-pipeline-outputs. Het is belangrijk om te onthouden dat verschillende functietakken een nieuwe instantie van de ML-pijplijn implementeren en uitvoeren en dat elk de tussenresultaten naar een andere submap moet exporteren met een nieuwe subsleutel en/of een gestandaardiseerd voor- of achtervoegsel dat de kenmerk branch-ID.

Deze aanpak ondersteunt volledige controleerbaarheid van elk experiment. De multi-branching-benadering van de ontwikkelingsstrategie genereert echter een grote hoeveelheid gegevens. Daarom is een data lifecycle-strategie noodzakelijk. We raden u aan ten minste de gegevens van elke feature branch ML-pijplijn te verwijderen in elk succesvol pull/merge-verzoek. Maar dit hangt af van het bedrijfsmodel en de mate van controle die uw bedrijf moet ondersteunen. U kunt een vergelijkbare benadering gebruiken in de batch-inferentie ML-pijplijnen

Betrouwbare fase

Na de eerste scheiding van zorgen tussen datawetenschappers, ML-engineers en data-engineers door meerdere accounts te gebruiken, is de volgende stap het promoten van de geproduceerde modellen van het modelregister naar een geïsoleerde omgeving om gevolgtrekkingen uit te voeren. We moeten echter zorgen voor de robuustheid van de ingezette modellen. Daarom is een simulatie van het ingezette model naar een spiegelomgeving van productie verplicht, namelijk pre-productie (of staging).

De volgende afbeelding illustreert deze architectuur.

De promotie van een model- en eindpuntimplementatie in de pre-productieomgeving wordt uitgevoerd met behulp van de statusupdategebeurtenissen van het modelregister (of git push op de implementatierepository), die een afzonderlijke CI/CD-pijplijn activeert met behulp van EventBridge-gebeurtenissen. De eerste stap van de CI/CD-pijplijn vraagt ​​om handmatige goedkeuring door de hoofdgegevenswetenschapper (en optioneel de producteigenaar, bedrijfsanalist of andere hoofdgegevenswetenschappers). De goedkeurder moet de prestatie-KPI's van het model en QA van de code in de implementatierepository valideren. Na goedkeuring voert de CI/CD-pipeline de testcode uit naar de deployment-repository (integratietest, stresstest, ML-test). Naast het modeleindpunt test de CI/CD ook de triggerende infrastructuur, zoals EventBridge, Lambda-functies of API Gateway. Het volgende diagram toont deze bijgewerkte architectuur.

Nadat de tests met succes zijn uitgevoerd, laat de CI/CD-pijplijn de nieuwe (of dezelfde) goedkeurders weten dat een model klaar is om naar productie te worden gepromoveerd. In dit stadium wil de bedrijfsanalist misschien wat aanvullende statistische hypothesetests uitvoeren op de resultaten van het model. Na goedkeuring worden de modellen en de triggerende infrastructuur in productie genomen. Meerdere implementatiemethoden worden ondersteund door SageMaker, zoals blauw/groen, Canary en A/B-testen (zie meer in Inzet vangrails). Als de CI/CD-pijplijn faalt, keert een terugdraaimechanisme het systeem terug naar de laatste robuuste staat.

Het volgende diagram illustreert de belangrijkste stappen van de CI/CD-pijplijn om een ​​model en de infrastructuur te promoten om het modeleindpunt te activeren, zoals API Gateway, Lambda-functies en EventBridge.

Data lake en MLOps-integratie

Op dit moment is het belangrijk om de gegevensvereisten per ontwikkelingsfase of account te begrijpen, en de manier om MLOps te integreren met een gecentraliseerd datameer. Het volgende diagram illustreert de MLOps- en data lake-lagen.

In het datameer zijn de data-ingenieurs verantwoordelijk voor het samenvoegen van meerdere gegevensbronnen en het maken van de bijbehorende datasets (bijvoorbeeld een enkele tabel met de structuurgegevens of een enkele map met PDF-bestanden of afbeeldingen) voor de ML-gebruiksscenario's door ETL te bouwen pijpleidingen zoals gedefinieerd door de datawetenschappers (tijdens de fase van de exploratiedata-analyse). Die datasets kunnen worden opgesplitst in historische gegevens en gegevens voor gevolgtrekking en testen. Alle gegevens worden gecatalogiseerd (bijvoorbeeld met de AWS Glue Data Catalog) en kunnen worden gedeeld met andere accounts en gebruikers door Lake Formation te gebruiken als een gegevensbeheerlaag (voor gestructureerde gegevens). Op het moment van schrijven is Lake Formation alleen compatibel met Athena-query's, AWS Glue-taken en Amazon EMR.

Aan de andere kant moet de MLOps-omgeving de ML-pijplijnen irrigeren met specifieke datasets die zich in lokale buckets in dev, pre-prod en prod bevinden. De ontwikkelomgeving is verantwoordelijk voor het bouwen en trainen van de modellen op aanvraag met behulp van SageMaker-pijplijnen die gegevens uit het datameer halen. Daarom raden we als eerste stap van de pijplijn aan om ofwel een Athena-stap te hebben, waarbij alleen gegevensmonsters en query's nodig zijn, of een Amazon EMR-stap, als complexere transformaties vereist zijn. Als alternatief kunt u een AWS Glue-taak gebruiken via een callback-stap, maar nog niet als een native stap met SageMaker Pipelines.

Pre-prod en prod zijn verantwoordelijk voor het testen of het uitvoeren van real-time en batch-inferentie. In het geval van realtime inferentie is het niet nodig om gegevens naar de MLOps pre-prod- en prod-accounts te verzenden, omdat de invoer voor inferentie kan meeliften op de payload van het API Gateway-verzoek. In het geval van batchinferentie (of grootschalige invoergegevens), moeten de benodigde datasets, ofwel testdata ofwel data voor inferentie, in de lokale ML-databuckets terechtkomen (pre-prod of prod). U hebt twee opties om gegevens naar pre-prod en prod te verplaatsen: ofwel door Athena of Amazon EMR te activeren en gegevens uit het datameer te halen, of door gegevens van het datameer naar die MLOps-accounts te pushen. De eerste optie vereist de ontwikkeling van aanvullende mechanismen in de MLOps-accounts, bijvoorbeeld het creëren van geplande EventBridge-gebeurtenissen (zonder te weten of de gegevens in het datameer zijn bijgewerkt) of on-data aankomst in S3 EventBridge-gebeurtenissen in het datameer (voor meer details, zie Toegang tussen verschillende accounts vereenvoudigen met het resourcebeleid van Amazon EventBridge). Nadat de gebeurtenis aan de MLOps-kant is opgevangen, kan een Athena-query of Amazon EMR gegevens lokaal ophalen en activeren asynchrone gevolgtrekking or batch-transformatie. Dit kan voor de eenvoud in een SageMaker-pijplijn worden verpakt. De tweede optie is om in de laatste stap van de ETL-pijplijn de functionaliteit van het pushen van gegevens naar de MLOps-buckets toe te voegen. Deze benadering vermengt echter de verantwoordelijkheden (het data lake triggert inferentie) en vereist dat Lake Formation toegang geeft tot het data lake om in de MLOps-buckets te schrijven.

De laatste stap is om de inferentieresultaten terug naar het datameer te verplaatsen. Om de gegevens te catalogiseren en beschikbaar te maken voor andere gebruikers, moeten de gegevens als een nieuwe gegevensbron terugkeren naar de landingsbucket.

Schaalbare fase

Na de ontwikkeling van de MLOps-basis en de end-to-end-productie van de eerste ML-use case, zijn de infrastructuur van dev, pre-prod, prod en de repository, CI/CD-pipeline en datastructuur getest en afgerond . De volgende stap is om nieuwe ML-use cases en teams aan het platform toe te voegen. Om snelheid-naar-waarde te garanderen, kunt u met SageMaker aangepaste SageMaker-projectsjablonen maken, die u kunt gebruiken om sjabloonopslagplaatsen en CI/CD-pijplijnen automatisch te instantiëren. Met dergelijke SageMaker-projectsjablonen zijn de leidende datawetenschappers verantwoordelijk voor het starten van nieuwe projecten en het toewijzen van een toegewijd team per nieuwe ML-use-cases.

Het volgende diagram illustreert dit proces.

Het probleem wordt complexer als verschillende datawetenschapper-teams (of meerdere bedrijfseenheden die ML moeten produceren) toegang hebben tot verschillende vertrouwelijke gegevens, en meerdere producteigenaren verantwoordelijk zijn voor het betalen van een aparte rekening voor de training, implementatie en uitvoering van de modellen . Daarom is per team een ​​aparte set MLOps-accounts (experiment, dev, pre-prod en prod) nodig. Om het gemakkelijk maken van nieuwe MLOps-accounts mogelijk te maken, introduceren we een ander account, het geavanceerde analytics-governanceaccount, dat toegankelijk is voor IT-leden en hen in staat stelt om MLOps-accounts op aanvraag te catalogiseren, instantiëren of buiten gebruik te stellen. Dit account host met name repositories met de infrastructuurcode van de MLOps-accounts (VPC, subnetten, eindpunten, buckets, AWS Identiteits- en toegangsbeheer (IAM) rollen en beleid, AWS CloudFormatie stapels), en AWS-servicecatalogus product om de CloudFormation-stacks van de infrastructuur met één klik automatisch te implementeren op de meerdere accounts, en een Amazon DynamoDB tabel om metadata te catalogiseren, zoals welk team verantwoordelijk is voor elke set accounts. Met deze mogelijkheid kan het IT-team MLOps-accounts on-demand instantiëren en de benodigde gebruikers, gegevenstoegang per account en consistente beveiligingsbeperkingen toewijzen.

Op basis van dit scenario scheiden we de rekeningen naar kortstondig en duurzaam. Data lake en tooling zijn duurzame accounts en spelen de rol van een enkel punt van waarheid voor respectievelijk de gegevens en de broncode. MLOps-accounts zijn meestal staatloos en worden op verzoek geïnstantieerd of buiten gebruik gesteld, waardoor ze kortstondig zijn. Zelfs als een set MLOps-accounts buiten gebruik wordt gesteld, kunnen de gebruikers of auditors eerdere experimenten en resultaten controleren omdat ze zijn opgeslagen in de duurzame omgevingen.

Als u Studio UI voor MLOps wilt gebruiken, maakt het tooling-account deel uit van het dev-account, zoals in de volgende afbeelding.

Als de gebruiker Sagemaker Studio UI voor MLOps wil gebruiken, maakt het tooling-account deel uit van de dev
rekening volgens de bovenstaande afbeelding. Voorbeeld broncode van deze stichting MLOPs is te vinden in:
Veilige MLOps-basis voor meerdere accounts op basis van CDK.

Merk op dat Sagemaker de mogelijkheid biedt om CodeCommit en CodePipeline te vervangen door andere ontwikkelingstools van derden, zoals GitHub en Jenkins (meer details zijn te vinden in Amazon SageMaker-projecten maken met behulp van bronbeheer van derden en Jenkins en Amazon SageMaker projecteert MLOps Sjabloon met GitLab- en GitLab-pijplijnen).

Persona's, operaties en technologieoverzicht

Met het MLOps-volwassenheidsmodel kunnen we een duidelijk architectuurontwerp en een roadmap voor levering definiëren. Elke persona moet echter een duidelijk beeld hebben van de belangrijkste AWS-accounts en -services om mee te communiceren en de activiteiten die moeten worden uitgevoerd. Het volgende diagram vat deze categorieën samen.

Conclusie

Een robuuste MLOps-basis, die de interactie tussen meerdere persona's en technologie duidelijk definieert, kan de snelheid naar waarde verhogen en de kosten verlagen, en datawetenschappers in staat stellen zich te concentreren op innovaties. In dit bericht hebben we laten zien hoe je een dergelijke basis in fasen kunt bouwen, wat leidt tot een soepel MLOps-volwassenheidsmodel voor het bedrijf en de mogelijkheid om meerdere datawetenschapsteams en ML-use-cases in productie te ondersteunen. We hebben een operationeel model gedefinieerd dat bestaat uit meerdere persona's met meerdere vaardigheden en verantwoordelijkheden. Tot slot hebben we voorbeelden gedeeld van hoe de code-ontwikkeling (repositories en CI/CD-pipelines), gegevensopslag en -deling en MLOps-beveiligde infrastructuurvoorzieningen voor bedrijfsomgevingen kunnen worden gestandaardiseerd. Veel zakelijke klanten hebben deze aanpak overgenomen en zijn in staat om hun ML-oplossingen binnen enkele dagen in plaats van maanden te produceren.

Als u opmerkingen of vragen heeft, laat deze dan achter in het opmerkingengedeelte.

Over de auteur

Dr Sokratis Kartakis is een Senior Machine Learning Specialist Solutions Architect voor Amazon Web Services. Sokratis richt zich op het in staat stellen van zakelijke klanten om hun Machine Learning (ML)-oplossingen te industrialiseren door gebruik te maken van AWS-services en het vormgeven van hun bedrijfsmodel, dat wil zeggen de MLOps-basis, en transformatie-roadmap door gebruik te maken van de beste ontwikkelingspraktijken. Hij heeft meer dan 15 jaar besteed aan het uitvinden, ontwerpen, leiden en implementeren van innovatieve end-to-end ML- en Internet of Things (IoT)-oplossingen op productieniveau in de domeinen energie, detailhandel, gezondheid, financiën/bankieren, motorsport enz. Sokratis brengt zijn vrije tijd graag door met familie en vrienden, of motorrijden.

Georgios Schinas is Specialist Solutions Architect voor AI/ML in de EMEA-regio. Hij is gevestigd in Londen en werkt nauw samen met klanten in het VK en Ierland. Georgios helpt klanten bij het ontwerpen en implementeren van machine learning-applicaties in productie op AWS met een bijzondere interesse in MLOps-praktijken en om klanten in staat te stellen machine learning op grote schaal uit te voeren. In zijn vrije tijd houdt hij van reizen, koken en tijd doorbrengen met vrienden en familie.

Giuseppe Angelo Porcelli is een Principal Machine Learning Specialist Solutions Architect voor Amazon Web Services. Met meerdere jaren software-engineering en ML-achtergrond, werkt hij met klanten van elke omvang om hun zakelijke en technische behoeften grondig te begrijpen en AI- en Machine Learning-oplossingen te ontwerpen die optimaal gebruik maken van de AWS Cloud en de Amazon Machine Learning-stack. Hij heeft gewerkt aan projecten in verschillende domeinen, waaronder MLOps, Computer Vision, NLP, en met een breed scala aan AWS-services. In zijn vrije tijd voetbalt Giuseppe graag.

Shelbee Eigenbrode is een Principal AI en Machine Learning Specialist Solutions Architect bij Amazon Web Services (AWS). Ze is al 24 jaar actief in de technologie, verspreid over meerdere sectoren, technologieën en functies. Ze concentreert zich momenteel op het combineren van haar DevOps- en ML-achtergrond in het domein van MLOps om klanten te helpen ML-workloads op grote schaal te leveren en te beheren. Met meer dan 35 verleende patenten in verschillende technologiedomeinen, heeft ze een passie voor continue innovatie en het gebruik van data om bedrijfsresultaten te stimuleren. Shelbee is co-creator en docent van de specialisatie Praktische Data Science op Coursera. Ze is ook co-directeur van Women In Big Data (WiBD), afdeling Denver. In haar vrije tijd brengt ze graag tijd door met haar familie, vrienden en overactieve honden.