SDN – Software Development Network SDN – Software Development Network – De SDN verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Microsoft en .NET.
Artikel uit SDN Magazine 147
Maak kennis met Azure App Service, een juweeltje in de Azure-servicecatalogus dat snel een van mijn favorieten is geworden. Dit krachtige platform stelt je in staat om naadloos je lift-and-shift applicaties over te zetten van een virtuele machine naar een zeer gepolijste, semi-cloud-native app. Onder de vele indrukwekkende functies biedt Azure App Service zowel verticale als horizontale automatische schalingsmogelijkheden. Dit betekent dat je indien nodig rekencapaciteit op aanvraag kunt benutten of kosten kunt besparen tijdens periodes van inactiviteit. Maar hoe zet je deze automatische schalingsfunctionaliteit eigenlijk op? Welke metrics, instellingen en strategieën zijn essentieel voor een succesvolle implementatie? Laten we duiken in de wereld van Azure App Service auto-scaling.
Basisprincipes van schalen
Schalen is een cruciaal aspect van het beheren van computing power in een cloudomgeving, en er zijn twee primaire opties om te overwegen: horizontaal schalen en verticaal schalen.
Horizontaal schalen houdt in dat er compute units, zoals VM’s of containers, van dezelfde grootte of type worden toegevoegd of verwijderd om wisselende workloads aan te kunnen. Een eenvoudig voorbeeld is het inzetten van nieuwe instanties van een app naast bestaande exemplaren of deze naar behoefte te verwijderen. Deze aanpak biedt een flexibelere en kosteneffectievere manier om schommelingen in de vraag op te vangen.
Aan de andere kant richt verticaal schalen zich op het vergroten van de rekenkracht van een enkele node of VM. Een veelvoorkomend voorbeeld is het vergroten van de vCPU-cores op een VM of pod om de verwerkingscapaciteit te vergroten. Deze methode kan met name nuttig zijn wanneer specifieke componenten binnen een applicatie meer resources nodig hebben om optimaal te presteren.
Zowel horizontale als verticale schaalopties voorzien in verschillende behoeften en scenario’s, waardoor het essentieel is om hun unieke voordelen en beperkingen te begrijpen om je cloudomgeving effectief te optimaliseren.
Schalingsopties
Azure App Service biedt drie verschillende schaalconfiguraties om te gebruiken voor diverse scenario’s. Elk van deze opties kan je helpen jouw omgeving te optimaliseren voor prestaties, kosten en betrouwbaarheid.
- Handmatig schalen: Deze optie is ideaal voor testdoeleinden of de initiële opzet van de omgeving. Het is echter niet aan te bevelen voor productieomgevingen, omdat het handmatige interventie vereist om resources aan te passen, wat tijdrovend kan zijn en vatbaar is voor menselijke fouten.
- Gepland schalen: Met deze methode is het mogelijk vaste data of tijden in te stellen voor het in- of uitschalen, waardoor het een handige en laagdrempelige oplossing is voor veel organisaties. Door te profiteren van voorspelbare gebruikspatronen, kan gepland schalen leiden tot zowel prestatieverbeteringen als kostenvermindering. Een goed voorbeeld is het terugschalen van de infrastructuur tijdens de nachtelijke uren of in het weekend wanneer het gebruik doorgaans lager is. Deze benadering zorgt ervoor dat resources efficiënt worden toegewezen en tegelijkertijd optimale prestaties worden gehandhaafd tijdens piekuren.
- Automatisch schalen: De laatste optie is automatisch schalen, dat het schalingsproces automatiseert op basis van metrics of events. Door automatisch schalen in uw omgeving op te nemen, kunt u het meeste uit de Azure omgeving halen door efficiënt hoge piekmomenten te bedienen en tegelijkertijd een kosteneffectieve opstelling te behouden. Deze dynamische methode past resources in realtime aan om aan de eisen van uw applicatie te voldoen, en maximaliseert zowel prestaties als kostenefficiëntie.
Bij het configureren van Azure App Service is het essentieel om de juiste schaalinstelling te kiezen op basis van specifieke behoeften en gebruikspatronen.
USE RED
Als je automatisch schalen op basis van metrics en events wilt implementeren, is het belangrijk om te beginnen met de juiste basis. Ten eerste, concentreer op het verticaal schalen door de juiste instantiegrootte te selecteren. De reden hiervoor is dat het wijzigen van de size van een app-instance een herstart vereist, wat de beschikbaarheid kan beïnvloeden. Om de juiste size te bepalen kun je de volgende stappen volgen:
Load Testing: Begin met het testen van de applicatie onder verschillende belastingen om de prestaties en resourcebehoeften te begrijpen. Hierdoor krijg je waardevolle informatie over hoe de app zich gedraagt onder verschillende omstandigheden en kan je onderdelen identificeren die geoptimaliseerd moeten worden.
Optimalisatie: Analyseer de resultaten van de load testing en voer indien nodig optimalisaties uit om de prestaties en efficiëntie van de applicatie te verbeteren. Denk bijvoorbeeld aan het verfijnen van de code, het optimaliseren van databasequery’s of het benutten van caching-technieken.
Selecteer een geschikte grootte: Kies op basis van de testen en optimalisatie-aanpassingen een geschikte instantiegrootte voor de app. Je kan bijvoorbeeld kiezen voor een P1V3-instantie. Onthoud dat het over het algemeen raadzaam is om te kiezen voor de kleinst mogelijke sizing, omdat dit meer controle biedt bij het schalen en grotere kostenbesparingen kan opleveren in vergelijking met het altijd vertrouwen op grotere VM’s.
Door deze stappen te volgen, wordt er een solide basis gelegd voor het automatisch schalen op basis van metrics en events.
Om automatische schaling regels effectief te implementeren binnen Azure, is het belangrijk om een applicatie te monitoren met de juiste aanpak. Twee populaire monitoringmethodologieën kunnen helpen bij het opzetten van schaalregels voor het op- en afschalen, waarbij het laatste cruciaal is voor het verminderen van kosten. De eerste methodologie is USE, wat staat voor Utilization (benutting), Saturation (verzadiging) en Errors (fouten).
Utilization (U): het deel van de resource dat wordt gebruikt, dus 100% benutting betekent dat er geen werk meer kan worden geaccepteerd;
Saturation (S): de mate waarin een hardware resource extra werk heeft dat het niet kan verwerken, waardoor een wachtrij ontstaat voor deze resource;
Errors (E): het aantal foutevents;
Hoewel de USE-methodologie een waardevol startpunt biedt voor automatische schaalregels door middel van resource-monitoring, is het misschien niet de meest effectieve aanpak voor het optimaliseren van kosten en gebruikerservaring. Door te concentreren op gebruikersgerichte metrics, kunnen efficiëntere regels ingesteld worden die beter aansluiten bij de werkelijke behoeften van gebruikers.
Hoewel infrastructuurmetrics belangrijk zijn om problemen zoals “out-of-memory” fouten te detecteren , sluit een gebruikersgerichte benadering beter aan bij het uiteindelijke doel van het bieden van een optimale gebruikerservaring. Een gewaagde uitspraak om dit perspectief te benadrukken is: “Ik vind het niet erg om 100% CPU- of geheugengebruik te hebben, zolang gebruikers er niet door worden beïnvloed; ik gebruik alles waarvoor ik heb betaald!”
Door gebruikerservaringsmetrics te prioriteren, kan je betere beslissingen nemen over wanneer op- of af te schalen, zodat resources efficiënt worden toegewezen en tegelijkertijd een hoogwaardige ervaring voor de gebruikers wordt gegarandeerd. Een goede manier om dit soort metrics toe te passen, is door de RED-methodologie te gebruiken die voortkomt uit Google’s SRE-aanpak. RED is afgeleid van de Four Golden Signals, wat ook een goede manier is om elk op metrics gebaseerd systeem op te bouwen.
Snelheid (R): Het aantal verzoeken per seconde.
Fouten (E): Het aantal mislukte verzoeken.
Duur (D): De tijd die nodig is om een verzoek te verwerken.
In mijn optiek is duur een zeer effectieve metric kan zijn voor schaalbeslissingen, voornamelijk omdat het nauw verbonden is met de gebruikerservaring. Uitsluitend vertrouwen op foutgebaseerde metrics, zoals HTTP 503, kan reactief zijn in plaats van proactief, omdat het te laat kan zijn om het probleem met schalen op te lossen tegen de tijd dat de fout optreedt. Op dezelfde manier kan het gebruik van snelheidsgebaseerde metrics uitgebreide prestatietests vereisen om het exacte punt te bepalen waarop de gebruikerservaring verslechtert.
Duur, aan de andere kant, is een intuïtievere en proactievere metric die u in staat stelt om een consistent performance voor elke gebruiker te handhaven. Door u te concentreren op responstijden, kunt u ervoor zorgen dat extra capaciteit precies wordt gebruikt wanneer dat nodig is. Bovendien is duur een metric die gemakkelijk te begrijpen is voor zowel technische als niet-technische teamleden, waardoor het eenvoudiger wordt om te communiceren en verwachtingen vast te stellen. Door vragen te stellen als “Hoe lang zou een gebruiker moeten wachten op een reactie?”, kunt u duidelijke doelen stellen en beter geïnformeerde beslissingen nemen over wanneer op- of af te schalen, wat uiteindelijk leidt tot een betere gebruikerservaring.
Hoe meer zielen, hoe meer vreugd
Voor een robuuste en proactieve schaalimplementatie is het belangrijk om responstijd te combineren met andere relevante metrics en inzichten uit loadtesten. Deze benadering stelt ontwikkelteams in staat om prestatiepieken of -degradatie nauwkeuriger te voorspellen, waardoor effectievere schaalbeslissingen mogelijk zijn.
Aangezien het opstarten van nieuwe instanties tijd kost (van enkele seconden tot minuten), is het kunnen voorspellen van aankomende werklastpieken essentieel om optimale prestaties te behouden. Evenzo is het belangrijk om rekening te houden met het afschalen op basis van meerdere metrics om mogelijke prestatievermindering te voorkomen. Terwijl een korte periode van lage responstijd bijvoorbeeld kan suggereren dat bronnen kunnen worden verkleind, kan het totale aantal verzoeken per minuut aangeven dat prestatieproblemen waarschijnlijk zijn als het verkeer toeneemt. In dergelijke gevallen kan het verstandig zijn om extra instanties langer te behouden om mogelijke verkeerspieken op te vangen.
Door een uitgebreide benadering te hanteren die rekening houdt met meerdere metrics en inzichten uit prestatietests, kunt u een effectievere schaalimplementatie creëren die optimale prestaties en gebruikerservaring garandeert en tegelijkertijd kosteneffectief blijft.
Conclusie
Azure App Service is uitgegroeid tot een krachtig platform dat organisaties in staat stelt om hun applicaties efficiënt naar de cloud over te brengen, terwijl het schaalbaarheid, kosteneffectiviteit en prestatie optimalisatie biedt. Om optimaal gebruik te maken van de automatische schalingsmogelijkheden, is het cruciaal om de verschillende schalingsopties en configuraties te begrijpen, evenals de metrics en strategieën.
Door te concentreren op zowel infrastructuur- als gebruikersgerichte metrics, kunnen ontwikkelteams robuustere en proactieve schaalimplementaties creëren die inspelen op de werkelijke behoeften van gebruikers en tegelijkertijd optimale prestaties behouden.
Het implementeren van automatische schaling met Azure App Service vereist een solide basis van horizontale schaling en de juiste instantiegrootte, evenals een goed doordachte schalingsregels die is afgestemd op de behoeften en gebruikerspatronen van de organisatie. Door zorgvuldig de balans te vinden tussen prestaties, kosten en betrouwbaarheid in de cloudomgeving, kunnen organisaties ervoor zorgen dat ze de voordelen van Azure App Service kunnen maximaliseren.
BIO: Mijn naam is Twan Koot, 30 jaar oud, en ik ben werkzaam als Principal Expert op het gebied van Microsoft Azure bij Ordina. Ik ben gespecialiseerd in het optimaliseren van applicatie performance in de cloud en het terugdringen van kosten. Naast mijn rol als Principal Expert, vervul ik ook de functie van Codesmith bij Ordina. Dit houdt in dat ik regelmatig optreed als internationaal spreker op diverse podia om mijn kennis en ervaringen te delen.