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över ytterligare resurser för att underhålla de önskade prestandanivåerna och uppfylla servicenivåavtal (SLA). När behovet sjunker och de ytterligare resurserna inte längre behövs kan de frigöras för att minimera kostnader.

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

  • Lodrät skalning, kallas även för att skala upp och ner, innebär att kapaciteten ändras för en resurs. Du kan t.ex. flytta ett program till en större VM-storlek. Lodrät skalning kräver ofta att systemet tillfälligt är otillgänglig medan det omdistribueras. Därför är det mindre vanligt att automatisera lodrät skalning.

  • Horisontell skalning, kallas även för att skala ut och in, 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 etableringen är klar distribueras lösningen på dessa ytterligare resurser. Om behovet sjunker kan de ytterligare resurserna stängas av smidigt och frigöras.

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

Kommentar

Automatisk skalning används främst för beräkningsresurser. Det är möjligt att horisontellt skala en databas eller meddelandekö. Detta innefattar vanligen datapartitionering, som normalt inte automatiseras.

Komponenter för automatisk skalning

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

  • Instrumentation och övervakningssystem på program-, tjänste- och infrastrukturnivåer. Dessa system samlar in nyckelvärden, till exempel svarstider, kölängder, processoranvändning och minnesanvändning.
  • Beslutsfattande logik som utvärderar de här måtten mot fördefinierade trösklar eller scheman och beslutar om skalning ska användas.
  • Komponenter som skalar systemet.
  • Testning, övervakning och justering av strategin för automatisk skalning säkerställer 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 någon inbyggd funktion för automatisk skalning, eller om du har specifika krav för automatisk skalning utöver dess funktioner, kan du överväga att använda en anpassad implementering. En anpassad implementering skulle samla in statistik för åtgärder och systemet, analysera måtten och sedan skala resurser i enlighet med detta.

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

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

Samtliga dessa beräkningsalternativ använder automatisk skalning genom 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 automatisk skalning. I stället tilldelar Azure Functions automatiskt datorkraft när koden körs och skalar ut enligt behov för att hantera belastningen. Mer information finns i Choose the correct hosting plan for Azure Functions (Välja rätt värdplan för Azure Functions).

Dessutom kan en anpassad lösning för automatisk skalning ibland vara bra. 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 ange anpassade regler baserat på de här måtten och använda Resource Manager REST-API:er 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 uppfyller dina krav.

Använd plattformens inbyggda funktioner för automatisk skalning om de uppfyller dina krav. Om inte, ska du noga överväga om du verkligen behöver mer komplexa funktioner för skalning. Exempel på ytterligare 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 automatisk skalning i Azure Monitor

Azure Monitor autoskalning ger en gemensam uppsättning funktioner för automatisk skalning för vm-skalningsuppsättningar, Azure App Service och Azure Cloud Service. Skalning kan utföras efter ett schema eller baserat på ett mått för körning, t.ex processor- eller minnesanvändning.

Exempel:

  • Skala ut till 10 instanser på vardagar och skala in till 4 instanser på lördagar och söndagar.
  • Skala ut med en instans om den genomsnittliga processoranvändningen är över 70 % och skalan in med en instans om processoranvändningen är lägre än 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. På samma sätt kan du skala ned vid tider med låg användning, så att du kan optimera kostnaderna. 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. Den skalas baserat på det värdet om maximalt eller minsta antal instanser inte har angetts.

En lista över inbyggda mått finns i Azure Monitor autoscaling common metrics (Vanliga mått för automatisk skalning i Azure Monitor). Du kan även implementera anpassade mått med Application Insights.

Du kan konfigurera automatisk skalning med PowerShell, Azure CLI, en Azure Resource Manager-mall eller Azure-portalen. Om du vill ha mer detaljerad kontroll använder du Azure Resource Manager REST API. Azure Monitoring Service Management Library och Microsoft Insights Library (i förhandsversion) är SDK:er som hjälper dig samla in mått från olika resurser, och utföra automatisk skalning genom att använda REST-API:erna. För resurser som saknar stöd för Azure Resource Manager, eller om du använder Azure Cloud Services, kan du använda Service Management REST API användas för automatisk skalning. I alla andra fall använder du Azure Resource Manager.

Tänk på följande när du använder automatisk skalning i Azure:

  • 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 det inte går använder du reaktiv automatisk skalning baserat på körtidsmått för att hantera oväntade förändringar av behov. Normalt 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. Detta gör att kapaciteten är tillgänglig vid behov, utan fördröjning när nya instanser startas. Definiera mått för varje schemalagd regel som tillåter reaktiv automatisk skalning under denna tid så att programmet kan hantera varaktiga men oförutsägbara behovstoppar.

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

  • Konfigurera reglerna för automatisk skalning och övervaka sedan prestanda för ditt program över tid. Använd resultatet av den här övervakningen för att ändra hur systemet skalas vid behov. Kom dock ihåg att automatisk skalning inte är en omedelbar process. Det tar tid att reagera på ett mått, till exempel genomsnittlig processoranvändning som ligger över (eller under) ett angivet tröskelvärde.

  • Regler för automatisk skalning som använder en identifieringsprocess som baseras på ett uppmätt utlösarattribut (till exempel processoranvändning eller kölängd) använder ett sammanställt värde över tid, i stället för omedelbara värden, för att utlösa en automatisk skalningsåtgärd. Som standard är det sammanlagda värdet ett medelvärde av värdena. Detta förhindrar att systemet reagerar för snabbt eller orsakar snabba svängningar. Det ger också tid för nya instanser som startas automatiskt att etablera sig i körningsläge, vilket förhindrar att ytterligare autoskalningsåtgärder inträffar medan de nya instanserna startas. För Azure Cloud Services och Azure Virtual Machines är standardvärdet för sammanställning 45 minuter, så det kan dröja så länge innan måttet utlöser automatisk skalning som svar på ökat behov. Du kan ändra aggregeringsperioden med hjälp av SDK, men perioder på mindre än 25 minuter kan orsaka oförutsägbara resultat. För webbappar är genomsnittsperioden mycket kortare, så att nya instanser kan finnas tillgängliga 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å instanser och den övre gränsen är 80 % CPU, lägre gräns är 60 %. När belastningen är på 85 % läggs en annan instans till. Efter en tid minskar belastningen till 60 %. Innan du skalar in beräknar autoskalningstjänsten fördelningen av den totala belastningen (av tre instanser) när en instans tas bort, vilket tar den till 90 %. Det innebär att den måste skalas ut igen omedelbart. Därför hoppar den över inskalning 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 med maximalt och minsta antal 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 3 och 6. Om du har en instans som körs skalar autoskalningsmotorn till tre instanser vid nästa körning. Om du manuellt anger skalan till åtta instanser skalar autoskalningen vid nästa körning tillbaka till sex instanser vid nästa körning. 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 profilen är markerad sist. I en profil kan du ha flera regler. Vid 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 SDK:et i stället för portalen, kan du ange ett mer detaljerat schema som bestämmer när reglerna är aktiva. Du kan även skapa egna mått och använda dem med eller utan någon av de befintliga reglerna 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 använda anpassade räknare för att mäta specifika affärsprocesser.

  • Vid automatisk skalning av Service Fabric består nodtyperna i klustret av vm-skalningsuppsättningar i serverdelen, så du måste konfigurera autoskalningsregler för varje nodtyp. Ta hänsyn till antalet noder som du måste ha innan du konfigurerar automatisk skalning. Det minsta antalet noder som du måste ha för den primära nodtypen avgörs av tillförlitlighetsnivån som du har valt. Mer information finns i Skala ett Service Fabric-kluster in eller ut med autoskalningsregler.

  • Du kan använda portalen för att länka resurser, till exempel SQL-databasinstanser och köer till en Cloud Service-instans. På så sätt kan du enkelt komma åt de separata konfigurationsalternativen för manuell och automatisk skalning för var och en av de länkade resurserna. Mer information finns i How to: Link a resource to a cloud service (Så här länkar du en resurs till en molntjänst).

  • När du konfigurerar flera principer och regler kan de hamna i konflikt med varandra. Automatisk skalning använder följande regler för konfliktlösning för att kontrollera att det alltid körs ett tillräckligt antal instanser:

    • 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 åtgärder för att skala in orsakar 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 Autoscaling and App Service Environment (Automatisk skalning och App Service-miljö).

Designöverväganden för program

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. Vid vågrätt skalning av en molnbaserad tjänst eller webbplats ska du inte förutsätta att flera begäranden från samma källa alltid kommer att 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. Automatisk skalning kan starta ytterligare 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 korrekt hantering kan en sådan uppgift förhindra att en instans av en process avslutas korrekt när systemet skalas in, eller att data kan förloras om processen avslutas med tvång. 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å detta.

  • Alternativt kan du implementera en kontrollpunktsmekanism som registrerar tillståndsinformation om uppgiften med jämna mellanrum, och spara det här tillståndet i varaktig lagring som kan nås av valfri instans av processen som kör aktiviteten. På så sätt kan arbetet som den utförde återupptas från den senaste kontrollpunkten med hjälp 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 ytterligare beräkningsinstanser för användargränssnitt (UI) utan att öka antalet beräkningsinstanser som körs i bakgrunden, eller motsatsen till detta. Om du tillhandahåller olika tjänstenivåer (till exempel grundläggande paket och premiumpaket) kan du behöva skala ut beräkningsresurserna för premiumpaketet mer aggressivt än för det grundläggande paketet för att uppfylla serviceavtalet.

  • Ö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. Detta är en möjlig indikator 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 inte nödvändigt 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. Det är troligt att affärsintressenter skulle 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.
    • 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 medan de skickas och bearbetas. Ett sådant bibliotek som tillhandahåller den här funktionen är NServiceBus.

  • Se till att du förstår relationen mellan resultaten från dessa typer av räknare och faktiska kapacitetskrav för beräkning om du baserar din strategi för automatisk skalning på räknare som mäter affärsprocesser, till exempel antal beställningar per timme eller genomsnittlig körningstid för en komplex transaktion. Det kan vara nödvändigt att skala fler än en komponent eller beräkningsenhet som svar på ändringar av affärsprocessräknare.

  • Överväg att begränsa det maximala antalet instanser som kan läggas till automatiskt för att förhindra att ett system försöker skala ut på ett överdrivet sätt och för att undvika kostnader som kopplas till att tusentals instanser körs. För de flesta metoder för automatisk skalning kan du ange lägsta och högsta antal instanser för en regel. Dessutom bör du på ett bra sätt dra ner på funktionerna som systemet tillhandahåller om det maximala antalet instanser har distribuerats och systemet fortfarande är överbelastat.

  • Tänk på att automatisk skalning kanske inte är den lämpligaste metoden för att hantera en plötslig ökning av arbetsbelastning. Det tar tid att etablera och starta nya instanser av en tjänst eller lägga till resurser i ett system, och behovstoppen kan ha passerats när dessa ytterligare resurser har gjorts 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 behöver kapacitet för att bearbeta alla begäranden när volymen varierar snabbt, och kostnaden inte är en viktig faktor, kan du överväga att använda en aggressiv strategi för automatisk skalning som startar ytterligare 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.

  • Metoden för automatisk skalning bör övervaka processen för automatisk skalning och logga information om varje automatisk skalningshändelse (vad som utlöste den, vilka resurser som lades till eller togs bort, samt 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 metoden även meddela en operatör som manuellt kan starta ytterligare resurser vid behov. Observera att operatorn under dessa omständigheter också kan vara ansvarig 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:

  • Mönster för begränsning. Det här mönstret beskriver hur ett program kan fortsätta fungera och uppfylla serviceavtal när ökade behov innebär 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önster för konkurrerande förbrukare. Det här mönstret beskriver hur du implementerar en pool med tjänsteinstanser som kan hantera meddelanden från en programinstans. Automatisk skalning kan användas för att starta och stoppa tjänsteinstanser så att den förväntade arbetsbelastningen matchas. Det här metoden gör det möjligt för ett system att bearbeta flera meddelanden samtidigt för att optimera genomflödet, förbättra skalbarheten och tillgängligheten och för att balansera arbetsbelastningen.

  • Övervakning och diagnostik. Instrumentation och telemetridata är viktiga för att samla in information som kan förbättra processen för automatisk skalning.