Serverless Machine Learning mit AWS Lambda

Bei einem Garagen-Projekt im EnBW TechLab wurde mittels Machine Learning (ML) ein Prognosemodell entwickelt, um zu einem beliebigen Zeitpunkt einen „vernünftigen“ Marktpreis für Gas zu ermitteln. Der ermittelte Preis wird für die Bewertung von Marktrisiken herangezogen. Nachdem mehrere Ansätze ausprobiert, verschiedene Algorithmen getestet und eine ganze Reihe von Merkmalen aus den vorhandenen historischen Daten extrahiert worden waren, konnten wir tatsächlich ein solches Modell trainieren, welches eine gute Vorhersage des gesuchten Bewertungspreises lieferte.

Schnell entstand im Fachbereich der Wunsch, das Modell im Testbetrieb auch anzuwenden. Die Frage war nun: Wie stellen wir das Modell für einen Testbetrieb bereit? Bisher existierte es nur auf den Entwicklungsrechnern in Form von Code, numerischen Gewichtsfaktoren und Hyperparametern. Man muss man wissen, dass ein Garagen-Projekt üblicherweise nur 2 Wochen lang läuft und ein Großteil der Zeit bereits mit der Modellentwicklung verstrichen war.

Als Antwort wurde eine Serverless Architektur auf Basis von Amazon Webservices (AWS) entwickelt. Die Besonderheit dieser Architektur ist die ausschließliche Verwendung von AWS Lambda Funktionen und PaaS Services für Storage, Konfiguration, APIs, Events. Mit dem in wenigen Tagen entstandenen System kann

  • die Prognose des täglichen Bewertungspreises abgefragt werden (das ist der Haupt-Einsatzzweck des ML-Modells)
  • ein automatisches Re-Training einer neuen Modellvariante mit neuen Daten ausgelöst werden (damit das Modell aus neuen Daten weiter dazulernt)
  • Qualitätsmetriken der verschiedenen Modellvarianten abgerufen werden (damit man beurteilen kann, wie gut das neue Modell ist)
  • eine Modellvariante als das aktuell gültige Modell deployt werden

Das System wurde als Infrastructure as Code realisiert und kann in wenigen Minuten auf jeden beliebigen AWS Account ausgerollt werden.

Hier ein Schaubild der Architektur:

Die wichtigsten Komponenten und ihre Funktion im Einzelnen:

API Gateway

Das API Gateway stellt nach außen die REST Schnittstellen bereit, mit denen die einzelnen Funktionen aufgerufen werden können. Das sind
/predict – Vorhersage aufgrund aktueller Daten abrufen
/metadata – Qualitätsmetriken zu verschiedenen Modellvarianten abfragen
/deploy – Eine bestimmte Modellvariante (identifiziert über eine UUID) für die Vorhersage auswählen.

Um eine neue Modellvariante automatisch zu erstellen (also ein Training mit neuen Daten durchzuführen) genügt es, neue Trainingsdaten in den S3-Bucket Trainingsdaten hochzuladen.

Lambda Funktionen

  • vorhersagen: Ruft die aktuell deployte Modellvariante mit den übergebenem Datensatz auf und liefert den neuen Bewertungspreis. Gleichzeitig wird jeder Aufruf im S3-Bucket Archiv gespeichert, damit die Daten für offline-Analysen zur Verfügung stehen. Welches das aktuelle Modell ist, liest die Funktion aus dem AWS Parameter Store. Wird durch den REST-Aufruf von /predict ausgelöst.
  • Modell deployen: Schreibt neue Konfigurationsdaten in den AWS Parameter Store und definiert damit, welches Modell verwendet wird. Wird durch den REST-Aufruf von /deploy ausgelöst.
  • Metadaten abfragen: Liefert Informationen über die vorhandenen Modelle, insbesondere über die beim Training ermittelten Qualitätsmetriken. Wird durch den REST-Aufruf von /metadata ausgelöst.
  • Modell trainieren: Führt ein Training mit den auf dem S3-Bucket Trainingsdaten hinterlegten Daten durch und erstellt somit eine neue Modellvariante, die im S3-Bucket Modelle abgelegt wird. Die Funktion wird durch neue Daten in Trainingsdaten ausgelöst.

Persistenter Speicher

  • Archiv (S3 Bucket): Speichert alle Anfragen an /predict und die Ergebnisse für spätere Analysen.
  • Parameter Store (Parameter Store): Speichert Laufzeitparameter als Key/Value Paare.
  • Modelle (S3 Bucket): Speichert die trainierten Modelle (Gewichtsfaktoren + Hyperparameter)
  • Trainingsdaten (S3 Bucket): Speichert die Trainingsdaten; werden hierhin neue Daten hochgeladen, löst dies automatisch ein neues Training aus.
  • Modell-Metadaten (Dynamo DB): Speichert alle Metadaten + Metriken zu den trainierten Modellen

Alle Komponenten sind Standard PaaS Services von AWS. Die Laufzeitkosten bestehen aus Storage-Kosten und Compute-Kosten für das API-Gateway und die Lambda-Funktionen – also ein reines „pay-per-use“.

Infrastructure-as-code

Die komplette Architektur liegt in Form von deploybarem Code in einem Git-Repository und es ist jederzeit möglich, sie per Script auf einem beliebigen AWS Account auszurollen. Hierzu wurde das Serverless Framework (https://serverless.com/framework/) eingesetzt, dass den Großteil des erforderlichen Scriptings übernimmt, so dass man im Grunde nur noch die Infrastruktur über Konfigurationsdateien deklariert (bei Serverless sind dies .yaml Dateien; das Format ist gut dokumentiert).

Fazit

Innerhalb kürzester Zeit (ca. 3 Tage) konnte die beschriebene Architektur umgesetzt werden. Für den Probebetrieb mit nur wenigen Aufrufen pro Tag fallen nur sehr geringe Kosten an.

Da nur PaaS Services verwendet werden und keine Server gewartet oder administriert werden müssen, ist der administrative Aufwand minimal.

Das Serverless Framework ermöglicht im Zusammenspiel mit AWS CloudFormation zudem eine sehr schnelle Umsetzung von Infrastructure-as-code in rekordverdächtiger Zeit.

Was für einen produktiven Betrieb fehlt ist ein (ernsthaftes) Monitoring der Anwendung inklusive Überwachung der Kosten sowie eine systematische Beurteilung der Modellmetriken durch den Fachbereich, z. B. in Form eines grafischen Dashboards.

Weiterhin müssen die Sicherheitseinstellungen der einzelnen Komponenten noch eingehender überprüft und an vielen Stellen eingeschränkt werden, da einzelne Komponenten noch zu viel Rechte haben (geschuldet der knappen Umsetzungszeit). AWS bietet hier entsprechende Hilfsmittel zur Analyse an.


© Copyright | Datenschutz