Delen via

Aanbevelingen voor het ontwerpen van een betrouwbare schaalstrategie

  • Artikel

Van toepassing op deze Azure-aanbeveling voor betrouwbaarheid in de Well-Architected Framework checklist:

RE:06 Implementeer een tijdige en betrouwbare schaalstrategie op toepassings-, gegevens- en infrastructuurniveau. Baseer de schaalstrategie op werkelijke of voorspelde gebruikspatronen en minimaliseer handmatige interventie.

Gerelateerde handleiding:Gegevenspartitionering

In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een betrouwbare schaalstrategie.

Definities

Term Definitie
Verticaal schalen Een schaalbenadering waarmee rekencapaciteit wordt toegevoegd aan bestaande resources.
Horizontaal schalen Een schaalbenadering waarmee exemplaren van een bepaald type resource worden toegevoegd.
Automatisch schalen Een schaalbenadering waarmee automatisch resources worden toegevoegd of verwijderd wanneer aan een set voorwaarden wordt voldaan.

Notitie

Schaalbewerkingen kunnen statisch zijn (regelmatig gepland dagelijks schalen voor normale belastingspatronen), automatisch (een geautomatiseerd proces als reactie op voorwaarden waaraan wordt voldaan) of handmatig (een operator voert een eenmalige schaalbewerking uit als reactie op een onverwachte belastingswijziging). Zowel verticaal als horizontaal schalen kan worden uitgevoerd via een van deze methoden. Automatische verticale schaalaanpassing vereist echter aanvullende ontwikkeling van aangepaste automatisering en kan downtime veroorzaken, afhankelijk van de resources die worden geschaald.

Belangrijke ontwerpstrategieën

Ontwerpen op basis van belastingpatronen

Als u een betrouwbare schaalstrategie voor uw workloads wilt ontwerpen, moet u zich richten op het identificeren van belastingspatronen voor de gebruiker en systeemstromen voor elke workload die leidt tot een schaalbewerking. Hier volgen voorbeelden van de verschillende laadpatronen:

  • Statische: elke nacht om 11:00 uur EST ligt het aantal actieve gebruikers onder de 100 en het CPU-gebruik voor de app-servers daalt met 90% op alle knooppunten.

  • Dynamisch, regelmatig en voorspelbaar: elke maandagochtend melden 1000 werknemers zich aan bij het ERP-systeem.

  • dynamische, onregelmatige en voorspelbare: er vindt een productlancering plaats op de eerste dag van de maand en er zijn historische gegevens uit eerdere lanceringen over hoe het verkeer in deze situaties toeneemt.

  • dynamische, onregelmatige en onvoorspelbare: een grootschalige gebeurtenis veroorzaakt een piek in de vraag naar een product. Bedrijven die bijvoorbeeld ontvochtigers produceren en verkopen, kunnen een plotselinge piek in online verkeer ervaren na een orkaan of een andere overstromingsgebeurtenis, omdat mensen in de getroffen gebieden ruimtes in hun huis moeten drogen.

Nadat u deze typen belastingpatronen hebt geïdentificeerd, kunt u het volgende doen:

  • Bepaal hoe de belastingwijziging die aan elk patroon is gekoppeld, van invloed is op uw infrastructuur.

  • Bouw automatisering om de schaal betrouwbaar aan te pakken.

Voor de vorige voorbeelden kunnen uw schaalstrategieën het volgende zijn:

  • statische: U hebt gepland om uw rekenknooppunten op te schalen tot het minimumaantal (2) tussen 23:00 en 06:00 EST.

  • dynamisch, regulier en voorspelbaar: u hebt een geplande opschaling van uw rekenknooppunten naar de normale dagelijkse capaciteit voordat de eerste regio begint met werken.

  • dynamische, onregelmatige en voorspelbare: u definieert een eenmalige geplande schaalaanpassing van uw reken- en database-exemplaren op de ochtend van een productlancering en u schaalt na een week weer omlaag.

  • dynamische, onregelmatige en onvoorspelbare: u hebt drempelwaarden voor automatische schaalaanpassing gedefinieerd om rekening te houden met niet-geplande verkeerspieken.

Schaalstrategieën automatiseren

Wanneer u uw schaalautomatisering ontwerpt, moet u rekening houden met deze problemen:

  • Dat alle onderdelen van uw workload kandidaten moeten zijn voor de implementatie van schaalvergroting. In de meeste gevallen worden wereldwijde services zoals Microsoft Entra ID automatisch en transparant geschaald voor u en uw klanten. Zorg ervoor dat u inzicht krijgt in de schaalmogelijkheden van uw netwerkinkomende en uitgaande controllers en uw oplossing voor taakverdeling.

  • Die onderdelen die niet kunnen worden uitgeschaald. Een voorbeeld hiervan is grote relationele databases waarvoor sharding niet is ingeschakeld en die niet kunnen worden geherstructureerd zonder aanzienlijke gevolgen. Documenteer de resourcelimieten die zijn gepubliceerd door uw cloudprovider en bewaak deze resources nauwkeurig. Neem deze specifieke resources op in uw toekomstige planning voor migratie naar schaalbare services.

  • De tijd die nodig is om de schaalbewerking uit te voeren, zodat u de bewerking op de juiste manier kunt plannen voordat de extra belasting uw infrastructuurraakt. Als het bijvoorbeeld 45 minuten duurt voordat een onderdeel zoals API Management wordt geschaald, kunt u de drempelwaarde voor schaalaanpassing aanpassen aan 65% in plaats van 90% u mogelijk helpen eerder te schalen en de verwachte toename van de belasting voor te bereiden.

  • De relatie van de componenten van het proces in de volgorde van schaaloperaties. Zorg ervoor dat u een downstreamonderdeel niet per ongeluk overbelast door eerst een upstream-onderdeel te schalen.

  • Stateful applicatie-elementen die kunnen worden onderbroken door een schaaloperatie en eventuele sessieaffiniteit (of sessieplakkendheid) die zijn geïmplementeerd. Plakkerigheid kan uw schaalbaarheid beperken en introduceert enkele punten van falen.

  • potentiële knelpunten. Uitschalen lost niet elk prestatieprobleem op. Als uw back-enddatabase bijvoorbeeld het knelpunt is, is het niet handig om meer webservers toe te voegen. Identificeer en los de knelpunten in het systeem eerst op voordat u meer exemplaren toevoegt. Stateful onderdelen van het systeem zijn de meest waarschijnlijke oorzaak van knelpunten.

Het volgen van het implementatiestempel ontwerppatroon helpt bij uw algehele infrastructuurbeheer. Het baseren van uw schaalontwerp op stempels als schaaleenheden is ook nuttig. Het helpt u uw schaalbewerkingen nauwkeurig te beheren voor meerdere workloads en subsets daarvan. In plaats van de schaalschema's en drempelwaarden voor automatisch schalen van veel afzonderlijke resources te beheren, kunt u een beperkte set schaaldefinities toepassen op een implementatiestempel en deze vervolgens naar behoefte spiegelen tussen stempels.

Compromis: Omhoog schalen heeft gevolgen voor de kosten, dus optimaliseer uw strategie om zo snel mogelijk omlaag te schalen om de kosten onder controle te houden. Zorg ervoor dat de automatisering die u gebruikt om omhoog te schalen ook triggers heeft om omlaag te schalen.

Azure faciliteiten

Er is een functie voor automatisch schalen beschikbaar in veel Azure-services. Hiermee kunt u eenvoudig voorwaarden configureren om exemplaren automatisch horizontaal te schalen. Sommige services hebben beperkte of geen ingebouwde functionaliteit om automatisch in te schalen, dus documenteer deze gevallen en definieer processen om te kunnen inschalen.

Veel Azure-services bieden API's die u kunt gebruiken om aangepaste bewerkingen voor automatisch schalen te ontwerpen met behulp van Azure Automation-, zoals de codevoorbeelden op Uw Azure IoT Hub-automatisch schalen. U kunt hulpprogramma's zoals KEDA gebruiken voor gebeurtenisgestuurde automatische schaalaanpassing, die beschikbaar is in Azure Kubernetes Service en Azure Container Apps.

Automatische schaalaanpassing van Azure Monitor biedt een algemene set functies voor automatisch schalen voor Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps en meer. Schalen kan worden uitgevoerd volgens een schema of op basis van een uitvoeringsmetriek, zoals CPU- of geheugengebruik. Zie de Azure Monitor-handleiding voor aanbevolen procedures.

Compromissen

Overwegingen voor automatisch schalen

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

Het systeem moet zijn ontworpen om horizontaal schaalbaar te zijn. Vermijd het maken van veronderstellingen over instantieaffiniteit. Ontwerp geen oplossingen die vereisen dat de code altijd wordt uitgevoerd in een specifiek exemplaar van een proces. Wanneer u een cloudservice of website horizontaal schaalt, wordt er niet van uitgegaan dat een reeks aanvragen van dezelfde bron altijd naar hetzelfde exemplaar wordt gerouteerd. Om dezelfde reden moeten services zo worden ontworpen dat ze stateless zijn, om te voorkomen dat een reeks aanvragen van een applicatie altijd naar hetzelfde exemplaar van een service wordt gerouteerd. Bij het ontwerpen van een service die berichten uit een wachtrij leest en verwerkt, moet u geen veronderstellingen maken over welk exemplaar van de service een specifiek bericht verwerkt. Automatisch schalen kan meer instanties van een service starten naarmate de wachtrijlengte toeneemt. In het patroon Concurrerende consumenten wordt beschreven hoe u dit scenario kunt verwerken.

Als de oplossing een langlopende taak implementeert, ontwerpt u deze taak om zowel uitschalen als inschalen te ondersteunen. Zonder de nodige zorgvuldigheid kan een dergelijke taak voorkomen dat een instantie van een proces op een nette manier wordt afgesloten wanneer het systeem wordt opgeschaald. Het kan ook gegevens verliezen als het proces geforceerd wordt beëindigd. In het ideale instantie herstructureer u een langlopende taak en breekt u de verwerking op die in kleinere, discrete segmenten wordt uitgevoerd. Het patroon Pipes en Filters geeft een voorbeeld van hoe u deze oplossing kunt bereiken.

U kunt ook een controlepuntmechanisme implementeren waarmee statusinformatie over de taak met regelmatige tussenpozen wordt vastgelegd. U kunt deze status vervolgens opslaan in duurzame opslag die toegankelijk is voor elk exemplaar van het proces dat de taak uitvoert. Als op deze wijze het proces wordt stopgezet, kan het werk dat werd uitgevoerd, door een andere instantie worden hervat vanaf het laatste controlepunt. Er zijn bibliotheken die deze functionaliteit bieden, zoals NServiceBus en MassTransit. Ze zorgen ervoor dat de status transparant wordt behouden, waarbij de intervallen worden afgestemd op de verwerking van berichten uit de queues in Azure Service Bus.

Wanneer achtergrondtaken worden uitgevoerd op afzonderlijke rekeninstanties, zoals in werkrollen van een toepassing in de cloudservices, moet u mogelijk verschillende onderdelen van de toepassing schalen met behulp van verschillende schaalbeleidsregels. U moet bijvoorbeeld extra rekenexemplaren voor de gebruikersinterface implementeren zonder het aantal achtergrondrekenexemplaren te verhogen, of omgekeerd. Als u verschillende serviceniveaus aanbiedt, zoals basis- en premium-servicepakketten, moet u mogelijk de rekenresources voor premium-servicepakketten agressiever uitbreiden dan voor basisservicepakketten om te voldoen aan service level agreements (SLA's).

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 probleem is een mogelijke indicator van een onevenwichtigheid of verschil tussen de huidige belasting en de verwerkingscapaciteit van de achtergrondtaak. Een iets complexer maar beter kenmerk waarop beslissingen voor schaalaanpassing moeten worden gebaseerd, is het gebruik van de tijd tussen het verzenden van een bericht en het moment waarop de verwerking is voltooid. Dit interval wordt 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 het eindpunt heeft te maken met integratie met een webservice van derden voor het verzenden van e-mailberichten. Zakelijke belanghebbenden zouden er waarschijnlijk rekening mee houden dat dit 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 bibliotheek die deze functionaliteit biedt, is NServiceBus.

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

Als u wilt voorkomen dat een systeem te veel uitschaalt en de kosten voor het uitvoeren van vele duizenden exemplaren wilt voorkomen, kunt u overwegen het maximum aantal exemplaren te beperken dat automatisch wordt toegevoegd. Met de meeste mechanismen voor automatisch schalen kunt u het minimum- en maximumaantal exemplaren voor een regel opgeven. Overweeg bovendien om de functionaliteit die het systeem biedt op een juiste manier te verminderen als het maximum aantal exemplaren is geïmplementeerd en het systeem nog steeds overbelast is.

Houd er rekening mee dat automatisch schalen mogelijk niet het meest geschikte mechanisme is voor het afhandelen van een plotselinge burst in een workload. Het kost tijd om nieuwe exemplaren van een service in te richten en te starten of resources toe te voegen aan een systeem, en de piekvraag kan duren voordat deze extra resources beschikbaar zijn. In dit scenario is het misschien beter om de service af te remmen. Voor meer informatie, zie het throttling-patroon.

Als u daarentegen de capaciteit nodig hebt om alle aanvragen te verwerken wanneer het volume snel fluctueert en de kosten geen belangrijke bijdragefactor zijn, kunt u overwegen een agressieve strategie voor automatisch schalen te gebruiken waarmee meer exemplaren sneller worden gestart. U kunt ook een vooraf ingepland beleid gebruiken waarmee een voldoende aantal exemplaren wordt gestart om de maximale belasting op te vangen voordat deze belasting wordt verwacht.

Het mechanisme voor automatisch schalen moet het proces voor automatisch schalen bewaken en de details van elke gebeurtenis voor automatisch schalen registreren (wat dit heeft geactiveerd, welke resources zijn toegevoegd of verwijderd en wanneer). Als u een aangepast mechanisme voor automatisch schalen maakt, moet u ervoor zorgen dat deze mogelijkheid is opgenomen. Analyseer de informatie om de effectiviteit van de strategie voor automatisch schalen te meten en stem deze zo nodig af. U kunt beide op de korte termijn afstemmen, omdat de gebruikspatronen duidelijker worden en op de lange termijn, naarmate het bedrijf toebreidt of de vereisten van de toepassing zich verder ontwikkelt. Als een toepassing de bovengrens bereikt die is gedefinieerd voor automatisch schalen, kan het mechanisme ook een operator waarschuwen die indien nodig handmatig meer resources kan starten. In deze omstandigheden is de operator mogelijk ook verantwoordelijk voor het handmatig verwijderen van deze resources nadat de workload is versoepeld.

Voorbeeld

Raadpleeg de referentiearchitectuur van de AKS-basislijn richtlijnen voor schalen.

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

controlelijst voor betrouwbaarheid