Hei alle sammen! Jeg heter Kirill, jeg er CTO hos Adapty. Mesteparten av arkitekturen vår er på AWS, og i dag skal jeg snakke om hvordan vi reduserte serverkostnadene med 3 ganger ved å bruke spot-forekomster i et produksjonsmiljø, samt hvordan man setter opp deres automatiske skalering. Først vil det være en oversikt over hvordan det fungerer, og deretter detaljerte instruksjoner for å komme i gang.
Hva er Spot-forekomster?
instanser er servere til andre AWS-brukere som for øyeblikket er inaktive, og de selger dem til en stor rabatt (Amazon skriver opptil 90 %, etter vår erfaring ~3x, varierer avhengig av region, AZ og instanstype). Hovedforskjellen deres fra vanlige er at de kan slå seg av når som helst. Derfor trodde vi lenge at det var normalt å bruke dem til jomfruelige miljøer, eller til oppgaver med å beregne noe, med mellomresultater lagret på S3 eller i en database, men ikke for salg. Det finnes tredjepartsløsninger som lar deg bruke spots på produksjon, men det er mange krykker for vårt tilfelle, så vi implementerte dem ikke. Tilnærmingen beskrevet i artikkelen fungerer helt innenfor standard AWS-funksjonaliteten, uten ekstra skript, kroner osv.
Nedenfor er noen skjermbilder som viser prishistorikken for spotforekomster.
m5.stor i eu-west-1 (Irland) regionen. Prisen har stort sett vært stabil i 3 måneder, og sparer for tiden 2.9x.
m5.large i us-east-1 regionen (N. Virginia). Prisen endrer seg konstant over 3 måneder, og sparer for tiden fra 2.3x til 2.8x avhengig av tilgjengelighetssonen.
t3.small i us-east-1-regionen (N. Virginia). Prisen har vært stabil i 3 måneder, sparer for tiden 3.4x.
Tjenestearkitektur
Den grunnleggende arkitekturen til tjenesten som vi vil snakke om i denne artikkelen er vist i diagrammet nedenfor.
Application Load Balancer → EC2 Target Group → Elastic Container Service
Application Load Balancer (ALB) brukes som en balanserer, som sender forespørsler til EC2 Target Group (TG). TG er ansvarlig for å åpne porter på forekomster for ALB-er og koble dem til porter av Elastic Container Service (ECS)-containere. ECS er en analog av Kubernetes i AWS, som administrerer Docker-containere.
En instans kan ha flere kjørende containere med samme porter, så vi kan ikke sette dem fast. ECS forteller TG at den lanserer en ny oppgave (i Kubernetes terminologi kalles dette en pod), den sjekker for ledige porter på instansen og tildeler en av dem til den lanserte oppgaven. TG sjekker også regelmessig om instansen og API-en jobber med den ved hjelp av helsesjekk, og hvis den ser noen problemer, slutter den å sende forespørsler dit.
EC2 Auto Scaling Groups + ECS-kapasitetsleverandører
Diagrammet ovenfor viser ikke tjenesten EC2 Auto Scaling Groups (ASG). Fra navnet kan du forstå at det er ansvarlig for å skalere forekomster. Men inntil nylig hadde ikke AWS en innebygd evne til å administrere antall kjørende maskiner fra ECS. ECS gjorde det mulig å skalere antall oppgaver, for eksempel ved bruk av CPU, RAM eller antall forespørsler. Men hvis oppgaver okkuperte alle gratis forekomster, ble ikke nye maskiner opprettet automatisk.
Dette har endret seg med bruken av ECS Capacity Providers (ECS CP). Nå kan hver tjeneste i ECS assosieres med en ASG, og dersom oppgavene ikke passer på de kjørende instansene, så vil nye bli reist (men innenfor de fastsatte ASG-grensene). Dette fungerer også i motsatt retning, hvis ECS CP ser inaktive forekomster uten oppgaver, vil den gi ASG-kommandoen for å slå dem av. ECS CP har muligheten til å spesifisere en målprosent av forekomstbelastning, slik at et visst antall maskiner alltid er ledige for raske skaleringsoppgaver; jeg skal snakke om dette litt senere.
EC2-startmaler
Den siste tjenesten jeg skal snakke om før jeg går i detalj om å lage denne infrastrukturen er EC2 Launch Templates. Den lar deg lage en mal som alle maskiner starter i henhold til, for ikke å gjenta den fra bunnen av hver gang. Her kan du velge type maskin som skal startes, sikkerhetsgruppe, diskbilde og mange andre parametere. Du kan også spesifisere brukerdata som skal lastes opp til alle lanserte forekomster. Du kan kjøre skript i brukerdata, for eksempel kan du redigere innholdet i en fil .
En av de viktigste konfigurasjonsparametrene for denne artikkelen er =sant. Hvis denne parameteren er aktivert, så snart ECS mottar et signal om at en spotforekomst blir tatt bort, overfører den alle oppgaver som jobber med den til Dreneringsstatus. Ingen nye oppgaver vil bli tildelt denne forekomsten; hvis det er oppgaver som ønsker å bli rullet ut til den akkurat nå, vil de bli kansellert. Forespørsler fra balansereren slutter også å komme. Melding om instanssletting kommer 2 minutter før selve hendelsen. Derfor, hvis tjenesten din ikke utfører oppgaver lenger enn 2 minutter og ikke lagrer noe på disken, kan du bruke spotforekomster uten å miste data.
Angående disk - AWS nylig Det er mulig å bruke Elastic File System (EFS) sammen med ECS; med denne ordningen er til og med disken ikke en hindring, men vi prøvde ikke dette, siden vi i prinsippet ikke trenger disken for å lagre tilstanden. Som standard, etter å ha mottatt SIGINT (sendt når en oppgave overføres til Dreneringsstatus), vil alle kjørende oppgaver bli stoppet etter 30 sekunder, selv om de ikke er fullført ennå; du kan endre denne tiden ved å bruke parameteren . Det viktigste er ikke å stille den i mer enn 2 minutter for spotmaskiner.
Opprette en tjeneste
La oss gå videre til å lage den beskrevne tjenesten. I prosessen vil jeg i tillegg beskrive flere nyttige punkter som ikke ble nevnt ovenfor. Generelt er dette en trinn-for-trinn-instruksjon, men jeg vil ikke vurdere noen veldig grunnleggende eller tvert imot veldig spesifikke tilfeller. Alle handlinger utføres i AWS visuelle konsoll, men kan reproduseres programmatisk ved hjelp av CloudFormation eller Terraform. Hos Adapty bruker vi Terraform.
EC2-startmal
Denne tjenesten oppretter en konfigurasjon av maskiner som skal brukes. Maler administreres i delen EC2 -> Forekomster -> Startmaler.
Amazon-maskinbilde (AMI) — spesifiser diskbildet som alle forekomster skal startes med. For ECS er det i de fleste tilfeller verdt å bruke det optimaliserte bildet fra Amazon. Den oppdateres jevnlig og inneholder alt som er nødvendig for at ECS skal fungere. For å finne ut gjeldende bilde-ID, gå til siden , velg regionen du bruker og kopier AMI-IDen for den. For eksempel, for us-east-1-regionen, er gjeldende ID i skrivende stund ami-00c7c1cf5bdc913ed. Denne ID-en må settes inn i elementet Spesifiser en egendefinert verdi.
Forekomsttype — angi instanstypen. Velg den som passer best for din oppgave.
Nøkkelpar (pålogging) — spesifiser et sertifikat som du kan koble til instansen med via SSH, om nødvendig.
Nettverksinnstillinger — spesifiser nettverksparametrene. Nettverksplattform i de fleste tilfeller bør det være en Virtual Private Cloud (VPC). Sikkerhetsgrupper — sikkerhetsgrupper for dine forekomster. Siden vi skal bruke en balanseringsenhet foran instansene, anbefaler jeg å spesifisere en gruppe her som tillater innkommende tilkoblinger kun fra balanseringsenheten. Det vil si at du vil ha 2 sikkerhetsgrupper, en for balanseren, som tillater innkommende tilkoblinger fra hvor som helst på portene 80 (http) og 443 (https), og den andre for maskiner, som tillater innkommende tilkoblinger på alle porter fra balanseringsgruppen . Utgående tilkoblinger i begge grupper må åpnes ved hjelp av TCP-protokollen til alle porter til alle adresser. Du kan begrense porter og adresser for utgående tilkoblinger, men da må du hele tiden overvåke at du ikke prøver å få tilgang til noe på en lukket port.
Lagring (volum) — spesifiser diskparametrene for maskinene. Diskstørrelsen kan ikke være mindre enn den som er spesifisert i AMI; for ECS Optimized er den 30 GiB.
Avanserte detaljer — spesifisere tilleggsparametere.
Kjøpsmulighet — om vi ønsker å kjøpe spotforekomster. Vi vil, men vi vil ikke merke av denne boksen her; vi konfigurerer den i Auto Scaling Group, det er flere alternativer der.
IAM-forekomstprofil — angi rollen som forekomstene vil bli lansert med. For at forekomster skal kjøre i ECS, trenger de tillatelser, som vanligvis finnes i rollen ecsInstanceRole. I noen tilfeller kan det opprettes, hvis ikke, så her om hvordan du gjør dette. Etter opprettelsen angir vi det i malen.
Deretter er det mange parametere, i utgangspunktet kan du legge igjen standardverdier overalt, men hver av dem har en klar beskrivelse. Jeg aktiverer alltid den EBS-optimaliserte forekomsten og T2/T3 Unlimited-alternativene hvis de brukes forekomster.
Bruker tid — angi brukerdata. Vi vil redigere filen /etc/ecs/ecs.config, som inneholder ECS-agentkonfigurasjonen.
Et eksempel på hvordan brukerdata kan se ut:
#!/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.configECS_CLUSTER=DemoApiClusterProd — parameteren indikerer at forekomsten tilhører en klynge med det gitte navnet, det vil si at denne klyngen vil kunne plassere sine oppgaver på denne serveren. Vi har ikke opprettet en klynge ennå, men vi vil bruke dette navnet når vi oppretter det.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameteren spesifiserer at når et signal mottas for å slå av en spotforekomst, skal alle oppgaver på den overføres til Dreneringsstatus.
ECS_CONTAINER_STOP_TIMEOUT=1m - parameteren spesifiserer at etter å ha mottatt et SIGINT-signal, har alle oppgaver 1 minutt før de blir drept.
ECS_ENGINE_AUTH_TYPE=docker — parameteren indikerer at Docker-ordningen brukes som autorisasjonsmekanisme
ECS_ENGINE_AUTH_DATA=... — tilkoblingsparametere til det private containerregisteret, der Docker-bildene dine er lagret. Hvis den er offentlig, trenger du ikke spesifisere noe.
For formålet med denne artikkelen vil jeg bruke et offentlig bilde fra Docker Hub, så spesifiser parametrene ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA ikke behov.
Godt å vite: Det anbefales å oppdatere AMI regelmessig, fordi nye versjoner oppdaterer versjoner av Docker, Linux, ECS-agent, etc. For ikke å glemme dette, kan du om utgivelsen av nye versjoner. Du kan motta varsler på e-post og oppdatere manuelt, eller du kan skrive en Lambda-funksjon som automatisk oppretter en ny versjon av Launch Template med en oppdatert AMI.
EC2 Auto Scaling Group
Auto Scaling Group er ansvarlig for lansering og skalering av forekomster. Grupper administreres i delen EC2 -> Autoskalering -> Autoskaleringsgrupper.
Start mal — velg malen som ble opprettet i forrige trinn. Vi forlater standardversjonen.
Kjøpsalternativer og forekomsttyper – spesifiser typene forekomster for klyngen. Overhold lanseringsmalen bruker forekomsttypen fra Launch Template. Kombiner kjøpsalternativer og forekomsttyper lar deg konfigurere forekomsttyper fleksibelt. Vi vil bruke den.
Valgfri On-Demand base — antall vanlige, ikke-punktforekomster som alltid vil fungere.
On-Demand-prosent over base — prosentandel av vanlige og spotforekomster, 50-50 vil bli fordelt likt, 20-80 for hver vanlige forekomst vil 4 spot-en bli hevet. For formålet med dette eksemplet vil jeg indikere 50-50, men i virkeligheten gjør vi oftest 20-80, i noen tilfeller 0-100.
Forekomststyper — her kan du spesifisere flere typer forekomster som skal brukes i klyngen. Vi brukte det aldri fordi jeg egentlig ikke forstår meningen med historien. Kanskje skyldes dette grensene for spesifikke typer instanser, men de kan enkelt økes gjennom støtte. Hvis du kjenner applikasjonen, vil jeg gjerne lese den i kommentarene)
Network — nettverksinnstillinger, velg VPC og undernett for maskiner, i de fleste tilfeller bør du velge alle tilgjengelige undernett.
Lastbalansering - balanseringsinnstillinger, men vi vil gjøre dette separat, vi vil ikke røre noe her. Helsekontroller vil også bli konfigurert senere.
Gruppestørrelse — vi angir grensene for antall maskiner i klyngen og ønsket antall maskiner ved start. Antall maskiner i klyngen vil aldri være mindre enn minimum spesifisert og mer enn maksimum, selv om skalering skulle skje i henhold til metrikkene.
Skaleringspolitikk — skaleringsparametere, men vi vil skalere basert på de kjørende ECS-oppgavene, så vi vil konfigurere skaleringen senere.
Forekomst av innskaleringsbeskyttelse — beskyttelse av forekomster mot sletting ved nedskalering. Vi aktiverer det slik at ASG ikke sletter maskinen som har kjørende oppgaver. ECS Capacity Provider vil deaktivere beskyttelse for forekomster som ikke har oppgaver.
Legg til merkelapper — du kan spesifisere tagger for forekomster (for dette må avmerkingsboksen Tag new instances være merket). Jeg anbefaler å spesifisere Name tag, så vil alle forekomster som lanseres i gruppen ha samme navn, og det er praktisk å se dem i konsollen.
Etter å ha opprettet gruppen åpner du den og går til delen Avanserte konfigurasjoner Hvorfor ikke alle alternativer er synlige i konsollen på opprettelsesstadiet.
Retningslinjer for oppsigelse — regler som tas i betraktning ved sletting av forekomster. De brukes i rekkefølge. Vi bruker vanligvis de på bildet under. Først blir forekomster med den eldste lanseringsmalen slettet (hvis vi for eksempel oppdaterte AMI, opprettet vi en ny versjon, men alle forekomster klarte å bytte til den). Deretter velges instansene som er nærmest neste faktureringstime. Og så velges de eldste ut basert på lanseringsdato.
Godt å vite: for å oppdatere alle maskiner i en klynge, praktisk å bruke . Hvis du kombinerer dette med Lambda-funksjonen fra forrige trinn, vil du ha et helautomatisk instansoppdateringssystem. Før du oppdaterer alle maskiner, må du deaktivere instansskaleringsbeskyttelse for alle instanser i gruppen. Ikke konfigurasjon i gruppen, men beskyttelse fra selve maskinene, dette gjøres på fanen Instance management.
Application Load Balancer og EC2 Target Group
Balanseringsenheten opprettes i seksjonen EC2 → Lastbalansering → Lastbalansere. Vi vil bruke Application Load Balancer; en sammenligning av ulike typer balansere kan leses på .
lyttere - Det er fornuftig å lage portene 80 og 443 og omdirigere fra 80 til 443 ved å bruke balanseringsregler senere.
Tilgjengelighetssoner — i de fleste tilfeller velger vi tilgjengelighetssoner for alle.
Konfigurer sikkerhetsinnstillinger — SSL-sertifikatet for balanseren er angitt her, det mest praktiske alternativet er i ACM. Om forskjellene Sikkerhetspolitikk kan leses inn , kan du la den være valgt som standard ELBSecurityPolicy-2016-08. Etter å ha opprettet balanseren, vil du se den DNS-navn, som du trenger for å konfigurere CNAME for domenet ditt. Slik ser det for eksempel ut i Cloudflare.
Sikkerhetsgruppe — opprett eller velg en sikkerhetsgruppe for balanseren, jeg skrev mer om dette rett ovenfor i delen EC2 Launch Template → Nettverksinnstillinger.
Målgruppen — vi oppretter en gruppe som er ansvarlig for å dirigere forespørsler fra balansereren til maskiner og sjekke tilgjengeligheten deres for å erstatte dem i tilfelle problemer. Måltype må være Forekomst, Protokoll и Havn noen, hvis du bruker HTTPS for kommunikasjon mellom balanseren og forekomster, må du laste opp et sertifikat til dem. For formålet med dette eksemplet vil vi ikke gjøre dette, vi vil bare forlate port 80.
Helsekontroller — parametere for å kontrollere funksjonaliteten til tjenesten. I en ekte tjeneste bør dette være en egen forespørsel som implementerer viktige deler av forretningslogikken; for formålet med dette eksemplet vil jeg la standardinnstillingene stå. Deretter kan du velge forespørselsintervall, tidsavbrudd, suksesskoder osv. I vårt eksempel vil vi indikere suksesskoder 200-399, fordi Docker-bildet som skal brukes returnerer en 304-kode.
Registrer mål — her er bilene for gruppen valgt ut, men i vårt tilfelle vil dette gjøres av ECS, så vi hopper over dette trinnet.
Godt å vite: på balansernivå kan du aktivere logger som vil bli lagret i S3 i en viss tid . Derfra kan de eksporteres til tredjepartstjenester for analyse, eller du kan gjøre SQL-spørringer direkte på dataene i S3 med . Det er praktisk og fungerer uten tilleggskode. Jeg anbefaler også å sette opp fjerning av tømmerstokker fra S3-bøtta etter en spesifisert tidsperiode.
ECS-oppgavedefinisjon
I de forrige trinnene opprettet vi alt relatert til tjenesteinfrastrukturen; nå går vi videre til å beskrive containerne vi skal lansere. Dette gjøres i delen ECS → Oppgavedefinisjoner.
Kompatibilitet med lanseringstype - velg EC2.
Oppgaveutførelse IAM-rolle - velge ecsTaskExecutionRole. Ved å bruke den skrives logger, gis tilgang til hemmelige variabler osv.
I delen Beholderdefinisjoner klikker du på Legg til beholder.
Bilde - lenke til bildet med prosjektkoden; for dette eksemplet vil jeg bruke et offentlig bilde fra Docker Hub .
Minnegrenser — minnegrenser for beholderen. Hard grense — hard limit, hvis containeren går utover den angitte verdien, vil docker kill-kommandoen bli utført, containeren vil dø umiddelbart. Myk grense — myk grense, beholderen kan gå utover den angitte verdien, men denne parameteren vil bli tatt i betraktning når du plasserer oppgaver på maskiner. For eksempel, hvis en maskin har 4 GiB RAM, og den myke grensen for en beholder er 2048 MiB, kan denne maskinen ha maksimalt 2 kjørende oppgaver med denne beholderen. I virkeligheten er 4 GiB RAM litt mindre enn 4096 MiB, dette kan sees på ECS Instances-fanen i klyngen. Myk grense kan ikke være større enn hard limit. Det er viktig å forstå at hvis det er flere beholdere i en oppgave, blir grensene deres oppsummert.
Havnekartlegginger - inn Vertsport Vi angir 0, dette betyr at porten vil bli tildelt dynamisk og vil bli overvåket av målgruppen. Containerhavn — porten som applikasjonen din kjører på er ofte spesifisert i utførelseskommandoen, eller tilordnet i applikasjonskoden din, Dockerfile, etc. For eksempelet vårt bruker vi 3000 fordi det er oppført i bildet som brukes.
Helsesjekk — parametere for beholderhelsesjekk, ikke å forveksle med den som er konfigurert i målgruppen.
Miljø — miljøinnstillinger. CPU-enheter - ligner på minnegrenser, bare om prosessoren. Hver prosessorkjerne er på 1024 enheter, så hvis serveren har en dual-core prosessor og beholderen er satt til 512, kan 4 oppgaver med denne beholderen startes på én server. CPU-enheter tilsvarer alltid antall kjerner; det kan ikke være litt færre av dem, slik tilfellet er med minne.
Kommando — en kommando for å starte en tjeneste inne i en container, alle parametere er spesifisert atskilt med komma. Dette kan være Gunicorn, npm, etc. Hvis det ikke er spesifisert, vil verdien av CMD-direktivet fra Dockerfilen bli brukt. Vi indikerer npm,start.
Miljøvariabler — containermiljøvariabler. Dette kan enten være enkle tekstdata eller hemmelige variabler fra eller .
Lagring og logging – her setter vi opp logging i CloudWatch Logs (en tjeneste for logger fra AWS). For å gjøre dette, bare aktiver avmerkingsboksen Automatisk konfigurer CloudWatch-logger. Etter å ha opprettet oppgavedefinisjonen, opprettes en gruppe logger automatisk i CloudWatch. Som standard lagres logger i den på ubestemt tid; Jeg anbefaler at du endrer oppbevaringsperioden fra Utløper aldri til den nødvendige perioden. Dette gjøres i CloudWatch Log-grupper, du må klikke på gjeldende periode og velge en ny.
ECS Cluster og ECS Capacity Provider
Gå til delen ECS → Klynger for å opprette en klynge. Vi velger EC2 Linux + Networking som mal.
Klyngens navn - veldig viktig, vi lager her samme navn som spesifisert i Launch Template-parameteren ECS_CLUSTER, i vårt tilfelle - DemoApiClusterProd. Merk av for Opprett en tom klynge. Eventuelt kan du aktivere Container Insights for å se beregninger for tjenester i CloudWatch. Hvis du gjorde alt riktig, vil du i ECS-forekomster-delen se maskiner som ble opprettet i Auto Scaling-gruppen.
Gå til fanen Kapasitetsleverandører og lage en ny. La meg minne deg på at det er nødvendig for å kontrollere opprettelsen og nedleggelsen av maskiner avhengig av antall kjørende ECS-oppgaver. Det er viktig å merke seg at en leverandør kun kan tilordnes én gruppe.
Autoskaleringsgruppe — velg den tidligere opprettede gruppen.
Administrert skalering — aktiver det slik at leverandøren kan skalere tjenesten.
Målkapasitet % — hvor mange prosent av maskinene som er lastet med oppgaver trenger vi. Hvis du spesifiserer 100 %, vil alle maskiner alltid være opptatt med å kjøre oppgaver. Hvis du spesifiserer 50 %, så vil alltid halvparten av bilene være gratis. I dette tilfellet, hvis det er et kraftig hopp i lasten, vil nye drosjer umiddelbart komme til frie biler, uten å måtte vente på at instanser skal settes inn.
Administrert oppsigelsesbeskyttelse — aktiver, denne parameteren lar leverandøren fjerne beskyttelsen av forekomster fra sletting. Dette skjer når det ikke er noen aktive oppgaver på maskinen og tillater Target kapasitet %.
ECS Service og skaleringsoppsett
Siste trinn :) For å opprette en tjeneste, må du gå til den tidligere opprettede klyngen på fanen Tjenester.
Starttype — du må klikke på Bytt til kapasitetsleverandørstrategi og velge de tidligere opprettede leverandørene.
Oppgavedefinisjon — velg den tidligere opprettede oppgavedefinisjonen og dens revisjon.
Servicenavn — for å unngå forvirring, angir vi alltid det samme som Oppgavedefinisjon.
Tjenestetype - alltid replika.
Antall oppgaver — ønsket antall aktive oppgaver i tjenesten. Denne parameteren styres av skalering, men må fortsatt spesifiseres.
Minimum sunn prosent и Maksimal prosent — bestemme oppførselen til oppgaver under distribusjon. Standardverdiene er 100 og 200, noe som indikerer at antallet oppgaver vil øke flere ganger på tidspunktet for distribusjon, og deretter gå tilbake til ønsket verdi. Hvis du har 1 oppgave kjørende, min=0 og max=100, vil den under utrulling bli drept, og etter det vil en ny bli hevet, det vil si at det vil være nedetid. Hvis 1 oppgave kjører, min=50, maks=150, vil ikke distribusjon skje i det hele tatt, fordi 1 oppgave ikke kan deles i to eller økes med en og en halv gang.
Implementeringstype — la rullende oppdatering.
Plasseringsmaler — regler for plassering av oppgaver på maskiner. Standard er AZ Balanced Spread - dette betyr at hver ny oppgave vil bli plassert på en ny forekomst til maskiner i alle tilgjengelighetssoner stiger. Vi gjør vanligvis BinPack - CPU og Spread - AZ; med denne policyen plasseres oppgaver så tett som mulig på én maskin per CPU. Hvis det er nødvendig å opprette en ny maskin, opprettes den i en ny tilgjengelighetssone.
Type lastbalanser — velg Application Load Balancer.
Tjeneste IAM rolle - velge ecsServiceRole.
Lastbalansernavn — velg den tidligere opprettede balanseringsenheten.
Helsesjekk utsettelsesperiode — pause før du utfører helsesjekker etter utrulling av en ny oppgave, vi setter den vanligvis til 60 sekunder.
Beholder til lastebalanse — i Målgruppenavn-elementet, velg den tidligere opprettede gruppen, og alt fylles ut automatisk.
Tjeneste automatisk skalering — tjenesteskaleringsparametere. Velg Konfigurer automatisk tjenesteskalering for å justere tjenestens ønskede antall. Vi setter minimum og maksimum antall oppgaver ved skalering.
IAM-rolle for automatisk skalering av tjenester - velge AWSServiceRoleForApplicationAutoScaling_ECSService.
Politikker for automatisk oppgaveskalering — regler for skalering. Det er 2 typer:
- Målsporing — sporing av målberegninger (CPU/RAM-bruk eller antall forespørsler for hver oppgave). For eksempel ønsker vi at den gjennomsnittlige prosessorbelastningen skal være 85 %, når den blir høyere vil nye oppgaver legges til til den når målverdien. Hvis belastningen er lavere, vil oppgaver bli fjernet, tvert imot, med mindre beskyttelse mot nedskalering er aktivert (Deaktiver innskalering).
- Trinnskalering - reaksjon på en vilkårlig hendelse. Her kan du konfigurere en reaksjon på en hvilken som helst hendelse (CloudWatch Alarm), når den inntreffer kan du legge til eller fjerne spesifisert antall oppgaver, eller spesifisere nøyaktig antall oppgaver.
En tjeneste kan ha flere skaleringsregler, dette kan være nyttig, det viktigste er å sikre at de ikke kommer i konflikt med hverandre.
Konklusjon
Hvis du fulgte instruksjonene og brukte det samme Docker-bildet, bør tjenesten din returnere en side som denne.
- Vi har laget en mal som alle maskiner i tjenesten lanseres etter. Vi lærte også hvordan du oppdaterer maskiner når malen endres.
- Vi har konfigurert behandlingen av stoppsignalet for spotforekomsten, så innen et minutt etter at vi har mottatt det, fjernes alle kjørende oppgaver fra maskinen, slik at ingenting går tapt eller avbrutt.
- Vi hevet balansereren for å fordele belastningen jevnt over maskinene.
- Vi har laget en tjeneste som kjører på spot-instanser, noe som reduserer maskinkostnadene med ca. 3 ganger.
- Vi har konfigurert automatisk skalering i begge retninger for å håndtere økte arbeidsmengder uten å pådra oss nedetidskostnader.
- Vi bruker Capacity Provider slik at applikasjonen styrer infrastrukturen (maskiner) og ikke omvendt.
- Vi er flinke.
Hvis du har forutsigbare topper i belastningen, for eksempel annonserer du i en stor e-postkampanje, kan du sette opp skalering ved å .
Du kan også skalere basert på data fra ulike deler av systemet ditt. For eksempel har vi funksjonaliteten brukere av mobilapplikasjonen. Noen ganger sendes en kampanje til over 1 million personer. Etter en slik distribusjon er det alltid en stor økning i forespørsler til API, siden mange brukere logger seg på applikasjonen samtidig. Så hvis vi ser at det er betydelig flere standardindikatorer i køen for å sende salgsfremmende push-varsler, kan vi umiddelbart starte flere ekstra maskiner og oppgaver for å være klare for belastningen.
Jeg vil være glad hvis du forteller meg i kommentarene interessante tilfeller av bruk av spot-forekomster og ECS eller noe om skalering.
Snart vil det komme artikler om hvordan vi behandler tusenvis av analytiske hendelser per sekund på en overveiende serverløs stack (med penger) og hvordan utrullingen av tjenester fungerer ved hjelp av GitLab CI og Terraform Cloud.
Abonner på oss, det blir interessant!
Kun registrerte brukere kan delta i undersøkelsen. , vær så snill.
Bruker du spotforekomster i produksjonen?
-
22,2%Ja 6
-
66,7%No18
-
11,1%Jeg lærte om dem fra en artikkel og planlegger å bruke dem3
27 brukere stemte. 5 brukere avsto.
Kilde: www.habr.com