Migrieren von On-Premises Analytics-Umgebungen nach Amazon Redshift

Eine Modernisierung von Analytics-Umgebungen bringt eine Vielzahl von Vorteilen und kann dazu beitragen, Digitalisierungsprozesse zu beschleunigen. In diesem Artikel geht es um das Erstellen einer Analytics-Umgebung mit Hilfe von Amazon Web Services (AWS), sowie die Verbindung mit einer relationalen Datenquelle, welche in einem Kundenrechenzentrum läuft. Kunden, die ihre Analytics-Umgebungen zu Amazon Redshift, dem Cloud Datawarehouse von AWS, migrieren, nennen als Hauptgründe Kosteneinsparungen, geringere Komplexität von Zielarchitektur und Daten-Pipelines, sowie generelle Vereinfachungen bei Betrieb, Support und Wartung. Die hier beschriebene Vorgehensweise einer Migration kann zudem als Blaupause für ähnliche Projekte verwendet werden.

Oft sind noch Altsysteme im Kundenrechenzentrum oder sogar in Firmengebäuden in Betrieb, um ständig wachsende Datenbestände zu verarbeiten und unternehmerischen Mehrwert aus der Analyse dieser Daten zu generieren. Sind Datenbestände und die dazugehörige Rechenkapazität intern gehostet, entstehen in den überwiegenden Fällen operationale und unternehmerische Risiken, die es zu lösen gilt. Es stellt sich beispielsweise die Frage, ob die Räumlichkeiten für die Server geeignet und in unterschiedliche Brandabschnitte unterteilt sind, um die nötige Redundanz im Katastrophenfall sicherzustellen. Oder auch wie die Zutrittskontrolle stattfindet, wie schnell der Prozess der Hardware- und Softwarebeschaffung bei Skalierungsbedarf greift, um den Analytics-Betrieb sicherzustellen, und ob in Teams das nötige Know-how vorhanden ist, um im Fehlerfall schnell zu reagieren.

Auch generelle, nicht-fachliche Anforderungen wie z.B. Sicherheit und Datenschutz spielen eine große Rolle. Die Verschlüsselung der Datenübertragung, der Endpunkte und der gespeicherten Daten muss ständig überwacht und an den aktuellen Stand der Technik angepasst werden. Besonders hohe Anforderungen gelten in regulierten Industrien. Performanz- und Nachhaltigkeitsfragen erhöhen den Bedarf an geschultem Personal, welches die Gesamtheit des Systems ständig für den Betrieb überwacht und optimiert.

Bei diesen Fragen können verwaltete Services von AWS, zum Beispiel für Datenbanken, Speicher sowie Extract, Transform, Load (ETL) helfen, Kosten und Komplexität zu reduzieren – oft bei gleichzeitiger Steigerung der Performanz.

Dieser Artikel gibt einen Überblick über eine konkrete Lösungsarchitektur, in der die zu analysierenden Daten zunächst in einem Data Lake auf AWS vorgehalten werden, um danach im Cloud Data Warehouse Amazon Redshift zur weiteren Analyse bereitgestellt werden zu können. Als Quellsystem wird in diesem Fall eine Vor-Ort-Datenbank (on-premises Datenbank), ergänzt durch die Möglichkeit eines dateibasierten Uploads, verwendet. Auch andere Quellsysteme sind möglich, auf die aufgrund der Vielzahl hier nicht im Detail eingegangen wird.

Lösungsübersicht

Das AWS „Database Freedom“-Programm ist als Option darauf ausgelegt, Unternehmen dabei zu helfen, ihre Datenbank-Workloads zu AWS zu migrieren. Dieses Programm bietet eine umfassende Sammlung von Tools, Handlungsempfehlungen und Expertenunterstützung, um den Übergang von lokalen Datenbanken, kommerziellen Datenbanken oder anderen Cloud-Datenbanklösungen zu AWS-eigenen Datenbankdiensten zu erleichtern. Insgesamt zielt das AWS „Database Freedom“-Programm darauf ab, den Migrationsprozess zu vereinfachen und zu beschleunigen, Kosten zu senken und die Leistung und Skalierbarkeit Ihrer Datenbank-Workloads zu verbessern, indem die robusten und umfassenden Datenbanklösungen von AWS genutzt werden.

Der AWS Database Migration Service (DMS) ist ein verwalteter Service, der Kunden dabei hilft, Datenbanken schnell, sicher und mit minimaler Ausfallzeit zu AWS zu migrieren. Er unterstützt sowohl homogene Migrationen (z.B. Oracle zu Oracle) als auch heterogene Migrationen (z.B. Oracle zu Amazon Aurora oder MySQL zu PostgreSQL). In diesem Fall wird DMS nicht nur im Zeitraum einer Migration genutzt, sondern stellt eine dauerhafte Verbindung zwischen einer on-premises Umgebung und AWS her.

Amazon Redshift ist ein vollständig verwaltetes Data Warehouse, das schnelles Abfragen und Analysieren von Daten im Petabyte-Maßstab ermöglicht. Es ist darauf ausgelegt, große Datenmengen effizient zu verarbeiten und zu analysieren. Wichtige Fähigkeiten für eine erfolgreiche Zielarchitektur sind beispielsweise:

Massively Parallel Processing (MPP): Amazon Redshift nutzt eine MPP-Architektur, die es ermöglicht, große Datenmengen über mehrere Knoten hinweg zu verteilen und parallel zu verarbeiten. Dies führt zu erheblichen Leistungsverbesserungen bei der Abfrage und Verarbeitung.
Columnar Storage: Daten werden spaltenweise gespeichert, was die Abfrageleistung verbessert, insbesondere bei analytischen Abfragen, die nur eine Auswahl an Spalten der Daten benötigen.
Materialized Views: Amazon Redshift unterstützt materialisierte Ansichten, die Zwischenergebnisse speichern und die Abfrageleistung durch Reduzierung der Berechnungszeit verbessern.
Verschlüsselung: Amazon Redshift bietet End-to-End-Verschlüsselung, sowohl für ruhende Daten (AES-256) als auch für Daten in Bewegung (SSL/TLS).

Architektur

Die wichtigsten Ressourcen der Zielarchitektur sind der AWS Database Migration Service (DMS), Amazon Redshift, AWS Glue Data Catalog und der Cloud-Objektspeicher Amazon S3. Die zusätzlichen Ressourcen unterstützen in der Erreichung des Zielzustandes, das Datawarehouse mit entsprechend aktuellen Daten zu befüllen. Diese sind in ihrer genauen Definition flexibel und können an die zu übertragenden Datenmengen und die Anforderungen angepasst werden. Generell gilt, Migrationsprojekte durch geeignete Projektpläne zu unterstützen. Je nach Größe der Quelldatenbanken oder Quelltabellen kann es notwendig sein, Anpassungen an der Architektur oder Einstellungen der beteiligten Services vornehmen zu müssen.

Kernbestandteil der hier beschriebenen Migration ist eine relationale Quelldatenbank, welche sich in einem externen Rechenzentrum befindet. Diese Datenbank hält alle Informationen, die zukünftig durch Amazon Redshift zur Verfügung gestellt werden sollen. Die Quelldaten werden beispielsweise durch weitere Applikationen erzeugt oder von anderen Quellsystemen eingelesen. Anschauliche Anwendungen aus der Praxis sind z.B. die Auswertung von Produkt- oder Finanzdaten. Weitere Migrationsszenarien sind möglich und AWS DMS unterstützt eine Vielzahl von Quellsystemen, die laufend aktualisiert werden.

AWS Database Migration Service

Die Basisarchitektur von AWS DMS ist in Abbildung 1 beschrieben. Sie besteht im Kern aus einer Replikationsinstanz, auf der verschiedene Replikationstasks laufen können. Quell- und Zielendpunkte verweisen jeweils auf die verschiedenen Quell- und Zieldatenbanken. Dabei muss sich ein Endpunkt stets auf einen AWS-Service beziehen. Somit sind Migrationsszenarien von on-premises zu on-premises Datenbanken ausgeschlossen. Die Endpunkte enthalten auch weitere notwendige Daten, beispielsweise Servernamen, Authentifikationsdetails, AWS „Identity and Access Management“ (IAM) Rollen, sowie Verschlüsselungsoptionen, welche beim Erstellen benötigt werden. Da in diesem Szenario die Quelldatenbank weiterbetrieben wird und ständig neue Daten generiert werden, läuft auch die zugehörige Replikationsinstanz permanent und repliziert die Daten nach Amazon S3. In alternativen Szenarien ist es auch möglich, die Quelldatenbank nach einer erfolgreichen Migration zusammen mit der AWS DMS-Replikationsinstanz abzuschalten.

Abbildung 1: AWS DMS Basisarchitektur

Die zweite Option, eine Datenbankmigration mittels AWS DMS abzubilden, ist AWS DMS Serverless. Bei der Serverless-Variante entfallen Aufgaben beim Management der Replikationsinstanz, zum Beispiel Kapazitätsplanung, Instanzprovisionierung, Kostenoptimierung und Versionsverwaltung. Für die Ressourcennutzung der Serverless-Replikation können Unter- und Obergrenzen durch sogenanntenDMS capacity units (DCUs) festgelegt werden. Jede DCU beinhaltet die Nutzung von 2 GB Arbeitsspeicher für Replikationsaufgaben. Kunden zahlen nur für die Ressourcen, welche von AWS DMS Serverless tatsächlich genutzt werden. Genauere Eigenschaften der Serverless Option finden sich in der Dokumentation von AWS DMS.

Die dritte Migrationsoption ist die homogene Datenmigration, welche die Migration von selbstverwalteten, On-Premises-Datenbanken zu den gewünschten Datenbanklösungen in der AWS Cloud weiter abstrahiert und somit vereinfacht. Allgemein werden homogene Datenmigrationen mit Instanz-Profilen, Datenanbietern und Migrationsprojekten durchgeführt, welche in der AWS Management Konsole definiert werden. Somit ist auch die Terminologie an das Abstraktionsniveau angepasst. Eine Migration wird von AWS DMS mit nativen Datenbanktools durchgeführt. Ob die zu migrierende Datenbank-Engine und die geplante Zielumgebung unterstützt werden, erfahren Sie unter „Quellen für homogene DMS-Datenmigrationen“ und „Ziele für homogene DMS-Datenmigrationen“.

Dieser Artikel beschreibt nur einen Auszug aus der breiten Funktionalität von AWS DMS. Nutzen Sie die angegebenen Referenzen oder auch die Links im Bereich „Verwandte Informationen“ am Ende dieses Artikels für zusätzliche Informationen. Im weiteren Verlauf wird speziell auf das Szenario einer Migration beziehungsweise permanenten Replikation zwischen einer Oracle-Quelldatenbank, AWS DMS und Amazon S3 eingegangen.

Netzwerkeigenschaften

Um eine Netzwerkverbindung zum Quell-Rechenzentrum herzustellen, wird in dieser Architektur AWS Direct Connect verwendet. AWS Direct Connect ist ein Cloud-Service, der eine dedizierte Netzwerkverbindung zwischen Ihrem lokalen Rechenzentrum und AWS bereitstellt, um eine zuverlässige, sichere und schnelle Datenübertragung mit niedriger Latenz zu ermöglichen. Es stehen verschiedene Bandbreiten und Optionen zur Ausfallsicherheit zur Verfügung. Wir gehen in diesem Fall davon aus, dass die Bandbreite hoch genug ist, um eine Datenübertragung nicht zu beeinträchtigen, und dass die Verbindung zwischen dem Rechenzentrum und AWS redundant ausgelegt ist.

Eine dedizierte, private Verbindung außerhalb des öffentlichen Internets ist maßgeblich, um schützenswerte unternehmerische Daten sicher zu übertragen. Eine zusätzliche Verschlüsselung ist möglich und wird anhand der Projektanforderungen festgelegt.

Eine Alternative stellt die Verbindung zwischen einem Rechenzentrum und der AWS Cloud über ein AWS Site-to-Site VPN her. Diese softwarebasierte Verbindung kann zum Einsatz kommen, wenn die Projektanforderungen in puncto Übertragungsbandbreite und die Geschäftsfortführung dies zulassen. Als zentrale Komponente terminiert ein AWS Transit Gateway die Verbindungen und sorgt für eine Bereitstellung der Daten in den jeweiligen AWS-Konten.

Data Lakes auf Amazon S3

Der erste Hauptaspekt bzw. Meilenstein dieses Szenarios ist, alle Daten in einem zentralen Data Lake zu speichern. Hierbei kommt Amazon S3 als primäre Speicherplattform zum Einsatz. Amazon S3 eignet sich für diese Zwecke optimal, da annährend unbegrenzter Speicherplatz zur Verfügung steht und somit Daten und Projekte im zukünftigen Wachstum nicht begrenzt werden. Auch die hohe Dauerhaftigkeit der Datenhaltung von 99.999999999%, die Kosteneffizienz, die standardmäßige Sicherheit und die Möglichkeit, unterschiedlichen Datenlieferanten und -konsumenten einen sicheren und einfachen Zugriff auf den Data Lake zu ermöglichen, sprechen für Amazon S3.

Der Aufbau und die Eigenschaften von Data Lakes sind vielfältig. Allgemein müssen Data Lakes in der Lage sein, Daten aus unterschiedlichsten Quellen und im Rohformat aufzunehmen. Dabei nehmen Data Lakes sowohl strukturierte als auch unstrukturierte Daten auf. Eine wichtige Eigenschaft ist zudem, dass Daten für eine Ablage im Data Lake nicht gesondert validiert oder aufbereitet werden müssen. Dies erleichtert in der Praxis die Adaption für Entwicklerteams enorm, da fast keine Nutzungsvoraussetzungen vorliegen. Es kann unmittelbar mit der Speicherung von Daten begonnen werden. Eine notwendige Validierung oder Aufbereitung der Daten erfolgt dann später in der Prozesskette. Es ist jedoch empfehlenswert, dass sich Datenlieferanten über die allgemeinen Konzepte von Data Lakes bzw. allgemeiner bewährte Praktiken informieren, um von Beginn an eine hohe Qualität der Datenhaltung sicherzustellen. Hierzu liefert z.B. das AWS Whitepaper „Storage Best Practices for Data and Analytics Applications“ einen guten Ansatzpunkt.

Mit der Erstellung und Speicherung der Daten in einem Data Lake ist ein wichtiger Schritt bereits vollzogen. AWS- Services wie AWS Lake Formation unterstützen bei der Erstellung und Verwaltung. Von hier aus können, je nach Qualitätsgrad der gespeicherten Daten, bereits sofort weitere ad-hoc Analysen, z.B. mittels Amazon Redshift Spectrum stattfinden. Direkte Visualisierungen sind mit Amazon QuickSight möglich, und auch der Einsatz von generativer KI mittels Amazon Q steigert die Unternehmensproduktivität.

Katalog und Suche

Der Data Lake nimmt durchgehend neue Objekte auf. Diese werden in Form von Rohdaten, transformierten Daten, strukturierten oder unstrukturierten Daten von verschiedenen Akteuren in den Data Lake hochgeladen. Um einen Überblick zu behalten, welche Datenobjekte bereits gespeichert oder erzeugt wurden, ist ein aktueller Katalog notwendig, der eine Suche nach diesen Objekten ermöglicht.

Abbildung 2: AWS Glue Datenkatalog

AWS Glue ist ein verwalteter Datenintegrationsservice, der die Datenaufbereitung einfacher, schneller und kostengünstiger macht. Der AWS Glue Datenkatalog ist als Bestandteil von AWS Glue ein zentraler Metadatenspeicher für Informationen, welche von Unternehmen in ihrem Data Lake abgelegt werden. Dabei verbindet sich ein AWS Glue Crawler mit verschiedenen AWS-basierten oder externen Datenspeichern, um die Daten zu inventarisieren und Metadaten zu erstellen. Der Katalog kann über verschiedene Zugriffsmethoden, zum Beispiel die AWS Glue Konsole, AWS Glue APIs, oder AWS Command Line Interfaces (AWS CLI) eingesehen werden, um die vorhandenen Daten zu prüfen. Siehe hierzu auch Abbildung 2, welche die generelle Funktionsweise darstellt.

Abbildung 3: AWS-Konto für Netzwerk, AWS Database Migration Service und Data Lake

Separierung von Produktions- und Entwicklungsumgebungen

Eine Zielumgebung in AWS besteht normalerweise aus mehreren AWS-Konten, welche zu einer Organisation innerhalb einer sogenannten Landing Zone zusammengefügt werden. In diesem Artikel wird die Architektur dahingehend vereinfacht dargestellt, dass sich die Netzwerkressourcen zusammen mit den anderen Ressourcen wie z.B. AWS DMS in demselben AWS-Konto befinden. In einer Produktionsumgebung sind diese Ressourcen idealerweise gekapselt in dedizierten AWS-Konten provisioniert.

Eine Trennung nach AWS-Konten findet jedoch statt für den AWS DMS/Data Lake und Amazon Redshift und zugehörige ETL-Prozesse. Die Separierung findet vorwiegend aus Gründen der Sicherheitsisolierung und der vereinfachten Verwaltung von Ressourcen statt. Zum einen kapselt die Verwendung mehrerer AWS-Konten die provisionierten Ressourcen nach von Kunden definierten Kriterien. Ressourcen werden z.B. nach Produkt-, Teamzugehörigkeit, Kostenstellen oder anderen logischer Kriterien separiert. Oft stehen für Mitarbeiter individuelle Entwicklungs- und Testkonten mit festen Budgetgrenzen zur Verfügung, um Services kennenzulernen oder zu bewerten.

Eine unverzichtbare Trennung auf Konto-Ebene ist jedoch eine Separierung zwischen Produktions- bzw. Produktions- und Entwicklungsumgebungen. Hauptsächlich wird dies aus Gründen der operationalen Sicherheit durchgeführt, um beispielsweise bei einem Zwischenfall die Reichweite und Auswirkungen auf benachbarte Dienste und Applikationen zu begrenzen.

In Entwicklungsumgebungen werden oft unterschiedliche Rechte mittels AWS Identity and Access Management (AWS IAM) an verschiedene Benutzergruppen vergeben. Eine versehentliche Beeinflussung von Produktionsumgebungen kann somit ausgeschlossen werden und die operationale Sicherheit wird stark erhöht. In Kombination mit Infrastructure as Code (IaC) und geeigneten Backup-Strategien, stehen somit auch bei einer Notfallwiederherstellung alle Ressourcen zeitnah wieder zur Verfügung. Abbildung 3 und 4 sind hier exemplarisch als eine Umgebung anzusehen. In der Praxis wird diese Architektur dupliziert und, je nach Anzahl der benötigten Umgebungen, der Code in unterschiedlichen Versionskontrollsystemen (VCS) abgelegt.

Amazon Redshift

Amazon Redshift ist ein vollständig verwalteter Data Warehouse-Service von AWS, der große Datenmengen mittels Massively Parallel Processing (MPP) und spaltenweiser Speicherung effizient analysiert. Er bietet flexible Datenintegrationsmethoden, automatische Skalierung und umfassende Sicherheitsmaßnahmen, was ihn ideal für umfangreiche Datenanalysen und Business Intelligence-Anwendungen macht. Für eine allgemeine Einführung bzw. Übersicht über die fortschreitende Entwicklung von Amazon Redshift besuchen Sie gerne die Produktseite von Amazon Redshift und das Video von der letzten AWS re:Invent Konferenz „Amazon Redshift: A decade of innovation in cloud data warehousing“ (Englisch).

In dieser Architektur hält Amazon Redshift alle Daten, die zur Analyse durch Data-Analysts, Data Engineers, Data-Scientists, sowie für das Erstellen von Dashboards oder die Nutzung durch technische Benutzer benötigt werden. Diese zentrale Zielarchitektur ist ein logischer erster Schritt bei einer initialen Migration. Je nach Anforderungen oder wachsenden Datenbeständen stehen weitere Lösungsarchitekturen wie z.B. Daten-Mesh oder der Multi-Datawarehouse-Ansatz zur Verfügung, um Analytics-Architekturen ständig weiterzuentwickeln.

Ein erfolgreicher Projektverlauf hängt von vielen Faktoren ab. Am Anfang steht ein Proof of Concept (PoC) bzw. eine Machbarkeitsstudie. Ein klar festgelegter Business-Sponsor ist für ein Projekt ebenso von essentieller Bedeutung, um beispielsweise Budgets festzulegen und richtungsweisende Entscheidungen zu treffen. Dies ist wichtig, damit potentielle Hemmnisse in unternehmerischen Prozessen früh identifiziert werden und bereits vor einem Start des nachfolgenden Hauptprojekts beseitigt oder abgemildert werden können. Ein erfahrener technischer Projektleiter kann bereits im Vorfeld beteiligte Teams informieren und auf betriebliche Anpassungen hinweisen. Oft werden während eines PoC wertvolle Kennzahlen erhoben, die für die spätere Migration wichtig sind. Beispielsweise können Daten zu der Größe der Produktionsdatenbank, Auslastung von Netzwerkstrecken, Dauer der Datenübertragung und Auslastung der AWS DMS Replikationsinstanz erhoben werden.

Weitere Aufgaben bestehen darin, sich auf ein Zieldatenformat zu einigen und das Schema-Design innerhalb der Amazon Redshift Datenbank nach bewährten Praktiken durchzuführen. Hierbei kann es notwendig sein, die Anforderungen von weiteren Fachabteilungen einzuholen und in das Design mit einfließen zu lassen. Sind wenig technische Kenntnisse in diesen Abteilungen vorhanden, können auch beispielsweise textuelle Fragen zum Einsatz kommen, zum Beispiel:

Welche Daten möchten Sie aus dem Datawarehouse abfragen und in welcher Frequenz?
Welche unternehmerischen Fragen sollen damit beantwortet werden?
Werden Daten aus anderen Fachabteilungen (Tabellen) benötigt, um diese mit den Daten der eigenen Abteilung zu verknüpfen?
Sind bereits Qualifikationen bei Teammitgliedern vorhanden, um Daten effizient abfragen zu können, oder werden Schulungen benötigt?

Dies sind nur einige Beispiele von potentiellen Fragen an Fachabteilungen, geben einem Projektleiter jedoch einen ersten Einblick, welcher Reifegrad im Unternehmen vorherrscht und wo eventuell Unterstützung notwendig ist. Viele Kunden von AWS greifen auf das AWS Partner Netzwerk zu und suchen einen Partner, der bei Fragen rund um Daten und Analytics unterstützen kann. Kunden evaluieren passende Partner nach sogenannten AWS Kompetenzen aus. Um diese zu erhalten, müssen Partner hohe Qualitätsstandards und entsprechende Projekterfolge nachweisen. Ein Partner könnte beispielsweise anhand der Kriterien „Data & Analytics Consulting Competency“, „Migration Consulting Competency“ und „Amazon Redshift Delivery“ ausgewählt werden, um z.B. bei Schema-Design und dem spaltenorientierten Datenbankdesign zu unterstützen. Die Entscheidung für die Auswahl eines Partners liegt hierbei vollständig beim Kunden.

Da die Quelldaten in den meisten Fällen aus Performanzgründen nicht im Rohformat in Amazon Redshift geladen werden sollen, bzw. ohne Anpassungen nicht dem gewünschten Zielformat entsprechen, werden die Rohdaten aus dem Data Lake noch einem ETL-Prozess unterzogen. Dieser sorgt dafür, dass Daten effizient abgefragt werden können. Hier kommen Services wie AWS Glue oder Datenintegrations-Software (Englisch) zum Einsatz, welche direkt über den AWS Marketplace bezogen werden können. Beim Bezug über den AWS Marketplace entfallen Aufwände für oft langwierige Einkaufsprozesse und eine Abrechnung erfolgt über das AWS-Konto, welches die Buchung durchführt.

Abbildung 4: AWS Account für Datawarehouse und ETL

Performanz-Checkliste

Nach dem Erstellen eines Amazon Redshift Clusters kann bereits mit einigen Optimierungen begonnen werden. Die wichtigsten werden im Folgenden beschrieben:

Lassen Sie sich die Empfehlungen von Amazon Redshift Advisor anzeigen und prüfen Sie die Umsetzung für Ihre Cluster. Hier beispielsweise mit dem AWS Command Line Interface:

# aws redshift list-recommendations

Mit dem Workload-Management (WLM) in Amazon Redshift können Benutzer Prioritäten innerhalb von Workloads flexibel verwalten, sodass kurze, schnelle Abfragen nicht hinter lange dauernden Abfragen in Warteschlangen hängen bleiben. Teilen Sie die Warteschlagen so ein, dass die Anforderungen unterschiedlicher Abteilungen erfüllt werden, ohne dass die Gesamtperformanz des Amazon Redshift Clusters sinkt. Um die Effizienz zu optimieren und die Ressourcen bestmöglich zu nutzen, empfiehlt AWS, mehrere Warteschlangen einzurichten und auf automatisches Workload-Management umzustellen.
Nebenläufigkeitsskalierung (engl. Concurrency Scaling): Dieses Feature ermöglicht es Amazon Redshift, zusätzliche Rechenkapazitäten bereitzustellen, um eine hohe gleichzeitige Benutzerlast ohne Leistungseinbußen zu bewältigen. Dies ist der Fall, wenn beispielsweise ein ETL-Workload auf Amazon Redshift aktiv ist und gleichzeitig SQL-Abfragen durch Analysten gestellt werden.
Diese und weitere Hinweise, um die Performanz von Amazon Redshift zu steigern, finden sich in dem Artikel: „Top 10 performance tuning techniques for Amazon Redshift“ (Englisch).

Sicherheit

Sicherheit hat bei AWS oberste Priorität. Jeder hier angesprochene Service hat eigene Sicherheitsmechanismen und -eigenschaften, die im Betrieb genutzt werden sollten. Allgemein gilt zudem das ‚least-privilege‘-Prinzip (deutsch: geringstmögliche Rechte), bei dem nur die Zugriffsrechte gewährt werden, die für den Zugriff oder den Betrieb minimal notwendig sind. Die Einhaltung dieses Prinzips sollte regelmäßig im Rahmen von AWS „Well Architected Framework Reviews“ oder Operational Reviews überprüft und korrigiert werden. Wir haben bereits eine Übersicht aus der Amzon Redshift Dokumentation verfügbar, welche die Sicherheitsmechanismen zusammenfasst. Dennoch sollen hier einige hervorgehoben werden.

Es sollte stets sichergestellt werden, dass Amazon Redshift Cluster nicht öffentlich im Internet zugänglich sein sollten. Bei berechtigten Ausnahmen sollte dies entsprechend den Anforderungen dokumentiert und mit internen Sicherheitsrichtlinien und -Experten abgestimmt werden.
Alle gespeicherten Daten sollten mittels AWS Key Management Service verschlüsselt werden. Dies gilt auch für beteiligte Replikationsinstanzen von AWS DMS und Backups. Für zu übertragende Daten sollte Endpunktsicherheit in Form von TLS/SSL-Verschlüsselung aktiviert werden.
Amazon Redshift und AWS DMS bieten automatische Versionsupdates von Unterversionen. Sicherheitsrelevante Updates werden somit während eines zuvor festgelegten Wartungsfensters automatisch eingespielt.
Dynamic Data Masking (DDM) ist eine erweiterte Eigenschaft, um sensible Informationen bei Abfragen mittels SQL oder Analysetools zu schützen. Hierbei werden mittels Regeln und basierend auf der jeweiligen Zugriffsrolle sensible Daten wie z.B. Kreditkarteninformationen oder personenbezogene Daten geschützt, anonymisiert oder pseudonymisiert. Dieses Feature unterstützt Kunden dabei, interne oder regulatorische Anforderungen einzuhalten. Der AWS Blogartikel beschreibt Details der Umsetzung: „How dynamic data masking support in Amazon Redshift helps achieve data privacy and compliance” (Englisch).

Fazit

In diesem Artikel wurde darauf eingegangen, wie ein erfolgreiches Analytics-Projekt zur Erstellung eines Datawarehouse mit Hilfe von AWS-Services und Drittanbietersoftware angegangen werden kann. Der Hauptaspekt bestand darin, aus einer im Unternehmensrechenzentrum laufenden relationalen Datenbank Daten in einen Data Lake auf AWS mittels AWS Database Migration Service zu migrieren, aufzubereiten und in ein Datawarehouse auf Amazon Redshift zu überführen. Dabei wurde auf die jeweiligen Meilensteine und Best Practices eingegangen und Hinweise für ein erfolgreiches Ausrollen gegeben. Hinweise zum sicheren Betrieb und stabilen Konnektivität vervollständigen diesen Artikel. Insgesamt stehen auf AWS alle Services zur Verfügung, um jede denkbare Art von Analytics-Projekten erfolgreich umzusetzen. Bei Bedarf werden diese Services durch Drittanbietersoftware, beziehbar über den AWS Marketplace, ergänzt.

Mehr erfahren

Über die Autoren

Lars Reimann ist ein leitender Lösungsarchitekt mit Sitz in Münster, Deutschland. Mit einem Hintergrund in M. Sc. Angewandter Informatik trat er im April 2020 AWS bei. Er befähigt seine Kunden im Unternehmens-Einzelhandelssektor mit bewährten Verfahren rund um ihre Cloud-Reise. Lars ist auch leidenschaftlich daran interessiert, wie Technologie genutzt werden kann, um aktuelle Herausforderungen für eine bessere Zukunft zu lösen.

AWS Germany – Amazon Web Services in Deutschland