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 DevOps och Azure Machine Learning. Lösningen bygger på scikit-learn-datauppsättningen för diabetes men kan enkelt anpassas för alla AI-scenarion och andra populära byggsystem som Jenkins eller Travis.
En referensimplementering för den här arkitekturen finns på GitHub.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Den här arkitekturen består av följande tjänster:
Azure Pipelines. Det här bygg- och testsystemet baseras på Azure DevOps och används för bygg- och versionspipelines. Azure Pipelines delar upp dessa pipelines i logiska steg som kallas uppgifter. Azure CLI-uppgiften gör det till exempel enklare att arbeta med Azure-resurser.
Azure Machine Learning är en molntjänst för träning, 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ärningspipelinen och bedömningsbilden. En Azure Machine Learning-arbetsyta ger det utrymme där du kan 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 i 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 bildskapande sker i distinkta steg i dessa pipelines för det här användningsfallet. Pipelinen publiceras eller uppdateras i slutet av byggfasen och utlöses vid ankomsten av nya data.
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ägelse in. Efter en viss transformering kan dessa loggar användas för omträning av modeller.
Azure Container Registry. Python-bedömningsskriptet paketeras som en Docker-avbildning och är version i registret.
Azure Container Instances. Som en del av versionspipelinen efterliknas qa- och mellanlagringsmiljön genom att distribuera webbtjänstavbildningen för bedömning till Container Instances, vilket är 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 visar automatisering från slutpunkt till slutpunkt för olika faser i ett AI-projekt med hjälp av verktyg som redan är bekanta för programvarutekniker. Maskininlärningsproblemet är enkelt att hålla fokus på DevOps-pipelinen. Lösningen använder scikit-learn-datauppsättningen för diabetes och bygger en linjär regressionsmodell för åsen för att förutsäga sannolikheten för diabetes.
Den här lösningen baseras på följande tre pipelines:
- Skapa pipeline. Skapar koden och kör en uppsättning tester.
- Omträningspipeline. Tränar om modellen enligt ett schema eller när nya data blir tillgängliga.
- Versionspipeline. Operationaliserar bedömningsbilden och höjer upp 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. Dessa tester säkerställer att koden överensstämmer med teamets standarder.
Enhetstest. Dessa tester ser till att koden fungerar, har tillräcklig kodtäckning och är stabil.
Datatest. Dessa tester kontrollerar att dataexemplen ö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 pipeline för datasinne som utlöses när nya data tas emot. Du kan till exempel flytta datatestaktiviteten till en pipeline för datainmatning så att du kan testa den tidigare.
Kommentar
Du bör överväga att aktivera DevOps-metoder för de data som används för att träna maskininlärningsmodellerna, men detta beskrivs inte i den här artikeln. Mer information om arkitektur och metodtips för CI/CD för en datainmatningspipeline finns i DevOps för en pipeline för datainmatning.
Följande engångsuppgifter inträffar när du konfigurerar infrastrukturen för Azure Machine Learning och Python SDK:
- Skapa den arbetsyta som är värd för alla Azure Machine Learning-relaterade resurser.
- Skapa beräkningsresurserna som kör träningsjobbet.
- Skapa maskininlärningspipelinen med det uppdaterade träningsskriptet.
- Publicera maskininlärningspipelinen som en REST-slutpunkt för att samordna träningsarbetsflödet. I nästa avsnitt beskrivs det här steget.
Omträningspipeline
Maskininlärningspipelinen samordnar processen med 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äningsmodell. Python-skriptet för träning 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ärderingsmodell. Ett enkelt utvärderingstest jämför den nya modellen med den befintliga modellen. Först när den nya modellen är bättre höjs den upp. Annars registreras inte modellen och pipelinen avbryts.
Registrera modell. Den omtränad modellen registreras med Azure Machine Learning 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 höjer upp den på ett säkert sätt i olika miljöer. Den här pipelinen delas in i två miljöer, QA och produktion:
QA-miljö
Modellartefaktutlösare. Versionspipelines utlöses varje gång en ny artefakt är tillgänglig. En ny modell som är registrerad i Azure Machine Learning Model Management behandlas som en versionsartefakt. 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 Operationalization Docker-avbildning. Avbildningen tilldelas automatiskt en version via Azure Container Registry.
Distribuera på containerinstanser. Den här tjänsten används för att skapa en icke-produktionsmiljö. Bedömningsbilden distribueras också här, och den 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 i Azure Kubernetes Service. Den här tjänsten används för att distribuera en bedömningsbild som en webbtjänst i stor skala i en produktionsmiljö.
Testa webbtjänsten. Ett enkelt API-test ser till att avbildningen har distribuerats.
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
Skalbarhet
En bygg-pipeline på Azure DevOps kan skalas för program i alla storlekar. Byggpipelines har en maximal tidsgräns som varierar beroende på vilken agent de körs på. Byggen kan köras för alltid på lokalt installerade agenter (privata agenter). För Microsoft-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 verifiera ändringarna snabbt och åtgärda dem om det uppstår problem. Kör långvariga tester under lediga timmar.
Versionspipelinen publicerar en webbtjänst för bedömning i realtid. En version av QA-miljön görs med containerinstanser för enkelhetens skull, men du kan använda ett annat Kubernetes-kluster som körs i QA/mellanlagringsmiljön.
Skala produktionsmiljön efter 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 för djupinlärningsarbetsbelastningar ger GPU:er i allmänhet bättre prestanda jämfört med processorer när hastigheten är en flaskhals. 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 kontra processorer för distribution av djupinlärningsmodeller.
Skala omträningspipelinen upp och ned 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 djupinlärningsarbetsbelastningar är GPU:er ett bättre val och stöds av Azure Machine Learning Compute.
Hantering
Övervaka omträningsjobbet. Maskininlärningspipelines samordnar omträning över ett kluster av datorer och ger ett enkelt sätt att övervaka dem. Använd Azure Machine Learning-användargränssnittet och leta efter loggarna under avsnittet pipelines. Alternativt skrivs dessa loggar också till blob och kan läsas därifrån samt med hjälp av verktyg som Azure Storage Explorer.
Loggning. Azure Machine Learning är ett enkelt sätt att logga i varje steg i maskininlärningslivscykeln. Loggarna lagras i en blobcontainer. Mer information finns i Aktivera loggning i Azure Machine Learning. För mer omfattande övervakning konfigurerar du Application Insights för att använda loggarna.
Säkerhet. Alla hemligheter och autentiseringsuppgifter lagras i Azure Key Vault och används i Azure Pipelines med hjälp av variabelgrupper.
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
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.
Beräkning är den största kostnadsdrivrutinerna i den här arkitekturen och kostnaden varierar beroende på användningsfallet. Den här arkitekturen använder Azure Machine Learning Compute, men andra alternativ är tillgängliga. Azure Machine Learning lägger inte till någon tilläggsavgift utöver kostnaden för de virtuella datorer som säkerhetskopierar beräkningsklustret. Konfigurera beräkningsklustret så att det har minst 0 noder, så att det när det inte används kan skala ned till 0 noder och inte medföra några kostnader. Beräkningskostnaden beror på nodtypen, ett antal noder och etableringsläget (låg prioritet eller dedikerad). Du kan beräkna kostnaden för Machine Learning och andra tjänster med hjälp av Priskalkylatorn för Azure.
Distribuera det här scenariot
Om du vill distribuera den här referensarkitekturen följer du stegen som beskrivs i guiden Komma igång på GitHub-lagringsplatsen.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Praneet Singh Solanki | Senior programvarutekniker
Nästa steg
- Vill du lära dig mer? Kolla in den relaterade utbildningsvägen Starta maskininlärningslivscykeln med MLOps.