Rekommendationer för att utforma en tillförlitlig skalningsstrategi
Gäller för den här rekommendationen om checklista för tillförlitlighet i Azure Well-Architected Framework:
| 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. |
Anteckning
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 reaktion på en oväntad belastningsändring). Både vertikal 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 driftstopp 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 minskar med 90 % över alla noder.
Dynamiskt, regelbundet och förutsägbart: Varje måndag morgon loggar 1 000 anställda över flera regioner in i 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 topp i efterfrågan på en produkt. Företag som tillverkar och säljer avfuktare kan till exempel 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 din infrastruktur.
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 skala 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 beräkningsnoderna 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 din skalningsautomatisering 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 i dina inkommande och utgående nätverksstyrenheter och din belastningsutjämningslösning.
De komponenter som inte kan skalas ut. Ett exempel är 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 de specifika resurserna 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 vara enklare att skala om skalningströskeln till 65 % i stället för 90 % tidigare och förbereda för den förväntade belastningsökningen.
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.
Alla tillståndskänsliga programelement som kan avbrytas av en skalningsåtgärd och eventuell sessionstillhörighet (eller sessionsstinne) som implementeras. Fasthet kan begränsa din skalningsförmåga 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 åtgärda 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ämpeln hjälper dig med den övergripande infrastrukturhanteringen. Det är också bra 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: Uppskalning 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 som du använder för att skala upp också har utlösare för nedskalning.
Azure-underlättande
En funktion för automatisk skalning är tillgänglig i många Azure-tjänster. Det gör att du enkelt kan konfigurera villkor för att automatiskt skala instanser horisontellt. Vissa tjänster har begränsade eller inga inbyggda funktioner för automatisk inskalning, 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 automatisk skalning, som finns 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 horisontellt ska du inte förutsätta 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 korrekt när systemet skalar in. Eller så kan den förlora data om processen med två försök avslutas. 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 beständig lagring som kan nås av alla instanser av processen som kör uppgiften. På så sätt kan arbetet 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 justerade med bearbetningen av meddelanden från köer i Azure Service Bus.
När bakgrundsaktiviteter 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 UI-beräkningsinstanser (användargränssnitt) utan att öka antalet beräkningsinstanser i bakgrunden eller tvärtom. 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 tjänstpaket för att uppfylla serviceavtal (SLA).
Överväg längden på kön som användargränssnittet och beräkningsinstanserna i bakgrunden kommunicerar över. 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 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 e-postmeddelanden. Affärsintressenter skulle sannolikt betrakta det som 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 det vara meningsfullt att skala ut.
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 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 de kostnader som är kopplade till 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 också att på ett smidigt sätt försämra 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 kapacitet för att bearbeta alla begäranden när volymen varierar 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 operatorn också vara ansvarig för att manuellt ta bort dessa resurser när arbetsbelastningen har minskat.
Exempel
Se vägledningen för skalning av AKS-baslinjereferensarkitektur.
Relaterade länkar
Checklista för tillförlitlighet
Se den fullständiga uppsättningen rekommendationer.
Feedback
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i: https://aka.ms/ContentUserFeedback.
Skicka och visa feedback för