MLOps voor Python-modellen met behulp van Azure Machine Learning

Blob Storage
Container Registry
Azure DevOps
Machine Learning
Pipelines

Deze referentiearchitectuur laat zien hoe u continue integratie (CI), continue levering (CD) en hertrainingspijplijn implementeert voor een AI-toepassing met behulp van Azure DevOps en Azure Machine Learning. De oplossing is gebaseerd op de gegevensset scikit-learn diabetes, maar kan eenvoudig worden aangepast voor elk AI-scenario en andere populaire buildsystemen zoals Jenkins of Travis.

Een referentie-implementatie voor deze architectuur is beschikbaar op GitHub.

Architectuur

Diagram van de Machine Learning DevOps-architectuur.

Een Visio-bestand van deze architectuur downloaden.

Werkstroom

Deze architectuur bestaat uit de volgende services:

Azure Pipelines. Dit build- en testsysteem is gebaseerd op Azure DevOps en wordt gebruikt voor de build- en release-pijplijnen. Azure Pipelines splitst deze pijplijnen op in logische stappen die taken worden genoemd. De Azure CLI-taak maakt het bijvoorbeeld eenvoudiger om met Azure-resources te werken.

Azure Machine Learning is een cloudservice voor het trainen, scoren, implementeren en beheren van machine learning-modellen op schaal. Deze architectuur maakt gebruik van de Azure Machine Learning Python SDK voor het maken van een werkruimte, rekenresources, de machine learning-pijplijn en de score-installatiekopieën. Een Azure Machine Learning-werkruimte biedt de ruimte om machine learning-modellen te experimenteren, te trainen en te implementeren.

Azure Machine Learning Compute is een cluster van virtuele machines op aanvraag met automatisch schalen en OPTIES voor GPU- en CPU-knooppunten. De trainingstaak wordt uitgevoerd op dit cluster.

Azure Machine Learning-pijplijnen bieden herbruikbare machine learning-werkstromen die opnieuw kunnen worden gebruikt in scenario's. Training, modelevaluatie, modelregistratie en het maken van installatiekopieën vinden plaats in afzonderlijke stappen binnen deze pijplijnen voor deze use case. De pijplijn wordt gepubliceerd of bijgewerkt aan het einde van de buildfase en wordt geactiveerd wanneer er nieuwe gegevens binnenkomen.

Azure Blob Storage. Blobcontainers worden gebruikt voor het opslaan van de logboeken van de scoreservice. In dit geval worden zowel de invoergegevens als de modelvoorspelling verzameld. Na enige transformatie kunnen deze logboeken worden gebruikt voor het opnieuw trainen van modellen.

Azure Container Registry. Het scorende Python-script is verpakt als een Docker-installatiekopieën en versiebeheer in het register.

Azure Container Instances. Als onderdeel van de release-pijplijn wordt de QA- en faseringsomgeving nagebootst door de installatiekopieën van de scorewebservice te implementeren in Container Instances. Dit biedt een eenvoudige, serverloze manier om een container uit te voeren.

Azure Kubernetes Service. Zodra de scorewebservice-installatiekopie grondig is getest in de QA-omgeving, wordt deze geïmplementeerd in de productieomgeving in een beheerd Kubernetes-cluster.

Azure-toepassing Insights. Deze bewakingsservice wordt gebruikt om prestatieafwijkingen te detecteren.

MLOps-pijplijn

Deze oplossing demonstreert end-to-end automatisering van verschillende fasen van een AI-project met behulp van hulpprogramma's die al bekend zijn bij softwaretechnici. Het probleem met machine learning is eenvoudig om de focus op de DevOps-pijplijn te houden. De oplossing maakt gebruik van de gegevensset scikit-learn diabetes en bouwt een lineair regressiemodel om de kans op diabetes te voorspellen. Zie Training of Python scikit-learn models (Training of Python scikit-learn models ) voor meer informatie.

Deze oplossing is gebaseerd op de volgende drie pijplijnen:

  • Build-pijplijn. Hiermee bouwt u de code en voert u een reeks tests uit.
  • Pijplijn opnieuw trainen. Hiermee wordt het model opnieuw getraind volgens een schema of wanneer nieuwe gegevens beschikbaar komen.
  • Release-pijplijn. Hiermee wordt de score-afbeelding operationeel gemaakt en wordt deze veilig in verschillende omgevingen gepromoot.

In de volgende secties worden deze pijplijnen beschreven.

Build-pipeline

De CI-pijplijn wordt steeds geactiveerd wanneer de code wordt ingecheckt. Er wordt een bijgewerkte Azure Machine Learning-pijplijn gepubliceerd na het bouwen van de code en het uitvoeren van een reeks tests. De build-pijplijn bestaat uit de volgende taken:

  • Codekwaliteit. Deze tests zorgen ervoor dat de code voldoet aan de normen van het team.

  • Eenheidstest. Deze tests zorgen ervoor dat de code werkt, voldoende codedekking heeft en stabiel is.

  • Gegevenstest. Deze tests controleren of de gegevensvoorbeelden voldoen aan het verwachte schema en de verwachte distributie. Pas deze test aan voor andere use cases en voer deze uit als een afzonderlijke pijplijn voor gegevensbeveiliging die wordt geactiveerd wanneer er nieuwe gegevens binnenkomen. Verplaats bijvoorbeeld de gegevenstesttaak naar een pijplijn voor gegevensopname , zodat u deze eerder kunt testen.

Notitie

U kunt overwegen om DevOps-procedures in te schakelen voor de gegevens die worden gebruikt om de machine learning-modellen te trainen, maar dit wordt niet in dit artikel behandeld. Zie DevOps voor een pijplijn voor gegevensopname voor meer informatie over de architectuur en best practices voor CI/CD van een pijplijn voor gegevensopname.

De volgende eenmalige taken worden uitgevoerd bij het instellen van de infrastructuur voor Azure Machine Learning en de Python SDK:

  • Maak de werkruimte die als host fungeert voor alle Azure Machine Learning-gerelateerde resources.
  • Maak de rekenresources die de trainingstaak uitvoeren.
  • Maak de machine learning-pijplijn met het bijgewerkte trainingsscript.
  • Publiceer de machine learning-pijplijn als een REST-eindpunt om de trainingswerkstroom te organiseren. In de volgende sectie wordt deze stap beschreven.

Pijplijn opnieuw trainen

De machine learning-pijplijn organiseert het proces voor het opnieuw trainen van het model op een asynchrone manier. Opnieuw trainen kan worden geactiveerd volgens een planning of wanneer nieuwe gegevens beschikbaar komen door het gepubliceerde REST-eindpunt van de pijplijn uit de vorige stap aan te roepen.

Deze pijplijn omvat de volgende stappen:

  • Model trainen. Het Python-script voor de training wordt uitgevoerd op de Azure Machine Learning Compute-resource om een nieuw modelbestand op te halen dat wordt opgeslagen in de uitvoeringsgeschiedenis. Omdat training de meest rekenintensieve taak in een AI-project is, maakt de oplossing gebruik van Azure Machine Learning Compute.

  • Model evalueren. Een eenvoudige evaluatietest vergelijkt het nieuwe model met het bestaande model. Alleen wanneer het nieuwe model beter is, wordt het gepromoveerd. Anders wordt het model niet geregistreerd en wordt de pijplijn geannuleerd.

  • Model registreren. Het opnieuw getrainde model wordt geregistreerd bij het azure ML-modelregister. Deze service biedt versiebeheer voor de modellen, samen met metagegevenstags, zodat ze eenvoudig kunnen worden gereproduceerd.

Release-pijplijn

Deze pijplijn laat zien hoe u de score-installatiekopieën operationeel kunt maken en deze veilig kunt promoveren in verschillende omgevingen. Deze pijplijn is onderverdeeld in twee omgevingen, QA en productie:

QA-omgeving

  • Trigger modelartefact. Release-pijplijnen worden geactiveerd telkens wanneer er een nieuw artefact beschikbaar is. Een nieuw model dat is geregistreerd bij Azure Machine Learning Model Management, wordt behandeld als een release-artefact. In dit geval wordt een pijplijn geactiveerd voor elk nieuw model dat wordt geregistreerd.

  • Een scoreafbeelding maken. Het geregistreerde model wordt samen met een scorescript en Python-afhankelijkheden (Conda YAML-bestand) verpakt in een Docker-installatiekopieën voor operationalisatie. Er wordt automatisch versiebeheer uitgevoerd op de installatiekopie via Azure Container Registry.

  • Implementeren op Container Instances. Deze service wordt gebruikt om een niet-productieomgeving te maken. De score-installatiekopie wordt hier ook geïmplementeerd en deze wordt meestal gebruikt voor het testen. Container Instances biedt een eenvoudige en snelle manier om de Docker-installatiekopieën te testen.

  • Test webservice. Een eenvoudige API-test zorgt ervoor dat de installatiekopie is geïmplementeerd.

Productieomgeving

  • Implementeren op Azure Kubernetes Service. Deze service wordt gebruikt voor het implementeren van een score-installatiekopieën als een webservice op schaal in een productieomgeving.

  • Test webservice. Een eenvoudige API-test zorgt ervoor dat de installatiekopie is geïmplementeerd.

Overwegingen

Deze overwegingen implementeren de pijlers van het Azure Well-Architected Framework, een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Schaalbaarheid

Een build-pijplijn in Azure DevOps kan worden geschaald voor toepassingen van elke grootte. Build-pijplijnen hebben een maximale time-out die varieert, afhankelijk van de agent waarop ze worden uitgevoerd. Builds kunnen voor altijd worden uitgevoerd op zelf-hostende agents (privéagenten). Voor Microsoft-gehoste agents voor een openbaar project kunnen builds zes uur worden uitgevoerd. Voor privéprojecten is de limiet 30 minuten.

Als u de maximale time-out wilt gebruiken, stelt u de volgende eigenschap in het YAML-bestand van Azure Pipelines in:

jobs:
- job: <job_name>
  timeoutInMinutes: 0

In het ideale plaats kunt u uw build-pijplijn snel laten voltooien en alleen eenheidstests en een subset van andere tests uitvoeren. Hiermee kunt u de wijzigingen snel valideren en oplossen als er problemen optreden. Voer langdurige tests buiten kantooruren uit.

De release-pijplijn publiceert een realtime scorewebservice. Een release voor de QA-omgeving wordt voor het gemak uitgevoerd met behulp van Container Instances, maar u kunt een ander Kubernetes-cluster gebruiken dat wordt uitgevoerd in de QA-/faseringsomgeving.

Schaal de productieomgeving op basis van de grootte van uw Azure Kubernetes Service cluster. De grootte van het cluster is afhankelijk van de belasting die u verwacht voor de geïmplementeerde scorewebservice. Voor realtime scorearchitecturen is doorvoer een belangrijke metrische waarde voor optimalisatie. Voor niet-deep learning-scenario's moet de CPU voldoende zijn om de belasting te verwerken; Voor deep learning-workloads bieden GPU's echter, wanneer snelheid een knelpunt is, over het algemeen betere prestaties in vergelijking met CPU's. Azure Kubernetes Service ondersteunt zowel CPU- als GPU-knooppunttypen. Dit is de reden waarom deze oplossing het gebruikt voor de implementatie van installatiekopieën. Zie GPU's versus CPU's voor de implementatie van deep learning-modellen voor meer informatie.

Schaal de pijplijn voor opnieuw trainen omhoog en omlaag, afhankelijk van het aantal knooppunten in uw Azure Machine Learning Compute-resource en gebruik de optie voor automatisch schalen om het cluster te beheren. Deze architectuur maakt gebruik van CPU's. Voor deep learning-workloads zijn GPU's een betere keuze en worden ze ondersteund door Azure Machine Learning Compute.

Beheer

  • Hertrainingstaak bewaken. Machine learning-pijplijnen organiseren omscholing in een cluster van machines en bieden een eenvoudige manier om deze te bewaken. Gebruik de gebruikersinterface van Azure Machine Learning en zoek onder de sectie pijplijnen naar de logboeken. Als alternatief worden deze logboeken ook naar de blob geschreven en kunnen ze van daaruit worden gelezen met behulp van hulpprogramma's zoals Azure Storage Explorer.

  • Logboekregistratie. Azure Machine Learning biedt een eenvoudige manier om elke stap van de levenscyclus van machine learning te registreren. De logboeken worden opgeslagen in een blobcontainer. Zie Logboekregistratie inSchakelen in Azure Machine Learning voor meer informatie. Voor uitgebreidere bewaking configureert u Application Insights voor het gebruik van de logboeken.

  • Beveiliging. Alle geheimen en referenties worden opgeslagen in Azure Key Vault en geopend in Azure Pipelines met behulp van variabele groepen.

Kostenoptimalisatie

Kostenoptimalisatie gaat over het zoeken naar manieren om onnodige kosten te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.

Azure DevOps is gratis voor opensource-projecten en kleine projecten met maximaal vijf gebruikers. Voor grotere teams kunt u een abonnement aanschaffen op basis van het aantal gebruikers.

Compute is het grootste kostenstuurprogramma in deze architectuur en de kosten variëren afhankelijk van de use-case. Deze architectuur maakt gebruik van Azure Machine Learning Compute, maar er zijn andere opties beschikbaar. Azure Machine Learning voegt geen toeslag toe boven op de kosten van de virtuele machines die uw rekencluster back-up maken. Configureer uw rekencluster met minimaal 0 knooppunten, zodat het niet in gebruik kan worden geschaald tot 0 knooppunten zonder dat er kosten in rekening worden gebracht. De rekenkosten zijn afhankelijk van het knooppunttype, een aantal knooppunten en de inrichtingsmodus (lage prioriteit of toegewezen). U kunt de kosten voor Machine Learning en andere services schatten met behulp van de Azure-prijscalculator.

Dit scenario implementeren

Als u deze referentiearchitectuur wilt implementeren, volgt u de stappen die worden beschreven in de handleiding Aan de slag in de GitHub-opslagplaats.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen