Et år i opstart. Sådan optimeres dine AWS-omkostninger, når du kører en opstart.

Cloud computing er bare en bedre måde at drive din virksomhed på

Før jeg grundlagde et firma undervurderede jeg, hvor vigtige cloud computing-tjenester er for opstart-økosystemet. AWS, GCE, Azure, Digital Ocean har spillet en kritisk rolle i spredningen af ​​nystartede virksomheder. At have adgang til næsten ubegrænsede ressourcer løser en masse tekniske vanskeligheder, så du kan fokusere på det, der er essentielt for din virksomheds vækst, snarere end at genere vedligeholdelse af hardware. Men som med enhver stor magt kommer stort ansvar.

Snap Inc., firmaet bag den populære Snapchat-messaging- og foto-delings-app, har accepteret at købe Amazon-skyveservices på 1 milliard dollars i løbet af de næste fem år, ifølge en ny arkivering hos den amerikanske Securities and Exchange Commission.

Når vi grundlagde Visely, er problemet med at betale AWS-regningen blevet meget reelt. Her er en kort oversigt over, hvordan vi skærer regningen dobbelt ved omhyggeligt at lave en infrastruktur fra de bedste tilgængelige muligheder, AWS giver.

AWS-forekomsttyper

AWS giver et stort udvalg af forskellige tilfælde. For Visely krævede vi VM'er, der effektivt kører webservere til servering af klientsiden, databaseservere (hosting MongoDB) og arbejdsbyrde til maskinlæring (Cassandra + Spark).

Valg af de bedste tilgængelige indstillinger nemt opsummeres til en månedlig regning på et par tusinder af dollars, som for en opstart, der startes, er en stor pris at betale. Et almindeligt beregnet optimeret eksempel med 4 CPU'er og 8 GB RAM kan koste op til 125 $ om måneden.

Dette er grundene, der tvang os til at se nærmere på forekomster af T2-typen.

T2 til redning

T2-forekomster giver en basislinjeydelse med evnen til at sprænge til et højere niveau i en periode, der er afledt af de kreditter, der er tildelt den valgte VM.

Kreditter og deres forbrugsrate var først kryptisk, men når vi først læste omhyggeligt gennem AWS-dokumenter, blev det hele lyd.

Lad mig give et eksempel. T2 lille (med en vCPU, 2 GB), starter med 288 credits tildelt. Grundlæggende ydelse er 20% CPU, hvilket betyder, at når du har krydset 20% -grænsen, vil dine kreditter begynde at brænde hurtigere, end du længes efter dem. Hvor hurtigt brænder de? Ganske hurtigt, ved 100% CPU-brug vil du forbruge 288 credits på cirka fire timer.

T2 lille kreditforbrug

Selv under disse forhold har du næppe brug for 100% CPU hele tiden. En masse startups har et forudsigeligt brugsmønster med en eller to toppe (dvs. øst- og vestkystkunder), der forekommer hele dagen. Dette er en ideel brugssag til T2-tilfælde, der kan dække brugstoppe med kreditter og gendanne sig i løbet af natten. Alle vores mikrotjenester kører på T2 VM'er, og de er nødt til at komme sig i løbet af off-peak timer.

Fejl, der skal undgås, når du bruger T2-tilfælde

Når du forbruger alle dine kreditter, fungerer din instans på basisniveauet, for T2 lille er dette 20% CPU. Gendannelsesprocessen er ret langsom (dvs. 12 kreditter i timen for T2 lille), så du skal være meget forsigtig med at vælge den forekomsttype, du har brug for til opgaven, så den aldrig forbruger alle kreditter i løbet af spidsbelastningen.

Uden kreditter og en belastning, der er større end baseline, vil din instans blive ustabil.

Ops 'rapport: tre ud af fem appserveres adfærd er lidt mærkelig (kreditter til @devopsreactions)

Den sidste ting, du ønsker, er at have et eksempel uden kreditter tilbage i spidsbelastningen. Din eneste mulighed, i dette tilfælde, vil være at levere en ny og omdirigere belastningen mod den. Vi har lært det på den hårde måde. Overvåg din kreditforbrug nøje. AWS leverer et praktisk CloudWatch-værktøj, som du kan konfigurere til at sende dig advarsler, når du går over en indstillet tærskel.

Sådan vælges T2-tilfælde optimalt

Start med tilfælde, der tydeligt giver nok hestekræfter til din belastning. Overvåg det i et par dage, og hvis du ser en flad graf over kreditbrug, skal du enten ændre forekomsttypen eller lægge flere tjenester på den.

Forekomsten klarer sig for godt

Dette var nøglesignalet om, at vi kan lægge mere belastning på forekomster, der havde denne kurve for kreditanvendelse. Vores strategi var enkel. Når vi opdagede VM'er, der var underudnyttede, begyndte vi at installere mere lave CPU-forbrugende tjenester på det.

Efter en måned med overvågning og finjustering skar vi antallet af kørende VM-instanser næsten i halve.

Spotforekomster til skalering af ikke-kritiske ressourcer og offline arbejdsbyrde

Bortset fra T2-type forekomster, leverer AWS også Spot-forekomster, der kan bruges til at skære omkostninger fra din månedlige regning. Den eneste forskel mellem On-Demand VM'er og Spot Instances er, at senere kan afbrydes af EC2 med to minutters varsel, når AWS har brug for dem tilbage.

En hård afbrydelse (eller dvaletilstand) med to minutters anmeldelse lyder hårdt, men til offline batchjobs eller on-demand-skalering kan dette være en ideel løsning.

Her på nemo.ai bruger vi Apache Spark til to typer opgaver:

  • offline analyse til forretningsdashboards
  • kører samarbejdsfiltreringsalgoritme for at identificere kunder, der købte også købte / set slags forhold

Begge disse job er offline og kan udføres i batches, et perfekt scenarie til tildeling af stedet.

Hvordan fungerer Spot Instances?

AWS indeholder en omfattende brugervejledning til, hvordan man bruger spot-forekomster. Kort sagt giver du et pristilbud på den ressource, du ønsker at bruge. Ressourcen tildeles når prisen for den falder under dit bud.

Vi kunne anmode om tre M3 (hukommelsesoptimeret) gnistforekomster med en specificeret maksimalpris, der kører på CentOS. Når anmodningen er opfyldt, er det næste trin simpelthen at indsætte Docker-containere med konfigurerede gnistarbejdere på den.

Batchjobbet begynder at udføres sekventielt for hver af de klienter, vi har. Det tager cirka en time at køre al den krævede behandling for alle klienter. I løbet af denne tidsramme kan Spot Instances genvindes med en meddelelse på to minutter, hvilket aldrig er et problem, da jobbet er offline og kan genoptages for de klienter, der er tilbage, når anmodningen er opfyldt igen.

For at opsummere er det, hvis du vil opbygge en applikation, der drager fordel af Spot-forekomster, her er top-software til design af software:

  • levering AWS-tilfælde med TerraForm (eller ethvert andet automatiseringsværktøj) for at starte din spot-forekomst med nødvendige tjenester så hurtigt som muligt. Brug af et forudbygget AMI-billede er også en løsning, skønt vi besluttede at køre Terra Form, da det bare er lettere for os.
  • det job, du kører på Spot Instance, bør ikke være bange for afbrydelse eller dvaletilstand.
  • implementering af påkrævede applikationer på Spot Instances skal være fuldstændigt automatiseret, ellers bruger du dyrebar tid på installationen, før VM bliver brugbar. Brug af Docker-billeder kan være en optimal løsning til dette.

For at verificere tilgængeligheden af ​​Spot-forekomster i din region, kan du bruge denne praktiske ressource.

Diverse omkostninger

Netværk og vedvarende opbevaring er næst dyreste ressourcer, vi måtte optimere. Her har du færre muligheder at lege med, vi besluttede at bruge SSD til tjenester, der kræver hurtig vedvarende I / O (dvs. MongoDB, Apache Solr). Statsløse tjenester klarer sig fint med magnetisk levering.

Hvad netværket angår, er der meget lidt, du kan justere, selvom du bestemt skal være opmærksom, hvis din netværksbrug er inden for de forventede grænser.

Som en opstart, der krævede flere VM'er for at køre sine tjenester, betalte indsatsen med omkostningsoptimering pænt, hvilket sparer os penge, som vi kunne bruge på andre ting.

Hvis du kunne lide denne historie, kan du tjekke den anden fra denne serie

Et år i opstart. Hvordan vi startede en opstart.