Vad är skalbarhet?
I affärsvärlden kan tillväxt vara fördelaktigt. Men när tillväxten sker för snabbt, och när du inte har förberett dig tillräckligt för den, kan tillväxt skapa problem. Ett av dessa problem är effekten av tillväxt på tillförlitligheten för program och tjänster som inte har utformats för att hantera en stor ökning av trafiken.
För dina kunder och användare är ett avbrott ett avbrott. De vet eller bryr sig inte om de inte kan komma åt din webbplats på grund av buggig kod eller för att för många andra försöker använda din perfekt kodade webbplats samtidigt.
Skalbarhet är möjligheten att anpassa sig till ökade krav eller föränderliga behov. Dina program och tjänster måste kunna hantera en större mängd arbetsbelastningar för att kunna växa. Skalbara program kan hantera ett växande antal begäranden över tid utan en negativ inverkan på tillgänglighet eller prestanda.
I den här lektionen får du lära dig mer om relationen mellan skalbarhet och tillförlitlighet, vikten av kapacitetsplanering för att uppnå skalbarhet och kortfattat granska några grundläggande begrepp och termer som rör skalning.
Relation mellan skalbarhet och tillförlitlighet
Den goda nyheten är att göra appen mer skalbar kan också göra den mer tillförlitlig. Om systemet till exempel skalar automatiskt och sedan får ett komponentfel på en enda virtuell dator, etablerar autoskalningstjänsten en annan instans för att uppfylla kraven för minsta antal virtuella datorer (VM). Systemet blir mer tillförlitligt. I ett annat exempel använder du en tjänst på högre nivå som Azure Storage som i sig är skalbar. Om du har ett lagringsproblem är tjänsten byggd för att vara tillförlitlig, så dina data replikeras.
Här är en analogi: Tänk på de hjälpmedelsramper som du ofta ser utanför byggnader som ursprungligen utformades för att rymma personer i rullstolar. De tjänar det syftet. Men de används också av föräldrar med barn i barnvagnar eller vagnar, eller av små barn för vilka trappstegen är för djupa eller höga. Den här användningen är en sekundär nytta.
Tillförlitlighet är ofta en sekundär fördel med skalbarhet. Om du utformar dina system så att de är skalbara är de förmodligen också mer tillförlitliga.
Skalbarhet och kapacitetsplanering
Kapacitetsplanering handlar om att fastställa vilka resurser du behöver för att uppfylla både nuvarande och framtida krav. Du gör den här planeringen genom att analysera din aktuella resursanvändning och sedan projicera för framtida tillväxt.
Om du vill uppskatta kapacitetsbehoven i framtiden bör du överväga sådana faktorer som:
- Förväntad affärstillväxt
- Periodiska variationer (säsongsvariationer och så vidare)
- Programbegränsningar
- Identifiering av flaskhalsar och begränsningsfaktorer
Du måste också ange servicenivåmål så att du kan skapa en kapacitetshanteringsplan som på ett tillförlitligt sätt uppfyller eller överskrider dessa mål när arbetsbelastningen och miljön ändras.
Kapacitetsplanering är en iterativ process. När vi går igenom den här modulen lär du dig att mappa resurskrav för programkomponenter.
Begrepp och terminologi
Innan du kan förstå de begrepp och strategier som du stöter på i den här modulen behöver du några nödvändiga kunskaper om några grundläggande begrepp och grundläggande termer som rör skalning.
- Skala upp: Gör en komponent större för att hantera en ökad arbetsbelastning. Kallas även för lodrät skalning.
- Utskalning: Lägga till fler komponenter eller resurser för att sprida ut belastningen över en distribuerad arkitektur. Du kan till exempel använda en enkel arkitektur som har flera serverdelar bakom en uppsättning klientdelar. När belastningen ökar lägger vi till fler back-end-servrar (och front-end-servrar) för att hantera denna. Kallas även för horisontell skalning.
- Manuell skalning: Kräver mänsklig åtgärd för att öka mängden resurser.
- Autoskalning: Systemet justerar automatiskt mängden resurser baserat på belastningen. För att vara tydlig justeras mängden både uppåt och nedåt baserat på antingen en ökad eller minskad belastning.
- DIY-skala: Gör-det-själv-skalning där du måste konfigurera automatisk skalning.
- Inbyggd skalning: Tjänster som har skapats för att vara skalbara och hantera den här skalningen åt dig i bakgrunden utan några åtgärder från din sida. Från ditt perspektiv ser de nästan oändligt skalbara ut eftersom du bara kan använda fler resurser utan att tilldela dem manuellt.
Tailwind Traders-arkitektur
I den här modulen ska vi använda en exempelarkitektur från ett fiktivt maskinvaruföretag som heter Tailwind Traders. Deras e-handelsplattform ser ut så här:
Det här diagrammet är ganska komplext vid första anblicken, så vi går igenom det. Webbplatsen har en klientdel. Det är det du interagerar med när du besöker tailwindtraders.com.
Front-end pratar med en uppsättning back-endtjänster. Dessa serverdelstjänster omfattar vanliga objekt som en kupongtjänst, en kundvagnstjänst, en inventeringstjänst och så vidare. Alla körs i Azure Kubernetes Service. Det finns andra delar och tekniker som är i spel med det här programmet. Allt du behöver fokusera på är klientdelen och serverdelstjänsterna som körs på Kubernetes.
Enstaka felpunkter
Nu när du har sett hela arkitekturen tar vi en stund att undersöka de enskilda felpunkterna och de platser vi kan lägga vår uppmärksamhet på när vi tänker på skalning.
Alla dessa tjänster är en enskild felpunkt – de är inte byggda för återhämtning eller för skalning. Om en av dem blir överbelastad kommer den sannolikt att krascha, och det finns inget enkelt sätt att lösa det just nu.
Senare i den här modulen tittar vi på andra sätt att utforma dessa tjänster så att de blir mer skalbara och tillförlitliga.
Företablerad kapacitet
Låt oss ta en titt på en annan fråga som kan visa sig vara besvärlig. Här är de tjänster/komponenter som kräver att vi etablerar kapacitet i förväg:
Med Cosmos DB etablerar vi till exempel dataflödet i förväg. Om vi överskrider dessa gränser börjar vi returnera felmeddelanden till våra kunder. Med Azure AI-tjänster väljer vi nivån och den nivån har ett maximalt antal begäranden per sekund. När vi har nått någon av gränserna kommer klienterna att få en reducerad hastighet.
Kommer en betydande trafikspik, till exempel vid lanseringen av en ny produkt, att orsaka att vi når dessa gränser? Just nu vet vi inte. Den här frågan är en annan som vi granskar senare i den här modulen.
Kostnader
Även när vi gör saker rätt måste vi fortfarande planera för tillväxt. Här är tjänsterna för betala per användning:
Här använder vi Azure Logic Apps och Azure Functions, som båda är exempel på serverlös teknik. Dessa tjänster skalas automatiskt och vi betalar per begäran. Din faktura växer som kundbasen gör. Vi bör åtminstone vara medvetna om vilken inverkan kommande händelser som en produktlansering kan ha på våra molnutgifter. Vi arbetar med att förstå och förutsäga våra molnutgifter senare i den här modulen också.