Beperkingspatroon

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 voldoen aan serviceniveaudoelstellingen (SLO's), zelfs wanneer een toename van de vraag een extreme belasting op resources plaatst.

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 overschrijden, ondervindt het slechte prestaties en kan het zelfs mislukken. 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 autoscaling kan leiden tot de inrichting van meer bronnen, is deze uitbreiding 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 serviceniveaudoelstellingen (SLO'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 belastingnivellering om de activiteit gelijkmatiger te verdelen (deze benadering wordt uitgebreid beschreven in het Wachtrij-gebaseerde belastingnivelleringspatroon). 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 Priority Queue pattern kan worden gebruikt om deze aanpak te implementeren, evenals het blootstellen van verschillende eindpunten voor de verschillende serviceniveaus/prioriteiten.

• Het uitstellen van bewerkingen die worden uitgevoerd namens applicaties of tenants met een lagere prioriteit. Deze bewerkingen kunnen worden opgeschort of beperkt, waarbij een uitzondering wordt gegenereerd om de tenant te informeren dat het systeem bezet is en dat de bewerking later opnieuw moet worden uitgevoerd.

• U moet voorzichtig zijn bij het integreren met sommige diensten van derden die mogelijk niet beschikbaar zijn of fouten geven. 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 ziet u de effecten van het uitstellen van bewerkingen. Net voor tijd T1 bereiken de totale resources die zijn toegewezen aan alle toepassingen die gebruikmaken van deze functies een drempelwaarde. Deze drempelwaarde vertegenwoordigt de limiet van 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 begrenzen kunnen ook worden gecombineerd om de toepassingen responsief te houden en aan de SLA's te voldoen. Als de vraag naar verwachting hoog blijft, biedt throttling een tijdelijke oplossing terwijl het systeem wordt opgeschaald. Op dat moment kan de volledige functionaliteit van het systeem worden hersteld.

In de volgende afbeelding wordt een grafiek getoond van het totale resourcegebruik door alle toepassingen die in een systeem draaien, in relatie tot de tijd. De grafiek laat zien hoe drosseling kan worden gecombineerd met automatisch schalen van de capaciteit.

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 teruggeschroefd, zoals hierboven al beschreven. Wanneer autoschaling is voltooid en de extra resources beschikbaar zijn, kan de 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 te gebruiken strategie is een architectuurbeslissing die van invloed is op het gehele ontwerp van een systeem. Throttling moet al vroeg in het ontwerpproces van de toepassing worden overwogen, aangezien het vaak niet eenvoudig is om toe te voegen nadat een systeem eenmaal is geïmplementeerd.

• Drosselen 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.

• Drosseling kan als tijdelijke maatregel worden gebruikt wanneer een systeem automatisch schaalt. In sommige gevallen is het beter om te vertragen in plaats van te schalen als een piek in activiteit plotseling is en waarschijnlijk niet lang zal duren, omdat schalen de operationele kosten aanzienlijk kan verhogen.

• Als er sprake is van beperking als tijdelijke maatregel terwijl een systeem schaalt, en indien de vraag naar resources zeer snel toeneemt, kan het gebeuren dat het systeem niet blijft functioneren, zelfs niet in een beperkte modus. Als dit niet acceptabel is, kunt u overwegen om grotere capaciteitsreserves te handhaven en agressiever automatisch schalen te configureren.

• Normaliseer resourcekosten voor verschillende bewerkingen, omdat ze doorgaans geen gelijke uitvoeringskosten hebben. Limieten voor stremming kunnen bijvoorbeeld lager zijn voor lezen en hoger voor schrijven. Het niet overwegen van de kosten van een bewerking kan leiden tot uitgeputte capaciteit en het blootstellen van een mogelijke aanvalsvector.

• Dynamische configuratiewijziging van knevelgedrag tijdens de looptijd 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 snelheidsbeperkingsconfiguratie voor het Externe Configuratieopslag patroon is uitgeplaatst en kan zonder implementaties worden gewijzigd en toegepast.

Wanneer dit patroon gebruiken

Gebruik dit patroon:

• Om ervoor te zorgen dat een systeem blijft voldoen aan serviceniveaudoelstellingen (SLO's).

• Om te voorkomen dat één tenant de door een toepassing geboden resources monopoliseert.

• Om pieken in activiteit te verwerken.

• Om de kosten van een systeem te optimaliseren door de maximaal benodigde resourceniveaus te beperken om het systeem gaande te kunnen houden.

• Om de rekenverwerking met een lage waarde te verminderen tijdens perioden met een hoog koolstofgehalte in het energienet.

Workloadontwerp

Een architect moet evalueren hoe het Throttling-pattern kan worden gebruikt bij het ontwerpen van hun workload om de doelstellingen en principes af te stemmen op de pijlers van het Azure Well-Architected Framework. Voorbeeld:

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.

Voorbeeld

In de laatste afbeelding ziet u hoe throttling 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 zijn mogelijk ook relevant bij de implementatie van dit patroon:

• Instrumentation and Telemetry Guidance (Richtlijnen voor instrumentatie en telemetrie). Drosseling is afhankelijk van het verzamelen van informatie over hoe intensief 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. Snelheidsbeperking kan worden gebruikt als een tussentijdse maatregel terwijl het systeem automatisch opschaalt, of om de noodzaak voor het systeem om automatisch op te schalen te vermijden. Het artikel bevat informatie over strategieën voor automatisch schalen.

Verwante bronnen

De volgende patronen zijn mogelijk ook relevant bij het implementeren van dit patroon:

• Loadbalancing op basis van wachtrijpatroon Loadnivellering gebaseerd op wachtrij is een veelgebruikte methode voor de implementatie van dosering. Een wachtrij kan fungeren als een buffer zodat aanvragen, die door een toepassing worden verzonden, met gelijkmatige snelheid aan een service kunnen worden doorgegeven.
• Prioriteitswachtrij-patroon 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 configuratieopslag. Het centraliseren en externaliseren van de throttling policies biedt de mogelijkheid om de configuratie tijdens uitvoering te wijzigen zonder herimplementatie. Services kunnen zich abonneren op configuratiewijzigingen, die de nieuwe configuratie onmiddellijk toepassen, om een systeem te stabiliseren.