Het verbruik beheren van resources die worden gebruikt door een exemplaar van een toepassing, een afzonderlijke tenant of een hele service. Hierdoor kan het systeem blijven functioneren en aan de service level agreements voldoen, ook als een toename in de vraag een extreme belasting voor de resources betekent.
Context en probleem
De belasting van een cloudtoepassing varieert doorgaans in de loop van de tijd op basis van het aantal actieve gebruikers of de typen activiteiten die ze uitvoeren. Zo zijn er tijdens kantooruren meer gebruikers actief of het systeem voert aan het eind van de maand analyses uit die qua rekenkracht kostbaar zijn. Ook kunnen zich onverwachte en onvoorspelbare pieken in de activiteit voordoen. Als de verwerkingsvereisten van het systeem de capaciteit van de beschikbare resources te boven gaan, zijn de prestaties slecht of er treden fouten op. Als het systeem aan een afgesproken serviceniveau moet voldoen, zijn dergelijke fouten onacceptabel.
Er zijn veel strategieën beschikbaar voor het verwerken van verschillende belasting in de cloud, afhankelijk van de bedrijfsdoelen voor de toepassing. Een strategie is om automatisch schalen te gebruiken om de ingerichte resources op elk gewenst moment aan te passen aan de behoeften van de gebruiker. Hierdoor wordt niet alleen voldaan aan de eisen van de gebruiker, maar worden ook de lopende kosten geoptimaliseerd. Hoewel automatisch schalen het inrichten van meer resources kan activeren, is deze inrichting niet onmiddellijk. Als de vraag snel toeneemt, is er een periode waarin er een tekort aan resources is.
Oplossing
Een alternatieve strategie voor automatisch schalen bestaat eruit toepassingen resources tot een bepaalde grenswaarde te laten gebruiken om ze vervolgens te beperken zodra deze grens wordt bereikt. Het systeem moet bijhouden hoe de resources worden gebruikt, zodat wanneer het gebruik de drempelwaarde overschrijdt, aanvragen van een of meerdere gebruikers kunnen worden beperkt. Hierdoor kan het systeem blijven functioneren en voldoen aan alle service level agreements (SLA's) die aanwezig zijn. Zie Instrumentation and Telemetry Guidance (Richtlijnen voor instrumentatie en telemetrie) voor meer informatie over het bewaken van resourcegebruik.
Het systeem kan een aantal beperkingsstrategieën implementeren, waaronder:
Het weigeren van aanvragen van een afzonderlijke gebruiker die gedurende een bepaalde periode al meer dan n keer per seconde toegang heeft gehad tot systeem-API's. Hiervoor moet het systeem het gebruik meten van resources voor elke tenant of gebruiker die een toepassing uitvoert. Zie Service Metering Guidance (Richtlijnen voor het meten van services) voor meer informatie.
Het uitschakelen of verminderen van de functionaliteit van bepaalde niet-essentiële services die bij voldoende resources ongehinderd kunnen worden uitgevoerd. Bijvoorbeeld als de toepassing video-uitvoer aan het streamen is, kan naar een lagere resolutie worden overgeschakeld.
Door gebruik te maken van load leveling om het volume aan activiteit te laten afnemen (deze benadering wordt uitgebreid beschreven in Patroon Load leveling patroon op basis van een wachtrij). In een omgeving met meerdere tenants vermindert deze benadering de prestaties voor elke tenant. Als het systeem verschillende tenants met verschillende SLA's moet ondersteunen, kan het werk voor tenants met een hogere prioriteit onmiddellijk worden uitgevoerd. Aanvragen voor andere tenants kunnen worden afgehouden en afgehandeld wanneer de achterstand is weggewerkt. Het patroon Prioriteitswachtrij kan worden gebruikt om deze aanpak te implementeren, omdat er verschillende eindpunten voor de verschillende serviceniveaus/prioriteiten kunnen worden weergegeven.
Het uitstellen van bewerkingen die worden uitgevoerd namens toepassingen of tenants van lagere prioriteit. Deze bewerkingen kunnen worden opgeschort of beperkt, waarbij de uitzondering geldt dat de tenant te informeren dat het systeem bezet is en de bewerking later opnieuw moet worden uitgevoerd.
U moet voorzichtig zijn bij het integreren met enkele services van derden die mogelijk niet beschikbaar zijn of fouten retourneren. Verminder het aantal gelijktijdige aanvragen dat wordt verwerkt, zodat de logboeken niet onnodig fouten invullen. U vermijdt ook de kosten die zijn gekoppeld aan onnodig opnieuw proberen de verwerking van aanvragen die mislukken vanwege die service van derden. Wanneer aanvragen vervolgens met succes worden verwerkt, gaat u terug naar normale, niet-beperkte aanvraagverwerking. Een bibliotheek die deze functionaliteit implementeert, is NServiceBus.
In de afbeelding wordt een gebiedsgrafiek getoond voor toepassingen die gebruikmaken van drie functies waarbij resourcegebruik (een combinatie van geheugen, CPU, bandbreedte en andere factoren) tegen de tijd is afgezet. Een functie is een functionaliteitsgebied, zoals een onderdeel dat een bepaalde reeks taken uitvoert, een stuk code dat een complexe berekening uitvoert of een element dat een service levert, zoals een in-memory cache. Deze functies zijn gelabeld met A, B en C.
Het gebied meteen onder de lijn voor een functie geeft de resources aan die door de toepassingen worden gebruikt als ze deze functie aanroepen. Zo toont het gebied onder de lijn voor functie A de resources die worden gebruikt door toepassingen die functie A gebruiken. Het gebied tussen de lijnen voor functie A en functie B geeft de resources aan die worden gebruikt door toepassingen die functie B aanroepen. Het totale resourcegebruik is een combinatie van de gebieden die bij elke functie horen.
In de vorige afbeelding worden de effecten van het uitstellen van bewerkingen geïllustreerd. Vlak voor tijdstip T1 bereikt het totaal aan resources dat is toegewezen aan alle toepassingen die deze functies gebruiken een drempelwaarde (de limiet van het resourcegebruik). Op dat moment bestaat het risico dat de toepassingen de beschikbare resources uitputten. In dit systeem is functie B minder belangrijk dan functie A of functie C, dus wordt B tijdelijk uitgeschakeld en komen de door B gebruikte resources vrij. Tussen tijdstip T1 en tijdstip T2 worden de toepassingen die gebruikmaken van de functies A en C normaal uitgevoerd. Uiteindelijk neemt het resourcegebruik van deze twee functies af tot het moment waarop (T2) er voldoende capaciteit is om functie B opnieuw in te schakelen.
De benaderingen met automatisch schalen en beperken kan ook worden gecombineerd om de toepassingen responsief en te houden en aan de SLA's te laten voldoen. Als de vraag naar verwachting hoog blijft, biedt beperking een tijdelijke oplossing terwijl het systeem wordt uitgeschaald. Op dit moment kan de volledige functionaliteit van het systeem worden hersteld.
In de volgende afbeelding wordt een grafiek getoond van het totale resourcegebruik door alle in een systeem uitgevoerde toepassingen, afgezet tegen de tijd. De grafiek laat zien hoe aanvraagbeperking met automatisch schalen kan worden gecombineerd.
Op tijdstip T1 wordt de drempelwaarde bereikt van de dynamische limiet van resourcegebruik. Op dit moment kan het systeem worden uitgeschaald. Als de nieuwe resources echter niet snel genoeg beschikbaar zijn, zijn de bestaande resources mogelijk uitgeput en kan het systeem mislukken. Om dit te voorkomen, wordt het systeem tijdelijk beperkt, zoals hierboven al beschreven. Wanneer automatisch schalen is voltooid en de extra resources beschikbaar zijn, kan beperking worden versoepeld.
Problemen en overwegingen
U moet de volgende punten overwegen wanneer u besluit hoe u dit patroon wilt implementeren:
Het beperken van een toepassing en de strategie voor het gebruik ervan zijn architectuurmatige beslissingen die het hele ontwerp van een systeem beïnvloeden. Beperking moet vroeg in het ontwerpproces van de toepassing worden overwogen omdat het lastig is toe te voegen als een systeem eenmaal is geïmplementeerd.
Beperking dient snel te worden uitgevoerd. Het systeem moet in staat zijn een toename van de activiteit te detecteren en dienovereenkomstig te reageren. Het systeem moet ook in staat zijn snel naar de oorspronkelijke toestand terug te keren als de belasting is afgenomen. Dit vereist dat de juiste prestatiegegevens continu worden vastgelegd en bewaakt.
Als een service een gebruikersaanvraag tijdelijk moet weigeren, moet deze een specifieke foutcode retourneren, zoals 429 ('Te veel aanvragen') en 503 ('Server te bezet') zodat de clienttoepassing kan begrijpen dat de reden voor de weigering om een aanvraag te verwerken wordt veroorzaakt door beperking.
- HTTP 429 geeft aan dat de aanroepende toepassing te veel aanvragen in een tijdvenster heeft verzonden en een vooraf vastgestelde limiet heeft overschreden.
- HTTP 503 geeft aan dat de service niet gereed is om de aanvraag te verwerken. De veelvoorkomende oorzaak is dat de service meer tijdelijke belastingpieken ondervindt dan verwacht.
De clienttoepassing kan dan enige tijd wachten voordat de aanvraag opnieuw wordt gedaan. Er moet een Retry-After HTTP-header worden opgenomen om de client te ondersteunen bij het kiezen van de strategie voor opnieuw proberen.
Beperking kan worden gebruikt als een tijdelijke maatregel als een systeem automatisch wordt geschaald. In sommige gevallen is het beter om simpelweg te beperken, in plaats van te schalen, als een piek in activiteit plotseling is en naar verwachting niet lang duurt, omdat schalen aanzienlijk kan worden toegevoegd aan lopende kosten.
Als beperking wordt gebruikt als een tijdelijke meting terwijl een systeem automatisch wordt geschaald en als de vraag naar resources zeer snel toeneemt, kan het systeem mogelijk niet blijven functioneren, zelfs niet wanneer het in een beperkte modus werkt. Als dit niet acceptabel is, kunt u reserves met grotere capaciteit overwegen en het automatisch schalen uitgebreider toe te passen.
Normaliseer resourcekosten voor verschillende bewerkingen, omdat ze doorgaans geen gelijke uitvoeringskosten hebben. Beperkingslimieten kunnen bijvoorbeeld lager zijn voor leesbewerkingen en hoger voor schrijfbewerkingen. Het niet overwegen van de kosten van een bewerking kan leiden tot uitgeputte capaciteit en het blootstellen van een mogelijke aanvalsvector.
Dynamische configuratiewijziging van beperkingsgedrag tijdens runtime is wenselijk. Als een systeem een abnormale belasting ondervindt die de toegepaste configuratie niet kan verwerken, moeten beperkingslimieten mogelijk worden verhoogd of verlaagd om het systeem te stabiliseren en het huidige verkeer bij te houden. Dure, riskante en trage implementaties zijn op dit moment niet wenselijk. Het gebruik van de beperkingsconfiguratie voor het externe configuratiearchief wordt ge externaliseerd en kan worden gewijzigd en toegepast zonder implementaties.
Wanneer dit patroon gebruiken
U gebruikt dit patroon voor het volgende:
Om ervoor te zorgen dat een systeem blijft voldoen aan de service level agreements.
Om te voorkomen dat één tenant de door een toepassing geboden resources monopoliseert.
Om pieken in de activiteiten te verwerken.
Om de kosten van een systeem te optimaliseren door de maximaal benodigde resourceniveaus te beperken om het systeem gaande te kunnen houden.
Workloadontwerp
Een architect moet evalueren hoe het beperkingspatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over betrouwbaarheidsontwerp helpen uw workload bestand te worden tegen storingen en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een fout is opgetreden. | U ontwerpt de limieten om resourceuitputting te voorkomen die tot storingen kan leiden. U kunt dit patroon ook gebruiken als een controlemechanisme in een respijtvol degradatieplan. - RE:07 Zelfbehoud |
| Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. | U kunt de limieten ontwerpen om resourceuitputting te voorkomen die kan leiden tot geautomatiseerd misbruik van het systeem. - SE:06 Netwerkbesturingselementen - SE:08 Hardening resources |
| Kostenoptimalisatie is gericht op het ondersteunen en verbeteren van het rendement van uw workload op investering. | De afgedwongen limieten kunnen kostenmodellering informeren en kunnen zelfs rechtstreeks worden gekoppeld aan het bedrijfsmodel van uw toepassing. Ze leggen ook duidelijke bovengrenzen op het gebruik, die kunnen worden meegenomen in de grootte van resources. - CO:02 Kostenmodel - CO:12 Schaalkosten |
| Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door optimalisaties in schalen, gegevens, code. | Wanneer het systeem onder hoge vraag staat, helpt dit patroon congestie te beperken die kan leiden tot knelpunten in de prestaties. U kunt het ook gebruiken om proactief lawaaierige buurscenario's te voorkomen. - PE:02 Capaciteitsplanning - PE:05 Schalen en partitioneren |
Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.
Opmerking
In de laatste afbeelding ziet u hoe beperking kan worden geïmplementeerd in een multitenant-systeem. Gebruikers van elke tenantorganisatie hebben toegang tot een cloudtoepassing waar ze enquêtes kunnen invullen en indienen. De toepassing bevat instrumentatie waarmee de snelheid wordt gecontroleerd waarmee deze gebruikers aanvragen bij de toepassing indienen.
Om te voorkomen dat de gebruikers van één tenant de reactiesnelheid en beschikbaarheid van de toepassing voor de andere gebruikers beperken, wordt er een limiet ingesteld op het aantal aanvragen dat de gebruikers van één tenant per seconde kunnen indienen. De toepassing blokkeert aanvragen die deze limiet overschrijden.
Volgende stappen
De volgende richtlijnen kunnen ook relevant zijn bij het implementeren van dit patroon:
- Instrumentation and Telemetry Guidance (Richtlijnen voor instrumentatie en telemetrie). Beperking is afhankelijk van het verzamelen van informatie over de mate waarin een service wordt gebruikt. Hierin wordt beschreven hoe aangepaste bewakingsgegevens kunnen worden gegenereerd en vastgelegd.
- Service Metering Guidance (Richtlijnen voor het meten van services). Beschrijft hoe u het gebruik van services kunt meten om inzicht te krijgen in hoe ze worden gebruikt. Deze informatie kan nuttig zijn bij het bepalen van de manier waarop een service kan worden beperkt.
- Richtlijnen voor automatisch schalen. Beperking kan worden gebruikt als een tussentijdse maatregel terwijl een systeem automatisch wordt geschaald of om de noodzaak van automatisch schalen te vermijden. Het artikel bevat informatie over strategieën voor automatisch schalen.
Verwante resources
De volgende patronen kunnen ook relevant zijn bij het implementeren van dit patroon:
- Patroon Load leveling op basis van wachtrij. Load leveling op basis van wachtrij is een veelgebruikte methode voor het implementering van beperking. Een wachtrij kan fungeren als een buffer zodat aanvragen, die door een toepassing worden verzonden, met gelijkmatige snelheid aan een service kunnen worden doorgegeven.
- Priority Queue Pattern (Patroon Wachtrij met prioriteit). Een systeem kan prioritietswachtrijen gebruiken als onderdeel van de beperkingsstrategie om de prestaties voor kritieke toepassing of toepassingen van hoog niveau te kunnen handhaven, terwijl de prestaties van minder belangrijke toepassingen worden verminderd.
- Patroon extern configuratiearchief. Het centraliseren en externaliseren van het beperkingsbeleid biedt de mogelijkheid om de configuratie tijdens runtime te wijzigen zonder dat er opnieuw hoeft te worden geïmplementeerd. Services kunnen zich abonneren op configuratiewijzigingen, waardoor de nieuwe configuratie onmiddellijk wordt toegepast om een systeem te stabiliseren.