{"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\/sv\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Skapande av skalbar API p\u00e5 AWS spotinstanser","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej alla! Jag heter Kirill och jag \u00e4r CTO p\u00e5 Adapty. St\u00f6rsta delen av v\u00e5r arkitektur \u00e4r p\u00e5 AWS, och idag kommer jag att ber\u00e4tta hur vi har minskat serverkostnaderna med 3 g\u00e5nger genom att anv\u00e4nda spotinstanser i produktionsmilj\u00f6, samt hur man st\u00e4ller in autoskalning f\u00f6r dem. F\u00f6rst blir en \u00f6versikt \u00f6ver hur detta fungerar och sedan en detaljerad guide f\u00f6r att s\u00e4tta ig\u00e5ng.<\/p>\n

<\/p>\n

Vad \u00e4r spotinstanser?<\/h2>\n

<\/p>\n

Spotinstanser<\/a><\/noindex> \u00e4r servrar som tillh\u00f6r andra AWS-anv\u00e4ndare och som f\u00f6r n\u00e4rvarande st\u00e5r tomma, och de s\u00e4ljer dem med en stor rabatt (Amazon skriver upp till 90 %, men enligt v\u00e5r erfarenhet \u00e4r det ~3x, beroende p\u00e5 region, AZ och typ av instans). Den fr\u00e4msta skillnaden fr\u00e5n vanliga instanser \u00e4r att de kan st\u00e4ngas av n\u00e4r som helst. D\u00e4rf\u00f6r trodde vi l\u00e4nge att det var okej att anv\u00e4nda dem f\u00f6r utvecklingsmilj\u00f6er eller f\u00f6r ber\u00e4kningsuppgifter, med lagring av mellanresultat p\u00e5 S3 eller i en databas, men inte f\u00f6r produktion. Det finns tredjepartsl\u00f6sningar f\u00f6r att anv\u00e4nda spotinstanser i produktion, men de har m\u00e5nga begr\u00e4nsningar f\u00f6r v\u00e5rt fall, s\u00e5 vi implementerade inte dem. Metoden som beskrivs i artikeln fungerar helt inom standardfunktionaliteten f\u00f6r AWS, utan extra skript, cron-jobb etc.<\/p>\n

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

Nedan f\u00f6ljer n\u00e5gra sk\u00e4rmdumpar som visar prishistoriken f\u00f6r spotinstanser.<\/p>\n

<\/p>\n

m5.large i regionen eu-west-1 (Irland). Priset har huvudsakligen varit stabilt under 3 m\u00e5nader, just nu \u00e4r besparingen 2.9x.<\/p>\n

<\/p>\n

\"Skapande<\/p>\n

<\/p>\n

m5.large i regionen us-east-1 (N. Virginia). Priset \u00e4ndras kontinuerligt under 3 m\u00e5nader, just nu \u00e4r besparingen mellan 2.3x och 2.8x beroende p\u00e5 tillg\u00e4nglighetszon.<\/p>\n

<\/p>\n

\"Skapande<\/p>\n

<\/p>\n

t3.small i regionen us-east-1 (N. Virginia). Priset har varit stabilt under 3 m\u00e5nader, just nu \u00e4r besparingen 3.4x.<\/p>\n

<\/p>\n

\"Skapande<\/p>\n

<\/p>\n

Tj\u00e4nstens arkitektur<\/h2>\n

<\/p>\n

Den grundl\u00e4ggande arkitekturen f\u00f6r tj\u00e4nsten som vi kommer att diskutera i denna artikel visas i diagrammet nedan.<\/p>\n

<\/p>\n

\"Skapande<\/p>\n

<\/p>\n

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

<\/p>\n

Vi anv\u00e4nder Application Load Balancer (ALB) som balansr\u00e4knare, som skickar f\u00f6rfr\u00e5gningar till EC2 Target Group (TG). TG ansvarar f\u00f6r att \u00f6ppna portar p\u00e5 instanserna f\u00f6r ALB och koppla dem till portarna f\u00f6r Elastic Container Service (ECS) containrar. ECS \u00e4r motsvarigheten till Kubernetes i AWS som hanterar Docker-kontainrar.<\/p>\n

<\/p>\n

P\u00e5 en instans kan det finnas flera aktiva containrar med samma portar, s\u00e5 vi kan inte ange dem fast. ECS meddelar TG att den startar en ny uppgift (i Kubernetes-termer kallas det en pod), den g\u00f6r en kontroll av tillg\u00e4ngliga portar p\u00e5 instansen och tilldelar en av dem till den startade uppgiften. TG kontrollerar ocks\u00e5 regelbundet om instansen och API:t p\u00e5 den fungerar genom h\u00e4lsokontroll, och om den ser n\u00e5gra problem slutar den att skicka beg\u00e4rningar dit.<\/p>\n

<\/p>\n

EC2 Auto Scaling-grupper + ECS kapacitetsleverant\u00f6rer<\/h3>\n

<\/p>\n

I diagrammet ovan visas inte tj\u00e4nsten EC2 Auto Scaling-grupper (ASG). Av namnet kan man f\u00f6rst\u00e5 att den ansvarar f\u00f6r att skala instanser. Fram till nyligen fanns det ingen inbyggd m\u00f6jlighet i AWS att hantera antalet aktiva maskiner fr\u00e5n ECS. ECS till\u00e4t att skala antalet uppgifter, till exempel baserat p\u00e5 CPU-, RAM-anv\u00e4ndning eller antal beg\u00e4rningar. Men om uppgifterna tog upp alla fria instanser, s\u00e5 startades inga nya maskiner automatiskt.<\/p>\n

<\/p>\n

Detta \u00e4ndrades med introduktionen av ECS kapacitetsleverant\u00f6rer (ECS CP). Nu kan varje tj\u00e4nst i ECS kopplas till ASG, och om uppgifterna inte f\u00e5r plats p\u00e5 de aktiva instanserna startas nya (men inom de gr\u00e4nser som ASG har st\u00e4llt in). Detta fungerar ocks\u00e5 \u00e5t andra h\u00e5llet; om ECS CP ser inaktiva instanser utan uppgifter ger det en signal till ASG att st\u00e4nga av dem. ECS CP har m\u00f6jlighet att ange en m\u00e5lsatt procentandel av instansbelastningen, s\u00e5 att ett antal maskiner alltid \u00e4r fria f\u00f6r snabb skalning av uppgifter, vilket jag kommer att ber\u00e4tta mer om lite senare.<\/p>\n

<\/p>\n

EC2 startmallar<\/h3>\n

<\/p>\n

Den sista tj\u00e4nsten jag kommer att ber\u00e4tta om innan jag g\u00e5r in p\u00e5 en detaljerad beskrivning av skapandet av denna infrastruktur \u00e4r EC2 startmallar. Den g\u00f6r det m\u00f6jligt att skapa en mall som alla maskiner kommer att startas utifr\u00e5n, s\u00e5 att man inte beh\u00f6ver g\u00f6ra det fr\u00e5n grunden varje g\u00e5ng. H\u00e4r kan man v\u00e4lja typ av k\u00f6rd maskin, s\u00e4kerhetsgrupp, diskbild och m\u00e5nga andra parametrar. Man kan ocks\u00e5 ange anv\u00e4ndardata som kommer att laddas upp till alla startade instanser. I anv\u00e4ndardata kan man k\u00f6ra skript, till exempel kan man redigera inneh\u00e5llet i filen konfiguration av ECS-agenten<\/a><\/noindex>.<\/p>\n

<\/p>\n

En av de viktigaste konfigurationsparametrarna i denna artikel \u00e4r ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Om den h\u00e4r inst\u00e4llningen \u00e4r aktiverad, kommer ECS, s\u00e5 snart den f\u00e5r signalen om att en spot-instans tas bort, att \u00f6verf\u00f6ra alla uppgifter som k\u00f6rs p\u00e5 den till status Draining. Inga nya uppgifter kommer att tilldelas till denna instans, och om det finns uppgifter som just nu vill startas p\u00e5 den, kommer de att avbrytas. F\u00f6rfr\u00e5gningar fr\u00e5n lastbalanseraren slutar ocks\u00e5 komma. Aviseringen om borttagning av instansen kommer tv\u00e5 minuter innan den faktiska h\u00e4ndelsen. D\u00e4rf\u00f6r, om din tj\u00e4nst inte har uppgifter som p\u00e5g\u00e5r l\u00e4ngre \u00e4n 2 minuter och inte sparar n\u00e5gonting p\u00e5 disken, kan du anv\u00e4nda spot-instans utan risk f\u00f6r dataloss.<\/p>\n

<\/p>\n

N\u00e4r det g\u00e4ller disken \u2014 AWS har nyligen gjort<\/a><\/noindex> det m\u00f6jligt att anv\u00e4nda Elastic File System (EFS) tillsammans med ECS, med detta uppl\u00e4gg utg\u00f6r inte ens disken ett hinder, men vi har inte provat det eftersom vi i princip inte beh\u00f6ver en disk f\u00f6r att spara status. Som standard, efter att ha mottagit SIGINT (som skickas i det \u00f6gonblick d\u00e5 uppgiften \u00f6verg\u00e5r till status Draining), kommer alla aktiva uppgifter att stoppas inom 30 sekunder, \u00e4ven om de inte har blivit klara, detta tidsintervall kan justeras med hj\u00e4lp av parametern ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Det viktigaste \u00e4r att inte st\u00e4lla in detta till mer \u00e4n 2 minuter f\u00f6r spot-maskiner.<\/p>\n

<\/p>\n

Skapa tj\u00e4nst<\/h2>\n

<\/p>\n

L\u00e5t oss g\u00e5 direkt till att skapa den beskrivna tj\u00e4nsten. Under processen kommer jag att beskriva n\u00e5gra ytterligare anv\u00e4ndbara punkter som inte n\u00e4mndes ovan. Generellt \u00e4r detta en steg-f\u00f6r-steg-instruktion, men n\u00e5gra mycket grundl\u00e4ggande eller \u00e5 sin sida mycket specifika fall kommer jag inte att diskutera. Alla \u00e5tg\u00e4rder utf\u00f6rs i den visuella konsolen i AWS, men de kan \u00e4ven reproduceras programatiskt med hj\u00e4lp av CloudFormation eller Terraform. P\u00e5 Adapty anv\u00e4nder vi Terraform.<\/p>\n

<\/p>\n

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

<\/p>\n

I denna tj\u00e4nst skapas en konfiguration av maskiner som ska anv\u00e4ndas. Hanteringen av mallarna sker under EC2 -> Instances -> Launch templates.<\/p>\n

<\/p>\n

Amazon machine image (AMI)<\/strong> \u2014 vi anger diskimage som alla instanser ska startas med. F\u00f6r ECS b\u00f6r man i de flesta fall anv\u00e4nda en optimerad bild fr\u00e5n Amazon. Den uppdateras regelbundet och inneh\u00e5ller allt n\u00f6dv\u00e4ndigt f\u00f6r att ECS ska fungera. F\u00f6r att ta reda p\u00e5 aktuell bild-ID g\u00e5r vi till sidan Amazon ECS-optimized AMIs<\/a><\/noindex>, v\u00e4ljer den aktuella regionen och kopierar AMI ID f\u00f6r den. Till exempel, f\u00f6r regionen us-east-1, \u00e4r det aktuella ID som skrivs i artikeln \u2014 ami-00c7c1cf5bdc913ed<\/em>. Detta ID m\u00e5ste klistras in i punkten Specificera ett anpassat v\u00e4rde.<\/p>\n

<\/p>\n

Instanstyp<\/strong> \u2014 specificera typ av instans. V\u00e4lj den som passar b\u00e4st f\u00f6r dina uppgifter.<\/p>\n

<\/p>\n

Nyckelpar (inloggning)<\/strong> \u2014 specificera certifikatet som g\u00f6r det m\u00f6jligt att ansluta till instansen via SSH, om det \u00e4r n\u00f6dv\u00e4ndigt.<\/p>\n

<\/p>\n

N\u00e4tverksinst\u00e4llningar<\/strong> \u2014 specificera n\u00e4tverksparametrar. N\u00e4tverksplattform<\/strong> b\u00f6r i de flesta fall vara Virtual Private Cloud (VPC). S\u00e4kerhetsgrupper<\/strong> \u2014 s\u00e4kerhetsgrupper f\u00f6r dina instanser. Eftersom vi kommer att anv\u00e4nda en lastbalanserare framf\u00f6r instanserna, rekommenderar jag att ange en grupp h\u00e4r som till\u00e5ter inkommande anslutningar endast fr\u00e5n lastbalanseraren. Det betyder att du kommer att ha 2 s\u00e4kerhetsgrupper, en f\u00f6r lastbalanseraren som till\u00e5ter inkommande (inbound) anslutningar fr\u00e5n alla h\u00e5ll p\u00e5 portarna 80 (http) och 443 (https), och en andra f\u00f6r maskinerna som till\u00e5ter inkommande anslutningar p\u00e5 alla portar fr\u00e5n lastbalanserarens grupp. Utg\u00e5ende (outbound) anslutningar i b\u00e5da grupperna m\u00e5ste \u00f6ppnas via TCP-protokollet p\u00e5 alla portar till alla adresser. Du kan begr\u00e4nsa portar och adresser f\u00f6r utg\u00e5ende anslutningar, men d\u00e5 m\u00e5ste du st\u00e4ndigt \u00f6vervaka att du inte f\u00f6rs\u00f6ker ansluta till n\u00e5gon st\u00e4ngd port.<\/p>\n

<\/p>\n

Lagring (volymer)<\/strong> \u2014 specificera diskparametrar f\u00f6r maskinerna. Diskens storlek kan inte vara mindre \u00e4n vad som anges i AMI, f\u00f6r ECS-optimerad \u2014 30 GiB.<\/p>\n

<\/p>\n

Avancerade detaljer<\/strong> \u2014 specificera ytterligare parametrar.<\/p>\n

<\/p>\n

K\u00f6palternativ<\/strong> \u2014 vill vi k\u00f6pa spottinstanser. Vi vill, men h\u00e4r kommer vi inte att markera denna ruta, vi konfigurerar det i Auto Scaling Group, d\u00e4r det finns fler alternativ.<\/p>\n

<\/p>\n

IAM instansprofil<\/strong> \u2014 specificera rollen som instanserna ska startas med. F\u00f6r att instanserna ska fungera i ECS beh\u00f6vs r\u00e4ttigheter som vanligtvis ligger i rollen ecsInstanceRole<\/em>. I vissa fall kan den skapas, om inte, s\u00e5 h\u00e4r instruktion<\/a><\/noindex> om hur man g\u00f6r detta. Efter skapandet anger vi den i mallen.
\nD\u00e4refter f\u00f6ljer m\u00e5nga parametrar, i de flesta fall kan standardv\u00e4rdena l\u00e4mnas, men varje parameter har en tydlig beskrivning. Jag aktiverar alltid parametrarna EBS-optimera instans och T2\/T3 Unlimited, om de anv\u00e4nds burstable<\/a><\/noindex> instanser.<\/p>\n

<\/p>\n

Anv\u00e4ndardata<\/strong> \u2014 specificera anv\u00e4ndardata. Vi kommer att redigera filen \/etc\/ecs\/ecs.config<\/code>, d\u00e4r konfigurationen av ECS-agenten ligger.
\nEtt exempel p\u00e5 hur anv\u00e4ndardata kan se ut:<\/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 parametern anger att instansen tillh\u00f6r ett kluster med det angivna namnet, vilket inneb\u00e4r att detta kluster kan k\u00f6ra sina uppgifter p\u00e5 den h\u00e4r servern. Vi har \u00e4nnu inte skapat ett kluster, men vi kommer att anv\u00e4nda detta namn n\u00e4r vi skapar ett.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 parametern anger att n\u00e4r ett slutsignal ges f\u00f6r en spotinstans, b\u00f6r alla uppgifter p\u00e5 den flyttas till statusen Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 parametern anger att efter att ha mottagit SIGINT-signalen har alla uppgifter 1 minut p\u00e5 sig innan de st\u00e4ngs av.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 parametern anger att Docker-schema anv\u00e4nds som autentiseringsmetod.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 anslutningsparametrar f\u00f6r det privata container-registret d\u00e4r dina Docker-bilder lagras. Om det \u00e4r offentligt, beh\u00f6ver ingenting anges.<\/p>\n
<\/p>\n
I den h\u00e4r artikeln kommer jag att anv\u00e4nda en offentlig bild fr\u00e5n Docker Hub, s\u00e5 jag beh\u00f6ver inte ange parametrar. ECS_ENGINE_AUTH_TYPE<\/code> och ECS_ENGINE_AUTH_DATA<\/code> beh\u00f6ver inte anges.<\/p>\n
<\/p>\n
Bra att veta<\/strong>: det rekommenderas att regelbundet uppdatera AMI, eftersom nya versioner uppdaterar versioner av Docker, Linux, ECS-agenten med mera. F\u00f6r att inte gl\u00f6mma detta kan man st\u00e4lla in notifieringar<\/a><\/noindex> om nya versioner sl\u00e4pps. Du kan f\u00e5 notifieringar via e-post och uppdatera manuellt, eller s\u00e5 kan du skriva en Lambda-funktion som automatiskt skapar en ny version av Launch Template med den uppdaterade AMI:n.<\/p>\n
<\/p>\n
EC2 Auto Scaling Group<\/strong><\/h3>\n
<\/p>\n
Auto Scaling Group ansvarar f\u00f6r att starta och skala instanser. Hantering av grupper sker under EC2 -> Auto Scaling -> Auto Scaling Groups.<\/p>\n
<\/p>\n
Launch template<\/strong> \u2014 vi v\u00e4ljer den mall som skapades i f\u00f6reg\u00e5ende steg. L\u00e5t versionen vara standard.<\/p>\n
<\/p>\n
Purchase options and instance types<\/strong> \u2014 vi anger instanstyper f\u00f6r klustret. Keep in launch template anv\u00e4nder instanstypen fr\u00e5n Launch Template. Combine purchase options and instance types till\u00e5ter flexibilitet i instanstyper. Vi kommer att anv\u00e4nda den.<\/p>\n
<\/p>\n
Optional On-Demand base<\/strong> \u2014 antalet vanliga, icke-spotsinstanser som alltid kommer att vara aktiva.<\/p>\n
<\/p>\n
On-Demand percentage above base<\/strong> \u2014 procentandelen av vanliga och spottinstanser, 50-50 kommer att f\u00f6rdela lika, 20-80 kommer att resultera i att 4 spottinstanser startas f\u00f6r varje vanlig instans. I det h\u00e4r exemplet kommer jag att ange 50-50, men i verkligheten g\u00f6r vi oftast 20-80, i vissa fall 0-100.<\/p>\n
<\/p>\n
Instanstyper<\/strong> \u2014 h\u00e4r kan du ange ytterligare typinstanser som ska anv\u00e4ndas i klustret. Vi har aldrig anv\u00e4nt detta eftersom jag inte riktigt f\u00f6rst\u00e5r syftet. Kanske handlar det om begr\u00e4nsningar f\u00f6r specifika typinstanser, men dessa kan enkelt \u00f6kas genom support. Om du k\u00e4nner till n\u00e5got till\u00e4mpningsomr\u00e5de skulle jag g\u00e4rna l\u00e4sa om det i kommentarerna)<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
N\u00e4tverk<\/strong> \u2014 n\u00e4tverksinst\u00e4llningar, v\u00e4lj VPC och undern\u00e4t f\u00f6r maskiner, i de flesta fall b\u00f6r man v\u00e4lja alla tillg\u00e4ngliga undern\u00e4t.<\/p>\n
<\/p>\n
Lastbalansering<\/strong> \u2014 inst\u00e4llningar f\u00f6r lastbalanserare, men vi g\u00f6r detta separat, h\u00e4r r\u00f6r vi inget. Sundhetskontroller<\/strong> kommer ocks\u00e5 att konfigureras senare.<\/p>\n
<\/p>\n
Gruppstorlek<\/strong> \u2014 anger begr\u00e4nsningar f\u00f6r antalet maskiner i klustret och \u00f6nskat antal maskiner vid start. Antalet maskiner i klustret kommer aldrig att bli mindre \u00e4n det minimi angivna och mer \u00e4n det maximala, \u00e4ven om det baserat p\u00e5 m\u00e4tningar borde ske en skalning.<\/p>\n
<\/p>\n
Skalningspolicyer<\/strong> \u2014 skalningsparametrar, men vi kommer att skala baserat p\u00e5 de aktiva ECS-uppgifterna, s\u00e5 vi kommer att st\u00e4lla in skalning senare.<\/p>\n
<\/p>\n
Skalningsskydd f\u00f6r instanser<\/strong> \u2014 skydd av instanser mot borttagning vid nedskalning. Vi aktiverar detta s\u00e5 att ASG inte tar bort en maskin som har aktiva uppgifter. Att inaktivera skydd f\u00f6r instanser utan uppgifter kommer att g\u00f6ras av ECS Capacity Provider.<\/p>\n
<\/p>\n
L\u00e4gg till taggar<\/strong> \u2014 du kan ange taggar f\u00f6r instanser (f\u00f6r detta m\u00e5ste rutan Tag new instances vara markerad). Jag rekommenderar att ange taggen Namn, s\u00e5 att alla instanser som startas inom gruppen f\u00e5r samma namn, vilket g\u00f6r det l\u00e4ttare att se dem i konsolen.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
Efter att ha skapat gruppen, \u00f6ppna den och g\u00e5 till avsnittet Avancerade konfigurationer, varf\u00f6r alla alternativ inte syns i konsolen vid skapandet.<\/p>\n
<\/p>\n
Borttagningspolicyer<\/strong> \u2014 regler som beaktas vid borttagning av instanser. De till\u00e4mpas i ordning. Vi anv\u00e4nder vanligtvis s\u00e5dana som p\u00e5 bilden nedan. F\u00f6rst tas instanser med den \u00e4ldsta Launch Template bort (till exempel, om vi har uppdaterat AMI, har vi f\u00e5tt en ny version, men alla instanser hann \u00f6verg\u00e5 till den). Sedan v\u00e4ljs instanser som ligger n\u00e4rmast n\u00e4sta ber\u00e4knade timme f\u00f6r fakturering. Och d\u00e4refter v\u00e4ljs de som \u00e4r \u00e4ldst baserat p\u00e5 startdatum.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
Bra att veta<\/strong>: f\u00f6r att uppdatera alla maskiner i klustret, \u00e4r det bekv\u00e4mt att anv\u00e4nda Instansuppdatering<\/a><\/noindex>. Om du kombinerar detta med Lambda-funktionen fr\u00e5n f\u00f6reg\u00e5ende steg, f\u00e5r du ett helt automatiserat system f\u00f6r att uppdatera instanser. Innan du uppdaterar alla maskiner m\u00e5ste instansers skydd mot nedskala in st\u00e4ngas av f\u00f6r alla instanser i gruppen. Det handlar inte om inst\u00e4llningen i gruppen, utan om skyddet p\u00e5 sj\u00e4lva maskinerna, vilket g\u00f6rs p\u00e5 fliken Instanshantering.<\/p>\n
<\/p>\n
Application Load Balancer och EC2 Target Group<\/h3>\n
<\/p>\n
Balansieraren skapas under EC2 \u2192 Load Balancing \u2192 Load Balancers. Vi kommer att anv\u00e4nda Application Load Balancer, och du kan l\u00e4sa om j\u00e4mf\u00f6relsen mellan olika typer av balansierare p\u00e5 tj\u00e4nstens sida<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u2014 det \u00e4r meningsfullt att skapa portarna 80 och 443 och att g\u00f6ra en omdirigering fr\u00e5n 80 till 443 med hj\u00e4lp av balansierarens regler.<\/p>\n
<\/p>\n
Availability Zones<\/strong> \u2014 i de flesta fall v\u00e4ljer vi alla tillg\u00e4nglighetszoner.<\/p>\n
<\/p>\n
Configure Security Settings<\/strong> \u2014 h\u00e4r anges SSL-certifikat f\u00f6r balansieraren, det mest bekv\u00e4ma alternativet \u00e4r att skapa certifikatet<\/a><\/noindex> i ACM. Du kan l\u00e4sa om skillnaderna i Security Policy<\/strong> , den kan l\u00e4mnas vald fr\u00e5n b\u00f6rjan dokumentationen<\/a><\/noindex>ELBSecurityPolicy-2016-08 . Efter att balansieraren har skapats kommer du att se dess<\/code>DNS-namn , som du m\u00e5ste st\u00e4lla in CNAME f\u00f6r din dom\u00e4n. S\u00e5 h\u00e4r ser det ut i Cloudflare.<\/strong>Security Group<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
\u2014 vi skapar eller v\u00e4ljer en s\u00e4kerhetsgrupp f\u00f6r balansieraren, mer om detta har jag skrivit tidigare i avsnittet EC2 Launch Template \u2192 N\u00e4tverksinst\u00e4llningar.<\/strong> Target group<\/p>\n
<\/p>\n
\u2014 vi skapar en grupp som ansvarar f\u00f6r att dirigera f\u00f6rfr\u00e5gningar fr\u00e5n balansieraren till maskinerna och kontrollerar deras tillg\u00e4nglighet f\u00f6r att ers\u00e4tta dem vid problem.<\/strong> Target type ska vara Instance,<\/strong> Protocol \u2014 alla, om du anv\u00e4nder HTTPS f\u00f6r kommunikationen mellan balansieraren och instanserna, m\u00e5ste du ladda certifikatet p\u00e5 dem. I det h\u00e4r exemplet kommer vi inte att g\u00f6ra det, utan bara l\u00e4mna port 80.<\/strong> och Port<\/strong> \u2014 parametrar f\u00f6r att kontrollera tj\u00e4nstens funktionalitet. I den verkliga tj\u00e4nsten b\u00f6r detta vara en separat beg\u00e4ran som implementerar viktiga delar av aff\u00e4rslogiken, i det h\u00e4r exemplet l\u00e4mnar jag standardinst\u00e4llningarna. Sedan kan du v\u00e4lja beg\u00e4rningsintervall, timeout, koder f\u00f6r framg\u00e5ngsrika svar och mer. I v\u00e5rt exempel ang\u00f6r vi framg\u00e5ngskoder 200-399, eftersom Docker-avbildningen som kommer att anv\u00e4ndas returnerar kod 304.<\/p>\n
<\/p>\n
Sundhetskontroller<\/strong> Register Targets<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
\u2014 h\u00e4r v\u00e4ljs maskiner f\u00f6r gruppen, men i v\u00e5rt fall kommer detta att hanteras av ECS, s\u00e5 vi hoppar bara \u00f6ver detta steg.<\/strong> : p\u00e5 balansierarens niv\u00e5 kan du aktivera loggar som kommer att sparas i S3 i ett visst<\/p>\n
<\/p>\n
Bra att veta<\/strong>format i SVG-konturformat.<\/a><\/noindex>. D\u00e4rifr\u00e5n kan de exporterats till tredjepartstj\u00e4nster f\u00f6r analys, eller s\u00e5 kan man g\u00f6ra SQL-fr\u00e5gor direkt mot data i S3 med hj\u00e4lp av Athena.<\/a><\/noindex>. Det \u00e4r praktiskt och fungerar utan n\u00e5gon extra kod. Jag rekommenderar ocks\u00e5 att st\u00e4lla in radering av loggar fr\u00e5n S3-bucketen efter en viss tidsperiod.<\/p>\n
<\/p>\n
ECS Task Definition<\/h3>\n
<\/p>\n
I de tidigare stegen skapade vi allt som har att g\u00f6ra med tj\u00e4nstens infrastruktur, nu g\u00e5r vi vidare till beskrivningen av de containrar som vi kommer att k\u00f6ra. Detta g\u00f6rs i avsnittet ECS \u2192 Task Definitions.<\/p>\n
<\/p>\n
Launch type compatibility<\/strong> \u2014 v\u00e4lj EC2.<\/p>\n
<\/p>\n
Task execution IAM role<\/strong> \u2014 v\u00e4lj ecsTaskExecutionRole<\/code>. Med den skrivs loggar, ge \u00e5tkomst till hemliga variabler etc.<\/p>\n
<\/p>\n
I avsnittet Container Definitions klickar vi p\u00e5 Add Container.<\/p>\n
<\/p>\n
Image<\/strong> \u2014 l\u00e4nk till bilden med projektets kod, i detta exempel kommer jag att anv\u00e4nda en offentlig bild fr\u00e5n Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Memory Limits<\/strong> \u2014 minnesgr\u00e4nser f\u00f6r containern. Hard Limit<\/strong> \u2014 h\u00e5rd gr\u00e4ns, om containern \u00f6verstiger det angivna v\u00e4rdet kommer kommandot docker kill att k\u00f6ras, containern d\u00f6r omedelbart. Soft Limit<\/strong> \u2014 mjuk gr\u00e4ns, containern kan \u00f6verstiga det angivna v\u00e4rdet, men vid placering av uppgifter p\u00e5 maskiner kommer denna parameter att beaktas. Till exempel, om maskinen har 4 GiB RAM och containerns mjuka gr\u00e4ns \u00e4r 2048 MiB, kan det maximalt finnas 2 aktiva uppgifter med denna container p\u00e5 denna maskin. I verkligheten \u00e4r 4 GiB RAM n\u00e5got mindre \u00e4n 4096 MiB, vilket kan ses p\u00e5 fliken ECS Instances i klustret. Mjuk gr\u00e4ns kan inte vara st\u00f6rre \u00e4n h\u00e5rd gr\u00e4ns. Det \u00e4r viktigt att f\u00f6rst\u00e5 att om en uppgift har flera containrar s\u00e5 summeras deras gr\u00e4nser.<\/p>\n
<\/p>\n
Port mappings<\/strong> \u2014 i Host port<\/strong> anger 0, vilket betyder att porten kommer att tilldelas dynamiskt, den \u00f6vervakas av Target Group. Container Port<\/strong> \u2014 porten d\u00e4r din applikation k\u00f6rs, oftast anges den i k\u00f6rkommandot eller tilldelas i koden av din applikation, Dockerfile etc. F\u00f6r v\u00e5rt exempel anv\u00e4nder vi 3000, eftersom den anges i Dockerfile<\/a><\/noindex> den anv\u00e4nda bilden.<\/p>\n
<\/p>\n
Health check<\/strong> \u2014 parametrar f\u00f6r att kontrollera h\u00e4lso-statusen f\u00f6r containern, f\u00f6rv\u00e4xla inte med den som st\u00e4llts in i Target Group.<\/p>\n
<\/p>\n
Environment<\/strong> \u2014 milj\u00f6inst\u00e4llningar. CPU units<\/strong> \u2014 liknar p\u00e5 minnesgr\u00e4nser, men handlar om processorn. Varje processor k\u00e4rna motsvarar 1024 enheter, s\u00e5 om servern har en dubbelk\u00e4rnig processor och containern har v\u00e4rdet 512, kan 4 uppgifter med denna container k\u00f6ras p\u00e5 en server. CPU-enheter motsvarar alltid antalet k\u00e4rnor, de kan inte vara n\u00e5got f\u00e4rre som i fallet med minnet.<\/p>\n
<\/p>\n
Kommando<\/strong> \u2014 kommandot f\u00f6r att starta tj\u00e4nsten inuti containern, alla parametrar anges med kommatecken. Det kan vara gunicorn, npm och s\u00e5 vidare. Om inget anges kommer v\u00e4rdet fr\u00e5n CMD-direktivet i Dockerfile att anv\u00e4ndas. Ange npm,start<\/code>.<\/p>\n
<\/p>\n
Milj\u00f6variabler<\/strong> \u2014 milj\u00f6variabler f\u00f6r containern. Dessa kan vara b\u00e5de enkla textdata och hemliga variabler fr\u00e5n Secrets Manager<\/a><\/noindex> eller Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Lagring och loggning<\/strong> \u2014 h\u00e4r kommer vi att konfigurera loggning i CloudWatch Logs (tj\u00e4nsten f\u00f6r loggar fr\u00e5n AWS). Det r\u00e4cker att aktivera rutan Auto-configure CloudWatch Logs. Efter skapandet av Task Definition kommer en logggrupp automatiskt att skapas i CloudWatch. Som standard lagras loggarna d\u00e4r o\u00e4ndligt, jag rekommenderar att \u00e4ndra Retention period fr\u00e5n Never Expire till den \u00f6nskade perioden. Detta g\u00f6rs i CloudWatch Log groups, klicka p\u00e5 den aktuella perioden och v\u00e4lj en ny.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
ECS Kluster och ECS Kapacitetsleverant\u00f6r<\/h3>\n
<\/p>\n
G\u00e5 till avsnittet ECS \u2192 Clusters f\u00f6r att skapa ett kluster. V\u00e4lj EC2 Linux + Networking som mall.<\/p>\n
<\/p>\n
Kluster namn<\/strong> \u2014 mycket viktigt, vi g\u00f6r h\u00e4r samma namn som anges i Launch Template i parametern ECS_CLUSTER<\/code>, i v\u00e5rt fall \u2014 DemoApiClusterProd<\/code>. Markera rutan Create an empty cluster. Valfritt kan Container Insights aktiveras f\u00f6r att se m\u00e4tv\u00e4rden f\u00f6r tj\u00e4nster i CloudWatch. Om du har gjort allt r\u00e4tt kommer du i avsnittet ECS Instances att se maskiner som skapades i Auto Scaling group.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
G\u00e5 till fliken Kapacitetsleverant\u00f6rer<\/strong> och skapa en ny. Jag p\u00e5minner om att den beh\u00f6vs f\u00f6r att hantera skapandet och avst\u00e4ngningen av maskiner beroende p\u00e5 antalet aktiva ECS-tasker. Det \u00e4r viktigt att notera att leverant\u00f6ren endast kan knytas till en grupp.<\/p>\n
<\/p>\n
Auto Scaling group<\/strong> \u2014 v\u00e4lj den tidigare skapade gruppen.<\/p>\n
<\/p>\n
Hantera skalning<\/strong> \u2014 aktivera s\u00e5 att leverant\u00f6ren kan skala tj\u00e4nsten.<\/p>\n
<\/p>\n
M\u00e5lkapacitet %<\/strong> \u2014 vilken procentbelastning av maskiner med uppgifter vi beh\u00f6ver. Om du anger 100 % kommer alla maskiner alltid att vara upptagna med aktiva uppgifter. Om du anger 50 % kommer h\u00e4lften av maskinerna alltid vara lediga. I s\u00e5 fall, om det finns en pl\u00f6tslig \u00f6kning i belastningen, kommer nya uppgifter omedelbart att g\u00e5 till de lediga maskinerna utan att beh\u00f6va v\u00e4nta p\u00e5 att instanserna ska rullas ut.<\/p>\n
<\/p>\n
Hantera avslutningsskydd<\/strong> \u2014 vi aktiverar detta parameter som till\u00e5ter leverant\u00f6ren att ta bort skyddet f\u00f6r instanser fr\u00e5n borttagning. Detta sker n\u00e4r det inte finns n\u00e5gra aktiva uppgifter p\u00e5 maskinen och m\u00f6jligg\u00f6r Target capacity %.<\/p>\n
<\/p>\n
ECS-tj\u00e4nst och inst\u00e4llning av skalning<\/h3>\n
<\/p>\n
Sista steget :) F\u00f6r att skapa en tj\u00e4nst m\u00e5ste du g\u00e5 in i den tidigare skapade klustern p\u00e5 fliken Tj\u00e4nster.<\/p>\n
<\/p>\n
Lanseringstyp<\/strong> \u2014 du m\u00e5ste klicka p\u00e5 Switch to capacity provider strategy och v\u00e4lja den tidigare skapade leverant\u00f6ren.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
Uppgiftsdefinition<\/strong> \u2014 vi v\u00e4ljer den tidigare skapade uppgiftsdefinitionen och dess version.<\/p>\n
<\/p>\n
Tj\u00e4nstnamn<\/strong> \u2014 f\u00f6r att inte blanda ihop, anger vi alltid samma namn som uppgiftsdefinitionen.<\/p>\n
<\/p>\n
Tj\u00e4nsttyp<\/strong> \u2014 alltid Replica.<\/p>\n
<\/p>\n
Antal uppgifter<\/strong> \u2014 \u00f6nskat antal aktiva uppgifter i tj\u00e4nsten. Denna parameter styrs av skalning, men den m\u00e5ste fortfarande anges.<\/p>\n
<\/p>\n
Minimalt h\u00e4lsoprocent<\/strong> och Maximalt procent<\/strong> \u2014 best\u00e4mmer beteendet f\u00f6r uppgifter vid distribution. Standardv\u00e4rdena 100 och 200 inneb\u00e4r att antalet uppgifter vid distribution \u00f6kar med en faktor och sedan \u00e5terg\u00e5r till \u00f6nskat antal. Om du har 1 uppgift, min=0 och max=100, kommer den att d\u00f6das vid distribution, och sedan kommer en ny att startas, vilket inneb\u00e4r d\u00f6d tid. Om 1 uppgift fungerar, min=50, max=150, d\u00e5 kommer distribution \u00f6verhuvudtaget inte att ske, eftersom 1 uppgift inte kan delas i h\u00e4lften eller \u00f6kas med en och en halv g\u00e5ng.<\/p>\n
<\/p>\n
Distributionstyp<\/strong> \u2014 vi l\u00e4mnar Rolling update.<\/p>\n
<\/p>\n
Placering smallar<\/strong> \u2014 regler f\u00f6r placering av uppgifter p\u00e5 maskiner. Som standard st\u00e5r det AZ Balanced Spread \u2014 detta inneb\u00e4r att varje ny uppgift kommer att placeras p\u00e5 en ny instans tills alla maskiner i alla tillg\u00e4nglighetszoner startas. Vi g\u00f6r vanligtvis BinPack \u2014 CPU och Spread \u2014 AZ, under denna policy placeras uppgifter s\u00e5 n\u00e4ra varandra som m\u00f6jligt per maskin enligt CPU. Vid behov av att skapa en ny maskin skapas den i en ny tillg\u00e4nglighetszon.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
Lastbalanserartyp<\/strong> \u2014 vi v\u00e4ljer Application Load Balancer.<\/p>\n
<\/p>\n
Tj\u00e4nst IAM-roll<\/strong> \u2014 vi v\u00e4ljer ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Lastbalanserarnamn<\/strong> \u2014 vi v\u00e4ljer den tidigare skapade lastbalanseraren.<\/p>\n
<\/p>\n
H\u00e4lsokontrollsp\u00e4rrperiod<\/strong> \u2014 paus f\u00f6re utf\u00f6rande av h\u00e4lsokontroller efter distribution av en ny uppgift, vi s\u00e4tter vanligtvis 60 sekunder.<\/p>\n
<\/p>\n
Beh\u00e5llare f\u00f6r att lastbalansera<\/strong> \u2014 i f\u00e4ltet Target group name v\u00e4ljer vi den tidigare skapade gruppen, och allt kommer att fyllas i automatiskt.<\/p>\n
<\/p>\n
\"Skapande<\/p>\n
<\/p>\n
Service Auto Scaling<\/strong> \u2014 inst\u00e4llningar f\u00f6r tj\u00e4nstens skalning. V\u00e4lj Configure Service Auto Scaling f\u00f6r att justera \u00f6nskat antal p\u00e5 din tj\u00e4nst. Ange minimi- och maximala antalet uppgifter vid skalning.<\/p>\n
<\/p>\n
IAM-roll f\u00f6r Service Auto Scaling<\/strong> \u2014 vi v\u00e4ljer AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Automatiska uppgiftsskaleringspolicyer<\/strong> \u2014 regler f\u00f6r skalning. Det finns tv\u00e5 typer:<\/p>\n
<\/p>\n
    \n
  1. Target tracking<\/strong> \u2014 \u00f6vervakning av en m\u00e5lmetrik (CPU\/RAM-anv\u00e4ndning eller antal f\u00f6rfr\u00e5gningar per uppgift). Till exempel, vi vill att den genomsnittliga CPU-belastningen ska vara 85%, n\u00e4r den blir h\u00f6gre kommer nya uppgifter att l\u00e4ggas till tills den n\u00e5r m\u00e5lv\u00e4rdet. Om belastningen \u00e4r l\u00e4gre kommer uppgifterna att tas bort, om inte skydd mot nedskalning \u00e4r aktiverat (Disable scale-in<\/strong>).<\/li>\n
  2. Step scaling<\/strong> \u2014 respons p\u00e5 ett vilkorat evenemang. H\u00e4r kan vi st\u00e4lla in reaktionen p\u00e5 vilket som helst evenemang (CloudWatch Alarm), n\u00e4r det intr\u00e4ffar kan vi l\u00e4gga till eller ta bort ett angivet antal uppgifter, eller ange ett exakt antal uppgifter.<\/li>\n<\/ol>\n
    <\/p>\n
    Tj\u00e4nsten kan ha flera skalningsregler, vilket kan vara anv\u00e4ndbart, men det \u00e4r viktigt att se till att de inte st\u00f6ter p\u00e5 varandra.<\/p>\n
    <\/p>\n
    Slutsats<\/h2>\n
    <\/p>\n
    Om du f\u00f6ljde instruktionerna och anv\u00e4nde samma Docker-image, b\u00f6r din tj\u00e4nst returnera en s\u00e5dan sida.<\/p>\n
    <\/p>\n
    \"Skapande<\/p>\n
    <\/p>\n
      \n
    1. Vi har skapat en mall som alla maskiner i tj\u00e4nsten startas med. Vi har ocks\u00e5 l\u00e4rt oss att uppdatera maskinerna vid \u00e4ndring av mallen.<\/li>\n
    2. Vi har st\u00e4llt in hantering av stopp-signaler f\u00f6r spottinstanser, s\u00e5 inom en minut efter att den mottas tas alla aktiva uppgifter bort fr\u00e5n maskinen, vilket g\u00f6r att inget g\u00e5r f\u00f6rlorat eller avbryts.<\/li>\n
    3. Vi har lyft en belastningsutj\u00e4mnare f\u00f6r att f\u00f6rdela lasten j\u00e4mnt mellan maskinerna.<\/li>\n
    4. Vi har skapat en tj\u00e4nst som k\u00f6rs p\u00e5 spottinstanser, vilket minskar kostnaderna f\u00f6r maskiner med cirka tre g\u00e5nger.<\/li>\n
    5. Vi har st\u00e4llt in automatiskt skalande i b\u00e5da riktningarna f\u00f6r att hantera \u00f6kad belastning, men samtidigt inte betala f\u00f6r stillest\u00e5nd.<\/li>\n
    6. Vi anv\u00e4nder Capacity Provider s\u00e5 att applikationen hanterar infrastrukturen (maskinerna), och inte tv\u00e4rtom.<\/li>\n
    7. Vi \u00e4r duktiga.<\/li>\n<\/ol>\n
      <\/p>\n
      Om du har f\u00f6ruts\u00e4gbara h\u00e4ftiga belastningar, till exempel om du g\u00f6r reklam i en stor e-postutskick, kan du st\u00e4lla in skalning baserad p\u00e5 schema<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      Det \u00e4r ocks\u00e5 m\u00f6jligt att skala baserat p\u00e5 data fr\u00e5n olika delar av ditt system. Till exempel har vi funktionaliteten att skicka individuella kampanjerbjudanden<\/a><\/noindex> till anv\u00e4ndare av mobilappen. Ibland g\u00e5r kampanjen ut till \u00f6ver 1M personer. Efter en s\u00e5dan utskick ses alltid en stor \u00f6kning av API-f\u00f6rfr\u00e5gningar, d\u00e5 m\u00e5nga anv\u00e4ndare loggar in p\u00e5 appen samtidigt. S\u00e5 om vi ser att k\u00f6n f\u00f6r att skicka kampanjnotiser har \u00f6kat markant j\u00e4mf\u00f6rt med standardniv\u00e5erna, kan vi omedelbart starta n\u00e5gra extra maskiner och uppgifter f\u00f6r att vara redo f\u00f6r belastningen.<\/p>\n
      <\/p>\n
      Jag skulle bli glad om ni i kommentarerna delar intressanta fall av anv\u00e4ndning av spot-instanser och ECS eller n\u00e5got om skalning.<\/p>\n
      <\/p>\n
      Snart kommer det artiklar om hur vi hanterar tusentals analystj\u00e4nster per sekund p\u00e5 en fr\u00e4mst serverl\u00f6s stack (med kostnader) och hur distributionen av tj\u00e4nster sker med hj\u00e4lp av GitLab CI och Terraform Cloud.<\/p>\n
      <\/p>\n
      F\u00f6lj oss, det kommer bli intressant!<\/p>\n
      Endast registrerade anv\u00e4ndare kan delta i omr\u00f6stningen. Logga in<\/a><\/noindex>, tack.<\/p>\n
      Anv\u00e4nder ni spot-instanser i produktion?<\/h2>\n