🥇Skaleeritava API loomine AWS-i spottinstances'il

Tere kõigile! Minu nimi on Kirill, olen Adapty CTO. Suur osa meie arhitektuurist asub AWS-is, ja täna räägin, kuidas me vähendasime serverikulud kolmandiku võrra, kasutades spottinstante tootmiskeskkonnas, ning kuidas neid automaatseteks skaleerimiseks seadistada. Esiteks, anan ülevaate, kuidas see toimib, ja seejärel detaliseeritud juhendi käivitamiseks.

Mis on spottinstantsid?

Spottinstantsid Instants on AWS — see on teiste kasutajate serverid, mis hetkel seisavad ja mida nad müüvad suure allahindlusega (Amazon väidab kuni 90%, meie kogemusest ~3x, varieerub sõltuvalt regionaalsetest eripära, AZ-st ja instantside tüübist). Peamine erinevus tavainstantsidest seisneb selles, et need võivad igal hetkel välja lülituda. Seetõttu oleme pikalt arvanud, et neid on normaalne kasutada arendus- või testkeskkondades või erinevate arvutuste tegemiseks, salvestades vahekohti S3-le või andmebaasi, kuid mitte tootmises. On olemas kolmandate osapoolte lahendusi, mis võimaldavad spote kasutada tootmises, kuid meie juhtumi jaoks on seal palju alternatiivseid lahendusi, mistõttu me neid ei rakendanud. Artiklis kirjeldatud lähenemine töötab täielikult AWS-i standardse funktsionaalsuse raames, ilma täiendavate skriptide, cronide jne kasutamiseta.

Järgnevalt toon välja mõned ekraanipildid, mis näitavad spotaalsete instantside hinnahistorit.

m5.large regioonis eu-west-1 (Iirimaa). Hind on peamiselt kolme kuu jooksul stabiilne, praegu on kokkuhoid 2.9x.

m5.large us-east-1 piirkonnas (N. Virginia). Hind muutub pidevalt 3 kuu vältel, praegu on sääst 2,3x kuni 2,8x sõltuvalt kättesaadavuspiirkonnast.

t3.small us-east-1 piirkonnas (N. Virginia). Hind on olnud stabiilne 3 kuu jooksul, praegu on sääst 3,4x.

Teenuse arhitektuur

Alusarhitektuur teenusele, millest me selles artiklis räägime, on kujutatud alloleval diagrammil.

Application Load Balancer → EC2 Target Group → Elastic Container Service

Balansseerijana kasutatakse Application Load Balancerit (ALB), mis suunab päringud EC2 Target Groupi (TG). TG vastutab ALB-le portide avamise eest instantsidel ja nende sidumise eest Elastic Container Service'i (ECS) konteinerite portidega. ECS on AWS-s Kubernetes'e analoog, mis haldab Docker konteinerite käsitsemist.

Ühel instantsil võib olla mitu töötavat konteinerit sama pordiga, seega ei saa me neid fikseerida. ECS teavitab TG-d, et ta käivitab uue ülesande (Kubernetes'i terminoloogias tuntud kui pod), see kontrollib instantsi vaba porte ja määrab ühe neist käivitatavale ülesandele. Samuti kontrollib TG regulaarselt, kas instants ja selle API töötavad, kasutades health check'i, ja kui ta näeb mingeid probleeme, siis lõpetab ta sealsete päringute edastamise.

EC2 Auto Scaling Groups + ECS Capacity Providers

Ülaltoodud diagrammil pole näidatud EC2 Auto Scaling Groups (ASG) teenust. Nagu nimest järeldada võib, vastutab see instantside skaleerimise eest. Siiski ei olnud viimase ajani AWS-is sisseehitatud funktsiooni, mis võimaldaks ECS-ist käivitatud masinate arvu hallata. ECS võimaldas ülesannete arvu skaleerida, näiteks CPU, RAMi või päringute arvu põhjal. Kuid kui ülesanded kasutasid kõik vabad instantsid, siis uusi masinaid automaatselt ei käivitatud.

See muutus ECS Capacity Providers (ECS CP) tekkimisega. Nüüd saab iga ECS teenuse siduda ASG-ga, ja kui ülesanded ei mahu töötavatesse instantsidesse, käivitatakse uued (kuid ASG seatud piirangute raames). See töötab ka vastupidiselt: kui ECS CP näeb ootavaid instantsse ilma ülesanneteta, annab ta ASG-le käsu need välja lülitada. ECS CP-l on võimalus määrata instantside sihtkoormuse protsent, et teatud arv masinaid oleks alati vabast, et tagada kiire ülesannete skaleerimine; räägin sellest natuke hiljem.

EC2 Launch Templates

Viimane teenus, millest ma räägin, enne kui lähen üksikasjalikule ülevaatele selle infrastruktuuri loomise kohta, on EC2 Launch Templates. See võimaldab luua malli, mille alusel kõik masinad käivitatakse, et seda iga kord nullist mitte korrata. Siin saab valida käivitatava masina tüübi, turvagruppi, ketta pildi ja palju muid parameetreid. Samuti saab määrata kasutajateabe, mis laetakse kõikidele käivitatud instantsidele. Kasutajateabes saab käivitada skripte, näiteks saab redigeerida faili sisu. ECS agendi konfiguratsioon.

Üks kõige olulisemaid konfiguratsiooni parameetreid selles artiklis on ECS_ENABLE_SPOT_INSTANCE_DRAINING=true. Kui see parameeter on sisse lülitatud, siis niipea kui ECS saab signaali, et spott instanssi eemaldatakse, muudab see kõik ülesanded, mis sellele töötavad, olekusse Draining. Uusi ülesandeid sellele instansile ei määrata, ja kui on ülesandeid, mis soovivad sellele välja lasta, tühistatakse need. Tasakaalustajalt tulevad päringud lakkaavad saabumast. Teate eemaldamise kohta saadetakse 2 minutit enne tegelikku sündmust. Seetõttu, kui teie teenus ei tee ülesandeid kauem kui 2 minutit ja ei salvesta midagi kettale, siis saate kasutada spott instansse ilma andmete kaotuseta.

Ketta osas — AWS on hiljuti teinud Elastic File System (EFS) kasutamine koos ECS-iga on võimalik, selle skeemiga ei ole isegi ketas takistuseks, kuid me ei ole seda proovinud, kuna põhimõtteliselt ei vaja me ketast oleku säilitamiseks. Vaikimisi saadetakse SIGINT (mis saadetakse ülesande staatuse muutmise ajal Drainingiks) kõik jooksvaid ülesandeid peatatakse 30 sekundi pärast, isegi kui nad ei ole lõpule viidud, seda aega saab muuta parameetri abil ECS_CONTAINER_STOP_TIMEOUT. Peamine on mitte seadistada seda üle 2 minuti spootmasinate jaoks.

Teenuse loomine

Liigume otse nimetatud teenuse loomise juurde. Protsessi käigus selgitan mitmeid kasulikke punkte, millest pole varem räägitud. Üldiselt on see samm-sammult juhend, kuid ma ei käsitle mõningaid tõeliselt põhitaseme või vastupidi väga spetsiifilisi juhtumeid. Kõik toimingud viiakse läbi AWS visuaalses konsoolis, kuid neid saab programmiliselt uuesti luua CloudFormationi või Terraformi abil. Adapty's kasutame Terraformi.

EC2 Launch Template

Selles teenuses luuakse masinate konfiguratsioon, mida kasutatakse. Mallide haldamine toimub jaotises EC2 -> Instances -> Launch templates.

Amazon machine image (AMI) — määrame diskifaili, millega kõik instantsid käivituvad. ECS-i jaoks on enamikul juhtudel otstarbekas kasutada Amazoni optimeeritud pilti. See uuendatakse regulaarselt ja sisaldab kõike vajalikku ECS-i toimimiseks. Aktuaalse ID leidmiseks külastame lehte Amazon ECS-iga optimeeritud AMI-d, valime kasutatava piirkonna ja kopeerime AMI ID selle jaoks. Näiteks piirkonnas us-east-1 on artikkel kirjutamise hetkeks aktuaalne ID — ami-00c7c1cf5bdc913ed. Selle ID tuleb sisestada punkti Specify a custom value.

Instantsi tüüp — määrame instantsi tüübi. Valige see, mis sobib teie ülesande jaoks kõige paremini.

Ahnuse paar (sisselogimine) — määrame sertifikaadi, millega saab vajadusel instantsiga SSH kaudu ühendust luua.

Võrguseaded — määrame võrgu parameetrid. Võrguteenuste platvorm enamikul juhtudel peab olema Virtual Private Cloud (VPC). Turvagrupp — turvaregid teie instantside jaoks. Kuna me kasutame koormuse tasakaalustajat instantside ees, soovitan siin määrata grupi, mis lubab sisenevaid ühendusi ainult koormuse tasakaalustajalt. Niisiis, teil on kaks turvaregistreid: üks koormuse tasakaalustaja jaoks, mis lubab sisenevaid (inbound) ühendusi kõikjal portidel 80 (http) ja 443 (https), ja teine masinate jaoks, mis lubab sisenevaid ühendusi kõigis portides koormuse tasakaalustaja grupist. Väljuvad (outbound) ühendused mõlemas grupis tuleb avada TCP protokolli kaudu kõigis portides, kõikidest aadressidest. Väljuvate ühenduste portide ja aadresside piiramine on võimalik, kuid siis tuleb pidevalt jälgida, et te ei püüa ühendust luua suletud pordi kaudu.

Salvestus (mahud) — määrame masinate ketaste parameetreid. Ketta maht ei tohi olla väiksem sellest, mis on määratud AMI-s, ECS Optimeeritud puhul — 30 GiB.

Täiendavad üksikasjad — määrame täiendavad parameetrid.

Ostuvalik — kas soovime osta spotinstante. Me tahame, kuid siin me seda märget ei pane, seame selle Auto Scaling Group’is, seal on rohkem valikuid.

IAM instantsi profiil — määrame rolli, millega instantsid käivitatakse. Et instantsid töötaksid ECS-is, on neil vaja õigusi, mis tavaliselt kuuluvad rolli ecsInstanceRole. Mõnel juhul võib see olla loodud, kui ei ole, siis siin juhend kuidas seda teha. Pärast loomist määrame selle mallis.
Edasi tuleb palju parameetreid, enamasti saab jätta vaikimisi väärtused, kuid igaühel on arusaadav kirjeldus. Mina lisan alati EBS-optimized instance ja T2/T3 Unlimited parameetrid, kui kasutatakse burstable instantsid.

Kasutajaandmed — määrame kasutajaandmed. Me redigeerime faili /etc/ecs/ecs.config, kus on ECS agendi konfiguratsioon.
Näide sellest, milline võib olla kasutajaandmed:

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

ECS_CLUSTER=DemoApiClusterProd — parameeter näitab, et instants kuulub klastrisse, mille nimi on määratud, see tähendab, et see klaster saab oma ülesandeid sellel serveril majutada. Me pole veel klastrit loonud, kuid loomisel kasutame seda nime.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameeter näitab, et kui spootinstansi väljalülitamise signaal tuleb, peavad kõik sellel olevad ülesanded minema staatusse Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m — parameeter määrab, et SIGINT signaali saamisel on kõigil ülesannetel 1 minut, enne kui need tapetakse.

ECS_ENGINE_AUTH_TYPE=docker — parameeter määrab, et autoriseerimise mehhanismina kasutatakse docker-skeemi.

ECS_ENGINE_AUTH_DATA=... — ühendamisparameetrid privaatsele konteineriregistrile, kus teie Docker pildid asuvad. Kui see on avalik, siis ei pea midagi näitama.

Selles artiklis kasutan avalikku pilti Docker Hubist, seega ei pea parameetreid ECS_ENGINE_AUTH_TYPE ja ECS_ENGINE_AUTH_DATA näitama.

Kasulik teada: soovitatakse regulaarselt AMI-d uuendada, kuna uutes versioonides uuendatakse Docker, Linux, ECS agent ja teised. Et sellest mitte unustada, võib seada teavitused uusversioonide väljastamise kohta. Saate teavitusi emailile ja uuendada käsitsi, või võite kirjutada Lambda-funktsiooni, mis loob automaatselt uue versiooni Launch Template'ist koos uuendatud AMI-ga.

EC2 Auto Scaling Group

Auto Scaling Group vastutab instantside käivitamise ja skaleerimise eest. Rühmade haldamine toimub EC2 -> Auto Scaling -> Auto Scaling Groups jaotises.

Launch template — valime eelmisel sammul loodud mall. Versiooni jätame vaikeväärtuseks.

Ostuvõimalused ja instantside tüübid — määrame välja klastrite instantside tüübid. Adhere to launch template kasutab Launch Template'i instantsi tüüpi. Combine purchase options and instance types võimaldab instantside tüüpide paindlikku seadistamist. Me kasutame seda.

Valikuline On-Demand baas — tavaliste, mitte-spotseeritud instantside arv, mis alati töötavad.

On-Demand protsent baasist — tavaliste ja spot-instantide protsentuaalne suhe, 50-50 jagab ühtlaselt, 20-80 tähendab, et iga tavaline instants tõstetakse 4 spot-instantiga. Antud näite põhjal esitan 50-50, aga tegelikult teeme me kõige sagedamini 20-80, mõnel juhul 0-100.

Instantside tüübid — siin saab määrata täiendavad instantside tüübid, mida klastris kasutatakse. Me ei ole kunagi kasutanud, sest ma ei saa sellest hästi aru. Võib-olla on asi instantside tüüpidega seotud limiitides, aga need tõstetakse hõlpsasti toe kaudu. Kui teil on rakendamise kohta teadmisi, oleksin rõõmus, kui loeksin kommentaarides).

Võrk log /dev/log local0 log /dev/log local1 notice chroot /var/lib/haproxy stats timeout 30s user haproxy group haproxy daemondefaults log global mode http option httplog option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000frontend http_front bind *:80 stats uri /haproxy?stats default_backend http_backbackend http_back balance roundrobin server server_name1 private_ip1:80 check server server_name2 private_ip2:80 check — võrguseaded, valige VPC ja alamvõrgud masinate jaoks, enamikul juhtudel tasub valida kõik saadaval olevad alamvõrgud.

Laotamine — tasakaalustamise seadistused, aga me teeme seda eraldi, siin ei puutu me midagi. Tervisekontrollid seadeid kohandatakse hiljem.

Gruppide suurus — määrame piirid klastris olevate masinate arvu ja soovitud käivitamise masinate arvu. Klastris olevate masinate arv ei saa kunagi olla väiksem kui minimaalne number ja suurem kui maksimaalne, isegi kui mõõdikute põhjal peaks toimuma skaleerimine.

Skaaleerimise poliitikad — skaleerimise parameetrid, kuid me skaleerime vastavalt käivitatud ECS ülesannetele, seega seadistame skaleerimise hiljem.

Instantsi skaaleerimise kaitse — kaitse instantside kustutamise eest allaskaleerimise korral. Lülitame sisse, et ASG ei kustutaks masinat, millel on töötavad ülesanded. Kaitse eemaldatakse instantsidelt, millel ei ole ülesandeid, ECS Capacity Provideri poolt.

Lisa silte — instantsidele saab lisada silte (kui on täpsustatud märge "Tag new instances"). Soovitan märkida sildi "Name", siis nimetatakse kõik instantsid, mis käivituvad grupi raames, ühesuguseks, mida on mugav jälgida konsoolis.

Pärast grupi loomist avage see ja minge jaotisse "Advanced configurations", miks ei ole loomise etapis konsoolis nähtavad kõik valikud.

Lõpetamispoliitikad — reeglid, mida arvestatakse instantside eemaldamisel. Need kehtivad järjekorras. Kasutame tavaliselt selliseid nagu pildil allpool. Esiteks eemaldatakse instantsid, millel on kõige vanem Launch Template (näiteks, kui oleme AMI-d uuendanud, on meil loodud uus versioon, aga kõik instantsid on selle peale vahetunud). Siis valitakse välja instantsid, mis on kõige lähemal järgmisele arveldamise ajale. Edasi valitakse kõige vanemad loodud kuupäevaga instantsid.

Kasulik teada: kõikide masinate värskendamiseks klastris on mugav kasutada Instance Refresh. Kui seda kombineerida eelneva sammu Lambda-funktsiooniga, siis on teil täiesti automatiseeritud instantside uuendamise süsteem. Kõikide masinate uuendamise eel tuleb välja lülitada instantside scale-in kaitse kõigile grupi instantsidele. Mitte grupi seadistus, vaid just masinate kaitse ennast, see tehakse Instantside halduse vahekaardil.

Application Load Balancer ja EC2 Target Group

Tasakaalustaja luuakse EC2 → Load Balancing → Load Balancers osas. Kasutame Application Load Balancerit, erinevate tasakaalustajate tüüpide võrdlust saab lugeda teenuse lehelt.

Listeners — on mõistlik seadistada 80. ja 443. port ning suunata 80. port 443. porti kaudu ülesandeid tasakaalujao reeglite abil.

Saadavuse tsoonid — valime enamasti kõiki saadavuse tsoone.

Konfigureeri turvaseaded — siin määratakse SSL-sertifikaat tasakaalustajale, kõige mugavam variant on luua sertifikaat ACM-is. Erinevuste kohta Turvapoliitika võib lugeda dokumentatsioonis, võib jätta vaikesätteks valitud ELBSecurityPolicy-2016-08. Pärast tasakaalustaja loomist näete selle DNS-nime, millele tuleb seadistada CNAME teie domeenile. Näiteks, nii see välja näeb Cloudflares.

Turvagrupp — loome või valime tasakaalustajale turgrupi, sellest on rohkem kirjutatud eelnevalt osas EC2 Launch Template → Võrguseaded.

Sihtgrupp — loome grupi, mis vastutab päringute suunamise eest tasakaalustajalt masinatele ja kontrollib nende kättesaadavust, et asendada probleemide korral. Sihttüüp peab olema Instance, Protokoll ja Port mõlemad, kui kasutate HTTPS-i suhtlemiseks tasakaalustaja ja instantside vahel, siis tuleb neile üles laadida sertifikaat. Antud näite raames me seda tegema ei hakka, lihtsalt jätame 80. porti.

Tervisekontrollid — teenused, mida kontrollida. Käesolev teenus peaks olema eraldi päring, mis rakendab olulisi äriloogika komponente; antud näite kontekstis jätan vaikeseaded alles. Edasi saab valida päringute vahemaa, ajutise katkestuse, eduka vastuse koodid jne. Näites määrame edukate koodide vahemiku 200-399, kuna kasutatav Docker pilt tagastab koodi 304.

Registreeri sihtpunktid — siin valitakse masinad grupi jaoks, kuid meie juhul tegeleb sellega ECS, seega jätame selle sammu lihtsalt vahele.

Kasulik teada: tasemel laadimisjagaja saab lubada logid, mis salvestatakse S3-sse teatud formaadis. Sealt saab neid eksportida kolmandatesse teenustesse analüüsiks või teha SQL-päringuid otse S3 andmetele Athena. See on mugav ja töötab ilma täiendava koodita. Soovitan samuti seadistada logide eemaldamine S3 ämbrist ettenähtud aja möödudes.

ECS ülesande määratlemine

Varasematel etappidel loodi kõik teenuse infrastruktuuriga seonduv, nüüd liigume konteinerite kirjeldamise juurde, mida me käivitame. See toimub jaotises ECS → Ülesande määratlused.

Käivitamise tüüpide ühilduvus — valige EC2.

Ülesande täitmise IAM-rakk — valige ecsTaskExecutionRole. Selle abil kirjutatakse logisid, antakse juurdepääs salajastele muutujaile jms.

Container Definitions jaotises vajutage Lisa konteiner.

Image — lingi pilt projekti koodiga, antud näite puhul kasutan avalikku pilti Docker Hub'ist bitnami/node-example:0.0.1.

Mälu limiidid — konteineri mälu limiidid. Jõhker limiit — rangelt määratud limiit, kui konteiner ületab määratud väärtuse, täidetakse käsk docker kill, konteiner sureb kohe. Pehme limiit — pehme limiit, konteiner võib ületada määratud väärtuse, kuid ülesannete paigutamisel masinates arvestatakse seda parameetrit. Näiteks kui masinas on 4 GiB RAM-i ja konteineri pehme limiit on 2048 MiB, siis võib selle konteineri jaoks olla masinas maksimaalselt 2 ülesannet käivitatud. Tegelikult on 4 GiB RAM-i veidi vähem kui 4096 MiB, seda saab vaadata ECS Instances vahekaardilt klastris. Pehme limiit ei saa olla suurem kui jõhker limiit. Oluline on mõista, et kui ühes ülesandes on mitu konteinerit, siis nende limiidid liidetakse.

Sadama kaardistamine — in Hosti port Määrame 0, see tähendab, et port määratakse dünaamiliselt, seda jälgib Target Group. Kontaineri port — port, millel teie rakendus töötab, määratakse sageli täitmis käsus või määratakse teie rakenduse koodis, Dockerfile'is jne. Meie näites kasutame 3000, sest see on määratud Dockerfile kasutatava pildi.

Tervisekontroll — konteineri töökindluse kontrollimise parameetrid, mitte segi ajada sellega, mis on seadistatud Target Group'is.

Keskkond — keskkonna seaded. CPU ühikud — sarnaneb Mälulävenditega, ainult et see on protsessori kohta. Iga protsessori tuum on 1024 ühikut, nii et kui serveril on kahetuumaline protsessor ja konteineril on väärtuseks seatud 512, siis sama serveri peal võib olla käivitatud 4 ülesannet selle konteineriga. CPU ühikute arv vastab alati tuumade arvule, neid ei saa olla vähem kui mälu puhul.

Käsk — käsk teenuse käivitamiseks konteineri sees, kõik parameetrid määratakse koma kaudu. See võib olla gunicorn, npm jne. Kui ei ole määratud, kasutatakse Dockerfile'i CMD direktiivi väärtust. Määrame npm,start.

Keskkonnamuutujad — konteineri keskkonnavariandid. Need võivad olla nii lihtsad tekstilised andmed kui ka salajased variandid Secrets Manager või Parameter Store.

Salvestamine ja logimine — siin seadistame logimise CloudWatch Logs'ile (AWS'i logiteenuse). Selleks piisab, kui märkida Auto-configure CloudWatch Logs. Pärast Task Definition'i loomist koostatakse automaatselt logigrupp CloudWatch'is. Vaikimisi säilitatakse logid selles lõputult, soovitan muuta Retention period'it vahemikule Never Expire vastavalt nõudmistele. Seda tehakse CloudWatch Log groups, klikkides praegusele perioodile ja valides uue.

ECS Cluster ja ECS Capacity Provider

Liigume jaotisse ECS → Clusters, et luua klaster. Mallina valime EC2 Linux + Networking.

Klasteri nimi — on äärmiselt oluline, et nimi oleks siin sama, mis Launch Template'is parameetris ECS_CLUSTER, meie puhul — DemoApiClusterProd. Märkige Create an empty cluster. Valikuliselt saate lubada Container Insights, et jälgida teenuste mõõdikuid CloudWatch'is. Kui kõik on õigesti tehtud, näete jaotises ECS Instances masinaid, mis loodi Auto Scaling grupis.

Liigume vahekaardile Capacity Providers ja loome uue. Tuletan meelde, et see on vajalik masinate loomise ja väljalülitamise haldamiseks sõltuvalt aktiivsete ECS-tööülesannete arvust. Oluline on märkida, et pakkuja saab olla seotud ainult ühe grupiga.

Auto Scaling group — valime varasemalt loodud grupi.

Managed scaling — aktiveerime, et pakkuja saaks teenust juurde skaleerida.

Target capacity % — kui suur protsent masinate koormusest on meie jaoks vajalik. Kui märkida 100%, on kõik masinad alati tööle kasutuses. Kui märkida 50%, jääb pooled masinad alati vabaks. Sellisel juhul, kui koormus järsult tõuseb, saavad uued tööülesanded kohe vabadele masinatele, ilma et peaks ootama instantside juurutamist.

Managed termination protection — aktiveerime, see seade lubab pakkujal eemaldada instantside kustutamise kaitse. See toimub, kui masinal ei ole aktiivseid tööülesandeid ja võimaldab Target capacity %.

ECS teenus ja skaleerimise seadistamine

Viimane samm :) Teenuse loomiseks tuleb minna varasemalt loodud klastrisse vahekaardile Teenused.

Launch type — tuleb klõpsata valikul Switch to capacity provider strategy ja valida varasemalt loodud pakkuja.

Task Definition — valime varem loodud Task Definition'i koos selle versiooniga.

Teenuse nimi — et mitte segadusse minna, määrame alati sama, mis Task Definition.

Teenuse tüüp — alati Replica.

Ülesannete arv — soovitud aktiivsete ülesannete arv teenuses. Seda parameetrit juhib skaleerimine, kuid see tuleb ikkagi määrata.

Minimaalne tervena püsiv protsent ja Maksimaalne protsent — määravad ülesannete käitumise juurutamisel. Vaikimisi väärtused 100 ja 200 viitavad sellele, et juurutamise hetkel suureneb ülesannete arv mitu korda ning seejärel naaseb soovitud hulka. Kui teil töötab 1 ülesanne, min=0 ja max=100, siis juurutamisel see tapetakse ja seejärel käivitatakse uus, st toimub seisak. Kui töötab 1 ülesanne, min=50 ja max=150, siis juurutamine ei toimu, sest 1 ülesannet ei saa pooleks jagada ega suurendada 1.5 korda.

Juurutamise tüüp — jätame Rolling update.

Paigutuse mallid — ülesannete paigutamise reeglid masinates. Vaikimisi on AZ Balanced Spread – see tähendab, et iga uus ülesanne paigutatakse uuele instantsile seni, kuni masinad tõusevad kõigis kättesaadavuse tsoonides. Me kasutame tavaliselt BinPack - CPU ja Spread - AZ, mille puhul paigutatakse ülesanded maksimaalselt tihedalt ühte masinasse CPU järgi. Uue masina loomise vajadusel luuakse see uues kättesaadavuse tsoonis.

Laaduritüüp — valime Rakenduse Tasakaalustaja.

Teenuse IAM roll — valime ecsServiceRole.

Laadurite nimi — valime varem loodud tasakaalustaja.

Tervisekontrolli gracia periood — paus enne tervisekontrollide teostamist pärast uue ülesande versiooni, tavaliselt seame 60 sekundit.

Konteiner, mida tasakaalustada — punktis Sihtgrupi nimi valime varem loodud rühma ja kõik täitub automaatselt.

Teenuse automaatne skaleerimine — teenuse skaleerimise parameetrid. Valime Configure Service Auto Scaling to adjust your service’s desired count. Seame minimaalne ja maksimaalne ülesannete arv skaleerimise ajal.

IAM roll teenuse automaatseks skaleerimiseks — valime AWSServiceRoleForApplicationAutoScaling_ECSService.

Automaatne ülesannete skaleerimise poliitika — skaleerimise reeglid. On 2 tüüpi:

Sihtjälgimise — sihtmõõdiku jälgimine (CPU/RAM kasutamine või kõigi ülesannete jaoks tehtud päringute arv). Näiteks tahame, et keskmine protsessori koormus oleks 85%, ning kui see tõuseb kõrgemale, siis uusi ülesandeid lisatakse, kuni see jõuab sihttasemele. Kui koormus on madalam, siis ülesandeid vastupidi eemaldatakse, kui allapoole skaleerimise kaitse ei ole sisse lülitatud (Keela sisse skaleerimine).
Samm-sammuline skaleerimine — reageerimine juhuslikule sündmusele. Siin saab seadistada reageerimise mis tahes sündmusele (CloudWatch Alarm), ja sündmuse toimumisel saab lisada või eemaldada määratud arvu ülesandeid, või määrata täpse ülesannete arvu.

Teenusel võib olla mitu skaleerimisreeglit, mis võib olla kasulik, kuid tuleb jälgida, et need üksteisega ei konflikteeruks.

Kokkuvõte

Kui järgite juhiseid ja kasutate sama Docker'i pilti, peaks teie teenus tagastama sellise lehe.

Oleme loonud mall, mille alusel käivitatakse kõik masinad teenuses. Oleme õppinud ka masinaid ajakohastama, kui mall muutub.
Me oleme seadistatud katkestussignaali töötlemise spottinstantside jaoks, seega eemaldatakse kõik töötavad ülesanded masinal ühe minuti jooksul pärast signaali saamist, nii et midagi ei kaota ega katkestata.
Oleme seadistanud tasakaalustaja, et jaotada koormust masinate vahel ühtlaselt.
Oleme loonud teenuse, mis töötab spottinstantsidel, seeläbi vähendades masinaid umbes kolm korda.
Oleme seadistanud automaatse skaaleerimise mõlemas suunas, et hallata koormuste suurenemist, kuid samal ajal mitte maksta seismise eest.
Kasutame Capacity Provider'i, et rakendus hallaks infrastruktuuri (masinaid), mitte vastupidi.
Me oleme toredad.

Kui teil on ettearvatavad koormuse tõusud, näiteks reklaamite suure e-kirja saatmisega, saate seadistada skaaleerimise ajakava järgi.

Samuti on võimalik teha skaaleerimist andmete põhjal erinevatest teie süsteemi osadest. Näiteks meil on funktsionaalsus isikliku reklaamipakkumise saatmiseks. mobiilirakenduse kasutajad. Mõnikord saadetakse kampaania 1M+ inimesele. Pärast sellist saatmist täheldatakse alati suurt API-päringute kasvu, kuna palju kasutajaid siseneb samal ajal rakendusse. Seega, kui näeme, et promotsioonipushide saatmise järjekorras on oluliselt rohkem inimesi kui tavapäraselt, saame kohe käivitada mitu täiendavat masinat ja ülesannet, et olla valmis koormuseks.

Oleksin väga tänulik, kui jagaksite kommentaarides huvitavaid juhtumeid spottinstantside ja ECS kasutamise kohta või midagi, mis puudutab skaleerimist.

Peagi tulevad artiklid selle kohta, kuidas töötleme tuhandeid analüütilisi sündmusi sekundis peamiselt serverless tehnoloogial (rahaga) ja kuidas teenuste juurutamine toimub GitLab CI ja Terraform Cloud abil.

Liituge meiega, see on huvitav!

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.