Dela via

Rekommendationer för att utforma en tillförlitlig skalningsstrategi

  • Artikel

Gäller för denna checklista för Azure Well-Architected Framework Reliability:

RE:06 Implementera en tidsenlig och tillförlitlig skalningsstrategi på program-, data- och infrastrukturnivå.

Relaterad guide: Datapartitionering

Den här guiden beskriver rekommendationerna för att utforma en tillförlitlig skalningsstrategi.

Definitioner

Period Definition
Vertikal skalning En skalningsmetod som lägger till beräkningskapacitet till befintliga resurser.
Horisontell skalning En skalningsmetod som lägger till instanser av en viss typ av resurs.
Automatisk skalning En skalningsmetod som automatiskt lägger till eller tar bort resurser när en uppsättning villkor uppfylls.

Kommentar

Skalningsåtgärder kan vara statiska (regelbundet schemalagd daglig skalning för att hantera normala belastningsmönster), automatisk (en automatiserad process som svar på villkor som uppfylls) eller manuell (en operatör utför en engångsskalningsåtgärd som en reaktion på en oväntad belastningsändring). Både lodrät och vågrät skalning kan utföras via någon av dessa metoder. Automatisk vertikal skalning kräver dock ytterligare anpassad automatiseringsutveckling och kan orsaka stilleståndstid beroende på vilka resurser som skalas.

Viktiga designstrategier

Om du vill utforma en tillförlitlig skalningsstrategi för dina arbetsbelastningar fokuserar du på att identifiera belastningsmönster för användar- och systemflöden för varje arbetsbelastning som leder till en skalningsåtgärd. Här är exempel på de olika belastningsmönstren:

  • Statisk: Varje natt vid 23:00 EST är antalet aktiva användare under 100 och processoranvändningen för appservrarna sjunker med 90 % över alla noder.

  • Dynamiskt, regelbundet och förutsägbart: Varje måndag morgon loggar 1 000 anställda i flera regioner in på ERP-systemet.

  • Dynamisk, oregelbunden och förutsägbar: En produktlansering sker den första dagen i månaden och det finns historiska data från tidigare uppskjutningar om hur trafiken ökar i dessa situationer.

  • Dynamisk, oregelbunden och oförutsägbar: En storskalig händelse orsakar en ökning av efterfrågan på en produkt. Till exempel kan företag som tillverkar och säljer avfuktare uppleva en plötslig ökning av trafiken efter en orkan eller annan översvämningshändelse när människor i drabbade områden behöver torka rum i sitt hem.

När du har identifierat dessa typer av belastningsmönster kan du:

  • Identifiera hur belastningsändringen som är associerad med varje mönster påverkar infrastrukturen.

  • Skapa automatisering för att hantera skalningen på ett tillförlitligt sätt.

I föregående exempel kan dina skalningsstrategier vara:

  • Statisk: Du har en schemalagd skalning av dina beräkningsnoder till det minsta antalet (2) mellan 23:00 och 06:00 EST.

  • Dynamisk, vanlig och förutsägbar: Du har en schemalagd utskalning av dina beräkningsnoder till den normala dagliga kapaciteten innan den första regionen börjar arbeta.

  • Dynamisk, oregelbunden och förutsägbar: Du definierar en schemalagd engångsskalning av dina beräknings- och databasinstanser på morgonen för en produktlansering och du skalar ned igen efter en vecka.

  • Dynamisk, oregelbunden och oförutsägbar: Du har definierat tröskelvärden för autoskalning för att ta hänsyn till oplanerade trafiktoppar.

När du utformar skalningsautomatiseringen måste du ta hänsyn till följande problem:

  • Att alla komponenter i din arbetsbelastning ska vara kandidater för skalningsimplementering. I de flesta fall skalas globala tjänster som Microsoft Entra ID automatiskt och transparent till dig och dina kunder. Se till att förstå skalningsfunktionerna för dina nätverksingress- och utgående styrenheter och din belastningsutjämningslösning.

  • De komponenter som inte kan skalas ut. Ett exempel skulle vara stora relationsdatabaser som inte har horisontell partitionering aktiverat och som inte kan omstruktureras utan betydande påverkan. Dokumentera de resursgränser som publicerats av molnleverantören och övervaka resurserna noga. Inkludera dessa specifika resurser i din framtida planering för migrering till skalbara tjänster.

  • Den tid det tar att utföra skalningsåtgärden så att du schemalägger åtgärden korrekt innan den extra belastningen når infrastrukturen. Om en komponent som API Management till exempel tar 45 minuter att skala kan det hjälpa dig att skala tidigare och förbereda för den förväntade ökningen av belastningen genom att justera skalningströskeln till 65 % i stället för 90 %.

  • Relationen mellan flödets komponenter när det gäller skalningsåtgärdernas ordning. Se till att du inte oavsiktligt överbelastar en underordnad komponent genom att först skala en överordnad komponent.

  • Tillståndskänsliga programelement som kan avbrytas av en skalningsåtgärd och alla sessionstillhörigheter (eller sessionspinnehet) som implementeras. Fasthet kan begränsa skalningsförmågan och introducerar enskilda felpunkter.

  • Potentiella flaskhalsar. Utskalning löser inte alla prestandaproblem. Om din serverdelsdatabas till exempel är flaskhalsen hjälper det inte att lägga till fler webbservrar. Identifiera och lösa flaskhalsarna i systemet först innan du bara lägger till fler instanser. Tillståndskänsliga delar i systemet är den mest troliga orsaken till flaskhalsar.

Att följa designmönstret för distributionsstämpel hjälper dig med den övergripande infrastrukturhanteringen. Det är också fördelaktigt att basera skalningsdesignen på stämplar som skalningsenheter. Och det hjälper dig att noggrant kontrollera dina skalningsåtgärder över flera arbetsbelastningar och delmängder av arbetsbelastningar. I stället för att hantera skalningsscheman och tröskelvärden för automatisk skalning för många olika resurser kan du tillämpa en begränsad uppsättning skalningsdefinitioner på en distributionsstämpel och sedan spegla den över stämplar efter behov.

Kompromiss: Att skala upp har kostnadskonsekvenser, så optimera din strategi för att skala ned så snart som möjligt för att hålla kostnaderna under kontroll. Se till att den automatisering du använder för att skala upp också har utlösare för att skala ned.

Azure-underlättande

En funktion för automatisk skalning är tillgänglig i många Azure-tjänster. Med den kan du enkelt konfigurera villkor för att automatiskt skala instanser vågrätt. Vissa tjänster har begränsade eller inga inbyggda funktioner att automatiskt skala in, så se till att dokumentera dessa fall och definiera processer för att hantera inskalning.

Många Azure-tjänster erbjuder API:er som du kan använda för att utforma anpassade automatiska skalningsåtgärder med hjälp av Azure Automation, till exempel kodexemplen i Autoskala din Azure IoT Hub. Du kan använda verktyg som KEDA för händelsedriven autoskalning, som är tillgänglig i Azure Kubernetes Service och Azure Container Apps.

Autoskalning i Azure Monitor innehåller en gemensam uppsättning funktioner för automatisk skalning för Azure Virtual Machine Scale Sets, Azure App Service, Azure Spring Apps med mera. Skalning kan utföras enligt ett schema eller baserat på ett körningsmått, till exempel CPU- eller minnesanvändning. Se Azure Monitor-guiden för bästa praxis.

Avvägningar

Överväganden för automatisk skalning

Automatisk skalning är inte en omedelbar lösning. Det är ingen garanti att systemets prestanda förbättras bara för att fler resurser läggs till för ett system eller för att fler instanser av en process körs. Tänk på följande när du utformar en strategi för automatisk skalning:

Systemet måste utformas för vågrätt skalbarhet. Undvik att göra antaganden om instanstillhörighet. Utforma inte lösningar som kräver att koden alltid körs i en specifik instans av en process. När du skalar en molntjänst eller webbplats vågrätt ska du inte anta att en serie begäranden från samma källa alltid dirigeras till samma instans. Se av samma orsak till att utforma tjänster som tillståndslösa för att undvika att flera begäranden från ett program alltid behöver dirigeras till samma instans av en tjänst. När du utformar en tjänst som läser meddelanden från en kö och bearbetar dem ska du inte göra några antaganden om vilken instans av tjänsten som hanterar ett visst meddelande. Autoskalning kan starta fler instanser av en tjänst när kölängden växer. Mönstret Konkurrerande konsumenter beskriver hur du hanterar det här scenariot.

Om lösningen implementerar en tidskrävande uppgift, ska du utforma den här uppgiften så att både skalning ut och in stöds. Utan vederbörlig försiktighet kan en sådan uppgift förhindra att en instans av en process stängs av rent när systemet skalar in. Eller så kan den förlora data om processen avslutas med två skäl. Vi rekommenderar att du omstrukturerar en tidskrävande uppgift och delar upp processen som den utför i mindre, diskreta segment. Mönstret Rör och filter är ett exempel på hur du kan uppnå den här lösningen.

Du kan också implementera en kontrollpunktsmekanism som registrerar tillståndsinformation om uppgiften med jämna mellanrum. Du kan sedan spara det här tillståndet i varaktig lagring som kan nås av alla instanser av processen som kör uppgiften. På så sätt kan det arbete som den utförde återupptas från den senaste kontrollpunkten av en annan instans om processen stängs av. Det finns bibliotek som tillhandahåller den här funktionen, till exempel NServiceBus och MassTransit. De bevarar transparent tillstånd, där intervallen är anpassade till bearbetningen av meddelanden från köer i Azure Service Bus.

När bakgrundsuppgifter körs på separata beräkningsinstanser, till exempel i arbetsroller i ett molntjänstbaserat program, kan du behöva skala olika delar av programmet med hjälp av olika skalningsprinciper. Du kan till exempel behöva distribuera extra beräkningsinstanser för användargränssnittet (UI) utan att öka antalet instanser av bakgrundsberäkning eller vice versa. Om du erbjuder olika tjänstnivåer, till exempel grundläggande och premiumtjänstpaket, kan du behöva skala ut beräkningsresurserna för premiumtjänstpaket mer aggressivt än för grundläggande servicepaket för att uppfylla serviceavtal (SLA).

Överväg längden på kön som gränssnitts- och bakgrundsberäkningsinstanser kommunicerar med. Använd det som ett kriterium för din strategi för automatisk skalning. Det här problemet är en möjlig indikator på en obalans eller skillnad mellan den aktuella belastningen och bearbetningskapaciteten för bakgrundsaktiviteten. Ett något mer komplext men bättre attribut för att basera skalningsbeslut på är att använda tiden mellan när ett meddelande skickades och när bearbetningen slutfördes. Det här intervallet kallas för den kritiska tiden. Om det här kritiska tidsvärdet ligger under ett meningsfullt affärströskelvärde är det onödigt att skala, även om kölängden är lång.

Det kan till exempel finnas 50 000 meddelanden i en kö. Men den kritiska tiden för det äldsta meddelandet är 500 ms, och slutpunkten hanterar integrering med en webbtjänst från tredje part för att skicka ut e-postmeddelanden. Affärsintressenter skulle sannolikt anse att det är en tidsperiod som inte skulle motivera att spendera extra pengar för skalning.

Å andra sidan kan det finnas 500 meddelanden i en kö, med samma kritiska tid på 500 ms, men slutpunkten är en del av den kritiska vägen i ett onlinespel i realtid där affärsintressenter definierade en svarstid på 100 ms eller mindre. I så fall skulle utskalning vara meningsfullt.

Om du vill använda kritisk tid i beslut om automatisk skalning är det bra att ett bibliotek automatiskt lägger till relevant information i meddelandehuvudena när de skickas och bearbetas. Ett bibliotek som tillhandahåller den här funktionen är NServiceBus.

Om du baserar din strategi för automatisk skalning på räknare som mäter affärsprocesser, till exempel antalet beställningar per timme eller den genomsnittliga körningstiden för en komplex transaktion, ser du till att du till fullo förstår relationen mellan resultaten från dessa typer av räknare och de faktiska beräkningskapacitetskraven. Det kan vara nödvändigt att skala mer än en komponent eller beräkningsenhet som svar på ändringar i affärsprocessräknare.

Om du vill förhindra att ett system försöker skala ut för mycket och undvika kostnaderna för att köra tusentals instanser bör du överväga att begränsa det maximala antalet instanser som läggs till automatiskt. Med de flesta mekanismer för automatisk skalning kan du ange det lägsta och högsta antalet instanser för en regel. Överväg dessutom att på ett smidigt sätt nedgradera de funktioner som systemet tillhandahåller om det maximala antalet instanser har distribuerats och systemet fortfarande är överbelastat.

Tänk på att autoskalning kanske inte är den lämpligaste mekanismen för att hantera en plötslig burst i en arbetsbelastning. Det tar tid att etablera och starta nya instanser av en tjänst eller lägga till resurser i ett system, och den högsta efterfrågan kan passera när dessa extra resurser är tillgängliga. I det här scenariot kan det vara bättre att begränsa tjänsten. Mer information finns i begränsningsmönstret.

Om du däremot behöver kapaciteten för att bearbeta alla begäranden när volymen fluktuerar snabbt och kostnaden inte är en viktig bidragande faktor kan du överväga att använda en aggressiv strategi för automatisk skalning som startar fler instanser snabbare. Du kan även använda en schemalagd princip som startar ett tillräckligt antal instanser för att uppfylla den största belastningen innan den belastningen förväntas.

Mekanismen för automatisk skalning bör övervaka autoskalningsprocessen och logga information om varje autoskalningshändelse (vad som utlöste den, vilka resurser som lades till eller togs bort och när). Om du skapar en anpassad metod för automatisk skalning ser du till att den innehåller den här funktionen. Analysera informationen för att mäta effektiviteten hos strategin för automatisk skalning och finjustera den vid behov. Du kan finjustera både på kort sikt, när användningsmönstret blir tydligare, och på lång sikt, när företaget expanderar eller kraven för programmet utvecklas. Om ett program når den övre gränsen som definierats för automatisk skalning kan mekanismen också varna en operatör som kan starta fler resurser manuellt om det behövs. Under dessa omständigheter kan operatören också ansvara för att manuellt ta bort dessa resurser när arbetsbelastningen har minskat.

Exempel

Se skalningsvägledningen för AKS-baslinjereferensarkitektur.

Checklista för tillförlitlighet

Se den fullständiga uppsättningen rekommendationer.

Checklista för tillförlitlighet