Ndërtimi i një API të shkallëzuar në Instancat e Spot AWS

Pershendetje te gjitheve! Emri im është Kirill, unë jam CTO në Adapty. Pjesa më e madhe e arkitekturës sonë është në AWS dhe sot do të flas për mënyrën se si i ulëm kostot e serverit me 3 herë duke përdorur shembuj të spotit në një mjedis prodhimi, si dhe si të konfigurojmë shkallëzimin automatik të tyre. Së pari do të ketë një përmbledhje se si funksionon, dhe më pas udhëzime të hollësishme për fillimin.

Cilat janë Instancat Spot?

Vend Instancat janë serverë të përdoruesve të tjerë të AWS që aktualisht janë të papunë dhe i shesin ato me një zbritje të madhe (Amazon shkruan deri në 90%, sipas përvojës sonë ~ 3x, ndryshon në varësi të rajonit, AZ dhe llojit të shembullit). Dallimi i tyre kryesor nga ato të zakonshmet është se ato mund të fiken në çdo kohë. Prandaj, për një kohë të gjatë kemi besuar se është normale t'i përdorim për mjedise të virgjëra, ose për detyra të llogaritjes së diçkaje, me rezultate të ndërmjetme të ruajtura në S3 ose në bazën e të dhënave, por jo për shitje. Ka zgjidhje të palëve të treta që ju lejojnë të përdorni spote në prodhim, por ka shumë paterica për rastin tonë, kështu që ne nuk i zbatuam ato. Qasja e përshkruar në artikull funksionon tërësisht brenda funksionalitetit standard AWS, pa skripta shtesë, kurora, etj.

Më poshtë janë disa pamje të ekranit që tregojnë historinë e çmimeve për rastet e rastit.

m5.i madh në rajonin eu-perëndim-1 (Irlandë). Çmimi ka qenë kryesisht i qëndrueshëm për 3 muaj, aktualisht duke kursyer 2.9x.

m5.i madh në rajonin e SHBA-lindje-1 (N. Virginia). Çmimi ndryshon vazhdimisht gjatë 3 muajve, duke kursyer aktualisht nga 2.3x në 2.8x në varësi të zonës së disponueshmërisë.

t3.i vogël në rajonin e SHBA-lindje-1 (N. Virginia). Çmimi ka qenë i qëndrueshëm për 3 muaj, aktualisht duke kursyer 3.4x.

Arkitektura e shërbimit

Arkitektura bazë e shërbimit për të cilën do të flasim në këtë artikull është paraqitur në diagramin më poshtë.

Balancuesi i ngarkesës së aplikacionit → Grupi i synuar EC2 → Shërbimi elastik i kontejnerëve

Balancuesi i ngarkesës së aplikacionit (ALB) përdoret si balancues, i cili dërgon kërkesa në Grupin e synuar EC2 (TG). TG është përgjegjëse për hapjen e porteve në instancat për ALB dhe lidhjen e tyre me portet e kontejnerëve të Shërbimit Elastic Container (ECS). ECS është një analog i Kubernetes në AWS, i cili menaxhon kontejnerët Docker.

Një shembull mund të ketë disa kontejnerë që funksionojnë me të njëjtat porte, kështu që ne nuk mund t'i vendosim ato në mënyrë fikse. ECS i thotë TG se po lëshon një detyrë të re (në terminologjinë e Kubernetes kjo quhet pod), ai kontrollon për porte falas në shembull dhe cakton njërën prej tyre në detyrën e nisur. TG gjithashtu kontrollon rregullisht nëse instanca dhe API po punojnë me të duke përdorur kontrollin shëndetësor, dhe nëse sheh ndonjë problem, ndalon dërgimin e kërkesave atje.

EC2 Auto Scaling Groups + Ofruesit e Kapacitetit ECS

Diagrami i mësipërm nuk tregon shërbimin EC2 Auto Scaling Groups (ASG). Nga emri mund të kuptoni se është përgjegjës për shkallëzimin e rasteve. Sidoqoftë, deri vonë, AWS nuk kishte një aftësi të integruar për të menaxhuar numrin e makinave që funksionojnë nga ECS. ECS bëri të mundur shkallëzimin e numrit të detyrave, për shembull, sipas përdorimit të CPU, RAM ose numrit të kërkesave. Por nëse detyrat pushtuan të gjitha rastet e lira, atëherë makinat e reja nuk u krijuan automatikisht.

Kjo ka ndryshuar me ardhjen e Ofruesve të Kapacitetit ECS (ECS CP). Tani çdo shërbim në ECS mund të shoqërohet me një ASG, dhe nëse detyrat nuk përshtaten në instancat e ekzekutimit, atëherë do të ngrihen të reja (por brenda kufijve të vendosur ASG). Kjo funksionon gjithashtu në drejtim të kundërt, nëse ECS CP sheh instanca boshe pa detyra, atëherë do të japë komandën ASG për t'i mbyllur ato. ECS CP ka aftësinë të specifikojë një përqindje të synuar të ngarkesës së shembullit, në mënyrë që një numër i caktuar makinash të jenë gjithmonë të lira për detyra të shkallëzimit të shpejtë; Unë do të flas për këtë pak më vonë.

Modelet e nisjes EC2

Shërbimi i fundit për të cilin do të flas përpara se të hyj në detaje rreth krijimit të kësaj infrastrukture është EC2 Launch Templates. Kjo ju lejon të krijoni një shabllon sipas të cilit do të fillojnë të gjitha makinat, në mënyrë që të mos e përsërisni këtë nga e para çdo herë. Këtu mund të zgjidhni llojin e makinës për të nisur, grupin e sigurisë, imazhin e diskut dhe shumë parametra të tjerë. Ju gjithashtu mund të specifikoni të dhënat e përdoruesit që do të ngarkohen në të gjitha rastet e nisura. Ju mund të ekzekutoni skriptet në të dhënat e përdoruesit, për shembull, mund të redaktoni përmbajtjen e një skedari Konfigurimet e agjentit ECS.

Një nga parametrat më të rëndësishëm të konfigurimit për këtë artikull është ECS_ENABLE_SPOT_INSTANCE_DRAINING= e vërtetë. Nëse ky parametër është i aktivizuar, atëherë sapo ECS merr një sinjal se një shembull i pikës po hiqet, ai transferon të gjitha detyrat që punojnë në të në statusin Draining. Asnjë detyrë e re nuk do t'i caktohet këtij shembulli; nëse ka detyra që dëshirojnë t'i vendosen për momentin, ato do të anulohen. Kërkesat nga balancuesi nuk vijnë gjithashtu. Njoftimi për fshirjen e shembullit vjen 2 minuta përpara ngjarjes aktuale. Prandaj, nëse shërbimi juaj nuk kryen detyra më të gjata se 2 minuta dhe nuk ruan asgjë në disk, atëherë mund të përdorni rastet spot pa humbur të dhëna.

Në lidhje me diskun - AWS kohët e fundit unë kam Është e mundur të përdoret Elastic File System (EFS) së bashku me ECS; me këtë skemë, edhe disku nuk është pengesë, por ne nuk e provuam këtë, pasi në parim nuk na nevojitet disku për të ruajtur gjendjen. Si parazgjedhje, pas marrjes SIGINT (dërgohet kur një detyrë transferohet në statusin "Draining", të gjitha detyrat e ekzekutimit do të ndalen pas 30 sekondash, edhe nëse nuk kanë përfunduar ende; mund ta ndryshoni këtë kohë duke përdorur parametrin ECS_CONTAINER_STOP_TIMEOUT. Gjëja kryesore është që të mos e vendosni për më shumë se 2 minuta për makineritë spot.

Krijimi i një shërbimi

Le të kalojmë në krijimin e shërbimit të përshkruar. Në këtë proces, unë do të përshkruaj gjithashtu disa pika të dobishme që nuk u përmendën më lart. Në përgjithësi, ky është një udhëzim hap pas hapi, por unë nuk do të shqyrtoj disa raste shumë themelore ose, përkundrazi, shumë specifike. Të gjitha veprimet kryhen në konsolën vizuale AWS, por mund të riprodhohen në mënyrë programore duke përdorur CloudFormation ose Terraform. Në Adapty ne përdorim Terraform.

Modeli i nisjes EC2

Ky shërbim krijon një konfigurim të makinave që do të përdoren. Modelet menaxhohen në seksionin EC2 -> Instances -> Launch templates.

Imazhi i makinës Amazon (AMI) — specifikoni imazhin e diskut me të cilin do të hapen të gjitha instancat. Për ECS, në shumicën e rasteve ia vlen të përdorni imazhin e optimizuar nga Amazon. Ai përditësohet rregullisht dhe përmban gjithçka të nevojshme që ECS të funksionojë. Për të gjetur ID-në aktuale të imazhit, shkoni te faqja AMI të optimizuara nga Amazon ECS, zgjidhni rajonin që po përdorni dhe kopjoni ID-në AMI për të. Për shembull, për rajonin us-east-1, ID-ja aktuale në kohën e shkrimit është ami-00c7c1cf5bdc913ed. Ky ID duhet të futet në artikullin Specifikoni një vlerë të personalizuar.

Lloji i shembullit - tregoni llojin e shembullit. Zgjidhni atë që i përshtatet më mirë detyrës suaj.

Çifti i çelësave (identifikimi) — specifikoni një certifikatë me të cilën mund të lidheni me shembullin nëpërmjet SSH, nëse është e nevojshme.

Cilësimet e rrjetit — specifikoni parametrat e rrjetit. Platforma e rrjetëzimit në shumicën e rasteve duhet të ketë një re private virtuale (VPC). Grupet e sigurisë — grupet e sigurisë për rastet tuaja. Meqenëse do të përdorim një balancues përpara instancave, unë rekomandoj të specifikoni këtu një grup që lejon lidhjet hyrëse vetëm nga balancuesi. Kjo do të thotë, do të keni 2 grupe sigurie, një për balancuesin, i cili lejon lidhjet hyrëse nga kudo në portat 80 (http) dhe 443 (https), dhe i dyti për makineritë, i cili lejon lidhjet hyrëse në çdo portë nga grupi i balancuesit. . Lidhjet dalëse në të dy grupet duhet të hapen duke përdorur protokollin TCP në të gjitha portet në të gjitha adresat. Ju mund të kufizoni portet dhe adresat për lidhjet dalëse, por më pas duhet të monitoroni vazhdimisht që nuk po përpiqeni të aksesoni diçka në një port të mbyllur.

Magazinimi (vëllimet) — specifikoni parametrat e diskut për makinat. Madhësia e diskut nuk mund të jetë më e vogël se ajo e specifikuar në AMI; për ECS Optimized është 30 GiB.

Detaje të avancuara — specifikoni parametra shtesë.

Opsioni i blerjes — nëse duam të blejmë raste spot. Ne duam, por nuk do ta kontrollojmë këtë kuti këtu; do ta konfigurojmë në Grupin e shkallëzimit automatik, ka më shumë opsione atje.

Profili i shembullit IAM — tregoni rolin me të cilin do të hapen instancat. Në mënyrë që instancat të ekzekutohen në ECS, atyre u duhen leje, të cilat zakonisht gjenden në rol ecsRoli i shembullit. Në disa raste mund të krijohet, nëse jo, atëherë këtu udhëzim se si ta bëni këtë. Pas krijimit, ne e tregojmë atë në shabllon.
Më tej ka shumë parametra, në thelb ju mund të lini vlerat e paracaktuara kudo, por secili prej tyre ka një përshkrim të qartë. Unë gjithmonë aktivizoj shembullin e optimizuar nga EBS dhe opsionet T2/T3 të pakufizuar nëse përdoren i shpërthyeshëm raste.

Të dhënat e përdoruesit — tregoni të dhënat e përdoruesit. Ne do të modifikojmë skedarin /etc/ecs/ecs.config, i cili përmban konfigurimin e agjentit ECS.
Një shembull se si mund të duken të dhënat e përdoruesit:

#!/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 — parametri tregon se shembulli i përket një grupi me emrin e dhënë, domethënë, ky grup do të jetë në gjendje të vendosë detyrat e tij në këtë server. Nuk kemi krijuar ende një grup, por këtë emër do ta përdorim kur ta krijojmë.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — Parametri specifikon që kur merret një sinjal për të fikur një shembull spot, të gjitha detyrat në të duhet të transferohen në statusin Draining.

ECS_CONTAINER_STOP_TIMEOUT=1m - parametri specifikon që pas marrjes së një sinjali SIGINT, të gjitha detyrat kanë 1 minutë përpara se të vriten.

ECS_ENGINE_AUTH_TYPE=docker — parametri tregon që skema Docker përdoret si mekanizëm autorizimi

ECS_ENGINE_AUTH_DATA=... — parametrat e lidhjes me regjistrin privat të kontejnerit, ku ruhen imazhet tuaja Docker. Nëse është publike, atëherë nuk keni nevojë të specifikoni asgjë.

Për qëllimet e këtij artikulli, unë do të përdor një imazh publik nga Docker Hub, kështu që specifikoni parametrat ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nuk keni nevojë.

Mirë ta di: Rekomandohet të përditësoni rregullisht AMI, sepse versionet e reja përditësojnë versionet e Docker, Linux, agjentit ECS, etj. Për të mos harruar këtë, mund të konfiguroni njoftimet në lidhje me lëshimin e versioneve të reja. Mund të merrni njoftime me email dhe të përditësoni manualisht, ose mund të shkruani një funksion Lambda që do të krijojë automatikisht një version të ri të Launch Template me një AMI të përditësuar.

EC2 Auto Scaling Group

Auto Scaling Group është përgjegjës për nisjen dhe shkallëzimin e rasteve. Grupet menaxhohen në seksionin EC2 -> Auto Scaling -> Auto Scaling Groups.

Nis shabllonin — zgjidhni shabllonin e krijuar në hapin e mëparshëm. Ne lëmë versionin e paracaktuar.

Opsionet e blerjes dhe llojet e shembullit — specifikoni llojet e instancave për grupin. Përmbajuni shabllonit të nisjes përdor llojin e shembullit nga Modeli Launch. Kombinimi i opsioneve të blerjes dhe llojeve të shembullit ju lejon të konfiguroni në mënyrë fleksibël llojet e shembujve. Ne do ta përdorim atë.

Bazë opsionale sipas kërkesës — numri i rasteve të rregullta, jo-spot që do të funksionojnë gjithmonë.

Përqindja sipas kërkesës mbi bazën — raporti i përqindjes së instancave të rregullta dhe të rastësishme, 50-50 do të shpërndahen në mënyrë të barabartë, 20-80 për çdo instancë të rregullt do të ngrihen 4 ato spote. Për qëllimet e këtij shembulli, unë do të tregoj 50-50, por në realitet ne më së shpeshti bëjmë 20-80, në disa raste 0-100.

Llojet e instancave — këtu mund të specifikoni lloje shtesë të instancave që do të përdoren në grup. Nuk e kemi përdorur kurrë sepse nuk e kuptoj vërtet kuptimin e tregimit. Ndoshta kjo është për shkak të kufizimeve në lloje të veçanta të rasteve, por ato mund të rriten lehtësisht përmes mbështetjes. Nëse e njihni aplikacionin, do të jem i lumtur ta lexoj atë në komente)

Rrjet — cilësimet e rrjetit, zgjidhni VPC dhe nënrrjetat për makinat, në shumicën e rasteve duhet të zgjidhni të gjitha nënrrjetet e disponueshme.

Balancimi i ngarkesës - cilësimet e balancuesit, por ne do ta bëjmë këtë veçmas, nuk do të prekim asgjë këtu. Kontrollet shëndetësore gjithashtu do të konfigurohet më vonë.

Madhësia e grupit - ne tregojmë kufijtë në numrin e makinave në grup dhe numrin e dëshiruar të makinave në fillim. Numri i makinave në grup nuk do të jetë kurrë më i vogël se minimumi i specifikuar dhe më shumë se maksimumi, edhe nëse shkallëzimi duhet të ndodhë sipas metrikës.

Politikat e shkallëzimit — parametrat e shkallëzimit, por ne do të shkallëzojmë në bazë të detyrave të ekzekutimit të ECS, kështu që do të konfigurojmë shkallëzimin më vonë.

Shembull mbrojtje nga shkalla — mbrojtja e rasteve nga fshirja kur zvogëlohet. Ne e aktivizojmë atë në mënyrë që ASG të mos fshijë makinën që ka detyra në punë. Ofruesi i Kapacitetit ECS do të çaktivizojë mbrojtjen për rastet që nuk kanë detyra.

Shtoni etiketa — ju mund të specifikoni etiketat për shembuj (për këtë, kutia e kontrollit Etiketimi i rasteve të reja duhet të kontrollohet). Unë rekomandoj të specifikoni etiketën e emrit, atëherë të gjitha rastet që hapen brenda grupit do të kenë të njëjtin emër dhe është e përshtatshme t'i shikoni ato në tastierë.

Pas krijimit të grupit, hapeni atë dhe shkoni te seksioni i konfigurimeve të avancuara.Pse të gjitha opsionet nuk janë të dukshme në tastierë në fazën e krijimit.

Politikat e përfundimit — rregullat që merren parasysh gjatë fshirjes së rasteve. Ato aplikohen sipas radhës. Zakonisht përdorim ato në foton më poshtë. Së pari, rastet me modelin më të vjetër të Nisjes fshihen (për shembull, nëse përditësuam AMI, krijuam një version të ri, por të gjitha rastet arritën të kalonin në të). Më pas zgjidhen rastet që janë më afër orës tjetër të faturimit. Dhe më pas ato më të vjetrat zgjidhen bazuar në datën e nisjes.

Mirë ta di: për të përditësuar të gjitha makinat në një grup, të përshtatshëm për t'u përdorur Rifresko shembull. Nëse e kombinoni këtë me funksionin Lambda nga hapi i mëparshëm, do të keni një sistem përditësimi plotësisht të automatizuar të shembullit. Përpara se të përditësoni të gjitha makinat, duhet të çaktivizoni mbrojtjen e shkallës së instancës për të gjitha rastet në grup. Jo konfigurim në grup, por mbrojtje nga vetë makinat, kjo bëhet në skedën e menaxhimit të shembullit.

Balancuesi i ngarkesës së aplikacionit dhe grupi i synuar EC2

Balancuesi krijohet në seksionin EC2 → Load Balancing → Load Balancers. Ne do të përdorim Application Load Balancer; një krahasim i llojeve të ndryshme të balancuesve mund të lexohet në faqe shërbimi.

dëgjuesit - ka kuptim të krijoni portat 80 dhe 443 dhe të ridrejtoni nga 80 në 443 duke përdorur rregullat e balancuesit më vonë.

Zonat e Disponueshmërisë — në shumicën e rasteve, ne zgjedhim zonat e aksesueshmërisë për të gjithë.

Konfiguro Cilësimet e Sigurisë — këtu tregohet certifikata SSL për balancuesin, opsioni më i përshtatshëm është të bëjë një certifikatë në ACM. Rreth dallimeve Politika e Sigurisë mund të lexohet në dokumentacionin, mund ta lini të zgjedhur si parazgjedhje ELBSecurityPolicy-2016-08. Pas krijimit të balancuesit, do ta shihni Emri i DNS, që ju nevojitet për të konfiguruar CNAME për domenin tuaj. Për shembull, kështu duket në Cloudflare.

Grupi i Sigurisë — krijoni ose zgjidhni një grup sigurie për balancuesin, kam shkruar më shumë për këtë pak më lart në seksionin EC2 Launch Template → Seksioni i cilësimeve të rrjetit.

Grupi i synuar — ne krijojmë një grup që është përgjegjës për drejtimin e kërkesave nga balancuesi te makineritë dhe kontrollimin e disponueshmërisë së tyre për t'i zëvendësuar ato në rast problemesh. Lloji i synuar duhet të jetë shembull, Protokoll и Port çdo, nëse përdorni HTTPS për komunikim midis balancuesit dhe instancave, atëherë duhet të ngarkoni një certifikatë tek ata. Për qëllimet e këtij shembulli, ne nuk do ta bëjmë këtë, ne thjesht do të largohemi nga porti 80.

Kontrollet shëndetësore — parametrat për kontrollimin e funksionalitetit të shërbimit. Në një shërbim real, kjo duhet të jetë një kërkesë e veçantë që zbaton pjesë të rëndësishme të logjikës së biznesit; për qëllimet e këtij shembulli, unë do të lë cilësimet e paracaktuara. Më pas, mund të zgjidhni intervalin e kërkesës, kohëzgjatjen, kodet e suksesit, etj. Në shembullin tonë, ne do të tregojmë kodet e suksesit 200-399, sepse imazhi Docker që do të përdoret kthen një kod 304.

Regjistro objektivat — këtu përzgjidhen makinat për grupin, por në rastin tonë kjo do të bëhet nga ECS, kështu që ne thjesht e kapërcejmë këtë hap.

Mirë ta di: në nivelin e balancuesit mund të aktivizoni regjistrat që do të ruhen në S3 në një farë mase formatin. Nga atje ato mund të eksportohen në shërbime të palëve të treta për analitikë, ose mund të bëni pyetje SQL drejtpërdrejt në të dhënat në S3 me duke përdorur Athena. Është i përshtatshëm dhe funksionon pa ndonjë kod shtesë. Unë rekomandoj gjithashtu vendosjen e heqjes së regjistrave nga kova S3 pas një periudhe të caktuar kohe.

Përkufizimi i detyrës ECS

Në hapat e mëparshëm, ne krijuam gjithçka që lidhet me infrastrukturën e shërbimit; tani kalojmë në përshkrimin e kontejnerëve që do të hedhim në treg. Kjo bëhet në seksionin ECS → Përkufizimet e detyrave.

Përputhshmëria e llojit të nisjes - zgjidhni EC2.

Ekzekutimi i detyrës Roli IAM - zgjidhni ecsTaskExecutionRole. Duke e përdorur atë, shkruhen regjistrat, jepet qasja në variablat sekrete, etj.

Në seksionin Përkufizimet e kontejnerit, klikoni Shto kontejnerin.

Imazh — lidhje me imazhin me kodin e projektit; për këtë shembull unë do të përdor një imazh publik nga Docker Hub bitnami/node-shembull:0.0.1.

Kufijtë e kujtesës — kufijtë e kujtesës për kontejnerin. Kufiri i vështirë — limit i fortë, nëse kontejneri shkon përtej vlerës së specifikuar, komanda docker kill do të ekzekutohet, kontejneri do të vdesë menjëherë. Kufiri i butë — kufiri i butë, kontejneri mund të shkojë përtej vlerës së specifikuar, por ky parametër do të merret parasysh kur vendosni detyra në makina. Për shembull, nëse një makinë ka 4 GiB RAM dhe kufiri i butë i një kontejneri është 2048 MiB, atëherë kjo makinë mund të ketë maksimumi 2 detyra ekzekutimi me këtë kontejner. Në realitet, 4 GiB RAM është pak më pak se 4096 MiB, kjo mund të shihet në skedën ECS Instances në grup. Kufiri i butë nuk mund të jetë më i madh se kufiri i fortë. Është e rëndësishme të kuptohet se nëse ka disa kontejnerë në një detyrë, atëherë kufijtë e tyre përmblidhen.

Hartat e porteve - në Porti pritës Ne tregojmë 0, kjo do të thotë se porti do të caktohet në mënyrë dinamike dhe do të monitorohet nga Target Group. Porti i kontejnerëve — porti në të cilin ekzekutohet aplikacioni juaj shpesh specifikohet në komandën e ekzekutimit ose caktohet në kodin e aplikacionit tuaj, Dockerfile, etj. Për shembullin tonë ne do të përdorim 3000 sepse është renditur në dockerfile imazhi që përdoret.

Kontroll shëndetësor — Parametrat e kontrollit të shëndetit të kontejnerit, të mos ngatërrohen me atë të konfiguruar në grupin e synuar.

mjedis - cilësimet e mjedisit. Njësitë CPU - të ngjashme me kufijtë e kujtesës, vetëm për procesorin. Çdo bërthamë procesori është 1024 njësi, kështu që nëse serveri ka një procesor me dy bërthama dhe kontejneri është vendosur në 512, atëherë 4 detyra me këtë kontejner mund të hapen në një server. Njësitë e CPU gjithmonë korrespondojnë me numrin e bërthamave; nuk mund të ketë pak më pak prej tyre, siç është rasti me kujtesën.

Komandë — një komandë për të nisur një shërbim brenda një kontejneri, të gjithë parametrat specifikohen të ndara me presje. Kjo mund të jetë gunicorn, npm, etj. Nëse nuk specifikohet, do të përdoret vlera e direktivës CMD nga Dockerfile. Ne tregojmë npm,start.

Variablat e mjedisit — variablat e mjedisit të kontejnerit. Këto mund të jenë ose të dhëna të thjeshta teksti ose variabla sekrete nga Menaxher i sekreteve ose Ruajtja e parametrave.

Magazinimi dhe Regjistrimi — këtu do të konfigurojmë regjistrimin në regjistrat e CloudWatch (një shërbim për regjistrat nga AWS). Për ta bërë këtë, thjesht aktivizoni kutinë e kontrollit të konfigurimit automatik të regjistrave të CloudWatch. Pas krijimit të Përkufizimit të Detyrës, një grup regjistrash do të krijohen automatikisht në CloudWatch. Si parazgjedhje, regjistrat ruhen në të për një kohë të pacaktuar; Unë rekomandoj ndryshimin e periudhës së ruajtjes nga Asnjëherë Skadon në periudhën e kërkuar. Kjo bëhet në grupet CloudWatch Log, duhet të klikoni në periudhën aktuale dhe të zgjidhni një të re.

ECS Cluster dhe ECS Capacity Provider

Shkoni te seksioni ECS → Clusters për të krijuar një grup. Ne zgjedhim EC2 Linux + Networking si shabllon.

Emri i grupit - shumë e rëndësishme, ne bëjmë këtu të njëjtin emër siç specifikohet në parametrin Launch Template ECS_CLUSTERnë rastin tonë - DemoApiClusterProd. Kontrolloni kutinë e kontrollit Krijo një grup bosh. Opsionale, mund të aktivizoni Container Insights për të parë metrikat për shërbimet në CloudWatch. Nëse keni bërë gjithçka në mënyrë korrekte, atëherë në seksionin ECS Instances do të shihni makinat që janë krijuar në grupin Auto Scaling.

Shkoni te skeda Ofruesit e Kapacitetit dhe krijoni një të re. Më lejoni t'ju kujtoj se është e nevojshme për të kontrolluar krijimin dhe mbylljen e makinave në varësi të numrit të detyrave të ekzekutimit të ECS. Është e rëndësishme të theksohet se një ofrues mund të caktohet vetëm në një grup.

Grupi i shkallëzimit automatik — zgjidhni grupin e krijuar më parë.

Shkallëzimi i menaxhuar — aktivizoni atë në mënyrë që ofruesi të mund të shkallëzojë shërbimin.

Kapaciteti i synuar % — sa përqind e makinerive të ngarkuara me detyra na duhen. Nëse specifikoni 100%, atëherë të gjitha makinat do të jenë gjithmonë të zëna me detyrat e ekzekutimit. Nëse specifikoni 50%, atëherë gjysma e makinave do të jenë gjithmonë falas. Në këtë rast, nëse ka një kërcim të mprehtë në ngarkesë, taksitë e reja do të arrijnë menjëherë te makinat e lira, pa pasur nevojë të presin që të vendosen rastet.

Mbrojtja e menaxhuar nga përfundimi — aktivizoni, ky parametër lejon ofruesin të heqë mbrojtjen e rasteve nga fshirja. Kjo ndodh kur nuk ka detyra aktive në makinë dhe lejon kapacitetin e synuar%.

Shërbimi ECS dhe konfigurimi i shkallëzimit

Hapi i fundit :) Për të krijuar një shërbim, duhet të shkoni te grupi i krijuar më parë në skedën Shërbimet.

Lloji i nisjes — duhet të klikoni në Strategjinë Kalo te ofruesi i kapacitetit dhe të zgjidhni ofruesit e krijuar më parë.

Përkufizimi i detyrës — zgjidhni Përkufizimin e Detyrës së krijuar më parë dhe rishikimin e tij.

Emri i shërbimit — për të shmangur konfuzionin, ne tregojmë gjithmonë të njëjtën gjë si Përkufizimi i Detyrës.

Lloji i shërbimit - gjithmonë Replica.

Numri i detyrave — numri i dëshiruar i detyrave aktive në shërbim. Ky parametër kontrollohet me shkallëzim, por gjithsesi duhet të specifikohet.

Përqindja minimale e shëndetshme и Përqindja maksimale — përcaktoni sjelljen e detyrave gjatë vendosjes. Vlerat e paracaktuara janë 100 dhe 200, që tregojnë se në momentin e vendosjes numri i detyrave do të rritet disa herë dhe më pas do të kthehet në vlerën e dëshiruar. Nëse keni 1 detyrë në ekzekutim, min=0 dhe max=100, atëherë gjatë vendosjes ajo do të mbyllet, dhe pas kësaj do të ngrihet një e re, domethënë do të jetë joproduktive. Nëse 1 detyrë po ekzekutohet, min=50, max=150, atëherë vendosja nuk do të ndodhë fare, sepse 1 detyrë nuk mund të ndahet në gjysmë ose të rritet me një herë e gjysmë.

Lloji i vendosjes — largohuni nga përditësimi Rolling.

Modelet e vendosjes — rregullat për vendosjen e detyrave në makina. Parazgjedhja është AZ Balanced Spread - kjo do të thotë se çdo detyrë e re do të vendoset në një shembull të ri derisa makinat në të gjitha zonat e disponueshmërisë të ngrihen. Zakonisht bëjmë BinPack - CPU dhe Spread - AZ; me këtë politikë, detyrat vendosen sa më dendur në një makinë për CPU. Nëse është e nevojshme të krijohet një makinë e re, ajo krijohet në një zonë të re disponueshmërie.

Lloji i balancuesit të ngarkesës — zgjidhni Application Load Balancer.

Roli i shërbimit IAM - zgjidhni ecsServiceRole.

Emri i balancuesit të ngarkesës — zgjidhni balancuesin e krijuar më parë.

Periudha e mospagimit të kontrollit shëndetësor — ndalojmë përpara se të kryejmë kontrollet shëndetësore pasi kemi vendosur një detyrë të re, zakonisht e vendosim në 60 sekonda.

Enë për të ngarkuar bilancin — në artikullin Emri i grupit të synuar, zgjidhni grupin e krijuar më parë dhe gjithçka do të plotësohet automatikisht.

Shkallëzim automatik i shërbimit — parametrat e shkallëzimit të shërbimit. Zgjidhni Konfiguro shkallëzimin automatik të shërbimit për të rregulluar numrin e dëshiruar të shërbimit tuaj. Ne vendosim numrin minimal dhe maksimal të detyrave gjatë shkallëzimit.

Roli IAM për shkallëzimin automatik të shërbimit - zgjidhni AWSServiceRoleForApplicationAutoScaling_ECSService.

Politikat automatike të shkallëzimit të detyrave - rregullat për shkallëzimin. Ka 2 lloje:

1. Ndjekja e synimeve — gjurmimi i metrikës së synuar (përdorimi i CPU/RAM ose numri i kërkesave për secilën detyrë). Për shembull, ne duam që ngarkesa mesatare e procesorit të jetë 85%, kur të bëhet më e lartë, do të shtohen detyra të reja derisa të arrijë vlerën e synuar. Nëse ngarkesa është më e ulët, atëherë detyrat do të hiqen, përkundrazi, përveç nëse aktivizohet mbrojtja kundër zvogëlimit (Çaktivizo shkallëzimin).
2. Shkallëzimi i hapit - reagimi ndaj një ngjarje arbitrare. Këtu mund të konfiguroni një reagim ndaj çdo ngjarje (Alarmi CloudWatch), kur të ndodhë, mund të shtoni ose hiqni numrin e caktuar të detyrave ose të specifikoni numrin e saktë të detyrave.

Një shërbim mund të ketë disa rregulla shkallëzimi, kjo mund të jetë e dobishme, gjëja kryesore është të siguroheni që ato të mos bien ndesh me njëra-tjetrën.

Përfundim

Nëse keni ndjekur udhëzimet dhe keni përdorur të njëjtin imazh Docker, shërbimi juaj duhet të kthejë një faqe si kjo.

1. Ne kemi krijuar një shabllon sipas të cilit lëshohen të gjitha makinat në shërbim. Mësuam gjithashtu se si të përditësojmë makinat kur ndryshon shablloni.
2. Ne kemi konfiguruar përpunimin e sinjalit të ndalimit të rastit të spotit, kështu që brenda një minute pas marrjes së tij, të gjitha detyrat e ekzekutimit hiqen nga makina, kështu që asgjë nuk humbet ose ndërpritet.
3. Ne ngritëm balancuesin për të shpërndarë ngarkesën në mënyrë të barabartë nëpër makina.
4. Ne kemi krijuar një shërbim që funksionon në rastet e duhura, i cili redukton kostot e makinës me rreth 3 herë.
5. Ne kemi konfiguruar shkallëzimin automatik në të dy drejtimet për të përballuar ngarkesat e shtuara të punës pa shkaktuar kosto joproduktive.
6. Ne përdorim Capacity Provider në mënyrë që aplikacioni të menaxhojë infrastrukturën (makinat) dhe jo anasjelltas.
7. Ne jemi të shkëlqyer.

Nëse keni rritje të parashikueshme në ngarkesë, për shembull po reklamoni në një fushatë të madhe emaili, mund të konfiguroni shkallëzimin sipas orari.

Ju gjithashtu mund të shkallëzoni bazuar në të dhënat nga pjesë të ndryshme të sistemit tuaj. Për shembull, ne kemi funksionalitetin dërgimi i ofertave individuale promovuese përdoruesit e aplikacionit celular. Ndonjëherë një fushatë u dërgohet mbi 1 milion njerëzve. Pas një shpërndarjeje të tillë, ka gjithmonë një rritje të madhe të kërkesave për API, pasi shumë përdorues hyjnë në aplikacion në të njëjtën kohë. Pra, nëse shohim se ka shumë më shumë tregues standardë në radhë për dërgimin e njoftimeve shtytëse promocionale, mund të nisim menjëherë disa makineri dhe detyra shtesë për të qenë gati për ngarkesën.

Do të jem i lumtur nëse më tregoni në komente raste interesante të përdorimit të rasteve spot dhe ECS ose diçka në lidhje me shkallëzimin.

Së shpejti do të ketë artikuj se si ne përpunojmë mijëra ngjarje analitike në sekondë në një pirg kryesisht pa server (me para) dhe se si funksionon vendosja e shërbimeve duke përdorur GitLab CI dhe Terraform Cloud.

Regjistrohu tek ne, do të jetë interesante!

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem

A përdorni rastet spot në prodhim?

• 22,2%Po 6

• 66,7%Nr 18

• 11,1%Mësova rreth tyre nga një artikull dhe planifikoj t'i përdor ato3

27 përdorues votuan. 5 përdorues abstenuan.

Burimi: www.habr.com