Automatische schaalaanpassing in de cloud

Omhoog schalen of uitschalen om aan een verhoogde vraag te voldoen en inschalen of omlaag schalen om de kosten te verlagen wanneer de vraag afneemt, kan handmatig worden uitgevoerd door cloudbeheerders. Een waakzame beheerder kan bijvoorbeeld detecteren dat de vraag toeneemt en de hulpprogramma's van cloudserviceproviders gebruiken om extra virtuele machines online te brengen (uitschalen) of bestaande VM's te vervangen door grotere machines met meer CPU en meer geheugen (omhoog schalen). Het sleutelwoord is 'watchful'. Als de vraag piekt en niemand zich ervan bewust is, kan het systeem als geheel langzaam, zelfs niet reagerend, worden voor eindgebruikers. Als u daarentegen omhoog schaalt of uitschaalt om zwaardere belastingen te kunnen verwerken en daarna vergeet terug te schalen wanneer de belasting afneemt, betaalt u uiteindelijk voor resources die u niet nodig hebt.

Daarom bieden populaire cloudplatforms automatische schaalaanpassingsmechanismen om resources te schalen als reactie op de fluctuerende vraag zonder menselijke tussenkomst. Er zijn twee primaire methoden voor automatische schaalaanpassing:

• Op tijd gebaseerde resources schalen volgens een vooraf bepaald schema. Als de website van uw organisatie bijvoorbeeld de hoogste belasting ondervindt tijdens kantooruren, configureert u automatisch schalen zodat resources elke ochtend om 8:00 uur omhoog of omlaag worden geschaald en elke middag omlaag of om 17:00 uur worden geschaald. Schaalaanpassing op basis van tijd wordt soms ook wel gepland schalen genoemd.

• Op basis van metrische gegevens: als belastingen minder voorspelbaar zijn, schaalt u resources op basis van vooraf gedefinieerde metrische gegevens, zoals CPU-gebruik, geheugendruk of gemiddelde wachttijd van aanvragen. Als het gemiddelde CPU-gebruik bijvoorbeeld 70% bereikt, worden automatisch extra VM's online gezet, en wanneer het CPU-gebruik weer terugzakt naar 30%, moet u de inrichting van de extra VM's ongedaan maken.

Of u nu wilt schalen op basis van tijd of metrische gegevens of beide, automatische schaalaanpassing is afhankelijk van schaalregels of schaalbeleid dat is geconfigureerd door een cloudbeheerder. Moderne cloudplatforms bieden ondersteuning voor schaalaanpassingsregels die variëren van eenvoudige, zoals uitvouwen van twee exemplaren tot vier elke dag om 8:00 uur en terugkeren naar twee exemplaren om 17:00 uur, tot complex. Verhoog bijvoorbeeld het aantal VM's met één als het maximale CPU-gebruik 70% overschrijdt of de gemiddelde wachttijd van de aanvraag 5 seconden bereikt. Voor het vinden van de juiste combinatie van regels zal de cloudbeheerder wat moeten experimenteren.

Alle belangrijke cloudserviceproviders, waaronder Amazon, Microsoft en Google, bieden ondersteuning voor automatische schaalaanpassing. Automatische schaalaanpassing van AWS kan worden toegepast op EC2-instanties, DynamoDB-tabellen en geselecteerde andere AWS-cloudservices. Azure biedt opties voor automatische schaalaanpassing voor belangrijke services, waaronder App Service en Virtual Machines. Google doet hetzelfde voor Google Compute Engine en Google App Engine.

In het algemeen wordt met services voor automatische schaalaanpassing niet omhoog en omlaag geschaald, maar in- en uitgeschaald, deels omdat er bij omhoog en omlaag schalen een instantie door een andere instantie moet worden vervangen waardoor enige uitvaltijd onvermijdelijk is in de periode dat nieuwe instanties worden gemaakt en online worden gebracht.

Automatische schaalaanpassing op basis van tijd

Automatische schaalaanpassing op basis van tijd is geschikt wanneer de belasting op een voorspelbare manier schommelt. De IT-systemen van veel organisaties hebben bijvoorbeeld tijdens kantooruren de hoogste belasting en ervaren mogelijk in de vroegste ochtenduren juist heel weinig belasting. Domino's Pizza's website kan op alle uren van de dag laden omdat het meer dan 16.000 winkels in bijna 100 landen/regio's beheert. Maar zoals verwacht is er in bepaalde perioden in het jaar sprake van een hogere belasting dan normaal.

Beide scenario's zijn geschikt voor automatische schaalaanpassing op basis van tijd. In afbeelding 7 ziet u hoe geplande automatische schaalaanpassing wordt uitgevoerd in Azure. In dit voorbeeld configureert een cloudbeheerder een Azure-app Service die als host fungeert voor de website van de organisatie om standaard twee exemplaren uit te voeren, maar schaal maximaal vier exemplaren tussen 6:00 uur en 18:00 uur zes dagen per week, met uitzondering van zondag. Als de beheerder in plaats daarvan de optie Begin-/einddatums opgeven selecteert, kan hij of zij net zo eenvoudig de App Service configureren om uit te schalen naar 10 instanties op de zondag waarop de Super Bowl wordt gespeeld. De beheerder kan ook meerdere schaalvoorwaarden definiëren om ook op andere datums uit te schalen.

Afbeelding 7: Geplande automatische schaalaanpassing in Azure.

Automatische schaalaanpassing gebruiken die op metrische gegevens is gebaseerd

Schaalaanpassing op basis van metrische gegevens, zoals CPU-gebruik en gemiddelde wachttijd van aanvragen, is geschikt wanneer de belasting minder voorspelbaar is. Bewaking is een cruciaal element voor het effectief automatisch aanpassen van de schaal van resources op basis van metrische gegevens over prestaties, omdat de automatische schaalaanpassingsfunctie hierdoor weet wanneer er kan worden geschaald. Door bewaking kunnen verkeerspatronen of het resourcegebruik worden geanalyseerd, om een goed onderbouwde beoordeling te maken over wanneer en in welke mate de schaal van resources moet worden aangepast om een maximale kwaliteit van de service te waarborgen en tegelijkertijd 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 90%, is het waarschijnlijk een goed idee om meer resources toe te voegen omdat het systeem zwaar wordt belast. Serviceproviders bepalen doorgaans deze triggerpunten door het breekpunt van resourceknooppunten te analyseren, te kijken wanneer ze beginnen te mislukken 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 lager is dan bijvoorbeeld 30%.

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. AWS maakt gebruik van CloudWatch om EC2-resources te bewaken en metrische gegevens voor schaalaanpassing te bieden (afbeelding 8). CloudWatch houdt metrische gegevens bij voor alle EC2-instanties in een schaalgroep en genereert een alarm wanneer een bepaald metrisch gegeven een drempelwaarde overschrijdt, bijvoorbeeld wanneer het CPU-gebruik hoger is dan 70%. AWS verhoogt of verlaagt vervolgens het aantal EC2-instanties op basis van het schaalaanpassingsbeleid dat door een beheerder is geconfigureerd.

Afbeelding 8: EC2-exemplaren automatisch schalen in AWS.

AWS biedt ook ondersteuning voor voorspellend schalen, waarbij machine learning wordt gebruikt om verkeerspatronen te anticiperen en het aantal exemplaren dienovereenkomstig te beheren. Het doel is om de schaal van cloudresources intelligent aan te passen zonder dat een cloudbeheerder regels voor automatische schaalaanpassing hoeft te configureren. Grote cloudserviceproviders vinden voortdurend nieuwe manieren om hun platformen te verbeteren met machine learning. Microsoft gebruikt nu bijvoorbeeld machine learning om de tolerantie van Virtuele Azure-machines te verbeteren door proactief VM-fouten te voorspellen en te beperken¹.

Verwijzingen

1. Microsoft (2018). Verbetering van de tolerantie van virtuele Azure-machines met voorspellende ML en livemigratie. https://azure.microsoft.com/blog/improving-azure-virtual-machine-resiliency-with-predictive-ml-and-live-migration/.