🥇Oprettelse af skalerbar API på AWS spot-instanser

Hej alle! Jeg hedder Kirill, og jeg er CTO hos Adapty. Størstedelen af vores arkitektur ligger på AWS, og i dag vil jeg fortælle om, hvordan vi reducerede serveromkostningerne med 3 gange ved at bruge spotinstanser i et produktionsmiljø, samt hvordan man opsætter automatisk skalering af dem. Først vil der være en overordnet gennemgang af, hvordan det fungerer, og derefter en detaljeret vejledning til opstart.

Hvad er spotinstanser?

Spotinstanser er servere fra andre AWS-brugere, som i øjeblikket er ledige, og de sælger dem med en stor rabat (Amazon skriver op til 90%, men ifølge vores erfaring er det cirka 3x, varierende afhængig af region, tilgængelighedszoner og instanstype). Den primære forskel fra almindelige instanser er, at de kan slukkes når som helst. Derfor har vi længe ment, at det var acceptabelt at bruge dem til udviklingsmiljøer eller til beregning af noget, mens man gemmer mellemliggende resultater på S3 eller i en database, men ikke til produktion. Der findes tredjepartsløsninger, der tillader brug af spotinstanser i produktionen, men der er mange udfordringer for vores tilfælde, så vi implementerede dem ikke. Tilgangen beskrevet i artiklen fungerer fuldt ud inden for AWS's standardfunktionalitet, uden yderligere scripts, cron-jobs osv.

Her er et par skærmbilleder, der viser prisudviklingen for spotinstanser.

m5.large i regionen eu-west-1 (Irland). Prisen har været overvejende stabil i 3 måneder, og i øjeblikket er besparelsen 2.9x.

m5.large i regionen us-east-1 (N. Virginia). Prisen ændrer sig konstant i løbet af 3 måneder, og i øjeblikket er besparelsen fra 2.3x til 2.8x afhængig af tilgængelighedszonen.

t3.small i regionen us-east-1 (N. Virginia). Prisen har været stabil i 3 måneder, og i øjeblikket er besparelsen 3.4x.

Tjenestearkitektur

Den grundlæggende arkitektur for den tjeneste, vi skal tale om i denne artikel, er vist i diagrammet herunder.

Application Load Balancer → EC2 Target Group → Elastic Container Service

Application Load Balancer (ALB) bruges som belastningsbalancer, der sender anmodninger til EC2 Target Group (TG). TG er ansvarlig for at åbne porte på instanserne for ALB og forbinde dem med portene på Elastic Container Service (ECS) containerne. ECS er den AWS-baserede version af Kubernetes, der styrer Docker-containere.

På én instans kan der være flere kørende containere med de samme porte, så vi kan ikke angive dem fast. ECS informerer TG om, at den starter en ny opgave (i Kubernetes-termer kaldes det en pod), som derefter tjekker de ledige porte på instansen og tildeler en af dem til den kørende opgave. TG tjekker også regelmæssigt, om instansen og API'en fungerer korrekt via health check, og hvis den opdager problemer, stopper den med at sende forespørgsler dertil.

EC2 Auto Scaling Groups + ECS Capacity Providers

I den ovenfor nævnte diagram vises EC2 Auto Scaling Groups (ASG) ikke. Som navnet antyder, er det ansvarligt for skalering af instanser. Indtil for nylig var der ikke en indbygget mulighed i AWS for at styre antallet af kørende maskiner fra ECS. ECS tillod skalering af antallet af opgaver baseret på CPU-, RAM-brug eller antallet af forespørgsler. Men hvis opgaverne beslaglagde alle ledige instanser, blev der automatisk ikke oprettet nye maskiner.

Dette ændrede sig med indførelsen af ECS Capacity Providers (ECS CP). Nu kan hver service i ECS knyttes til ASG, og hvis opgaverne ikke kan passe på de kørende instanser, vil der blive oprettet nye (men inden for de satte grænser for ASG). Dette fungerer også i den modsatte retning; hvis ECS CP ser inaktive instanser uden opgaver, vil den give ASG besked om at slukke dem. ECS CP har mulighed for at angive en målopteringsprocent for instanserne, så et vist antal maskiner altid er ledige til hurtig skalering af opgaver, som jeg vil fortælle mere om lidt senere.

EC2 Launch Templates

Den sidste service, jeg vil tale om, inden jeg går videre til en detaljeret beskrivelse af oprettelsen af denne infrastruktur, er EC2 Launch Templates. Den gør det muligt at oprette en skabelon, som alle maskiner vil blive startet ud fra, så man ikke behøver at gøre det fra bunden hver gang. Her kan man vælge typen af maskine, sikkerhedsgruppe, diskbillede og mange andre parametre. Man kan også angive brugerdata, som vil blive installeret på alle kørende instanser. I brugerdataene kan man køre scripts, for eksempel kan man redigere indholdet af filen konfigurationsfilen for ECS-agenten.

En af de vigtigste konfigurationsparametre i denne artikel er ECS_ENABLE_SPOT_INSTANCE_DRAINING=true. Hvis denne parameter er aktiveret, vil ECS, så snart det modtager signal om, at den spotinstans bliver taget tilbage, ændre status for alle opgaver, der kører på den, til Draining. Ingen nye opgaver vil blive tildelt denne instans, og hvis der er opgaver, der ønsker at køre på den, bliver de annulleret. Anmodninger fra load balancer stopper også med at komme. Underretning om fjernelse af instansen kommer 2 minutter før den faktiske begivenhed. Derfor, hvis din service ikke udfører opgaver i længere tid end 2 minutter og ikke gemmer noget på disken, kan du bruge spotinstanser uden datatab.

Hvad angår disken - AWS har for nylig gjort det muligt at bruge Elastic File System (EFS) sammen med ECS, med denne opsætning er disken ikke en hindring, men vi har ikke prøvet det, da vi grundlæggende ikke har brug for en disk til at gemme tilstand. Som standard, efter at have modtaget SIGINT (som sendes på tidspunktet for overgangen af opgaven til status Draining), vil alle aktive opgaver blive stoppet inden for 30 sekunder, selvom de ikke har nået at blive færdige, dette tidsrum kan ændres med parameteren ECS_CONTAINER_STOP_TIMEOUT. Det er vigtigt ikke at sætte det til mere end 2 minutter for spotmaskiner.

Oprettelse af service

Lad os gå direkte til oprettelsen af den beskrevne service. Undervejs vil jeg også beskrive nogle nyttige punkter, som ikke blev nævnt ovenfor. Generelt er det en trin-for-trin vejledning, men jeg vil ikke dække nogle helt basale eller omvendt meget specifikke tilfælde. Alle handlinger udføres i AWS's visuelle konsol, men de kan også reproduceres programmatisk med CloudFormation eller Terraform. I Adapty bruger vi Terraform.

EC2 Launch Template

I denne service oprettes en konfiguration af maskiner, som vil blive brugt. Styring af skabeloner sker i afsnittet EC2 -> Instances -> Launch templates.

Amazon machine image (AMI) — vi angiver diskbilledet, som alle instanser vil blive startet med. For ECS er det i de fleste tilfælde bedst at bruge det optimerede billede fra Amazon. Det opdateres regelmæssigt og indeholder alt det nødvendige for at arbejde med ECS. For at finde den aktuelle ID for billedet går vi til siden Amazon ECS-optimized AMIs, vælger den region, vi bruger, og kopierer AMI ID for den. For eksempel, for regionen us-east-1 er den aktuelle ID på tidspunktet for skrivningen ami-00c7c1cf5bdc913ed. Denne ID skal indsættes under Angiv en brugerdefineret værdi.

Instance type — angiver instanstypen. Vælg den, der passer bedst til din opgave.

Nøglepar (login) — angiv certifikatet, der kan bruges til at oprette forbindelse til instansen via SSH, hvis det er nødvendigt.

Netværksindstillinger — angiv netværksparametre. Netværksplatform bør i de fleste tilfælde være Virtual Private Cloud (VPC). Sikkerhedsgrupper — sikkerhedsgrupper for dine instanser. Da vi vil bruge en belastningsbalancer foran instanserne, anbefaler jeg at angive her en gruppe, der tillader indgående forbindelser kun fra belastningsbalanceren. Du vil have to sikkerhedsgrupper, én til belastningsbalanceren, der tillader indgående (inbound) forbindelser fra overalt på porte 80 (http) og 443 (https), og den anden til maskiner, der tillader indgående forbindelser på alle porte fra belastningsbalancerens gruppe. Udgående (outbound) forbindelser i begge grupper skal åbnes over TCP-protokollen til alle porte på alle adresser. Du kan begrænse porte og adresser for udgående forbindelser, men så skal du konstant overvåge, at du ikke forsøger at kontakte noget over en lukket port.

Lagring (volumener) — angiv diskparametrene for maskinerne. Diskens størrelse må ikke være mindre end det, der er angivet i AMI, for ECS-Optimeret — 30 GiB.

Avancerede detaljer — angiv yderligere parametre.

Købsoption — vil vi købe spot-instancer. Vi ønsker det, men her vil vi ikke markere denne afkrydsningsfelt; vi indstiller det i Auto Scaling Group, hvor der er flere muligheder.

IAM instansprofil — angiv den rolle, som instanserne vil blive startet med. For at instanserne kan fungere i ECS, har de brug for rettigheder, som normalt ligger i rollen ecsInstanceRole. I nogle tilfælde kan den blive oprettet, hvis ikke, så her instruktion om hvordan man gør dette. Efter oprettelse angiver vi den i skabelonen.
Derefter følger mange parametre, hvor de fleste værdier kan efterlades som standard, men hver af dem har en forståelig beskrivelse. Jeg aktiverer altid parametrene EBS-optimeret instans og T2/T3 Ubegrænset, hvis der bruges burstable instanser.

Brugerdata — angiv brugerdata. Vi vil redigere filen /etc/ecs/ecs.config, der indeholder konfigurationen for ECS-agenten.
Et eksempel på, hvordan brugerdata kan se ud:

#!/bin/bash
echo ECS_CLUSTER=DemoApiClusterProd >> /etc/ecs/ecs.config
echo ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> /etc/ecs/ecs.config
echo ECS_CONTAINER_STOP_TIMEOUT=1m >> /etc/ecs/ecs.config
echo ECS_ENGINE_AUTH_TYPE=docker >> /etc/ecs/ecs.config
echo "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> /etc/ecs/ecs.config

ECS_CLUSTER=DemoApiClusterProd — parameter indicates that the instance belongs to a cluster with a specified name, meaning this cluster can run its tasks on this server. We haven't created a cluster yet, but we will use this name when creating one.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameter indicates that when a signal to shut down the spot instance is received, all tasks on it should be changed to the Draining status.

ECS_CONTAINER_STOP_TIMEOUT=1m — parameter indicates that after receiving the SIGINT signal, all tasks have 1 minute before they are terminated.

ECS_ENGINE_AUTH_TYPE=docker — parameter indicates that the docker scheme is used as the authorization mechanism.

ECS_ENGINE_AUTH_DATA=... — parameters for connecting to a private container registry where your Docker images are stored. If it is public, nothing needs to be specified.

In this article, I will use a public image from Docker Hub, so I won't specify the parameters. ECS_ENGINE_AUTH_TYPE og ECS_ENGINE_AUTH_DATA not required.

It is good to know: it is recommended to regularly update the AMI, as new versions update the versions of Docker, Linux, ECS agent, etc. To remember this, you can set up notifications about the release of new versions. You can receive notifications via email and update manually, or you can write a Lambda function that will automatically create a new version of the Launch Template with the updated AMI.

EC2 Auto Scaling Group

The Auto Scaling Group is responsible for launching and scaling instances. Management of groups occurs in the EC2 -> Auto Scaling -> Auto Scaling Groups section.

Launch template — choose the template created in the previous step. Leave the version set to default.

Purchase options and instance types — specify the instance types for the cluster. Adhere to launch template uses the instance type from the Launch Template. Combine purchase options and instance types allows flexible configuration of instance types. We will use it.

Optional On-Demand base — the number of standard, non-spot instances that will always run.

On-Demand percentage above base — the percentage ratio of standard and spot instances, 50-50 will distribute evenly, 20-80 will deploy 4 spot instances for each standard instance. In this example, I will indicate 50-50, but in reality, we most often do 20-80, in some cases 0-100.

Instance types — her kan du angive yderligere typer af instanser, der vil blive brugt i klyngen. Vi har aldrig brugt det, fordi jeg ikke helt forstår meningen med denne funktion. Måske handler det om grænser for specifikke typer af instanser, men de kan nemt øges gennem support. Hvis du kender anvendelsen, vil jeg gerne læse det i kommentarerne)

Netværk — netværksindstillinger, vælg VPC og undernet til maskiner, i de fleste tilfælde bør du vælge alle tilgængelige undernet.

Lastbalancering — indstillinger for belastningsbalancereren, men det vil vi gøre separat, her rører vi ikke ved noget. Health checks vil også blive konfigureret senere.

Group size — vi angiver grænser for antallet af maskiner i klyngen og det ønskede antal maskiner ved opstart. Antallet af maskiner i klyngen vil aldrig blive mindre end den minimumsangivne og større end den maksimale, selvom metrikkerne skulle indikere en skalering.

Scaling policies — skaleringsparametre, men vi vil skalere baseret på de kørende ECS-opgaver, derfor konfigurerer vi skaleringen senere.

Instance scale-in protection — beskyttelse af instanser mod sletning ved nedskaleringshandlinger. Vi aktiverer det for at sikre, at ASG ikke sletter en maskine, som har aktive opgaver. Beskyttelsen vil blive deaktiveret for instanser uden opgaver af ECS Capacity Provider.

Add tags — du kan angive tags for instanser (for dette skal boksen Tag new instances være tjekket). Jeg anbefaler at angive tagget Name, da alle instanser, der startes inden for gruppen, vil have samme navn, hvilket gør det nemt at se dem i konsollen.

Efter oprettelse af gruppen, åbn den, og gå til afsnittet Advanced configurations, da ikke alle muligheder ses i konsollen under oprettelsen.

Termination policies — regler, der tages i betragtning ved sletning af instanser. De anvendes i rækkefølge. Vi bruger normalt dem, som vist på billedet nedenfor. Først slettes instanser med den ældste Launch Template (for eksempel, hvis vi har opdateret AMI, vil der blive oprettet en ny version, men alle instanser har nået at overgå til den). Derefter vælges instanser, der ligger tættest på næste faktureringscyklus. Og til sidst vælges de ældste baseret på opstartsdatum.

It is good to know: for at opdatere alle maskiner i klyngen, er det praktisk at bruge Instance RefreshHvis du kombinerer dette med Lambda-funktionen fra det forrige trin, vil du have et fuldt automatiseret system til opdatering af instanser. Før opdateringen af alle maskiner skal instans scale-in-beskyttelse deaktiveres for alle instanser i gruppen. Ikke kun indstillingen i gruppen, men specifikt beskyttelsen på selve maskinerne, som gøres under fanen Instansstyring.

Application Load Balancer og EC2 Target Group

Balancereren oprettes under EC2 → Load Balancing → Load Balancers. Vi vil bruge Application Load Balancer, og en sammenligning af de forskellige typer af balancere kan læses på servicesiden.

Lyttere — det giver mening at opsætte porte 80 og 443 og lave en omdirigering fra 80 til 443 ved hjælp af balancerens regler.

Tilgængelighedszoner — i de fleste tilfælde vælger vi alle tilgængelighedszoner.

Konfigurer sikkerhedsindstillinger — her angives SSL-certifikatet for balancereren, den mest bekvemme mulighed er at oprette certifikatet i ACM. Forskellene på Sikkerhedspolitik kan læses i dokumentationen, den valgte standardmulighed kan beholdes ELBSecurityPolicy-2016-08. Efter oprettelse af balancereren vil du se dens DNS-navn, som CNAME skal konfigureres for dit domæne. For eksempel ser det sådan ud i Cloudflare.

Security Group — vi opretter eller vælger en sikkerhedsgruppe til balancereren, detaljer om dette blev nævnt tidligere i sektionen EC2 Launch Template → Netværksindstillinger.

Target group — vi opretter en gruppe, der er ansvarlig for at rute anmodninger fra balancereren til maskinerne og kontrollere deres tilgængelighed for at erstatte dem i tilfælde af problemer. Target type skal være Instance, Protokol og Port uanset hvad, hvis du bruger HTTPS til kommunikation mellem balancereren og instanserne, skal certifikatet uploades til dem. I dette eksempel vælger vi at lade port 80 være uændret.

Health checks — parametre til kontrol af servicefunktionalitet. I den faktiske service skal dette være en separat anmodning, der implementerer vigtige dele af forretningslogikken; i dette eksempel vil jeg lade indstillingerne være standard. Du kan derefter vælge interval for anmodninger, timeout, koder for succesfulde svar osv. I vores eksempel angiver vi Succes koder 200-399, fordi Docker-billedet, der vil blive brugt, returnerer 304-koden.

Registrer mål — her vælges de maskiner til gruppen, men i vores tilfælde vil dette blive håndteret af ECS, så vi springer blot dette trin over.

It is good to know: på balancererniveau kan du aktivere logfiler, som vil blive gemt i S3 i et bestemt format. Derfra kan de eksporteres til tredjepartstjenester til analyse, eller man kan lave SQL-forespørgsler direkte på dataene i S3 med Athena. Det er praktisk og fungerer uden noget yderligere kode. Jeg anbefaler også at indstille sletning af logs fra S3-bucketen efter en angivet tidsperiode.

ECS Task Definition

I de tidligere trin har vi oprettet alt relateret til tjenesteinfrastrukturen, nu går vi videre til at beskrive de containere, vi skal køre. Dette gøres i sektionen ECS → Task Definitions.

Launch type compatibility — vælger EC2.

Task execution IAM role — vælger ecsTaskExecutionRole. Med denne skrives logfiler, der gives adgang til hemmelige variabler m.m.

I sektionen Container Definitions klikker vi på Add Container.

Billede — link til billedet med projektets kode, i dette eksempel vil jeg bruge et offentligt billede fra Docker Hub bitnami/node-example:0.0.1.

Memory Limits — hukommelsesgrænser for containeren. Hard Limit — hård grænse, hvis containeren overskrider den angivne værdi, vil kommandoen docker kill blive udført, og containeren vil straks blive dræbt. Soft Limit — blød grænse, containeren kan overskride den angivne værdi, men ved placering af opgaver på maskiner vil denne parameter blive taget i betragtning. For eksempel, hvis der er 4 GiB RAM på maskinen, og soft limit for containeren er 2048 MiB, så kan der maksimalt køres 2 opgaver med denne container på den maskine. Faktisk er 4 GiB RAM lidt mindre end 4096 MiB, det kan ses på fanen ECS Instances i klyngen. Soft limit må ikke være større end hard limit. Det er vigtigt at forstå, at hvis der er flere containere i en opgave, så summeres deres grænser.

Port mappings — i Host port angiver 0, det betyder, at porten vil blive tildelt dynamisk, og denne vil blive overvåget af Target Group. Container Port — porten, hvor din applikation kører, angives ofte i kommandolinjen til udførelse eller tildeles i koden til din applikation, Dockerfile osv. For vores eksempel bruger vi 3000, fordi den er angivet i Dockerfile det anvendte billede.

Health check — parametre til kontrol af containerens funktionalitet, ikke forveksles med den, der er indstillet i Target Group.

Miljø — miljøindstillinger. CPU units — ligner på hukommelsesgrænser, men handler om processoren. Hvert CPU-kerne svarer til 1024 enheder, så hvis serveren har en dual-core processor, og containeren har værdien 512, kan der køres 4 opgaver med denne container på én server. CPU-enheder svarer altid til antallet af kerner, og de kan ikke være lidt færre, som det er tilfældet med hukommelsen.

Command — kommandoen til at starte tjenesten inden i containeren, alle parametre angives med komma. Det kan være gunicorn, npm osv. Hvis ikke angivet, vil værdien fra CMD-direktivet i Dockerfile blive brugt. Vi angiver npm,start.

Miljøvariabler — containerens miljøvariabler. Disse kan være både almindelige tekstdata og hemmelige variabler fra Secrets Manager eller Parameter Store.

Lagring og Logning — her konfigurerer vi logning til CloudWatch Logs (tjeneste til logfiler fra AWS). For dette er det tilstrækkeligt at aktivere afkrydsningsfeltet Auto-configure CloudWatch Logs. Efter oprettelsen af Task Definition vil der automatisk blive oprettet en loggruppe i CloudWatch. Som standard opbevares loggene i denne gruppe uendeligt, jeg anbefaler at ændre opbevaringsperioden fra Never Expire til den ønskede periode. Dette gøres i CloudWatch Log-grupper, man skal klikke på den nuværende periode og vælge en ny.

ECS Cluster og ECS Capacity Provider

Vi går til sektionen ECS → Clusters for at oprette et cluster. Som skabelon vælger vi EC2 Linux + Networking.

Cluster-navn — meget vigtigt, vi angiver her det samme navn, som angivet i Launch Template under parameteren ECS_CLUSTER, i vores tilfælde — DemoApiClusterProd. Vi mærker afkrydsningsfeltet Create an empty cluster. Valgfrit kan Container Insights aktiveres for at se metrikker for tjenesterne i CloudWatch. Hvis du har gjort alt rigtigt, vil du i sektionen ECS Instances se de maskiner, der er oprettet i Auto Scaling-gruppen.

Vi går til fanen Capacity Providers og opretter en ny. Jeg vil minde om, at den er nødvendig for at styre oprettelsen og slukningen af maskiner afhængig af antallet af kørende ECS-opgaver. Det er vigtigt at bemærke, at leverandøren kun kan knyttes til én gruppe.

Auto Scaling-gruppe — vi vælger den tidligere oprettede gruppe.

Managed scaling — aktiveres, så leverandøren kan skalere tjenesten.

Målkapacitet % — hvilken procent belastning af maskinerne kræver vi til opgaverne? Hvis du angiver 100%, vil alle maskiner altid være optaget af aktive opgaver. Hvis du angiver 50%, vil halvdelen af maskinerne altid være ledige. I dette tilfælde, hvis der opstår et pludseligt hop i belastningen, vil nye opgaver straks gå til de ledige maskiner, uden at det er nødvendigt at vente på udrulning af instanser.

Administreret termineringbeskyttelse — vi aktiverer dette, denne parameter tillader udbyderen at fjerne beskyttelsen af instanser mod sletning. Dette sker, når der ikke er aktive opgaver på maskinen, og tillader Target capacity %.

ECS Service og opsætning af skalering

Sidste skridt:) For at oprette en service skal du gå ind i det tidligere oprettede cluster under fanen Tjenester.

Starttype — du skal klikke på Skift til kapacitetsudbyder strategi og vælge de tidligere oprettede udbydere.

Opgavebeskrivelse — vælg den tidligere oprettede opgavebeskrivelse og dens revision.

Servicenavn — for ikke at forveksle det, angiver vi altid det samme som opgavebeskrivelsen.

Servicetype — altid Replica.

Antal opgaver — det ønskede antal aktive opgaver i servicen. Denne parameter styres af skaleringen, men det er stadig nødvendigt at angive det.

Minimum sund procent og Maksimal procent — bestemmer opgavernes adfærd under udrulning. Standardværdierne er 100 og 200, hvilket betyder, at antallet af opgaver vil forøges med det dobbelte under udrulningen og derefter vende tilbage til det ønskede antal. Hvis du har 1 opgave, min=0, og max=100, så vil den under udrulningen blive afsluttet, og derefter bliver en ny opgave startet, hvilket vil resultere i en nedetid. Hvis 1 opgave kører, min=50, max=150, så vil udrulningen ikke finde sted, fordi 1 opgave ikke kan opdeles i to eller forøges med halvdelen.

Udrulningstype — lad os beholde Rolling update.

Placering skabeloner — regler for placering af opgaver på maskinerne. Som standard er det AZ Balanced Spread — det betyder, at hver ny opgave vil blive placeret på en ny instans, indtil alle maskiner i alle tilgængelighedszoner er oppe. Vi plejer at anvende BinPack - CPU og Spread - AZ; med denne politik placeres opgaverne så tæt som muligt på én maskine efter CPU. Hvis det er nødvendigt at oprette en ny maskine, bliver den oprettet i en ny tilgængelighedszone.

Load balancer type — vi vælger Application Load Balancer.

Service IAM rolle — vi vælger ecsServiceRole.

Load balancer navn — vi vælger den tidligere oprettede balancer.

Sundhedstjek grace periode — pause før udførelse af sundhedstjek efter udrulningen af den nye opgave; vi plejer at sætte den til 60 sekunder.

Container til load balancing — i punktet Målgruppe navn vælger vi den tidligere oprettede gruppe, og alt udfyldes automatisk.

Service Auto Scaling — parametre for servicestørrelse. Vælg Configure Service Auto Scaling for at justere din services ønskede antal. Angiv minimums- og maksimumsantallet af opgaver ved skalering.

IAM-rolle til Service Auto Scaling — vi vælger AWSServiceRoleForApplicationAutoScaling_ECSService.

Automatiske opgavestyringspolitikker — regler for skalering. Der er 2 typer:

Målsporing — sporing af målmetric (brug af CPU/RAM eller antal forespørgsler pr. opgave). For eksempel, vi ønsker, at den gennemsnitlige CPU-belastning skal være 85%, når den bliver højere, så nye opgaver vil blive tilføjet, indtil den når målværdien. Hvis belastningen er lavere, vil opgaver blive fjernet, medmindre beskyttelsen mod nedskalering er aktiveret (Deaktiver nedskala).
Step scaling — reaktion på en vilkårlig hændelse. Her kan du indstille reaktionen på enhver hændelse (CloudWatch Alarm), når den hændelse opstår, kan du tilføje eller fjerne det angivne antal opgaver, eller angive et præcist antal opgaver.

Tjenesten kan have flere skaleregler, hvilket kan være nyttigt, vigtigst er at sikre, at de ikke konflikter med hinanden.

Konklusion

Hvis du har fulgt instruktionerne og brugt det samme Docker-billede, skal din tjeneste returnere en sådan side.

Vi har oprettet en skabelon, som alle maskiner i tjenesten kører efter. Vi har også lært at opdatere maskinerne, når skabelonen ændres.
Vi har konfigureret håndtering af stopsignal for spotinstanser, så inden for et minut efter modtagelse af signalet fjernes alle kørende opgaver fra maskinen, så intet går tabt og intet afbrydes.
Vi har oprettet en belastningsbalancer for at fordele belastningen jævnt mellem maskinerne.
Vi har oprettet en tjeneste, der kører på spotinstanser, hvilket reducerer omkostningerne til maskinerne med cirka 3 gange.
Vi har konfigureret automatisk skalering begge veje for at håndtere øgede belastninger, men samtidig ikke betale for inaktivitet.
Vi bruger Capacity Provider, så applikationen styrer infrastrukturen (maskinerne) og ikke omvendt.
Vi gør det godt.

Hvis du har forudsigelige belastningsspidser, for eksempel hvis du annoncerer i en stor e-mail-kampagne, kan du indstille skalering efter tidsplan..

Du kan også foretage skalering baseret på data fra forskellige dele af dit system. For eksempel har vi funktionaliteten til at sende individuelle kampagnetilbud til brugere af mobilappen. Nogle gange sendes kampagnen til over 1M personer. Efter en sådan udsendelse ses der altid en stor stigning i API-forespørgsler, da mange brugere samtidigt logger ind på appen. Så hvis vi ser, at der er betydeligt flere forespørgsler i køen til at sende kampagne-push end de normale niveauer, kan vi straks starte flere ekstra maskiner og opgaver for at være klar til belastningen.

Jeg vil sætte pris på, hvis I deler interessante cases for brug af spot-instanser og ECS i kommentarerne, eller noget om skalering.

Snart kommer der artikler om, hvordan vi behandler tusindvis af analytiske hændelser per sekund på et primært serverløst stack (med penge) samt hvordan deployment af tjenester er struktureret ved hjælp af GitLab CI og Terraform Cloud.

Tilmeld dig vores, det bliver spændende!

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, please.