Suchen

Microservices und Cloud-native Apps in der Praxis, Teil 1 Image Resizer mit AWS Lambda und API Gateway

Autor / Redakteur: Dipl. -Ing. Thomas Drilling / Stephan Augsten

Eine einheitliche User Experience über mehrere Gerätetypen hinweg ist nicht einfach umzusetzen. Für das Image Resizing eignen sich Microservices auf Basis von Function-as-a-Service hervorragend. Folgendes Beispiel stellt in zwei Beiträgen einen auf AWS Lambda-basierenden Image-Resizer vor, der On the Fly arbeitet.

Firma zum Thema

Für das Image Resizing eignen sich Microservices auf Basis von Function-as-a-Service hervorragend.
Für das Image Resizing eignen sich Microservices auf Basis von Function-as-a-Service hervorragend.
(Bild: geralt / Pixabay )

Zugegeben: Ein Image-Resizer ist quasi das Parade-Beispiel für den Einstieg in AWS Lambda. Daher haben zahlreiche Lambda-Tutorials bei AWS selbst oder Github eine solche Größenanpassung zum Thema. Zwei lohnenswerte Beispiele auf Github sind z. B. der Serverless Image Processor oder Lambda Resize Image.

In der grafischen Lambda-Console findet sich im Serverless App Repository z. B. der „image-resizer“. Wer einen solchen Service „in production“ betreiben möchte, dem empfiehlt AWS die Verwendung des Serverless Image Handlers, eine sogenannte „AWS Solution“. Dies sind von eignen Solution Architects erstellte und getestete CloudFormation-Vorlagen, die sich mit wenig Aufwand bereitstellen und einsetzen lassen.

Freilich besteht ein Unterschied zwischen einer einzelnen Lambda-Funktion als Microservice und einer voll funktionsfähigen serverlosen Anwendung. In diesem Tutorial präsentieren wir einen Entwurf für einen Image-Resizer, der sich von den Standard-Beispielen insofern abhebt, dass er „on-the-fly“ arbeitet, also direkt in den Anwendungsworkflow eingearbeitet ist, wozu der Dienst andere AWS-Dienste wie S3 und API Gateway integriert.

Die Idee basiert auf einen Blog-Eintrag im AWS Compute Blog. Der Code ist Open Source und im Github-Repo der Amazon Web Services Labs zu finden. Wir zeigen aber im zweiten Teil dieses Beitrags, wie man den Service Schritt für Schritt manuell aufbaut.

Größenänderung „On the fly“

Allen oben beschriebenen Lösungen haben gemein, dass die zu konvertierenden Bilder auf Amazon S3 hochgeladen werden und die S3-Ereignisbenachrichtigungsfunktion jeweils eine Lambda-Funktion triggert, womit sich ein Service realisieren lässt, der sozusagen „auf Vorrat“ jedes auf dem überwachten S3-Bucket hochgeladene Bild konvertiert, wenn es hochgeladen wird.

Der von uns vorgestellt Ansatz arbeitet hingegen „lazy“ und erstellt ein Asset mit geänderter Größe nur dann, wenn ein Benutzer diese bestimmte Größe anfordert. Anstatt also Bilder beim Hochladen zu verarbeiten und in alle potenziell erforderlichen Größen zu ändern, bietet der Ansatz, Bilder im laufenden Betrieb zu verarbeiten eine erhöhte Agilität, reduziert die Storage-Kosten und ist extrem widerstandsfähiger gegen Ausfälle. Was bedeutet das im Einzelfall?

Vorteile des On-the-Fly-Ansatzes

Überarbeitet etwa ein Entwickler seine Website, kann er schnell und einfach neue Dimensionen hinzufügen, anstatt das gesamte Archiv der gespeicherten Bilder erneut zu verarbeiten. Letzteres ist z. B. im Rahmen eines Batch-Prozesses in jedem Fall zeitaufwändig, kostspielig und fehleranfällig.

Mit unserem On-the-Fly-Ansatz können Entwickler stattdessen einen neuen Satz von Dimensionen angeben und einfach neue Assets in dem Moment generieren, in dem der Kunden die neue Website oder Anwendung nutzt. Ferner müssen die veränderten Bilder beim herkömmlichen Verfahren unbegrenzt gespeichert werden, da der Vorgang ja nur einmal ausgeführt wird. Beim On-the-Fly-Ansatz müssen Entwickler überhaupt keine Bilder speichern, die nicht vom Nutzer zugegriffen/angefordert werden.

Der On-the-Fly-Ansatz ist außerdem robuster. Dazu ein Beispiel: so helfen bekanntlich S3-Lebenszyklus-Regeln – etwa für automatisierten Ablaufdaten älterer Bilder – bei der Kosten-Optimierung, indem die Speicherkosten an die spezifischen Zugriffsmuster einer Anwendung angepasst sind, im Extremfall bis zum Ablauf. Versucht aber nun ein Benutzer auf ein Bild mit geänderter Größe zuzugreifen, das durch eine Lebenszyklusregel entfernt wurde, ändert die API automatisch die Größe, um die Anforderung dennoch zu erfüllen.

Widerstandsfähigkeit

Ein Best Practice-Ansatz im Cloud-Computing (nicht nur bei AWS) besteht bekanntlich darin, verteilte Dienste stets so zu entwerfen, dass man den möglichen Ausfall sämtlicher Komponenten von Vorneherein einkalkuliert. In unserem Beispiel heißt das: wird die Bildverarbeitung nur einmal bei der Objekterstellung ausgeführt, kann ein zeitweiliger Fehler in diesem Prozess oder ein Datenverlust bereits der verarbeiteten Bilder zu Fehlern für zukünftige Benutzer führen.

Ändert man die Größe von Bildern jedoch erst bei Bedarf, leitet jede Anforderung die Verarbeitung ein, sobald kein Bild mit passender Größe gefunden wird. Das bedeutet, dass zukünftige Anforderungen auch nach früheren Fehlern nichts ins Leere laufen. Folgende Abbildung illustriert, wie der Prozess in Gänze abläuft:

Die automatisierte Größenanpassung von Bildern lässt sich komplett innerhalb der AWS-Umgebung abbilden.
Die automatisierte Größenanpassung von Bildern lässt sich komplett innerhalb der AWS-Umgebung abbilden.
(Bild: AWS)

  • 1. Ein Benutzer fordert über seinen statischen Website-Hosting-Endpunkt für S3 ein Asset mit geänderter Größe vom Bucket an. Dieser verfügt dazu über eine Routing-Regel, die so konfiguriert ist, dass Anforderungen für ein nicht gefundenes Objekt automatisch an die Größenänderungs-API in API Gateway umgeleitet werden.
  • 2. Da das Asset mit geänderter Größe nicht im Bucket vorhanden ist, wird die Anforderung also vorübergehend an die API-Methode zur Größenänderung im AWS API-Gateway umgeleitet.
  • 3. Der Browser des Benutzers folgt demnach der Umleitung und fordert die Größenänderung über das API-Gateway an.
  • 4. Die API-Gateway-Methode ist so konfiguriert, dass sie eine Lambda-Funktion triggert, welche die Anforderung bedient, also das Resizing vornimmt.
  • 5. Sie lädt dazu zunächst das Originalbild aus dem S3-Bucket herunter, ändert die Größe und lädt das verkleinerte Bild in Form des ursprünglich angeforderten Schlüssels wieder in den Bucket hoch.
  • 6. Wenn die Lambda-Funktion abgeschlossen ist, leitet API Gateway den Benutzer dauerhaft zu der in S3 gespeicherten angepassten Datei um.
  • 7. Der Browser des Benutzers fordert also eigentlich das jetzt verfügbare Bild mit geänderter Größe aus dem S3-Bucket an. Nachfolgende Anforderungen von Diesem und anderen Benutzern werden direkt von S3 aus bearbeitet und umgehen den Größenänderungsvorgang. Wird das Bild mit geänderter Größe in der Zukunft gelöscht, wird der obige Vorgang einfach wiederholt und das Bild mit geänderter Größe wird neu erstellt und in den S3-Bucket ersetzt.

Schauen wir uns im Teil 2 an, wie dich das Ganze umsetzen lässt.

(ID:46586704)

Über den Autor

Dipl. -Ing. Thomas Drilling

Dipl. -Ing. Thomas Drilling

IT-Consultant, Trainer, Freier Journalist