Hvad er hurtig elasticitet i cloud computing?

Hurtig elasticitet er skyens evne til hurtigt at tildele og frigive kapacitet, ofte automatisk, så ressourcerne skaleres op og ned efter efterspørgslen. NIST opregner den som en af de fem væsentlige egenskaber ved cloud computing. For brugeren fremstår den tilgængelige kapacitet ubegrænset og kan tages i enhver mængde på ethvert tidspunkt og derefter afleveres igen.

Vigtigste pointer

• NIST SP 800-145 definerer den som funktioner, der "kan tildeles og frigives elastisk, i nogle tilfælde automatisk, så de skaleres hurtigt udad og indad i takt med efterspørgslen".
• Begge retninger tæller. Når du frigiver kapacitet, hvis efterspørgslen falder, bliver elasticitet til besparelser.
• I praksis leveres den af autoskalering: metrikker, skaleringspolitikker, minimums- og maksimumsgrænser og en load balancer.
• Elasticitet er kortsigtet og automatisk; skalerbarhed er den langsigtede evne til at vokse. En cloud-workload har brug for begge dele.
• Den virker kun, hvis applikationen er bygget til det: tilstandsløse servere, sessionslager uden for serveren og en database, der kan følge med.

NIST-definitionen, ord for ord

US National Institute of Standards and Technology skrev den definition, som de fleste lærebøger og certificeringseksamener bruger. I NIST Special Publication 800-145, The NIST Definition of Cloud Computing lyder den (her i oversættelse):

"Funktioner kan tildeles og frigives elastisk, i nogle tilfælde automatisk, så de skaleres hurtigt udad og indad i takt med efterspørgslen. For forbrugeren fremstår de funktioner, der kan tildeles, ofte som ubegrænsede og kan tages i anvendelse i enhver mængde på ethvert tidspunkt."

De fire øvrige væsentlige egenskaber er selvbetjening efter behov, bred netværksadgang, ressourcepooling og målt service. Hver frase i definitionen har en praktisk betydning:

• "Tildeles og frigives": kapaciteten går tilbage såvel som ud. Et system, der kun vokser, er skalerbart, ikke elastisk.
• "I nogle tilfælde automatisk": automatisering er almindelig, men ikke et krav. En person, der klikker "tilføj fem servere" og får dem på få minutter, passer stadig til definitionen.
• "Udad og indad": definitionen beskriver horisontal skalering, hvor man tilføjer og fjerner instanser, i stedet for at ændre størrelsen på én maskine.
• "I takt med efterspørgslen": kapaciteten skal følge den faktiske belastning og ikke en prognose, der blev lavet for flere måneder siden.
• "Fremstår som ubegrænsede": leverandørens pulje er så stor, at en enkelt kunde sjældent rammer kanten, selv om kvoter på kontoen stadig gælder.

Hvordan fungerer det i praksis?

Cloududbydere leverer elasticitet gennem autoskaleringstjenester. AWS Auto Scaling "overvåger dine applikationer og justerer automatisk kapaciteten for at opretholde stabil, forudsigelig ydeevne til lavest mulige pris" (oversat fra AWS' beskrivelse). Azure og Google Cloud har tilsvarende tjenester til grupper af virtuelle maskiner, containere og databaser.

En typisk opsætning har fem dele:

1. Metrikker som CPU-forbrug, forespørgsler pr. mål eller kølængde, indsamlet hvert minut eller hyppigere.
2. Politikker, der siger, hvornår der skal handles: hold CPU omkring 50 %, tilføj to instanser, når køen overskrider en tærskel, eller tilføj kapacitet hver hverdag kl. 08.00.
3. Grænser: et minimum for at forblive tilgængelig og et maksimum for at begrænse udgifterne.
4. Tildeling fra en skabelon eller et image, så nye instanser er identiske og starter hurtigt.
5. En load balancer, der sender trafik til nye instanser, når sundhedstjek er bestået, og tømmer dem for trafik, før de fjernes.

Microsofts Azure Well-Architected Framework peger på konsekvensen for designet: horisontal skalering af virtuelle maskiner "kræver en separat load balancer, håndtering af klientforespørgsler og eksternt lagret tilstand" (oversat). Elasticitet er lige så meget en egenskab ved applikationens design som en funktion i platformen.

Hurtig elasticitet og skalerbarhed

Skalerbarhed handler om, hvorvidt et system kan klare mere belastning, når det får flere ressourcer. Elasticitet handler om, hvorvidt det får og frigiver de ressourcer hurtigt og automatisk, når belastningen ændrer sig.

Hvis du vil se mulighederne for større virksomheder, herunder VM-grupper med autoskalering, containere og serverless, kan du læse vores guide til elastisk skalerbarhed i cloud computing.

Eksempler

• Udsalg i detailhandlen. En webshop skalerer sit web- og kasselag op til en Black Friday-kampagne og tilbage til normalt niveau ugen efter.
• Sæsonbestemte virksomheder. Et skisportssteds booking- og webcamsider har størstedelen af trafikken i nogle få vintermåneder.
• Mediefrigivelser. En streaming- eller nyhedstjeneste tilføjer kapacitet, når en populær udgivelse eller en brydende historie giver en bølge af trafik.
• Batchanalyse. Et økonomiteam kører månedsafslutningens rapporter på hundredvis af kerner i en time i stedet for på nogle få servere i flere dage.
• Udvikling og test. Testmiljøer startes til en belastningstest eller en pull request og slettes bagefter.

Sæsoncasen er reel hos Opsio-kunden Branäsgruppen, en af Sveriges største skiresortgrupper, med op til 15.000 skiløbere om dagen i højsæsonen. Gruppens lokale VMware-miljø skulle skaleres manuelt før hver efterspørgselstop, og ydeevnen faldt, indtil det var gjort. Efter flytningen til AWS beskriver casen om Branäsgruppen web-frontends, middleware og databaselag, der nu udvides og trækker sig sammen automatisk efter sæsonens efterspørgsel.

Fordele og begrænsninger

Fordelene er direkte: du betaler kun for spidskapacitet, mens spidsen varer, brugerne får ensartede svartider, og ingen skal tilføje servere manuelt før en kampagne.

Begrænsningerne er lige så praktiske:

• Opstartstid. Nye virtuelle maskiner skal bruge tid på at starte og varme op. Meget skarpe spidser kræver ekstra luft, forvarmet kapacitet eller serverless.
• Datalaget. Webservere er lette at skalere; relationsdatabaser er ikke. Planlæg læsereplikaer, caching eller en managed database, der kan skalere.
• Kvoter. Grænser på kontoen for instanser eller samtidighed kan stoppe udvidelsen. Hæv dem før kendte spidser.
• Overraskelser på regningen. En fejl eller bottrafik kan skalere dig hurtigt op. Sæt altid et maksimum og budgetalarmer.
• Licenser. Software, der licenseres pr. server eller pr. kerne, tillader måske ikke kortlivede instanser.

Har din workload det? Et hurtigt tjek

• Kan en enkelt server lukkes, uden at brugerne mister deres session eller data?
• Findes der en skaleringspolitik med afprøvede minimums- og maksimumsgrænser?
• Falder kapaciteten faktisk efter en spids? Se grafen over antal instanser for sidste måned.
• Er databasen belastningstestet ved spidstrafik og ikke kun weblaget?
• Er servicekvoterne høje nok til din største forventede spids?

Hvis flere af svarene er "nej", er workloaden hostet i skyen, men endnu ikke elastisk. Opsios teams inden for AWS managed service og cloudrådgivning gennemgår og lukker de huller som en del af arkitekturarbejdet.

Ofte stillede spørgsmål

Hvad er hurtig elasticitet i cloud computing?

Det er en af de fem væsentlige egenskaber ved cloud computing, som NIST har defineret: kapacitet kan tildeles og frigives hurtigt, nogle gange automatisk, så den skaleres ud og ind efter efterspørgslen, og for brugeren fremstår den ubegrænset.

Hvad er et eksempel på hurtig elasticitet?

En webshop, der kører fire webservere en normal dag, automatisk skalerer til tyve under en salgskampagne og vender tilbage til fire, når kampagnen slutter. Den betaler kun for de ekstra seksten servere, mens de kører.

Hvad er forskellen på elasticitet og skalerbarhed?

Skalerbarhed er evnen til at klare mere belastning ved at tilføje ressourcer, som regel på lang sigt. Elasticitet er at tilføje og fjerne de ressourcer hurtigt, ofte automatisk, når efterspørgslen stiger og falder.

Er hurtig elasticitet det samme som autoskalering?

Ikke helt. Elasticitet er egenskaben; autoskalering er den mest almindelige måde at levere den på. NIST's definition siger, at tildelingen sker "i nogle tilfælde automatisk", så hurtig manuel skalering tæller også, men i praksis automatiserer cloudteams det.

Hvorfor er elasticitet vigtig i cloud computing?

Fordi den fjerner valget mellem at betale for ubrugt kapacitet og at løbe tør for kapacitet i spidsbelastning. Du dimensionerer til dagens efterspørgsel, skalerer ud, når den stiger, og skalerer ind igen, når den falder.

Relateret læsning

• Hvad er Cloud Elasticity
• Hvordan kan Elastic Computing optimere dine cloududgifter?
• Hvad er de vigtigste fordele ved elasticitet i cloud-tjenester?