Aanbevelingen voor het ontwerpen van een betrouwbare schaalstrategie

  • Artikel

Van toepassing op deze aanbeveling voor de betrouwbaarheidschecklist van Azure Well-Architected Framework:

RE:06 Implementeer een tijdige en betrouwbare schaalstrategie op toepassings-, gegevens- en infrastructuurniveau.

Gerelateerde 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 instanties 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 om normale belastingspatronen mogelijk te maken), 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. Automatisch verticaal schalen vereist echter extra aangepaste automatiseringsontwikkeling en kan downtime veroorzaken, afhankelijk van de resources die worden geschaald.

Belangrijke ontwerpstrategieën

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

  • Statisch: elke nacht om 23:00 uur EST is het aantal actieve gebruikers lager dan 100 en het CPU-gebruik voor de app-servers daalt met 90% op alle knooppunten.

  • Dynamisch, regelmatig en voorspelbaar: elke maandagochtend melden 1000 werknemers in meerdere regio's 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 ontvochtigers produceren en verkopen, kunnen bijvoorbeeld een plotselinge piek in het verkeer ervaren na een orkaan of een andere overstroming, wanneer mensen in getroffen gebieden kamers in hun huis moeten drogen.

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

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

  • Bouw automatisering om het schalen betrouwbaar aan te pakken.

In de vorige voorbeelden kunnen uw schaalstrategieën zijn:

  • Statisch: u hebt een geplande schaal van uw rekenknooppunten tot het minimumaantal (2) tussen 23:00 en 06:00 uur EST.

  • Dynamisch, regelmatig en voorspelbaar: u hebt een geplande schaal 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 een week weer omlaag.

  • Dynamisch, onregelmatig en onvoorspelbaar: u hebt drempelwaarden voor automatische schaalaanpassing gedefinieerd om rekening te houden met niet-geplande verkeerspieken.

Houd bij het ontwerpen van uw schaalautomatisering rekening met de volgende problemen:

  • Dat alle onderdelen van uw workload geschikt moeten zijn voor het schalen van implementatie. In de meeste gevallen worden globale services zoals Microsoft Entra id automatisch en transparant geschaald voor u en uw klanten. Zorg ervoor dat u de schaalmogelijkheden van uw netwerkcontrollers voor inkomend en uitgaand verkeer en uw taakverdelingsoplossing begrijpt.

  • De 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 een onderdeel zoals API Management bijvoorbeeld 45 minuten nodig heeft om te schalen, kan het aanpassen van de schaaldrempelwaarde naar 65% in plaats van 90% u helpen om eerder te schalen en u voor te bereiden op de verwachte toename van de belasting.

  • De relatie van de onderdelen van de stroom in de 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 sessie-stickiness) die is geïmplementeerd. Plakkerigheid kan uw schaalmogelijkheden beperken en introduceert Single Points of Failure.

  • Mogelijke knelpunten. Uitschalen lost niet elk prestatieprobleem op. Als uw back-enddatabase bijvoorbeeld het knelpunt is, helpt het niet om meer webservers toe te voegen. Identificeer en los eerst de knelpunten in het systeem op voordat u alleen maar meer exemplaren toevoegt. Knelpunten worden meestal veroorzaakt door stateful onderdelen van het systeem.

Het volgen van het ontwerppatroon voor implementatiestempels helpt bij uw algehele infrastructuurbeheer. Het is ook handig om uw schaalontwerp te baseren op stempels als schaaleenheden. En het helpt u om uw schaalbewerkingen voor meerdere workloads en subsets van workloads strikt te beheren. 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 zegels.

Afweging: 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

Een functie voor automatisch schalen is 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. Zorg er dus voor dat u deze gevallen documenteer en processen definieert om in te schalen.

Veel Azure-services bieden API's die u kunt gebruiken om aangepaste automatische schaalbewerkingen 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 metrische runtime-waarde, zoals CPU- of geheugengebruik. Zie de Handleiding voor Azure Monitor voor best practices.

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 veronderstellingen over exemplaaraffiniteit. Ontwerp geen oplossingen waarvoor de code altijd moet worden uitgevoerd in een specifiek exemplaar van een proces. Wanneer u een cloudservice of website horizontaal schaalt, moet u er niet vanuit gaan dat een reeks aanvragen van dezelfde bron altijd naar hetzelfde exemplaar wordt doorgestuurd. 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. Het patroon Concurrerende consumenten beschrijft hoe dit scenario moet worden verwerkt.

Als met de oplossing een langlopende taak wordt geïmplementeerd, ontwerpt u deze taak zo dat zowel uit- als inschalen wordt ondersteund. Zonder de juiste zorg kan een dergelijke taak voorkomen dat een exemplaar van een proces netjes wordt afgesloten wanneer het systeem wordt ingeschaald. Of het kan 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 and Filters biedt 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. Op deze manier kan, als het proces wordt afgesloten, het werk dat het uitvoerde, worden hervat vanaf het laatste controlepunt door een ander exemplaar. Er zijn bibliotheken die deze functionaliteit bieden, zoals NServiceBus en MassTransit. Ze behouden transparant de status, 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 cloudservice-gehoste toepassing, moet u mogelijk verschillende onderdelen van de toepassing schalen met behulp van ander schaalbeleid. Mogelijk moet u bijvoorbeeld extra rekeninstanties van de gebruikersinterface (UI) implementeren zonder het aantal rekenprocessen op de achtergrond te verhogen, of omgekeerd. Als u verschillende serviceniveaus aanbiedt, zoals Basis- en Premium-servicepakketten, moet u de rekenresources voor Premium-servicepakketten mogelijk agressiever uitschalen dan voor basisservicepakketten om te voldoen aan serviceovereenkomsten (SLA's).

Houd rekening met de lengte van de wachtrij waarover ui en rekenprocessen op de achtergrond 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 u schaalbeslissingen kunt baseren, 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 tijdswaarde onder een zinvolle zakelijke drempelwaarde ligt, is het niet nodig om te schalen, zelfs als de wachtrijlengte 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 zullen dit waarschijnlijk beschouwen als een periode die niet rechtvaardigt om extra geld uit te geven voor schalen.

Aan de andere kant kunnen er 500 berichten in een wachtrij staan, met dezelfde kritieke tijd van 500 ms, maar het eindpunt maakt deel uit van het kritieke pad in een realtime onlinespel waarin 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 automatische schaalaanpassingsbeslissingen, is het handig om een bibliotheek automatisch de relevante informatie toe te voegen aan de kopteksten van berichten terwijl deze worden verzonden en verwerkt. Een bibliotheek die deze functionaliteit biedt, is NServiceBus.

Als u uw strategie voor automatisch schalen baseert op tellers die bedrijfsprocessen meten, zoals het aantal geplaatste orders per uur of de gemiddelde duur van een complexe transactie, moet u ervoor zorgen dat u de relatie tussen de resultaten van dit type 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 overmatig probeert uit te schalen en de kosten voor het uitvoeren van vele duizenden exemplaren wilt voorkomen, kunt u overwegen om het maximum aantal exemplaren dat automatisch wordt toegevoegd, te beperken. Met de meeste mechanismen voor automatisch schalen kunt u het minimum- en maximum aantal exemplaren voor een regel opgeven. Daarnaast kunt u overwegen om de functionaliteit die het systeem biedt, probleemloos 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 om een plotselinge burst in een workload af te handelen. Het kost tijd om nieuwe exemplaren van een service in te richten en te starten of resources aan een systeem toe te voegen. De piekvraag kan voorbij zijn op het moment dat deze extra resources beschikbaar zijn. In dit scenario is het misschien beter om de service te beperken. Zie het beperkingspatroon 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 factor zijn, kunt u overwegen om 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 deze 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 kan de operator ook verantwoordelijk zijn voor het handmatig verwijderen van deze resources nadat de werkbelasting is afgelast.

Voorbeeld

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

Controlelijst voor betrouwbaarheid

Raadpleeg de volledige set aanbevelingen.

Controlelijst voor betrouwbaarheid