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 „PUT“, „GET“ 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 verschwindet, was 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 Management–Abschnitts 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 Lambda–Funktionen 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 Insights. CloudWatch Lambda Insights sammelt nach Aktivierung des Service, Daten ü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 Lambda–Funktion 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, end–to–end 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 Parameter–Server 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öchte. Um 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 pandas, PySpark 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 Management–Konsole 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 CloudWatch, AWS 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.
Februar 2021
Nach einer Vielzahl von Neuerungen rund um die Jahreswende, war AWS in Hinblick auf die Änderungen von bestehenden Services im Februar etwas zurückhaltender.
Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen des Monats Februar dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Das Hauptaugenmerkt liegt hierbei auch Veränderungen, bei denen wir von einem direkten Einfluss auf unsere Kunden im Versicherungs‑, Finanz- und Retailsektor ausgehen. Die interessantesten Änderungen beziehen sich auf die Services AWS Elasticsearch Service und AWS Glue Studio.
AWS Elasticsearch
AWS Elasticsearch Service ist ein managed Service, welcher die Bereitstellung, Betrieb und Skalierung von Elasticsearch-Clustern übernimmt. Im Monat Februar sind hier zwei Neuerungen hinzugekommen: Zum einen wurde der Service um Trace Analytics erweitert und zum anderen werden nun Rollups vom Service unterstützt.
Trace Analytics
Mit der Erweiterung des Elasticsearch Services um Trace Analytics ist es nun möglich, verteiltes Tracing durchzuführen, wodurch Flaschenhälse in Anwendungen mit mehreren Komponenten leichter gefunden und ausgebessert werden können. Die bereits vorhandenen Protokollanalysefunktionen von Elasticsearch können durch Trace Daten ergänzt werden und liefern so eine vollständigere Einsicht in die Leistungsdaten einer Architektur als die Möglichkeiten, die Elasticsearch bisher allein geboten hat.
Trace Analytics unterstützt OpenTelemetry. Dies ist ein Projekt, welches APIs, Libraries und Agents bereitstellt, die das Sammeln von Metriken zum Monitoring von Applikationen ermöglicht. Stand heute werden von Trace Analytics die Erfassung von Daten aus Anwendungsbibliotheken und SDKs unterstützt, die mit dem OpenTelemetry Collector kompatibel sind. Dies sind unter anderen OpenTelemetry‑, X‑Ray, Jaeger- und Zipkin-SDKs. Die so gesammelten Daten können dann beispielsweise mit Kibana untersucht und visualisiert werden. Des Weiteren werden mit Trace Analytics zwei neue Komponenten in das OpenTelemetry und Elasticsearch Ökosystem eingepflegt.
Die erste Komponente ist der Data Prepper. Dies ist eine Server-seitige Applikation, die für das Sammeln und Transformieren der Daten zuständig ist. Die Daten instrumentalisierter Applikationen werden vom OpenTelemetry Collector eingesammelt und an den Data Prepper weitergereicht und schlussendlich von diesem verarbeitet und in den Elasticsearch Service geschrieben.
Zusätzlich zu dem oben beschriebenen, lässt sich Trace Analytics auch in Architekturen, welche mit der von uns im Oktober vorgestellten AWS Distro for OpenTelemetry arbeiten, integrieren und wird in allen AWS Elasticsearch Service Domains unterstützt, die Elasticsearch 7.9 oder höher ausführen.
Rollups
Eine andere Neuerung im Bereich Elasticsearch sind Index-Rollups. Die Index-Rollups ermöglichen es, Daten mit einer hohen Granularität zusammenzufassen und so Speicherkosten zu senken.
Zeitreihendaten, schlussendlich also gesammelte Messwerte, besitzen die Eigenschaft, dass deren Anzahl monoton wachsend ist. Durch das monotone Wachstum sinkt nicht nur die Geschwindigkeit von Aggregationen, sondern es steigt gleichzeitig der Speicherbedarf und damit einhergehend die Kosten. Nun ist es jedoch so, dass Messwerte, die weit in der Vergangenheit liegen, für Analysen einen geringeren Mehrwert bieten als neuere Daten, aber bisher trotzdem dieselben Ressourcen benötigten. Dies kann nun mittels Index-Rollups umgangen werden: Index-Rollups erlauben das Zusammenführen von mehreren relevanten Feldern, die in gröberen Zeit-Buckets zusammengefasst sind, in einem neuen Index. Durch das Zusammenführen mehrere Felder wird der Speicherbedarf, und somit auch die damit verbundenen Kosten, von historischen Daten reduziert.
Index-Rollups können entweder in festen Intervallen oder aber on-Demand ausgeführt werden. Zur Verwendung dieses Features wird eine Elasticsearch Service Domain benötigt, die Elasticsearch 7.9 oder höher ausführt.
AWS Glue Studio
Im Februar erhielt das ETL-Tool AWS Glue Studio einige Änderungen, welche die Bedienbarkeit erleichtern sollen. Zwei dieser Änderungen beziehen sich auf das Zusammenspiel von AWS Glue Studio und dem AWS Glue Data Catalog und werden nachfolgend vorgestellt.
Die erste dieser beiden Änderungen ist, dass AWS Glue Studio nun das Aktualisieren des Data Catalogs bei der Ausführung von Jobs unterstützt. Durch diese neue Funktion können Tabellen auf einem aktuellen Stand gehalten und erstellt werden, während AWS Glue die neuen Daten in den S3-Speicher schreibt. Dies erlaubt es die Daten direkt von jedem Service aus abzufragen, welcher mit dem AWS Glue Data Catalog kompatibel ist. Bisher war es notwendig, entweder in eine bereits existierende Tabelle zu schreiben oder einen AWS Glue-Crawler auszuführen, nachdem die Daten in den S3-Bucket geschrieben wurden.
Die Zweite Änderung von AWS Glue Studio in Verbindung mit dem Data Catalog zielt darauf ab, dass es nun möglich ist mit AWS Glue Daten in S3 zu lesen, ohne dass sie zuvor zum Data Catalog hinzugefügt worden sind. Bisher war es so, dass lediglich Tabellen des AWS Glue Data Catalog als Datenquelle verwendet werden konnten; das heißt, dass bisher entweder Tabellen mittels Data Crawler oder per Hand dem Data Catalog hinzugefügt werden mussten. Inzwischen lassen sich direkt Speicherorte und Objekte in S3 als Datenquelle verwenden. AWS Glue leitet nun direkt das Schema der ausgewählten Daten ab und zeigt es in der grafischen Oberfläche des Tools an, sodass ETL-bzw. ELT-Jobs schneller erstellt werden können.
Weitere Änderungen im Februar
Neben den Neuerungen für den AWS Elasticsearch Service gab es auch noch weitere Änderungen im Februar rund um das Thema Monitoring, welche unter anderem auf EC2 Auto Scaling Gruppen und Amazon SNS betreffen. Des Weiteren ist ab sofort der Machine Learning Service Amazon Lookout for Vision verfügbar.
Skalierungshistorie von EC2 Auto Scaling-Gruppen
In Bezug auf Amazon EC2 Auto Scaling-Gruppen ist es nun möglich, die Skalierungshistorie von gelöschten Auto Scaling-Gruppen einzusehen. Wenn man früher eine Auto Scaling-Gruppe gelöscht hat, musste man entweder selbst die Historie persistieren oder aber im Nachhinein den Support kontaktieren, um diese Daten erneut zu erhalten. Seit neuestem kann die die Skalierungshistorie von bereits gelöschten Gruppen durch Abfragen mit Hilfe des Parameters –include-deleted-groups abgerufen werden.
CloudWatch Metriken und SNS
Der Benachrichtigungsservice Amazon Simple Notification Service publiziert dank Neuerungen Metriken von AWS CloudWatch in einer Auflösung von einer Minute und nicht wie bisher in fünf Minuten. Dies bedeutet, dass beispielsweise Aggregationen jede Minute und nicht mehr nur alle 5 Minuten abgerufen werden, was im Allgemeinen das Monitoring verbessert.
Amazon Lookout for Vision
Amazon Lookout for Vision ist ein Machine-Learning Service, welcher, unter Zuhilfenahme von Computer Vision, Fehler und Anomalien in der Optik von hergestellten Produkten erkennt und somit schlussendlich dabei hilft, die Qualitätsprüfung zu automatisieren.
Die Qualitätssicherung von Ergebnissen industrieller Prozesse benötigt häufig eine Inspektion, die von Menschen durchgeführt werden muss. Ein solches Vorgehen ist zwar notwendig, aber auch kostenintensiv und nicht skalierbar. Mit Amazon Lookout for Vision bietet Amazon in Zukunft einen Service an, mit welchem ein solches Prozedere (teilweise) automatisiert werden kann. Der Service verwendet Computer Vision, um Endprodukte auf optische Fehler wie Dellen, Kratzer, Risse oder aber auch fehlende Produktkomponenten zu überprüfen. Zur Verwendung des Services müssen lediglich einige Bilder des akzeptablen und anomalen Zustands als Trainingsdatensatz für den zu bewertenden Prozess bereitgestellt werden. Im Anschluss daran lassen sich Kameras verwenden, welche den Herstellungsprozess überwachen, damit der Service Unterschiede zwischen dem Trainingsdatensatz und den aktuellen Daten ermitteln kann. Die Ergebnisse werden dann in Dashboards innerhalb der Managementkonsole von AWS bereitgestellt.
März 2021
Nach einem verhältnismäßig ruhigen Februar und zu Beginn des Frühlings liefert AWS seinen Nutzern wieder eine Vielzahl von Neuerungen und Erweiterungen der bereits bestehenden Services.
Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen des Monats März dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Das Hauptaugenmerkt liegt hierbei auf Veränderungen, bei denen wir von einem direkten Einfluss auf unsere Kunden im Versicherungs‑, Finanz- und Retailsektor ausgehen. In diesem Beitrag werden insbesondere Änderungen und Ankündigungen der Services AWS S3, AWS Redshift, AWS Fault Injection Simulator und AWS QuickSight vorgestellt.
AWS S3
Wie beinahe jeden Monat, wurden von Amazon auch im März Änderungen am Cloudobjektdatenspeicher durchgeführt. Die interessantesten Änderungen in diesem Monat beziehen sich auf das Zusammenspiel mit dem Serverless Compute Service AWS Lambda sowie einer Preisreduzierung von Amazon S3 Glacier.
AWS S3 Object Lambda
Einer der Hauptverwendungszwecke des S3-Services ist das zentrale Speichern von Daten an einem einzigen Ort, um von dort aus mehrere Applikationen mit Daten zu versorgen. Eine Problematik, die sich bei dieser Verwendungsart immer wieder ergibt, ist, dass verschiedene Applikationen auch verschiedene Ansprüche an die Daten haben. So kann es zum Beispiel sein, dass Daten, die aus dem Sales-Bereich einer Organisation stammen, zunächst von sensiblen Informationen bereinigt werden müssen, bevor die Daten zu analytischen Zwecken freigegeben werden können, wohingegen bei der Verwendung für den Marketing-Sektor die Daten sogar noch weiter angereichert werden müssen.
Um diesen unterschiedlichen Ansprüchen gerecht zu werden, war es bisher nötig, entweder jeweils passende Versionen des Datensatzes zu erstellen, zu speichern und schließlich auch zu verwalten oder aber eine Art Proxy-Layer zwischen den S3-Speicher und dem anfragenden System aufzubauen, welches die Daten je nach Anfrage aufbereitet. Beide Lösungsansätze führten jedoch zu erhöhten Kosten sowie einem Mehraufwand an Wartungsarbeit.
AWS hat sich im März nun diesem Problem angenommen und die AWS S3 Object Lambda Funktionen eingeführt. Dieses neue Feature ermöglicht es, mit Hilfe von Lambda-Funktionen, Daten, die per „Get“-Request abgefragt werden, automatisch anzupassen und macht somit eine oben beschrieben Architektur obsolet. Da die Lambdas schlussendlich durch die „Get“-Requests auch aufgerufen werden, müssen hierfür keine Anpassungen an der anfragenden Applikation selbst vorgenommen werden, sondern lediglich passende Access Points und Lambda-Funktionen definiert werden. Bei einer solchen Konstruktion wird der Lambda-Funktion bei Aufruf alle notwendigen Informationen über das anfragende System und das abgefragte Objekt mitgegeben, sodass für das jeweilige Target-System passende Transformationen und Anreicherungen durchgeführt werden können.
Bei der Verwendung des Services fallen die üblichen Kosten und Limitationen von Lambda-Funktionen an. Die letzten Änderungen hinsichtlich der Abrechnungszeiten und RAM-Nutzung haben wir in diesem Blogbeitrag im Januar vorgestellt.
AWS S3 Glacier
Eine weitere Änderung von AWS S3 bezieht sich auf die Kosten für „Put“- und Lifecycle-Anfragen von Daten, die in S3 Glacier abgelegt worden sind bzw. abgelegt werden.
Die Cold Data Storage Tiers AWS S3 Glacier bzw. AWS S3 Glacier Deep Archive werden häufig zum Persistieren bzw. Archivieren selten genutzter Daten verwendet. Beide Tiers bestechen zwar durch sehr geringere Speicherkosten, bringen dafür allerdings standardmäßig sehr hohe Abfragezeiten und ‑kosten mit sich. AWS verringert die Kosten für das Ablegen von Daten in AWS S3 Glacier um 40%. Dies gilt sowohl für die manuelle Ablage mittels der „Put“-API sowie der automatischen Verschiebung der Daten mittels Lifecycle Policy.
AWS Redshift
Auch für das Cloud Data Warehouse AWS Redshift sind seit März einige interessante Änderungen und Neuerungen verfügbar. Dies bezieht sich sowohl auf direkte Veränderungen des Services, wie beispielsweise der Möglichkeit, datenbankübergreifende Abfragen auszuführen, aber auch generelle Neuerungen, wie der Verfügbarkeit von weiteren Knotentypen.
Datenbankübergreifende Redshift-Abfragen/Redshift Data Sharing
Bei der Verwendung von AWS Redshift ist es häufig so, dass Kunden ihre Daten über mehrere Datenbanken hinweg speichern und organisieren. Jedoch ist es möglich, dass einige Usergruppen über ihre Datensätze hinweg Abfragen und Joins durchführen wollen bzw. müssen. Dies ist nun mittels Datenbankübergreifenden Abfragen möglich, ohne eine direkte Verbindung zur jeweiligen Datenbank aufzubauen.
AWS Redshift verfügt nun überall, wo auch die neuen RA3-Knoten verfügbar sind, über die Möglichkeit, Abfragen über mehrere Datenbanken hinweg durchzuführen. Dies erlaubt es in einem Redshift Cluster Daten aus einer beliebigen Datenbank, unter Restriktion der Zugriffkontrollen für Benutzer, Daten abzufragen und sogar zu eliminieren. Die Compute-Ressourcen, die hierbei beansprucht werden, sind die des Verbraucherclusters. Allgemein wird mittels solcher Abfragen die Datenorganisation innerhalb eines Unternehmens vereinfacht.
Eine weitere Neuerung von AWS Redshift ist, dass zu dem oben angesprochenen RA3-Knoten mit dem RA3.xlplus ein weiterer Knotentyp in Europa nun verfügbar ist. Die RA3-Knoten wurden im Dezember 2019 zu den bisher verfügbaren Compute und Storage Nodes hinzugefügt und verwenden im Gegensatz zu den beiden Letzteren keine SSD bzw. HDD als Speichermedium, sondern greifen auf den S3-Speicher von AWS zurück, was ein flexibles Skalieren des Storages in Redshift-Architekturen ermöglicht. Bisher war es allerdings so, dass die RA3-Knoten mit 12 bzw. 48 vCPUs verhältnismäßig hohe Kosten erzeugten für Compute-Ressourcen, die unter Umständen nicht vollständig ausgeschöpft werden konnten. Der RA3.xlplus ist deutlich kleiner und verfügt hingegen lediglich noch über 4 vCPUs, wodurch er eine kostengünstige Alternative darstellt.
AWS Fault Injection Simulator
Ein häufiger Grund in die Cloud zu wechseln ist – neben der Hoffnung auf eine Kostenersparnis und der flexiblen Skalierbarkeit der einzelnen Komponenten einer Architektur – die hohe Ausfallsicherheit. Um dies zu gewährleisten lieferte AWS bereits einige Komponenten und Möglichkeiten, wie zum Beispiel das Verwenden von verschiedenen Regionen und Rechenzentren, Load Balancer oder Cross-Region Replication. Hierbei stellen sich jedoch häufig zwei Fragen: Wie verlässlich sind diese Maßnahmen wirklich und was passiert mit den Systemen im Falle eines Ausfalls?
Um die erzeugten Vorkehrungen auch tatsächlich zu testen, hat Amazon Mitte des Monats den AWS Fault Injection Simulator veröffentlicht. Unter Verwendung dieses Services, können bewusst Fehler in ein System eingespielt werden, um diese auf ihre Verlässlichkeit hin zu untersuchen. Bisher wird der Service in Verbindung mit EC2-Instanzen, dem Elastic Container Service (ECS), dem Elastic Kubernetes Service (EKS) sowie dem Relational Database Service (RDS) unterstützt, allerdings soll diese Liste im Verlaufe des Jahres um weitere Services ergänzt werden.
AWS QuickSight
Amazon QuickSight ist ein cloud-basierter BI-Service, mit welchem es möglich ist, Daten aus verschiedenen Quellen zusammenzuführen und zu visualisieren, um schlussendlich ein tieferes Verständnis der Daten zu erhalten. Um dies nun noch weiter zu vereinfachen, hat Amazon die sogenannte QuickInfo eingeführt, mit welcher Dashboard-Leser zusätzliche Erkenntnisse aus den Darstellungen gewinnen können. Die QuickInfo soll hierbei zusätzlichen Kontext zu den bestehenden Dashboards mit weiteren Dimensionen und Metriken liefern. Welche zusätzlichen Informationen in der QuickInfo stehen sollen, kann von dem jeweiligen Erstellen des Dashboards definiert und angepasst werden.
Zusätzlich hierzu hat Amazon auch die Anomalieerkennung von QuickSight verbessert. Dies erlaubt es nun schneller Benachrichtigungen zu erhalten, wenn Auffälligkeiten im System auftreten. Eine weitere Änderung, welche die Arbeit mit QuickSight vereinfacht, ist, dass im Kontextmenü der aktuelle Kontoname angezeigt wird. Dies ist insbesondere bei der Arbeit mit mehreren Konten, so wie es beispielsweise bei einer Unterteilung in eine Test- und eine Produktionsumgebung auftreten kann, von Relevanz.
Policy Validation
Einer der wahrscheinlich elementarsten Bereiche bei der Arbeit mit AWS ist das Identity and Access Management (IAM). Im IAM-Abschnitt von AWS werden unteranderem Zugriffs- und Nutzungsberechtigungen von Usern festgelegt. Bei der Vergabe von Zugriffen empfiehlt es sich grundsätzlich, so wenig Berechtigungen wie nötig zu vergeben. Um dies zukünftig einfacher zu gestalten, hat AWS die sogenannte Policy Validation eingeführt, welche eine Überprüfung von IAM-Policies vornimmt, noch bevor sie einem User gewährt werden. Hierbei werden Policies auf über 100 mögliche Problemstellungen untersucht. In Anschluss an diese Überprüfungen werden von AWS konkrete Empfehlungen und Verbesserungsvorschläge ausgegeben. So warnt AWS zum Beispiel vor zu geringen Restriktionen, welche unter anderem bei der Vergabe mittels sogenannter Wildcards entstehen können oder gibt konkrete Fehler an, wie zum Beispiel eine falsche Formatierung eines Datums.
AWS Glue Studio
In den letzten Monaten gab es immer mehr Veränderungen und Neuerungen an AWSs ETL-Tool AWS Glue bzw. AWS Glue Studio, welche wir ebenfalls in vergangenen Blogbeiträgen vorgestellt haben. Seit Ende März ist es jetzt auch möglich, SQL-Abfragen zur Transformation in AWS Glue Studio zu definieren, um Aggregationen und Filterlogik noch einfacher auf den Daten durchführen zu können. Bisher war es – zumindest für unerfahrene Sparkprogrammier – nötig auf einzelne Code-Snippets zurückzugreifen, um Transformationen durchführen zu können, die noch nicht als visuelles Objekt verfügbar waren. Da es nun möglich ist, auch Aggregationen und Filter mittels SQL zu definieren, wird die Verwendung von AWS Glue auch für User ohne Spark-Erfahrungen simpler und auch performanter.
Für weitere regelmäßige Updates zum Thema AWS Cloud, folgen Sie unserer Präsenz auf Xing und Instagram oder direkt unserem Blog.
