Bei Skyeng verwenden wir Amazon Redshift, einschließlich paralleler Skalierung. Daher erschien uns der Artikel von Stefan Gromall, dem Gründer von dotgo.com, für intermix.io interessant. Nach dem Transfer - ein kleiner Teil unserer Erfahrung vom Ingenieur laut Daniyar Belkhodzhaev.Die Amazon Redshift-Architektur ermöglicht die Skalierung durch Hinzufügen neuer Knoten zum Cluster. Die Bewältigung der Spitzenanzahl von Anforderungen kann zu einer Überversorgung von Knoten führen. Die Parallelitätsskalierung erhöht im Gegensatz zum Hinzufügen neuer Knoten die Rechenleistung nach Bedarf.
Die parallele Skalierung von Amazon Redshift bietet Redshift-Clustern zusätzliche Leistung für die Bearbeitung von Spitzenanforderungen. Es funktioniert durch Übertragen von Anforderungen an neue "parallele" Cluster im Hintergrund. Anforderungen werden basierend auf der WLM-Konfiguration und den Regeln weitergeleitet.
Die Preisgestaltung für die parallele Skalierung basiert auf einem frei verwendbaren Kreditmodell. Über der Norm für kostenlose Kredite basiert die Zahlung auf dem Zeitpunkt, zu dem der Cluster mit paralleler Skalierung Anforderungen verarbeitet.
Der Autor testete die parallele Skalierung in einem der internen Cluster. In diesem Beitrag wird er über die Testergebnisse sprechen und Tipps für den Einstieg geben.
Clusteranforderungen
Um die parallele Skalierung verwenden zu können, muss ein Amazon Redshift-Cluster die folgenden Anforderungen erfüllen:
- Plattform: EC2-VPC;
- Knotentyp: dc2.8xlarge, ds2.8xlarge, dc2.large oder ds2.xlarge;
- Anzahl der Knoten: von 2 bis 32 (Cluster mit einem Knoten werden nicht unterstützt).
Gültige Anforderungstypen
Die parallele Skalierung ist nicht für alle Arten von Abfragen geeignet. In der ersten Version werden nur Leseanforderungen verarbeitet, die drei Bedingungen erfüllen:
- Schreibgeschützte SELECT-Abfragen (obwohl weitere Typen geplant sind);
- Die Abfrage bezieht sich nicht auf eine Tabelle mit der INTERLEAVED-Sortierung.
- Die Abfrage verwendet Amazon Redshift Spectrum nicht, um auf externe Tabellen zu verweisen.
Um zu einem parallelen Skalierungscluster zu routen, muss die Anforderung in die Warteschlange gestellt werden. Darüber hinaus werden Abfragen, die für die
SQA- Warteschlange
(Short Query Acceleration) geeignet sind, nicht in Clustern mit paralleler Skalierung ausgeführt.
Warteschlangen und SQAs erfordern die korrekte Konfiguration von
Redshift Workload Management (WLM) . Wir empfehlen, dass Sie zuerst Ihr WLM optimieren - dies reduziert die Notwendigkeit einer parallelen Skalierung. Dies ist wichtig, da die parallele Skalierung nur für eine bestimmte Anzahl von Stunden kostenlos ist. AWS behauptet, dass die parallele Skalierung für 97% der Kunden kostenlos sein wird, was uns zum Thema Preisgestaltung bringt.
Kosten für die parallele Skalierung
Für die parallele Skalierung bietet AWS ein Kreditmodell an. Jeder aktive
Amazon Redshift- Cluster sammelt stündlich Kredite, bis zu einer Stunde kostenloser paralleler Skalierungskredite pro Tag.
Sie zahlen nur, wenn die Verwendung von parallelen Skalierungsclustern die Anzahl der erhaltenen Kredite überschreitet.
Die Kosten werden mit der Nachfragerate pro Sekunde für einen parallelen Cluster berechnet, der über der freien Rate verwendet wird. Die Zahlung erfolgt nur während der Ausführung Ihrer Anforderungen mit einer Mindestzahlung von einer Minute bei jeder Aktivierung eines parallelen Skalierungsclusters. Die On-Demand-Rate pro Sekunde wird auf der Grundlage der allgemeinen Grundsätze der
Amazon Redshift- Preisgestaltung berechnet,
dh sie hängt vom Knotentyp und der Anzahl der Knoten in Ihrem Cluster ab.
Parallele Skalierung ausführen
Die parallele Skalierung beginnt für jede WLM-Warteschlange. Gehen Sie zur AWS Redshift-Konsole und wählen Sie im linken Navigationsmenü „Workload Management“. Wählen Sie im nächsten Dropdown-Menü die WLM-Gruppe Ihres Clusters aus.
Neben jeder Warteschlange wird eine neue Spalte mit dem Namen "Concurrency Scaling Mode" angezeigt. Der Standardwert ist "Aus". Klicken Sie auf "Ändern" und Sie können die Einstellungen für jede Warteschlange ändern.
Konfiguration
Die parallele Skalierung leitet relevante Abfragen an neue dedizierte Cluster weiter. Neue Cluster haben dieselbe Größe (Typ und Anzahl der Knoten) wie der Hauptcluster.
Die Standardanzahl der für die parallele Skalierung verwendeten Cluster ist eins (1) mit der Möglichkeit, insgesamt bis zu zehn (10) Cluster zu konfigurieren.
Die Gesamtzahl der Cluster für die parallele Skalierung kann mit dem Parameter max_concurrency_scaling_clusters festgelegt werden. Durch Erhöhen dieser Einstellung werden zusätzliche redundante Cluster bereitgestellt.
Überwachung
Die AWS Redshift-Konsole verfügt über mehrere zusätzliche Diagramme. Das Diagramm Max Configured Concurrency Scaling Clusters zeigt den Wert von max_concurrency_scaling_clusters im Zeitverlauf an.
Die Anzahl der aktiven Skalierungscluster wird im Abschnitt "Parallelitätsskalierungsaktivität" in der Benutzeroberfläche angezeigt:
Auf der Registerkarte "Anforderungen" gibt es eine Spalte, in der angegeben ist, ob die Anforderung im Hauptcluster oder im Cluster mit paralleler Skalierung ausgeführt wurde:
Unabhängig davon, ob eine bestimmte Anforderung im Hauptcluster oder über einen Cluster mit paralleler Skalierung ausgeführt wurde, wird sie in stl_query.concurrency_scaling_status gespeichert.
Der Wert 1 gibt an, dass die Anforderung in einem Cluster mit paralleler Skalierung ausgeführt wurde, während andere Werte angeben, dass sie im Hauptcluster ausgeführt wurde.
Ein Beispiel:
Informationen zur parallelen Skalierung werden auch in einigen anderen Tabellen und Ansichten gespeichert, z. B. SVCS_CONCURRENCY_SCALING_USAGE. Darüber hinaus gibt es eine Reihe von Katalogtabellen, in denen Informationen zur parallelen Skalierung gespeichert sind.
Ergebnisse
Die Autoren haben am 29.03.19 um ca. 18:30 Uhr GMT eine parallele Skalierung für eine Warteschlange im internen Cluster gestartet. Sie haben den Parameter max_concurrency_scaling_clusters um ca. 20:30 Uhr am 29. März 2019 in 3 geändert.
So simulieren Sie die Anforderungswarteschlange und reduzieren die Anzahl der Steckplätze für diese Warteschlange von 15 auf 5.
Das folgende Dashboard-Diagramm von intermix.io zeigt die Anzahl der Anforderungen, die ausgeführt und in die Warteschlange gestellt werden, nachdem die Anzahl der Slots verringert wurde.
Wir sehen, dass sich die Wartezeit für Anforderungen in der Warteschlange erhöht hat, während die maximale Zeit mehr als 5 Minuten beträgt.
Hier sind die relevanten Informationen von der AWS-Konsole darüber, was während dieser Zeit passiert ist:
Redshift hat drei (3) parallele Skalierungscluster wie konfiguriert gestartet. Es scheint, dass diese Cluster nicht vollständig genutzt wurden, obwohl viele der Anforderungen in unserem Cluster in der Warteschlange standen.
Das Verwendungsdiagramm korreliert mit dem Skalierungsaktivitätsdiagramm:
Nach einigen Stunden überprüften die Autoren die Warteschlange, und es scheint, dass 6 Anforderungen mit paralleler Skalierung ausgeführt wurden. Wir haben auch zwei Anfragen selektiv über die Benutzeroberfläche geprüft. Sie haben nicht überprüft, wie diese Werte verwendet werden sollen, wenn mehrere parallele Cluster gleichzeitig aktiv sind.
Schlussfolgerungen
Parallele Skalierung kann die Warteschlangenzeit von Anforderungen während Spitzenlasten reduzieren.
Nach den Ergebnissen des Basistests stellte sich heraus, dass sich die Situation mit Ladeanforderungen teilweise verbessert hat. Die parallele Skalierung allein löste jedoch nicht alle Probleme mit der Parallelität.
Dies ist auf Einschränkungen bei den Abfragetypen zurückzuführen, die die parallele Skalierung verwenden können. Zum Beispiel haben Autoren viele Tabellen mit verschachtelten Sortierschlüsseln, und der größte Teil unserer Arbeitslast ist ein Datensatz.
Obwohl die parallele Skalierung in der WLM-Konfiguration keine universelle Lösung darstellt, ist die Verwendung dieser Funktion in jedem Fall einfach und verständlich.
Daher empfiehlt der Autor, es für Ihre WLM-Warteschlangen zu verwenden. Beginnen Sie mit einem einzelnen parallelen Cluster und überwachen Sie die Spitzenlast über die Konsole, um festzustellen, ob die neuen Cluster vollständig ausgelastet sind.
Da AWS zusätzliche Arten von Abfragen und Tabellen unterstützt, sollte die parallele Skalierung schrittweise effizienter werden.
Kommentar von Belkhodzhaev Daniyar, einem Ingenieur nach Skyeng
Wir bei Skyeng haben auch sofort auf die sich abzeichnende Möglichkeit der parallelen Skalierung hingewiesen.
Die Funktionalität ist sehr attraktiv, insbesondere angesichts der Tatsache, dass laut AWS die meisten Benutzer nicht einmal extra dafür bezahlen müssen.
So kam es, dass wir Mitte April eine ungewöhnliche Flut von Anfragen an den Redshift-Cluster hatten. In dieser Zeit haben wir häufig auf die Parallelitätsskalierung zurückgegriffen. Manchmal arbeitete der zusätzliche Cluster 24 Stunden am Tag, ohne anzuhalten.
Dies ermöglichte es, die Situation akzeptabel zu machen, wenn sie das Warteschlangenproblem nicht vollständig löste.
Unsere Beobachtungen stimmen weitgehend mit dem Eindruck der Jungs von intermix.io überein.
Wir haben auch festgestellt, dass trotz des Vorhandenseins ausstehender Anforderungen in der Warteschlange nicht alle Anforderungen sofort an einen parallelen Cluster umgeleitet wurden. Anscheinend liegt dies daran, dass der parallele Cluster noch einige Zeit zum Starten benötigt. Infolgedessen haben wir bei kurzfristigen Spitzenlasten immer noch kleine Warteschlangen, und die entsprechenden Alarme haben Zeit zum Arbeiten.
Nachdem wir die abnormalen Belastungen im April beseitigt hatten, gingen wir, wie AWS erwartet hatte, in den episodischen Nutzungsmodus - als Teil der freien Norm.
Sie können die gleichzeitigen Skalierungskosten in AWS Cost Explorer verfolgen. Sie müssen Service - Rotverschiebung, Verwendungstyp - CS auswählen, z. B. USW2-CS: dc2.large.
Details zu den Preisen in russischer Sprache finden Sie hier.