AWS Neuigkeiten Dezember 2020 und Januar 2021

Auch während der Jahreswende, die durch die re:Invent-Events von AWS geprägt war, gab es einige Neuerungen und Ergänzungen im Angebot des Cloudanbieters. Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen der Monate Dezember 2020 und Januar 2021 dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Aufgrund der Fülle an Ankündigungen, die während der re:Invent getätigt worden sind, liegt das Hauptaugenmerk dieser Liste auf Veränderungen, die bereits veröffentlicht worden sind und bei denen wir von einem direkten Einfluss auf Kunden im Versicherungs-, Finanz- und Retailbereich ausgehen. Ein besonderer Fokus dieses Artikels liegt hierbei auf den Neuerungen der Services Amazon S3, AWS Lambda, AWS SageMaker und AWS CloudShell, sowie den neu hinzugekommen fully managed Services von Grafana und Prometheus.  

 

Amazon Simple Storage Service (S3) 

Die Monate Dezember und Januar brachten für den Objektdatenspeicher S3 einige kleine, aber nützliche Änderungen mit sich. Die interessantesten Änderungen beziehen sich auf die Konsistenz im Zusammenspiel der API-Funktionen wie PUTGET oder „List“, einer Erweiterung der Verfügbarkeit von AWS PrivateLink sowie der Replizierung von Buckets. 

Erst schreiben, dann lesen 

Cloud-Objektdatenspeicher bedienen dank ihrer hohen Erreichbarkeit und ihrer flexiblen Skalierung perfekt die Kriterien, die ein Data Lake erfüllen muss. Für die Daten selbst ist der Data Lake allerdings noch nicht der finale Ort. Häufig ist es so, dass die Daten hier lediglich persistiert werden und eine direkte Weiterverarbeitung der Daten erfolgen soll. Um dies zu gewährleisten, kann mit den API-Funktionen von S3 gearbeitet werden: Mittels „Put“-Befehl können Daten in den Data Lake eingespeist werden und mittels Get“ von ihrem eigentlichen Zielort abgefragt werden. Bis vor kurzem war es so, dass ein kleines Zeitfenster nach einem „Put“-Befehl existierte, in welchem Daten zwar bereits gespeichert wurden, allerdings noch nicht für Get“-Abfragen sichtbar waren und somit bei der Verarbeitung übersehen werden konnten. Um dies zu umgehen war es bisher notwendig, zusätzliche Services wie den S3Guard zu verwenden. Im Dezember des letzten Jahres wurde allerdings verkündet, dass nun alle „Put“-, Get“- und „List“-Befehle, sowie Operationen, die beispielsweise die Tags von Objekten ändern, konsistent seien. Dies hat zur Folge, dass das zuvor beschriebene kleine Zeitfenster verschwindetwas im Allgemeinen die Arbeit mit S3 als Data Lake weiter erleichtert. 

PrivateLink for S3 

Während der re:Invent im Dezember wurde ebenfalls angekündigt, dass PrivateLink für den S3-Speicher bald zur Verfügung stehen werde. Dies ist inzwischen der Fall und es kann nun über AWS PrivateLink, unter Zuhilfenahme privater IP-Adressen, eine direkte Verbindung von einem on-premises System zum S3-Speicher hergestellt werden. Bisher war dies lediglich mit Hilfe eines Workarounds möglich: Eine bisherige Architektur, die dies erzielen sollte, bestand darin, dass Proxy-Server mit privaten IP-Adressen innerhalb eines VPCs in der AWS Cloud verwendet wurden und eine Verbindung zum S3-Speicher mittels Gateway-Endpoints erstellt wurde. Eine solche Konstruktion könnte nun durch die Verwendung des PrivateLinks ersetzt werden. Dies bietet zum einen die Möglichkeit, dass Cloudarchitekturen simpler gestaltet werden können, zum anderen entfernt es die Proxy-Server als potenzielle Fehlerquelle innerhalb eines Workflows. 

Replizierung  

Eine weitere Neuerung mit Bezug auf den S3-Speicher bezieht sich auf die Möglichkeit, einen Bucket auf mehrere Zielbuckets, sowohl innerhalb einer Region als auch über mehrere Regionen hinweg, zu replizieren. Bisher war es notwendig für ein solches Vorhaben mit einen Monitoring Tool zu arbeiten, welches schlussendlich eine Lambda-Funktion anspricht, die diese Datei in mehrere Zielbuckets repliziert. Diese Konstruktion kann nun durch eine passende Replikationsregel im ManagementAbschnitts des jeweiligen Buckets ersetzt werden. Während dieser Replikation können auch Eigenschaften, wie zum Beispiel die Storage-Tier des Objektes oder auch die Ownership geändert werden. 

AWS Lambda 

Für den serverless compute Service AWS Lambda gab es ebenfalls einige Neuerungen. Diese betreffen unter anderem die maximale Größe, die minimalen Kosten und die Möglichkeiten zum Monitoring. 

Billing Duration und Größe 

Seit Dezember 2020 sind weitere Größen des serverless compute Services verfügbar. So ist es nun beispielsweise möglich, Lambda-Funktionen mit bis zu 10 GB RAM und 6 vCPUs zu verwenden. Eine Folge hieraus ist, dass Anwendungen, die auf Multithreading und Multiprocessing setzen, an Geschwindigkeit gewinnen und unter Umständen sogar geringere Kosten erzeugen, da die Kosten für LambdaFunktionen proportional mit ihrem konfigurierten RAM und ihrer Ausführungszeit wachsen  Die Verwendung von mehr Arbeitsspeicher steigert somit zunächst zwar die Kosten, die Zeitersparnis, die erzielt werden kann, könnte diese wiederum ausgleichen.  

Nicht nur die möglichen Größen von Lambda-Funktionen haben sich verändert: Auch die minimale Laufzeit – bzw. die Zeit die minimal berechnet wird – ist reduziert worden. Wie zuvor in diesem Blogbeitrag erwähnt, werden die Kosten von Lambda-Funktionen hinsichtlich ihres konfigurierten RAMs und ihrer Ausführungszeit bestimmt. Bisher galt, dass, unabhängig von der tatsächlichen Länge der Ausführung, mindestens 100ms berechnet werden. Diese minimale Zeitspanne wurde nun entfernt: Es ist inzwischen so, dass die Ausführungszeit von Lambda-Funktionen auf die nächsthöhere Millisekunde aufgerundet wird. Dies liefert eine genauere Abrechnung der tatsächlich genutzten Ressourcen als es bisher der Fall war und endet schlussendlich in einer Kostenersparnis bei der Verwendung von kurzlebigen Lambda-Funktionen, wie sie häufig bei Orchestrierungsaufgaben zu finden sind.  

Eine Frage, die an dieser Stelle nun auftauchen kann, ist, wie es am einfachsten möglich ist, die optimale Größe einer Lambda-Funktion zu bestimmen. Auch hierfür hat sich AWS eine neue Lösung überlegt: 

Um ein besseres Verständnis für die Auslastung von Lambda-Funktionen zu erhalten, hat AWS eine Erweiterung zu CloudWatch veröffentlicht: Amazon CloudWatch Lambda InsightsCloudWatch Lambda Insights sammelt nach Aktivierung des ServiceDaten über die Performance von Lambda-Funktionen, wie beispielsweise Informationen über den maximalen RAM-Verbrauch und die Ausführungszeit. Diese Daten werden dann von dem Service aggregiert, um sie in automatisch angelegten Dashboards, zusammen mit den für die Ausführung der LambdaFunktion entstandenen Kosten, zur Verfügung zu stellen. Mithilfe dieser Einblicke ist es künftig leichter möglich, die optimale Größe von Lambda-Funktionen zu bestimmen. 

AWS SageMaker 

Eine Vielzahl von Änderungen erlebte der fully-managed Machine-Learning Service von AWS. Die meisten dieser Änderungen zielen auf eine allgemeine Verbesserung der Nutzung ab, wie zum Beispiel der Vereinfachung im Bereich Debugging und dem Training von Modellen. Es gab aber auch grundlegende Änderungen wie die Einführung von Amazon SageMaker Pipelines, welches es ermöglicht, endtoend Machine Learning Pipelines zu erstellen und automatisieren. Weiterhin wurde im Dezember der Data Wrangler von AWS vorgestellt, welcher die Aufbereitung von Daten erleichtern soll. 

Einfachere und schnellere Anwendung von Parallelisierungen 

Wie aufgeführt zielen viele der Neuerungen auf eine einfachere Benutzung des Service ab. Zentraler Aspekt hierbei ist die Einführung einer neuen Library, welche die auftretende Arbeitslast besser auf mehrere Instanzen verteilt und die Kommunikation zwischen eben diesen verbessert. Dies hat zur Folge, dass bis zu 90% der Ressourcen, die über die GPU bereitgestellt werden, für das tatsächliche Modell-Training verwendet werden können und dadurch weniger Leistung in Bereiche wie Datentransfer investiert werden muss
Die Funktionsweise des Algorithmus, der dies ermöglicht, basiert darauf, dass die GPUs nicht mehr untereinander kommunizieren, sondern ihre neu berechneten Gradienten in ihrem eigenen Speicher behalten. Nach einer gewissen Zeit (Threshold) werden diese Gradienten dann an die ParameterServer weitergeleitet, welche auf der CPU der GPU-Instanz laufen. Jede einzelne dieser CPUs erhält Informationen aller GPUs. Die CPUs verarbeiten dann die neuen Gradienten, die sie von den GPUs erhalten haben, und verteilen diese anschließend wieder an alle GPUs. Durch die Einführung dieser neuen Library ist es leichter geworden, große Datasets und Modelle mit einer Vielzahl von neuronalen Layern schnell und effizient mit SageMaker zu verarbeiten. 

Amazon SageMaker Data Wrangler 

In nahezu allen Machine Learning Projekten ist es so, dass die Aufbereitung der Daten einen Großteil der Zeit in Anspruch nimmt. Hierunter fallen diverse Aufgaben wie beispielsweise das Zusammensuchen der Daten, das Entfernen von Dubletten, das Erstellen von Grafiken und Histogrammen sowie die Anreicherung der vorhandenen Daten. Insbesondere zu Beginn eines Projektes besitzt diese Arbeit einen experimentellen Charakter. Häufig wird an dieser Stelle mit Technologien, wie zum Beispiel pandas oder PySpark gearbeitet und diverse Transformationen werden ausprobiert, bis man schlussendlich einen passenden Wert an Genauigkeit erreicht hat und die Arbeit von dem Trainingsdatensatz auf den vollständigen Datensatz übertragen möchteUm dies zu realisieren, ist es notwendig, alle Operationen, die auf den Trainingsdatensatz durchgeführt wurden zu dokumentieren und auf den vollen Datensatz zu übertragen, was grundsätzlich eine potenzielle Fehlerquelle birgt. 

Für all diese Aufgaben hat AWS nun AWS SageMaker Data Wrangler veröffentlicht. Data Wrangler soll es ermöglichen, mit nur wenigen Klicks eine Verbindung zu einer Datenquelle zu erstellen und die Datensätze zu analysieren und visualisieren. Weiterhin können Transformationen in Data Wrangler selbst durchgeführt und als Code gespeichert werden, sodass bisher fehleranfällige Dokumentationsarbeit von AWS übernommen wird. 

Für alle diese Aufgaben bietet Data Wrangler ein grafisches User Interface an. Zum derzeitigen Stand sind beispielsweise über 300 vorgefertigte Transformationen verfügbar, welche per Drop-Down Menü ausgewählt und auf den Datensatz angewandt werden können. Weiterhin können auch eigene Transformation mit Hilfe von pandasPySpark oder PySpark SQL durchgeführt werden. Die Resultate der Transformation lassen sich direkt im Studio begutachten, sodass ein interaktives Arbeiten mit den Daten möglich ist. 

AWS CloudShell 

Auch wenn die ManagementKonsole von AWS stetig im Wandel ist, gibt es doch einige Aufgaben, die in dieser nicht erledigt werden können. Für eben solche Aufgaben ist es notwendig, die Command Line zu verwenden. Bisher mussten, um von der Command Line auf die AWS Cloud zuzugreifen, Dinge wie Public Keys oder Credentials eigenständig auf den lokalen Systemen verwaltet werden. 

Seit Dezember 2020 bietet AWS die AWS CloudShell an. Diese ist schlussendlich ein Command Line Interface in der AWS Cloud selbst, unter welcher die CLI v2 installiert ist, sodass AWS-Befehle direkt in der Cloud ausgeführt werden können. Der Log-In in die CloudShell kann mittels SSO oder einem anderen Verfahren stattfinden. Mit diesen kann sich auch in die Management Konsole eingeloggt werden, allerdings muss dem User die Policy AWSCloudShellFullAccess gewährt werden. Die Applikation basiert auf Linux2, sodass auch klassische UNIX-Befehle verwendet werden können. 

Weitere Fully Managed Services 

Zeitgleich hat AWS sein Repertoire an Fully Managed Services erweitert. So wurden beispielsweise Grafana und Prometheus, welches bereits in diesem Artikel von uns vorgestellt wurde, hinzugefügt. 

Grafana 

Grafana ist eine open-source Technologie, welche in den Bereich der Observability-Tools einzuordnen ist und für die Visualisierung und Analyse von Daten zuständig ist. Dies erlaubt es, sowohl Daten von internen Quellen wie CloudWatchAWS X-Ray oder Elasticsearch Service als auch von Drittanbietern wie Datadog oder Splunk zu visualisieren und so beispielsweise die Anzahl an Aufrufen die jeweiligen Services grafisch darzustellen. Außerdem ist eine Anbindung an den Nachrichtendienst von AWS, AWS Simple Notification Service, möglich, sodass beispielsweise beim Ausfall eines Service eine Benachrichtigung über Grafana verschickt werden kann. AWS übernimmt bei der Verwendung des fully managed Services sowohl die Bereitstellung und das Setup von Grafana, als auch das kontinuierliche Patching, Skalieren der Ressourcen und das Aufspielen von Versionsupgrades. 

 

Für weitere regelmäßige Updates zum Thema AWS Cloud, folgen Sie unserer Präsenz auf Xing und Instagram oder direkt unserem Blog.