{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Oprettelse af et skalerbart API p\u00e5 AWS spotinstanser","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alle! Jeg hedder Kirill, og jeg er CTO hos Adapty. St\u00f8rstedelen af vores arkitektur ligger p\u00e5 AWS, og i dag vil jeg fort\u00e6lle om, hvordan vi reducerede serveromkostningerne med 3 gange ved at bruge spotinstanser i et produktionsmilj\u00f8, samt hvordan man ops\u00e6tter automatisk skalering af dem. F\u00f8rst vil der v\u00e6re en overordnet gennemgang af, hvordan det fungerer, og derefter en detaljeret vejledning til opstart.<\/p>\n

<\/p>\n

Hvad er spotinstanser?<\/h2>\n

<\/p>\n

Spotinstanser<\/a><\/noindex> er servere fra andre AWS-brugere, som i \u00f8jeblikket er ledige, og de s\u00e6lger dem med en stor rabat (Amazon skriver op til 90%, men if\u00f8lge vores erfaring er det cirka 3x, varierende afh\u00e6ngig af region, tilg\u00e6ngelighedszoner og instanstype). Den prim\u00e6re forskel fra almindelige instanser er, at de kan slukkes n\u00e5r som helst. Derfor har vi l\u00e6nge ment, at det var acceptabelt at bruge dem til udviklingsmilj\u00f8er eller til beregning af noget, mens man gemmer mellemliggende resultater p\u00e5 S3 eller i en database, men ikke til produktion. Der findes tredjepartsl\u00f8sninger, der tillader brug af spotinstanser i produktionen, men der er mange udfordringer for vores tilf\u00e6lde, s\u00e5 vi implementerede dem ikke. Tilgangen beskrevet i artiklen fungerer fuldt ud inden for AWS's standardfunktionalitet, uden yderligere scripts, cron-jobs osv.<\/p>\n

<\/a><\/noindex><\/p>\n

Her er et par sk\u00e6rmbilleder, der viser prisudviklingen for spotinstanser.<\/p>\n

<\/p>\n

m5.large i regionen eu-west-1 (Irland). Prisen har v\u00e6ret overvejende stabil i 3 m\u00e5neder, og i \u00f8jeblikket er besparelsen 2.9x.<\/p>\n

<\/p>\n

\"Oprettelse<\/p>\n

<\/p>\n

m5.large i regionen us-east-1 (N. Virginia). Prisen \u00e6ndrer sig konstant i l\u00f8bet af 3 m\u00e5neder, og i \u00f8jeblikket er besparelsen fra 2.3x til 2.8x afh\u00e6ngig af tilg\u00e6ngelighedszonen.<\/p>\n

<\/p>\n

\"Oprettelse<\/p>\n

<\/p>\n

t3.small i regionen us-east-1 (N. Virginia). Prisen har v\u00e6ret stabil i 3 m\u00e5neder, og i \u00f8jeblikket er besparelsen 3.4x.<\/p>\n

<\/p>\n

\"Oprettelse<\/p>\n

<\/p>\n

Tjenestearkitektur<\/h2>\n

<\/p>\n

Den grundl\u00e6ggende arkitektur for den tjeneste, vi skal tale om i denne artikel, er vist i diagrammet herunder.<\/p>\n

<\/p>\n

\"Oprettelse<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

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

<\/p>\n

P\u00e5 \u00e9n instans kan der v\u00e6re flere k\u00f8rende containere med de samme porte, s\u00e5 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\u00e5 instansen og tildeler en af dem til den k\u00f8rende opgave. TG tjekker ogs\u00e5 regelm\u00e6ssigt, om instansen og API'en fungerer korrekt via health check, og hvis den opdager problemer, stopper den med at sende foresp\u00f8rgsler dertil.<\/p>\n

<\/p>\n

EC2 Auto Scaling Groups + ECS Capacity Providers<\/h3>\n

<\/p>\n

I den ovenfor n\u00e6vnte 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\u00f8rende maskiner fra ECS. ECS tillod skalering af antallet af opgaver baseret p\u00e5 CPU-, RAM-brug eller antallet af foresp\u00f8rgsler. Men hvis opgaverne beslaglagde alle ledige instanser, blev der automatisk ikke oprettet nye maskiner.<\/p>\n

<\/p>\n

Dette \u00e6ndrede sig med indf\u00f8relsen af ECS Capacity Providers (ECS CP). Nu kan hver service i ECS knyttes til ASG, og hvis opgaverne ikke kan passe p\u00e5 de k\u00f8rende instanser, vil der blive oprettet nye (men inden for de satte gr\u00e6nser for ASG). Dette fungerer ogs\u00e5 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\u00e5lopteringsprocent for instanserne, s\u00e5 et vist antal maskiner altid er ledige til hurtig skalering af opgaver, som jeg vil fort\u00e6lle mere om lidt senere.<\/p>\n

<\/p>\n

EC2 Launch Templates<\/h3>\n

<\/p>\n

Den sidste service, jeg vil tale om, inden jeg g\u00e5r videre til en detaljeret beskrivelse af oprettelsen af denne infrastruktur, er EC2 Launch Templates. Den g\u00f8r det muligt at oprette en skabelon, som alle maskiner vil blive startet ud fra, s\u00e5 man ikke beh\u00f8ver at g\u00f8re det fra bunden hver gang. Her kan man v\u00e6lge typen af maskine, sikkerhedsgruppe, diskbillede og mange andre parametre. Man kan ogs\u00e5 angive brugerdata, som vil blive installeret p\u00e5 alle k\u00f8rende instanser. I brugerdataene kan man k\u00f8re scripts, for eksempel kan man redigere indholdet af filen konfigurationsfilen for ECS-agenten<\/a><\/noindex>.<\/p>\n

<\/p>\n

En af de vigtigste konfigurationsparametre i denne artikel er ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Hvis denne parameter er aktiveret, vil ECS, s\u00e5 snart det modtager signal om, at den spotinstans bliver taget tilbage, \u00e6ndre status for alle opgaver, der k\u00f8rer p\u00e5 den, til Draining. Ingen nye opgaver vil blive tildelt denne instans, og hvis der er opgaver, der \u00f8nsker at k\u00f8re p\u00e5 den, bliver de annulleret. Anmodninger fra load balancer stopper ogs\u00e5 med at komme. Underretning om fjernelse af instansen kommer 2 minutter f\u00f8r den faktiske begivenhed. Derfor, hvis din service ikke udf\u00f8rer opgaver i l\u00e6ngere tid end 2 minutter og ikke gemmer noget p\u00e5 disken, kan du bruge spotinstanser uden datatab.<\/p>\n

<\/p>\n

Hvad ang\u00e5r disken - AWS har for nylig gjort<\/a><\/noindex> det muligt at bruge Elastic File System (EFS) sammen med ECS, med denne ops\u00e6tning er disken ikke en hindring, men vi har ikke pr\u00f8vet det, da vi grundl\u00e6ggende ikke har brug for en disk til at gemme tilstand. Som standard, efter at have modtaget SIGINT (som sendes p\u00e5 tidspunktet for overgangen af opgaven til status Draining), vil alle aktive opgaver blive stoppet inden for 30 sekunder, selvom de ikke har n\u00e5et at blive f\u00e6rdige, dette tidsrum kan \u00e6ndres med parameteren ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Det er vigtigt ikke at s\u00e6tte det til mere end 2 minutter for spotmaskiner.<\/p>\n

<\/p>\n

Oprettelse af service<\/h2>\n

<\/p>\n

Lad os g\u00e5 direkte til oprettelsen af den beskrevne service. Undervejs vil jeg ogs\u00e5 beskrive nogle nyttige punkter, som ikke blev n\u00e6vnt ovenfor. Generelt er det en trin-for-trin vejledning, men jeg vil ikke d\u00e6kke nogle helt basale eller omvendt meget specifikke tilf\u00e6lde. Alle handlinger udf\u00f8res i AWS's visuelle konsol, men de kan ogs\u00e5 reproduceres programmatisk med CloudFormation eller Terraform. I Adapty bruger vi Terraform.<\/p>\n

<\/p>\n

EC2 Launch Template<\/strong><\/h3>\n

<\/p>\n

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

<\/p>\n

Amazon machine image (AMI)<\/strong> \u2014 vi angiver diskbilledet, som alle instanser vil blive startet med. For ECS er det i de fleste tilf\u00e6lde bedst at bruge det optimerede billede fra Amazon. Det opdateres regelm\u00e6ssigt og indeholder alt det n\u00f8dvendige for at arbejde med ECS. For at finde den aktuelle ID for billedet g\u00e5r vi til siden Amazon ECS-optimized AMIs<\/a><\/noindex>, v\u00e6lger den region, vi bruger, og kopierer AMI ID for den. For eksempel, for regionen us-east-1 er den aktuelle ID p\u00e5 tidspunktet for skrivningen ami-00c7c1cf5bdc913ed<\/em>. Denne ID skal inds\u00e6ttes under Angiv en brugerdefineret v\u00e6rdi.<\/p>\n

<\/p>\n

Instance type<\/strong> \u2014 angiver instanstypen. V\u00e6lg den, der passer bedst til din opgave.<\/p>\n

<\/p>\n

N\u00f8glepar (login)<\/strong> \u2014 angiv certifikatet, der kan bruges til at oprette forbindelse til instansen via SSH, hvis det er n\u00f8dvendigt.<\/p>\n

<\/p>\n

Netv\u00e6rksindstillinger<\/strong> \u2014 angiv netv\u00e6rksparametre. Netv\u00e6rksplatform<\/strong> b\u00f8r i de fleste tilf\u00e6lde v\u00e6re Virtual Private Cloud (VPC). Sikkerhedsgrupper<\/strong> \u2014 sikkerhedsgrupper for dine instanser. Da vi vil bruge en belastningsbalancer foran instanserne, anbefaler jeg at angive her en gruppe, der tillader indg\u00e5ende forbindelser kun fra belastningsbalanceren. Du vil have to sikkerhedsgrupper, \u00e9n til belastningsbalanceren, der tillader indg\u00e5ende (inbound) forbindelser fra overalt p\u00e5 porte 80 (http) og 443 (https), og den anden til maskiner, der tillader indg\u00e5ende forbindelser p\u00e5 alle porte fra belastningsbalancerens gruppe. Udg\u00e5ende (outbound) forbindelser i begge grupper skal \u00e5bnes over TCP-protokollen til alle porte p\u00e5 alle adresser. Du kan begr\u00e6nse porte og adresser for udg\u00e5ende forbindelser, men s\u00e5 skal du konstant overv\u00e5ge, at du ikke fors\u00f8ger at kontakte noget over en lukket port.<\/p>\n

<\/p>\n

Lagring (volumener)<\/strong> \u2014 angiv diskparametrene for maskinerne. Diskens st\u00f8rrelse m\u00e5 ikke v\u00e6re mindre end det, der er angivet i AMI, for ECS-Optimeret \u2014 30 GiB.<\/p>\n

<\/p>\n

Avancerede detaljer<\/strong> \u2014 angiv yderligere parametre.<\/p>\n

<\/p>\n

K\u00f8bsoption<\/strong> \u2014 vil vi k\u00f8be spot-instancer. Vi \u00f8nsker det, men her vil vi ikke markere denne afkrydsningsfelt; vi indstiller det i Auto Scaling Group, hvor der er flere muligheder.<\/p>\n

<\/p>\n

IAM instansprofil<\/strong> \u2014 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<\/em>. I nogle tilf\u00e6lde kan den blive oprettet, hvis ikke, s\u00e5 her instruktion<\/a><\/noindex> om hvordan man g\u00f8r dette. Efter oprettelse angiver vi den i skabelonen.
\nDerefter f\u00f8lger mange parametre, hvor de fleste v\u00e6rdier kan efterlades som standard, men hver af dem har en forst\u00e5elig beskrivelse. Jeg aktiverer altid parametrene EBS-optimeret instans og T2\/T3 Ubegr\u00e6nset, hvis der bruges burstable<\/a><\/noindex> instanser.<\/p>\n

<\/p>\n

Brugerdata<\/strong> \u2014 angiv brugerdata. Vi vil redigere filen \/etc\/ecs\/ecs.config<\/code>, der indeholder konfigurationen for ECS-agenten.
\nEt eksempel p\u00e5, hvordan brugerdata kan se ud:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 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.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 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.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 parameter indicates that after receiving the SIGINT signal, all tasks have 1 minute before they are terminated.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 parameter indicates that the docker scheme is used as the authorization mechanism.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 parameters for connecting to a private container registry where your Docker images are stored. If it is public, nothing needs to be specified.<\/p>\n
<\/p>\n
In this article, I will use a public image from Docker Hub, so I won't specify the parameters. ECS_ENGINE_AUTH_TYPE<\/code> og ECS_ENGINE_AUTH_DATA<\/code> not required.<\/p>\n
<\/p>\n
It is good to know<\/strong>: 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<\/a><\/noindex> 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.<\/p>\n
<\/p>\n
EC2 Auto Scaling Group<\/strong><\/h3>\n
<\/p>\n
The Auto Scaling Group is responsible for launching and scaling instances. Management of groups occurs in the EC2 -> Auto Scaling -> Auto Scaling Groups section.<\/p>\n
<\/p>\n
Launch template<\/strong> \u2014 choose the template created in the previous step. Leave the version set to default.<\/p>\n
<\/p>\n
Purchase options and instance types<\/strong> \u2014 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.<\/p>\n
<\/p>\n
Optional On-Demand base<\/strong> \u2014 the number of standard, non-spot instances that will always run.<\/p>\n
<\/p>\n
On-Demand percentage above base<\/strong> \u2014 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.<\/p>\n
<\/p>\n
Instance types<\/strong> \u2014 her kan du angive yderligere typer af instanser, der vil blive brugt i klyngen. Vi har aldrig brugt det, fordi jeg ikke helt forst\u00e5r meningen med denne funktion. M\u00e5ske handler det om gr\u00e6nser for specifikke typer af instanser, men de kan nemt \u00f8ges gennem support. Hvis du kender anvendelsen, vil jeg gerne l\u00e6se det i kommentarerne)<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Netv\u00e6rk<\/strong> \u2014 netv\u00e6rksindstillinger, v\u00e6lg VPC og undernet til maskiner, i de fleste tilf\u00e6lde b\u00f8r du v\u00e6lge alle tilg\u00e6ngelige undernet.<\/p>\n
<\/p>\n
Lastbalancering<\/strong> \u2014 indstillinger for belastningsbalancereren, men det vil vi g\u00f8re separat, her r\u00f8rer vi ikke ved noget. Health checks<\/strong> vil ogs\u00e5 blive konfigureret senere.<\/p>\n
<\/p>\n
Group size<\/strong> \u2014 vi angiver gr\u00e6nser for antallet af maskiner i klyngen og det \u00f8nskede antal maskiner ved opstart. Antallet af maskiner i klyngen vil aldrig blive mindre end den minimumsangivne og st\u00f8rre end den maksimale, selvom metrikkerne skulle indikere en skalering.<\/p>\n
<\/p>\n
Scaling policies<\/strong> \u2014 skaleringsparametre, men vi vil skalere baseret p\u00e5 de k\u00f8rende ECS-opgaver, derfor konfigurerer vi skaleringen senere.<\/p>\n
<\/p>\n
Instance scale-in protection<\/strong> \u2014 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.<\/p>\n
<\/p>\n
Add tags<\/strong> \u2014 du kan angive tags for instanser (for dette skal boksen Tag new instances v\u00e6re tjekket). Jeg anbefaler at angive tagget Name, da alle instanser, der startes inden for gruppen, vil have samme navn, hvilket g\u00f8r det nemt at se dem i konsollen.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Efter oprettelse af gruppen, \u00e5bn den, og g\u00e5 til afsnittet Advanced configurations, da ikke alle muligheder ses i konsollen under oprettelsen.<\/p>\n
<\/p>\n
Termination policies<\/strong> \u2014 regler, der tages i betragtning ved sletning af instanser. De anvendes i r\u00e6kkef\u00f8lge. Vi bruger normalt dem, som vist p\u00e5 billedet nedenfor. F\u00f8rst slettes instanser med den \u00e6ldste Launch Template (for eksempel, hvis vi har opdateret AMI, vil der blive oprettet en ny version, men alle instanser har n\u00e5et at overg\u00e5 til den). Derefter v\u00e6lges instanser, der ligger t\u00e6ttest p\u00e5 n\u00e6ste faktureringscyklus. Og til sidst v\u00e6lges de \u00e6ldste baseret p\u00e5 opstartsdatum.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
It is good to know<\/strong>: for at opdatere alle maskiner i klyngen, er det praktisk at bruge Instance Refresh<\/a><\/noindex>Hvis du kombinerer dette med Lambda-funktionen fra det forrige trin, vil du have et fuldt automatiseret system til opdatering af instanser. F\u00f8r opdateringen af alle maskiner skal instans scale-in-beskyttelse deaktiveres for alle instanser i gruppen. Ikke kun indstillingen i gruppen, men specifikt beskyttelsen p\u00e5 selve maskinerne, som g\u00f8res under fanen Instansstyring.<\/p>\n
<\/p>\n
Application Load Balancer og EC2 Target Group<\/h3>\n
<\/p>\n
Balancereren oprettes under EC2 \u2192 Load Balancing \u2192 Load Balancers. Vi vil bruge Application Load Balancer, og en sammenligning af de forskellige typer af balancere kan l\u00e6ses p\u00e5 servicesiden<\/a><\/noindex>.<\/p>\n
<\/p>\n
Lyttere<\/strong> \u2014 det giver mening at ops\u00e6tte porte 80 og 443 og lave en omdirigering fra 80 til 443 ved hj\u00e6lp af balancerens regler.<\/p>\n
<\/p>\n
Tilg\u00e6ngelighedszoner<\/strong> \u2014 i de fleste tilf\u00e6lde v\u00e6lger vi alle tilg\u00e6ngelighedszoner.<\/p>\n
<\/p>\n
Konfigurer sikkerhedsindstillinger<\/strong> \u2014 her angives SSL-certifikatet for balancereren, den mest bekvemme mulighed er at oprette certifikatet<\/a><\/noindex> i ACM. Forskellene p\u00e5 Sikkerhedspolitik<\/strong> kan l\u00e6ses i dokumentationen<\/a><\/noindex>, den valgte standardmulighed kan beholdes ELBSecurityPolicy-2016-08<\/code>. Efter oprettelse af balancereren vil du se dens DNS-navn<\/strong>, som CNAME skal konfigureres for dit dom\u00e6ne. For eksempel ser det s\u00e5dan ud i Cloudflare.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Security Group<\/strong> \u2014 vi opretter eller v\u00e6lger en sikkerhedsgruppe til balancereren, detaljer om dette blev n\u00e6vnt tidligere i sektionen EC2 Launch Template \u2192 Netv\u00e6rksindstillinger.<\/p>\n
<\/p>\n
Target group<\/strong> \u2014 vi opretter en gruppe, der er ansvarlig for at rute anmodninger fra balancereren til maskinerne og kontrollere deres tilg\u00e6ngelighed for at erstatte dem i tilf\u00e6lde af problemer. Target type<\/strong> skal v\u00e6re Instance, Protokol<\/strong> og Port<\/strong> uanset hvad, hvis du bruger HTTPS til kommunikation mellem balancereren og instanserne, skal certifikatet uploades til dem. I dette eksempel v\u00e6lger vi at lade port 80 v\u00e6re u\u00e6ndret.<\/p>\n
<\/p>\n
Health checks<\/strong> \u2014 parametre til kontrol af servicefunktionalitet. I den faktiske service skal dette v\u00e6re en separat anmodning, der implementerer vigtige dele af forretningslogikken; i dette eksempel vil jeg lade indstillingerne v\u00e6re standard. Du kan derefter v\u00e6lge 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.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Registrer m\u00e5l<\/strong> \u2014 her v\u00e6lges de maskiner til gruppen, men i vores tilf\u00e6lde vil dette blive h\u00e5ndteret af ECS, s\u00e5 vi springer blot dette trin over.<\/p>\n
<\/p>\n
It is good to know<\/strong>: p\u00e5 balancererniveau kan du aktivere logfiler, som vil blive gemt i S3 i et bestemt format<\/a><\/noindex>. Derfra kan de eksporteres til tredjepartstjenester til analyse, eller man kan lave SQL-foresp\u00f8rgsler direkte p\u00e5 dataene i S3 med Athena<\/a><\/noindex>. Det er praktisk og fungerer uden noget yderligere kode. Jeg anbefaler ogs\u00e5 at indstille sletning af logs fra S3-bucketen efter en angivet tidsperiode.<\/p>\n
<\/p>\n
ECS Task Definition<\/h3>\n
<\/p>\n
I de tidligere trin har vi oprettet alt relateret til tjenesteinfrastrukturen, nu g\u00e5r vi videre til at beskrive de containere, vi skal k\u00f8re. Dette g\u00f8res i sektionen ECS \u2192 Task Definitions.<\/p>\n
<\/p>\n
Launch type compatibility<\/strong> \u2014 v\u00e6lger EC2.<\/p>\n
<\/p>\n
Task execution IAM role<\/strong> \u2014 v\u00e6lger ecsTaskExecutionRole<\/code>. Med denne skrives logfiler, der gives adgang til hemmelige variabler m.m.<\/p>\n
<\/p>\n
I sektionen Container Definitions klikker vi p\u00e5 Add Container.<\/p>\n
<\/p>\n
Billede<\/strong> \u2014 link til billedet med projektets kode, i dette eksempel vil jeg bruge et offentligt billede fra Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Memory Limits<\/strong> \u2014 hukommelsesgr\u00e6nser for containeren. Hard Limit<\/strong> \u2014 h\u00e5rd gr\u00e6nse, hvis containeren overskrider den angivne v\u00e6rdi, vil kommandoen docker kill blive udf\u00f8rt, og containeren vil straks blive dr\u00e6bt. Soft Limit<\/strong> \u2014 bl\u00f8d gr\u00e6nse, containeren kan overskride den angivne v\u00e6rdi, men ved placering af opgaver p\u00e5 maskiner vil denne parameter blive taget i betragtning. For eksempel, hvis der er 4 GiB RAM p\u00e5 maskinen, og soft limit for containeren er 2048 MiB, s\u00e5 kan der maksimalt k\u00f8res 2 opgaver med denne container p\u00e5 den maskine. Faktisk er 4 GiB RAM lidt mindre end 4096 MiB, det kan ses p\u00e5 fanen ECS Instances i klyngen. Soft limit m\u00e5 ikke v\u00e6re st\u00f8rre end hard limit. Det er vigtigt at forst\u00e5, at hvis der er flere containere i en opgave, s\u00e5 summeres deres gr\u00e6nser.<\/p>\n
<\/p>\n
Port mappings<\/strong> \u2014 i Host port<\/strong> angiver 0, det betyder, at porten vil blive tildelt dynamisk, og denne vil blive overv\u00e5get af Target Group. Container Port<\/strong> \u2014 porten, hvor din applikation k\u00f8rer, angives ofte i kommandolinjen til udf\u00f8relse eller tildeles i koden til din applikation, Dockerfile osv. For vores eksempel bruger vi 3000, fordi den er angivet i Dockerfile<\/a><\/noindex> det anvendte billede.<\/p>\n
<\/p>\n
Health check<\/strong> \u2014 parametre til kontrol af containerens funktionalitet, ikke forveksles med den, der er indstillet i Target Group.<\/p>\n
<\/p>\n
Milj\u00f8<\/strong> \u2014 milj\u00f8indstillinger. CPU units<\/strong> \u2014 ligner p\u00e5 hukommelsesgr\u00e6nser, men handler om processoren. Hvert CPU-kerne svarer til 1024 enheder, s\u00e5 hvis serveren har en dual-core processor, og containeren har v\u00e6rdien 512, kan der k\u00f8res 4 opgaver med denne container p\u00e5 \u00e9n server. CPU-enheder svarer altid til antallet af kerner, og de kan ikke v\u00e6re lidt f\u00e6rre, som det er tilf\u00e6ldet med hukommelsen.<\/p>\n
<\/p>\n
Command<\/strong> \u2014 kommandoen til at starte tjenesten inden i containeren, alle parametre angives med komma. Det kan v\u00e6re gunicorn, npm osv. Hvis ikke angivet, vil v\u00e6rdien fra CMD-direktivet i Dockerfile blive brugt. Vi angiver npm,start<\/code>.<\/p>\n
<\/p>\n
Milj\u00f8variabler<\/strong> \u2014 containerens milj\u00f8variabler. Disse kan v\u00e6re b\u00e5de almindelige tekstdata og hemmelige variabler fra Secrets Manager<\/a><\/noindex> eller Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Lagring og Logning<\/strong> \u2014 her konfigurerer vi logning til CloudWatch Logs (tjeneste til logfiler fra AWS). For dette er det tilstr\u00e6kkeligt 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 \u00e6ndre opbevaringsperioden fra Never Expire til den \u00f8nskede periode. Dette g\u00f8res i CloudWatch Log-grupper, man skal klikke p\u00e5 den nuv\u00e6rende periode og v\u00e6lge en ny.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
ECS Cluster og ECS Capacity Provider<\/h3>\n
<\/p>\n
Vi g\u00e5r til sektionen ECS \u2192 Clusters for at oprette et cluster. Som skabelon v\u00e6lger vi EC2 Linux + Networking.<\/p>\n
<\/p>\n
Cluster-navn<\/strong> \u2014 meget vigtigt, vi angiver her det samme navn, som angivet i Launch Template under parameteren ECS_CLUSTER<\/code>, i vores tilf\u00e6lde \u2014 DemoApiClusterProd<\/code>. Vi m\u00e6rker 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.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Vi g\u00e5r til fanen Capacity Providers<\/strong> og opretter en ny. Jeg vil minde om, at den er n\u00f8dvendig for at styre oprettelsen og slukningen af maskiner afh\u00e6ngig af antallet af k\u00f8rende ECS-opgaver. Det er vigtigt at bem\u00e6rke, at leverand\u00f8ren kun kan knyttes til \u00e9n gruppe.<\/p>\n
<\/p>\n
Auto Scaling-gruppe<\/strong> \u2014 vi v\u00e6lger den tidligere oprettede gruppe.<\/p>\n
<\/p>\n
Managed scaling<\/strong> \u2014 aktiveres, s\u00e5 leverand\u00f8ren kan skalere tjenesten.<\/p>\n
<\/p>\n
M\u00e5lkapacitet %<\/strong> \u2014 hvilken procent belastning af maskinerne kr\u00e6ver vi til opgaverne? Hvis du angiver 100%, vil alle maskiner altid v\u00e6re optaget af aktive opgaver. Hvis du angiver 50%, vil halvdelen af maskinerne altid v\u00e6re ledige. I dette tilf\u00e6lde, hvis der opst\u00e5r et pludseligt hop i belastningen, vil nye opgaver straks g\u00e5 til de ledige maskiner, uden at det er n\u00f8dvendigt at vente p\u00e5 udrulning af instanser.<\/p>\n
<\/p>\n
Administreret termineringbeskyttelse<\/strong> \u2014 vi aktiverer dette, denne parameter tillader udbyderen at fjerne beskyttelsen af instanser mod sletning. Dette sker, n\u00e5r der ikke er aktive opgaver p\u00e5 maskinen, og tillader Target capacity %.<\/p>\n
<\/p>\n
ECS Service og ops\u00e6tning af skalering<\/h3>\n
<\/p>\n
Sidste skridt:) For at oprette en service skal du g\u00e5 ind i det tidligere oprettede cluster under fanen Tjenester.<\/p>\n
<\/p>\n
Starttype<\/strong> \u2014 du skal klikke p\u00e5 Skift til kapacitetsudbyder strategi og v\u00e6lge de tidligere oprettede udbydere.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Opgavebeskrivelse<\/strong> \u2014 v\u00e6lg den tidligere oprettede opgavebeskrivelse og dens revision.<\/p>\n
<\/p>\n
Servicenavn<\/strong> \u2014 for ikke at forveksle det, angiver vi altid det samme som opgavebeskrivelsen.<\/p>\n
<\/p>\n
Servicetype<\/strong> \u2014 altid Replica.<\/p>\n
<\/p>\n
Antal opgaver<\/strong> \u2014 det \u00f8nskede antal aktive opgaver i servicen. Denne parameter styres af skaleringen, men det er stadig n\u00f8dvendigt at angive det.<\/p>\n
<\/p>\n
Minimum sund procent<\/strong> og Maksimal procent<\/strong> \u2014 bestemmer opgavernes adf\u00e6rd under udrulning. Standardv\u00e6rdierne er 100 og 200, hvilket betyder, at antallet af opgaver vil for\u00f8ges med det dobbelte under udrulningen og derefter vende tilbage til det \u00f8nskede antal. Hvis du har 1 opgave, min=0, og max=100, s\u00e5 vil den under udrulningen blive afsluttet, og derefter bliver en ny opgave startet, hvilket vil resultere i en nedetid. Hvis 1 opgave k\u00f8rer, min=50, max=150, s\u00e5 vil udrulningen ikke finde sted, fordi 1 opgave ikke kan opdeles i to eller for\u00f8ges med halvdelen.<\/p>\n
<\/p>\n
Udrulningstype<\/strong> \u2014 lad os beholde Rolling update.<\/p>\n
<\/p>\n
Placering skabeloner<\/strong> \u2014 regler for placering af opgaver p\u00e5 maskinerne. Som standard er det AZ Balanced Spread \u2014 det betyder, at hver ny opgave vil blive placeret p\u00e5 en ny instans, indtil alle maskiner i alle tilg\u00e6ngelighedszoner er oppe. Vi plejer at anvende BinPack - CPU og Spread - AZ; med denne politik placeres opgaverne s\u00e5 t\u00e6t som muligt p\u00e5 \u00e9n maskine efter CPU. Hvis det er n\u00f8dvendigt at oprette en ny maskine, bliver den oprettet i en ny tilg\u00e6ngelighedszone.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Load balancer type<\/strong> \u2014 vi v\u00e6lger Application Load Balancer.<\/p>\n
<\/p>\n
Service IAM rolle<\/strong> \u2014 vi v\u00e6lger ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Load balancer navn<\/strong> \u2014 vi v\u00e6lger den tidligere oprettede balancer.<\/p>\n
<\/p>\n
Sundhedstjek grace periode<\/strong> \u2014 pause f\u00f8r udf\u00f8relse af sundhedstjek efter udrulningen af den nye opgave; vi plejer at s\u00e6tte den til 60 sekunder.<\/p>\n
<\/p>\n
Container til load balancing<\/strong> \u2014 i punktet M\u00e5lgruppe navn v\u00e6lger vi den tidligere oprettede gruppe, og alt udfyldes automatisk.<\/p>\n
<\/p>\n
\"Oprettelse<\/p>\n
<\/p>\n
Service Auto Scaling<\/strong> \u2014 parametre for servicest\u00f8rrelse. V\u00e6lg Configure Service Auto Scaling for at justere din services \u00f8nskede antal. Angiv minimums- og maksimumsantallet af opgaver ved skalering.<\/p>\n
<\/p>\n
IAM-rolle til Service Auto Scaling<\/strong> \u2014 vi v\u00e6lger AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automatiske opgavestyringspolitikker<\/strong> \u2014 regler for skalering. Der er 2 typer:<\/p>\n
<\/p>\n
    \n
  1. M\u00e5lsporing<\/strong> \u2014 sporing af m\u00e5lmetric (brug af CPU\/RAM eller antal foresp\u00f8rgsler pr. opgave). For eksempel, vi \u00f8nsker, at den gennemsnitlige CPU-belastning skal v\u00e6re 85%, n\u00e5r den bliver h\u00f8jere, s\u00e5 nye opgaver vil blive tilf\u00f8jet, indtil den n\u00e5r m\u00e5lv\u00e6rdien. Hvis belastningen er lavere, vil opgaver blive fjernet, medmindre beskyttelsen mod nedskalering er aktiveret (Deaktiver nedskala<\/strong>).<\/li>\n
  2. Step scaling<\/strong> \u2014 reaktion p\u00e5 en vilk\u00e5rlig h\u00e6ndelse. Her kan du indstille reaktionen p\u00e5 enhver h\u00e6ndelse (CloudWatch Alarm), n\u00e5r den h\u00e6ndelse opst\u00e5r, kan du tilf\u00f8je eller fjerne det angivne antal opgaver, eller angive et pr\u00e6cist antal opgaver.<\/li>\n<\/ol>\n
    <\/p>\n
    Tjenesten kan have flere skaleregler, hvilket kan v\u00e6re nyttigt, vigtigst er at sikre, at de ikke konflikter med hinanden.<\/p>\n
    <\/p>\n
    Konklusion<\/h2>\n
    <\/p>\n
    Hvis du har fulgt instruktionerne og brugt det samme Docker-billede, skal din tjeneste returnere en s\u00e5dan side.<\/p>\n
    <\/p>\n
    \"Oprettelse<\/p>\n
    <\/p>\n
      \n
    1. Vi har oprettet en skabelon, som alle maskiner i tjenesten k\u00f8rer efter. Vi har ogs\u00e5 l\u00e6rt at opdatere maskinerne, n\u00e5r skabelonen \u00e6ndres.<\/li>\n
    2. Vi har konfigureret h\u00e5ndtering af stopsignal for spotinstanser, s\u00e5 inden for et minut efter modtagelse af signalet fjernes alle k\u00f8rende opgaver fra maskinen, s\u00e5 intet g\u00e5r tabt og intet afbrydes.<\/li>\n
    3. Vi har oprettet en belastningsbalancer for at fordele belastningen j\u00e6vnt mellem maskinerne.<\/li>\n
    4. Vi har oprettet en tjeneste, der k\u00f8rer p\u00e5 spotinstanser, hvilket reducerer omkostningerne til maskinerne med cirka 3 gange.<\/li>\n
    5. Vi har konfigureret automatisk skalering begge veje for at h\u00e5ndtere \u00f8gede belastninger, men samtidig ikke betale for inaktivitet.<\/li>\n
    6. Vi bruger Capacity Provider, s\u00e5 applikationen styrer infrastrukturen (maskinerne) og ikke omvendt.<\/li>\n
    7. Vi g\u00f8r det godt.<\/li>\n<\/ol>\n
      <\/p>\n
      Hvis du har forudsigelige belastningsspidser, for eksempel hvis du annoncerer i en stor e-mail-kampagne, kan du indstille skalering efter tidsplan.<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Du kan ogs\u00e5 foretage skalering baseret p\u00e5 data fra forskellige dele af dit system. For eksempel har vi funktionaliteten til at sende individuelle kampagnetilbud<\/a><\/noindex> til brugere af mobilappen. Nogle gange sendes kampagnen til over 1M personer. Efter en s\u00e5dan udsendelse ses der altid en stor stigning i API-foresp\u00f8rgsler, da mange brugere samtidigt logger ind p\u00e5 appen. S\u00e5 hvis vi ser, at der er betydeligt flere foresp\u00f8rgsler i k\u00f8en til at sende kampagne-push end de normale niveauer, kan vi straks starte flere ekstra maskiner og opgaver for at v\u00e6re klar til belastningen.<\/p>\n
      <\/p>\n
      Jeg vil s\u00e6tte pris p\u00e5, hvis I deler interessante cases for brug af spot-instanser og ECS i kommentarerne, eller noget om skalering.<\/p>\n
      <\/p>\n
      Snart kommer der artikler om, hvordan vi behandler tusindvis af analytiske h\u00e6ndelser per sekund p\u00e5 et prim\u00e6rt serverl\u00f8st stack (med penge) samt hvordan deployment af tjenester er struktureret ved hj\u00e6lp af GitLab CI og Terraform Cloud.<\/p>\n
      <\/p>\n
      Tilmeld dig vores, det bliver sp\u00e6ndende!<\/p>\n
      Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n
      Bruger I spot-instanser i produktionen?<\/h2>\n