Bij Skyeng gebruiken we Amazon Redshift, inclusief parallel scaling, dus dit artikel van Stefan Gromoll, oprichter van dotgo.com, voor intermix.io vonden we interessant. Na de vertaling een stukje van onze ervaring van data-ingenieur Daniyar Belkhodzhaev.
maakt schaalvergroting mogelijk door nieuwe knooppunten aan het cluster toe te voegen. De noodzaak om met een piekaantal verzoeken om te gaan, kan leiden tot overprovisioning van knooppunten. Concurrency Scaling vergroot, in tegenstelling tot het toevoegen van nieuwe knooppunten, de rekenkracht indien nodig.
Parallelle schaling van Amazon Redshift geeft Redshift-clusters extra capaciteit om piekverzoekvolumes af te handelen. Het werkt door verzoeken naar nieuwe “parallelle” clusters op de achtergrond te verplaatsen. Aanvragen worden gerouteerd op basis van WLM-configuratie en -regels.
Prijzen voor parallelle schaalvergroting zijn gebaseerd op een kredietmodel met een gratis laag. Boven de gratis credits is de betaling gebaseerd op de tijd dat het Parallel Scaling Cluster verzoeken verwerkt.
De auteur testte parallelle schaling op een van de interne clusters. In dit bericht vertelt hij over de testresultaten en geeft hij tips om aan de slag te gaan.
Clustervereisten
Om parallelle schaling te gebruiken, moet uw Amazon Redshift-cluster aan de volgende vereisten voldoen:
- platform: EC2-VPC;
— knooppunttype: dc2.8xlarge, ds2.8xlarge, dc2.large of ds2.xlarge;
— aantal knooppunten: van 2 tot 32 (clusters met één knooppunt worden niet ondersteund).
Acceptabele verzoektypen
Parallelle schaling is niet geschikt voor alle typen query's. In de eerste versie verwerkt het alleen leesverzoeken die aan drie voorwaarden voldoen:
— SELECT-query's zijn alleen-lezen (hoewel er meer typen gepland zijn);
— de zoekopdracht verwijst niet naar een tabel met de sorteerstijl INTERLEAVED;
- De query maakt geen gebruik van Amazon Redshift Spectrum om naar externe tabellen te verwijzen.
Om naar het Parallel Scaling Cluster te worden gerouteerd, moet de aanvraag in de wachtrij staan. Bovendien komen zoekopdrachten in aanmerking voor de wachtrij , werkt niet op parallelle schaalclusters.
Wachtrijen en SQA vereisen een juiste configuratie . We raden u aan eerst uw WLM te optimaliseren. Dit vermindert de noodzaak voor parallelle schaling. En dit is belangrijk omdat parallel schalen slechts een bepaald aantal uren gratis is. AWS beweert dat parallelle schaalvergroting voor 97% van de klanten gratis zal zijn, wat ons bij de kwestie van de prijs brengt.
Kosten van parallelle schaling
AWS biedt een kredietmodel voor parallelle schaalvergroting. Elk actief cluster Verzamelt credits per uur, tot één uur gratis parallelle schaalcredits per dag.
U betaalt alleen wanneer uw Parallel Scaling Clusters-gebruik groter is dan het aantal ontvangen credits.
De kosten worden berekend op basis van een on-demand tarief per seconde voor een parallel cluster dat boven het gratis tarief wordt gebruikt. Er worden alleen kosten in rekening gebracht voor de duur van uw verzoeken, met een minimum van één minuut per keer dat een Parallel Scaling Cluster wordt geactiveerd. Het on-demand-tarief per seconde wordt berekend op basis van algemene prijsprincipes , dat wil zeggen dat het afhankelijk is van het type knooppunt en het aantal knooppunten in uw cluster.
Parallelle schaling lanceren
Voor elke WLM-wachtrij wordt parallelle schaling geactiveerd. Ga naar de AWS Redshift-console en selecteer Workload Management in het linkernavigatiemenu. Selecteer de WLM-parametergroep van uw cluster in het volgende vervolgkeuzemenu.
Naast elke wachtrij ziet u een nieuwe kolom met de naam 'Concurrency Scaling Mode'. De standaardinstelling is "Uitgeschakeld". Klik op "Bewerken" en u kunt de instellingen voor elke wachtrij wijzigen.
Configuratie
Parallelle schaling werkt door de juiste aanvragen door te sturen naar nieuwe speciale clusters. Nieuwe clusters hebben dezelfde grootte (type en aantal knooppunten) als het hoofdcluster.
Het standaardaantal clusters dat wordt gebruikt voor parallelle schaling is één (1), met de mogelijkheid om in totaal maximaal tien (10) clusters te configureren.
Het totale aantal clusters voor parallelle schaling kan worden ingesteld met de parameter max_concurrency_scaling_clusters. Het verhogen van de waarde van deze parameter zorgt voor extra redundante clusters.
controle
Er zijn verschillende extra grafieken beschikbaar in de AWS Redshift-console. In het diagram Max. geconfigureerde clusters voor gelijktijdig schalen wordt de waarde van max_concurrency_scaling_clusters in de loop van de tijd weergegeven.
Het aantal actieve schaalclusters wordt weergegeven in de gebruikersinterface in het gedeelte 'Gelijktijdige schaalactiviteit':
Op het tabblad Query's staat een kolom die aangeeft of de query is uitgevoerd in het hoofdcluster of in het parallelle schaalcluster:
Ongeacht of een bepaalde query is uitgevoerd in het hoofdcluster of via een parallelle schaalcluster, deze wordt opgeslagen in stl_query.concurrency_scaling_status.
Een waarde van 1 geeft aan dat de query is uitgevoerd in het parallelle schaalcluster, terwijl andere waarden aangeven dat deze is uitgevoerd in het primaire cluster.
Voorbeeld:
Informatie over gelijktijdigheidsschaling wordt ook opgeslagen in een aantal andere tabellen en weergaven, zoals SVCS_CONCURRENCY_SCALING_USAGE. Daarnaast zijn er een aantal catalogustabellen waarin informatie over parallelle schaling wordt opgeslagen.
Bevindingen
De auteurs zijn op 18-30-00 om ongeveer 29.03.2019:3:20 uur GMT begonnen met parallel schalen voor één wachtrij in het interne cluster. De parameter max_concurrency_scaling_clusters is op 30-00-29.03.2019 om ongeveer XNUMX:XNUMX:XNUMX uur gewijzigd in XNUMX.
Om een wachtrij met verzoeken te simuleren, hebben we het aantal slots voor deze wachtrij teruggebracht van 15 naar 5.
Hieronder ziet u een intermix.io-dashboarddiagram dat het aantal lopende verzoeken en in de wachtrij toont na het verminderen van het aantal slots.
We zien dat de wachttijd voor verzoeken in de wachtrij is toegenomen, waarbij de maximale tijd ruim 5 minuten bedraagt.
Hier is de relevante informatie van de AWS-console over wat er gedurende deze periode is gebeurd:
Redshift lanceerde drie (3) parallelle schaalclusters zoals geconfigureerd. Het lijkt erop dat deze clusters onderbenut waren, ook al stonden veel verzoeken in ons cluster in de wachtrij.
De gebruiksgrafiek komt overeen met de schaalactiviteitsgrafiek:
Na een paar uur controleerden de auteurs de wachtrij en het leek erop dat zes verzoeken parallel werden geschaald. We hebben ook willekeurig twee verzoeken getest via de gebruikersinterface. We hebben niet gecontroleerd hoe deze waarden moeten worden gebruikt als er meerdere parallelle clusters tegelijk actief zijn.
Bevindingen
Parallelle schaling kan de tijd die verzoeken in de wachtrij doorbrengen tijdens piekbelastingen verminderen.
Op basis van de resultaten van de basistest bleek dat de situatie met laadaanvragen deels is verbeterd. Parallelle schaling alleen loste echter niet alle gelijktijdigheidsproblemen op.
Dit komt door beperkingen op de typen query's die parallelle schaling kunnen gebruiken. De auteurs hebben bijvoorbeeld veel tabellen met verweven sorteersleutels, en het grootste deel van onze werklast bestaat uit schrijven.
Hoewel parallel schalen geen universele oplossing is voor het instellen van WLM, is het gebruik van deze functie eenvoudig en duidelijk.
Daarom raadt de auteur aan om het te gebruiken voor uw WLM-wachtrijen. Begin met één parallel cluster en monitor de piekbelasting via de console om te bepalen of de nieuwe clusters volledig worden benut.
Naarmate AWS ondersteuning toevoegt voor extra querytypen en tabellen, zou parallelle schaling geleidelijk steeds efficiënter moeten worden.
Commentaar van Daniyar Belkhodzhaev, Skyeng Data Engineer
Wij bij Skyeng merkten ook meteen de opkomende mogelijkheid van parallelle schaalvergroting op.
De functionaliteit is zeer aantrekkelijk, vooral gezien het feit dat AWS inschat dat de meeste gebruikers er niet eens extra voor hoeven te betalen.Het gebeurde zo dat we midden april een ongewone stroom verzoeken kregen aan het Roodverschuivingscluster. Gedurende deze periode hebben we vaak onze toevlucht genomen tot Concurrency Scaling; soms werkte een extra cluster 24 uur per dag zonder te stoppen.
Dit maakte het mogelijk om het probleem met wachtrijen niet volledig op te lossen, maar toch om de situatie acceptabel te maken.
Onze observaties vallen grotendeels samen met de indrukken van de jongens van intermix.io.
We merkten ook dat er weliswaar verzoeken in de wachtrij stonden, maar dat niet alle verzoeken onmiddellijk werden doorgestuurd naar het parallelle cluster. Blijkbaar gebeurt dit omdat het parallelle cluster nog steeds tijd nodig heeft om te starten. Als gevolg hiervan hebben we tijdens piekbelastingen op korte termijn nog steeds kleine wachtrijen en hebben de bijbehorende alarmen de tijd om te activeren.
Nadat we in april van de abnormale belastingen af waren, zijn we, zoals AWS verwachtte, in de occasionele gebruiksmodus terechtgekomen - binnen de vrije norm.
U kunt uw parallelle schaalkosten volgen in AWS Cost Explorer. U moet Service - Roodverschuiving, Gebruikstype - CS selecteren, bijvoorbeeld USW2-CS:dc2.large.U kunt meer lezen over prijzen in het Russisch
Bron: www.habr.com