MLOps för Python-modeller med Azure Machine Learning

Den här referensarkitekturen visar hur du implementerar kontinuerlig integrering (CI), kontinuerlig leverans (CD) och omträningspipeline för ett AI-program med hjälp av Azure DevOpsoch Azure Machine Learning. Lösningen bygger på datamängden scikit-learn diabetes, men kan enkelt anpassas för alla AI-scenarier och andra populära byggsystem som Jenkins eller Jenkins.

En referensimplementering för den här arkitekturen finns på GitHub.

Arkitektur

Den här arkitekturen består av följande komponenter:

Azure Pipelines. Det här bygg- och testsystemet baseras på Azure DevOps och används för bygg- och lanseringspipelines. Azure Pipelines delar in dessa pipelines i logiska steg som kallas uppgifter. Till exempel gör Azure CLI-uppgiften det enklare att arbeta med Azure-resurser.

Azure Machine Learning är en molntjänst för utbildning, bedömning, distribution och hantering av maskininlärningsmodeller i stor skala. Den här arkitekturen använder Azure Machine Learning Python SDK för att skapa en arbetsyta, beräkningsresurser, maskininlärningspipeline och bedömningsavbildningen. En Azure Machine Learning arbetsyta ger utrymme för att experimentera, träna och distribuera maskininlärningsmodeller.

Azure Machine Learning Compute är ett kluster med virtuella datorer på begäran med alternativ för automatisk skalning och GPU och CPU-noder. Träningsjobbet körs på det här klustret.

Azure Machine Learning pipelines ger återanvändbara arbetsflöden för maskininlärning som kan återanvändas i olika scenarier. Träning, modellutvärdering, modellregistrering och skapande av avbildningar sker i separata steg i dessa pipelines för det här användningsfallet. Pipelinen publiceras eller uppdateras i slutet av byggfasen och utlöses när nya data kommer.

Azure Blob Storage. Blobcontainrar används för att lagra loggarna från bedömningstjänsten. I det här fallet samlas både indata och modellförutsägelsen in. Efter viss transformering kan dessa loggar användas för modellomträning.

Azure Container Registry. Python-bedömningsskriptet är paketerat som en Docker-avbildning och en version i registret.

Azure Container Instances. Som en del av lanseringspipelinen efterliknar QA och mellanlagringsmiljön genom att distribuera bedömningswebbtjänstavbildningen till Container Instances, vilket ger ett enkelt, serverlöst sätt att köra en container.

Azure Kubernetes Service. När bedömningswebbtjänstavbildningen har testats noggrant i QA-miljön distribueras den till produktionsmiljön i ett hanterat Kubernetes-kluster.

Azure Application Insights. Den här övervakningstjänsten används för att identifiera prestandaavvikelser.

MLOps-pipeline

Den här lösningen demonstrerar automatisering från början till slut i olika faser av ett AI-projekt med hjälp av verktyg som programvarutekniker redan är bekanta med. Maskininlärningsproblemet är enkelt för att behålla fokus på DevOps-pipelinen. Lösningen använder datamängden scikit-learn diabetes och skapar en linjär regressionsmodell för att förutsäga sannolikheten för diabetes. Mer information finns i Träning av Python scikit-learn-modeller.

Den här lösningen baseras på följande tre pipelines:

• Bygg-pipeline. Skapar koden och kör en uppsättning tester.
• Omträningspipeline. Omtränar modellen enligt ett schema eller när nya data blir tillgängliga.
• Lanseringspipeline. Operationaliserar bedömningsbilden och främjar den på ett säkert sätt i olika miljöer.

I nästa avsnitt beskrivs var och en av dessa pipelines.

Bygg-pipeline

CI-pipelinen utlöses varje gång kod checkas in. Den publicerar en uppdaterad Azure Machine Learning-pipeline när du har byggt koden och kört en serie tester. Bygg-pipelinen består av följande uppgifter:

• Kodkvalitet. De här testerna säkerställer att koden följer teamets standarder.

• Enhetstest. De här testerna ser till att koden fungerar, har tillräcklig kodtäckning och är stabil.

• Datatest. Dessa tester kontrollerar att dataproverna överensstämmer med det förväntade schemat och distributionen. Anpassa det här testet för andra användningsfall och kör det som en separat datasenlighetspipeline som utlöses när nya data tas emot. Flytta till exempel datatestaktiviteten till en pipeline för datainmatning så att du kan testa den tidigare.

Följande en-gång-uppgifter utförs när du ställer in infrastrukturen för Azure Machine Learning och Python SDK:

• Skapa arbetsytan som är värd för Azure Machine Learning alla relaterade resurser.
• Skapa de beräkningsresurser som kör träningsjobbet.
• Skapa pipelinen för maskininlärning med det uppdaterade träningsskriptet.
• Publicera maskininlärningspipelinen som en REST-slutpunkt för att orkestrera träningsarbetsflödet. I nästa avsnitt beskrivs det här steget.

Omträningspipeline

Pipelinen för maskininlärning dirigerar processen att träna om modellen på ett asynkront sätt. Omträning kan utlösas enligt ett schema eller när nya data blir tillgängliga genom att anropa den publicerade REST-slutpunkten för pipelinen från föregående steg.

Den här pipelinen omfattar följande steg:

• Träna modell. Python-träningsskriptet körs på Azure Machine Learning Compute-resursen för att hämta en ny modellfil som lagras i körningshistoriken. Eftersom träning är den mest beräkningsintensiva uppgiften i ett AI-projekt använder lösningen Azure Machine Learning Compute.

• Utvärdera modellen. Ett enkelt utvärderingstest jämför den nya modellen med den befintliga modellen. Det är först när den nya modellen blir bättre som den befordras. Annars registreras inte modellen och pipelinen avbryts.

• Registrera modellen. Den omtränade modellen registreras med Azure ML Model-registret. Den här tjänsten tillhandahåller versionskontroll för modellerna tillsammans med metadatataggar så att de enkelt kan återskapas.

Lanseringspipeline

Den här pipelinen visar hur du operationaliserar bedömningsbilden och befordrar den på ett säkert sätt i olika miljöer. Den här pipelinen är indelad i två miljöer, QA och produktion:

QA-miljö

• Modellartefaktutlösare. Lanseringspipelines utlöses varje gång en ny artefakt är tillgänglig. En ny modell som registrerats Azure Machine Learning Modellhantering behandlas som en lanseringsartefakt. I det här fallet utlöses en pipeline för varje ny modell som registreras.

• Skapa en bedömningsbild. Den registrerade modellen paketeras tillsammans med ett bedömningsskript och Python-beroenden(Conda YAML-fil)i en Docker-avbildning för operationalisering. Avbildningen tilldelas automatiskt en version via Azure Container Registry.

• Distribuera på Container Instances. Den här tjänsten används för att skapa en icke-produktionsmiljö. Bedömningsavbildningen distribueras också här och används främst för testning. Container Instances är ett enkelt och snabbt sätt att testa Docker-avbildningen.

• Testa webbtjänsten. Ett enkelt API-test ser till att avbildningen har distribuerats.

Produktionsmiljö

• Distribuera på Azure Kubernetes Service. Den här tjänsten används för att distribuera en bedömningsavbildning som en webbtjänst i stor skala i en produktionsmiljö.

• Testa webbtjänsten. Ett enkelt API-test ser till att avbildningen har distribuerats.

Skalbarhetsöverväganden

En bygg-pipeline på Azure DevOps kan skalas för program av valfri storlek. Bygg-pipelines har en maximal tidsgräns som varierar beroende på vilken agent de körs på. Byggen kan köras för alltid på egna agenter (privata agenter). För Microsofts värdbaserade agenter för ett offentligt projekt kan byggen köras i sex timmar. För privata projekt är gränsen 30 minuter.

Om du vill använda den maximala tidsgränsen anger du följande egenskap i YAML-filen för Azure Pipelines:

jobs:
- job: <job_name>
  timeoutInMinutes: 0

Vi rekommenderar att bygg-pipelinen slutförs snabbt och endast kör enhetstester och en delmängd av andra tester. På så sätt kan du snabbt validera ändringarna och åtgärda dem om det uppstår problem. Kör långvariga tester utanför arbetstid.

Lanseringspipelinen publicerar en realtidsbedömningswebbtjänst. En version av QA-miljön görs med hjälp Container Instances för enkelhetens skull, men du kan använda ett annat Kubernetes-kluster som körs i QA/mellanlagringsmiljön.

Skala produktionsmiljön enligt storleken på ditt Azure Kubernetes Service kluster. Klustrets storlek beror på vilken belastning du förväntar dig för den distribuerade bedömningswebbtjänsten. För realtidsbedömningsarkitekturer är dataflödet ett viktigt optimeringsmått. För icke-djupinlärningsscenarier bör processorn vara tillräcklig för att hantera belastningen. Men när hastigheten är en flaskhals för arbetsbelastningar för djupinlärning ger GPU:er vanligtvis bättre prestanda jämfört med processorer. Azure Kubernetes Service stöder både CPU- och GPU-nodtyper, vilket är anledningen till att den här lösningen använder den för avbildningsdistribution. Mer information finns i GPU:er jämfört med processorer för distribution av djupinlärningsmodeller.

Skala om träningspipelinen uppåt och nedåt beroende på antalet noder i din Azure Machine Learning Compute-resurs och använd alternativet för automatisk skalning för att hantera klustret. Den här arkitekturen använder processorer. För arbetsbelastningar för djupinlärning är GPU:er ett bättre val och stöds av Azure Machine Learning Compute.

Överväganden kring hantering

• Övervaka omträningsjobb. Maskininlärningspipelines dirigerar omträning över ett kluster med datorer och ger ett enkelt sätt att övervaka dem. Använd Azure Machine Learning användargränssnitt och titta under avsnittet pipelines för loggarna. De här loggarna skrivs också till blob och kan läsas därifrån med hjälp av verktyg som Azure Storage Explorer.

• Loggning. Azure Machine Learning är ett enkelt sätt att logga vid varje steg i livscykeln för maskininlärning. Loggarna lagras i en blobcontainer. Mer information finns i Aktivera loggning i Azure Machine Learning. För mer omfattande övervakning konfigurerar du Insights att använda loggarna.

• Säkerhet. Alla hemligheter och autentiseringsuppgifter lagras i Azure Key Vault i Azure Pipelines med hjälp av variabelgrupper.

Kostnadsöverväganden

Azure DevOps är kostnadsfritt för projekt med öppen källkod och små projekt med upp till fem användare. För större team köper du en plan baserat på antalet användare.

Compute är den största kostnadsdrivrutinen i den här arkitekturen och kostnaden varierar beroende på användningsfall. Den här arkitekturen använder Azure Machine Learning Compute, men det finns andra alternativ. Azure Machine Learning lägger inte till någon avgift utöver kostnaden för de virtuella datorer som backar upp beräkningsklustret. Konfigurera beräkningsklustret så att det har minst 0 noder, så att det kan skala ned till 0 noder när det inte används och inte medföra några kostnader. Beräkningskostnaden beror på nodtypen, ett antal noder och etableringsläget (lågprioriterat eller dedikerat). Du kan beräkna kostnaden för Machine Learning och andra tjänster med hjälp av priskalkylatorn för Azure.

Distribuera lösningen

Om du vill distribuera den här referensarkitekturen följer du stegen som beskrivs Komma igång guiden i GitHub lagringsplatsen.

Nästa steg

• Vill du veta mer? Kolla in de relaterade utbildningsvägarna: Microsoft Learn starta livscykeln för maskininlärning med MLOps