Achtergrondtaken

  • Artikel

Voor veel soorten toepassingen zijn achtergrondtaken vereist die onafhankelijk van de gebruikersinterface worden uitgevoerd. Voorbeelden zijn batchtaken, intensieve verwerkingstaken en langlopende processen zoals werkstromen. Achtergrondtaken kunnen worden uitgevoerd zonder tussenkomst van de gebruiker: de toepassing kan de taak starten en vervolgens doorgaan met het verwerken van interactieve aanvragen van gebruikers. Dat kan de belasting op de gebruikersinterface van de toepassing helpen verminderen, waardoor de beschikbaarheid wordt verbeterd en de interactieve responstijden korter worden.

Als er bijvoorbeeld een toepassing is vereist voor het genereren van miniaturen van afbeeldingen die door gebruikers zijn geüpload, kunt u dat doen als achtergrondtaak en de miniatuur opslaan in de opslag zonder dat de gebruiker hoeft te wachten totdat het proces is voltooid. Op dezelfde manier kan een gebruiker die een order plaatst een achtergrondwerkstroom initiëren voor het verwerken van de order, terwijl de gebruiker in de gebruikersinterface door de web-app kan blijven bladeren. Wanneer de achtergrondtaak is voltooid, kan de gebruikersinterface de opgeslagen ordergegevens bijwerken en een e-mailbericht naar de gebruiker verzenden om de order te bevestigen.

Wanneer u een taak wilt implementeren als achtergrondtaak, geldt als belangrijkste criterium of de taak kan worden uitgevoerd zonder tussenkomst van de gebruiker en zonder dat de gebruikersinterface moet wachten tot de taak is voltooid. Taken waarvoor de gebruiker of de gebruikersinterface moet wachten tot ze zijn voltooid, zijn mogelijk niet geschikt als achtergrondtaak.

Typen achtergrondtaken

Achtergrondtaken omvatten doorgaans een of meer van de volgende soorten taken:

  • CPU-intensieve taken, zoals wiskundige berekeningen of structurele modelanalyses.
  • I/O-intensieve taken, zoals het uitvoeren van een reeks opslagtransacties of het indexeren van bestanden.
  • Batchtaken, zoals nachtelijke gegevensupdates of geplande verwerking.
  • Langlopende werkstromen, zoals het afhandelen van orders of het inrichten van services en systemen.
  • Verwerking van gevoelige gegevens waarbij de taak ter verwerking wordt doorgegeven aan een veiliger locatie. Het is bijvoorbeeld mogelijk dat u geen gevoelige gegevens binnen een web-app wilt verwerken. In plaats daarvan kunt u een patroon zoals het Gatekeeper-patroon gebruiken om de gegevens over te dragen naar een geïsoleerd achtergrondproces dat toegang heeft tot beveiligde opslag.

Triggers

Achtergrondtaken kunnen op verschillende manieren worden gestart. Ze kunnen worden onderverdeeld in de volgende categorieën:

  • Gebeurtenisgestuurde triggers. De taak wordt gestart als reactie op een gebeurtenis, meestal een actie van een gebruiker of een stap in een werkstroom.
  • Planninggestuurde triggers. De taak wordt aangeroepen via een planning op basis van een timer. Dat kan een herhalende planning zijn of een eenmalige aanroep die is opgegeven voor een later tijdstip.

Gebeurtenisgestuurde triggers

Gebeurtenisgestuurde aanroep maakt gebruik van een trigger om de achtergrondtaak te starten. Voorbeelden van het gebruik van gebeurtenisgestuurde triggers zijn:

  • De gebruikersinterface of een andere taak plaatst een bericht in een wachtrij. Het bericht bevat gegevens over een actie die heeft plaatsgevonden, zoals de gebruiker die een bestelling plaatst. De achtergrondtaak luistert op deze wachtrij en detecteert de binnenkomst van een nieuw bericht. De achtergrondtaak leest het bericht en gebruikt de gegevens daarin als invoer voor de achtergrondtaak. Dit patroon wordt asynchrone communicatie op basis van berichten genoemd.
  • De gebruikersinterface of een andere taak slaat een waarde op in de opslag of werkt een waarde in de opslag bij. De achtergrondtaak controleert de opslag en detecteert wijzigingen. De achtergrondtaak leest de gegevens en gebruikt deze als invoer voor de achtergrondtaak.
  • De gebruikersinterface of een andere taak stuurt een aanvraag naar een eindpunt, zoals een HTTPS-URI, of naar een API die wordt weergegeven als webservice. De gegevens die vereist zijn voor het voltooien van de achtergrondtaak worden als onderdeel van de aanvraag doorgegeven. Het eindpunt of de webservice roept de achtergrondtaak aan, die de gegevens gebruikt als invoer.

Typische voorbeelden van taken die voor gebeurtenisgestuurde aanroepen geschikt zijn, zijn verwerking van installatiekopieën, werkstromen, verzenden van gegevens naar externe services, verzenden van e-mailberichten en inrichten van nieuwe gebruikers in multitenant-toepassingen.

Planninggestuurde triggers

Planninggestuurde aanroep maakt gebruik van een timer om de achtergrondtaak te starten. Voorbeelden van het gebruik van planninggestuurde triggers zijn:

  • Een timer die lokaal wordt uitgevoerd binnen de toepassing of als onderdeel van het besturingssysteem van de toepassing roept regelmatig een achtergrondtaak aan.
  • Een timer die wordt uitgevoerd in een andere toepassing, zoals Azure Logic Apps, verzendt regelmatig een aanvraag naar een API of webservice. De API of webservice roept de achtergrondtaak aan.
  • Een afzonderlijk proces of afzonderlijke toepassing start een timer die ervoor zorgt dat de achtergrondtaak eenmaal wordt aangeroepen na een opgegeven vertraging of op een bepaald tijdstip.

Typische voorbeelden van taken die geschikt zijn voor planninggestuurde aanroepen, zijn batchverwerkingsroutines (zoals het bijwerken van lijsten met gerelateerde producten voor gebruikers op basis van hun recent gedrag), routinetaken voor gegevensverwerking (zoals het bijwerken van indexen of het genereren van cumulatieve resultaten), gegevensanalyse voor dagelijkse rapporten, opschonen van gegevensretentie en controles op gegevensconsistentie.

Als u een planninggestuurde taak gebruikt die als één instantie moet worden uitgevoerd, moet u rekening houden met het volgende:

  • Als het rekenproces dat zorgt voor uitvoering van de planner (zoals een virtuele machine die door Windows geplande taken gebruikt) wordt aangepast, zijn er meerdere instanties van de planner die worden uitgevoerd. Deze zouden meerdere instanties van de taak kunnen starten. Lees dit blogbericht over idempotentie voor meer informatie hierover.
  • Als de uitvoering van taken langer duurt dan de periode tussen plannergebeurtenissen, is het mogelijk dat de planner een andere instantie van de taak start terwijl de vorige taak nog actief is.

Retourneren van resultaten

Achtergrondtaken worden asynchroon in een afzonderlijk proces, of zelfs op een afzonderlijke locatie, uitgevoerd vanuit de gebruikersinterface die of het proces dat de achtergrondtaak heeft aangeroepen. In het ideale instantie zijn achtergrondtaken 'fire and forget'-bewerkingen, en de voortgang van de uitvoering heeft geen invloed op de gebruikersinterface of het aanroepende proces. Dit betekent dat het aanroepende proces niet wacht totdat de taken zijn voltooid. Daarom kan dat proces niet automatisch detecteren wanneer de taak wordt beëindigd.

Als u een achtergrondtaak nodig hebt om te communiceren met de aanroepende taak om voortgang of voltooiing aan te geven, moet u daarvoor een mechanisme implementeren. Enkele voorbeelden:

  • Schrijf een waarde voor de statusindicator naar de opslag die toegankelijk is voor de gebruikersinterface of de aanroepende taak, die deze waarde indien nodig kan controleren. Andere gegevens die de achtergrondtaak naar de aanroepende taak moet terugsturen, kunnen in dezelfde opslag worden geplaatst.
  • Maak een antwoordenwachtrij waarop de gebruikersinterface of aanroepende taak luistert. De achtergrondtaak kan naar de wachtrij berichten verzenden die status en voltooiing aangeven. Gegevens die door de achtergrondtaak naar de aanroepende taak moeten worden teruggestuurd, kunnen in de berichten worden opgenomen. Als u Azure Service Bus gebruikt, kunt u de kenmerken ReplyTo en CorrelationId gebruiken om deze mogelijkheid te implementeren.
  • Geef een API of eindpunt uit de achtergrondtaak weer die de gebruikersinterface of de aanroepende taak kan openen om statusinformatie op te halen. Gegevens die door de achtergrondtaak naar de aanroepende taak moeten worden teruggestuurd, kunnen in de reactie worden opgenomen.
  • Laat de achtergrondtaak de gebruikersinterface of de aanroepende taak via een API aanroepen om de status op vooraf gedefinieerde tijdstippen of na voltooiing aan te geven. Dit kan door middel van gebeurtenissen die lokaal worden gegenereerd of via een mechanisme voor publiceren en abonneren. Gegevens die door de achtergrondtaak naar de aanroepende taak moeten worden teruggestuurd, kunnen in de aanvraag of de nettolading van de gebeurtenis worden opgenomen.

Hostingomgeving

U kunt achtergrondtaken hosten met behulp van een reeks verschillende services op het Azure-platform:

  • Azure Web Apps en WebJobs. Met WebJobs kunt u binnen de context van een web-app aangepaste taken uitvoeren op basis van tal van verschillende soorten scripts of uitvoerbare programma's.
  • Azure Functions. U kunt functies gebruiken voor achtergrondtaken die niet lang worden uitgevoerd. Een andere use-case is als uw workload al wordt gehost in het App Service-plan en wordt onderbenut.
  • Azure-VM's. Als u een Windows-service hebt of Windows Taakplanner wilt gebruiken, is het gebruikelijk om uw achtergrondtaken binnen een specifieke virtuele machine te hosten.
  • Azure Batch. Azure Batch is een platformservice die rekenintensief werk inplant voor uitvoering op een beheerde verzameling virtuele machines. Hiermee kunnen rekenresources automatisch worden geschaald.
  • Azure Kubernetes Service (AKS). Azure Kubernetes Service biedt een beheerde hostingomgeving voor Kubernetes in Azure.
  • Azure Container Apps. Met Azure Container Apps kunt u serverloze microservices bouwen op basis van containers.

In de volgende secties worden deze opties gedetailleerder beschreven en worden overwegingen opgenomen om u te helpen bij het kiezen van de juiste optie.

Azure Web Apps en WebJobs

Met Azure WebJobs kunt u aangepaste taken als achtergrondtaken binnen een Azure-web-app uitvoeren. Webtaken (of WebJobs) worden binnen de context van uw web-app als een doorlopend proces uitgevoerd. WebJobs worden ook uitgevoerd als reactie op een trigger-gebeurtenis van Azure Logic Apps of externe factoren, zoals wijzigingen in opslagblobs en berichtenwachtrijen. Webtaken kunnen op aanvraag worden gestart en gestopt, en zonder problemen worden afgesloten. Als een doorlopend uitgevoerde webtaak mislukt, wordt deze automatisch opnieuw gestart. Foutbewerkingen en bewerkingen voor opnieuw uitvoeren kunnen worden geconfigureerd.

Wanneer u een webtaak configureert, geldt het volgende:

  • Als de webtaak moet reageren op een gebeurtenisgestuurde trigger, moet u deze configureren als Continu uitvoeren. Het script of het programma wordt opgeslagen in de map site/wwwroot/app_data/jobs/continuous.
  • Als de webtaak moet reageren op een planninggestuurde trigger, moet u deze configureren als Gepland uitvoeren. Het script of het programma wordt opgeslagen in de map site/wwwroot/app_data/jobs/triggered.
  • Als u de optie Op aanvraag uitvoeren kiest wanneer u een taak configureert, wordt dezelfde code uitgevoerd als met de optie Gepland uitvoeren wanneer u deze start.

Azure-webtaken worden uitgevoerd binnen de sandbox van de web-app. Dit betekent dat ze toegang hebben tot omgevingsvariabelen en gegevens, zoals verbindingsreeksen, kunnen delen met de web-app. De webtaak heeft toegang tot de unieke id van de computer waarop de taak wordt uitgevoerd. De verbindingsreeks met de naam AzureWebJobsStorage biedt toegang tot Azure Storage-wachtrijen, -blobs en -tabellen voor toepassingsgegevens en toegang tot Service Bus voor berichten en communicatie. De verbindingsreeks met de naam AzureWebJobsDashboard biedt toegang tot de logboekbestanden voor de taakbewerkingen.

Azure-webtaken hebben de volgende kenmerken:

  • Beveiliging: webtaken worden beveiligd door de implementatiereferenties van de web-app.
  • Ondersteunde bestandstypen: u kunt WebJobs definiëren met behulp van opdrachtscripts (.cmd), batchbestanden (.bat), PowerShell-scripts (.ps1), Bash-shellscripts (), PHP-scripts (.sh.php), Python-scripts (.py), JavaScript-code (.js) en uitvoerbare programma's (.exe, .jaren meer).
  • Implementatie: U kunt scripts en uitvoerbare bestanden implementeren met behulp van Azure Portal, met behulp van Visual Studio, met behulp van de Azure WebJobs SDK of door ze rechtstreeks naar de volgende locaties te kopiëren:
    • Voor getriggerde uitvoering: site/wwwroot/app_data/jobs/triggered/{job name}
    • Voor continue uitvoering: site/wwwroot/app_data/jobs/continuous/{job name}
  • Logboekregistratie: Console.Out wordt behandeld (gemarkeerd) als INFO. Console.Error wordt behandeld als ERROR. U kunt met behulp van Azure Portal toegang krijgen tot controlegegevens en diagnostische gegevens. U kunt logboekbestanden rechtstreeks vanaf de site downloaden. Ze worden op de volgende locaties opgeslagen:
    • Voor getriggerde uitvoering: Vfs/data/jobs/triggered/jobName
    • Voor continue uitvoering: Vfs/data/jobs/continuous/jobName
  • Configuratie: u kunt webtaken configureren met behulp van de portal, de REST API en PowerShell. U kunt gebruikmaken van het configuratiebestand settings.job in dezelfde hoofdmap als het taakscript om configuratiegegevens voor een taak te verschaffen. Bijvoorbeeld:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

Overwegingen

  • Webtaken worden standaard samen met de web-app geschaald. U kunt echter taken zodanig configureren dat ze in één instantie worden uitgevoerd door het configuratiekenmerk is_singleton in te stellen op true. Webtaken van één instantie zijn nuttig voor taken die u niet wilt schalen of uitvoeren als meerdere gelijktijdige instanties, zoals opnieuw indexeren, gegevensanalyse en vergelijkbare taken.
  • Als u de impact van taken op de prestaties van de web-app wilt minimaliseren, kunt u een leeg Azure Web App-exemplaar maken in een nieuw App Service-plan om langlopende of resource-intensieve webtaken te hosten.

Azure Functions

Een optie die vergelijkbaar is met WebJobs, is Azure Functions. Deze service is serverloos dat het meest geschikt is voor gebeurtenisgestuurde triggers die gedurende een korte periode worden uitgevoerd. Een functie kan ook worden gebruikt om geplande taken uit te voeren via timertriggers, wanneer deze is geconfigureerd voor uitvoering op ingestelde tijden.

Azure Functions is geen aanbevolen optie voor grote, langlopende taken, omdat ze onverwachte time-outproblemen kunnen veroorzaken. Afhankelijk van het hostingabonnement kunnen ze echter worden overwogen voor schemagestuurde triggers.

Overwegingen

Als de achtergrondtaak naar verwachting wordt uitgevoerd voor een korte duur als reactie op een gebeurtenis, kunt u overwegen om de taak uit te voeren in een verbruiksabonnement. De uitvoeringstijd kan maximaal een maximale tijd worden geconfigureerd. Een functie die wordt uitgevoerd voor langere kosten. Ook CPU-intensieve taken die meer geheugen verbruiken, kunnen duurder zijn. Als u extra triggers gebruikt voor services als onderdeel van uw taak, worden deze afzonderlijk gefactureerd.

Het Premium-abonnement is geschikter als u een groot aantal taken hebt die kort zijn, maar die naar verwachting continu worden uitgevoerd. Dit abonnement is duurder omdat er meer geheugen en CPU nodig zijn. Het voordeel is dat u functies zoals integratie van virtuele netwerken kunt gebruiken.

Het Dedicated-plan is het meest geschikt voor achtergrondtaken als uw workload er al op wordt uitgevoerd. Als u te weinig gebruikte VM's hebt, kunt u deze uitvoeren op dezelfde VIRTUELE machine en rekenkosten delen.

Lees deze artikelen voor meer informatie:

Azure Virtual Machines

Achtergrondtaken kunnen worden geïmplementeerd op een manier die voorkomt dat ze worden geïmplementeerd in Azure Web Apps, of deze opties zijn mogelijk niet handig. Typische voorbeelden zijn Windows-services en hulpprogramma's en uitvoerbare programma's van derden. Een ander voorbeeld zijn programma's die zijn geschreven voor een uitvoeringsomgeving die anders is dan de omgeving waar de toepassing wordt gehost. Dat kan bijvoorbeeld een Unix- of Linux-programma zijn dat u vanuit een Windows- of .NET-toepassing wilt uitvoeren. U kunt kiezen uit een reeks besturingssystemen voor een virtuele Azure-machine en uw service of uitvoerbaar programma op die virtuele machine uitvoeren.

Zie Vergelijking van Azure App Services, Virtual Machines, Service Fabric en Cloud Services om te bepalen wanneer u het beste virtuele machines kunt gebruiken. Zie Grootten voor virtuele Windows-machines in Azure voor informatie over de opties voor virtuele machines in Azure. Ga naar Azure Marketplace voor virtuele machines voor meer informatie over de besturingssystemen en vooraf gedefinieerde installatiekopieën die er voor virtuele machines beschikbaar zijn.

U hebt een aantal opties om de achtergrondtaak te initiëren in een aparte virtuele machine:

  • U kunt de taak op aanvraag rechtstreeks vanuit uw toepassing uitvoeren door een aanvraag te verzenden naar een eindpunt dat toegang biedt tot de taak. Daardoor worden alle gegevens doorgegeven die de taak vereist. Dit eindpunt roept de taak aan.
  • U kunt de taak configureren met een planning door gebruik te maken van een planner of timer die beschikbaar is in het door u gekozen besturingssysteem. Zo kunt u in Windows gebruikmaken van Windows Taakplanner om scripts en taken uit te voeren. Of als u SQL Server op de virtuele machine hebt geïnstalleerd, kunt u de SQL Server Agent gebruiken om scripts en taken uit te voeren.
  • U kunt Azure Logic Apps gebruiken om de taak te starten door een bericht toe te voegen aan een wachtrij waarop de taak luistert of door een aanvraag te verzenden naar een API die door de taak wordt weergegeven.

Zie het gedeelte Triggers hierboven voor meer informatie over hoe u achtergrondtaken kunt initiëren.

Overwegingen

Houd rekening met de volgende punten bij het bepalen of achtergrondtaken in een virtuele Azure-machine moeten worden geïmplementeerd:

  • Het hosten van achtergrondtaken in een afzonderlijke virtuele Azure-machine biedt flexibiliteit en zorgt voor nauwkeurige controle bij het initiëren, de uitvoering, de planning en de toewijzing van resources. De runtimekosten nemen echter wel toe als een virtuele machine alleen voor het uitvoeren van achtergrondtaken moet worden geïmplementeerd.
  • Er is geen functie voor het controleren van de taken in Azure Portal en het is ook niet mogelijk om mislukte taken automatisch opnieuw te starten. U kunt wel de algemene status van de virtuele machine controleren en beheren door de Azure Resource Manager-cmdlets te gebruiken. Er zijn echter geen mogelijkheden om processen en threads in rekenknooppunten te besturen. Gebruik van een virtuele machine betekent normaal gesproken extra moeite om een mechanisme te implementeren waarmee gegevens worden verzameld van instrumentatie in de taak en van het besturingssysteem in de virtuele machine. Een mogelijk geschikte oplossing is gebruik te maken van het System Center Management Pack voor Azure.
  • U kunt overwegen controletests te maken die worden weergegeven via HTTP-eindpunten. De code voor deze tests kan statuscontroles uitvoeren, operationele gegevens en statistieken verzamelen, of foutinformatie verzamelen en deze doorsturen naar een managementtoepassing. Zie het patroon Statuseindpuntbewaking voor meer informatie.

Zie voor meer informatie:

Azure Batch

Overweeg Azure Batch als u grote, parallelle HPC-workloads (High Performance Computing) wilt uitvoeren op tientallen, honderden of duizenden VM's.

De Batch-service richt de virtuele machines in, wijst taken toe aan de virtuele machines, voert die taken uit en bewaakt de voortgang. Batch kan de virtuele machines automatisch uitschalen als reactie op de workload. Batch biedt ook taakplanning. Azure Batch biedt ondersteuning voor Linux- en Windows-VM's.

Overwegingen

Batch is uitstekend geschikt voor intrinsiek parallelle workloads. Batch kan ook parallelle berekeningen met een verkleiningsstap aan het eind uitvoeren of MPI-toepassingen (Message Passing Interface) uitvoeren voor parallelle taken waarvoor berichten tussen knooppunten moeten worden doorgegeven.

Een Azure Batch-taak wordt uitgevoerd in een pool van knooppunten (VM's). Een mogelijke aanpak is een pool alleen toe te wijzen wanneer dat nodig is en deze te verwijderen nadat de taak is voltooid. Daarmee wordt het gebruik geoptimaliseerd omdat knooppunten niet inactief zijn, maar de taak moet wachten tot er knooppunten zijn toegewezen. U kunt een pool ook vooraf maken. Deze aanpak minimaliseert de tijd voordat een taak wordt gestart, maar kan er wel toe leiden dat knooppunten inactief blijven. Zie Levensduur van pool en rekenknooppunt voor meer informatie.

Zie voor meer informatie:

Azure Kubernetes Service

Azure Kubernetes Service (AKS) beheert uw gehoste Kubernetes-omgeving, waardoor u eenvoudig containertoepassingen kunt implementeren en beheren.

Containers komen van pas bij het uitvoeren van achtergrondtaken. Dit zijn enkele voordelen:

  • Containers ondersteunen hosting met hoge dichtheid. Bij het plaatsen van meerdere containers in elke virtuele machine kunt u een achtergrondtaak in een container isoleren.
  • De containerorchestrator handelt de interne taakverdeling af, evenals het configureren van het interne netwerk en andere configuratietaken.
  • Containers kunnen op elk moment worden gestart en gestopt.
  • Met Azure Container Registry kunt u uw containers binnen Azure-grenzen registreren. Het product wordt geleverd met beveiliging, privacy en nabijheidsvoordelen.

Overwegingen

  • Vereist een goed begrip van het gebruik van een containerorchestrator. Afhankelijk van de vaardighedenset van uw DevOps-team, kan dit al dan niet een probleem zijn.

Zie voor meer informatie:

Azure Container Apps

Met Azure Container Apps kunt u serverloze microservices bouwen op basis van containers. Onderscheidende functies van Container Apps zijn onder andere:

  • Geoptimaliseerd voor het uitvoeren van containers voor algemeen gebruik, met name voor toepassingen die veel microservices omvatten die zijn geïmplementeerd in containers.
  • Mogelijk gemaakt door Kubernetes en opensource-technologieën zoals Dapr, KEDA en envoy.
  • Ondersteunt Kubernetes-apps en microservices met functies zoals servicedetectie en het splitsen van verkeer.
  • Maakt gebeurtenisgestuurde toepassingsarchitecturen mogelijk door schaal te ondersteunen op basis van verkeer en het ophalen van gebeurtenisbronnen zoals wachtrijen, waaronder schalen naar nul.
  • Ondersteuning van langlopende processen en kan achtergrondtaken uitvoeren.

Overwegingen

Azure Container Apps biedt geen directe toegang tot de onderliggende Kubernetes-API's. Als u toegang nodig hebt tot de Kubernetes-API's en het besturingsvlak, moet u Azure Kubernetes Service gebruiken. Als u echter Kubernetes-toepassingen wilt bouwen en geen directe toegang nodig hebt tot alle systeemeigen Kubernetes-API's en clusterbeheer, biedt Container Apps een volledig beheerde ervaring op basis van best practices. Om deze redenen geven veel teams de voorkeur aan het bouwen van containermicroservices met Azure Container Apps.

Zie voor meer informatie:

U kunt aan de slag met het bouwen van uw eerste container-app met behulp van de quickstarts.

Partitionering

Als u besluit achtergrondtaken op te nemen in een bestaand rekenproces, moet u overwegen hoe dit van invloed is op de kwaliteitskenmerken van het rekenproces en de achtergrondtaak zelf. Met deze factoren kunt u bepalen of de taken bij het bestaande rekenproces moeten worden geplaatst of dat ze naar een afzonderlijk rekenproces moeten worden gestuurd:

  • Beschikbaarheid: achtergrondtaken hoeven niet altijd dezelfde mate van beschikbaarheid als andere onderdelen van de toepassing te hebben. Dat geldt met name voor de gebruikersinterface en andere onderdelen die rechtstreeks bij de gebruikersinteractie betrokken zijn. Achtergrondtaken zijn mogelijk minder gevoelig voor latentie, herhaalde verbindingsfouten en andere factoren die van invloed zijn op de beschikbaarheid omdat de bewerkingen in een wachtrij kunnen worden geplaatst. Er moet wel onvoldoende capaciteit zijn om de back-up van aanvragen te voorkomen die wachtrijen kunnen blokkeren en van invloed kunnen zijn op de toepassing als geheel.

  • Schaalbaarheid: achtergrondtaken kunnen andere schaalbaarheidsvereisten hebben dan de gebruikersinterface en de interactieve onderdelen van de toepassing. Het schalen van de gebruikersinterface kan nodig zijn om te voldoen aan pieken in de vraag, terwijl openstaande achtergrondtaken mogelijk worden voltooid tijdens minder drukke tijden door minder rekenprocessen.

  • Tolerantie: een fout met een rekenproces dat alleen achtergrondtaken host heeft wellicht geen ernstige gevolgen voor de toepassing als geheel als de aanvragen voor deze taken in een wachtrij kunnen worden geplaatst of worden uitgesteld totdat de taak weer beschikbaar is. Als het rekenproces en/of de taken opnieuw kunnen worden opgestart binnen de juiste interval, heeft dat wellicht geen invloed op gebruikers van de toepassing.

  • Beveiliging: achtergrondtaken kunnen andere beveiligingsvereisten of beperkingen hebben dan de gebruikersinterface of andere onderdelen van de toepassing. U kunt een andere beveiligingsomgeving voor de taken opgeven met behulp van een afzonderlijk rekenproces. U kunt ook patronen zoals Gatekeeper gebruiken om de rekenprocessen op de achtergrond te isoleren van de gebruikersinterface en zo de beveiliging en scheiding van taken te optimaliseren.

  • Prestaties: u kunt het type rekenproces voor achtergrondtaken kiezen op basis van de prestatievereisten van de taken. Dit kan betekenen dat er een minder kostbare rekenoptie wordt gebruikt als de taken niet dezelfde verwerkingscapaciteit als de gebruikersinterface vereisen, of een groter rekenproces als er extra capaciteit en resources nodig zijn.

  • Beheerbaarheid: achtergrondtaken kunnen een andere ritme voor ontwikkeling en implementatie hebben dan de belangrijkste toepassingscode of de gebruikersinterface. Door ze naar een afzonderlijk rekenproces over te zetten kunnen updates en versiebeheer worden vereenvoudigd.

  • Kosten: door rekenprocessen toe te voegen om achtergrondtaken uit te voeren, neme de hostingkosten toe. De juiste verhouding tussen extra capaciteit en die extra kosten moet u zorgvuldig afwegen.

Zie het patroon Leader Election en het patroon Concurrerende consumenten voor meer informatie.

Conflicten

Als er meerdere exemplaren van een achtergrondtaak zijn, is het mogelijk dat die strijden om toegang tot resources en services, zoals databases en opslag. Deze gelijktijdige toegang kan leiden tot conflicten tussen resources, wat weer kan leiden tot conflicten in de beschikbaarheid van de services en tot problemen met de integriteit van gegevens in de opslag. U kunt resourceconflicten oplossen met een pessimistische benadering van vergrendeling. Hiermee voorkomt u dat concurrerende instanties van een taak zich gelijktijdig toegang verschaffen tot een service of gegevens beschadigen.

Een andere benadering om conflicten op te lossen is achtergrondtaken te definiëren als een singleton, zodat er altijd maar één exemplaar wordt uitgevoerd. Dat elimineert echter wel de betrouwbaarheid en prestatievoordelen van een configuratie met meerdere instanties. Dat geldt met name als de gebruikersinterface voldoende werk kan leveren om meer dan één achtergrondtaak aan de gang te houden.

Het is essentieel om ervoor te zorgen dat de achtergrondtaak automatisch opnieuw kan worden opgestart en dat de taak voldoende capaciteit heeft om te kunnen omgaan met pieken in de vraag. U kunt dit doen door een rekenproces met voldoende resources toe te wijzen, door een wachtrijmechanisme te implementeren dat aanvragen kan vasthouden en ze pas uitvoert wanneer de aanvraag afneemt, of door een combinatie van beide technieken.

Coördinatie

De achtergrondtaken zijn mogelijk complex en vereisen mogelijk meerdere afzonderlijke taken om een resultaat te produceren of om aan alle vereisten te voldoen. Het is gebruikelijk om in deze scenario's de taak onder te verdelen in kleinere afzonderlijke stappen of subtaken die door meerdere gebruikers kunnen worden uitgevoerd. Taken met meerdere stappen kunnen efficiënter en flexibeler zijn omdat de afzonderlijke stappen in meerdere taken kunnen worden ingezet. Bovendien kan de volgorde van de stappen eenvoudig worden veranderd en kunnen er stappen worden verwijderd of toegevoegd.

Het coördineren van meerdere taken en stappen kan lastig zijn, maar er zijn drie algemene patronen die u kunt gebruiken bij de implementatie van een oplossing:

  • Een taak in meerdere herbruikbare stappen opdelen. Een toepassing moet een verscheidenheid aan taken van uiteenlopende complexiteit uitvoeren op de informatie die wordt verwerkt. Een eenvoudige, maar niet-flexibele benadering van de implementatie van deze toepassing is deze verwerking uit te voeren als een monolithische module. Maar met deze benadering bestaat de kans dat de mogelijkheden afnemen voor het herstructureren van de code, voor het optimaliseren ervan of de code opnieuw te gebruiken als onderdelen van dezelfde verwerking elders in de toepassing zijn vereist. Zie het patroon Pipes en Filters voor meer informatie.

  • Uitvoering van de stappen voor een taak beheren. Een toepassing kan taken uitvoeren die uit een aantal stappen bestaan (waarvan sommige externe services aanroepen of toegang krijgen tot externe resources). De afzonderlijke stappen kunnen los van elkaar staan, maar ze worden ingedeeld door de toepassingslogica waarmee de taak wordt geïmplementeerd. Zie scheduler Agent Supervisor-patroon voor meer informatie.

  • Het herstel beheren voor taakstappen die mislukken. Een toepassing kan het werk ongedaan maken dat is uitgevoerd door een reeks stappen (die samen een uiteindelijke consistente bewerking definiëren) als een of meer stappen mislukken. Zie het patroon Compenserende transactie voor meer informatie.

Overwegingen voor tolerantie

Achtergrondtaken moeten tolerant zijn om de toepassing betrouwbare services te kunnen bieden. Overweeg de volgende punten bij het plannen en ontwerpen van achtergrondtaken:

  • Achtergrondtaken moeten probleemloos opnieuw opstarten kunnen afhandelen zonder gegevens te beschadigen of inconsistentie in de toepassing te introduceren. Voor langlopende taken of taken met meerdere stappen kunt u controlepunten gebruiken door de status van taken in een permanente opslag of als berichten in een wachtrij op te slaan, al naargelang de meest geschikte methode. U kunt bijvoorbeeld statusinformatie in een bericht in een wachtrij behouden en deze informatie incrementeel bijwerken met de voortgang van de taak zodat de taak kan worden verwerkt vanaf het laatste goede controlepunt in plaats van helemaal opnieuw te beginnen. Wanneer u Azure Service Bus-wachtrijen gebruikt, kunt u berichtsessies gebruiken om hetzelfde scenario in te schakelen. Met sessies kunt u de verwerkingsstatus van de toepassing opslaan en ophalen met behulp van de methoden SetState en GetState. Zie het Scheduler Agent Supervisor-patroon voor meer informatie over het ontwerpen van betrouwbare processen en werkstromen met meerdere taken.

  • Wanneer u wachtrijen gebruikt om te communiceren met achtergrondtaken, kunnen de wachtrijen fungeren als buffer voor het opslaan van aanvragen die naar de taken worden verzonden terwijl de toepassing zwaarder belast is dan normaal. Daardoor kunnen taken de gebruikersinterface bijhouden tijdens minder drukke perioden. Dit betekent ook dat opnieuw opstarten de gebruikersinterface niet blokkeert. Zie het patroon Load Leveling op basis van wachtrijen voor meer informatie. Als sommige taken belangrijker zijn dan andere, kunt u overwegen het patroon Prioriteitswachtrij te implementeren om ervoor te zorgen dat deze taken worden uitgevoerd vóór minder belangrijke taken.

  • Achtergrondtaken die geïnitieerd worden door berichten of verwerkingsberichten moeten ontworpen zijn voor het afhandelen van inconsistenties, zoals berichten die in de verkeerde volgorde binnenkomen, berichten die herhaaldelijk een fout veroorzaken (vaak aangeduid als onverwerkbare berichten) en berichten die meer dan één keer binnenkomen. Overweeg de volgende:

    • Berichten die in een specifieke volgorde moeten worden verwerkt, zoals berichten die gegevens wijzigen op basis van de bestaande gegevenswaarde (bijvoorbeeld door een waarde aan een bestaande waarde toe te voegen), komen mogelijk niet binnen in de oorspronkelijke volgorde waarin ze zijn verzonden. Ze kunnen ook in een andere volgorde door verschillende instanties van een achtergrondtaak worden verwerkt vanwege een wisselende belasting van elk rekenproces. Berichten die in een specifieke volgorde moeten worden verwerkt, hebben een volgnummer, sleutel of andere indicator nodig waarvan achtergrondtaken gebruik kunnen maken om ervoor te zorgen dat ze in de juiste volgorde worden verwerkt. Als u Azure Service Bus gebruikt, kunt u berichtsessies gebruiken om de volgorde van de levering van de achtergrondtaken te waarborgen. Het is echter meestal efficiënter om het proces waar mogelijk zodanig te ontwerpen dat de volgorde van berichten er niet toe doet.

    • Een achtergrondtaak kijkt doorgaans naar berichten in de wachtrij, die tijdelijk verborgen worden voor andere gebruikers van berichten. Vervolgens worden de berichten verwijderd nadat ze met succes zijn verwerkt. Als een achtergrondtaak mislukt bij het verwerken van een bericht, wordt dat bericht opnieuw in de wachtrij opgenomen nadat de time-out is verlopen. Het bericht wordt verwerkt door een andere instantie van de taak of tijdens de volgende verwerkingscyclus van deze instantie. Als het bericht voortdurend een fout in de gebruiker veroorzaakt, wordt de taak, de wachtrij en uiteindelijk de toepassing zelf geblokkeerd wanneer de wachtrij vol raakt. Het is daarom essentieel om onverwerkbare berichten te detecteren en uit de wachtrij te verwijderen. Als u Azure Service Bus gebruikt, kunnen berichten die een fout veroorzaken, automatisch of handmatig worden verplaatst naar een gekoppelde wachtrij met dode brieven.

    • Wachtrijen garanderen dat berichten minimaal eenmaal worden geleverd, maar ze kunnen hetzelfde bericht ook meer dan eens leveren. Bovendien geldt dat als een achtergrondtaak mislukt na het verwerken van een bericht, maar voordat het bericht uit de wachtrij wordt verwijderd, het bericht weer voor verwerking beschikbaar komt. Achtergrondtaken moeten idempotent zijn, wat betekent dat het verwerken van hetzelfde bericht meerdere keren geen fout of inconsistentie veroorzaakt in de gegevens van de toepassing. Sommige bewerkingen zijn van nature idempotent, zoals het instellen van een opgeslagen waarde op een specifieke nieuwe waarde. Bewerkingen zoals het toevoegen van een waarde aan een bestaande opgeslagen waarde zonder te controleren of de opgeslagen waarde nog steeds hetzelfde is als toen het bericht oorspronkelijk werd verzonden, leiden echter tot inconsistenties. Azure Service Bus-wachtrijen kunnen worden geconfigureerd om dubbele berichten automatisch te verwijderen. Zie de richtlijnen voor het verwerken van idempotente berichten voor meer informatie over de uitdagingen met ten minste één berichtbezorging.

    • Sommige berichtensystemen, zoals Azure Queue Storage en Azure Service Bus-wachtrijen, ondersteunen een eigenschap voor het aantal wachtrijen die aangeeft hoe vaak een bericht uit de wachtrij is gelezen. Dit kan nuttig zijn bij de afhandeling van herhaalde en onverwerkbare berichten. Zie Asynchronous Messaging Primer (Asynchrone berichtpatronen) en Idempotency Patterns (Idempotentiepatronen) voor meer informatie.

Overwegingen bij schalen en prestaties

Achtergrondtaken moeten krachtig genoeg zijn zodat ze de toepassing niet blokkeren en niet leiden tot inconsistenties vanwege een vertraagde verwerking wanneer het systeem wordt belast. Normaal gesproken nemen de prestaties toe door het schalen van de rekenprocessen die als host fungeren voor de achtergrondtaken. Overweeg de volgende punten wat betreft schaalbaarheid en prestaties van achtergrondtaken:

  • ondersteuning voor Azure automatische schaalaanpassing (zowel uitschalen als weer inschalen) op basis van huidige vraag en belasting of volgens een vooraf gedefinieerd schema, voor gehoste implementaties van Web Apps en virtuele machines. Gebruik deze functie om ervoor te zorgen dat de toepassing als geheel voldoende prestaties levert terwijl runtimekosten worden geminimaliseerd.

  • Wanneer achtergrondtaken een andere prestatiemogelijkheid hebben dan de andere onderdelen van een toepassing (bijvoorbeeld de gebruikersinterface of onderdelen zoals de gegevenstoegangslaag), kunnen de achtergrondtaken worden gehost in een afzonderlijke rekenservice, zodat de gebruikersinterface en achtergrondtaken onafhankelijk kunnen worden geschaald om de belasting te beheren. Als meerdere achtergrondtaken aanzienlijk verschillende prestatiemogelijkheden van elkaar hebben, kunt u overwegen deze afzonderlijk te verdelen en elk type afzonderlijk te schalen. Houd er echter rekening mee dat dit de runtimekosten kan verhogen.

  • Het eenvoudig schalen van de rekenresources is mogelijk niet voldoende om verlies van prestaties onder belasting te voorkomen. Mogelijk moet u ook de schaal van opslagwachtrijen en andere resources vergroten om te voorkomen dat één punt van de algemene verwerkingsketen een knelpunt wordt. Houd ook rekening met andere beperkingen, zoals de maximale doorvoer van opslag en andere services waarvan de toepassing en de achtergrondtaken afhankelijk zijn.

  • Achtergrondtaken moeten zijn ontworpen voor schalen. Ze moeten bijvoorbeeld het aantal in gebruik zijnde opslagwachtrijen dynamisch kunnen detecteren om te luisteren op of berichten te verzenden naar de juiste wachtrij.

  • Standaard worden webtaken geschaald met hun bijbehorende Azure Web Apps-instantie. Als u echter een webtaak alleen als één instantie wilt laten uitvoeren, kunt u een Settings.job-bestand maken dat de JSON-gegevens {"is_singleton": true} bevat. Dit dwingt Azure slechts één instantie van de webtaak uit te voeren, zelfs als er meerdere instanties van de gekoppelde web-app zijn. Dit is een handige techniek voor geplande taken die alleen als één instantie moeten worden uitgevoerd.

Volgende stappen