Den här referensarkitekturen visar hur du distribuerar Python-modeller som webbtjänster för att göra förutsägelser i realtid med hjälp av Azure Kubernetes Service. Maskininlärningsmodeller som distribueras i Azure Kubernetes är bra för storskaliga produktionsdistributioner.
Två scenarier beskrivs i den här artikeln: distribution av vanliga Python-modeller och de specifika kraven för att distribuera djupinlärningsmodeller. I båda scenarierna används den arkitektur som visas. Dessutom finns det två referensimplementering för dessa scenarier på GitHub, en för vanliga Python-modeller och en för djupinlärningsmodeller.
Scenario: matchning Stack Overflow vanliga frågor och svar
Det här scenariot visar hur du distribuerar en matchande modell med vanliga frågor och svar som en webbtjänst för att tillhandahålla förutsägelser för användarfrågor. I det här scenariot refererar "Indata" i arkitekturdiagrammet till textsträngar som innehåller användarfrågor som matchar en lista med vanliga frågor och svar. Det här scenariot är utformat för maskininlärningsbiblioteket scikit-learn för Python, men kan generaliseras till alla scenarier som använder Python-modeller för att göra förutsägelser i realtid.
I det här scenariot används en delmängd Stack Overflow frågedata som innehåller ursprungliga frågor som taggats som JavaScript, deras dubblettfrågor och svar. Den tränar en scikit-learn-pipeline för att förutsäga matchningsannolikheten för en dubblettfråga med var och en av de ursprungliga frågorna. Dessa förutsägelser görs i realtid med hjälp av en REST API slutpunkt.
Programflödet för den här arkitekturen är följande:
- Den tränade modellen registreras i maskininlärningsmodellregistret.
- Azure Machine Learning skapar en Docker-avbildning som innehåller modellen och bedömningsskriptet.
- Azure Machine Learning distribuerar bedömningsavbildningen på Azure Kubernetes Service (AKS) som en webbtjänst.
- Klienten skickar en HTTP POST-begäran med kodade frågedata.
- Webbtjänsten som skapas av Azure Machine Learning extraherar frågan från begäran.
- Frågan skickas till pipelinemodellen scikit-learn för funktionalitet och bedömning.
- Matchande frågor och svar om deras poäng returneras till klienten.
Här är en skärmbild av exempelappen som förbrukar resultatet:
Scenario: Bildklassificering med ett neuralt faltningsnätverk
Det här scenariot visar hur du distribuerar en CNN-modell (Convolutional Neural Network) som en webbtjänst för att tillhandahålla förutsägelser om bilder. I det här scenariot refererar "Indata" i arkitekturdiagrammet till bildfiler. CNN-nätverk är effektiva inom datorseende för uppgifter som bildklassificering och objektidentifiering. Det här scenariot är utformat för ramverken TensorFlow, Keras (med TensorFlow-backend) och PyTorch. Den kan dock generaliseras till alla scenarier som använder djupinlärningsmodeller för att göra förutsägelser i realtid.
I det här scenariot används en förtränad ResNet-152-modell som tränats på datauppsättningen ImageNet-1K (1 000 klasser) för att förutsäga vilken kategori (se bilden nedan) som en bild tillhör. Dessa förutsägelser görs i realtid med hjälp av en REST API slutpunkt.
Programflödet för djupinlärningsmodellen är följande:
- Djupinlärningsmodellen registreras i maskininlärningsmodellregistret.
- Azure Machine Learning skapar en Docker-avbildning inklusive modellen och bedömningsskriptet.
- Azure Machine Learning distribuerar bedömningsavbildningen på Azure Kubernetes Service (AKS) som en webbtjänst.
- Klienten skickar en HTTP POST-begäran med kodade bilddata.
- Webbtjänsten som skapas av Azure Machine Learning förbearbetar avbildningsdata och skickar dem till modellen för bedömning.
- De förutsagda kategorierna med sina poäng returneras till klienten.
Arkitektur
Den här arkitekturen består av följande komponenter.
Azure Machine Learning är en molntjänst som används för att träna, distribuera, automatisera och hantera maskininlärningsmodeller i den omfattande skala som molnet erbjuder. Den används i den här arkitekturen för att hantera distributionen av modeller och autentisering, routning och belastningsutjämning av webbtjänsten.
Virtuell dator (VM). Den virtuella datorn visas som ett exempel på en enhet – lokal eller i molnet – som kan skicka en HTTP-begäran.
Azure Kubernetes Service (AKS) används för att distribuera programmet i ett Kubernetes-kluster. AKS förenklar distributionen och driften av Kubernetes. Klustret kan konfigureras med endast CPU-baserade virtuella datorer för vanliga Python-modeller eller GPU-aktiverade virtuella datorer för djupinlärningsmodeller.
Azure Container Registry lagring av avbildningar för alla typer av Docker-containerdistributioner, inklusive DC/OS, Docker Swarm och Kubernetes. Bedömningsavbildningarna distribueras som containrar på Azure Kubernetes Service används för att köra bedömningsskriptet. Avbildningen som används här skapas Machine Learning från den tränade modellen och bedömningsskriptet och skickas sedan till Azure Container Registry.
Saker att tänka på gällande prestanda
För realtidsbedömningsarkitekturer blir dataflödesprestandan en viktig faktor. För vanliga Python-modeller räcker processorer för att hantera arbetsbelastningen.
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. För att matcha GPU-prestanda med hjälp av processorer behövs vanligtvis ett kluster med ett stort antal processorer.
Du kan använda processorer för den här arkitekturen i båda scenarierna, men för djupinlärningsmodeller ger GPU:er högre dataflödesvärden jämfört med ett CPU-kluster med liknande kostnad. AKS stöder användning av GPU:er, vilket är en fördel med att använda AKS för den här arkitekturen. Dessutom använder djupinlärningsdistributioner vanligtvis modeller med ett stort antal parametrar. Användning av GPU:er förhindrar att resurser mellan modellen och webbtjänsten, vilket är ett problem i distributioner med endast CPU.
Skalbarhetsöverväganden
För vanliga Python-modeller, där AKS-klustret etableras med endast CPU-baserade virtuella datorer, bör du vara försiktig när du skalar ut antalet poddar. Målet är att utnyttja klustret fullt ut. Skalningen beror på de CPU-begäranden och gränser som definierats för poddarna. Machine Learning via Kubernetes stöder även automatisk poddskalning baserat på CPU-användning eller andra mått. Autoskalning av kluster kan skala agentnoder baserat på väntande poddar.
För djupinlärningsscenarier med GPU-aktiverade virtuella datorer är resursbegränsningarna på poddar sådana att en GPU tilldelas till en podd. Beroende på vilken typ av virtuell dator som används måste du skala noderna i klustret för att uppfylla efterfrågan på tjänsten. Du kan enkelt göra detta med hjälp av Azure CLI och kubectl.
Överväganden för övervakning och loggning
AKS-övervakning
För insyn i AKS-prestanda kan du använda funktionen Azure Monitor för containrar. Den samlar in minnes- och processormått från kontrollanter, noder och containrar som är tillgängliga i Kubernetes via mått-API:et.
När du distribuerar programmet övervakar du AKS-klustret för att se till att det fungerar som förväntat, att alla noder fungerar och att alla poddar körs. Även om du kan använda kommandoradsverktyget kubectl för att hämta poddstatus innehåller Kubernetes även en webbinstrumentpanel för grundläggande övervakning av klusterstatus och hantering.
Om du vill se det övergripande tillståndet för klustret och noderna går du till avsnittet Noder på Kubernetes-instrumentpanelen. Om en nod är inaktiv eller har misslyckats kan du visa felloggarna från den sidan. På samma sätt går du till avsnitten Poddar och distributioner för information om antalet poddar och status för distributionen.
AKS-loggar
AKS loggar automatiskt alla stdout/stderr till loggarna för poddarna i klustret. Använd kubectl för att se dessa och även händelser och loggar på nodnivå. Mer information finns i distributionsstegen.
Använd Azure Monitor för containrar för att samla in mått och loggar via en containerversion av Log Analytics-agenten för Linux, som lagras på Log Analytics-arbetsytan.
Säkerhetsöverväganden
Använd Microsoft Defender för molnet för att få en central vy över säkerhetstillståndet för dina Azure-resurser. Defender for Cloud övervakar potentiella säkerhetsproblem och ger en heltäckande bild av säkerhetshälsan för din distribution, även om den inte övervakar AKS-agentnoder. Defender for Cloud konfigureras per Azure-prenumeration. Aktivera insamling av säkerhetsdata enligt beskrivningen i Aktivera Defender för moln på dina prenumerationer. När datainsamling har aktiverats genomsöker Defender for Cloud automatiskt alla virtuella datorer som skapats under prenumerationen.
Åtgärder. Om du vill logga in på ett AKS-kluster med din Azure Active Directory-autentiseringstoken (Azure AD) konfigurerar du AKS att använda Azure AD för användarautentisering. Klusteradministratörer kan också konfigurera Kubernetes rollbaserad åtkomstkontroll (Kubernetes RBAC) baserat på en användares identitet eller kataloggruppsmedlemskap.
Använd Azure RBAC för att styra åtkomsten till de Azure-resurser som du distribuerar. Med Azure RBAC kan du tilldela auktoriseringsroller till medlemmar i DevOps-teamet. En användare kan tilldelas till flera roller och du kan skapa anpassade roller för ännu mer specifika behörigheter.
HTTPS. Som en säkerhetsmetod bör programmet framtvinga HTTPS- och omdirigering av HTTP-begäranden. Använd en ingress-kontrollant för att distribuera en omvänd proxy som avslutar SSL och omdirigerar HTTP-begäranden. Mer information finns i Create an HTTPS ingress controller on Azure Kubernetes Service (AKS) (Skapa en HTTPS-ingresskontrollant på Azure Kubernetes Service (AKS).
Autentisering. Den här lösningen begränsar inte åtkomsten till slutpunkterna. Om du vill distribuera arkitekturen i en företagsinställning måste du skydda slutpunkterna via API-nycklar och lägga till någon form av användarautentisering i klientprogrammet.
Containerregister. Den här lösningen använder Azure Container Registry för att lagra Docker-avbildningen. Koden som programmet är beroende av, och modellen, finns i den här avbildningen. Företagsprogram bör använda ett privat register för att skydda mot skadlig kod och för att hålla informationen i containern komprometterad.
DDoS-skydd. Överväg att aktivera DDoS Protection Standard. Även om grundläggande DDoS-skydd är aktiverat som en del av Azure-plattformen, ger DDoS Protection Standard skyddsfunktioner som är specifikt utformade för virtuella Azure-nätverksresurser.
Loggning. Använd bästa praxis innan du lagrar loggdata, till exempel rensa användarlösenord och annan information som kan användas för att genomföra säkerhetsbedrägerier.
Kostnadsöverväganden
Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure. Här är några andra överväganden.
Mer information finns i Microsoft Azure Well-Architected Framework-artikeln Principer för kostnadsoptimering.
Azure Machine Learning
I den här referensarkitekturen drivs en stor del av kostnaden av beräkningsresurser. För experimentering och träning är Azure Machine Learning kostnadsfritt. Du debiteras bara för den beräkning som används av webbtjänsten. Använd priskalkylatorn för Azure för att beräkna dina beräkningskostnader.
Azure Container Registry
Azure Container Registry erbjuder Basic,Standardoch Premium. Välj en nivå beroende på vilken lagring du behöver. Välj Premium om du behöver geo-replikering eller om du har förbättrat dataflödet för Docker-pull-åtgärder mellan samtidiga noder. Dessutom tillkommer standardavgifter för nätverk. Mer information finns i Priser för Azure Container Registry .
Azure Kubernetes Service
Du betalar bara för de instanser av virtuella datorer, lagring och nätverksresurser som förbrukas av ditt Kubernetes-kluster. Information om hur du beräknar kostnaden för de nödvändiga resurserna finns i Container Services-kalkylatorn.
Mer information finns i Microsoft Azure Well-Architected Framework-artikeln Principer för kostnadsoptimering.
DevOps-överväganden
I den här arkitekturen skapas bedömningsavbildningarna av Machine Learning och distribueras som containrar i AKS. Du kan integrera hela arkitekturen i en lanseringspipeline för modellhantering och driftsättning. Pipelinen kan innehålla DevOps-uppgifter för datasanningstest, modellträning på olika beräkningsmål, modellversionshantering, modelldistribution som en realtidswebbtjänst, mellannivådistribution till QA/produktionsmiljöer, integreringstestning och funktionell testning. MLOps (Machine Learning Operationalization) för Python-modeller som använder Azure Machine Learning-referensarkitektur visar hur du implementerar en kontinuerlig integrering (CI), kontinuerlig leverans (CD) och omträningspipeline för ett AI-program med hjälp av Azure DevOps och Azure Machine Learning.
Distribution
Om du vill distribuera den här referensarkitekturen följer du stegen som beskrivs i GitHub lagringsplatsen:
Nästa steg
Läs produktdokumentationen:
- Distribuera en modell till ett Azure Kubernetes Service kluster
- Introduktion till privata Docker-containerregister i Azure
Prova följande Microsoft Learning sökvägar: