Belastingspatronen berekenen

Als verkeer naar een cloudresource, zoals een virtuele machine (of een set VM's) of een web-app, constant en ongewijzigd zou zijn, zou u de schaal niet hoeven aan te passen. Een cloudbeheerder kan simpelweg het aantal instanties inrichten dat nodig is om de belasting te verwerken, en klaar is kees. Maar de verkeerspatronen wijzigen wel degelijk na verloop van tijd, soms voorspelbaar soms niet. In de praktijk moet een beheerder de belasting vaststellen van de resources die ze beheert en schaalaanpassing gebruiken om ervoor te zorgen dat het systeem aan de vraag kan blijven voldoen.

Voordat we gaan bespreken hoe de schaal kan worden aangepast, bespreken we waarom we de schaal aanpassen door in detail in te gaan op een aantal van de algemene belastingspatronen die veel voorkomen op VM's en andere cloudresources.

Consistente groei

Een van de meest voorkomende factoren voor schaalaanpassing is een consistente groei in de vraag. Afbeelding 1 toont het verkeer naar de website van een bedrijf gedurende een periode van 24 maanden. Het bedrijf groeit snel en het verkeer naar hun website weerspiegelt dat. Als we ervan uitgaan dat één webserver 5000 aanvragen per tijdseenheid kan verwerken, begint het bedrijf met wellicht drie of vier webservers, maar twee jaar later hebben ze er ongeveer 20 nodig om aan de toenemende vraag te kunnen voldoen en de klanten goed te blijven helpen.

Afbeelding 1: Consistente groei.

Een consistente groei is van de eenvoudigste belastingspatronen om te compenseren, omdat de wijziging stabiel en geleidelijk is. We kunnen de schaal waarschijnlijk aanpassen met behulp van fysieke servers omdat we kunnen voorspellen wanneer de volgende server (of set servers) nodig is en we weken of zelfs maanden hebben om ons voor te bereiden, maar met cloud-computing kunnen we al binnen enkele minuten nieuwe virtuele servers online brengen. En hoewel de 24-maandelijkse trend een stabiele en voorspelbare groei toont, kan de belasting aanzienlijk schommelen binnen kortere perioden. Cloud-computing kan veel beter worden aangepast aan microtrends dan schaalaanpassing met fysieke servers.

Voortdurende schommelende belasting

De snelle elasticiteit van cloud-computing is essentieel wanneer de belasting op een onvoorspelbare manier gedurende relatief korte perioden schommelt. In afbeelding 2 ziet u de belasting van een website gedurende een periode van 24 uur. Stel nogmaals dat één server 5000 aanvragen per tijdseenheid kan verwerken. Het aantal benodigde servers varieert van 2 tot 16 in de loop van de dag. We kunnen dit verkeer inpassen door 16 virtuele webservers te allen tijde online te houden, maar de cloudserviceproviders brengen ook kosten in rekening voor VM's wanneer ze inactief zijn. Met de overtollige capaciteit wordt niet alleen energie verspild, maar worden de kosten bovendien zo ongeveer verdubbeld.

Afbeelding 2: Constant fluctuerende belasting.

Cyclische belastingen

In afbeelding 3 ziet u een belasting die in een regelmatig en enigszins voorspelbaar patroon toeneemt en afneemt; de vraag neemt bijvoorbeeld toe tijdens kantooruren en valt de avond- en nachturen weer terug. Voor deze belasting zijn maximaal 20 servers nodig voor het verwerken van de vraag, opnieuw uitgaande van 5000 aanvragen per tijdseenheid per server. Het is onredelijk om fysieke servers 24 uur per dag in en uit te schakelen, maar virtuele servers kunnen eenvoudig op basis van een schema worden ingericht en buiten gebruik worden gesteld, om ervoor te zorgen dat de servercapaciteit ongeveer gelijk is aan de vraag. Fysieke servers die gedurende 12 uur per dag inactief zijn of nauwelijks worden gebruikt, vertegenwoordigen ongewenste CapEx en onnodig energieverbruik. Virtuele servers brengen ook kosten met zich mee, maar ze kunnen worden verwijderd wanneer ze niet nodig zijn en snel opnieuw aangemaakt wanneer de vraag dat vereist.

Afbeelding 3: Cyclische belasting die elke 24 uur wordt herhaald.

Onvoorspelbare uitbarstingen

Een van de moeilijkste patronen om mee om te gaan wat kosten en onderhoud betreft, is een patroon dat onvoorspelbare bursts veroorzaakt (afbeelding 4). Als pieken voorspelbaar zijn, bijvoorbeeld als via de website een pizzabezorgservice wordt aangeboden die een hogere belasting ondervindt in weekenden en op feestdagen, dan kan hiervoor extra capaciteit worden gepland. Maar als ze niet voorspelbaar zijn, moeten we ervoor zorgen dat ze op elk gewenst moment kunnen worden verwerkt.

Afbeelding 4: Onvoorspelbare bursts.

We kunnen overmatig hoge kosten (de kosten van servers die zijn ingericht voor het verwerken van piekbelastingen, maar die in tijden van minder verkeer relatief inactief zijn) voorstellen als het gebied tussen de bovenkant van de curve en een horizontale lijn die door het hoogste punt is getekend. In dat geval zijn de kosten voor het leveren van 100.000 aanvragen per tijdseenheid voor de belasting in afbeelding 4 aanzienlijk hoger dan de kosten voor het bieden van gelijkwaardige capaciteit in afbeelding 3.

Als we kunnen anticiperen op de omvang van de piekvraag (niet noodzakelijkerwijs de timing daarvan) en u zich geen zorgen hoeft te maken over kosten, kunnen we op elk moment voldoende capaciteit bieden door voldoende servers in te richten om de hoogste belastingen te verwerken. Met cloud-computing kunnen we resources online plaatsen wanneer ze nodig zijn en ze offline halen wanneer ze niet meer nodig zijn (waardoor er ook geen kosten voor deze resources meer in rekening worden gebracht). Elasticiteit wordt verkregen door de schaal van cloudresources aan te passen. Laten we het concept van schaalaanpassing bekijken om te zien waarom het een belangrijke factor is voor de rendabiliteit van cloud-computing.