Concurrency Scaling & Performance

Amazon Redshift und die Kunst der Leistungsoptimierung in der Cloud

Werner Vogels

© Shutterstock / rawf8

Ist es egal, ob ich einen Cloud-Dienst oder eine lokale Anwendung entwickle? Auf keinen Fall, sagt Werner Vogels, CTO Amazon.com. In seinem Fachartikel zeigt er die maßgeblichen Unterschiede zwischen dem online- und dem on-premise-Ansatz auf und geht dabei insbesondere auf die Frage nach der Performance ein.

Die Entwicklung von Cloud-Diensten unterscheidet sich von der Entwicklung von On-premise-Lösungen in entscheidenden Punkten. In diesem Beitrag erläutere ich einige Unterschiede anhand des Beispiels des Amazon-Redshift-Teams und ihrem Vorgehen, um die Leistung des Data-Warehousing-Dienstes zu verbessern. Dabei wurden mit ein paar einfachen Techniken bemerkenswerte Fortschritte erzielt:

  • Effektive Auswertung von Nutzungsmetriken
  • Prüfung von Benchmark-Ergebnissen
  • Optimierung der Leistung bei kurzfristiger, starker Benutzeraktivität

Effektive Auswertung von Nutzungsmetriken

Der größte Unterschied zwischen der Entwicklung für die Cloud und der Entwicklung von Software für den Einsatz „on premise“ besteht darin, dass Unternehmen in der Cloud einen viel besseren Einblick bekommen, wie Kunden einzelne Dienste nutzen. Jede Woche scannt das Amazon-Redshift-Team zum Beispiel die Flotte von Data Warehouses und erstellt ein Jupyter Notebook, das eine Gesamtansicht der Nutzung zeigt. Dabei werden nicht spezifische Abfragen, sondern nur allgemeine Informationen wie Vorgang, Anzahl, Dauer und Ausführungspläne erfasst. Das ergibt Hunderte Millionen von Datenproben. Die Diagramme unten zeigen die Häufigkeit, die Dauer und den Ausführungsplan für SELECT– und INSERT/UPDATE/DELETE-Abfragen.

Die Diagramme decken auf, dass Kunden fast so viele INSERT/UPDATE/DELETE-Abfragen in ihren Amazon Redshift Data Warehouses ausführen wie SELECT-Abfragen. Offensichtlich aktualisieren sie ihre Systeme viel häufiger als zuvor mit On-premise-Lösungen. Damit ändert sich die Art der Herausforderungen, die das Amazon-Redshift-Team priorisiert angehen muss.

Außerdem wird deutlich, dass die Verteilung der Laufzeiten grob einem Potenzgesetz folgt. Obwohl die überwiegende Mehrheit der Abfragen weniger als 100 Millisekunden benötigt, ist die Gesamtzeit in jedem Bucket in etwa gleich. Jede Woche ist es die Aufgabe des Teams, etwas zu finden, das die Laufzeiten nach links verschiebt und die Gesamtzeit reduziert. Dazu werden die Ausführungspläne mit Blick auf die größten Verbesserungsmöglichkeiten analysiert.

Blockchain Whitepaper 2019

Free: Blockchain Technology Whitepaper

If building a blockchain from scratch is beyond your current scope, the blockchain technology whitepaper is worth a look. Experts from the field share their know-how, tips and tricks, development advice, and strategy for becoming a blockchain master.

Das hat im vergangenen Jahr zu beeindruckenden Ergebnissen geführt. Über die gesamte Flotte hinweg sind wiederholte Abfragen 17-mal schneller, Löschvorgänge zehnmal schneller, das Hinzufügen einzelner Datensätze dreimal schneller und Commits doppelt so schnell. Die genannten Beispiele sind normalerweise nicht in Data-Warehousing-Benchmarks zu finden. Trotzdem handelt es sich dabei um bedeutende Bestandteile von Kunden-Workloads.

Solch beeindruckende Resultate sind das Ergebnis eines disziplinierten Engineerings, das die Leistung mit jedem Patch um fünf bis zehn Prozent verbessert. In den vergangenen sechs Monaten haben diese Zuwächse zu einer 3,5-fachen Steigerung des Durchsatzes von Abfragen in Amazon Redshift geführt. Es ergeben sich also jeweils kleine Verbesserungen, die sich allerdings stark summieren. Der Schlüssel dazu ist das Wissen, was bei den einzelnen Schritten genau verbessert werden muss.

Prüfung von Benchmark-Ergebnissen

Iterative Verbesserungen auf der Grundlage von Trends in Nutzungsmetriken sind der beste Weg, das Kundenerlebnis zu verbessern. Allerdings ist es auch wichtig, Benchmarks im Auge zu behalten, die Kunden helfen, einen Anbieter von Cloud-Data-Warehousing-Diensten mit einem anderen zu vergleichen.

Es ist wichtig, bei der Bereitstellung von Leistungsdaten Abfragen zu verwenden, die von Industriestandard-Benchmarks wie TPC-DS abgeleitet sind. Künstliche Workloads, die nur ausgewählte Abfragen enthalten, verzerren das Ergebnis. Es ist außerdem entscheidend, sowohl solche Fälle aufzuzeigen, in denen der Anbieter besser ist, als auch solche, bei denen er schlechter abschneidet.

Eine wissenschaftliche Herangehensweise erfordert, dass die Ergebnisse reproduzierbar sind. Dazu gehört auch, dass das jeweils genutzte Setup genau dokumentiert wird. Der Code und die Skripte, die das Amazon-Redshift-Team für das Benchmarking verwendet hat, sind auf GitHub verfügbar und die zugehörigen Daten sind in einem öffentlichen Amazon S3 Bucket gespeichert. Die URL lautet https://github.com/awslabs/amazon-redshift-utils.

Hinweis: Sie benötigen gültige AWS-Anmeldeinformationen, um auf die öffentlichen S3-Daten zugreifen zu können. Skriptbenutzer sollten die DDL-Datei mit ihren eigenen AWS-Schlüsseln aktualisieren, um die TPC-DS-Daten zu laden.

Optimierung der Leistung bei kurzfristiger, starker Benutzeraktivität

Ein weiterer wesentlicher Unterschied zwischen On-premise-Systemen und der Cloud ist die Fülle der verfügbaren Ressourcen. Ein typisches Data Warehouse hat signifikante Unterschiede bei der gleichzeitigen Nutzung von Abfragen im Laufe eines Tages. Es ist kostengünstiger, Ressourcen nur für den Zeitraum hinzuzufügen, in dem sie benötigt werden, als sie permanent für Spitzenlasten bereitzustellen.

Concurrency Scaling ist eine neue Funktion von Amazon Redshift, die bei Bedarf vorübergehend Kapazität hinzufügt, um die hohe Nachfrage von gleichzeitigen Benutzern und Abfragen zu bewältigen. Aufgrund der oben beschriebenen Leistungssteigerungen haben 87 Prozent der aktuellen Kunden keine signifikanten Wartezeiten in der Warteschlange und benötigen keine Parallelität über das hinaus, was ihr Haupt-Cluster bietet. Die restlichen 13 Prozent haben Spitzen bei der gleichzeitigen Nachfrage, durchschnittlich über zehn Minuten hinweg.

Mit der neuen Funktion startet Amazon Redshift automatisch einen Cluster für den Zeitraum, in dem eine erhöhte Parallelität dazu führt, dass Anfragen warten. Für alle 24 Stunden, die Ihr Haupt-Cluster in Betrieb ist, erhalten Sie Credits für eine Stunde Concurrency Scaling. Dies bedeutet, dass Concurrency Scaling für mehr als 97 Prozent der Kunden kostenlos ist.

Die Nutzung, die am Ende des Monats die aufgelaufenen Credits übersteigt, wird sekundengenau abgerechnet. So profitieren Nutzer nicht nur von konstant schneller Leistung, sondern auch von planbaren monatlichen Kosten, selbst in Zeiten hoher Bedarfsschwankungen. Im folgenden Diagramm sehen Sie, wie sich der Durchsatz von Abfragen, die aus dem TPC-H-Benchmark abgeleitet wurden, mit steigender Anzahl gleichzeitiger Benutzer erhöht und Amazon Redshift vorübergehend Cluster hinzufügt.

Concurrency Scaling ist ein gutes Beispiel dafür, wie das Amazon-Redshift-Team in der Lage ist, die Elastizität von Cloud-Ressourcen zu nutzen, um die Kapazität automatisch nach Bedarf zu skalieren. Für die Nutzer bedeutet das eine konstant schnelle Leistung für alle User und Workloads, selbst bei Tausenden von gleichzeitigen Abfragen.

Für eine Vorschau des bald verfügbaren Concurrency Scaling kann man sich aktuell vormerken lassen, um eine E-Mail-Benachrichtigung zu erhalten, sobald die Funktion zum Testen vorliegt. Weitere Informationen dazu finden Sie unter https://pages.awscloud.com/redshift-new-features.html.

Geschrieben von
Werner Vogels
Werner Vogels
Werner Vogels ist Chief Technology Officer (CTO) und Vizepräsident von Amazon.com. Werner bloggt unter https://www.allthingsdistributed.com.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Amazon Redshift und die Kunst der Leistungsoptimierung in der Cloud"

avatar
4000
  Subscribe  
Benachrichtige mich zu:
Max
Gast

Architektonisch unterscheidet sich Redshift kaum von on premise Lösungen, wobei storage und compute eng miteinander gekoppelt sind und sich nicht on the go auf und ab skalieren lassen. Snowflake dagegen wurde von Grund auf für die Cloud gebaut, ist auf AWS und Azure erhältlich und ermöglicht sofortigen Zugriff auf alle strukturierten und semi strukturierten Daten (JSON) einfach per SQL.