Aanbevelingen voor het ontwerpen van een betrouwbare schaalstrategie
Is van toepassing op deze aanbeveling voor de controlelijst voor betrouwbaarheid van Azure Well-Architected Framework:
| RE:06 | Implementeer een tijdige en betrouwbare schaalstrategie op toepassings-, gegevens- en infrastructuurniveau. |
|---|
Verwante handleiding: Gegevenspartitionering
In deze handleiding worden de aanbevelingen beschreven voor het ontwerpen van een betrouwbare schaalstrategie.
Definities
| Termijn | Definitie |
|---|---|
| Verticale schaalaanpassing | Een schaalbenadering waarmee rekencapaciteit wordt toegevoegd aan bestaande resources. |
| Horizontale schaalaanpassing | 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:
Statisch: 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.
Dynamisch, onregelmatig en voorspelbaar: een productlancering vindt plaats op de eerste dag van de maand en er zijn historische gegevens van eerdere lanceringen over hoe het verkeer in deze situaties toeneemt.
Dynamisch, onregelmatig en onvoorspelbaar: Een grootschalige gebeurtenis veroorzaakt een piek in de vraag naar een product. Bedrijven die bijvoorbeeld ontvochtigers produceren en verkopen, kunnen een plotselinge piek in het verkeer ervaren na een orkaan of een ander overstromingsgebeurtenis wanneer mensen in getroffen gebieden 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:
Statisch: U hebt een geplande schaal van uw rekenknooppunten tot het minimumaantal (2) tussen 11:00 en 6:00 EST.
Dynamisch, normaal en voorspelbaar: u hebt een geplande uitschaal van uw rekenknooppunten naar de normale dagelijkse capaciteit voordat de eerste regio begint te werken.
Dynamisch, onregelmatig en voorspelbaar: u definieert een eenmalige geplande schaalaanpassing van uw reken- en database-exemplaren op de ochtend van een productlancering en u schaalt na één week weer omlaag.
Dynamisch, onregelmatig en onvoorspelbaar: 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 het schalen van de implementatie. 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.
Deze 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 goed plant voordat de extra belasting uw infrastructuur bereikt. Als het bijvoorbeeld 45 minuten duurt voordat een onderdeel zoals API Management wordt geschaald, kan het aanpassen van de drempelwaarde voor schaalaanpassing naar 65% in plaats van 90% u helpen om eerder te schalen en de verwachte toename van de belasting voor te bereiden.
De relatie van de onderdelen van de stroom in volgorde van schaalbewerkingen. Zorg ervoor dat u een downstreamonderdeel niet per ongeluk overbelast door eerst een upstream-onderdeel te schalen.
Stateful toepassingselementen die kunnen worden onderbroken door een schaalbewerking en eventuele sessieaffiniteit (of sessiekleverigheid) die zijn geïmplementeerd. Stickiness kan uw schaalvermogen beperken en introduceert single points of failure.
Mogelijke 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. Knelpunten worden meestal veroorzaakt door stateful onderdelen van het systeem.
Door het ontwerppatroon voor implementatiestempels te volgen, kunt u het algehele infrastructuurbeheer gebruiken. Het baseren van uw schaalontwerp op stempels als schaaleenheden is ook nuttig. En het helpt u uw schaalbewerkingen nauwkeurig te beheren voor meerdere workloads en subsets van workloads. 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-facilitering
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 bij Uw Azure IoT Hub automatisch schalen. U kunt hulpprogramma's zoals KEDA gebruiken voor automatisch schalen op basis van gebeurtenissen. Deze is beschikbaar 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 metrische runtimegegevens, zoals CPU- of geheugengebruik. Raadpleeg de Handleiding voor Azure Monitor voor aanbevolen procedures.
Compromissen
Overwegingen voor automatisch schalen
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 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. 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. Automatisch schalen kan meer exemplaren van een service starten naarmate de wachtrijlengte 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. Zonder zorg kan een dergelijke taak voorkomen dat een exemplaar van een proces schoon wordt afgesloten wanneer het systeem wordt ingeschaald. Het kan ook gegevens verliezen 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 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 het proces op deze manier wordt afgesloten, kan het werk dat het proces heeft uitgevoerd, worden hervat vanaf het laatste controlepunt door 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 toepassing in de cloudservices, moet u mogelijk verschillende onderdelen van de toepassing schalen met behulp van verschillende schaalbeleidsregels. U moet bijvoorbeeld extra rekenprocessen (UI) implementeren zonder het aantal achtergrondrekenexemplaren te verhogen of omgekeerd. Als u verschillende serviceniveaus aanbiedt, zoals basic- en premium-servicepakketten, moet u mogelijk de rekenresources uitschalen voor Premium-servicepakketten die agressiever zijn dan voor basisservicepakketten om te voldoen aan serviceovereenkomsten (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 te beperken. Zie het patroon Beperking voor meer informatie.
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 gepland beleid gebruiken op basis waarvan voldoende exemplaren worden gestart om de maximum belasting te verwerken, voordat deze belasting daadwerkelijk 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, 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 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.
Opmerking
Raadpleeg de richtlijnen voor het schalen van de AKS-basislijnarchitectuur.
Verwante koppelingen
Controlelijst voor betrouwbaarheid
Raadpleeg de volledige set aanbevelingen.