MLOps At The Edge met Amazon SageMaker Edge Manager en AWS IoT Greengrass

Heruitgegeven door Plato

volgers: 0

Internet of Things (IoT) heeft klanten in meerdere industrieën, zoals productie, automobiel en energie, in staat gesteld om real-world omgevingen te bewaken en te besturen. Door een verscheidenheid aan edge IoT-apparaten zoals camera's, thermostaten en sensoren in te zetten, kunt u gegevens verzamelen, naar de cloud verzenden en machine learning-modellen (ML) bouwen om afwijkingen, storingen en meer te voorspellen. Als de use-case echter realtime voorspelling vereist, moet u uw IoT-oplossing verrijken met ML-at-the-edge (ML@Edge)-mogelijkheden. ML@Edge is een concept dat de levenscyclus van het ML-model loskoppelt van de levenscyclus van de app en waarmee u een end-to-end ML-pijplijn kunt uitvoeren die gegevensvoorbereiding, modelbouw, modelcompilatie en -optimalisatie, modelimplementatie (naar een vloot van edge-apparaten) omvat, modeluitvoering en modelbewaking en -beheer. U implementeert de app één keer en voert de ML-pijplijn zo vaak uit als nodig is.

Zoals u zich kunt voorstellen, is het niet triviaal om alle stappen te implementeren die worden voorgesteld door het ML@Edge-concept. Er zijn veel vragen die ontwikkelaars moeten beantwoorden om een complete ML@Edge-oplossing te implementeren, bijvoorbeeld:

Hoe bedien ik ML-modellen op een vloot (honderden, duizenden of miljoenen) apparaten aan de rand?
Hoe beveilig ik mijn model terwijl ik het aan de rand implementeer en laat draaien?
Hoe kan ik de prestaties van mijn model bewaken en zo nodig bijscholen?

In dit bericht leert u hoe u al deze vragen kunt beantwoorden en een end-to-end oplossing kunt bouwen voor het automatiseren van uw ML@Edge-pijplijn. U zult zien hoe u het moet gebruiken Amazon SageMaker Edge Manager, Amazon SageMaker Studio en AWS IoT Greengrass v2 om een MLOps-omgeving (ML Operations) te creëren die het proces van het bouwen en implementeren van ML-modellen op grote vloten van edge-apparaten automatiseert.

In de volgende secties presenteren we een referentiearchitectuur met details over alle componenten en workflows die nodig zijn om een complete oplossing voor MLOps te bouwen die is gericht op edge-workloads. Vervolgens duiken we diep in de stappen die deze oplossing automatisch uitvoert om een nieuw model te bouwen en voor te bereiden. We laten u ook zien hoe u de edge-apparaten voorbereidt om te beginnen met het implementeren, uitvoeren en bewaken van ML-modellen, en demonstreren hoe u de ML-modellen die op uw apparaatpark zijn geïmplementeerd, kunt bewaken en onderhouden.

Overzicht oplossingen

De productie van robuuste ML-modellen vereist de samenwerking van meerdere persona's, zoals datawetenschappers, ML-ingenieurs, data-ingenieurs en zakelijke belanghebbenden, onder een semi-geautomatiseerde infrastructuur na specifieke bewerkingen (MLOp's). Ook de modularisering van de omgeving is belangrijk om al deze verschillende persona's de flexibiliteit en wendbaarheid te geven om (onafhankelijk van de workflow) het onderdeel waarvoor ze verantwoordelijk zijn te ontwikkelen of te verbeteren. Een voorbeeld van een dergelijke infrastructuur bestaat uit meerdere AWS-accounts die deze samenwerking en productie van de ML-modellen mogelijk maken, zowel in de cloud als naar de edge-apparaten. In de volgende referentiearchitectuur laten we zien hoe we de meerdere accounts en services hebben georganiseerd die dit end-to-end MLOps-platform vormen voor het bouwen van ML-modellen en het implementeren ervan aan de rand.

Deze oplossing bestaat uit de volgende accounts:

Data Lake-account – Data-engineers nemen gegevens op, slaan ze op en bereiden ze voor uit meerdere gegevensbronnen, waaronder on-premise databases en IoT-apparaten.
Tooling-account – IT-operators beheren en controleren CI/CD-pijplijnen voor geautomatiseerde continue levering en implementatie van ML-modelpakketten in de pre-productie- en productieaccounts voor externe edge-apparaten. Runs van CI/CD-pipelines worden geautomatiseerd door het gebruik van: Amazon EventBridge, die wijzigingsstatusgebeurtenissen van ML-modellen en doelen bewaakt AWS CodePipeline.
Experiment- en ontwikkelingsaccount – Datawetenschappers kunnen onderzoek doen en experimenteren met meerdere modelleringstechnieken en algoritmen om zakelijke problemen op basis van ML op te lossen en proof-of-concept-oplossingen te creëren. ML-ingenieurs en datawetenschappers werken samen om een proof of concept te schalen en geautomatiseerde workflows te creëren met behulp van Amazon SageMaker-pijpleidingen om gegevens voor te bereiden en ML-modellen te bouwen, te trainen en te verpakken. De implementatie van de pijplijnen wordt aangestuurd via CI/CD-pijplijnen, terwijl het versiebeheer van de modellen wordt bereikt met behulp van de Amazon SageMaker-modelregister. Gegevenswetenschappers evalueren de statistieken van meerdere modelversies en vragen om promotie van het beste model naar productie door de CI/CD-pijplijn te activeren.
Pre-productie account – Voordat het model naar de productieomgeving wordt gepromoveerd, moet het model worden getest om de robuustheid in een simulatieomgeving te garanderen. Daarom is de preproductieomgeving een simulator van de productieomgeving, waarin SageMaker-modeleindpunten automatisch worden geïmplementeerd en getest. Testmethoden kunnen een integratietest, stresstest of ML-specifieke tests op inferentieresultaten omvatten. In dit geval is de productieomgeving geen SageMaker-modeleindpunt, maar een edge-apparaat. Om een edge device in pre-productie te simuleren, zijn twee benaderingen mogelijk: gebruik een Amazon Elastic Compute-cloud (Amazon EC2) instantie met dezelfde hardwarekenmerken, of gebruik een in-lab testbed dat bestaat uit de daadwerkelijke apparaten. Met deze infrastructuur implementeert de CI/CD-pipeline het model in de bijbehorende simulator en voert de meerdere tests automatisch uit. Nadat de tests met succes zijn uitgevoerd, vereist de CI/CD-pijplijn handmatige goedkeuring (bijvoorbeeld van de IoT-belanghebbende om het model naar productie te promoten).
productie account – In het geval van het hosten van het model op de AWS Cloud, implementeert de CI/CD-pijplijn een SageMaker-modeleindpunt op het productieaccount. In dit geval bestaat de productieomgeving uit meerdere vloten van edge devices. Daarom gebruikt de CI/CD-pijplijn Edge Manager om de modellen te implementeren op de overeenkomstige apparatenvloot.
Edge-apparaten – Externe edge-apparaten zijn hardwareapparaten die ML-modellen kunnen uitvoeren met Edge Manager. Het stelt de applicatie op die apparaten in staat om de modellen te beheren, conclusies te trekken tegen de modellen en gegevens veilig vast te leggen in Amazon eenvoudige opslagservice (Amazone S3).

SageMaker-projecten u helpen bij het automatiseren van het proces van het inrichten van resources binnen elk van deze accounts. We duiken niet diep in deze functie, maar voor meer informatie over het bouwen van een SageMaker-projectsjabloon die ML-modellen voor meerdere accounts implementeert, gaat u naar Implementatie van meerdere accounts met Amazon SageMaker Pipelines.

Pre-productie account: Digital twin

Na het trainingsproces moet het resulterende model worden geëvalueerd. In het pre-productie-account heb je een gesimuleerd Edge-apparaat. Het vertegenwoordigt de digitale tweeling van het edge-apparaat waarop het ML-model in productie draait. Deze omgeving heeft het dubbele doel om de klassieke tests uit te voeren (zoals unit, integratie en rook) en om een speeltuin te zijn voor het ontwikkelteam. Dit apparaat wordt gesimuleerd met behulp van een EC2-instantie waarin alle componenten die nodig zijn om het ML-model te beheren, zijn geïmplementeerd.

De betrokken diensten zijn als volgt:

AWS IoT-kern - We gebruiken AWS IoT-kern om AWS IoT-dingsobjecten te maken, een apparaatvloot te maken, de apparaatvloot te registreren zodat deze kan communiceren met de cloud, X.509-certificaten te maken om edge-apparaten te authenticeren voor AWS IoT Core, de rolalias te associëren met AWS IoT Core die werd gegenereerd toen de vloot heeft gemaakt, een AWS-accountspecifiek eindpunt voor de referentieprovider krijgen, een officieel Amazon Root CA-bestand krijgen en het Amazon CA-bestand uploaden naar Amazon S3.
Amazon Sagemaker Neo- Saliemaker Neo optimaliseert automatisch machine learning-modellen voor inferentie om sneller te werken zonder verlies van nauwkeurigheid. Het ondersteunt een machine learning-model dat al is gebouwd met DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX of XGBoost en is getraind in Amazon SageMaker of ergens anders. Vervolgens kiest u uw doelhardwareplatform, dat een SageMaker-hostinginstantie of een edge-apparaat kan zijn op basis van processors van Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments of Xilinx.
Edge-manager – We gebruiken Edge Manager om het edge-apparaat binnen de Sagemaker-vloten te registreren en te beheren. Vloten zijn verzamelingen van logisch gegroepeerde apparaten die u kunt gebruiken om gegevens te verzamelen en te analyseren. Bovendien verpakt Edge Manager-packer het geoptimaliseerde model en maakt een AWS IoT Greengrass V2-component die direct kan worden ingezet. U kunt Edge Manager gebruiken om ML-modellen te bedienen op een reeks slimme camera's, slimme luidsprekers, robots en andere vloten van SageMaker-apparaten.
AWS IoT Greengrass V2 - AWS IoT Greengrass stelt u in staat om componenten in de gesimuleerde apparaten te implementeren met behulp van een EC2-instantie. Door de AWS IoT Greengrass V2-agent in de EC2-instanties te gebruiken, kunnen we de toegang, het beheer en de implementatie van de Edge Manager-agent en het model naar apparaten vereenvoudigen. Zonder AWS IoT Greengrass V2 vereist het instellen van apparaten en vloten voor het gebruik van Edge Manager dat u de agent handmatig uit een S3-release-bucket kopieert. Met AWS IoT Greengrass V2 en Edge Manager-integratie is het mogelijk om AWS IoT Greengrass V2-componenten te gebruiken. Componenten zijn vooraf gebouwde softwaremodules die edge-apparaten kunnen verbinden met AWS-services of services van derden via AWS IoT Greengrass.
Edge Manager-agent – De Edge Manager-agent wordt ingezet via AWS IoT Greengrass V2 in de EC2-instantie. De agent kan meerdere modellen tegelijk laden en conclusies trekken met geladen modellen op edge-apparaten. Het aantal modellen dat de agent kan laden, wordt bepaald door het beschikbare geheugen op het apparaat.
Amazon S3 - We gebruiken een S3-bucket om de inferentie vastgelegde gegevens van de Edge Manager-agent op te slaan.

We kunnen een pre-productie-account definiëren als een digitale tweeling voor het testen van ML-modellen voordat we ze naar echte edge-apparaten verplaatsen. Dit biedt de volgende voordelen:

Wendbaarheid en flexibiliteit – Datawetenschappers en ML-engineers moeten snel valideren of het ML-model en bijbehorende scripts (preprocessing en inferentiescripts) aan de rand van het apparaat werken. De afdelingen IoT en datawetenschap in grote ondernemingen kunnen echter verschillende entiteiten zijn. Door de technologiestack in de cloud identiek te repliceren, kunnen datawetenschappers en ML-engineers artefacten herhalen en consolideren voorafgaand aan de implementatie.
Versnelde risicobeoordeling en productietijd – Implementatie op het edge-apparaat is de laatste fase van het proces. Nadat u alles in een geïsoleerde en op zichzelf staande omgeving hebt gevalideerd, moet u ervoor zorgen dat het voldoet aan de specificaties die door de edge worden vereist op het gebied van kwaliteit, prestaties en integratie. Dit helpt om verdere betrokkenheid van andere mensen in de IoT-afdeling te voorkomen om artefactversies te repareren en te herhalen.
Verbeterde teamsamenwerking en verbeterde kwaliteit en prestaties – Het ontwikkelingsteam kan de impact van het ML-model onmiddellijk beoordelen door edge-hardwarestatistieken te analyseren en het niveau van interactie met tools van derden te meten (bijv. I/O-snelheid). Vervolgens is het IoT-team alleen verantwoordelijk voor de implementatie in de productieomgeving en kan het erop vertrouwen dat de artefacten nauwkeurig zijn voor een productieomgeving.
Geïntegreerde speeltuin om te testen – Gezien het doel van ML-modellen, moet de pre-productieomgeving in een traditionele workflow worden vertegenwoordigd door een edge-apparaat buiten de cloudomgeving. Dit introduceert een ander niveau van complexiteit. Er zijn integraties nodig om statistieken en feedback te verzamelen. In plaats daarvan, door gebruik te maken van de gesimuleerde digitale tweelingomgeving, worden interacties verminderd en wordt de time-to-market verkort.

Productieaccount en edge-omgeving

Nadat de tests zijn voltooid en de artefactstabiliteit is bereikt, kunt u doorgaan met de productie-implementatie via de pijplijnen. De implementatie van een artefact vindt programmatisch plaats nadat een operator het artefact heeft goedgekeurd. Echter, toegang tot de AWS-beheerconsole wordt verleend aan operators in de alleen-lezen modus om metadata geassocieerd met de wagenparken te kunnen monitoren en daardoor inzicht te hebben in de versie van het ingezette ML-model en andere metrieken die verband houden met de levenscyclus.

Edge-apparaatvloten behoren tot het AWS-productieaccount. Dit account heeft specifieke beveiligings- en netwerkconfiguraties om communicatie tussen de cloud en edge-apparaten mogelijk te maken. De belangrijkste AWS-services die in het productieaccount worden ingezet, zijn Edge Manager, dat verantwoordelijk is voor het beheer van alle apparaatvloten, het verzamelen van gegevens en het bedienen van ML-modellen, en AWS IoT Core, dat IoT-dingsobjecten, certificaten, rolalias en eindpunten beheert.

Tegelijkertijd moeten we een edge-apparaat configureren met de services en componenten om ML-modellen te beheren. De belangrijkste componenten zijn als volgt:

AWS IoT Greengrass V2
Een Edge Manager-agent
AWS IoT-certificaten
Application.py, dat verantwoordelijk is voor het orkestreren van het inferentieproces (het ophalen van informatie uit de edge-gegevensbron en het uitvoeren van inferentie met behulp van de Edge Manager-agent en het geladen ML-model)
Een verbinding met Amazon S3 of het data lake-account om afgeleide gegevens op te slaan

Geautomatiseerde ML-pijplijn

Nu je meer weet over de organisatie en de componenten van de referentiearchitectuur, kunnen we dieper in de ML-pijplijn duiken die we gebruiken om het ML-model binnen het ontwikkelaccount te bouwen, trainen en evalueren.

Een pijplijn (gebouwd met behulp van Amazon SageMaker Modelbouwpijpleidingen) is een reeks onderling verbonden stappen die wordt gedefinieerd door een JSON-pijplijndefinitie. Deze pijplijndefinitie codeert een pijplijn met behulp van een Directed Acyclic Graph (DAG). Deze DAG geeft informatie over de vereisten voor en relaties tussen elke stap van uw pijplijn. De structuur van de DAG van een pijplijn wordt bepaald door de gegevensafhankelijkheden tussen stappen. Deze gegevensafhankelijkheden worden gemaakt wanneer de eigenschappen van de uitvoer van een stap worden doorgegeven als invoer voor een andere stap.

Om datawetenschapsteams in staat te stellen eenvoudig het maken van nieuwe versies van ML-modellen te automatiseren, is het belangrijk om validatiestappen en geautomatiseerde gegevens te introduceren voor het continu invoeren en verbeteren van ML-modellen, evenals strategieën voor modelbewaking om pijplijntriggering mogelijk te maken. In het volgende diagram ziet u een voorbeeld van een pijplijn.

Voor het inschakelen van automatiseringen en MLOps-mogelijkheden is het belangrijk om modulaire componenten te maken voor het maken van herbruikbare code-artefacten die kunnen worden gedeeld in verschillende stappen en ML-gebruiksscenario's. Hierdoor kunt u de implementatie snel van een experimenteerfase naar een productiefase verplaatsen door de overgang te automatiseren.

De stappen voor het definiëren van een ML-pijplijn om continue training en versiebeheer van ML-modellen mogelijk te maken, zijn als volgt:

Voorverwerking – Het proces van gegevensopschoning, feature-engineering en het maken van datasets voor het trainen van het ML-algoritme
Trainingen – Het proces van het trainen van het ontwikkelde ML-algoritme voor het genereren van een nieuwe versie van het ML-modelartefact
Evaluatie – Het evaluatieproces van het gegenereerde ML-model, voor het extraheren van belangrijke statistieken met betrekking tot het modelgedrag op nieuwe gegevens die niet zijn gezien tijdens de trainingsfase
Registratie – Het proces van het versiebeheer van het nieuwe getrainde ML-modelartefact door de geëxtraheerde metrieken te koppelen aan het gegenereerde artefact

Hieronder vindt u meer details over het bouwen van een SageMaker-pijplijn: notitieboekje.

Activeer CI/CD-pipelines met EventBridge

Wanneer u klaar bent met het bouwen van het model, kunt u het implementatieproces starten. De laatste stap van de SageMaker-pijplijn die in de vorige sectie is gedefinieerd, registreert een nieuwe versie van het model in de specifieke SageMaker-modelregistergroep. De implementatie van een nieuwe versie van het ML-model wordt beheerd met behulp van de modelregistratiestatus. Door handmatig een ML-modelversie goed te keuren of af te wijzen, roept deze stap een gebeurtenis op die wordt vastgelegd door EventBridge. Dit evenement kan vervolgens een nieuwe pijplijn starten (CI/CD deze keer) voor het maken van een nieuwe versie van de AWS IoT Greengrass-component die vervolgens wordt geïmplementeerd in de pre-productie- en productieaccounts. De volgende schermafbeelding toont onze gedefinieerde EventBridge-regel.

Deze regel bewaakt de SageMaker-modelpakketgroep door te zoeken naar updates van modelpakketten in de status Approved or Rejected.

De EventBridge-regel wordt vervolgens geconfigureerd om CodePipeline te targeten, waarmee de workflow wordt gestart voor het maken van een nieuwe AWS IoT Greengrass-component met behulp van Amazon SageMaker Neo en Edgemanager.

Optimaliseer ML-modellen voor de doelarchitectuur

Met Neo kunt u ML-modellen optimaliseren voor het uitvoeren van inferentie op edge-apparaten (en in de cloud). Het optimaliseert automatisch de ML-modellen voor betere prestaties op basis van de doelarchitectuur en ontkoppelt het model van het oorspronkelijke framework, zodat u het op een lichtgewicht runtime kunt uitvoeren.

Raadpleeg het volgende: notitieboekje voor een voorbeeld van het compileren van een PyTorch Resnet18-model met Neo.

Stel het implementatiepakket samen door de AWS IoT Greengrass-component op te nemen

Met Edge Manager kunt u modellen beheren, beveiligen, implementeren en bewaken op een groot aantal edge-apparaten. In de volgende notitieboekje, kunt u meer details zien over hoe u een minimalistische vloot van edge-apparaten kunt bouwen en enkele experimenten met deze functie uitvoeren.

Nadat u het wagenpark hebt geconfigureerd en het model hebt gecompileerd, moet u een Edge Manager-verpakkingstaak uitvoeren, die het model voorbereidt op implementatie in het wagenpark. U kunt een inpaktaak starten met behulp van de Boto3 SDK. Voor onze parameters gebruiken we het geoptimaliseerde model en modelmetadata. Door de volgende parameters toe te voegen aan: OutputConfig, bereidt de baan ook een AWS IoT Greengrass V2-component voor met het model:

PresetDeploymentType
PresetDeploymentConfig

Zie de volgende code:

import boto3
import time

SageMaker_client = boto3.client('SageMaker')

SageMaker_client.create_edge_packaging_job(
    EdgePackagingJobName="mlops-edge-packaging-{}".format(int(time.time()*1000)),
    CompilationJobName=compilation_job_name,
    ModelName="PytorchMLOpsEdgeModel",
    ModelVersion="1.0.0",
    RoleArn=role,
    OutputConfig={
        'S3OutputLocation': 's3://{}/model/'.format(bucket_name),
        "PresetDeploymentType": "GreengrassV2Component",
        "PresetDeploymentConfig": json.dumps(
            {"ComponentName": component_name, "ComponentVersion": component_version}
        ),
    }
)

Implementeer ML-modellen aan de rand op schaal

Nu is het tijd om het model te implementeren in uw vloot van edge-apparaten. Ten eerste moeten we ervoor zorgen dat we de nodige AWS Identiteits- en toegangsbeheer (IAM) permissies om onze IoT-apparaten in te richten en er componenten op te implementeren. We hebben twee basiselementen nodig om apparaten in ons IoT-platform te introduceren:

IAM-beleid – Dit beleid zorgt voor de automatische voorziening van dergelijke apparaten, gekoppeld aan de gebruiker of rol die de voorziening uitvoert. Het moet IoT-schrijfrechten hebben om het IoT-ding en de groep te maken, en om het benodigde beleid aan het apparaat te koppelen. Voor meer informatie, zie: Minimaal IAM-beleid voor installatieprogramma om resources te leveren.
IAM-rol – deze rol is gekoppeld aan de IoT-dingen en -groepen die we creëren. Je kunt deze rol tijdens de inrichting maken met basisrechten, maar het zal functies missen zoals toegang tot Amazon S3 of AWS Sleutelbeheerservice (AWS KMS) die later nodig kan zijn. U kunt deze rol vooraf maken en opnieuw gebruiken wanneer we het apparaat inrichten. Voor meer informatie, zie: Kernapparaten autoriseren om te communiceren met AWS.

Installatie en levering van AWS IoT Greengrass

Nadat we het IAM-beleid en de rol hebben ingevoerd, zijn we klaar om: installeer AWS IoT Greengrass Core-software met automatische resourcevoorziening. Hoewel het mogelijk is om de IoT-bronnen in te richten door handmatige stappen te volgen, is er de handige procedure om deze bronnen automatisch te leveren tijdens de installatie van de AWS IoT Greengrass v2-kern. Dit is de voorkeursoptie om snel nieuwe apparaten in het platform te integreren. Daarnaast default-jdk, moeten andere pakketten worden geïnstalleerd, zoals: curl, unzip en python3.

Wanneer we ons apparaat inrichten, moet de naam van het IoT-ding exact hetzelfde zijn als het edge-apparaat dat is gedefinieerd in Edge Manager, anders worden gegevens niet vastgelegd naar de S3-doelbucket.

Het installatieprogramma kan de AWS IoT Greengrass-rol en alias maken tijdens de installatie als deze niet bestaan. Ze worden echter gemaakt met minimale machtigingen en vereisen handmatig meer beleid om te communiceren met andere services zoals Amazon S3. We raden u aan deze IAM-resources van tevoren te maken, zoals eerder aangegeven, en ze vervolgens opnieuw te gebruiken wanneer u nieuwe apparaten aan het account toevoegt.

Verpakking van model- en inferentiecomponenten

Nadat onze code is ontwikkeld, kunnen we zowel de code (voor inferentie) als onze ML-modellen als componenten in onze apparaten implementeren.

Nadat het ML-model is getraind in SageMaker, kunt u het model optimaliseren met Neo met behulp van een Sagemaker-compilatietaak. De resulterende gecompileerde modelartefacten kunnen vervolgens worden verpakt in een GreenGrass V2-component met behulp van de Edge Manager-packer. Vervolgens kan het worden geregistreerd als een gebruikerscomponent in de Mijn componenten sectie op de AWS IoT Greengrass-console. Dit onderdeel bevat al de nodige levenscyclusopdrachten om het modelartefact in ons apparaat te downloaden en te decomprimeren, zodat de inferentiecode het kan laden om de gemaakte afbeeldingen te verzenden.

Met betrekking tot de inferentiecode moeten we een component maken met behulp van de console of AWS-opdrachtregelinterface (AWS CLI). Eerst pakken we onze bronafleidingscode en noodzakelijke afhankelijkheden in op Amazon S3. Nadat we de code hebben geüpload, kunnen we onze component maken met behulp van een recept in .yaml of JSON, zoals in het volgende voorbeeld:

---
RecipeFormatVersion: 2020-01-25
ComponentName: dummymodel.inference
ComponentVersion: 0.0.1
ComponentDescription: Deploys inference code to a client
ComponentPublisher: Amazon Web Services, Inc.
ComponentDependencies:
  aws.GreenGrass.TokenExchangeService:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
  dummymodel:
    VersionRequirement: '>=0.0.0'
    DependencyType: HARD
Manifests:
  - Platform:
      os: linux
      architecture: "*"
    Lifecycle:
      install: |-
        apt-get install python3-pip
        pip3 install numpy
        pip3 install sysv_ipc
        pip3 install boto3
        pip3 install grpcio-tools
        pip3 install grpcio
        pip3 install protobuf
        pip3 install SageMaker
        tar xf {artifacts:path}/sourcedir.tar.gz
      run:
        script: |-
          sleep 5 && sudo python3 {work:path}/inference.py 
    Artifacts:
      - URI: s3://BUCKET-NAME/path/to/inference/sourcedir.tar.gz
        Permission:
          Execute: OWNER

Dit voorbeeldrecept toont de naam en beschrijving van onze component, evenals de noodzakelijke vereisten voor onze run scriptopdracht. Het recept pakt het artefact uit in een werkmapomgeving op het apparaat en we gebruiken dat pad om onze inferentiecode uit te voeren. De AWS CLI-opdracht om een dergelijk recept te maken is:

aws greengrassv2 create-component-version --region $REGION 
                                          --inline-recipe fileb://path/to/recipe.yaml

U kunt dit onderdeel nu zien gemaakt op de AWS IoT Greengrass-console.

Pas op voor het feit dat de componentversie van belang is en dat deze moet worden gespecificeerd in het receptbestand. Als u hetzelfde versienummer herhaalt, wordt een fout geretourneerd.

Nadat ons model en onze inferentiecode als componenten zijn ingesteld, zijn we klaar om ze te implementeren.

Implementeer de applicatie en het model met AWS IoT Greengrass

In de vorige secties hebt u geleerd hoe u de inferentiecode en de ML-modellen verpakt. Nu kunnen we een implementatie maken met meerdere componenten die zowel componenten als configuraties bevatten die nodig zijn om onze inferentiecode te laten communiceren met het model in het edge-apparaat.

De Edge Manager-agent is het onderdeel dat op elk edge-apparaat moet worden geïnstalleerd om alle Edge Manager-mogelijkheden in te schakelen. Op de SageMaker-console hebben we een apparaatvloot gedefinieerd, die een bijbehorende S3-bucket heeft. Alle edge-apparaten die aan de vloot zijn gekoppeld, zullen hun gegevens vastleggen en rapporteren aan dit S3-pad. De agent kan worden ingezet als een component in AWS IoT Greengrass v2, waardoor het eenvoudiger te installeren en configureren is dan wanneer de agent in stand-alone modus zou worden ingezet. Bij het implementeren van de agent als onderdeel, moeten we de configuratieparameters opgeven, namelijk het apparaatpark en het S3-pad.

We maken een implementatieconfiguratie met de aangepaste componenten voor het model en de code die we zojuist hebben gemaakt. Deze setup wordt gedefinieerd in een JSON-bestand waarin de naam en het doel van de implementatie worden vermeld, evenals de componenten in de implementatie. We kunnen de configuratieparameters van elk onderdeel toevoegen en bijwerken, zoals in de Edge Manager-agent, waar we de vlootnaam en bucket specificeren.

{
    "targetArn": "targetArn",
    "deploymentName": "dummy-deployment",
    "components": {
        "aws.GreenGrass.Nucleus": {
            "version": "2.5.3",
        },
        "aws.GreenGrass.Cli": {
            "version": "2.5.3"
        },
        "aws.GreenGrass.SageMakerEdgeManager": {
            "version": 1.1.0,
            "configurationUpdate": {
                "merge": {
                "DeviceFleetName": "FLEET-NAME",
                "BucketName": "BUCKET-NAME-URI"
                }
            }
        },
        "dummymodel.inference": {
            "version": "0.0.1"
        },
        "dummymodel": {
            "version": "0.0.1"
        }
    }
}

Het is vermeldenswaard dat we niet alleen het model, de inferentiecomponenten en de agent hebben toegevoegd, maar ook de AWS IoT Greengrass CLI en de kern als componenten. De eerste kan helpen bij het debuggen van bepaalde implementaties lokaal op het apparaat. De laatste wordt toegevoegd aan de implementatie om indien nodig de benodigde netwerktoegang vanaf het apparaat zelf te configureren (bijvoorbeeld proxy-instellingen), en ook voor het geval u een OTA-upgrade van de AWS IoT Greengrass v2-kern wilt uitvoeren. De kern wordt niet geïmplementeerd omdat deze op het apparaat is geïnstalleerd en alleen de configuratie-update wordt toegepast (tenzij er een upgrade is). Om te implementeren, hoeven we alleen de volgende opdracht uit te voeren over de voorgaande configuratie. Vergeet niet om de doel-ARN in te stellen waarop de implementatie wordt toegepast (een IoT-ding of IoT-groep). We kunnen deze componenten ook vanuit de console implementeren.

aws greengrassv2 create-deployment --region $REGION 
                                   --cli-input-json file://path/to/deployment.json

Monitor en beheer ML-modellen die tot aan de edge zijn geïmplementeerd

Nu uw toepassing op de edge-apparaten draait, is het tijd om te begrijpen hoe u de vloot kunt bewaken om het beheer, het onderhoud en de zichtbaarheid te verbeteren. Kies op de SageMaker-console Edge-manager in het navigatievenster en kies vervolgens Edge-apparaatvloten. Kies hier uw vloot.

Op de detailpagina van het wagenpark kunt u enkele metadata zien van de modellen die op elk apparaat van uw wagenpark draaien. Vlootrapport wordt elke 24 uur gegenereerd.

Gegevens die door elk apparaat worden vastgelegd via de Edge Agent, worden verzonden naar een S3-bucket in json-lijnen-indeling (JSONL). Het proces van het verzenden van vastgelegde gegevens wordt beheerd vanuit een applicatiestandpunt. U bent dus vrij om te beslissen of u deze gegevens verstuurt, hoe en hoe vaak.

U kunt deze gegevens voor veel dingen gebruiken, zoals het bewaken van gegevensdrift en modelkwaliteit, het bouwen van een nieuwe gegevensset, het verrijken van een datameer en meer. Een eenvoudig voorbeeld van hoe u deze gegevens kunt gebruiken, is wanneer u een gegevensafwijking identificeert in de manier waarop gebruikers omgaan met uw toepassing en u een nieuw model moet trainen. U bouwt vervolgens een nieuwe dataset met de vastgelegde gegevens en kopieert deze terug naar het ontwikkelaccount. Dit kan automatisch een nieuwe run van uw omgeving starten die een nieuw model bouwt en dit opnieuw implementeert in de hele vloot om de prestaties van de geïmplementeerde oplossing te behouden.

Conclusie

In dit bericht heb je geleerd hoe je een complete oplossing kunt bouwen die MLOps en ML@Edge combineert met behulp van AWS-services. Het bouwen van een dergelijke oplossing is niet triviaal, maar we hopen dat de referentiearchitectuur die in dit bericht wordt gepresenteerd, u kan inspireren en u kan helpen bij het bouwen van een solide architectuur voor uw eigen zakelijke uitdagingen. U kunt ook alleen de onderdelen of modules van deze architectuur gebruiken die integreren met uw bestaande MLOps-omgeving. Door één enkele module tegelijk te prototypen en de juiste AWS-services te gebruiken om elk onderdeel van deze uitdaging aan te pakken, kunt u leren hoe u een robuuste MLOps-omgeving kunt bouwen en ook de uiteindelijke architectuur verder kunt vereenvoudigen.

Als volgende stap raden we u aan om Sagemaker Edge Manager uit te proberen om uw ML at edge-levenscyclus te beheren. Voor meer informatie over hoe Edge Manager werkt, zie Implementeer modellen aan de rand met SageMaker Edge Manager .

Over de auteurs

Bruno Piston is een AI/ML Specialist Solutions Architect voor AWS gevestigd in Milaan. Hij werkt samen met klanten van elke omvang om hen te helpen hun technische behoeften grondig te begrijpen en AI- en Machine Learning-oplossingen te ontwerpen die optimaal gebruik maken van de AWS Cloud en de Amazon Machine Learning-stack. Zijn expertisegebieden zijn Machine Learning end-to-end, Machine Learning Industrialization en MLOps. Hij brengt graag tijd door met zijn vrienden en het verkennen van nieuwe plaatsen, maar ook van reizen naar nieuwe bestemmingen.

Matteo Calabrese is een AI/ML Customer Delivery Architect in het AWS Professional Services-team. Hij werkt met grote ondernemingen in EMEA aan AI/ML-projecten en helpt hen bij het voorstellen, ontwerpen, leveren, schalen en optimaliseren van ML-productieworkloads. Zijn belangrijkste expertises zijn ML Operation (MLOps) en Machine Learning bij Edge. Zijn doel is het verkorten van hun tijd om bedrijfsresultaten te waarderen en te versnellen door AWS best practices te bieden. In zijn vrije tijd houdt hij van wandelen en reizen.

Raúl Díaz García is een Sr Data Scientist in het AWS Professional Services-team. Hij werkt met grote zakelijke klanten in EMEA, waar hij hen helpt bij het mogelijk maken van oplossingen met betrekking tot Computer Vision en Machine Learning in de IoT-ruimte.

Sokratis Kartakis is een Senior Machine Learning Specialist Solutions Architect voor Amazon Web Services. Sokratis richt zich op het in staat stellen van zakelijke klanten om hun Machine Learning (ML)-oplossingen te industrialiseren door gebruik te maken van AWS-services en het vormgeven van hun bedrijfsmodel, dat wil zeggen de MLOps-basis, en transformatie-roadmap door gebruik te maken van de beste ontwikkelingspraktijken. Hij heeft meer dan 15 jaar besteed aan het uitvinden, ontwerpen, leiden en implementeren van innovatieve end-to-end ML- en Internet of Things (IoT)-oplossingen op productieniveau in de domeinen energie, detailhandel, gezondheid, financiën/bankieren, motorsport enz. Sokratis brengt zijn vrije tijd graag door met familie en vrienden, of motorrijden.

Samir Araújo is een AI / ML Solutions Architect bij AWS. Hij helpt klanten bij het creëren van AI / ML-oplossingen die hun zakelijke uitdagingen oplossen met behulp van AWS. Hij heeft gewerkt aan verschillende AI / ML-projecten met betrekking tot computervisie, natuurlijke taalverwerking, prognoses, ML aan de rand en meer. Hij speelt graag met hardware- en automatiseringsprojecten in zijn vrije tijd, en hij heeft een bijzondere interesse voor robotica.