Design för skalning

Skalbarhet är möjligheten för ett system att hantera ökad belastning. Tjänster som omfattas av Automatisk skalning i Azure kan skalas automatiskt för att matcha efterfrågan för att hantera arbetsbelastningen. Dessa tjänster skalar ut för att säkerställa kapacitet under arbetsbelastningstoppar och återgå till det normala automatiskt när belastningen sjunker.

För att uppnå prestandaeffektivitet bör du överväga hur din programdesign skalar och implementerar PaaS-erbjudanden som har inbyggda skalningsåtgärder.

Ett program kan skalas på två sätt: vertikal skalningoch horisontell skalning. Vertikal skalning (skala upp)ökar kapaciteten för en resurs, till exempel genom att använda en större storlek på en virtuell dator (VM). Horisontell skalning (utskalning)lägger till nya instanser av en resurs, till exempel virtuella datorer eller databasrepliker.

Horisontell skalning har betydande fördelar jämfört med vertikal skalning, till exempel:

  • Verklig molnskala:Program är utformade för att köras på hundratals eller till och med tusentals noder och når skalor som inte är möjliga på en enda nod.
  • Horisontell skalning är elastisk:Du kan lägga till fler instanser om belastningen ökar eller ta bort instanser under tystare perioder.
  • Utskalningen kan aktiveras automatiskt, antingen enligt ett schema eller som reaktion på ändringar i belastningen.
  • Det kan vara billigare att skala ut än att skapa upp. Att köra flera små, virtuella datorer kan kosta mindre än en enda stor virtuell dator.
  • Horisontell skalning kan också öka återhämtningskapaciteten genom att lägga till mer redundans. Om en instans skulle krascha fortsätter programmet köras.

En fördel med vertikal skalning är att det går att göra utan några ändringar i programmet. Men någon gång kommer du att ha en gräns där du inte kan skala upp längre. Om du behöver ytterligare skalning då, måste den vara horisontell.

Horisontell skalning måste finnas inbyggd i systemets utformning. Du kan exempelvis skala ut virtuella datorer genom att placera dem bakom en lastbalanserare. Men varje virtuell dator i poolen måste hantera alla klientbegäranden, så programmet måste vara tillståndslöst eller lagra tillstånd externt (t.ex. i en distribuerad cache). I hanterade PaaS-tjänster finns ofta horisontell skalning och automatisk skalning inbyggt. Det är en stor fördel med PaaS-tjänster att det är så enkelt att skala tjänsterna.

Att bara lägga till flera instanser innebär inte att ett program kan skaländras. Det kan leda till flaskhalsen någon annanstans. Om du skalar en webbklientdel för att hantera fler klientförfrågningar kan det utlösa låskonkurrens i databasen. Du bör överväga andra mått, till exempel optimistisk samtidighet eller datapartitionering, för att möjliggöra mer dataflöde till databasen.

Utför alltid prestanda- och belastningstester för att hitta potentiella flaskhalsar. Statuskänsliga delar i ett system, som databaser, är den vanligaste orsaken till flaskhalsar. De kräver noggrann design för horisontell skalning. Att lösa problem med en flaskhals kan visa på andra flaskhalsar på andra ställen.

Använd checklistan för prestandaeffektivitet och granska din design ur skalbarhetssynpunkt.

I molnet beror möjligheten att dra nytta av skalbarheten på din infrastruktur och dina tjänster. Plattformar, till exempel Kubernetes, har skapats med skalning i åtanke. Virtuella datorer kan inte skalas lika enkelt även om skalningsåtgärder är möjliga. Med virtuella datorer kanske du vill planera i förväg för att undvika att skala om infrastrukturen i framtiden för att möta efterfrågan. Ett annat alternativ är att välja en annan plattform, till exempel skalningsuppsättningar för virtuella Azure-datorer.

När du använder skalbarhet kan du förutsäga den aktuella genomsnittliga och högsta tiden för din arbetsbelastning. Med betalningsalternativen kan du hantera den här förutsägelsen. Du betalar antingen per minut eller per timme beroende på tjänsten under en vald tidsperiod.

Planera för tillväxt

Planeringen för tillväxt börjar med att förstå dina aktuella arbetsbelastningar, vilket kan hjälpa dig att förutse skalningsbehov baserat på prediktiva användningsscenarier. Ett exempel på ett prediktivt användningsscenario är en e-handelswebbplats som känner till att infrastrukturen ska skalas om på rätt sätt för en förväntad hög volym helgtrafik.

Utför belastningstester och stresstester för att fastställa vilken infrastruktur som krävs för att stödja de förväntade topparna i arbetsbelastningar. En bra plan omfattar att införa en buffert för att hantera slumpmässiga toppar.

Mer information om hur du fastställer de övre och högsta gränserna för ett programs kapacitet finns i Prestandatestning i grundpelaren för prestandaeffektivitet.

En annan viktig del i planeringen för skalning är att se till att den region som är värd för ditt program stöder den kapacitet som krävs för att hantera belastningsökning. Om du använder en arkitektur för flera regioner kontrollerar du att de sekundära regionerna också har stöd för ökningen. En region kan erbjuda produkten, men den förväntade belastningen kanske inte ökar utan nödvändiga SKU:er (lagerhållningsenheter) så du måste verifiera kapaciteten.

Om du vill verifiera din region och tillgängliga SKU:er väljer du först produkten och regionerna i Produkt tillgängliga efter region.

Produkttillgänglighet per region

Kontrollera sedan de SKU:er som är tillgängliga i Azure Portal.

Lägga till skalningsenheter

För varje resurs bör du känna till de övre skalningsgränserna och använda horisontell partitionering eller nedbrytning för att gå utöver dessa gränser. Utforma programmet så att det enkelt kan skalas genom att lägga till en eller flera skalningsenheter, till exempel med hjälp av mönstret Distributionsstämplar. Fastställ skalningsenheterna för systemet för väldefinierade uppsättningar av resurser.

Nästa steg kan vara att använda inbyggda skalningsfunktioner eller verktyg för att förstå vilka resurser som behöver skalas samtidigt med andra resurser. Om du till exempel lägger till X antal virtuella datorer på frontend-sidan kan det krävas Y antal extra köer och Z antal lagringskonton för att hantera den extra arbetsbelastningen. En skalningsenhet kan därför bestå av X VM-instanser, Y-köer och Z-lagringskonton.

Använda autoskalning för att hantera belastningsökningar och minskningar

Med autoskalning kan du köra rätt mängd resurser för att hantera belastningen på din app. Den lägger till resurser (kallas att skala ut) för att hantera en ökning av belastningen, till exempel säsongsbaserade arbetsbelastningar. Autoskalning sparar pengar genom att ta bort inaktiva resurser (kallas att skala in) under en minskad belastning, till exempel helger och helger för vissa företagsappar.

Du skalar automatiskt mellan det lägsta och högsta antalet instanser som ska köras och lägger till eller tar bort virtuella datorer automatiskt baserat på en uppsättning regler.

Automatisk skalning

Mer information finns i Autoskalning.

Förstå skalningsmål

Skalningsåtgärder (vågräta – att ändra antalet identiska instanser, vertikal – växla till fler/mindre kraftfulla instanser) kan vara snabba, men det tar vanligtvis tid att slutföra. Det är viktigt att förstå hur den här fördröjningen påverkar programmet under belastning och om försämrad prestanda är acceptabelt.

Mer information finns i Metodtips för autoskalning.

Dra nytta av funktioner för automatisk plattformsskalning

Så här kan du dra nytta av funktionerna för automatisk skalning:

  • Använd inbyggda funktioner för automatisk skalning när det är möjligt i stället för anpassade mekanismer eller mekanismer från tredje part.
  • Använd schemalagda skalningsregler där det är möjligt för att säkerställa att resurser är tillgängliga.
  • Lägg till reaktiv autoskalning i reglerna där det är lämpligt för att hantera oväntade förändringar i efterfrågan.

Anteckning

Om ditt program uttryckligen har utformats för att hantera avslutningen av vissa av dess instanser ska du se till att använda automatisk skalning för att skala ned och skala in resurser som inte längre behövs för den givna belastningen för att minska driftskostnaderna.

Mer information finns i Autoskalning.

Autoskalning av CPU eller minnesintensiva program

Processor- eller minnesintensiva program kräver uppskalning till en större dator-SKU med mer processorkraft eller minne. När du har minskat behovet av cpu eller minne kan instanserna återgå till den ursprungliga instansen.

Du kan till exempel ha ett program som bearbetar bilder, videor eller musik. Med tanke på processen och kraven kan det vara klokt att skala upp en server genom att lägga till CPU eller minne för att snabbt bearbeta den stora mediefilen. Utskalning gör att systemet kan bearbeta fler filer samtidigt, men det påverkar inte bearbetningshastigheten för varje enskild fil.

Autoskalning med Azure-beräkningstjänster

Autoskalning fungerar genom att samla in mått för resursen (CPU- och minnesanvändning) och programmet (begäranden i kö och begäranden per sekund). Regler kan sedan skapas för att lägga till och ta bort instanser beroende på hur regeln utvärderas. En App Services-appplan gör att regler för automatisk skalning kan konfigureras för utskalning/inskalning och uppskalning/nedskalning. Skalning gäller även för Azure Automation.

Exemplet på automatisk skalning i Application Service visar hur du skapar en Azure App Service plan, som innehåller en Azure App Service.

Azure Kubernetes Service (AKS) erbjuder två nivåer av autoskalning:

  • Horisontell autoskalning:Kan aktiveras på tjänstcontainrar för att lägga till fler eller färre poddinstanser i klustret.
  • Automatisk skalning avkluster: Kan aktiveras på vm-agentinstanser som kör en agentnodpool för att lägga till fler eller ta bort VM-instanser dynamiskt.

Andra Azure-tjänster omfattar följande tjänster:

Varje tjänst dokumenterar sina autoskalningsfunktioner. Läs Översikt över autoskalning för en allmän diskussion om automatisk skalning på Azure-plattformen.

Anteckning

Om programmet inte har inbyggd möjlighet att skala automatiskt eller inte är konfigurerat för att skala ut automatiskt när belastningen ökar, är det möjligt att programmets tjänster misslyckas om de blir mättade med användarbegäranden. Referens Azure Automation för möjliga lösningar.

Nästa steg