Resources schalen

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

Schalen kan helpen om de prestaties te verbeteren door de doorvoer te verbeteren, aangezien dan 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 kan dit helpen bij het verbeteren van de betrouwbaarheid van het systeem door het gebruik van resources te verminderen, zodat het breekpunt van de resource verder weg ligt.

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. Dus zelfs als het zinvol is om omhoog of uit te schalen, is het ook belangrijk om te weten wanneer u weer omlaag of in moet schalen om kosten te besparen. In een n-tier-toepassing is het ook belangrijk om te bepalen waar zich de knelpunten bevinden en welke laag moet worden geschaald: de gegevenslaag of de serverlaag.

Het schalen van resources wordt mogelijk gemaakt door taakverdeling (dit is eerder besproken), waarmee het schaalbare aspect van een systeem kan worden gemaskeerd door dit te verbergen achter een consistent eindpunt.

Strategieën voor schalen

Horizontaal schalen (uit- en inschalen)

Horizontaal schalen is een strategie waarbij extra resources kunnen worden toegevoegd aan het systeem of overbodige resources kunnen worden verwijderd uit het systeem. Dit type schaalaanpassing is nuttig voor de serverlaag, wanneer de belasting van het systeem onvoorspelbaar is en op een inconsistente manier varieert. 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 dit een uitdagende taak maken, zijn de opstarttijd van een exemplaar, het prijsmodel van de cloudserviceprovider en het potentiële verlies aan omzet door het afnemen van de geleverde kwaliteit (QoS) door niet op tijd uit te schalen. Laten we bijvoorbeeld eens kijken naar het volgende belastingspatroon:

Afbeelding 6: Voorbeeld van een patroon voor het laden van aanvragen

Stel dat we Amazon Web Services gebruiken. Stel ook dat elke tijdseenheid gelijk is aan drie uur van de werkelijke tijd en dat er één server nodig is om 5000 aanvragen te verwerken. Als u de belasting bekijkt tijdens de tijdseenheden 16 tot 22, is er sprake van een enorme schommeling van de belasting. We zien dat er rond tijdseenheid 16 een daling van de vraag optreedt en dat het aantal toegewezen resources dan kan worden verminderd. Omdat we van ongeveer 50.000 aanvragen bijna nul aanvragen gaan in een tijdsbestek van drie uur, kunnen we theoretisch gezien de kosten van tien instanties besparen die anders rond tijdseenheid 16 actief zouden zijn geweest.

Laten we nu eens aannemen dat elke tijdseenheid overeenkomt met twintig minuten van de werkelijke tijd. Als we in dit voorbeeld alle resources bij tijdseenheid 16 uitschalen om na twintig minuten weer nieuwe resources op te starten, stijgen de kosten in plaats van dat ze afnemen omdat AWS elke rekeninstantie op uurbasis factureert.

Naast de bovenstaande twee overwegingen moet een serviceprovider ook de verliezen evalueren die het gevolg zijn van afgenomen QoS gedurende tijdseenheid twintig, als er slechts capaciteit is voor 90.000 aanvragen in plaats van 100.000.

De schaalaanpassing is afhankelijk van de kenmerken van het verkeer en de daaruit voortvloeiende belasting die bij een webservice wordt gegenereerd. Als het verkeer een voorspelbaar patroon volgt (bijvoorbeeld op basis van menselijk gedrag zoals het streamen van films van een webservice 's avonds), kan de schaalaanpassing voorspellend zijn om de QoS te behouden. In veel gevallen kan het verkeer echter niet worden voorspeld en moeten de schaalsystemen reactief zijn op basis van verschillende criteria, zoals in de bovenstaande voorbeelden is getoond.

Verticaal schalen (omhoog en omlaag schalen)

Er zijn bepaalde soorten belasting voor serviceproviders die beter voorspelbaar zijn dan andere. Als u bijvoorbeeld weet op basis van historische patronen dat het aantal aanvragen altijd 10.000-15.000 zal zijn, kunt u met een gerust hart aannemen dat één server die 20.000 aanvragen kan verwerken, voldoende is voor de doeleinden van de serviceprovider. Deze belasting kan in de toekomst toenemen, maar zolang dat op een consistente manier gebeurt, kan de service worden overgezet naar een grotere instantie die meer aanvragen kan verwerken. Dit is geschikt voor kleine toepassingen die te maken hebben met een geringe hoeveelheid verkeer.

De uitdaging bij verticaal schalen is dat de overschakeling altijd wat tijd kost en dat die als uitvaltijd moet worden beschouwd. Dit komt doordat de QoS tijdens dat interval afneemt, omdat alle bewerkingen van de kleinere instantie naar een grotere instantie moeten worden overgezet, zelfs als de overschakelingstijd niet meer dan een paar minuten duurt.

Daarnaast bieden de meeste cloudproviders rekenresources in toenemende rekenkracht door de rekenkracht van een resource te verdubbelen. Daarom is de granulariteit bij omhoog schalen niet zo fijn als bij horizontaal schalen. Dus zelfs als de belasting voorspelbaar is en geleidelijk toeneemt naarmate de populariteit van de service toeneemt, kiezen veel serviceproviders voor horizontaal schalen in plaats van verticaal.

Overwegingen voor schalen

Controleren

Bewaking of monitoring is een van de meest cruciale elementen voor het effectief schalen van resources, omdat u hiermee de beschikking krijgt over metrische waarden die u kunt gebruiken om te interpreteren welke onderdelen van het systeem moeten worden geschaald en wanneer dit moet gebeuren. Door bewaking kunnen verkeerspatronen of het resourcegebruik worden geanalyseerd, om een goed onderbouwde beoordeling te geven over wanneer en in welke mate de schaal van resources moet worden aangepast om de QoS te maximaliseren en de kosten te minimaliseren.

Er zijn verschillende aspecten van resources die worden bewaakt om schaalaanpassing van resources te activeren. De meest voorkomende metrische waarde is het resourcegebruik. Met een bewakingsservice kan bijvoorbeeld het CPU-gebruik van elk resourceknooppunt worden bijgehouden en de schaal van resources worden aangepast als het gebruik buitensporig of te laag is. Als het gebruik voor elke resource bijvoorbeeld hoger is dan 95%, is het waarschijnlijk een goed idee om meer resources toe te voegen omdat het systeem zwaar wordt belast. Serviceproviders bepalen deze triggerpunten doorgaans door het breekpunt van resourceknooppunten te analyseren, te bepalen wanneer ze problemen krijgen en hun gedrag onder verschillende belastingsniveaus in kaart te brengen. Hoewel het, vanuit het oogpunt van de kosten, belangrijk is om elke resource maximaal te benutten, is het raadzaam om wat ruimte vrij te houden voor het besturingssysteem voor overheadactiviteiten. Evenzo geldt dat mogelijk niet alle resourceknooppunten nodig zijn en een aantal hiervan kan worden verwijderd als het gebruik aanzienlijk lager is dan zeg 50%.

In de praktijk bewaken serviceproviders doorgaans een combinatie van verschillende metrische gegevens van een resourceknooppunt om te evalueren wanneer de schaal van resources moet worden aangepast. Enkele hiervan zijn CPU-gebruik, geheugenverbruik, doorvoer en latentie. Azure biedt Azure Monitor als een extra service die elke Azure-resource kan bewaken en dergelijke gegevens kan verstrekken.

Staatloos

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 gegevens van 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, vereist schaalaanpassing van resources een strategie om de context van de bestaande knooppuntconfiguratie over te brengen naar de nieuwe knooppuntconfiguratie. Houd er rekening mee dat er methoden zijn voor het implementeren van stateful services, bijvoorbeeld het onderhouden van een netwerkcache met Memcached zodat de context kan worden gedeeld tussen de servers.

Bepalen wat u wilt schalen

Afhankelijk van de aard van de service moeten verschillende resources worden geschaald, afhankelijk van de vereiste. In het geval van de serverlaag bestaat de kans dat bij een toename van de workloads, afhankelijk van het type toepassing, er resourceconflicten kunnen ontstaan voor wat betreft CPU, geheugen, netwerkbandbreedte of al deze onderdelen. Door het verkeer te controleren, kunnen we bepalen welke resource in het nauw komt en die specifieke resource vervolgens op de juiste manier schalen. Cloudserviceproviders bieden niet altijd de granulariteit om alleen rekenkracht of geheugen te schalen, maar ze bieden wel verschillende soorten rekeninstanties die zijn afgestemd op belastingen die reken- of geheugenintensief zijn. In het geval van een toepassing die bijvoorbeeld geheugenintensieve workloads heeft, zou het raadzaam zijn om de resources omhoog te schalen naar instanties die zijn geoptimaliseerd voor geheugen. Voor toepassingen die een groot aantal aanvragen moeten verwerken die niet per se veel rekenkracht of geheugen nodig hebben, is het uitschalen van meerdere standaard-rekeninstanties mogelijk een betere strategie.

Het uitbreiden van de hardwareresources is niet altijd de beste oplossing om de prestaties van een service te verbeteren. 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 het niet meer nodig is om de schaal van fysieke resources aan te passen.

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 voor lees- en schrijfbewerkingen, waardoor de zoektijden op de harde schijf kunnen worden verbeterd, wat weer een zeer gunstige invloed kan hebben op de latentie van de service. Als u meerdere gegevensinstanties in de gegevenslaag hebt, kan de betrouwbaarheid en beschikbaarheid van de toepassing worden verbeterd door failover-redundantie te bieden. Het repliceren van gegevens over meerdere instanties heeft als extra voordeel dat de netwerklatentie wordt verminderd als de client wordt bediend door een datacenter dat zich fysiek dichter bij de client 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 gegevens gepartitioneerd in verschillende partities en opgeslagen op meerdere gegevensservers.

De extra uitdaging bij het schalen van de gegevenslaag is dat consistentie behouden blijft (een leesbewerking op alle replica's is hetzelfde), beschikbaarheid (lees- en schrijfbewerkingen altijd slagen) en partitietolerantie (gegarandeerde eigenschappen in het systeem worden behouden wanneer communicatie tussen knooppunten wordt voorkomen). 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 dat het systeem dus op zijn best uit een combinatie van twee eigenschappen kan bestaan. In latere modules leert u meer over strategieën voor het schalen van databases en de CAP-stelling.