Wachtrijgebaseerd nivelleringspatroon

Gebruik een wachtrij die fungeert als buffer tussen een taak en de service die wordt aangeroepen. Deze aanpak zorgt ervoor dat onregelmatige zware belastingen worden vereffend waardoor de service kan mislukken of dat er een time-out optreedt voor de taak. Het helpt het effect van pieken in de vraag op beschikbaarheid en reactiesnelheid van de taak en de service te minimaliseren.

Context en probleem

Veel oplossingen in de cloud voeren taken uit die services aanroepen. In deze omgeving kunnen onregelmatige zware belastingen prestatie- of betrouwbaarheidsproblemen voor een service veroorzaken.

Een service maakt mogelijk deel uit van dezelfde oplossing als de taken die deze gebruiken, of een partnerservice die toegang biedt tot veelgebruikte resources. Voorbeelden van deze typen services zijn een cache of een opslagservice. Wanneer meerdere taken gelijktijdig worden uitgevoerd en dezelfde service gebruiken, is het moeilijk om op elk gewenst moment het volume van aanvragen te voorspellen.

Een service kan pieken in de vraag ondervinden die deze overbelasten en ervoor zorgen dat de service niet snel kan reageren op aanvragen. Het overspoelen van een service met veel gelijktijdige aanvragen kan er ook toe leiden dat de service mislukt als deze niet kan omgaan met conflicten die deze aanvragen veroorzaken.

Oplossing

Plaats een wachtrij tussen de taak en de service. De taak en de service worden asynchroon uitgevoerd. De taak plaatst een bericht met de gegevens die de service nodig heeft voor de wachtrij. De wachtrij fungeert als buffer en slaat het bericht op totdat de service het ophaalt. De service haalt berichten op uit de wachtrij en verwerkt deze. Aanvragen van meerdere taken, die kunnen worden gegenereerd met een hoge variabele snelheid, kunnen via dezelfde berichtenwachtrij aan de service worden doorgegeven. In het volgende diagram ziet u hoe een wachtrij de belasting van een service kan verdelen.

In het diagram ziet u hoe een berichtenwachtrij taakaanvragen met variabele snelheid loskoppelt van een service die ze met een consistente snelheid verwerkt. De stroom wordt van links naar rechts verplaatst. Aan de linkerkant wijzen aparte pijlen van drie taakiconen naar een centrale berichtenwachtrij om te laten zien hoe taken onafhankelijk verzoeken indienen in dezelfde wachtrij. Een enkele pijl wijst van de berichtenwachtrij naar een serviceknooppunt uiterst rechts, wat aangeeft hoe de service berichten met een consistente snelheid verwerkt.

De wachtrij ontkoppelt de taken van de service, zodat de service de berichten in zijn eigen tempo kan verwerken, zelfs wanneer gelijktijdige taken een groot aantal aanvragen genereren. Taken worden ook niet vertraagd als de service niet beschikbaar is wanneer ze berichten in de wachtrij plaatsen.

Dit patroon biedt de volgende voordelen:

• Het helpt de beschikbaarheid te maximaliseren omdat servicevertragingen niet onmiddellijk en rechtstreeks van invloed zijn op de toepassing. De toepassing kan berichten blijven posten in de wachtrij, zelfs wanneer de service niet beschikbaar is of momenteel geen berichten verwerkt.

• Het helpt de schaalbaarheid te maximaliseren omdat het aantal wachtrijen en het aantal services kan variëren om te voldoen aan de vraag.

• Dit helpt de kosten te beheren omdat u slechts voldoende service-exemplaren nodig hebt om te voldoen aan de vereisten voor een gemiddelde belasting in plaats van de piekbelasting.

Note

Sommige diensten passen snelheidsbeperking toe wanneer de vraag een drempel bereikt die tot systeemuitval kan leiden. Throttling kan de beschikbare functionaliteit beperken. Implementeer belastingverdeling in deze services, zodat de vraag deze drempelwaarde niet bereikt.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

• Implementeer toepassingslogica waarmee de snelheid wordt beheerd waarmee services berichten verwerken om te voorkomen dat de doelresource wordt overweldigd. Vermijd dat pieken in de aanvraag worden doorgestuurd naar de volgende fase van het systeem. Test het systeem onder belasting om ervoor te zorgen dat het de vereiste nivellering oplevert. Om de vereiste verdeling te bereiken, past u het aantal wachtrijen en het aantal service-instanties aan die berichten verwerken.

• Berichtenwachtrijen zijn een eenrichtingscommunicatiemechanisme. Als een taak een antwoord van een service verwacht, moet u mogelijk een mechanisme implementeren dat de service kan gebruiken om een antwoord te verzenden. Zie Asynchrone berichtopties in Azure voor meer informatie.

• Automatisch schalen zonder de cumulatieve downstreamsnelheid van consumenten te beperken, verplaatst alleen de overbelasting naar downstreamafhankelijkheden. Deze overbelasting kan de strijd om gedeelde systeembronnen tussen deze services vergroten en de effectiviteit van de wachtrij om de belasting af te vlakken verminderen.

• Als uw gemiddelde producentpercentage de consumentensnelheid overschrijdt, blijft de wachtrij toenemen en neemt de latentie toe. Bewaak de wachtrijdiepte en schaal afnemers binnen veilige grenzen, of verminder de werklast aan de producentzijde.

• Dit patroon is afhankelijk van de duurzaamheid van de wachtrij om berichtverlies te voorkomen. Als de broker geen berichten op duurzame opslag bewaart, kan een crash- of capaciteitslimiet ertoe leiden dat gegevens verloren gaan voordat consumenten deze verwerken. Kies een wachtrijservice waarmee berichten naar schijf of gerepliceerde opslag worden bewaard en begrijp de groottequota en retentielimieten. Voor workloads waarbij berichten regionale uitval moeten kunnen overleven, evalueer opties voor geografisch noodherstel.

• De meeste wachtrijdiensten leveren berichten met at-least-once-semantiek, wat betekent dat afnemers hetzelfde bericht meer dan één keer kunnen ontvangen. Ontwerp consumentenlogica om idempotent te zijn, zodat het verwerken van hetzelfde bericht meerdere keren hetzelfde resultaat oplevert en problemen zoals dubbele records of herhaalde kosten voorkomt.

• Sommige berichten kunnen niet worden verwerkt omdat ze ongeldige gegevens bevatten, verwijzen naar ontbrekende resources of permanente fouten activeren. In plaats van deze berichten eindeloos te laten rondgaan en de wachtrij te laten blokkeren, stuurt u ze naar een wachtrij voor onbestelbare berichten. Bewaak de wachtrijdiepte van dead-letter zodat uw operations-team fouten kan onderzoeken, het onderliggende probleem kan oplossen en berichten indien van toepassing opnieuw kan indienen.

• Als u een wachtrij introduceert tussen een producent en consument, blijft de oorspronkelijke inzendingsorder niet onder alle omstandigheden behouden, met name wanneer meerdere consumenten berichten parallel verwerken. Als voor uw workload strikte volgorde is vereist, gebruikt u functies zoals berichtsessies in Azure Service Bus. Als strikte volgorde niet vereist is, ontwerpt u consumenten om berichten in een willekeurige volgorde te verwerken, wat het schalen vereenvoudigt.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

• Uw workload ondervindt onregelmatige pieken die downstreamservices kunnen overbelasten.

• U moet de aanvraaginname loskoppelen van de verwerkingsdoorvoer om de tolerantie en kostenbeheersing te verbeteren.

Dit patroon is mogelijk niet geschikt wanneer:

• Voor de aanroeper is een synchrone reactie met lage latentie vereist.

• Het workloadvolume is voorspelbaar laag en stabiel, dus het toevoegen van wachtrijcomplexiteit biedt weinig voordeel.

Ontwerp van werkbelasting

Beoordeel hoe u het patroon Queue-Based Load Leveling kunt gebruiken bij het ontwerpen van een workload om aan te sluiten bij de doelstellingen en principes die aan bod komen in de Azure Well-Architected Framework-pijlers. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pijler	Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden.	De aanpak die in dit patroon wordt beschreven, kan tolerantie bieden tegen plotselinge pieken in de vraag door de ontvangst van taken te ontkoppelen van hun verwerking. Het kan ook storingen in wachtrijverwerking isoleren, zodat ze geen invloed hebben op de opname. - RE:06 Opschalen
Kostenoptimalisatie is gericht op het ondersteunen en verbeteren van het rendement van uw workload op investeringen.	Omdat de verwerking van de belasting is losgekoppeld van het binnenkomen van aanvragen of taken, kunt u deze aanpak gebruiken om de noodzaak te verminderen om meer middelen dan nodig te provisioneren voor het verwerken van piekbelasting. - CO:12 Schaalvoordelen
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code.	Deze aanpak maakt opzettelijk ontwerp mogelijk voor doorvoerprestaties, omdat de aanvraaginname niet hoeft te correleren met de verwerkingssnelheid. - PE:05 Schaalverdeling en partitioneren

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Example

Een web-app schrijft gegevens naar een extern gegevensarchief. Als meerdere exemplaren van de web-app gelijktijdig worden uitgevoerd, kan de gegevensopslag mogelijk niet snel genoeg op verzoeken reageren, waardoor verzoeken een time-out kunnen krijgen, kunnen worden beperkt of anderszins kunnen mislukken. In het volgende diagram ziet u een gegevensarchief dat wordt overweldigd door gelijktijdige aanvragen van exemplaren van een toepassing.

In het diagram wijzen pijlen van verschillende verticaal gestapelde pictogrammen van Azure App Service-exemplaren naar één pictogram voor gegevensopslag. Sommige van de App Service-exemplaren maken succesvol verbinding met de gegevensopslag. Twee van de instanties tonen een symbool voor een geblokkeerde verbinding met het label 'timeout', wat aangeeft dat de verbindingspoging is mislukt.

U kunt dit probleem oplossen door een wachtrij te gebruiken om de belasting te verdelen over de toepassingsinstanties en de dataopslag. Een Azure Functions-app leest berichten uit een Service Bus wachtrij en voert de lees-/schrijfaanvragen uit naar het gegevensarchief. Azure Functions kan instanties schalen op basis van de Service Bus-wachtrijachterstand met behulp van doelgerichte schaalaanpassing, binnen uw geconfigureerde schaalgrenzen. U kunt ook gelijktijdigheidsinstellingen voor triggers afstemmen om het gegevensarchief te beveiligen. Zie Doelgerichte schaling en Uitschalen beperken voor richtlijnen voor de implementatie. Zonder deze afstemming kan de workerlaag opnieuw back-endcontentie veroorzaken.

In het diagram wijzen pijlen van verschillende verticaal gestapelde App Service-exemplaarpictogrammen naar een Service Bus berichtenwachtrij. Een andere pijl wijst vanuit de berichtenwachtrij, via een functie-app en naar het gegevensarchief.

Als technologievariatie kunt u hetzelfde patroon implementeren met behulp van Azure Container Apps in plaats van Azure Functions. In die benadering verbruikt een gecontaineriseerde werkrol berichten van Service Bus en schrijft deze naar het gegevensarchief. Container Apps schaalt de worker op of af tussen het geconfigureerde minimum- en maximumaantal replica's op basis van wachtrijgerelateerde schaalregels. U kunt dezelfde methode ook implementeren met behulp van Azure Queue Storage als de gebeurtenisbron. Zie Regels voor schalen instellen in Container Apps en Een gebeurtenisgestuurde taak implementeren met behulp van Container Apps voor implementatierichtlijnen.

Volgende stappen 

De volgende richtlijnen zijn mogelijk ook relevant bij de implementatie van dit patroon:

• Asynchrone berichtopties in Azure: Berichtenwachtrijen zijn inherent asynchroon. Mogelijk moet u de toepassingslogica van een taak opnieuw ontwerpen als deze rechtstreeks met een service communiceert. Op dezelfde manier moet u mogelijk een service herstructureren om aanvragen uit een berichtenwachtrij te accepteren.

• Keuze tussen Azure berichtenservices: Meer informatie om u te helpen bij het kiezen van een berichten- en wachtrijmechanisme in Azure toepassingen.

• Aanbevelingen voor het ontwikkelen van achtergrondtaken: pas dit patroon toe op achtergrondtaken, zodat berichtenwachtrijen aanvragen voor achtergrondtaken kunnen opslaan wanneer de toepassing een hoge belasting ondervindt.

• Web-Queue-Worker architectuurstijl: het web en de werkrol zijn beide staatloos. Sessiestatus kan worden opgeslagen in een gedistribueerde cache. De worker voert langdurige taken asynchroon uit en kan worden geactiveerd door berichten in de wachtrij of volgens een schema worden uitgevoerd voor batchverwerking.

Gerelateerde bronnen

• Competing Consumers-patroon: Het is mogelijk om meerdere exemplaren van een service uit te voeren, waarbij elk exemplaar fungeert als berichtconsument van de load-leveling-wachtrij. U kunt deze benadering gebruiken om de snelheid aan te passen waarmee berichten worden ontvangen van en doorgestuurd naar een service.

• Beperkingspatroon: Een eenvoudige manier om beperking in een service te implementeren, is het gebruik van load leveling op basis van wachtrijen en het routeren van alle aanvragen naar een service via een berichtenwachtrij. De service kan aanvragen verwerken met een snelheid die ervoor zorgt dat deze de benodigde resources niet verbruikt en de hoeveelheid mogelijke conflicten vermindert.