Dela via

Automatisk skalning

  • Artikel

Automatisk skalning är processen för att dynamiskt tilldela resurser för att matcha prestandakrav. När mängden arbete växer kan ett program behöva ytterligare resurser för att underhålla de önskade prestandanivåerna och uppfylla servicenivåavtal (SLA). Eftersom efterfrågan minskar och de extra resurserna inte längre behövs kan de avallokeras för att minimera kostnaderna.

Automatisk skalning använder elasticiteten hos molndrivna miljöer och kräver lägre arbetsinsats för hantering. Det minskar behovet av att en operatör regelbundet övervakar systemets prestanda och tar beslut om att lägga till eller ta bort resurser.

Det finns två sätt som ett program kan skalas på:

  • Vertikal skalning, även kallad upp- och nedskalning, innebär att ändra kapaciteten för en resurs. Du kan till exempel flytta ett program till en större storlek på den virtuella datorn. Vertikal skalning kräver ofta att systemet blir tillfälligt otillgängligt när det distribueras om. Därför är det mindre vanligt att automatisera vertikal skalning.

  • Horisontell skalning, även kallad utskalning och inskalning, innebär att lägga till eller ta bort instanser av en resurs. Programmet fortsätter köras utan avbrott medan nya resurser etableras. När etableringsprocessen är klar distribueras lösningen på dessa extra resurser. Om efterfrågan minskar kan de extra resurserna stängas av rent och frigöras.

Många molnbaserade system, inklusive Microsoft Azure, stöder automatisk horisontell skalning. Resten av den här artikeln fokuserar på horisontell skalning.

Anmärkning

Autoskalning gäller främst för beräkningsresurser. Även om det är möjligt att horisontellt skala en databas eller meddelandekö, innebär den här processen vanligtvis datapartitionering, vilket vanligtvis inte är automatiserat.

Komponenter för automatisk skalning

En strategi för automatisk skalning omfattar vanligtvis följande komponenter:

  • Instrumenterings- och övervakningssystem på program-, tjänst- och infrastrukturnivå. Dessa system samlar in viktiga mått, till exempel svarstider, kölängder, CPU-användning och minnesanvändning.

  • Beslutslogik utvärderar dessa liveanvändningsmått mot fördefinierade tröskelvärden eller scheman och avgör om de ska skalas.

  • Komponenter och mekanismer utför skalningsåtgärden. Helst bör dessa komponenter och mekanismer frikopplas från själva arbetsbelastningskoden och hanteras som en extern process. Kod som är inaktiv eller överbelastad bör inte vara ansvarig för att skala sig själv.

  • Test-, övervaknings- och justeringsfunktioner för strategin för automatisk skalning för att säkerställa att den fungerar som förväntat.

Azure tillhandahåller inbyggda mekanismer för automatisk skalning som hanterar vanliga scenarier. Om en viss tjänst eller teknik inte har inbyggda funktioner för automatisk skalning eller om du har specifika krav på automatisk skalning utöver dess funktioner bör du överväga en anpassad implementering. En anpassad implementering samlar in drifts- och systemmått, analyserar måtten och skalar resurser därefter.

Konfigurera automatisk skalning för en Azure-lösning

Azure tillhandahåller inbyggd automatisk skalning för de flesta beräkningsalternativ.

De här beräkningsalternativen använder alla autoskalningsfunktionen i Azure Monitor för att tillhandahålla en gemensam uppsättning funktioner för automatisk skalning.

  • Azure Functions skiljer sig från tidigare beräkningsalternativ eftersom du inte behöver konfigurera några regler för autoskalning. I stället allokerar Azure Functions automatiskt beräkningskraft när koden körs. Azure Functions skalas ut efter behov för att hantera belastningen. Mer information finns i Välj rätt värdplan för Azure Functions.

En anpassad autoskalningslösning kan ibland vara användbar. Du kan till exempel använda Azure Diagnostics och programbaserade mått, tillsammans med anpassad kod för att övervaka och exportera programmåtten. Sedan kan du definiera anpassade regler baserat på dessa mått och använda Rest-API:er för Azure Resource Manager för att utlösa automatisk skalning. En anpassad lösning är dock inte enkel att implementera och bör endast övervägas om ingen av de tidigare metoderna kan uppfylla dina krav.

Använd de inbyggda funktionerna för automatisk skalning på plattformen om de uppfyller dina krav. Om inte bör du noga överväga om du behöver mer komplexa skalningsfunktioner. Exempel på andra krav kan vara mer detaljerad kontroll, olika sätt att identifiera utlösarhändelser för skalning, skalning mellan prenumerationer och skalning av andra typer av resurser.

Använda autoskalningsfunktionen i Azure Monitor

Autoskalningsfunktionen i Azure Monitor innehåller en gemensam uppsättning funktioner för automatisk skalning för vm-skalningsuppsättningar, App Service och Azure Cloud Services. Skalning kan utföras enligt ett schema eller baserat på ett körningsmått, till exempel CPU- eller minnesanvändning.

Tänk på följande exempel:

  • Skala ut till 10 instanser på vardagar och skala in till fyra instanser på lördag och söndag.

  • Skala ut med en instans om den genomsnittliga CPU-användningen är över 70%och skala in med en instans om CPU-användningen understiger 50%.

  • Skala ut med en instans om antalet meddelanden i en kö överskrider ett visst tröskelvärde.

Skala upp resursen när belastningen ökar för att säkerställa tillgängligheten. Vid tider med låg användning skalar du ned så att du kan optimera kostnaden. Använd alltid en kombination av utskalnings- och inskalningsregel. Annars sker autoskalningen endast i en riktning tills den når tröskelvärdet (högsta eller minsta antal instanser) som anges i profilen.

Välj ett standardinstansantal som är säkert för din arbetsbelastning. Resursen skalar baserat på det värdet om maximalt eller minsta antal instanser inte har angetts.

En lista över inbyggda mått finns i Vanliga mått för automatisk skalning i Azure Monitor. Du kan också implementera anpassade mått med hjälp av Application Insights.

Du kan konfigurera automatisk skalning med hjälp av PowerShell, Azure CLI, en Azure Resource Manager-mall eller Azure-portalen. Mer detaljerad kontroll finns i Resource Manager REST API. Azure Monitoring Management Library och Microsoft Insights-biblioteket (i förhandsversion) är SDK:er som gör det möjligt att samla in mått från olika resurser och utföra autoskalning genom att använda REST-API:erna. För resurser där Resource Manager-stöd inte är tillgängligt, eller om du använder Azure Cloud Services, kan SERVICE Management REST API användas för automatisk skalning. I alla andra fall använder du Resource Manager.

Tänk på följande när du använder autoskalning:

  • Fundera på om du kan förutsäga belastningen på programmet tillräckligt korrekt för att använda schemalagd autoskalning, lägga till och ta bort instanser för att möta förväntade toppar i efterfrågan. Om du inte kan kan du använda automatisk skalning baserat på reaktiva åtgärder och driftvärden för att hantera oförutsägbara förändringar i efterfrågan. Vanligtvis kan du kombinera dessa metoder.

    Skapa till exempel en strategi som lägger till resurser baserat på ett schema över de tider då du vet att programmet är som mest upptaget. Extra resurser hjälper till att säkerställa att kapaciteten är tillgänglig när det behövs, utan fördröjning vid start av nya instanser. För varje schemalagd regel definierar du mått som tillåter reaktiv autoskalning under den perioden för att säkerställa att programmet kan hantera varaktiga men oförutsägbara toppar i efterfrågan.

  • Det är ofta svårt att förstå relationen mellan mått och kapacitetskrav, särskilt när ett program först distribueras. Konfigurera lite extra kapacitet i början och övervaka och justera sedan reglerna för automatisk skalning för att föra kapaciteten närmare den faktiska belastningen.

  • Konfigurera reglerna för automatisk skalning och övervaka sedan programmets prestanda över tid. Använd resultatet av den här övervakningen för att justera hur systemet skalar om det behövs. Tänk dock på att autoskalningsprocessen inte är omedelbar. Det tar tid att reagera på ett mått som genomsnittlig cpu-användning som överskrider eller understiger ett angivet tröskelvärde.

  • Regler för automatisk skalning som använder en identifieringsmekanism baserat på ett uppmätt utlösarattribut använder ett aggregerat värde över tid, i stället för omedelbara värden, för att utlösa en autoskalningsåtgärd. Utlösarattribut inkluderar CPU-användning eller kölängd. Som standard är aggregeringen ett medelvärde av värdena. Den här metoden förhindrar att systemet reagerar för snabbt eller orsakar snabb svängning. Det ger också tid för nya instanser som startas automatiskt att stabilisera sig i körningsläge. Andra autoskalningsåtgärder kan inte ske medan de nya instanserna startar upp. För Azure Cloud Services och Azure Virtual Machines är standardperioden för aggregeringen 45 minuter. Det kan därför ta upp till den angivna tidsperioden innan måttet utlöser autoskalning som svar på toppar i efterfrågan. Du kan ändra aggregeringsperioden med hjälp av SDK, men perioder på mindre än 25 minuter kan orsaka oförutsägbara resultat. För funktionen Web Apps i App Service är genomsnittsperioden kortare, vilket gör att nya instanser kan vara tillgängliga om cirka fem minuter efter en ändring av det genomsnittliga utlösarmåttet.

  • Undvik att flaxa där in- och utskalningsåtgärder kontinuerligt går fram och tillbaka. Anta att det finns två fall. Den övre gränsen är 80% CPU och den nedre gränsen är 60%. När belastningen är på 85%läggs en annan instans till. Efter en tid minskar belastningen till 60%. Innan autoskalningstjänsten skalar in beräknas fördelningen av den totala belastningen (av tre instanser) när en instans tas bort, vilket tar den till 90%. Det skulle behöva skalas ut igen omedelbart. Därför hoppar den över att skala in och du kanske aldrig ser de förväntade skalningsresultaten.

    Den flaxande situationen kan styras genom att välja en tillräcklig marginal mellan tröskelvärdena för utskalning och inskalning.

  • Manuell skalning återställs baserat på det maximala och minsta antalet instanser som används för automatisk skalning. Om du manuellt uppdaterar antalet instanser till ett värde som är högre eller lägre än det maximala värdet skalar autoskalningsmotorn automatiskt tillbaka till det lägsta (om det är lägre) eller det högsta (om det är högre). Du kan till exempel ange intervallet mellan tre och sex. Om du har en körande instans skalar autoskalningsmotorn till tre instanser när nästa körning sker. På samma sätt, om du manuellt ställer in antalet instanser till åtta, skalar autoscale tillbaka till sex instanser när den körs nästa gång. Manuell skalning är tillfällig om du inte även återställer reglerna för autoskalning.

  • Autoskalningsmotorn bearbetar bara en profil i taget. Om ett villkor inte uppfylls söker det efter nästa profil. Håll nyckelmåtten borta från standardprofilen eftersom den profilen kontrolleras sist. I en profil kan du ha flera regler. När det gäller utskalning körs autoskalning om någon regel uppfylls. Vid inskalning kräver autoskalning att alla regler uppfylls.

    Mer information om hur Azure Monitor skalar finns i Metodtips för autoskalning.

  • Om du konfigurerar automatisk skalning med hjälp av SDK:et i stället för portalen kan du ange ett mer detaljerat schema under vilket reglerna är aktiva. Du kan också skapa egna mått och använda dem med eller utan några av de befintliga i dina regler för automatisk skalning. Du kanske till exempel vill använda alternativa räknare, till exempel antalet begäranden per sekund eller den genomsnittliga minnestillgängligheten. Eller så kan du använda anpassade räknare för att mäta specifika affärsprocesser.

  • När du autoskalar Service Fabric består nodtyperna i klustret av vm-skalningsuppsättningar i serverdelen, så du måste konfigurera regler för autoskalning för varje nodtyp. Ta hänsyn till antalet noder som du måste ha innan du konfigurerar automatisk skalning. Din tillförlitlighetsnivå styr det minsta antalet noder som du måste ha för den primära nodtypen. För mer information, se Skala ett Service Fabric-kluster in eller ut med hjälp av autoskalningsregler.

  • Du kan använda portalen för att länka resurser som Azure SQL Database-instanser och köer till en molntjänstinstans. Med den här metoden kan du enklare komma åt konfigurationsalternativen för separat manuell och automatisk skalning för var och en av de länkade resurserna. Mer information finns i Hantera Azure Cloud Services.

  • När du konfigurerar flera principer och regler kan de vara i konflikt med varandra. Autoscale använder följande konfliktlösningsregler för att säkerställa att det alltid finns ett tillräckligt antal instanser som körs:

    • Utskalningsåtgärder har alltid företräde framför inskalningsåtgärder.

    • När utskalningsåtgärder står i konflikt har regeln som initierar den största ökningen av antalet instanser företräde.

    • När inskalningsåtgärder står i konflikt har regeln som initierar den minsta minskningen av antalet instanser företräde.

  • I en App Service-miljö kan alla arbetspooler eller frontend-mått användas för att definiera regler för autoskalning. Mer information finns i Översikt över App Service Environment.

Överväganden för programdesign

Automatisk skalning är inte en omedelbar lösning. Att bara lägga till resurser i ett system eller köra fler instanser av en process garanterar inte att systemets prestanda förbättras. Tänk på följande när du utformar en strategi för automatisk skalning:

  • Systemet måste vara utformat för att vara horisontellt skalbart. 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. Av samma anledning utformar du tjänster som tillståndslösa för att undvika att kräva att en serie begäranden från ett program alltid 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 specifikt 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 utformar du den här uppgiften så att den stöder både utskalning och inskalning. Utan korrekt design kan en sådan uppgift förhindra att en instans av en process stängs av ordentligt när systemet växer. Det kan också förlora data om processen tvångsavslutas. Vi rekommenderar att du omstrukturerar en tidskrävande uppgift och delar upp bearbetningen som den utför i mindre, diskreta segment. Ett exempel finns i Mönster för rör och filter.

  • Du kan också implementera en kontrollpunktsmekanism som registrerar tillståndsinformation om uppgiften med jämna mellanrum. Spara den här tillståndsinformationen i varaktig lagring som alla instanser av processen som kör uppgiften kan komma åt. Så om processen stängs av kan det arbete som den utförde återupptas från den senaste kontrollpunkten med hjälp av en annan instans. Det finns bibliotek som tillhandahåller den här funktionen, till exempel NServiceBus och MassTransit. De upprätthåller transparent status där intervallen är synkroniserade med 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 fler beräkningsinstanser för användargränssnitt (UI) utan att öka antalet instanser av bakgrundsberäkning eller motsatsen. Du kan erbjuda olika servicenivåer, till exempel grundläggande och premiumtjänstpaket. Du kan behöva skala ut beräkningsresurserna för Premium Service-paket mer aggressivt än resurser för grundläggande tjänstpaket. Den här metoden hjälper dig att uppfylla serviceavtal.

Andra skalningsvillkor

  • Överväg längden på kön som UI- och bakgrundsberäkningsinstanser använder för att kommunicera. Använd det som ett kriterium för din strategi för automatisk skalning. Det här villkoret kan tyda på en obalans eller skillnad mellan den aktuella belastningen och bearbetningskapaciteten för bakgrundsaktiviteten. Det finns ett något mer komplext men bättre attribut att basera skalningsbeslut på. Använd tiden mellan när ett meddelande skickades och när bearbetningen var klar, så kallad kritisk tid. 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 den slutpunkten hanterar integrering med en partnerwebbtjänst för att skicka ut e-postmeddelanden. Affärsintressenter kanske inte anser att det här scenariot är tillräckligt brådskande för att motivera kostnaden för utskalning.

    • Å 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 är det vettigt att skala ut.

    • För att kunna använda kritisk tid i beslut om automatisk skalning är det bra att ett bibliotek automatiskt lägger till relevant information i meddelandehuvudena under överföring och bearbetning. Ett sådant 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 ser du till att du förstår relationen mellan resultaten från dessa typer av räknare och de faktiska beräkningskapacitetskraven. Exempel på räknare är antalet beställningar som görs varje timme eller den genomsnittliga körtiden för en komplex transaktion. 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 bör du överväga att begränsa det maximala antalet instanser som kan läggas till automatiskt. Den här metoden undviker även kostnaderna som är kopplade till att köra tusentals instanser. 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 du distribuerar det maximala antalet instanser och systemet fortfarande är överbelastat.

  • Tänk på att autoskalning kanske inte är den mest lämpliga mekanismen för att hantera en plötslig ökning av arbetsbelastningen. Det tar tid att konfigurera 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 strypa tjänsten. Mer information finns i Begränsningsmönster.

  • Om du däremot behöver kapaciteten för att bearbeta alla begäranden när volymen varierar snabbt kan du överväga att använda en aggressiv strategi för automatisk skalning som startar extra instanser snabbare. Se till att kostnaden inte är en viktig bidragande faktor. Du kan också använda en schemalagd princip som startar ett tillräckligt antal instanser för att uppfylla den maximala belastningen innan belastningen förväntas.

  • Mekanismen för automatisk skalning bör övervaka autoskalningsprocessen och logga information om varje autoskalningshändelse. Den här informationen omfattar vad som utlöste händelsen, vilka resurser som lades till eller togs bort och när den inträffade. Om du skapar en anpassad mekanism för automatisk skalning kontrollerar du att den innehåller den här funktionen. Analysera informationen för att mäta effektiviteten i strategin för automatisk skalning och justera den om det behövs. Du kan finjustera både på kort sikt, eftersom användningsmönstren blir mer uppenbara och på lång sikt när verksamheten 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 extra 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.

Följande mönster och vägledning kan också vara relevanta för ditt scenario när du implementerar autoskalning:

  • Begränsningsmönstret beskriver hur ett program kan fortsätta att fungera och uppfylla serviceavtal när en ökad efterfrågan lägger en extrem belastning på resurser. Begränsning kan användas med automatisk skalning för att förhindra att ett system överbelastas medan systemet skalas ut.

  • Mönstret Konkurrerande konsumenter beskriver hur du implementerar en pool med tjänstinstanser som kan hantera meddelanden från alla programinstanser. Autoskalning kan användas för att starta och stoppa tjänstinstanser för att matcha den förväntade arbetsbelastningen. Med den här metoden kan ett system bearbeta flera meddelanden samtidigt för att optimera dataflödet, förbättra skalbarheten och tillgängligheten och balansera arbetsbelastningen.

  • Övervakning och diagnostik, inklusive instrumentering och mått, är viktiga för att samla in den information som kan driva autoskalningsprocessen.