Batchscores voor Deep Learning-modellen met behulp Azure Machine Learning pijplijnen

Logic Apps
Machine Learning
Op rollen gebaseerd toegangsbeheer van Azure
Storage

Deze referentiearchitectuur laat zien hoe u neurale stijloverdracht kunt toepassen op een video, met behulp van Azure Machine Learning. Stijloverdracht is een deep learning-techniek waarmee een bestaande afbeelding in de stijl van een andere afbeelding wordt gemaakt. Deze architectuur kan worden ge generaliseerd voor elk scenario dat gebruikmaakt van batch scoren met deep learning. Deze oplossing implementeren.

Architectuurdiagram voor deep learning-modellen die gebruikmaken van Azure Machine Learning.

Scenario: een mediaorganisatie heeft een video waarvan de stijl die ze willen wijzigen, eruit wil zien als een specifieke schilderij. De organisatie wil deze stijl op tijd en op een geautomatiseerde manier toepassen op alle frames van de video. Zie Image Style Transfer Using Convolutional Neural Networks (PDF) (Afbeeldingsstijloverdracht met convolutionele neurale netwerken (PDF) voor meer achtergrondinformatie over algoritmen voor neurale stijloverdracht.

Deze referentiearchitectuur is ontworpen voor workloads die worden geactiveerd door de aanwezigheid van nieuwe media in Azure Storage.

De verwerking omvat de volgende stappen:

  1. Upload videobestand toevoegen aan Azure Blob Storage.
  2. Het videobestand wordt Azure Logic Apps om een aanvraag te verzenden naar het Azure Machine Learning het gepubliceerde eindpunt van de pijplijn.
  3. De pijplijn verwerkt de video, past stijloverdracht toe met MPI en verwerkt de video na.
  4. De uitvoer wordt weer opgeslagen in blobopslag zodra de pijplijn is voltooid.

Architectuur voor een deep learning-ML pijplijn

Deze architectuur bestaat uit de volgende onderdelen.

Compute

Azure Machine Learning pijplijnen gebruikt om reproduceerbare en eenvoudig te beheren rekenreeksen te maken. Het biedt ook een beheerd rekendoel (waarop een pijplijnberekening kan worden uitgevoerd) met de naam Azure Machine Learning Compute voor het trainen, implementeren en scoren machine learning modellen.

Storage

Azure Blob Storage wordt gebruikt voor het opslaan van alle afbeeldingen (invoerafbeeldingen, stijlafbeeldingen en uitvoerafbeeldingen). Azure Machine Learning kan worden geïntegreerd met Blob Storage, zodat gebruikers gegevens niet handmatig tussen rekenplatforms en blob-opslagen hoeft te verplaatsen. Blob-opslag is ook rendabel voor de prestaties die deze workload vereist.

Activeren/plannen

Azure Logic Apps wordt gebruikt om de werkstroom te activeren. Wanneer de logische app detecteert dat er een blob is toegevoegd aan de container, wordt de Azure Machine Learning-pijplijn. Logic Apps is geschikt voor deze referentiearchitectuur omdat het een eenvoudige manier is om wijzigingen in blobopslag te detecteren, met een eenvoudig proces voor het wijzigen van de trigger.

Onze gegevens voorverwerken en nabewerken

Deze referentiearchitectuur maakt gebruik van videobeelden van een orangutan in een boomstructuur.

  1. Gebruik FFmpeg om het audiobestand uit de videobeelden te extraheren, zodat het audiobestand later weer kan worden toegevoegd aan de uitvoervideo.
  2. Gebruik FFmpeg om de video op te delen in afzonderlijke frames. De frames worden onafhankelijk van elkaar verwerkt, parallel.
  3. Op dit moment kunnen we neurale stijloverdracht parallel toepassen op elk afzonderlijk frame.
  4. Als elk frame is verwerkt, moeten we FFmpeg gebruiken om de frames opnieuw samen te maken.
  5. Ten slotte wordt het audiobestand opnieuw aan de overige beelden toegevoegd.

Prestatieoverwegingen

GPU versus CPU

Voor deep learning-workloads presteren GPU's over het algemeen aanzienlijk veel beter dan CPU's, in zoverre dat een groot cluster CPU's doorgaans nodig is om vergelijkbare prestaties te krijgen. Hoewel het een optie is om alleen CPU's in deze architectuur te gebruiken, bieden GPU's een veel beter kosten-/prestatieprofiel. We raden u aan de nieuwste NCv3-serie van voor GPU geoptimaliseerde VM's te gebruiken.

GPU's zijn niet standaard ingeschakeld in alle regio's. Zorg ervoor dat u een regio selecteert met GPU's ingeschakeld. Daarnaast hebben abonnementen een standaardquotum van nul kernen voor voor GPU geoptimaliseerde VM's. U kunt dit quotum verhogen door een ondersteuningsaanvraag te openen. Zorg ervoor dat uw abonnement voldoende quota heeft om uw workload uit te voeren.

Parallelliseren tussen VM's en kernen

Bij het uitvoeren van een stijloverdrachtsproces als batch-job, moeten de taken die voornamelijk op GPU's worden uitgevoerd, parallel worden uitgevoerd op VM's. Er zijn twee benaderingen mogelijk: u kunt een groter cluster maken met behulp van VM's met één GPU of een kleiner cluster maken met behulp van VM's met veel GPU's.

Voor deze workload hebben deze twee opties vergelijkbare prestaties. Het gebruik van minder VM's met meer GPU's per VM kan helpen om de verplaatsing van gegevens te verminderen. Het gegevensvolume per taak voor deze workload is echter niet groot, dus u zult niet veel bandbreedtebeperking door blobopslag zien.

MPI-stap

Bij het maken van Azure Machine Learning pijplijnis de MPI-stap (message processing interface) een van de stappen die wordt gebruikt om een parallelle berekening uit te voeren. Met de MPI-stap kunt u de gegevens gelijkmatig splitsen over de beschikbare knooppunten. De MPI-stap wordt pas uitgevoerd als alle aangevraagde knooppunten gereed zijn. Als één knooppunt mislukt of wordt verpeerd (als het een virtuele machine met lage prioriteit is), moet de MPI-stap opnieuw wordenrun.

Beveiligingsoverwegingen

Toegang tot Azure Blob Storage beperken

In deze referentiearchitectuur is Azure Blob Storage het belangrijkste opslagonderdeel dat moet worden beveiligd. De basislijnimplementatie die wordt weergegeven in de GitHub gebruikt opslagaccountsleutels voor toegang tot de blobopslag. Voor meer controle en beveiliging kunt u in plaats daarvan een Shared Access Signature (SAS) gebruiken. Dit verleent beperkte toegang tot objecten in de opslag, zonder dat de accountsleutels in code hoeven te worden gecodeerd of in tekst zonder tekst hoeven te worden opgeslagen. Deze aanpak is vooral nuttig omdat accountsleutels zichtbaar zijn in tekst zonder tekst in de ontwerpinterface van de logische app. Het gebruik van een SAS helpt er ook voor te zorgen dat het opslagaccount correct wordt bestuurd en dat toegang alleen wordt verleend aan de personen die het nodig hebben.

Zorg er voor scenario's met gevoeligere gegevens voor dat al uw opslagsleutels zijn beveiligd, omdat deze sleutels volledige toegang verlenen tot alle invoer- en uitvoergegevens van de workload.

Gegevensversleuteling en gegevensversleuteling

Deze referentiearchitectuur maakt gebruik van stijloverdracht als voorbeeld van een batchscoreproces. Voor meer gegevensgevoelige scenario's moeten de gegevens in de opslag at-rest worden versleuteld. Telkens als gegevens van de ene locatie naar de volgende worden verplaatst, gebruikt u Transport Layer Security (TSL) om de gegevensoverdracht te beveiligen. Zie de beveiligingshandleiding Azure Storage meer informatie.

Uw berekening in een virtueel netwerk beveiligen

Wanneer u uw Machine Learning-rekencluster implementeert, kunt u uw cluster configureren voor inrichting in een subnet van een virtueel netwerk. Met dit subnet kunnen de rekenknooppunten in het cluster veilig communiceren met andere virtuele machines.

Bescherming tegen schadelijke activiteiten

In scenario's met meerdere gebruikers moet u ervoor zorgen dat gevoelige gegevens zijn beveiligd tegen schadelijke activiteiten. Als andere gebruikers toegang krijgen tot deze implementatie om de invoergegevens aan te passen, moet u rekening houden met de volgende voorzorgsmaatregelen en overwegingen:

  • Gebruik op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) om de toegang van gebruikers te beperken tot alleen de resources die ze nodig hebben.
  • Twee afzonderlijke opslagaccounts inrichten. Sla invoer- en uitvoergegevens op in het eerste account. Externe gebruikers kunnen toegang krijgen tot dit account. Sla uitvoerbare scripts en uitvoerlogboekbestanden op in het andere account. Externe gebruikers mogen geen toegang hebben tot dit account. Deze scheiding zorgt ervoor dat externe gebruikers geen uitvoerbare bestanden kunnen wijzigen (om schadelijke code te injecteren) en geen toegang hebben tot logboekbestanden die gevoelige informatie kunnen bevatten.
  • Kwaadwillende gebruikers kunnen een DDoS-aanval uitvoeren op de wachtrij van de taak of onjuist vorm geven aan de wachtrij van de taak, waardoor het systeem wordt vergrendeld of fouten met dequeuing veroorzaakt.

Bewaking en registratie

Batchtaken bewaken

Tijdens het uitvoeren van uw taak is het belangrijk om de voortgang te controleren en ervoor te zorgen dat de taak werkt zoals verwacht. Het kan echter een uitdaging zijn om te controleren op een cluster met actieve knooppunten.

Als u de algehele status van het cluster wilt controleren, gaat u naar de Machine Learning-service in de Azure Portal om de status van de knooppunten in het cluster te controleren. Als een knooppunt inactief is of een taak is mislukt, worden de foutenlogboeken opgeslagen in blobopslag en zijn ze ook toegankelijk in de Azure Portal.

Bewaking kan verder worden verrijkt door logboeken te verbinden met Application Insights of door afzonderlijke processen uit te uitvoeren om de status van het cluster en de taken ervan te peilen.

Logboekregistratie met Azure Machine Learning

Azure Machine Learning logt automatisch alle stdout/stderr in het bijbehorende blob-opslagaccount. Tenzij anders aangegeven, wordt in Azure Machine Learning werkruimte automatisch een opslagaccount ingericht en worden uw logboeken in dit account dumpen. U kunt ook een opslagnavigatieprogramma zoals Azure Storage Explorergebruiken. Dit is een eenvoudigere manier om door logboekbestanden te navigeren.

Kostenoverwegingen

Vergeleken met de opslag- en planningsonderdelen, zijn de rekenbronnen die in deze referentiearchitectuur worden gebruikt, verreweg de belangrijkste kosten. Een van de belangrijkste uitdagingen is het parallelliseren van het werk in een cluster met GPU-computers.

De Azure Machine Learning rekenclustergrootte kan automatisch omhoog en omlaag worden geschaald, afhankelijk van de taken in de wachtrij. U kunt automatisch schalen programmatisch inschakelen door de knooppunten minimum en maximum in te stellen.

Voor werk waarvoor geen onmiddellijke verwerking is vereist, configureert u automatisch schalen, zodat de standaardtoestand (minimaal) een cluster van nul knooppunten is. Met deze configuratie begint het cluster met nul knooppunten en wordt het alleen omhoog geschaald wanneer er taken in de wachtrij worden gedetecteerd. Als het batchscoreproces slechts een paar keer per dag of minder wordt gedaan, resulteert deze instelling in aanzienlijke kostenbesparingen.

Automatisch schalen is mogelijk niet geschikt voor batchtaken die te dicht bij elkaar plaatsvinden. De tijd die het kost om een cluster in te zetten brengt ook kosten met zich mee, dus als een batchworkload slechts enkele minuten na het einde van de vorige taak begint, kan het rendabeler zijn om het cluster tussen taken te laten draaien.

Azure Machine Learning Compute ondersteunt ook virtuele machines met lage prioriteit, waarmee u uw berekening kunt uitvoeren op virtuele machines met korting, met het nadeel dat ze op elk moment kunnen worden ver vervallen. Virtuele machines met lage prioriteit zijn ideaal voor niet-kritieke workloads voor batchscores.

De oplossing implementeren

Als u deze referentiearchitectuur wilt implementeren, volgt u de stappen die worden beschreven in GitHub -repo.

Notitie

U kunt ook een architectuur voor batch scoren implementeren voor Deep Learning-modellen met behulp van de Azure Kubernetes Service. Volg de stappen die in deze GitHub worden beschreven.