MLOps am Rand mit Amazon SageMaker Edge Manager und AWS IoT Greengrass

Das Internet der Dinge (IoT) hat es Kunden in zahlreichen Branchen wie Fertigung, Automobil und Energie ermöglicht, reale Umgebungen zu überwachen und zu steuern. Durch den Einsatz einer Vielzahl von Edge-IoT-Geräten wie Kameras, Thermostaten und Sensoren können Sie Daten sammeln, an die Cloud senden und Modelle für maschinelles Lernen (ML) erstellen, um Anomalien, Ausfälle und mehr vorherzusagen. Wenn der Anwendungsfall jedoch eine Echtzeitvorhersage erfordert, müssen Sie Ihre IoT-Lösung mit ML-am-Edge-Funktionen (ML@Edge) anreichern. ML@Edge ist ein Konzept, das den Lebenszyklus des ML-Modells vom Lebenszyklus der App entkoppelt und es Ihnen ermöglicht, eine End-to-End-ML-Pipeline auszuführen, die Datenvorbereitung, Modellerstellung, Modellkompilierung und -optimierung, Modellbereitstellung (auf eine Flotte von Edge-Geräten) umfasst. Modellausführung und Modellüberwachung und -steuerung. Sie stellen die App einmal bereit und führen die ML-Pipeline so oft wie nötig aus.

Wie Sie sich vorstellen können, ist es nicht trivial, alle vom ML@Edge-Konzept vorgeschlagenen Schritte umzusetzen. Es gibt viele Fragen, die sich Entwickler stellen müssen, um eine vollständige ML@Edge-Lösung zu implementieren, zum Beispiel:

• Wie betreibe ich ML-Modelle auf einer Flotte (Hunderte, Tausende oder Millionen) von Geräten am Edge?
• Wie sichere ich mein Modell, während ich es am Edge bereitstelle und ausführe?
• Wie überwache ich die Leistung meines Modells und trainiere es bei Bedarf neu?

In diesem Beitrag erfahren Sie, wie Sie all diese Fragen beantworten und eine End-to-End-Lösung für die Automatisierung Ihrer ML@Edge-Pipeline erstellen. Sie werden sehen, wie man es benutzt Amazon SageMaker Edge-Manager, Amazon SageMaker-Studio und AWS IoT Greengrass v2 um eine MLOps-Umgebung (ML Operations) zu erstellen, die den Prozess der Erstellung und Bereitstellung von ML-Modellen für große Flotten von Edge-Geräten automatisiert.

In den nächsten Abschnitten stellen wir eine Referenzarchitektur vor, die alle Komponenten und Workflows beschreibt, die zum Erstellen einer vollständigen Lösung für MLOps mit Schwerpunkt auf Edge-Workloads erforderlich sind. Dann tauchen wir tief in die Schritte ein, die diese Lösung automatisch ausführt, um ein neues Modell zu erstellen und vorzubereiten. Wir zeigen Ihnen auch, wie Sie die Edge-Geräte vorbereiten, um mit der Bereitstellung, Ausführung und Überwachung von ML-Modellen zu beginnen, und demonstrieren, wie Sie die auf Ihrer Geräteflotte bereitgestellten ML-Modelle überwachen und warten.

Lösungsüberblick

Die Produktion robuster ML-Modelle erfordert die Zusammenarbeit mehrerer Personen, wie z. B. Datenwissenschaftler, ML-Ingenieure, Dateningenieure und Geschäftsbeteiligte, in einer halbautomatischen Infrastruktur nach bestimmten Vorgängen (MLOps). Auch die Modularisierung der Umgebung ist wichtig, um all diesen verschiedenen Personas die Flexibilität und Agilität zu geben, die Komponente, für die sie verantwortlich sind, (unabhängig vom Workflow) zu entwickeln oder zu verbessern. Ein Beispiel für eine solche Infrastruktur besteht aus mehreren AWS-Konten, die diese Zusammenarbeit und Produktion der ML-Modelle sowohl in der Cloud als auch auf den Edge-Geräten ermöglichen. In der folgenden Referenzarchitektur zeigen wir, wie wir die mehreren Konten und Dienste organisiert haben, aus denen sich diese End-to-End-MLOps-Plattform zum Erstellen von ML-Modellen und deren Bereitstellung am Edge zusammensetzt.

Diese Lösung besteht aus den folgenden Konten:

• Data Lake-Konto – Data Engineers erfassen, speichern und bereiten Daten aus mehreren Datenquellen vor, darunter lokale Datenbanken und IoT-Geräte.
• Werkzeugkonto – IT-Operatoren verwalten und prüfen CI/CD-Pipelines für die automatisierte kontinuierliche Bereitstellung und Bereitstellung von ML-Modellpaketen über die Vorproduktions- und Produktionskonten für Remote-Edge-Geräte. Läufe von CI/CD-Pipelines werden durch die Verwendung von automatisiert Amazon EventBridge, das Änderungsstatusereignisse von ML-Modellen und -Zielen überwacht AWS CodePipeline.
• Experimentier- und Entwicklungskonto – Datenwissenschaftler können mit mehreren Modellierungstechniken und Algorithmen forschen und experimentieren, um Geschäftsprobleme auf der Grundlage von ML zu lösen und Proof-of-Concept-Lösungen zu erstellen. ML-Ingenieure und Datenwissenschaftler arbeiten zusammen, um einen Proof of Concept zu skalieren und automatisierte Workflows zu erstellen Amazon SageMaker-Pipelines um Daten vorzubereiten und ML-Modelle zu erstellen, zu trainieren und zu verpacken. Die Bereitstellung der Pipelines wird über CI/CD-Pipelines gesteuert, während die Versionskontrolle der Modelle mithilfe von erreicht wird Amazon SageMaker-Modellregistrierung. Data Scientists werten die Metriken mehrerer Modellversionen aus und fordern die Heraufstufung des besten Modells in die Produktion an, indem sie die CI/CD-Pipeline auslösen.
• Vorproduktionskonto – Vor der Beförderung des Modells in die Produktionsumgebung muss das Modell getestet werden, um die Robustheit in einer Simulationsumgebung sicherzustellen. Daher ist die Vorproduktionsumgebung ein Simulator der Produktionsumgebung, in der SageMaker-Modellendpunkte automatisch bereitgestellt und getestet werden. Testmethoden können einen Integrationstest, Stresstest oder ML-spezifische Tests zu Inferenzergebnissen umfassen. In diesem Fall ist die Produktionsumgebung kein SageMaker-Modellendpunkt, sondern ein Edge-Gerät. Um ein Edge-Gerät in der Vorproduktion zu simulieren, sind zwei Ansätze möglich: Verwenden Sie eine Amazon Elastic Compute-Cloud (Amazon EC2)-Instanz mit den gleichen Hardwaremerkmalen oder verwenden Sie eine Testumgebung im Labor, die aus den tatsächlichen Geräten besteht. Mit dieser Infrastruktur stellt die CI/CD-Pipeline das Modell für den entsprechenden Simulator bereit und führt die mehreren Tests automatisch durch. Nachdem die Tests erfolgreich ausgeführt wurden, muss die CI/CD-Pipeline manuell genehmigt werden (z. B. vom IoT-Stakeholder, um das Modell in die Produktion zu bringen).
• Produktionskonto – Beim Hosten des Modells in der AWS Cloud stellt die CI/CD-Pipeline einen SageMaker-Modellendpunkt auf dem Produktionskonto bereit. In diesem Fall besteht die Produktionsumgebung aus mehreren Flotten von Edge-Geräten. Daher verwendet die CI/CD-Pipeline Edge Manager, um die Modelle auf der entsprechenden Geräteflotte bereitzustellen.
• Edge-Geräte – Remote-Edge-Geräte sind Hardwaregeräte, die ML-Modelle mit Edge Manager ausführen können. Es ermöglicht der Anwendung auf diesen Geräten, die Modelle zu verwalten, Rückschlüsse auf die Modelle zu ziehen und Daten sicher zu erfassen Amazon Simple Storage-Service (Amazon S3).

SageMaker-Projekte helfen Ihnen, den Prozess der Bereitstellung von Ressourcen in jedem dieser Konten zu automatisieren. Wir tauchen nicht tief in diese Funktion ein, aber um mehr darüber zu erfahren, wie Sie eine SageMaker-Projektvorlage erstellen, die ML-Modelle kontenübergreifend bereitstellt, lesen Sie weiter Bereitstellung eines Modells mit mehreren Konten mit Amazon SageMaker Pipelines.

Vorproduktionskonto: Digitaler Zwilling

Nach dem Trainingsprozess muss das resultierende Modell evaluiert werden. Im Vorproduktionskonto haben Sie ein simuliertes Edge-Gerät. Es repräsentiert die digitaler Zwilling des Edge-Geräts, auf dem das ML-Modell in der Produktion läuft. Diese Umgebung hat den doppelten Zweck, die klassischen Tests (wie Unit, Integration und Smoke) durchzuführen und eine Spielwiese für das Entwicklungsteam zu sein. Dieses Gerät wird mithilfe einer EC2-Instanz simuliert, in der alle zur Verwaltung des ML-Modells erforderlichen Komponenten bereitgestellt wurden.

Die beteiligten Dienste sind wie folgt:

• AWS IoT-Kern - Wir gebrauchen AWS IoT-Kern um AWS IoT-Objekte zu erstellen, eine Geräteflotte zu erstellen, die Geräteflotte zu registrieren, damit sie mit der Cloud interagieren kann, X.509-Zertifikate zu erstellen, um Edge-Geräte bei AWS IoT Core zu authentifizieren, den Rollenalias mit AWS IoT Core zu verknüpfen, das wann generiert wurde die Flotte erstellt hat, einen AWS-kontospezifischen Endpunkt für den Anmeldeinformationsanbieter abrufen, eine offizielle Amazon-Root-CA-Datei abrufen und die Amazon-CA-Datei auf Amazon S3 hochladen.
• Amazon Sagemaker Neo – Sagemaker Neo optimiert automatisch maschinelle Lernmodelle für die Inferenz, damit sie ohne Genauigkeitsverlust schneller ausgeführt werden. Es unterstützt Machine-Learning-Modelle, die bereits mit DarkNet, Keras, MXNet, PyTorch, TensorFlow, TensorFlow-Lite, ONNX oder XGBoost erstellt und in Amazon SageMaker oder anderswo trainiert wurden. Dann wählen Sie Ihre Ziel-Hardwareplattform aus, die eine SageMaker-Hosting-Instanz oder ein Edge-Gerät basierend auf Prozessoren von Ambarella, Apple, ARM, Intel, MediaTek, Nvidia, NXP, Qualcomm, RockChip, Texas Instruments oder Xilinx sein kann.
• Edge-Manager – Wir verwenden Edge Manager, um das Edge-Gerät innerhalb der Sagemaker-Flotten zu registrieren und zu verwalten. Flotten sind Sammlungen logisch gruppierter Geräte, die Sie zum Sammeln und Analysieren von Daten verwenden können. Außerdem verpackt Edge Manager Packager das optimierte Modell und erstellt eine AWS IoT Greengrass V2-Komponente, die direkt bereitgestellt werden kann. Sie können Edge Manager verwenden, um ML-Modelle auf einer Flotte von intelligenten Kameras, intelligenten Lautsprechern, Robotern und anderen Flotten von SageMaker-Geräten zu betreiben.
• AWS IoT Greengrass V2 - AWS IoT Greengrass ermöglicht Ihnen die Bereitstellung von Komponenten auf den simulierten Geräten mithilfe einer EC2-Instance. Durch die Verwendung des AWS IoT Greengrass V2-Agenten in den EC2-Instances können wir den Zugriff, die Verwaltung und die Bereitstellung des Edge Manager-Agenten und -Modells auf Geräten vereinfachen. Ohne AWS IoT Greengrass V2 müssen Sie zum Einrichten von Geräten und Flotten für die Verwendung von Edge Manager den Agenten manuell aus einem S3-Release-Bucket kopieren. Mit der AWS IoT Greengrass V2- und Edge Manager-Integration ist es möglich, AWS IoT Greengrass V2-Komponenten zu verwenden. Komponenten sind vorgefertigte Softwaremodule, die Edge-Geräte über AWS IoT Greengrass mit AWS-Diensten oder Diensten von Drittanbietern verbinden können.
• Edge Manager-Agent – Der Edge Manager-Agent wird über AWS IoT Greengrass V2 in der EC2-Instance bereitgestellt. Der Agent kann mehrere Modelle gleichzeitig laden und Rückschlüsse auf geladene Modelle auf Edge-Geräten ziehen. Die Anzahl der Modelle, die der Agent laden kann, wird durch den verfügbaren Speicher auf dem Gerät bestimmt.
• Amazon S3 – Wir verwenden einen S3-Bucket, um die vom Edge Manager-Agent erfassten Inferenzdaten zu speichern.

Wir können ein Vorproduktionskonto als digitalen Zwilling zum Testen von ML-Modellen definieren, bevor sie in echte Edge-Geräte verschoben werden. Dies bietet folgende Vorteile:

• Beweglichkeit und Flexibilität – Datenwissenschaftler und ML-Ingenieure müssen schnell validieren, ob das ML-Modell und die zugehörigen Skripte (Vorverarbeitungs- und Inferenzskripte) am Geräterand funktionieren. IoT- und Data-Science-Abteilungen in großen Unternehmen können jedoch unterschiedliche Einheiten sein. Durch die identische Replikation des Technologie-Stacks in der Cloud können Data Scientists und ML-Ingenieure Artefakte vor der Bereitstellung iterieren und konsolidieren.
• Beschleunigte Risikobewertung und Produktionszeit – Die Bereitstellung auf dem Edge-Gerät ist die letzte Phase des Prozesses. Nachdem Sie alles in einer isolierten und eigenständigen Umgebung validiert haben, stellen Sie sicher, dass es den vom Edge geforderten Spezifikationen in Bezug auf Qualität, Leistung und Integration entspricht. Dies trägt dazu bei, eine weitere Beteiligung anderer Personen in der IoT-Abteilung zu vermeiden, um Artefaktversionen zu reparieren und zu iterieren.
• Verbesserte Zusammenarbeit im Team und verbesserte Qualität und Leistung – Das Entwicklungsteam kann die Auswirkungen des ML-Modells sofort bewerten, indem es Edge-Hardware-Metriken analysiert und das Ausmaß der Interaktionen mit Tools von Drittanbietern (z. B. E/A-Rate) misst. Dann ist das IoT-Team nur für die Bereitstellung in der Produktionsumgebung verantwortlich und kann sicher sein, dass die Artefakte für eine Produktionsumgebung genau sind.
• Integrierter Spielplatz zum Testen – Angesichts des Ziels von ML-Modellen sollte die Vorproduktionsumgebung in einem traditionellen Workflow durch ein Edge-Gerät außerhalb der Cloud-Umgebung dargestellt werden. Dies führt zu einer weiteren Ebene der Komplexität. Integrationen sind erforderlich, um Metriken und Feedback zu sammeln. Stattdessen werden durch die Verwendung der simulierten Umgebung des digitalen Zwillings Interaktionen reduziert und die Markteinführungszeit verkürzt.

Produktionskonto und Edge-Umgebung

Nachdem die Tests abgeschlossen sind und die Artefaktstabilität erreicht ist, können Sie über die Pipelines mit der Produktionsbereitstellung fortfahren. Die Artefaktbereitstellung erfolgt programmgesteuert, nachdem ein Bediener das Artefakt genehmigt hat. Allerdings Zugriff auf die AWS-Managementkonsole wird Betreibern im schreibgeschützten Modus gewährt, um mit den Flotten verbundene Metadaten überwachen zu können und somit Einblick in die Version des bereitgestellten ML-Modells und andere mit dem Lebenszyklus verbundene Metriken zu erhalten.

Edge-Geräteflotten gehören zum AWS-Produktionskonto. Dieses Konto verfügt über spezifische Sicherheits- und Netzwerkkonfigurationen, um die Kommunikation zwischen der Cloud und Edge-Geräten zu ermöglichen. Die wichtigsten AWS-Services, die im Produktionskonto bereitgestellt werden, sind Edge Manager, der für die Verwaltung aller Geräteflotten, das Sammeln von Daten und den Betrieb von ML-Modellen verantwortlich ist, und AWS IoT Core, das IoT-Ding-Objekte, Zertifikate, Rollen-Alias ​​und Endpunkte verwaltet.

Gleichzeitig müssen wir ein Edge-Gerät mit den Diensten und Komponenten konfigurieren, um ML-Modelle zu verwalten. Die Hauptkomponenten sind wie folgt:

• AWS IoT Greengrass V2
• Ein Edge Manager-Agent
• AWS IoT-Zertifikate
• Application.py, das für die Orchestrierung des Inferenzprozesses verantwortlich ist (Abrufen von Informationen aus der Edge-Datenquelle und Durchführen von Inferenzen mithilfe des Edge Manager-Agents und des geladenen ML-Modells)
• Eine Verbindung zu Amazon S3 oder dem Data Lake-Konto, um abgeleitete Daten zu speichern

Automatisierte ML-Pipeline

Nachdem Sie nun mehr über die Organisation und die Komponenten der Referenzarchitektur wissen, können wir tiefer in die ML-Pipeline eintauchen, die wir zum Erstellen, Trainieren und Evaluieren des ML-Modells innerhalb des Entwicklungskontos verwenden.

Eine Pipeline (erstellt mit Amazon SageMaker-Modellerstellungspipelines) ist eine Reihe miteinander verbundener Schritte, die durch eine JSON-Pipelinedefinition definiert sind. Diese Pipeline-Definition codiert eine Pipeline unter Verwendung eines gerichteten azyklischen Graphen (DAG). Dieser DAG enthält Informationen zu den Anforderungen und Beziehungen zwischen den einzelnen Schritten Ihrer Pipeline. Die Struktur des DAG einer Pipeline wird durch die Datenabhängigkeiten zwischen den Schritten bestimmt. Diese Datenabhängigkeiten werden erstellt, wenn die Eigenschaften der Ausgabe eines Schritts als Eingabe an einen anderen Schritt übergeben werden.

Damit Data-Science-Teams die Erstellung neuer Versionen von ML-Modellen einfach automatisieren können, ist es wichtig, Validierungsschritte und automatisierte Daten zum kontinuierlichen Einspeisen und Verbessern von ML-Modellen sowie Modellüberwachungsstrategien zum Aktivieren von Pipeline-Triggern einzuführen. Das folgende Diagramm zeigt eine Beispielpipeline.

Um Automatisierungen und MLOps-Funktionen zu ermöglichen, ist es wichtig, modulare Komponenten zum Erstellen wiederverwendbarer Codeartefakte zu erstellen, die über verschiedene Schritte und ML-Anwendungsfälle hinweg gemeinsam genutzt werden können. Dadurch können Sie die Implementierung schnell von einer Experimentierphase in eine Produktionsphase verschieben, indem Sie den Übergang automatisieren.

Die Schritte zum Definieren einer ML-Pipeline zum Ermöglichen des kontinuierlichen Trainings und der Versionierung von ML-Modellen sind wie folgt:

• Anarbeitung – Der Prozess der Datenbereinigung, Feature-Engineering und Datensatzerstellung zum Trainieren des ML-Algorithmus
• Ausbildung – Der Prozess des Trainierens des entwickelten ML-Algorithmus zum Generieren einer neuen Version des ML-Modellartefakts
• Evaluierung – Der Prozess der Bewertung des generierten ML-Modells zum Extrahieren wichtiger Metriken in Bezug auf das Modellverhalten auf neuen Daten, die während der Trainingsphase nicht gesehen wurden
• Registrierung: – Der Prozess der Versionierung des neu trainierten ML-Modellartefakts durch Verknüpfen der extrahierten Metriken mit dem generierten Artefakt

Weitere Einzelheiten zum Erstellen einer SageMaker-Pipeline finden Sie im Folgenden Notizbuch.

Lösen Sie CI/CD-Pipelines mit EventBridge aus

Wenn Sie das Erstellen des Modells abgeschlossen haben, können Sie den Bereitstellungsprozess starten. Der letzte Schritt der im vorherigen Abschnitt definierten SageMaker-Pipeline registriert eine neue Version des Modells in der spezifischen SageMaker-Modellregistrierungsgruppe. Die Bereitstellung einer neuen Version des ML-Modells wird mithilfe des Modellregistrierungsstatus verwaltet. Durch manuelles Genehmigen oder Ablehnen einer ML-Modellversion löst dieser Schritt ein Ereignis aus, das von EventBridge erfasst wird. Dieses Ereignis kann dann eine neue Pipeline (diesmal CI/CD) zum Erstellen einer neuen Version der AWS IoT Greengrass-Komponente starten, die dann für die Vorproduktions- und Produktionskonten bereitgestellt wird. Der folgende Screenshot zeigt unsere definierte EventBridge-Regel.

Diese Regel überwacht die SageMaker-Modellpaketgruppe, indem sie im Status nach Aktualisierungen von Modellpaketen sucht Approved or Rejected.

Die EventBridge-Regel wird dann so konfiguriert, dass sie auf CodePipeline abzielt, wodurch der Workflow zum Erstellen einer neuen AWS IoT Greengrass-Komponente mithilfe von gestartet wird Amazon SageMaker Neo und Edge-Manager.

Optimieren Sie ML-Modelle für die Zielarchitektur

Mit Neo können Sie ML-Modelle für die Durchführung von Inferenzen auf Edge-Geräten (und in der Cloud) optimieren. Es optimiert automatisch die ML-Modelle für eine bessere Leistung basierend auf der Zielarchitektur und entkoppelt das Modell vom ursprünglichen Framework, sodass Sie es auf einer schlanken Laufzeit ausführen können.

Beachten Sie Folgendes Notizbuch ein Beispiel für die Kompilierung eines PyTorch Resnet18-Modells mit Neo.

Erstellen Sie das Bereitstellungspaket, indem Sie die AWS IoT Greengrass-Komponente einbeziehen

Mit Edge Manager können Sie Modelle auf einer Flotte von Edge-Geräten verwalten, sichern, bereitstellen und überwachen. Im Folgenden Notizbuch, können Sie weitere Details zum Aufbau einer minimalistischen Flotte von Edge-Geräten sehen und einige Experimente mit dieser Funktion durchführen.

Nachdem Sie die Flotte konfiguriert und das Modell kompiliert haben, müssen Sie einen Edge Manager-Verpackungsauftrag ausführen, der das Modell für die Bereitstellung in der Flotte vorbereitet. Sie können einen Verpackungsauftrag mit dem Boto3 SDK starten. Für unsere Parameter verwenden wir das optimierte Modell und die Modellmetadaten. Durch Hinzufügen der folgenden Parameter zu OutputConfig, bereitet der Job auch eine AWS IoT Greengrass V2-Komponente mit dem Modell vor:

• PresetDeploymentType
• PresetDeploymentConfig

Siehe folgenden 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}
        ),
    }
)

Stellen Sie ML-Modelle in großem Umfang am Edge bereit

Jetzt ist es an der Zeit, das Modell auf Ihrer Flotte von Edge-Geräten bereitzustellen. Zuerst müssen wir sicherstellen, dass wir das Notwendige haben AWS Identity and Access Management and (ICH BIN) Berechtigungen unsere IoT-Geräte bereitstellen und Komponenten darauf bereitstellen können. Wir benötigen zwei grundlegende Elemente, um mit dem Onboarding von Geräten in unsere IoT-Plattform zu beginnen:

• IAM-Richtlinie – Diese Richtlinie ermöglicht die automatische Bereitstellung solcher Geräte, die dem Benutzer oder der Rolle zugeordnet sind, die die Bereitstellung durchführt. Es sollte über IoT-Schreibberechtigungen verfügen, um das IoT-Ding und die Gruppe zu erstellen und die erforderlichen Richtlinien an das Gerät anzuhängen. Weitere Informationen finden Sie unter Minimale IAM-Richtlinie für das Installationsprogramm zum Bereitstellen von Ressourcen.
• IAM-Rolle – Diese Rolle ist den IoT-Dingen und -Gruppen zugeordnet, die wir erstellen. Sie können diese Rolle zum Zeitpunkt der Bereitstellung mit grundlegenden Berechtigungen erstellen, aber es fehlen Funktionen wie der Zugriff auf Amazon S3 oder AWS-Schlüsselverwaltungsservice (AWS KMS), die später benötigt werden könnten. Sie können diese Rolle im Voraus erstellen und wiederverwenden, wenn wir das Gerät bereitstellen. Weitere Informationen finden Sie unter Autorisieren Sie Core-Geräte für die Interaktion mit AWS.

Installation und Bereitstellung von AWS IoT Greengrass

Nachdem wir die IAM-Richtlinie und -Rolle eingerichtet haben, sind wir bereit Installieren Sie die AWS IoT Greengrass Core-Software mit automatischer Ressourcenbereitstellung. Obwohl es möglich ist, die IoT-Ressourcen mithilfe manueller Schritte bereitzustellen, gibt es das praktische Verfahren, diese Ressourcen während der Installation des AWS IoT Greengrass v2-Nukleus automatisch bereitzustellen. Dies ist die bevorzugte Option, um neue Geräte schnell in die Plattform einzubinden. Neben default-jdk, andere Pakete müssen installiert werden, wie z curl, unzip und python3.

Wenn wir unser Gerät bereitstellen, muss der Name des IoT-Dings genau mit dem in Edge Manager definierten Edge-Gerät übereinstimmen, da sonst keine Daten im S3-Ziel-Bucket erfasst werden.

Das Installationsprogramm kann die AWS IoT Greengrass-Rolle und den Alias ​​während der Installation erstellen, wenn sie nicht vorhanden sind. Sie werden jedoch mit minimalen Berechtigungen erstellt und erfordern das manuelle Hinzufügen weiterer Richtlinien, um mit anderen Diensten wie Amazon S3 zu interagieren. Wir empfehlen, diese IAM-Ressourcen wie zuvor gezeigt im Voraus zu erstellen und sie dann wiederzuverwenden, wenn Sie neue Geräte in das Konto integrieren.

Paketierung von Modell- und Inferenzkomponenten

Nachdem unser Code entwickelt wurde, können wir sowohl den Code (für die Inferenz) als auch unsere ML-Modelle als Komponenten in unseren Geräten bereitstellen.

Nachdem das ML-Modell in SageMaker trainiert wurde, können Sie das Modell mit Neo mithilfe eines Sagemaker-Kompilierungsjobs optimieren. Die resultierenden kompilierten Modellartefakte können dann mit dem Edge Manager Packager in eine GreenGrass V2-Komponente gepackt werden. Dann kann es als benutzerdefinierte Komponente in der registriert werden Meine Komponenten Abschnitt auf der AWS IoT Greengrass-Konsole. Diese Komponente enthält bereits die notwendigen Lebenszyklusbefehle zum Herunterladen und Dekomprimieren des Modellartefakts in unserem Gerät, damit der Inferenzcode es laden kann, um die damit erfassten Bilder zu senden.

In Bezug auf den Inferenzcode müssen wir eine Komponente mit der Konsole oder erstellen AWS-Befehlszeilenschnittstelle (AWS-CLI). Zuerst packen wir unseren Quell-Inferenzcode und die notwendigen Abhängigkeiten zu Amazon S3. Nachdem wir den Code hochgeladen haben, können wir unsere Komponente mithilfe eines Rezepts in .yaml oder JSON wie im folgenden Beispiel erstellen:

---
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

Dieses Beispielrezept zeigt den Namen und die Beschreibung unserer Komponente sowie die notwendigen Voraussetzungen vor unserem Befehl zum Ausführen des Skripts. Das Rezept entpackt das Artefakt in einer Arbeitsordnerumgebung auf dem Gerät, und wir verwenden diesen Pfad, um unseren Inferenzcode auszuführen. Der AWS CLI-Befehl zum Erstellen eines solchen Rezepts lautet:

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

Sie können diese erstellte Komponente jetzt auf der AWS IoT Greengrass-Konsole sehen.

Beachten Sie, dass die Komponentenversion wichtig ist und in der Rezeptdatei angegeben werden muss. Das Wiederholen derselben Versionsnummer gibt einen Fehler zurück.

Nachdem unser Modell und unser Inferenzcode als Komponenten eingerichtet wurden, können wir sie bereitstellen.

Stellen Sie die Anwendung und das Modell mit AWS IoT Greengrass bereit

In den vorherigen Abschnitten haben Sie gelernt, wie Sie den Rückschlusscode und die ML-Modelle packen. Jetzt können wir eine Bereitstellung mit mehreren Komponenten erstellen, die sowohl Komponenten als auch Konfigurationen enthalten, die für unseren Inferenzcode erforderlich sind, um mit dem Modell im Edge-Gerät zu interagieren.

Der Edge Manager-Agent ist die Komponente, die auf jedem Edge-Gerät installiert werden sollte, um alle Edge Manager-Funktionen zu aktivieren. Auf der SageMaker-Konsole haben wir eine Geräteflotte definiert, die einen zugehörigen S3-Bucket hat. Alle mit der Flotte verbundenen Edge-Geräte erfassen ihre Daten und melden sie an diesen S3-Pfad. Der Agent kann als Komponente in AWS IoT Greengrass v2 bereitgestellt werden, was die Installation und Konfiguration vereinfacht, als wenn der Agent im Standalone-Modus bereitgestellt würde. Beim Bereitstellen des Agenten als Komponente müssen wir seine Konfigurationsparameter angeben, nämlich die Geräteflotte und den S3-Pfad.

Wir erstellen eine Bereitstellungskonfiguration mit den benutzerdefinierten Komponenten für das gerade erstellte Modell und den Code. Dieses Setup wird in einer JSON-Datei definiert, die den Bereitstellungsnamen und das Ziel sowie die Komponenten in der Bereitstellung auflistet. Wir können die Konfigurationsparameter jeder Komponente hinzufügen und aktualisieren, z. B. im Edge Manager-Agenten, wo wir den Flottennamen und den Bucket angeben.

{
    "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"
        }
    }
}

Es ist erwähnenswert, dass wir nicht nur das Modell, die Inferenzkomponenten und den Agenten hinzugefügt haben, sondern auch die AWS IoT Greengrass CLI und den Kern als Komponenten. Ersteres kann dabei helfen, bestimmte Bereitstellungen lokal auf dem Gerät zu debuggen. Letzteres wird der Bereitstellung hinzugefügt, um bei Bedarf den erforderlichen Netzwerkzugriff vom Gerät selbst zu konfigurieren (z. B. Proxy-Einstellungen) und auch für den Fall, dass Sie ein OTA-Upgrade des AWS IoT Greengrass v2-Kerns durchführen möchten. Der Kern wird nicht bereitgestellt, da er auf dem Gerät installiert ist, und es wird nur das Konfigurationsupdate angewendet (es sei denn, es ist ein Upgrade vorhanden). Zum Bereitstellen müssen wir einfach den folgenden Befehl über die vorherige Konfiguration ausführen. Denken Sie daran, den Ziel-ARN einzurichten, auf den die Bereitstellung angewendet wird (ein IoT-Ding oder eine IoT-Gruppe). Wir können diese Komponenten auch über die Konsole bereitstellen.

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

Überwachen und verwalten Sie am Edge bereitgestellte ML-Modelle

Jetzt, da Ihre Anwendung auf den Edge-Geräten ausgeführt wird, ist es an der Zeit zu verstehen, wie die Flotte überwacht werden kann, um Governance, Wartung und Sichtbarkeit zu verbessern. Wählen Sie in der SageMaker-Konsole Edge-Manager im Navigationsbereich und wählen Sie dann aus Edge-Geräteflotten. Wählen Sie hier Ihre Flotte aus.

Auf der Detailseite der Flotte können Sie einige Metadaten der Modelle sehen, die auf jedem Gerät Ihrer Flotte ausgeführt werden. Der Flottenbericht wird alle 24 Stunden erstellt.

Daten, die von jedem Gerät über den Edge Agent erfasst werden, werden im JSON-Zeilenformat (JSONL) an einen S3-Bucket gesendet. Der Prozess des Sendens erfasster Daten wird von einem Anwendungsstandpunkt verwaltet. Es steht Ihnen daher frei, ob, wie und wie oft Sie diese Daten übermitteln.

Sie können diese Daten für viele Dinge verwenden, z. B. zum Überwachen von Datendrift und Modellqualität, zum Erstellen eines neuen Datasets, zum Anreichern eines Data Lake und für mehr. Ein einfaches Beispiel für die Verwendung dieser Daten ist, wenn Sie eine Datenabweichung in der Art und Weise feststellen, wie Benutzer mit Ihrer Anwendung interagieren, und Sie ein neues Modell trainieren müssen. Anschließend erstellen Sie ein neues Dataset mit den erfassten Daten und kopieren es zurück in das Entwicklungskonto. Dadurch kann automatisch eine neue Ausführung Ihrer Umgebung gestartet werden, die ein neues Modell erstellt und es für die gesamte Flotte erneut bereitstellt, um die Leistung der bereitgestellten Lösung beizubehalten.

Zusammenfassung

In diesem Beitrag haben Sie gelernt, wie Sie eine vollständige Lösung erstellen, die MLOps und ML@Edge mit AWS-Services kombiniert. Das Erstellen einer solchen Lösung ist nicht trivial, aber wir hoffen, dass die in diesem Beitrag vorgestellte Referenzarchitektur Sie inspirieren und Ihnen helfen kann, eine solide Architektur für Ihre eigenen geschäftlichen Herausforderungen zu erstellen. Sie können auch nur die Teile oder Module dieser Architektur verwenden, die sich in Ihre vorhandene MLOps-Umgebung integrieren lassen. Indem Sie jeweils ein einzelnes Modul prototypisieren und die entsprechenden AWS-Services verwenden, um jeden Teil dieser Herausforderung anzugehen, können Sie lernen, wie Sie eine robuste MLOps-Umgebung aufbauen und auch die endgültige Architektur weiter vereinfachen.

Als nächsten Schritt empfehlen wir Ihnen, Sagemaker Edge Manager auszuprobieren, um Ihren ML-at-Edge-Lebenszyklus zu verwalten. Weitere Informationen zur Funktionsweise von Edge Manager finden Sie unter Stellen Sie Modelle mit SageMaker Edge Manager am Edge bereit .

Über die Autoren

Bruno Piston ist ein AI/ML Specialist Solutions Architect für AWS mit Sitz in Mailand. Er arbeitet mit Kunden jeder Größe zusammen, um ihnen dabei zu helfen, ihre technischen Anforderungen genau zu verstehen und KI- und maschinelle Lernlösungen zu entwickeln, die die AWS Cloud und den Amazon Machine Learning-Stack optimal nutzen. Seine Fachgebiete sind Machine Learning End-to-End, Machine Learning Industrialization und MLOps. Er genießt es, Zeit mit seinen Freunden zu verbringen, neue Orte zu erkunden und zu neuen Zielen zu reisen.

Matteo Calabrese ist AI/ML Customer Delivery Architect im AWS Professional Services-Team. Er arbeitet mit großen EMEA-Unternehmen an KI/ML-Projekten und hilft ihnen beim Vorschlagen, Entwerfen, Bereitstellen, Skalieren und Optimieren von ML-Produktions-Workloads. Seine Hauptkompetenzen sind ML Operation (MLOps) und Machine Learning at Edge. Sein Ziel ist es, die Zeit bis zur Wertschöpfung zu verkürzen und Geschäftsergebnisse zu beschleunigen, indem er Best Practices für AWS bereitstellt. In seiner Freizeit wandert und reist er gerne.

Raúl Díaz García ist Senior Data Scientist im AWS Professional Services-Team. Er arbeitet mit großen Unternehmenskunden in ganz EMEA zusammen, wo er ihnen hilft, Lösungen im Zusammenhang mit Computer Vision und maschinellem Lernen im IoT-Bereich zu entwickeln.

Sokratis Kartakis ist ein Senior Machine Learning Specialist Solutions Architect für Amazon Web Services. Sokratis konzentriert sich darauf, Unternehmenskunden zu ermöglichen, ihre Lösungen für maschinelles Lernen (ML) zu industrialisieren, indem sie AWS-Services nutzen und ihr Betriebsmodell, dh die MLOps-Grundlage, und ihre Transformations-Roadmap unter Nutzung bewährter Entwicklungspraktiken gestalten. Er hat über 15 Jahre damit verbracht, innovative End-to-End-Lösungen für ML und Internet of Things (IoT) auf Produktionsebene in den Bereichen Energie, Einzelhandel, Gesundheit, Finanzen/Banken, Motorsport usw. zu erfinden, zu entwerfen, zu leiten und zu implementieren. Seine Freizeit verbringt Sokratis gerne mit Familie und Freunden oder beim Motorradfahren.

Samir Araújo ist AI / ML Solutions Architect bei AWS. Er hilft Kunden bei der Erstellung von AI / ML-Lösungen, die ihre geschäftlichen Herausforderungen mithilfe von AWS lösen. Er hat an mehreren AI / ML-Projekten gearbeitet, die sich mit Computer Vision, Verarbeitung natürlicher Sprache, Prognose, ML am Rande und vielem mehr befassen. In seiner Freizeit spielt er gerne mit Hardware- und Automatisierungsprojekten und hat ein besonderes Interesse an Robotik.