Automatisch schalen

  • Artikel

Automatisch schalen is het proces van het dynamisch toewijzen van resources zodat deze overeenkomen met de prestatievereisten. Als de hoeveelheid werk groeit, heeft een toepassing mogelijk extra resources nodig om het gewenste prestatieniveau te behouden en te voldoen aan de SLA’s (Service Level Agreement). Wanneer de vraag afneemt en de extra resources niet meer nodig zijn, kan de toewijzing ervan ongedaan worden gemaakt om de kosten te verminderen.

Automatisch schalen maakt gebruik van de elasticiteit van cloudomgevingen terwijl tegelijkertijd de beheeroverhead wordt vereenvoudigd. Het verkleint de noodzaak om de prestaties van een systeem voortdurend te laten bijhouden door een operator die vervolgens beslissingen moet nemen over het toevoegen of verwijderen van resources.

Er zijn twee manieren waarop een toepassing kan worden geschaald:

  • Verticaal schalen, ook wel omhoog of omlaag schalen genoemd. Dit betreft het wijzigen van de capaciteit van een resource. U kunt een toepassing bijvoorbeeld verplaatsen naar een grotere VM. Tijdens verticaal schalen is een systeem vaak tijdelijk niet beschikbaar terwijl het opnieuw wordt geïmplementeerd. Daarom is het minder gebruikelijk om verticaal schalen te automatiseren.

  • Horizontaal schalen, ook wel in- en uitschalen genoemd. Dit betreft het toevoegen of verwijderen van exemplaren van een resource. De toepassing wordt zonder onderbreking uitgevoerd terwijl nieuwe resources worden ingericht. Wanneer de inrichting is voltooid, wordt de oplossing toegepast op deze extra resources. Als de vraag afneemt, kunnen de extra resources netjes worden uitgeschakeld en kan de toewijzing ervan ongedaan worden gemaakt.

Veel cloudsystemen, waaronder Microsoft Azure, bieden ondersteuning voor automatisch horizontaal schalen. De rest van dit artikel gaat over horizontaal schalen.

Notitie

Automatisch schalen wordt met name toegepast op rekenresources. Het is ook mogelijk om een database of berichtenwachtrij horizontaal te schalen, maar hiervoor is meestal gegevenspartitionering nodig, wat doorgaans niet wordt geautomatiseerd.

Onderdelen voor automatisch schalen

Een strategie voor automatisch schalen omvat meestal de volgende onderdelen:

  • Instrumentatie en bewaking van systemen op het niveau van de toepassing, service en infrastructuur. Met deze systemen worden belangrijke metrische gegevens vastgelegd zoals antwoordtijden, lengtes van wachtrijen, en CPU- en geheugengebruik.
  • Besluitvormingslogica waarmee deze metrische gegevens worden geëvalueerd op basis van vooraf gedefinieerde drempelwaarden of planningen, en waarmee beslissingen worden genomen over het al dan niet schalen.
  • Onderdelen waarmee het systeem wordt geschaald.
  • Testen, bewaken en afstemmen van de strategie voor automatisch schalen om te controleren of deze werkt zoals verwacht.

Azure biedt ingebouwde mechanismen voor automatisch schalen voor de meest voorkomende scenario’s. Als een bepaalde service of technologie geen ingebouwde functie voor automatisch schalen heeft, of als u hogere specifieke vereisten voor automatisch schalen hebt dan worden geboden, kunt u een aangepaste implementatie overwegen. Met een aangepaste implementatie kunt u metrische gegevens verzamelen over de werking en het systeem, deze analyseren en de resources vervolgens naar behoefte schalen.

Automatisch schalen configureren voor een oplossing in Azure

Automatisch schalen is ingebouwd in Azure voor de meeste rekenopties.

Al deze rekenopties maken gebruik van Automatisch schalen met Azure Monitor voor een algemene set met functies voor automatisch schalen.

  • Azure Functions verschilt van de vorige opties omdat u hier geen regels voor automatisch schalen hoeft te configureren. In plaats hiervan wordt rekencapaciteit in Azure Functions automatisch toegewezen wanneer uw code wordt uitgevoerd. Er wordt, indien nodig, uitgeschaald om de belasting te verwerken. Zie Choose the correct hosting plan for Azure Functions (Het juiste hostingabonnement voor Azure Functions kiezen) voor meer informatie.

Ten slotte kan een aangepaste oplossing voor automatisch schalen soms nuttig zijn. U kunt bijvoorbeeld Azure Diagnostics en metrische gegevens op basis van toepassingen gebruiken, samen met aangepaste code om de metrische gegevens van de toepassing te bewaken en te exporteren. U kunt dan aangepaste regels definiëren op basis van deze metrische gegevens, en Resource Manager REST API's gebruiken om automatisch schalen te activeren. Een aangepaste oplossing is echter niet eenvoudig te implementeren. Overweeg dit daarom alleen als geen van de vorige methoden aan uw vereisten voldoet.

Gebruik de ingebouwde functies voor automatisch schalen op het platform, als deze voldoen aan uw vereisten. Als dit niet het geval is, moet u zorgvuldig afwegen of u werkelijk behoefte hebt aan complexere schaalfuncties. Voorbeelden van aanvullende vereisten zijn mogelijk meer granulariteit van beheer, verschillende manieren om trigger-gebeurtenissen te detecteren voor schalen, schalen in abonnementen en andere typen resources te schalen.

Automatisch schalen met Azure Monitor gebruiken

Automatische schaalaanpassing van Azure Monitor biedt een algemene set functies voor automatisch schalen voor virtuele-machineschaalsets, Azure-app Service en Azure Cloud Service. Het schalen kan volgens een planning worden uitgevoerd of op basis van metrische runtime-gegevens, zoals CPU- en geheugengebruik.

Voorbeelden:

  • Uitschalen naar 10 exemplaren op werkdagen, en inschalen naar 4 exemplaren op zaterdag en zondag.
  • Uitschalen naar plus één exemplaar als het gemiddelde CPU-gebruik hoger is dan 70%, en inschalen naar min één exemplaar als het CPU-gebruik onder de 50% komt.
  • Uitschalen naar plus één exemplaar als het aantal berichten in een wachtrij boven een bepaalde drempelwaarde komt.

Schaal de resource omhoog wanneer de belasting toeneemt om de beschikbaarheid te garanderen. Op dezelfde manier kunt u op momenten van laag gebruik omlaag schalen, zodat u de kosten kunt optimaliseren. Gebruik altijd een combinatie van uitschalen en inschalen. Anders vindt de automatische schaalaanpassing slechts in één richting plaats totdat de drempelwaarde (maximum- of minimumaantal exemplaren) in het profiel is bereikt.

Selecteer een standaardaantal exemplaren dat veilig is voor uw workload. Deze wordt geschaald op basis van die waarde als er geen maximum- of minimumaantal exemplaren zijn ingesteld.

Zie Azure Monitor autoscaling common metrics (Metrische gegevens automatisch schalen met Azure Monitor) voor een lijst met ingebouwde metrische gegevens. U kunt aangepaste metrische gegevens ook implementeren met behulp van Application Insights.

U kunt automatisch schalen configureren met behulp van PowerShell, Azure CLI, een Azure Resource Manager-sjabloon of Azure Portal. Gebruik de Azure Resource Manager REST API voor meer gedetailleerd beheer. De Azure Monitoring Service-beheerbibliotheek en de Microsoft Insights-bibliotheek (in de preview-versie) zijn SDK’s voor het verzamelen van metrische gegevens uit verschillende resources en het uitvoeren van automatisch schalen met behulp van een van de REST API’s. De Service Management REST API kan worden gebruikt voor het automatisch schalen van resources waarvoor Azure Resource Manager-ondersteuning niet beschikbaar is of als u gebruikmaakt van Azure Cloud Services. Gebruik in alle andere gevallen Azure Resource Manager.

Houd rekening met de volgende punten wanneer u automatisch schalen van Azure gebruikt:

  • Overweeg of u de belasting van de toepassing nauwkeurig genoeg kunt voorspellen om geplande automatische schaalaanpassing te gebruiken, exemplaren toe te voegen en te verwijderen om te voldoen aan verwachte pieken in de vraag. Als u dit niet zeker weet, kunt u beter reactief automatisch schalen gebruiken op basis van metrische runtime-gegevens om moeilijk te voorspellen wijzigingen in de vraag te verwerken. Doorgaans kunt u deze twee methoden combineren. Maak bijvoorbeeld een strategie waarmee resources worden toegevoegd op basis van een schema van de tijden waarin u weet dat de toepassing het drukst is. Dit zorgt ervoor dat de capaciteit beschikbaar is wanneer dit is vereist, zonder vertraging doordat een nieuw exemplaar moet worden gestart. Definieer voor elk geplande regel metrische gegevens op basis waarvan reactief automatisch schalen gedurende deze periode is toegestaan. Zo zorgt u ervoor dat de toepassing aanhoudende maar moeilijk te voorspellen pieken in de vraag kan verwerken.

  • Het is vaak lastig om de relatie te begrijpen tussen metrische gegevens en de capaciteitsvereisten, vooral wanneer een toepassing de eerste keer wordt geïmplementeerd. Richt in het begin wat extra capaciteit in, en bewaak de regels voor automatisch schalen vervolgens en stem ze af om de capaciteit beter te laten overeenkomen met de werkelijke belasting.

  • Configureer de regels voor automatisch schalen en bewaak vervolgens gedurende een bepaalde periode de prestaties van de toepassing. Gebruik de resultaten hiervan om, indien nodig, de manier aan te passen waarop in het systeem automatisch wordt geschaald. Houd er echter rekening mee dat automatisch schalen nooit onmiddellijk wordt doorgevoerd. Het duurt even om te reageren op metrische gegevens zoals het overschrijden (of juist niet) van de drempelwaarde voor het gemiddelde CPU-gebruik.

  • Regels voor automatisch schalen die gebruikmaken van een detectiemechanisme op basis van een gemeten triggerkenmerk (zoals CPU-gebruik of lengtes van wachtrijen), maken gebruik van een statistische waarde over een bepaalde periode - en niet van onmiddellijke waarden - voor het activeren van automatisch schalen. Deze statistische waarde is standaard een gemiddelde van alle waarden. Dit voorkomt dat het systeem te snel reageert of dat snelle wisselingen plaatsvinden. Het maakt ook tijd mogelijk voor nieuwe exemplaren die automatisch in de actieve modus worden gestart, waardoor er geen extra acties voor automatisch schalen kunnen optreden terwijl de nieuwe exemplaren worden gestart. Voor Azure Cloud Services en virtuele Azure-machines is de standaardperiode voor de statistische waarde 45 minuten. Het duurt dus maximaal 45 minuten voordat automatisch schalen wordt geactiveerd op basis van de metrische gegevens als antwoord op de pieken in de vraag. U kunt de aggregatieperiode wijzigen met behulp van de SDK, maar perioden van minder dan 25 minuten kunnen onvoorspelbare resultaten veroorzaken. Voor Web Apps is de gemiddelde periode veel korter, zodat nieuwe exemplaren al na ongeveer vijf minuten na een wijziging in de gemiddelde triggermeting beschikbaar zijn.

  • Vermijd flapping waarbij in- en uitschaalacties voortdurend heen en weer gaan. Stel dat er twee exemplaren zijn en dat de bovengrens 80% CPU is, een lagere limiet is van 60%. Wanneer de belasting 85% is, wordt er een ander exemplaar toegevoegd. Na enige tijd neemt de belasting af tot 60%. Voordat u inschaalt, berekent de service voor automatisch schalen de verdeling van de totale belasting (van drie exemplaren) wanneer een exemplaar wordt verwijderd, waarbij deze naar 90% wordt verplaatst. Dit betekent dat het onmiddellijk weer moet worden uitgeschaald. Hierdoor wordt het inschalen overgeslagen en ziet u mogelijk nooit de verwachte schaalresultaten.

    De flappingsituatie kan worden bepaald door een voldoende marge te kiezen tussen de drempelwaarden voor uitschalen en inschalen.

  • Handmatig schalen wordt opnieuw ingesteld op maximum- en minimumaantal exemplaren dat wordt gebruikt voor automatisch schalen. Als u het aantal exemplaren handmatig bijwerkt naar een waarde die hoger of lager is dan de maximumwaarde, wordt de engine voor automatisch schalen automatisch terug geschaald naar het minimum (indien lager) of het maximum (indien hoger). U stelt bijvoorbeeld het bereik tussen 3 en 6 in. Als u één actief exemplaar hebt, wordt de engine voor automatisch schalen geschaald naar drie exemplaren tijdens de volgende uitvoering. Als u de schaal handmatig instelt op acht exemplaren, wordt deze op de volgende uitvoering automatisch schalen terug geschaald naar zes exemplaren tijdens de volgende uitvoering. Handmatig schalen is tijdelijk, tenzij u ook de regels voor automatisch schalen opnieuw instelt.

  • De engine voor automatisch schalen verwerkt slechts één profiel tegelijk. Als niet aan een voorwaarde wordt voldaan, wordt gecontroleerd op het volgende profiel. Houd belangrijke metrische gegevens buiten het standaardprofiel omdat dat profiel als laatste is gecontroleerd. Binnen een profiel kunt u meerdere regels hebben. Bij uitschalen wordt automatisch schalen uitgevoerd als aan een regel wordt voldaan. Bij inschalen moet aan alle regels voor automatische schaalaanpassing worden voldaan.

Zie Aanbevolen procedures voor automatische schaalaanpassing voor meer informatie over hoe Azure Monitor wordt geschaald.

  • Als u automatisch schalen configureert met behulp van de SDK in plaats van de portal, kunt u een meer gedetailleerde planning opgeven gedurende welke de regels actief zijn. U kunt ook uw eigen metrische gegevens maken en deze gebruiken met of zonder de bestaande metrische gegevens in uw regels voor automatisch schalen. U kunt bijvoorbeeld alternatieve tellers gebruiken, zoals het aantal aanvragen per seconde of de gemiddelde beschikbaarheid van het geheugen, of aangepaste tellers gebruiken om specifieke bedrijfsprocessen te meten.

  • Wanneer Service Fabric automatisch wordt geschaald, worden de knooppunttypen in uw cluster gemaakt van virtuele-machineschaalsets aan de back-end. U moet dus regels voor automatisch schalen instellen voor elk knooppunttype. Houd rekening met het aantal knooppunten dat u moet hebben voordat u automatische schaalaanpassing instelt. Het minimum aantal knooppunten dat u nodig hebt voor het primaire knooppunttype, wordt bepaald door het betrouwbaarheidsniveau dat u hebt gekozen. Zie Een Service Fabric-cluster in- of uitschakelen met behulp van regels voor automatisch schalen voor meer informatie.

  • U kunt de portal gebruiken om resources zoals SQL Database-exemplaren en wachtrijen te koppelen aan een Cloud Service-exemplaar. Hierdoor hebt u eenvoudiger toegang tot de afzonderlijke handmatige en automatische configuratieopties voor schalen voor elk van de gekoppelde resources. Zie How to: Link a resource to a cloud service (Instructies: een resource koppelen aan een cloudservice) voor meer informatie.

  • Wanneer u meerdere regels en beleidsregels configureert, kunnen deze met elkaar conflicteren. Automatisch schalen maakt gebruik van de volgende regels voor conflictoplossing om ervoor te zorgen dat altijd genoeg exemplaren worden uitgevoerd:

    • Uitschaalbewerkingen hebben altijd voorrang op inschalingsbewerkingen.
    • Wanneer uitschaalbewerkingen conflicteren, heeft de regel die de grootste toename van het aantal exemplaren start voorrang.
    • Wanneer bewerkingen voor inschalen onderling conflicteren, heeft de regel voorrang op basis waarvan de kleinste afname van het aantal exemplaren plaatsvindt.

  • In een App Service-omgeving kunnen alle werkrollen of front-endgegevens worden gebruikt om regels voor automatisch schalen te definiëren. Zie Autoscaling and App Service Environment (Automatisch schalen en App Service Environment) voor meer informatie.

Ontwerpoverwegingen voor toepassingen

Automatisch schalen is geen onmiddellijke oplossing. Het simpelweg toevoegen van resources aan een systeem of het uitvoeren van meer exemplaren van een proces is geen garantie dat de prestaties van het systeem verbeteren. Houd rekening met de volgende punten bij het ontwerpen van een strategie voor automatisch schalen:

  • Het systeem moet zijn ontworpen om horizontaal te kunnen worden geschaald. Vermijd veronderstellingen over de affiniteit van exemplaren. Ontwerp geen oplossingen waarvoor is vereist dat de code altijd wordt uitgevoerd in een specifiek exemplaar van een proces. Wanneer u een cloudservice of website horizontaal schaalt, moet u niet veronderstellen dat een reeks aanvragen van dezelfde bron altijd naar hetzelfde exemplaar worden gerouteerd. Ontwerp om deze reden ook staatloze services om te voorkomen dat een reeks aanvragen van een toepassing altijd moeten worden gerouteerd naar hetzelfde exemplaar van een service. Bij het ontwerpen van een service waarmee berichten uit een wachtrij worden gelezen en verwerkt, kunt u niet van tevoren weten welk exemplaar van de service een specifiek bericht gaat verwerken. Met automatisch schalen kunnen extra exemplaren van een service worden gestart als de lengte van de wachtrij toeneemt. In het patroon Concurrerende consumenten wordt beschreven hoe u dit scenario kunt verwerken.

  • Als met de oplossing een langlopende taak wordt geïmplementeerd, ontwerpt u deze taak zo dat zowel uit- als inschalen wordt ondersteund. Als u dit niet doet, kan een dergelijke taak ervoor zorgen dat een exemplaar van een proces wordt afgesloten wanneer het systeem wordt ingeschaald, of er kunnen gegevens verloren gaan als het proces geforceerd wordt beëindigd. U kunt een langlopende taak het beste herstructureren en de verwerkingstaak opsplitsen in kleinere afzonderlijke gedeelten. Het patroon Pipes en Filters geeft een voorbeeld van hoe u dit kunt bereiken.

  • U kunt er ook voor kiezen om een controlepunt te implementeren waarmee met enige regelmaat statusgegevens voor de taak worden vastgelegd. U kunt deze status vervolgens opslaan in een duurzame opslag die toegankelijk is voor elk exemplaar van het proces dat de taak uitvoert. Als het proces op deze manier wordt afgesloten, kan het werk dat het proces heeft uitgevoerd, worden hervat vanaf het laatste controlepunt met behulp van een ander exemplaar. Er zijn bibliotheken die deze functionaliteit bieden, zoals NServiceBus en MassTransit. Ze behouden de status transparant, waarbij de intervallen worden afgestemd op de verwerking van berichten uit wachtrijen in Azure Service Bus.

  • Wanneer achtergrondtaken worden uitgevoerd op afzonderlijke rekeninstanties, zoals in werkrollen van een cloudservices-gehoste toepassing, moet u mogelijk verschillende onderdelen van de toepassing schalen met behulp van verschillende schaalbeleidsregels. Misschien wilt u bijvoorbeeld extra UI-rekenprocessen (User Interface) implementeren zonder het aantal rekenprocessen op de achtergrond te verhogen, of juist het tegenovergestelde hiervan. Als u verschillende serviceniveaus biedt (zoals Basic- en Premium-pakketten), moet u mogelijk de rekenresources voor Premium-pakketten veel meer uitschalen dan die voor de Basic-pakketten om aan de SLA’s te voldoen.

  • Houd rekening met de lengte van de wachtrij over welke ui- en achtergrond-rekeninstanties communiceren. Gebruik dit als criterium voor uw strategie voor automatisch schalen. Dit is een mogelijke indicator van een onevenwichtigheid of verschil tussen de huidige belasting en de verwerkingscapaciteit van de achtergrondtaak. Er is een iets complexer, maar beter kenmerk voor het baseren van schaalbeslissingen op. Gebruik de tijd tussen het moment waarop een bericht is verzonden en wanneer de verwerking is voltooid, ook wel de kritieke tijd genoemd. Als deze kritieke tijdwaarde onder een zinvolle bedrijfsdrempel ligt, is het niet nodig om te schalen, zelfs als de lengte van de wachtrij lang is.

    • Er kunnen bijvoorbeeld 50.000 berichten in een wachtrij staan, maar de kritieke tijd van het oudste bericht is 500 ms en dat eindpunt te maken heeft met integratie met een externe webservice voor het verzenden van e-mailberichten. Het is waarschijnlijk dat zakelijke belanghebbenden overwegen dat het een periode is die niet zou rechtvaardigen om extra geld uit te geven voor schaalaanpassing.
    • Aan de andere kant kunnen er 500 berichten in een wachtrij zijn, met dezelfde kritieke tijd van 500 ms, maar het eindpunt maakt deel uit van het kritieke pad in een realtime onlinespel, waarbij zakelijke belanghebbenden een reactietijd van 100 ms of minder hebben gedefinieerd. In dat geval zou uitschalen zinvol zijn.
    • Als u kritieke tijd wilt gebruiken bij beslissingen voor automatisch schalen, is het handig om een bibliotheek automatisch de relevante informatie toe te voegen aan de kopteksten van berichten, terwijl ze worden verzonden en verwerkt. Een dergelijke bibliotheek die deze functionaliteit biedt, is NServiceBus.

  • Als u uw strategie voor automatisch schalen baseert op tellers waarmee bedrijfsprocessen worden gemeten (zoals het aantal geplaatste orders per uur of de gemiddelde uitvoeringstijd van een complexe overdracht), zorgt u ervoor dat u de relatie tussen de resultaten van deze typen tellers en de werkelijke vereisten voor de rekencapaciteit volledig begrijpt. Het kan nodig zijn om meer dan één onderdeel of rekeneenheid te schalen als reactie op wijzigingen in de tellers voor bedrijfsprocessen.

  • Overweeg om het maximum aantal exemplaren dat automatisch kan worden toegevoegd, te beperken om te voorkomen dat een systeem te veel wordt uitgeschaald en de hoge kosten te voorkomen die gepaard gaan met het uitvoeren van duizenden exemplaren. Bij de meeste mechanismen voor automatisch schalen kunt u zelf opgeven hoeveel exemplaren van een regel u minimaal en maximaal wilt uitvoeren. Overweeg daarnaast om de functionaliteit van het systeem te verlagen als het nog steeds is overbelast als het maximum aantal exemplaren is geïmplementeerd.

  • Onthoud dat automatisch schalen mogelijk niet de beste manier is om een plotselinge verhoging van de werkbelasting te verwerken. Het kost tijd om nieuwe exemplaren van een service in te richten en te starten, of om resources toe te voegen aan een systeem. Tegen de tijd dat deze extra resources beschikbaar zijn, is de piek in de vraag mogelijk al voorbij. In dit scenario is het wellicht beter om de service te beperken. Zie het patroon Beperking voor meer informatie.

  • Als u daarentegen wel de volledige capaciteit nodig hebt om alle aanvragen te verwerken wanneer het volume fluctueert - en de kosten geen cruciale rol spelen -, kunt u overwegen om een proactieve strategie voor automatisch schalen te gebruiken, waardoor extra exemplaren sneller worden gestart. U kunt ook gepland beleid gebruiken op basis waarvan voldoende exemplaren worden gestart om de maximum belasting te verwerken, voordat deze belasting daadwerkelijk wordt verwacht.

  • Met het mechanisme voor automatisch schalen moet het proces van automatisch schalen worden bewaakt. De details van elke gebeurtenis voor automatisch schalen moeten in een logboek worden vastgelegd. (Wat was de trigger, welke resources zijn toegevoegd of verwijderd, en wanneer?) Als u een aangepast mechanisme voor automatisch schalen maakt, zorgt u ervoor dat deze mogelijkheid hierin is opgenomen. Analyseer de informatie om de efficiëntie van de strategie voor automatisch schalen te meten en, indien nodig, af te stemmen. U kunt zowel op de korte termijn afstemmen (zodra het verbruikspatroon duidelijker wordt), als op de lange termijn (wanneer de bedrijfstaken toenemen of de vereisten van de toepassing zich ontwikkelen). Als een toepassing de bovengrens voor automatisch schalen bereikt, wordt in het mechanisme mogelijk ook een operator gewaarschuwd. Deze kan eventueel handmatig extra resources starten, indien nodig. Houd er rekening mee dat de operator onder deze omstandigheden ook verantwoordelijk kan zijn voor het handmatig verwijderen van deze resources nadat de workload is versoepeld.

De volgende patronen en richtlijnen zijn mogelijk ook relevant voor uw scenario bij het implementeren van automatische schaalaanpassing:

  • Patroon voor beperking. Dit patroon beschrijft hoe een toepassing kan blijven functioneren en kan blijven voldoen aan de SLA’s wanneer de vraag toeneemt en de resources extreem worden belast. Beperking kan worden gebruikt met automatisch schalen om te voorkomen dat een systeem wordt overbelast tijdens het uitschalen.

  • Patroon Concurrerende consumenten. Dit patroon beschrijft hoe een pool met service-exemplaren wordt geïmplementeerd die berichten van elk toepassingsexemplaar kunnen verwerken. Automatisch schalen kan worden gebruikt om service-exemplaren te starten en te stoppen anticiperend op de verwachte werkbelasting. Deze aanpak stelt een systeem in staat om meerdere berichten tegelijkertijd te verwerken en zo de doorvoer te optimaliseren, schaalbaarheid en beschikbaarheid te verbeteren, en de werkbelasting in balans te houden.

  • Bewaking en diagnose. Instrumentatie en telemetrie zijn essentieel voor het verzamelen van informatie waarvan het proces voor automatisch schalen afhankelijk is.