Deze referentiearchitectuur laat zien hoe u continue integratie (CI), continue levering (CD) en hertrainingspijplijn voor een AI-toepassing implementeert met behulp van Azure DevOps en Azure Machine Learning. De oplossing is gebaseerd op de gegevensset voor 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
Een Visio-bestand van deze architectuur downloaden.
Workflow
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 breekt deze pijplijnen op in logische stappen die taken worden genoemd. Met de Azure CLI-taak kunt u bijvoorbeeld eenvoudiger met Azure-resources 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 om een werkruimte, rekenresources, de machine learning-pijplijn en de score-installatiekopieën te maken. Een Azure Machine Learning-werkruimte biedt de ruimte waarin u machine learning-modellen kunt experimenteren, trainen en implementeren.
Azure Machine Learning Compute is een cluster van virtuele machines op aanvraag met opties voor automatisch schalen en GPU en CPU-knooppunten. De trainingstaak wordt uitgevoerd op dit cluster.
Azure Machine Learning-pijplijnen bieden herbruikbare machine learning-werkstromen die in scenario's opnieuw kunnen worden gebruikt. Training, modelevaluatie, modelregistratie en het maken van installatiekopieën vindt plaats in verschillende stappen binnen deze pijplijnen voor deze use-case. De pijplijn wordt gepubliceerd of bijgewerkt aan het einde van de buildfase en wordt geactiveerd bij nieuwe gegevens aankomst.
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 wordt 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 scorewebservice-installatiekopieën te implementeren in Container Instances, die een eenvoudige, serverloze manier biedt 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 op een beheerd Kubernetes-cluster.
Azure-toepassing Inzichten. 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 met softwaretechnici. Het probleem met machine learning is eenvoudig om de focus te houden op de DevOps-pijplijn. De oplossing maakt gebruik van de gegevensset diabetes scikit-learn en bouwt een ridge lineair regressiemodel om de kans op diabetes te voorspellen.
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 planning of wanneer er nieuwe gegevens beschikbaar komen.
- Release-pijplijn. Hiermee wordt de scoreafbeelding operationeel gemaakt en wordt deze veilig in verschillende omgevingen gepromoot.
In de volgende secties wordt elk van 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 standaarden van het team.
Eenheidstest. Deze tests zorgen ervoor dat de code werkt, voldoende codedekking heeft en stabiel is.
Gegevenstest. Met deze tests wordt gecontroleerd of de gegevensvoorbeelden voldoen aan het verwachte schema en de verwachte distributie. Pas deze test aan voor andere gebruiksscenario's en voer deze uit als een afzonderlijke pijplijn voor gegevensbeveiliging die wordt geactiveerd wanneer nieuwe gegevens binnenkomen. Verplaats de gegevenstesttaak bijvoorbeeld naar een pijplijn voor gegevensopname, zodat u deze eerder kunt testen.
Notitie
Overweeg devOps-procedures in te schakelen voor de gegevens die worden gebruikt voor het trainen van de machine learning-modellen, maar dit wordt niet behandeld in dit artikel. Zie DevOps voor een pijplijn voor gegevensopname voor meer informatie over de architectuur en aanbevolen procedures voor CI/CD van een pijplijn voor gegevensopname.
De volgende eenmalige taken vinden plaats 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 van 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.
In deze pijplijn worden de volgende stappen behandeld:
Train het model. Het Python-trainingsscript wordt uitgevoerd op de Azure Machine Learning Compute-resource om een nieuw modelbestand op te halen dat is opgeslagen in de uitvoeringsgeschiedenis. Omdat training de meest rekenintensieve taak in een AI-project is, maakt de oplossing gebruik van Azure Machine Learning Compute.
Evalueer het model. 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 Machine Learning Model-register. 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 promoten in verschillende omgevingen. Deze pijplijn is onderverdeeld in twee omgevingen, QA en productie:
QA-omgeving
Trigger modelartefact. Release-pijplijnen worden telkens geactiveerd wanneer een nieuw artefact beschikbaar is. Een nieuw model dat is geregistreerd bij Azure Machine Learning Model Management, wordt behandeld als een releaseartefact. In dit geval wordt er een pijplijn geactiveerd voor elk nieuw model.
Maak een scoreafbeelding. 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 dit wordt meestal gebruikt voor het testen. Container Instances biedt een eenvoudige en snelle manier om de Docker-installatiekopieën te testen.
Test de webservice. Een eenvoudige API-test zorgt ervoor dat de installatiekopie is geïmplementeerd.
Productieomgeving
Implementeren in Azure Kubernetes Service. Deze service wordt gebruikt voor het implementeren van een score-installatiekopieën als een webservice op schaal in een productieomgeving.
Test de webservice. Een eenvoudige API-test zorgt ervoor dat de installatiekopie is geïmplementeerd.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is 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 op 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éagents). Voor door 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 uw YAML-bestand van Azure Pipelines in:
jobs:
- job: <job_name>
timeoutInMinutes: 0
In het ideale voorbeeld 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 deze oplossen als er problemen optreden. Voer langlopende tests uit tijdens buiten kantooruren.
De release-pijplijn publiceert een realtime scorewebservice. Voor het gemak wordt een release voor de QA-omgeving 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 scorearchitecturen in realtime is doorvoer een belangrijke optimalisatiemetriek. Voor niet-deep learning-scenario's moet de CPU voldoende zijn om de belasting te verwerken; Voor deep learning-workloads, wanneer snelheid een knelpunt is, bieden GPU's doorgaans betere prestaties vergeleken met CPU's. Azure Kubernetes Service ondersteunt zowel CPU- als GPU-knooppunttypen. Dit is de reden waarom deze oplossing deze 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 deze ondersteund door Azure Machine Learning Compute.
Beheer
Hertrainingstaak bewaken. Machine learning-pijplijnen organiseren het opnieuw trainen op een cluster van machines en bieden een eenvoudige manier om ze te bewaken. Gebruik de Gebruikersinterface van Azure Machine Learning en kijk onder de sectie pijplijnen voor de logboeken. Deze logboeken worden ook naar de blob geschreven en kunnen daar ook worden gelezen met behulp van hulpprogramma's zoals Azure Storage Explorer.
Logboekregistratie. Azure Machine Learning biedt een eenvoudige manier om u aan te melden bij elke stap van de machine learning-levenscyclus. De logboeken worden opgeslagen in een blobcontainer. Zie Logboekregistratie inschakelen in Azure Machine Learning voor meer informatie. Voor uitgebreidere bewaking configureert u Application Insights om de logboeken te gebruiken.
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 manieren om onnodige uitgaven 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 koopt u een abonnement op basis van het aantal gebruikers.
Compute is het grootste kostenstuurprogramma in deze architectuur en de kosten zijn 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 waarop uw rekencluster wordt ondersteund. Configureer uw rekencluster zodanig dat er minimaal 0 knooppunten zijn, zodat het, wanneer dit niet wordt gebruikt, omlaag kan worden geschaald naar 0 knooppunten en er geen 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. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Praneet Singh Solanki | Senior Software Engineer
Volgende stappen
- Wilt u meer informatie? Bekijk het gerelateerde leertraject, start de levenscyclus van machine learning met MLOps.