De schaal van rekenresources aanpassen

Een van de belangrijke voordelen van de cloud is de mogelijkheid om de schaal van resources in een systeem on-demand aan te passen. U kunt de belasting van een systeem verminderen door omhoog te schalen (grotere resources inrichten) of uit te schalen (extra resources inrichten) door het gebruik te verlagen als gevolg van een verhoogde capaciteit of een bredere verdeling van de workload.

Schaalaanpassing kan helpen om de reactietijd (en de waargenomen prestaties vanuit het perspectief van de gebruiker) te verbeteren door de doorvoer te verhogen, omdat nu een groter aantal aanvragen kan worden verwerkt. Dit kan ook helpen bij het verminderen van de latentie tijdens piekbelasting, omdat een kleiner aantal aanvragen in de wachtrij wordt geplaatst tijdens piekbelastingen op één resource. Daarnaast kunt u met schaalaanpassing de betrouwbaarheid van het systeem verbeteren door het gebruik van resources te verminderen en te voorkomen dat het breekpunt wordt bereikt.

Het is belangrijk om te weten dat we met de cloud weliswaar eenvoudig nieuwere of betere resources kunnen inrichten, maar dat de kosten altijd een factor zijn die in overweging moet worden genomen. Daarom is het ook belangrijk om te herkennen wanneer u in of omlaag wilt schalen om de kosten te besparen, hoewel het handig is om omhoog of uit te schalen.

Horizontale schaalaanpassing (in- en uitschalen)

Horizontale schaalaanpassing is een strategie waarbij extra resources worden toegevoegd aan het systeem of waarbij overbodige resources in de loop van de tijd worden verwijderd uit het systeem. Dit type schaalaanpassing is nuttig voor de serverlaag wanneer de belasting van het systeem inconsistent is of op een onvoorspelbare manier schommelt. Door de aard van de schommelende belasting is het cruciaal om de juiste hoeveelheid resources in te richten om de belasting te allen tijde te kunnen verwerken.

Een paar overwegingen die van deze taak een ware uitdaging maken, zijn

• de opstarttijd van een instantie (bijvoorbeeld een virtuele machine);
• het prijsmodel van de cloudserviceprovider; en
• het potentiële winstverlies bij een lagere servicekwaliteit (QoS) als gevolg van het niet op tijd uitschalen.

Afbeelding 5: Voorbeeld van belastingspatroon.

Denk bijvoorbeeld aan het belastingspatroon in afbeelding 5 hierboven.

Stel dat we Amazon Web Services gebruiken, dat elke tijdseenheid gelijk is aan 1 uur van de daadwerkelijke tijd en dat er één server nodig is om 5000 aanvragen te verwerken. De vraag kent een piek tussen tijdseenheden 6 en 8 en tijdseenheden 14 en 16. Als voorbeeld bekijken we de tweede piekperiode. We zien dat rond tijdseenheid 16 een daling van de vraag optreedt en we beginnen het aantal toegewezen resources te verminderen. Omdat we binnen drie uur van ongeveer 90.000 aanvragen naar 10.000 aanvragen gaan, kunnen we de kosten verlagen van een stuk of tien extra instanties die rond tijdseenheid 15 online waren.

In afbeelding 6 ziet u een patroon voor schaalaanpassing waarmee het aantal instanties ad hoc wordt aangepast aan het belastingspatroon, waarbij het aantal instanties in het rood wordt weergegeven. In piekperioden wordt het aantal instanties naar respectievelijk 20 en 18 uitgeschaald, om de resources te bieden die nodig zijn om het verkeer te verwerken. Op andere momenten wordt het aantal instanties verlaagd (ingeschaald) om het resourcegebruik relatief constant te maken. Als we ervan uitgaan dat elke instantie 20 cent per uur kost, komen de kosten voor het online houden van 20 instanties voor een periode van 24 uur in totaal op 96 dollar. Door de schaal van het aantal instanties aan te passen (zoals weergegeven), verlaagt u de kosten tot ongeveer 42 dollar voor een jaarlijkse besparing van meer dan 15.000 dollar. Dat is een aanzienlijk bedrag voor vrijwel elke IT-begroting.

Afbeelding 6: In- en uitschalen met vraag.

Schaalaanpassing is afhankelijk van de kenmerken van het verkeer en de daaruit voortvloeiende belasting die bij een webservice is gegenereerd. Als het verkeer een voorspelbaar patroon volgt, bijvoorbeeld op basis van menselijk gedrag zoals het 's avonds streamen van films vanaf een webservice, kan de schaalaanpassing voorspellend zijn om de servicekwaliteit te handhaven. Het verkeer kan echter in veel gevallen niet worden voorspeld en de schaalaanpassingssystemen moeten reactief zijn op basis van verschillende criteria.

Het is handig om te weten dat in- en uitschalen kan worden uitgevoerd met zowel containerinstanties als VM-instanties. Workloads worden van oudsher uitgevoerd in de cloud in VM's, maar het wordt steeds gebruikelijker om ze uit te voeren in containers. Schaalaanpassing wordt bereikt met workloads op basis van een virtuele machine door het aantal VM's te verhogen en te verlagen. Op deze manier kan ook de schaal van op containers gebaseerde workloads worden aangepast door het aantal containers te variëren. Omdat containers vaak sneller opstarten dan VM's, is de elasticiteit enigszins groter omdat nieuwe containerinstanties in minder tijd online kunnen worden gebracht dan VM-instanties.

Verticale schaalaanpassing (omhoog en omlaag schalen)

Horizontale schaalaanpassing is een manier om elasticiteit te bereiken, maar dit is niet de enige manier. Stel dat het verkeer naar uw website zelden meer dan 15.000 aanvragen per tijdseenheid overschrijdt en dat u één grote instantie inricht die 20.000 aanvragen kan verwerken; genoeg om normaal verkeer redelijk goed te verwerken en kleine pieken op te vangen. Als de belasting op de website toeneemt, kunt u de toename in het verkeer redelijk opvangen door de serverinstantie te vervangen door een instantie met twee keer zoveel CPU-kernen en twee keer zoveel RAM-geheugen. Dit staat bekend als omhoog schalen.

De primaire uitdaging voor verticale schaalaanpassing is dat de overschakeling wat tijd kost die als uitvaltijd moet worden beschouwd. Dit komt doordat de servicekwaliteit tijdens dat interval afneemt, omdat alle bewerkingen van de kleinere instantie naar een grotere instantie moeten worden verplaatst, zelfs als de overschakelingstijd niet meer dan een paar minuten duurt.

Een andere beperking van verticale schaalaanpassing is een geringe granulariteit. Als u tien serverinstanties online hebt en de capaciteit tijdelijk met 10% wilt verhogen, kunt u uitschalen van 10 naar 11 instanties om het gewenste resultaat te krijgen. Bij verticale schaalaanpassing heeft de eerstvolgende grotere instantie echter doorgaans ongeveer twee keer zoveel capaciteit als de vorige instantie. Dit is het equivalent van horizontale schaalaanpassing van 10 naar 20 instanties, om ruimte te bieden voor een toename van 10% in het verkeer. Dit is minder rendabel dan horizontale schaalaanpassing.

Een laatste overweging waarmee rekening moet worden gehouden met betrekking tot verticale schaalaanpassing is beschikbaarheid. Als u één grote instantie hebt voor alle klanten van een website en die instantie uitvalt, wordt de website ook uitgeschakeld. Als u daarentegen tien kleine instanties inricht voor het verwerken van dezelfde belasting en een van deze uitvalt, zien gebruikers misschien een kleine afname van de prestaties, maar ze hebben nog steeds toegang tot de site. Dus zelfs als de belasting voorspelbaar is en gestaag toeneemt naarmate de populariteit van de service toeneemt, kiezen veel cloudbeheerders ervoor om de schaal horizontaal aan te passen in plaats van verticaal.

De schaal van de serverlaag aanpassen

Schaalbaarheid is soms genuanceerder dan het eenvoudig inrichten van meer resources (uitschalen) of grotere resources (omhoog schalen). In de serverlaag kan een hogere vraag leiden tot meer concurrentie voor specifieke typen resources zoals CPU, geheugen en netwerkbandbreedte. Cloudserviceproviders bieden doorgaans VM's die zijn geoptimaliseerd voor intensieve rekenworkloads, geheugenintensieve workloads en netwerkintensieve workloads. Als u weet wat uw workload is en u het juiste type VM hebt gekozen, is het belangrijk om meer of grotere VM's te activeren. Het is beter om met vijf VM's intensieve rekenworkloads te verwerken dan met tien, zelfs als VM's die voor CPU-intensieve workloads zijn geoptimaliseerd 20% duurder zijn dan meer algemene VM's.

Het uitbreiden van het aantal hardwareresources is niet altijd de beste oplossing voor het verbeteren van de prestaties van een service. Het verhogen van de efficiëntie van de algoritmen die door de service worden gebruikt, kan ook conflicten met resources verminderen en het gebruik verbeteren, waardoor niet langer de schaal van fysieke resources hoeft te worden aangepast.

Een belangrijke overweging bij schaalaanpassing is 'statefulness' (of het gebrek daaraan). Een staatloos serviceontwerp is geschikt voor een schaalbare architectuur. Een staatloze service betekent in feite dat de clientaanvraag alle informatie bevat die nodig is om een aanvraag van de server te verwerken. De server slaat geen clientgegevens op in de instantie en slaat alle informatie over de sessie op in de serverinstantie.

Wanneer u een staatloze service gebruikt, kunt u wanneer u maar wilt wisselen tussen resources, zonder enige configuratie die is vereist voor het onderhouden van de context (status) van de clientverbinding voor volgende aanvragen. Als de service stateful is, is voor schaalaanpassing van resources een strategie vereist om de context van de bestaande configuratie over te dragen naar de nieuwe configuratie. Houd er rekening mee dat er methoden zijn voor het implementeren van stateful services, bijvoorbeeld het onderhouden van een netwerkcache zodat de context kan worden gedeeld tussen servers.

De schaal van de gegevenslaag aanpassen

In op gegevens gerichte toepassingen, met een groot aantal lees- en schrijfbewerkingen (of beide) naar een database of opslagsysteem, wordt de retourtijd voor elke aanvraag vaak beperkt door lees- en schrijftijden op de vaste schijf. Grotere instanties bieden hogere I/O-prestaties, waardoor de zoektijden op de harde schijf kunnen worden verbeterd en de latentie van de service kan worden verkort. Hoewel meerdere gegevensinstanties in de gegevenslaag de betrouwbaarheid en beschikbaarheid van de toepassing kunnen verbeteren door failoverredundantie te bieden, biedt het repliceren van gegevens tussen meerdere instanties extra voordelen bij het verminderen van de netwerklatentie als de client wordt bediend door een datacentrum dat zich fysiek dichterbij bevindt. Sharding, of het partitioneren van de gegevens over meerdere resources, is een andere strategie voor horizontale schaalaanpassing van gegevens. In plaats van de gegevens simpelweg in meerdere instanties te repliceren, worden de gegevens gepartitioneerd in segmenten en opgeslagen op meerdere gegevensservers.

Een extra uitdaging bij schaalaanpassing van de gegevenslaag is het handhaven van consistentie (een leesbewerking die op alle replica's hetzelfde is), beschikbaarheid (lees- en schrijfbewerkingen die altijd slagen) en partitietolerantie (gegarandeerde eigenschappen in het systeem blijven behouden wanneer communicatie tussen knooppunten wordt voorkomen door fouten). Dit wordt vaak aangeduid als de CAP-stelling, die aangeeft dat het in een gedistribueerd databasesysteem heel moeilijk is om alle drie de eigenschappen volledig te verkrijgen, en dus op zijn best uit een combinatie van twee eigenschappen kan bestaan¹.

Verwijzingen

1. Wikipedia. CAP-stelling. https://en.wikipedia.org/wiki/CAP_theorem.