ProHoster > Blogs > Administrācija > Mērogojama API izveide uz AWS vietas gadījumiem

Mērogojama API izveide uz AWS vietas gadījumiem

Sveiki visiem! Mani sauc Kirils, es esmu Adapty CTO. Lielākā daļa mÅ«su arhitektÅ«ras ir uz AWS, un Å”odien es runāŔu par to, kā mēs 3 reizes samazinājām servera izmaksas, ražoÅ”anas vidē izmantojot vietas gadÄ«jumus, kā arÄ« to, kā iestatÄ«t to automātisko mērogoÅ”anu. Vispirms bÅ«s pārskats par to, kā tas darbojas, un pēc tam detalizēti norādÄ«jumi par darba sākÅ”anu.

Kas ir spot instances?

Vieta instances ir citu AWS lietotāju serveri, kas Å”obrÄ«d ir dÄ«kstāvē, un viņi tos pārdod ar lielu atlaidi (Amazon raksta lÄ«dz 90%, mÅ«su pieredzē ~3x, mainās atkarÄ«bā no reÄ£iona, AZ un instances veida). To galvenā atŔķirÄ«ba no parastajiem ir tā, ka tos var izslēgt jebkurā laikā. Tāpēc ilgu laiku mēs uzskatÄ«jām, ka ir normāli tos izmantot neapstrādātām vidēm vai kaut ko aprēķināt, ar starprezultātiem, kas saglabāti S3 vai datu bāzē, bet ne pārdoÅ”anai. Ir treÅ”o puÅ”u risinājumi, kas ļauj ražoÅ”anā izmantot spotus, taču mÅ«su gadÄ«jumā ir daudz kruÄ·u, tāpēc mēs tos neieviesām. Rakstā aprakstÄ«tā pieeja pilnÄ«bā darbojas standarta AWS funkcionalitātes ietvaros, bez papildu skriptiem, kronām utt.

Tālāk ir sniegti daži ekrānuzņēmumi, kas parāda tūlītēju gadījumu cenu vēsturi.

m5.liels eu-west-1 (ÄŖrija) reÄ£ionā. Cena pārsvarā ir stabila 3 mēneÅ”us, Å”obrÄ«d ietaupot 2.9x.

Mērogojama API izveide uz AWS vietas gadījumiem

m5.liels ASV-austrumu-1 reÄ£ionā (N. Virdžīnija). Cena nepārtraukti mainās 3 mēneÅ”u laikā, Å”obrÄ«d ietaupot no 2.3x lÄ«dz 2.8x atkarÄ«bā no pieejamÄ«bas zonas.

Mērogojama API izveide uz AWS vietas gadījumiem

t3.mazs us-east-1 reÄ£ionā (N. Virdžīnija). Cena ir stabila 3 mēneÅ”us, Å”obrÄ«d ietaupa 3.4x.

Mērogojama API izveide uz AWS vietas gadījumiem

Pakalpojumu arhitektūra

Pakalpojuma pamata arhitektÅ«ra, par kuru mēs runāsim Å”ajā rakstā, ir parādÄ«ta zemāk esoÅ”ajā diagrammā.

Mērogojama API izveide uz AWS vietas gadījumiem

Lietojumprogramma Load Balancer ā†’ EC2 mērÄ·a grupa ā†’ ElastÄ«go konteineru serviss

Lietojumprogrammas slodzes lÄ«dzsvarotājs (ALB) tiek izmantots kā balansētājs, kas nosÅ«ta pieprasÄ«jumus EC2 mērÄ·a grupai (TG). TG ir atbildÄ«gs par portu atvērÅ”anu ALB gadÄ«jumos un savienoÅ”anu ar elastÄ«go konteineru pakalpojuma (ECS) konteineru portiem. ECS ir Kubernetes analogs AWS, kas pārvalda Docker konteinerus.

Vienai instancei var bÅ«t vairāki darbojas konteineri ar vienādiem portiem, tāpēc mēs nevaram tos iestatÄ«t fiksēti. ECS paziņo TG, ka tas palaiž jaunu uzdevumu (Kubernetes terminoloÄ£ijā to sauc par podziņu), tā pārbauda, ā€‹ā€‹vai instancē nav brÄ«vu portu, un vienu no tiem pieŔķir palaistajam uzdevumam. TG arÄ« regulāri pārbauda, ā€‹ā€‹vai instance un API strādā pie tā, izmantojot veselÄ«bas pārbaudi, un, ja tā konstatē problēmas, pārtrauc pieprasÄ«jumu sÅ«tÄ«Å”anu.

EC2 automātiskās mērogoÅ”anas grupas + ECS jaudas nodroÅ”inātāji

IepriekÅ” redzamajā diagrammā nav parādÄ«ts EC2 automātiskās mērogoÅ”anas grupu (ASG) pakalpojums. No nosaukuma var saprast, ka tas ir atbildÄ«gs par gadÄ«jumu mērogoÅ”anu. Tomēr vēl nesen AWS nebija iebÅ«vētas iespējas pārvaldÄ«t ECS strādājoÅ”o maŔīnu skaitu. ECS ļāva mērogot uzdevumu skaitu, piemēram, pēc CPU lietojuma, RAM vai pieprasÄ«jumu skaita. Bet, ja uzdevumi aizņēma visus bezmaksas gadÄ«jumus, jaunas maŔīnas netika izveidotas automātiski.

Tas ir mainÄ«jies lÄ«dz ar ECS jaudas nodroÅ”inātāju (ECS CP) parādÄ«Å”anos. Tagad katru pakalpojumu ECS var saistÄ«t ar ASG, un, ja uzdevumi neietilpst esoÅ”ajos gadÄ«jumos, tiks paaugstināti jauni (bet noteikto ASG robežās). Tas darbojas arÄ« pretējā virzienā, ja ECS CP redz dÄ«kstāves gadÄ«jumus bez uzdevumiem, tad tas dos ASG komandu, lai tās izslēgtu. ECS CP ir iespēja norādÄ«t mērÄ·a slodzes procentuālo daļu, lai noteikts maŔīnu skaits vienmēr bÅ«tu brÄ«vs ātrai mērogoÅ”anas uzdevumu veikÅ”anai; par to es runāŔu nedaudz vēlāk.

EC2 palaiŔanas veidnes

Pēdējais pakalpojums, par kuru es runāŔu pirms Ŕīs infrastruktÅ«ras izveides, ir EC2 palaiÅ”anas veidnes. Tas ļauj jums izveidot veidni, pēc kuras visas maŔīnas sāks darboties, lai katru reizi to neatkārtotu no nulles. Å eit jÅ«s varat izvēlēties startējamās maŔīnas veidu, droŔības grupu, diska attēlu un daudzus citus parametrus. Varat arÄ« norādÄ«t lietotāja datus, kas tiks augÅ”upielādēti visās palaistajās instancēs. Varat palaist skriptus lietotāja datos, piemēram, varat rediģēt faila saturu ECS aÄ£entu konfigurācijas.

Viens no svarÄ«gākajiem Ŕī raksta konfigurācijas parametriem ir ECS_ENABLE_SPOT_INSTANCE_DRAINING= patiess. Ja Å”is parametrs ir iespējots, tad, tiklÄ«dz ECS saņem signālu, ka tiek noņemta vietas instance, tā pārsÅ«ta visus ar to saistÄ«tos uzdevumus uz statusu Draining. Å ai instancei netiks pieŔķirti jauni uzdevumi; ja ir uzdevumi, kurus tajā vēlaties izlaist tÅ«lÄ«t, tie tiks atcelti. Pārstāj nākt arÄ« pieprasÄ«jumi no balansiera. Paziņojums par instances dzÄ“Å”anu tiek saņemts 2 minÅ«tes pirms faktiskā notikuma. Tāpēc, ja jÅ«su pakalpojums neveic uzdevumus ilgāk par 2 minÅ«tēm un neko nesaglabā diskā, varat izmantot vietas gadÄ«jumus, nezaudējot datus.

AttiecÄ«bā uz disku - AWS nesen izgatavots Kopā ar ECS ir iespējams izmantot elastÄ«go failu sistēmu (EFS), ar Å”o shēmu pat disks nav Ŕķērslis, taču mēs to neizmēģinājām, jo ā€‹ā€‹principā mums nav nepiecieÅ”ams disks, lai saglabātu stāvokli. Pēc noklusējuma pēc SIGINT saņemÅ”anas (nosÅ«tÄ«ts, kad uzdevums ir pārsÅ«tÄ«ts uz iztukÅ”oÅ”anas statusu), visi izpildāmie uzdevumi tiks apturēti pēc 30 sekundēm, pat ja tie vēl nav pabeigti; Å”o laiku varat mainÄ«t, izmantojot parametru ECS_CONTAINER_STOP_TIMEOUT. Galvenais ir neiestatÄ«t to ilgāk par 2 minÅ«tēm punktmaŔīnām.

Pakalpojuma izveide

Pāriesim pie aprakstÄ«tā pakalpojuma izveidoÅ”anas. Å ajā procesā es papildus aprakstÄ«Å”u vairākus noderÄ«gus punktus, kas netika minēti iepriekÅ”. Kopumā Ŕī ir soli pa solim sniegta instrukcija, taču es neapskatÄ«Å”u dažus ļoti elementārus vai, gluži pretēji, ļoti konkrētus gadÄ«jumus. Visas darbÄ«bas tiek veiktas AWS vizuālajā konsolē, taču tās var reproducēt programmatiski, izmantojot CloudFormation vai Terraform. Uzņēmumā Adapty mēs izmantojam Terraform.

EC2 palaiŔanas veidne

Šis pakalpojums izveido to iekārtu konfigurāciju, kuras tiks izmantotas. Veidnes tiek pārvaldītas sadaļā EC2 -> Instances -> Launch templates.

Amazon maŔīnas attēls (AMI) ā€” norādiet diska attēlu, ar kuru tiks palaists visi gadÄ«jumi. AttiecÄ«bā uz ECS vairumā gadÄ«jumu ir vērts izmantot optimizēto attēlu no Amazon. Tas tiek regulāri atjaunināts un satur visu nepiecieÅ”amo, lai ECS darbotos. Lai uzzinātu paÅ”reizējo attēla ID, dodieties uz lapu Amazon ECS optimizēti AMI, atlasiet izmantoto reÄ£ionu un nokopējiet tā AMI ID. Piemēram, us-east-1 reÄ£ionam paÅ”reizējais ID rakstÄ«Å”anas laikā ir ami-00c7c1cf5bdc913ed. Å is ID ir jāievieto vienumā NorādÄ«t pielāgotu vērtÄ«bu.

GadÄ«juma veids ā€” norāda gadÄ«juma veidu. Izvēlieties to, kas vislabāk atbilst jÅ«su uzdevumam.

Atslēgu pāris (pieteikÅ”anās) ā€” norādiet sertifikātu, ar kuru, ja nepiecieÅ”ams, varat izveidot savienojumu ar gadÄ«jumu, izmantojot SSH.

TÄ«kla iestatÄ«jumi ā€” norādÄ«t tÄ«kla parametrus. TÄ«kla platforma vairumā gadÄ«jumu vajadzētu bÅ«t Virtual Private Cloud (VPC). DroŔības grupas ā€” droŔības grupas jÅ«su gadÄ«jumiem. Tā kā instanču priekŔā izmantosim balansētāju, iesaku Å”eit norādÄ«t grupu, kas pieļauj ienākoÅ”os savienojumus tikai no balansiera. Tas nozÄ«mē, ka jums bÅ«s 2 droŔības grupas, viena balansētājam, kas nodroÅ”ina ienākoÅ”os savienojumus no jebkuras vietas portos 80 (http) un 443 (https), un otrā iekārtām, kas ļauj ienākoÅ”os savienojumus jebkurā portā no balansētāja grupas. . IzejoÅ”ie savienojumi abās grupās ir jāatver, izmantojot TCP protokolu uz visiem portiem uz visām adresēm. Varat ierobežot portus un adreses izejoÅ”ajiem savienojumiem, taču tad jums pastāvÄ«gi jāuzrauga, vai jÅ«s nemēģināt kaut kam piekļūt slēgtā portā.

Krātuve (apjomi) ā€” norādiet maŔīnu diska parametrus. Diska izmērs nedrÄ«kst bÅ«t mazāks par AMI norādÄ«to; ECS Optimized tas ir 30 GiB.

Papildu informācija ā€” norādÄ«t papildu parametrus.

PirkÅ”anas iespēja ā€” vai mēs vēlamies pirkt vietas eksemplārus. Mēs vēlamies, bet mēs neatzÄ«mēsim Å”o izvēles rÅ«tiņu; mēs to konfigurēsim automātiskās mērogoÅ”anas grupā, tur ir vairāk iespēju.

IAM instances profils ā€” norādiet lomu, ar kādu instances tiks uzsāktas. Lai gadÄ«jumi darbotos ECS, tiem ir nepiecieÅ”amas atļaujas, kas parasti ir atrodamas lomā ecsInstanceRole. Dažos gadÄ«jumos to var izveidot, ja nē, tad Å”eit norādÄ«jums par to, kā to izdarÄ«t. Pēc izveides mēs to norādām veidnē.
Tālāk ir daudz parametru, bÅ«tÄ«bā jÅ«s varat atstāt noklusējuma vērtÄ«bas visur, taču katram no tiem ir skaidrs apraksts. Es vienmēr iespējoju EBS optimizēto gadÄ«jumu un T2/T3 Unlimited opcijas, ja tās tiek izmantotas pārsprāgstoÅ”s gadÄ«jumiem.

Lietotājs laiks ā€” norāda lietotāja datus. Mēs rediģēsim failu /etc/ecs/ecs.config, kurā ir ECS aÄ£enta konfigurācija.
Piemērs tam, kā varētu izskatīties lietotāja dati:

#!/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 ā€” parametrs norāda, ka instance pieder klasterim ar doto nosaukumu, tas ir, Å”is klasteris varēs izvietot savus uzdevumus Å”ajā serverÄ«. Mēs vēl neesam izveidojuÅ”i klasteri, bet mēs izmantosim Å”o nosaukumu, veidojot to.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true ā€” parametrs norāda, ka tad, kad tiek saņemts signāls, lai izslēgtu vietas instanci, visi tajā esoÅ”ie uzdevumi ir jāpārsÅ«ta uz Draining statusu.

ECS_CONTAINER_STOP_TIMEOUT=1m - parametrs norāda, ka pēc SIGINT signāla saņemÅ”anas visiem uzdevumiem ir 1 minÅ«te pirms nogalināŔanas.

ECS_ENGINE_AUTH_TYPE=docker ā€” parametrs norāda, ka Docker shēma tiek izmantota kā autorizācijas mehānisms

ECS_ENGINE_AUTH_DATA=... ā€” savienojuma parametri ar privāto konteineru reÄ£istru, kurā tiek glabāti jÅ«su Docker attēli. Ja tas ir publisks, tad nekas nav jānorāda.

Å Ä« raksta vajadzÄ«bām es izmantoÅ”u publisko attēlu no Docker Hub, tāpēc norādiet parametrus ECS_ENGINE_AUTH_TYPE Šø ECS_ENGINE_AUTH_DATA nevajag.

Labi zināt: Ieteicams regulāri atjaunināt AMI, jo jaunās versijas atjaunina Docker, Linux, ECS aÄ£enta uc versijas. Lai par to neaizmirstu, varat iestatÄ«t paziņojumus par jaunu versiju izlaiÅ”anu. Varat saņemt paziņojumus pa e-pastu un atjaunināt manuāli, vai arÄ« varat ierakstÄ«t Lambda funkciju, kas automātiski izveidos jaunu palaiÅ”anas veidnes versiju ar atjauninātu AMI.

EC2 automātiskās mērogoÅ”anas grupa

Auto Scaling Group ir atbildÄ«ga par gadÄ«jumu palaiÅ”anu un mērogoÅ”anu. Grupas tiek pārvaldÄ«tas sadaļā EC2 -> Auto Scaling -> Auto Scaling Groups.

Palaist veidni ā€” atlasiet iepriekŔējā darbÄ«bā izveidoto veidni. Mēs atstājam noklusējuma versiju.

PirkÅ”anas iespējas un gadÄ«jumu veidi ā€” norādiet klastera gadÄ«jumu veidus. Ievērot palaiÅ”anas veidni izmanto palaiÅ”anas veidnes instances veidu. PirkÅ”anas opciju un gadÄ«jumu veidu apvienoÅ”ana ļauj elastÄ«gi konfigurēt gadÄ«jumu tipus. Mēs to izmantosim.

Izvēles bāze pēc pieprasÄ«juma ā€” parasto gadÄ«jumu skaits, kas vienmēr darbosies.

Pēc pieprasÄ«juma procentuālā daļa virs bāzes ā€” parasto un spot instanču procentuālā attiecÄ«ba, 50-50 tiks sadalÄ«ti vienādi, 20-80 uz katru parasto instanci tiks pacelti 4 spot instanci. Å Ä« piemēra vajadzÄ«bām es norādÄ«Å”u 50-50, bet patiesÄ«bā mēs visbiežāk darām 20-80, dažos gadÄ«jumos 0-100.

Instanču veidi ā€” Å”eit varat norādÄ«t papildu gadÄ«jumu veidus, kas tiks izmantoti klasterÄ«. Mēs to nekad neizmantojām, jo ā€‹ā€‹es Ä«sti nesaprotu stāsta nozÄ«mi. Iespējams, tas ir saistÄ«ts ar ierobežojumiem noteikta veida gadÄ«jumiem, taču tos var viegli palielināt, izmantojot atbalstu. Ja zināt pieteikumu, es ar prieku to izlasÄ«Å”u komentāros)

Mērogojama API izveide uz AWS vietas gadījumiem

tÄ«kls ā€” tÄ«kla iestatÄ«jumi, atlasiet VPC un iekārtu apakÅ”tÄ«klus, vairumā gadÄ«jumu jums vajadzētu atlasÄ«t visus pieejamos apakÅ”tÄ«klus.

Slodzes lÄ«dzsvaroÅ”ana - balansiera iestatÄ«jumi, bet mēs to darÄ«sim atseviŔķi, mēs Å”eit neko nepieskarsim. VeselÄ«bas pārbaudes tiks konfigurēts arÄ« vēlāk.

Grupas lielums ā€” startā norādām maŔīnu skaita ierobežojumus klasterÄ« un vēlamo maŔīnu skaitu. Iekārtu skaits klasterÄ« nekad nebÅ«s mazāks par norādÄ«to minimumu un lielāks par maksimālo, pat ja mērogoÅ”ana notiek saskaņā ar metriku.

MērogoÅ”anas politikas ā€” mērogoÅ”anas parametri, bet mērogoÅ”ana tiks veikta, pamatojoties uz ECS uzdevumiem, tāpēc mērogoÅ”anu konfigurēsim vēlāk.

GadÄ«juma mēroga aizsardzÄ«ba ā€” gadÄ«jumu aizsardzÄ«ba pret dzÄ“Å”anu, samazinot. Mēs to iespējojam, lai ASG neizdzēstu maŔīnu, kurai ir darbÄ«bas uzdevumi. ECS jaudas nodroÅ”inātājs atspējos aizsardzÄ«bu gadÄ«jumiem, kuriem nav uzdevumu.

Pievienojiet tagus ā€” varat norādÄ«t instanču tagus (Å”im nolÅ«kam ir jāatzÄ«mē izvēles rÅ«tiņa AtzÄ«mēt jaunas instances). Es iesaku norādÄ«t vārda tagu, tad visiem grupas ietvaros palaistajiem gadÄ«jumiem bÅ«s vienāds nosaukums, un tos ir ērti skatÄ«t konsolē.

Mērogojama API izveide uz AWS vietas gadījumiem

Pēc grupas izveidoÅ”anas atveriet to un dodieties uz sadaļu Advanced configurations.Kāpēc izveides stadijā konsolē nav redzamas visas opcijas.

IzbeigÅ”anas politikas ā€” noteikumi, kas tiek ņemti vērā, dzÄ“Å”ot gadÄ«jumus. Tie tiek piemēroti secÄ«bā. Mēs parasti izmantojam tos, kas redzami zemāk esoÅ”ajā attēlā. Pirmkārt, tiek dzēsti gadÄ«jumi ar vecāko palaiÅ”anas veidni (piemēram, ja mēs atjauninājām AMI, mēs izveidojām jaunu versiju, taču visiem gadÄ«jumiem izdevās pārslēgties uz to). Pēc tam tiek atlasÄ«ti gadÄ«jumi, kas ir vistuvāk nākamajai norēķinu stundai. Un pēc tam tiek atlasÄ«ti vecākie, pamatojoties uz palaiÅ”anas datumu.

Mērogojama API izveide uz AWS vietas gadījumiem

Labi zināt: lai atjauninātu visas maŔīnas klasterÄ«, ērti lietojamas GadÄ«juma atsvaidzināŔana. Ja to apvienosit ar Lambda funkciju no iepriekŔējās darbÄ«bas, jums bÅ«s pilnÄ«bā automatizēta instanču atjaunināŔanas sistēma. Pirms visu iekārtu atjaunināŔanas ir jāatspējo instanču mēroga aizsardzÄ«ba visiem grupas gadÄ«jumiem. Nevis konfigurācija grupā, bet aizsardzÄ«ba no paŔām maŔīnām, tas tiek darÄ«ts cilnē Instances pārvaldÄ«ba.

Lietojumprogrammas slodzes līdzsvarotājs un EC2 mērķa grupa

Balansētājs tiek izveidots sadaļā EC2 ā†’ Load Balancing ā†’ Load Balancers. Mēs izmantosim Application Load Balancer; dažādu veidu balansētāju salÄ«dzinājumu var lasÄ«t vietnē pakalpojuma lapa.

KlausÄ«tāji - ir jēga izveidot portus 80 un 443 un pāradresēt no 80 uz 443, izmantojot balansÄ“Å”anas noteikumus vēlāk.

PieejamÄ«bas zonas ā€” vairumā gadÄ«jumu mēs izvēlamies pieejamÄ«bas zonas ikvienam.

Konfigurējiet droŔības iestatÄ«jumus ā€” Å”eit norādÄ«ts balansētāja SSL sertifikāts, ērtākais variants ir uztaisÄ«t sertifikātu ACM. Par atŔķirÄ«bām DroŔības politika var izlasÄ«t dokumentācija, varat atstāt to atlasÄ«tu pēc noklusējuma ELBSecurityPolicy-2016-08. Pēc balansiera izveidoÅ”anas jÅ«s to redzēsit DNS nosaukums, kas jums ir nepiecieÅ”ams, lai konfigurētu sava domēna CNAME. Piemēram, Ŕādi tas izskatās Cloudflare.

Mērogojama API izveide uz AWS vietas gadījumiem

DroŔības grupa ā€” izveidot vai atlasÄ«t balansētāja droŔības grupu, par to es vairāk rakstÄ«ju tieÅ”i augstāk sadaļā EC2 Launch Template ā†’ Network settings.

MērÄ·a grupa ā€” mēs izveidojam grupu, kas ir atbildÄ«ga par pieprasÄ«jumu marÅ”rutÄ“Å”anu no balansiera uz maŔīnām un to pieejamÄ«bas pārbaudi, lai problēmu gadÄ«jumā tās nomainÄ«tu. MērÄ·a tips jābÅ«t piemēram, Protokols Šø osta jebkura, ja izmantojat HTTPS saziņai starp balansētāju un gadÄ«jumiem, jums ir jāaugÅ”upielādē tajos sertifikāts. Å Ä« piemēra vajadzÄ«bām mēs to nedarÄ«sim, mēs vienkārÅ”i atstāsim 80. portu.

VeselÄ«bas pārbaudes ā€” parametri pakalpojuma funkcionalitātes pārbaudei. Reālā pakalpojumā tam vajadzētu bÅ«t atseviŔķam pieprasÄ«jumam, kas ievieÅ” svarÄ«gas biznesa loÄ£ikas daļas; Ŕī piemēra vajadzÄ«bām es atstāŔu noklusējuma iestatÄ«jumus. Tālāk varat atlasÄ«t pieprasÄ«juma intervālu, taimautu, veiksmes kodus utt. MÅ«su piemērā mēs norādÄ«sim veiksmes kodus 200ā€“399, jo Docker attēls, kas tiks izmantots, atgriež 304 kodu.

Mērogojama API izveide uz AWS vietas gadījumiem

ReÄ£istrēt mērÄ·us ā€” Å”eit tiek atlasÄ«tas grupas automaŔīnas, bet mÅ«su gadÄ«jumā to darÄ«s ECS, tāpēc Å”o soli vienkārÅ”i izlaižam.

Labi zināt: balansētāja lÄ«menÄ« varat iespējot žurnālus, kas tiks saglabāti S3 noteiktā laikā formātā. No turienes tos var eksportēt uz treŔās puses pakalpojumiem analÄ«zei, vai arÄ« varat veikt SQL vaicājumus tieÅ”i S3 datiem, izmantojot izmantojot Atēnu. Tas ir ērti un darbojas bez papildu koda. Es arÄ« iesaku iestatÄ«t žurnālu noņemÅ”anu no S3 kausa pēc noteikta laika.

ECS uzdevuma definīcija

IepriekŔējos soļos mēs izveidojām visu, kas saistÄ«ts ar pakalpojumu infrastruktÅ«ru, tagad mēs pārejam pie konteineru apraksta, ko mēs uzsāksim. Tas tiek darÄ«ts sadaļā ECS ā†’ Uzdevumu definÄ«cijas.

PalaiÅ”anas veida saderÄ«ba - izvēlieties EC2.

Uzdevuma izpildes IAM loma - izvēlēties ecsTaskExecutionRole. Izmantojot to, tiek rakstÄ«ti žurnāli, tiek nodroÅ”ināta piekļuve slepenajiem mainÄ«gajiem utt.

Sadaļā Konteinera definīcijas noklikŔķiniet uz Pievienot konteineru.

attēls ā€” saite uz attēlu ar projekta kodu; Å”im piemēram es izmantoÅ”u publisko attēlu no Docker Hub bitnami/mezgls-piemērs:0.0.1.

Atmiņas ierobežojumi ā€” konteinera atmiņas ierobežojumi. Cietais ierobežojums ā€” cietais limits, ja konteiners pārsniedz norādÄ«to vērtÄ«bu, tiks izpildÄ«ta docker kill komanda, konteiners nekavējoties mirs. MÄ«kstais ierobežojums ā€” mÄ«kstā robeža, konteiners var pārsniegt norādÄ«to vērtÄ«bu, taču Å”is parametrs tiks ņemts vērā, novietojot uzdevumus maŔīnām. Piemēram, ja iekārtai ir 4 GiB RAM un konteinera mÄ«kstais ierobežojums ir 2048 MiB, tad Å”ai iekārtai ar Å”o konteineru var darboties ne vairāk kā 2 darbi. PatiesÄ«bā 4 GiB RAM ir nedaudz mazāks par 4096 MiB, to var apskatÄ«t klastera cilnē ECS Instances. MÄ«kstais ierobežojums nevar bÅ«t lielāks par stingro ierobežojumu. Ir svarÄ«gi saprast, ka, ja vienā uzdevumā ir vairāki konteineri, tad to robežas tiek summētas.

Portu kartējumi - plkst Uzņēmēja ports Mēs norādām 0, tas nozÄ«mē, ka ports tiks pieŔķirts dinamiski un to uzraudzÄ«s mērÄ·a grupa. Konteineru osta ā€” ports, kurā darbojas jÅ«su lietojumprogramma, bieži tiek norādÄ«ts izpildes komandā vai pieŔķirts jÅ«su lietojumprogrammas kodā, Dockerfile utt. MÅ«su piemērā mēs izmantosim 3000, jo tas ir norādÄ«ts Dockerfile izmantotais attēls.

VeselÄ«bas pārbaude ā€” konteinera veselÄ«bas pārbaudes parametri, kurus nedrÄ«kst sajaukt ar mērÄ·a grupā konfigurētajiem parametriem.

vide - vides iestatÄ«jumi. CPU vienÄ«bas - lÄ«dzÄ«gi kā Atmiņas ierobežojumi, tikai par procesoru. Katrs procesora kodols ir 1024 vienÄ«bas, tādēļ, ja serverim ir divkodolu procesors un konteiners ir iestatÄ«ts uz 512, tad vienā serverÄ« var palaist 4 uzdevumus ar Å”o konteineru. CPU vienÄ«bas vienmēr atbilst kodolu skaitam, to nevar bÅ«t nedaudz mazāk, kā tas ir ar atmiņu.

Komanda ā€” komanda pakalpojuma palaiÅ”anai konteinerā, visi parametri ir norādÄ«ti atdalot ar komatiem. Tas varētu bÅ«t lielradzis, npm utt. Ja tas nav norādÄ«ts, tiks izmantota CMD direktÄ«vas vērtÄ«ba no Dockerfile. Mēs norādām npm,start.

Vides mainÄ«gie ā€” konteinera vides mainÄ«gie. Tie var bÅ«t vienkārÅ”i teksta dati vai slepeni mainÄ«gie no Noslēpumu pārvaldnieks vai Parametru veikals.

UzglabāŔana un mežizstrāde - Å”eit mēs iestatÄ«sim reÄ£istrÄ“Å”anos pakalpojumā CloudWatch žurnāli (pakalpojums žurnāliem no AWS). Lai to izdarÄ«tu, vienkārÅ”i iespējojiet izvēles rÅ«tiņu Automātiski konfigurēt CloudWatch žurnālus. Pēc uzdevuma definÄ«cijas izveides pakalpojumā CloudWatch automātiski tiks izveidota žurnālu grupa. Pēc noklusējuma žurnāli tajā tiek glabāti neierobežotu laiku; iesaku mainÄ«t saglabāŔanas periodu no Nekad nebeidzas uz nepiecieÅ”amo periodu. Tas tiek darÄ«ts CloudWatch žurnāla grupās, jums jānoklikŔķina uz paÅ”reizējā perioda un jāizvēlas jauns.

Mērogojama API izveide uz AWS vietas gadījumiem

ECS klasteris un ECS jaudas nodroŔinātājs

Lai izveidotu klasteri, dodieties uz sadaļu ECS ā†’ Klasteri. Mēs izvēlamies EC2 Linux + Networking kā veidni.

Klastera nosaukums - ļoti svarÄ«gi, mēs Å”eit izveidojam tādu paÅ”u nosaukumu, kāds norādÄ«ts parametrā Launch Template ECS_CLUSTER, mÅ«su gadÄ«jumā - DemoApiClusterProd. AtzÄ«mējiet izvēles rÅ«tiņu Izveidot tukÅ”u klasteru. Pēc izvēles varat iespējot Container Insights, lai pakalpojumā CloudWatch skatÄ«tu pakalpojumu metriku. Ja visu izdarÄ«jāt pareizi, sadaļā ECS Instances redzēsiet maŔīnas, kas tika izveidotas grupā Auto Scaling.

Mērogojama API izveide uz AWS vietas gadījumiem

Dodieties uz cilni Jaudas nodroÅ”inātāji un izveidojiet jaunu. Ä»aujiet man atgādināt, ka tas ir nepiecieÅ”ams, lai kontrolētu maŔīnu izveidi un izslēgÅ”anu atkarÄ«bā no darbojoÅ”os ECS uzdevumu skaita. Ir svarÄ«gi atzÄ«mēt, ka pakalpojumu sniedzēju var pieŔķirt tikai vienai grupai.

Automātiskās mērogoÅ”anas grupa ā€” izvēlieties iepriekÅ” izveidoto grupu.

PārvaldÄ«ta mērogoÅ”ana ā€” iespējojiet to, lai pakalpojumu sniedzējs varētu mērogot pakalpojumu.

MērÄ·a jauda % ā€” cik procentu mums vajag ar uzdevumiem piekrautu maŔīnu. Ja norādāt 100%, tad visas maŔīnas vienmēr bÅ«s aizņemtas ar darba uzdevumiem. Ja norādāt 50%, tad puse no maŔīnām vienmēr bÅ«s bez maksas. Šādā gadÄ«jumā, ja notiek straujÅ” slodzes lēciens, jauni taksometri nekavējoties tiks pie brÄ«vajām automaŔīnām, negaidot instanču izvietoÅ”anu.

PārvaldÄ«ta izbeigÅ”anas aizsardzÄ«ba ā€” iespējot, Å”is parametrs ļauj nodroÅ”inātājam noņemt gadÄ«jumu aizsardzÄ«bu pret dzÄ“Å”anu. Tas notiek, ja iekārtā nav aktÄ«vu uzdevumu un tiek atļauta mērÄ·a ietilpÄ«ba%.

ECS serviss un mērogoÅ”anas iestatÄ«Å”ana

Pēdējais solis :) Lai izveidotu servisu, cilnē Services jāiet uz iepriekÅ” izveidoto klasteru.

PalaiÅ”anas veids ā€” jānoklikŔķina uz Pārslēgties uz jaudas nodroÅ”inātāja stratēģiju un jāizvēlas iepriekÅ” izveidotie pakalpojumu sniedzēji.

Mērogojama API izveide uz AWS vietas gadījumiem

Uzdevuma definÄ«cija ā€” atlasiet iepriekÅ” izveidoto uzdevumu definÄ«ciju un tās pārskatÄ«Å”anu.

Pakalpojuma nosaukums ā€” lai izvairÄ«tos no neskaidrÄ«bām, mēs vienmēr norādām to paÅ”u, kas ir uzdevuma definÄ«cija.

Pakalpojuma veids - vienmēr Reprodukcija.

Uzdevumu skaits ā€” vēlamais aktÄ«vo uzdevumu skaits pakalpojumā. Å o parametru kontrolē mērogoÅ”ana, taču tas joprojām ir jānorāda.

Minimālais veselais procents Šø Maksimālais procents ā€” noteikt uzdevumu uzvedÄ«bu izvietoÅ”anas laikā. Noklusējuma vērtÄ«bas ir 100 un 200, kas norāda, ka izvietoÅ”anas laikā uzdevumu skaits palielināsies vairākas reizes un pēc tam atgriezÄ«sies pie vēlamās vērtÄ«bas. Ja jums darbojas 1 uzdevums, min = 0 un max = 100, tad izvietoÅ”anas laikā tas tiks nogalināts, un pēc tam tiks pacelts jauns, tas ir, tas bÅ«s dÄ«kstāve. Ja darbojas 1 uzdevums, min=50, max=150, tad izvietoÅ”ana nenotiks vispār, jo 1 uzdevumu nevar sadalÄ«t uz pusēm vai palielināt par pusotru reizi.

IzvietoÅ”anas veids ā€” atstājiet ritoÅ”o atjauninājumu.

Izvietojuma veidnes ā€” noteikumi par uzdevumu ievietoÅ”anu maŔīnām. Noklusējums ir AZ Balanced Spread ā€” tas nozÄ«mē, ka katrs jauns uzdevums tiks ievietots jaunā instancē, lÄ«dz paaugstinās maŔīnas visās pieejamÄ«bas zonās. Mēs parasti veicam BinPack ā€” CPU un Spread ā€” AZ; ar Å”o politiku uzdevumi tiek izvietoti pēc iespējas blÄ«vāk vienā datorā uz katru CPU. Ja ir nepiecieÅ”ams izveidot jaunu maŔīnu, tā tiek izveidota jaunā pieejamÄ«bas zonā.

Mērogojama API izveide uz AWS vietas gadījumiem

Slodzes balansētāja tips ā€” atlasiet Lietojumprogrammas slodzes lÄ«dzsvarotājs.

Pakalpojuma IAM loma - izvēlēties ecsServiceRole.

Slodzes balansētāja nosaukums ā€” izvēlieties iepriekÅ” izveidoto balansētāju.

VeselÄ«bas pārbaudes labvēlÄ«bas periods ā€” pauze pirms veselÄ«bas pārbaužu veikÅ”anas pēc jauna uzdevuma izvērÅ”anas, parasti mēs to iestatām uz 60 sekundēm.

Konteiners slodzes lÄ«dzsvaram ā€” punktā MērÄ·a grupas nosaukums atlasiet iepriekÅ” izveidoto grupu, un viss tiks aizpildÄ«ts automātiski.

Mērogojama API izveide uz AWS vietas gadījumiem

Pakalpojuma automātiskā mērogoÅ”ana ā€” pakalpojuma mērogoÅ”anas parametri. Atlasiet Konfigurēt pakalpojuma automātisko mērogoÅ”anu, lai pielāgotu pakalpojuma vēlamo skaitu. Mērogojot, mēs iestatām minimālo un maksimālo uzdevumu skaitu.

IAM loma pakalpojuma automātiskajai mērogoÅ”anai - izvēlēties AWSServiceRoleForApplicationAutoScaling_ECSService.

Automātiskās uzdevumu mērogoÅ”anas politikas ā€” mērogoÅ”anas noteikumi. Ir 2 veidi:

  1. MērÄ·a izsekoÅ”ana ā€” mērÄ·a metrikas izsekoÅ”ana (CPU/RAM lietojums vai pieprasÄ«jumu skaits katram uzdevumam). Piemēram, mēs vēlamies, lai procesora vidējā slodze bÅ«tu 85%, kad tā kļūst lielāka, tiks pievienoti jauni uzdevumi, lÄ«dz tā sasniegs mērÄ·a vērtÄ«bu. Ja slodze ir mazāka, uzdevumi tiks noņemti, gluži pretēji, ja vien nav iespējota aizsardzÄ«ba pret samazināŔanu (Atspējot mērogoÅ”anu).
  2. Pakāpju mērogoÅ”ana - reakcija uz patvaļīgu notikumu. Å eit varat konfigurēt reakciju uz jebkuru notikumu (CloudWatch Alarm), kad tā notiek, varat pievienot vai noņemt norādÄ«to uzdevumu skaitu vai norādÄ«t precÄ«zu uzdevumu skaitu.

Pakalpojumam var bÅ«t vairāki mērogoÅ”anas noteikumi, tas var bÅ«t noderÄ«gi, galvenais ir nodroÅ”ināt, lai tie nebÅ«tu pretrunā viens ar otru.

Secinājums

Ja ievērojāt norādÄ«jumus un izmantojāt to paÅ”u Docker attēlu, jÅ«su pakalpojumam vajadzētu atgriezt Ŕādu lapu.

Mērogojama API izveide uz AWS vietas gadījumiem

  1. Mēs esam izveidojuÅ”i veidni, saskaņā ar kuru tiek palaists visas pakalpojuma iekārtas. Mēs arÄ« uzzinājām, kā atjaunināt maŔīnas, kad mainās veidne.
  2. Esam konfigurējuÅ”i spot instances apstāŔanās signāla apstrādi, tāpēc minÅ«tes laikā pēc tā saņemÅ”anas no maŔīnas tiek noņemti visi darbojoÅ”ie uzdevumi, tādējādi nekas netiek zaudēts vai pārtraukts.
  3. Mēs pacēlām balansieri, lai vienmērÄ«gi sadalÄ«tu slodzi pa maŔīnām.
  4. Mēs esam izveidojuÅ”i pakalpojumu, kas darbojas uz vietas, kas samazina maŔīnas izmaksas aptuveni 3 reizes.
  5. Mēs esam konfigurējuÅ”i automātisko mērogoÅ”anu abos virzienos, lai tiktu galā ar palielinātu darba slodzi, neradot dÄ«kstāves izmaksas.
  6. Mēs izmantojam Capacity Provider, lai lietojumprogramma pārvaldÄ«tu infrastruktÅ«ru (maŔīnas), nevis otrādi.
  7. Mēs esam lieliski.

Ja jums ir paredzami slodzes pieaugumi, piemēram, jÅ«s reklamējat lielā e-pasta kampaņā, varat iestatÄ«t mērogoÅ”anu, izmantojot saraksts.

Varat arÄ« mērogot, pamatojoties uz datiem no dažādām sistēmas daļām. Piemēram, mums ir funkcionalitāte individuālu reklāmas piedāvājumu izsÅ«tÄ«Å”ana mobilās aplikācijas lietotāji. Dažreiz kampaņa tiek nosÅ«tÄ«ta vairāk nekā 1 miljonam cilvēku. Pēc Ŕādas izplatÄ«Å”anas vienmēr ievērojami palielinās pieprasÄ«jumu skaits API, jo daudzi lietotāji vienlaikus piesakās lietojumprogrammā. Tātad, ja mēs redzam, ka rindā uz reklāmas push paziņojumu nosÅ«tÄ«Å”anu ir ievērojami vairāk standarta rādÄ«tāju, mēs varam nekavējoties palaist vairākas papildu iekārtas un uzdevumus, lai bÅ«tu gatavi slodzei.

PriecāŔos, ja komentāros pastāstÄ«sit interesantus spot instanču un ECS izmantoÅ”anas gadÄ«jumus vai kaut ko par mērogoÅ”anu.

DrÄ«zumā bÅ«s raksti par to, kā mēs apstrādājam tÅ«kstoÅ”iem analÄ«tisko notikumu sekundē pārsvarā bez serveru stekā (ar naudu) un kā notiek pakalpojumu izvietoÅ”ana, izmantojot GitLab CI un Terraform Cloud.

Abonējiet mūs, tas būs interesanti!

Aptaujā var piedalīties tikai reģistrēti lietotāji. Ielogoties, lūdzu.

Vai ražoŔanā izmantojat vietas gadījumus?

  • 22,2%Jā 6

  • 66,7%Nr.18

  • 11,1%Es uzzināju par tiem no raksta un plānoju tos izmantot3

Nobalsoja 27 lietotāji. 5 lietotāji atturējās.

Avots: www.habr.com

Pievieno komentāru