Virkeligheden ved at køre en produktions Node-app på AWS Elastic Beanstalk

Erfaringer fra 2 års drift af en produktions-Node-app på AWS 'ELB-platform

Front-Matter

Lad os være ærlige, AWS-prisregner er forvirrende. En del af det er på grund af a la carte- betalingsmetoden, som AWS tilbyder. Dette gør det vanskeligt at prøve at give et godt tilbud til en klient. Forhåbentlig kan denne artikel give noget lys over, hvor meget det koster at køre en app, samt nogle måder at reducere omkostningerne på.

De reelle omkostninger ved at køre en app

Jeg har styret en node-webapp på ELB i omkring to år nu. Det første år var fantastisk, de gav dig alt gratis (for det meste)! Derefter skal du begynde at betale for ting som EC2-forekomster.

Denne artikel vil fokusere på mine specifikke appkrav, som er en nodebaseret ekspressapp, der er hostet på Elastic Beanstalk.

For min detaljer om bygningen, se min tidligere artikel her.

Sammenbrud

Dette kører jeg i øjeblikket på AWS:

Enkelt EBS-miljø (US West Region):

  • 1 klassisk belastningsafbalancering
  • 1 t2.micro EC2-forekomst
  • S3 Bucket, der indeholder billeder (7 GB i skrivende stund)
  • 1 Rute 53 Hosted Zone

$ 18 (Load Balancer) + $ 5 (EC2 med en RI) + $ 0,50 (Rute 53) + $ 0,17 (S3) + $ 0,21 (Dataoverførsel) = Omkring $ 25 om måneden.

Derudover er jeg vært for en MongoDB et andet sted, så hvis du planlægger at være vært for en DB på AWS, vil det medføre ekstra omkostninger. Lad os nedbryde de forskellige omkostninger.

Load Balancer

Dette er den dyreste del af stakken. Det koster:

  • $ 0,025 pr. Klassisk belastningsafbalanceringstime (eller delvis time)
  • $ 0,008 pr. GB data behandlet af en Classic Load Balancer

Det betyder, at hvis du kører din app 24 timer i døgnet, koster det ca. $ 18+ datagebyrer hver måned.

EC2-instans

On-demand EC2-forekomster er dyrere, end de burde være. For at spare nogle penge her henvises til nedenstående afsnit om reserverede EC2-forekomster. Hvis du spekulerede på, ville det koste $ 8,40 at køre den samme type EC2-forekomst som nævnt ovenfor, on-demand.

S3

Jeg har et par S3 spande. En til min statiske startside, en til at holde billeder og en til at holde applikationsversionen. Så vidt jeg ved, opretter ELB automatisk en til styring af applikationsversionerne.

S3 er ret billig, så jeg er ikke så bekymret for at forsøge at nikkel og skære det, men der er måder at spare penge via deres gletsjersystem.

Database

Jeg er vært for min MongoDB DB på mLab, som snart forsvinder. Så jeg opdaterer dette, når jeg finder ud af, hvor meget det faktisk koster, når jeg er tvunget til at flytte til Mongos Atlas.

Reserverede EC2-forekomster

Lad os tale om Reserved Instances (RI). Amazons indviklede faktureringssystem er den mest forvirrende del om styring af noget på AWS. Reserverede forekomster kan mindske nogle af omkostningerne, men er alt for forvirrende.

Efter en masse læsning og samtale med AWS kundeservice, var det lidt, jeg regnede med.

For det første er der to forskellige måder, du kan reservere, hvor RI er: Regional og tilgængelighedszone. Regionale midler, det er specifikt for en af ​​hovedregionerne, f.eks. us-west-2 (Oregon). Tilgængelighedszonen (AZ) er specifik for en zone inden for denne region, f.eks. Us-vest-2 a (Oregon).

Jeg købte en RI i us-west-2, og den blev automatisk anvendt på min instans, der kørte i dette område. Hvis du køber en inden for AZ, gælder den kun for den specifikke AZ, f.eks. Us-west-2a, så hvis ELB snurrer op til en EC2-forekomst i us-west2b, ​​har du ikke held.

Derudover er der “standard” og “konvertible” typer RI'er. Jeg er ikke 100% på, hvad det betyder, men ud fra hvad jeg forstår, er cabriolet mere fleksibelt, hvad du kan bytte det til, men dyrere.

Endelig er der tre typer betalingstyper: Nej foran, delvis foran, alt foran. Dette er ret ligetil, du betaler enten intet, noget eller alt, når du reserverer instansen. Der er ingen omkostningsfordel, som jeg kan se. Men som en ny konto kan du sandsynligvis ikke gøre noget på forhånd.

Per AWS-support:

Ingen forhåndsreserverede forekomster (RI'er) kan udgøre en betydelig faktureringsrisiko for nye konti, da de er en kontraktlig forpligtelse til at betale månedligt for hele RI-løbetiden. Af denne grund kan nye konti og let anvendte konti ikke tilmelde sig No Upfront RI'er, før der er opbygget en vellykket faktureringshistorik hos os.

Du kan støde på denne fejl, hvis du prøver at købe en nej-up-front.

Fejl: Din nuværende kvote tillader ikke dig at købe det påkrævede antal reserverede forekomster (Service: AmazonEC2; Statuskode: 400; Fejlkode: ReservedInstancesLimitExceeded;)

Advarsel: Af en eller anden grund tager det lidt for den reserverede instans at "kick-in", hvilket betyder at den første dag i måneden altid koster mere. Jeg er ikke sikker på, hvorfor dette er, men hvis jeg finder ud af det, opdaterer jeg dette. Se graf nedenfor:

Smertepunkter

Dette er blot nogle mindre klager over den samlede EBS, som jeg regnede med, at jeg ville medtage som et tillæg til min originale artikel, hvis du er nysgerrig.

Automatiske opdateringer er ikke rigtig så automatiske

Nodeversioner stemmer ikke op fra version til version.

Se nedenstående trin om, hvordan jeg administrerer ændring af Linux-versioner, når Node ikke fungerer.

Kører mere end et miljø

At have et udviklingsmiljø og en produktion, der kører på samme tid, er let, men det er dyrt. Det fordobler det faktisk. Derfor ødelægger jeg normalt dev-miljøet, så snart jeg er færdig med det.

Dokumentation er frygtelig

AWS er ​​for stort til sit eget bedste. Det er en del af, hvorfor jeg skriver dette. Det var virkelig svært at finde svar på mine specifikke behov.

Hvordan jeg administrerer opdateringer

Jeg har to separate forekomster af min Git repo installeret på min bærbare computer. Jeg har en til dev og en til produktion.

Jeg bruger udviklingsmiljøet til at udvikle sig! Temmelig ligetil. Jeg bruger produktionsmappen udelukkende med det formål at hente opdateringer fra Git-mastergren, køre min webpack-konfiguration og implementere på produktionsserveren.

Årsagen til, at de er adskilte, er fordi jeg kan opretholde separate elastiske bønnestængelkonfigurationer og ikke behøver at bekymre mig om at implementere det forkerte sted.

Opdateringer, der ikke kræver en Linux-miljøændring

For opdateringer, der ikke kræver ændringer i linux-miljøet, er det så simpelt som at køre eb deployi terminalen. Det er fantastisk og tager cirka 10 minutter at sprede sig.

Opdateringer, der kræver en Linux-miljøændring

Lejlighedsvis vil du gerne opdatere Linux-miljøet, men du kan ikke også, fordi AWS er ​​freaking dum (jeg er sikker på, at der er en grund) og kun tillader visse versioner af Node på hver Linux-build. Til dette er det lidt mere kompliceret, men håndterbart.

  1. Skub til produktionskonfiguration under ny env. Sidste gang jeg gjorde dette, oprettede jeg bare en ny instans via eb create prod-1. Det gør, hvad det har brug for, og distribuerer din app til et nyt miljø.
  2. Sørg for, at alle dine opdateringer fungerer. Virker ret åbenlyst, men det er et godt tidspunkt at sikre sig, at der ikke var nogen hikke med den nye build.
  3. Sørg for, at dine miljøer er konfigureret korrekt. Dette er en del af den tidligere version, men sørg for at trække fra den rigtige DB eller hvad som helst.
  4. Sørg for, at din load balancer har det samme SSL-certifikat (hvis relevant). Sjov kendsgerning, hvis du prøver at få adgang til en ELB-forekomst i https uden et certifikat, vil det mislykkes!
  5. Byt forekomsterne. Endelig, efter at alt ser godt ud at gå, er der en knap i konsollen for at bytte instans-webadresser. NEM LET. Du behøver ikke ændre noget på rute 53, det gør det hele for dig.

Så der har du det. Sådan styres dine opdateringer. Temmelig let.

Afsluttende tanker

Hvis du har nogle forslag til at gøre det billigere / lettere, vil jeg meget gerne høre dem. Jeg kan godt lide diskussionen om værktøjer og muligheder lige så meget som den næste udvikler!

Med det forlader jeg med dette: God kodning!