vorheriger Artikel
Der PoC ist gemacht, ein produktionsreifes Modell wurde trainiert und der Showcase hat alle Stakeholder:innen begeistert. Doch damit sich nun auch Business Cases mit dem Modell realisieren lassen, bedarf es einer Einbettung des Modells (und der Prozessierung) in die bestehende (Cloud-)Landschaft.
Die Grundschritte der Bildprozessierung
Der Umgang mit Bild- und Videodateien bringt im Vergleich zu strukturierten Daten völlig neue Herausforderungen mit sich. Das richtige Framework kann dabei unterstützen, diese Herausforderungen schnellstmöglich zu bewältigen und so eine einfache Implementierung der Bildprozessierung zu realisieren.
Bilddateien werden in aller Regel im Stream verarbeitet. Dabei durchläuft jedes Bild einzeln den vollständigen Prozess. Dieser lässt sich grundsätzlich in vier verschiedene logische Grundschritte unterteilen:
Prepare: Das Bild wirdfür die folgenden Verarbeitungsschritte vorbereitet. Hierbei wird zunächst die Bilddatei (aus dem Blob-Storage) geladen. Anschließend werden die für die Analyse notwendigen Anpassungen an dem Bild vorgenommen. Dies kann beispielsweise eine Größenanpassung oder ein Zurechtschneiden des Bildes sein. Im Anschluss erfolgt häufig eine base64-Kodierung für den folgenden Verarbeitungsschritt.
Analyse: Das Bild wird im nächsten Schritt (in aller Regel mit ML-Modellen) automatisiert analysiert. Hierfür wird das Modell zumeist über eine REST-API bereitgestellt. Im Analyse-Schritt wird der base64-enkodierte String an diese Schnittstelle gesendet. Die Antwort enthält das Ergebnis der Analyse – beispielsweise die erkannte Klasse des Bildes oder die Koordinaten von bestimmten Objekten im Bild.
Transform: Vor der dauerhaften Speicherung findet optional eine Transformation des Bildes statt. Diese erfolgt entweder auf Basis der Analyseergebnisse (z. B. Entfernen von Gesichtern zur Anonymisierung) oder unabhängig davon (Reduzierung der Auflösung zur Einsparung von Speicherplatz).
Action: Abschließend werden Aktionen auf Basis der Analyseergebnisse ausgeführt. Hierzu gehört beispielsweise das dauerhafte Speichern von Bild- und Metadaten. Es können aber auch Nachrichten an Folgesysteme verschickt werden, um diese über die abgeschlossene Bildprozessierung zu informieren.
Die Bausteine der Prozessierung
Die Implementierung der einzelnen Verarbeitungsschritte ist heute dank der Public Cloud und den dort angebotenen (serverless) Services einfacher und standardisierter möglich als je zuvor. Doch damit die Bilder im Produktivbetrieb verarbeitet werden können, wird mehr benötigt als eine virtuelle Maschine. Eine robuste Architektur kann dabei aus folgenden Bausteinen bestehen:
Model Serving: Damit das trainierte Modell verwendet wird, muss es verfügbar gemacht werden. Hierfür wird in aller Regel eine REST-API benötigt, die das (enkodierte) Bild als Input bekommt und als Antwort die Analyseergebnisse zurückgibt. Alle Hyperscaler bieten Services an, die ein Deployment von Modellen einfach ermöglichen.
Message Broker: Damit neue Bilder robust prozessiert werden können, wird ein skalierbarer Messaging-Dienst benötigt. Der Upload eines Bildes kann so beispielsweise das Event sein, das die Veröffentlichung einer Nachricht auslöst. Die Nachricht triggert anschließend die asynchrone Prozessierung des Bildes.
Application: Es wird eine Instanz benötigt, die die vier Grundschritte der Prozessierung auf das Bild anwendet. Sofern die Schritte innerhalb eines Containers implementiert wurden, kann hierfür ein (serverless) Container Service verwendet werden.
Storage: Die dauerhafte Speicherung des Bildes erfolgt nach Abschluss der Analyse in einem Blob-Storage. Zusätzlich wird eine Datenbank benötigt, in der Metadaten des Bildes und Resultate der Analyse gespeichert werden können.
Artifacts: In der Artifact Registry werden die auszuführenden Container-Images abgelegt. Ebenfalls finden sich hier die selbst erstellten Python Packages, in denen der Code zur Prozessierung bereitgestellt wird. Diese werden beim Build des Containers importiert.
Monitoring: Um einen langfristig reibungslosen Betrieb zu ermöglichen, ist eine Überwachung der Prozessschritte notwendig. Bei dieser Überwachung werden Fehlermeldungen im Prozess erkannt (und gemeldet). Außerdem wird frühzeitig ersichtlich, falls sich beispielsweise die Vorhersagen der Modelle unerwartet verändern.
Wenn’s schnellgehen muss – synchrone Bildverarbeitung
Doch nicht in jedem Anwendungsfall ist eine Architektur wie die gezeigte sinnvoll. Im oberen Beispiel werden die Bilder asynchron verarbeitet – wann (und wie schnell) die Verarbeitung stattfindet, ist hier zweitrangig. Soll aber ein Computer-Vision-Modell beispielsweise in eine App eingebunden werden, muss die Verarbeitung mit einer geringen Latenz erfolgen. Um diesen Anforderungen gerecht zu werden, bedarf es somit Änderungen an der Architektur.
In diesem Fall ergibt es Sinn, die gesamte Verarbeitung in einen synchronen und einen asynchronen Teil zu trennen. Ein HTTP-Request löst die synchrone Verarbeitung aus. In diesem Teil werden nur jene Analysen durchgeführt, die unbedingt notwendig sind; bevor das Ergebnis der Analyse (beispielsweise die Bildklassifikation) zurückgegeben wird, wird zusätzlich die folgende asynchrone Verarbeitung mit der Veröffentlichung einer Nachricht im Message Broker ausgelöst.
Im asynchronen Teil der Prozessierung werden anschließend alle nicht zeitkritischen Schritte durchgeführt. In diesem Teil können ebenfalls Analysen durchgeführt werden (z. B. um zu verhindern, dass Bilder mit Gesichtern gespeichert werden). Anschließend können die Bilder und Stammdaten ebenso dauerhaft gespeichert werden.
Projektübergreifende Synergien nutzen
Natürlich können funktionsfähige Architekturen über die Oberfläche oder mit dem CLI des jeweiligen Hyperscalers aufgebaut werden. Dies bringt jedoch zwei Probleme mit sich:
- Ein manueller Aufbau der Infrastruktur ist fehleranfällig und später nur noch bedingt nachvollziehbar.
- Der Aufbau einer zweiten, identischen Infrastruktur (z. B. für ein weiteres Projekt) ist zeitaufwändig.
Aus diesem Grunde bietet es sich an, die Infrastruktur in einem Code (z. B. Terraform) zu definieren. So lassen sich projektübergreifende Synergien optimal nutzen und doppelte manuelle Aufwände bestmöglich vermeiden.
Du hast ein Computer-Vision-Modell (oder die Idee dazu), das nur darauf wartet, endlich produktiv eingesetzt zu werden? Lass uns planen, wie wir diese Herausforderung am besten gemeinsam meistern.
