Patroon voor load leveling op basis van wachtrij

Functions
Service Bus

Gebruik een wachtrij die fungeert als buffer tussen een taak en een service die wordt aangeroepen om onregelmatige zware belasting te vlakken waardoor de service kan mislukken of dat er een time-out optreedt voor de taak. Dit kan helpen om de impact van pieken in de vraag op beschikbaarheid en reactiesnelheid voor zowel de taak als de service te minimaliseren.

Context en probleem

Veel oplossingen in de cloud hebben betrekking op actieve taken die services aanroepen. Als in deze omgeving een service te maken heeft met onregelmatige zware belastingen, kan dit leiden tot problemen met de prestaties of betrouwbaarheid.

Een service kan deel uitmaken van dezelfde oplossing als de taken die de service gebruiken of kan een service van derden zijn die toegang biedt tot veelgebruikte resources, zoals een cache of een opslagservice. Als dezelfde service wordt gebruikt door een aantal taken die gelijktijdig worden uitgevoerd, kan het lastig zijn om op elk moment het volume van de aanvragen van de service te voorspellen.

Een service kan pieken in de vraag ondervinden die ertoe leiden dat de service wordt overbelast en niet op tijd kan reageren op aanvragen. Als een service wordt overspoeld door een groot aantal gelijktijdige aanvragen, kan dit er ook toe leiden dat de service tekortschiet als deze de conflicten die deze aanvragen veroorzaken, niet kan afhandelen.

Oplossing

Herstructureer de oplossing en 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 vereist in een wachtrij. De wachtrij fungeert als buffer en slaat het bericht op totdat dit wordt opgehaald door de service. De service haalt de berichten uit de wachtrij op en verwerkt deze. Aanvragen van een aantal taken, die met een zeer variabele snelheid kunnen worden gegenereerd, kunnen via dezelfde berichtenwachtrij worden doorgegeven aan de service. In deze afbeelding ziet u hoe een wachtrij wordt gebruikt om de belasting van een service te spreiden.

Figure 1 - Using a queue to level the load on a service

De wachtrij koppelt de taken los van de service en de service kan de berichten in zijn eigen tempo afhandelen, ongeacht het volume van de aanvragen van gelijktijdige taken. Daarnaast treedt er geen vertraging in een taak op als de service niet beschikbaar is op het moment dat een bericht in de wachtrij wordt geplaatst.

Dit patroon biedt de volgende voordelen:

  • Het kan helpen zorgen voor een maximale beschikbaarheid omdat vertragingen in services geen onmiddellijke en directe invloed hebben op de toepassing, die berichten in de wachtrij kan blijven plaatsen, zelfs als de service niet beschikbaar is of momenteel geen berichten verwerkt.

  • Het kan helpen zorgen voor een maximale schaalbaarheid omdat zowel het aantal wachtrijen als het aantal services kan worden gevarieerd om aan vraag te voldoen.

  • Het kan helpen de kosten te beperken omdat het aantal ge├»mplementeerde service-exemplaren alleen toereikend hoeft te zijn voor de gemiddelde belasting in plaats van voor de piekbelasting.

    Sommige services implementeren aanvraagbeperking als de vraag een drempel bereikt waarboven het systeem tekort kan schieten. Deze beperking kan de beschikbare functionaliteit verminderen. U kunt load leveling implementeren met deze services om ervoor te zorgen dat deze drempelwaarde niet wordt bereikt.

Problemen en overwegingen

Beschouw de volgende punten als u besluit hoe u dit patroon wilt implementeren:

  • U moet een toepassingslogica implementeren die de snelheid bepaalt waarop services berichten afhandelen om te voorkomen dat de doelresource wordt overspoeld. Vermijd dat pieken in de aanvraag worden doorgestuurd naar de volgende fase van het systeem. Test het systeem met belasting om er zeker van te zijn dat het de vereiste herverdeling biedt en pas het aantal wachtrijen en het aantal service-exemplaren dat berichten afhandelt aan om dit te bereiken.
  • Berichtenwachtrijen zijn een eenrichtingscommunicatiemechanisme. Als een taak een antwoord van een service verwacht, is het wellicht noodzakelijk een mechanisme te implementeren dat de service kan gebruiken kunt om een antwoord te verzenden. Zie Asynchronous Messaging Primer (Inleiding in asynchrone berichtverzending) voor meer informatie.
  • Wees voorzichtig als u automatisch schalen toepast op services die luisteren naar aanvragen in de wachtrij. Dit kan leiden tot meer conflicten voor alle resources die deze services delen en de effectiviteit van het gebruik van de wachtrij om de belasting te spreiden verminderen.

Wanneer dit patroon gebruiken

Dit patroon is bruikbaar voor elke toepassing die gebruikmaakt van services die vatbaar zijn voor overbelasting.

Dit patroon is niet bruikbaar als de toepassing een reactie van de service verwacht met een minimale latentie.

Voorbeeld

Een web-app schrijft gegevens naar een extern gegevensarchief. Als een groot aantal exemplaren van de web-app gelijktijdig wordt uitgevoerd, kan het gegevensarchief mogelijk niet snel genoeg reageren op aanvragen, waardoor er een time-out optreedt voor aanvragen, wordt beperkt of anderszins mislukt. In het volgende diagram ziet u dat een gegevensarchief wordt overweldigd door een groot aantal gelijktijdige aanvragen van exemplaren van een toepassing.

Figure 2 - A service being overwhelmed by a large number of concurrent requests from instances of a web app

U kunt dit oplossen door een wachtrij te gebruiken om de belasting tussen de toepassingsexemplaren en het gegevensarchief te ewerken. Een Azure Functions-app leest de berichten uit de wachtrij en voert de lees-/schrijfaanvragen uit naar het gegevensarchief. De toepassingslogica in de functie-app kan de snelheid bepalen waarmee aanvragen worden doorgegeven aan het gegevensarchief, om te voorkomen dat de store wordt overspoeld. (Anders introduceert de functie-app hetzelfde probleem opnieuw aan de back-end.)

Figure 3 - Using a queue and a function app to level the load

Volgende stappen

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

  • Asynchronous Messaging Primer (Inleiding in asynchrone berichtpatronen). Berichtenwachtrijen zijn inherent asynchroon. De toepassingslogica in een taak moet mogelijk opnieuw worden ontworpen als deze wordt aangepast van directe communicatie met een service naar het gebruik van een berichtenwachtrij. Het kan ook nodig zijn een service zo te herstructureren dat deze aanvragen van een berichtenwachtrij accepteert. In plaats daarvan kan mogelijk ook een proxyservice worden ge├»mplementeerd, zoals in het voorbeeld wordt beschreven.

  • Kies tussen Azure Messaging-services. Informatie over het kiezen van een mechanisme voor berichtverzending en wachtrijgebruik n Azure-toepassingen.

  • De schaalbaarheid in een Azure-webtoepassing verbeteren. Deze referentiearchitectuur omvat load leveling op basis van wachtrijen als onderdeel van de architectuur.

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

  • Patroon concurrerende consumenten. Het is wellicht mogelijk meerdere exemplaren van een service uit te voeren, die elk fungeren als een berichtgebruiker uit de wachtrij voor load leveling. U kunt deze benadering gebruiken om de snelheid aan te passen waarmee berichten worden ontvangen van en doorgestuurd naar een service.

  • Patroon voor beperking. Een eenvoudige manier om aanvraagbeperking te implementeren met een service, is op wachtrij gebaseerde load leveling te gebruiken en alle aanvragen naar een service om te leiden via een berichtenwachtrij. De service kan aanvragen verwerken met een snelheid die ervoor zorgt dat de resources die de service vereist, niet worden uitgeput en die het aantal mogelijke conflicten verlaagt.