Izrada skalabilnog API-ja na AWS Spot instancama

Bok svima! Moje ime je Kirill, ja sam CTO u Adaptyju. Većina naše arhitekture je na AWS-u, a danas ću govoriti o tome kako smo smanjili troškove poslužitelja za 3 puta korištenjem spot instanci u produkcijskom okruženju, kao i kako postaviti njihovo automatsko skaliranje. Prvo će biti pregled kako radi, a zatim detaljne upute za početak.

Što su spot instance?

Mjesto instance su serveri drugih AWS korisnika koji trenutno miruju, a prodaju ih s velikim popustom (Amazon piše do 90%, po našem iskustvu ~3x, varira ovisno o regiji, AZ i vrsti instance). Njihova glavna razlika od običnih je da se mogu isključiti u bilo kojem trenutku. Stoga smo dugo vremena vjerovali da je normalno koristiti ih za virgin okruženja, ili za zadatke izračunavanja nečega, s međurezultatima pohranjenima na S3 ili u bazi podataka, ali ne i za prodaju. Postoje rješenja trećih strana koja vam omogućuju korištenje spotova u proizvodnji, ali postoji mnogo štaka za naš slučaj, pa ih nismo implementirali. Pristup opisan u članku radi u potpunosti unutar standardne AWS funkcionalnosti, bez dodatnih skripti, krunica i sl.

Ispod je nekoliko snimaka zaslona koji prikazuju povijest cijena za spot instance.

m5.veliki u regiji eu-west-1 (Irska). Cijena je uglavnom stabilna 3 mjeseca, trenutno ušteda 2.9x.

m5.veliki u regiji us-east-1 (N. Virginia). Cijena se konstantno mijenja tijekom 3 mjeseca, trenutno ušteda od 2.3x do 2.8x ovisno o zoni dostupnosti.

t3.malo u regiji us-east-1 (N. Virginia). Cijena je stabilna 3 mjeseca, trenutno ušteda 3.4x.

Servisna arhitektura

Osnovna arhitektura usluge o kojoj ćemo govoriti u ovom članku prikazana je na donjem dijagramu.

Balansiranje opterećenja aplikacije → Ciljna skupina EC2 → Usluga elastičnog spremnika

Kao balanser koristi se Application Load Balancer (ALB) koji šalje zahtjeve EC2 Target Group (TG). TG je odgovoran za otvaranje portova na instancama za ALB-ove i njihovo povezivanje s portovima spremnika Elastic Container Service (ECS). ECS je analog Kubernetesa u AWS-u, koji upravlja Docker spremnicima.

Jedna instanca može imati nekoliko aktivnih spremnika s istim portovima, tako da ih ne možemo postaviti fiksno. ECS govori TG-u da pokreće novi zadatak (u terminologiji Kubernetesa to se naziva pod), provjerava ima li slobodnih portova na instanci i jedan od njih dodjeljuje pokrenutom zadatku. TG također redovito provjerava rade li instanca i API na njoj koristeći provjeru zdravlja, a ako uoči bilo kakve probleme, prestaje slati zahtjeve tamo.

EC2 grupe za automatsko skaliranje + pružatelji ECS kapaciteta

Gornji dijagram ne prikazuje uslugu EC2 Auto Scaling Groups (ASG). Iz naziva možete shvatiti da je odgovoran za skaliranje instanci. Međutim, donedavno AWS nije imao ugrađenu mogućnost upravljanja brojem strojeva koji rade iz ECS-a. ECS je omogućio skaliranje broja zadataka, na primjer, korištenjem CPU-a, RAM-a ili brojem zahtjeva. Ali ako su zadaci zauzeli sve slobodne instance, novi strojevi nisu automatski stvoreni.

To se promijenilo dolaskom ECS pružatelja kapaciteta (ECS CP). Sada se svaka usluga u ECS-u može povezati s ASG-om, a ako zadaci ne stanu na pokrenute instance, pokrenut će se novi (ali unutar utvrđenih ASG ograničenja). Ovo također radi u suprotnom smjeru, ako ECS CP vidi neaktivne instance bez zadataka, tada će dati ASG naredbu da ih ugasi. ECS CP ima mogućnost odrediti ciljni postotak učitavanja instance, tako da je određeni broj strojeva uvijek slobodan za zadatke brzog skaliranja; o tome ću malo kasnije.

Predlošci za pokretanje EC2

Posljednja usluga o kojoj ću govoriti prije nego što uđem u detalje o stvaranju ove infrastrukture su EC2 Launch Templates. Omogućuje vam da stvorite predložak prema kojem će se svi strojevi pokrenuti, kako se to ne bi ponavljalo svaki put ispočetka. Ovdje možete odabrati vrstu stroja za pokretanje, sigurnosnu grupu, sliku diska i mnoge druge parametre. Također možete odrediti korisničke podatke koji će se učitati u sve pokrenute instance. Možete pokretati skripte u korisničkim podacima, na primjer, možete uređivati ​​sadržaj datoteke Konfiguracije ECS agenta.

Jedan od najvažnijih konfiguracijskih parametara za ovaj članak je ECS_ENABLE_SPOT_INSTANCE_DRAINING=istinito. Ako je ovaj parametar uključen, čim ECS primi signal da se spot instanca oduzima, prebacuje sve zadatke koji rade na njoj u status Draining. Ovoj instanci neće se dodijeliti novi zadaci; ako postoje zadaci koji se sada žele uvesti na nju, bit će otkazani. Zahtjevi od balansera također prestaju dolaziti. Obavijest o brisanju instance dolazi 2 minute prije stvarnog događaja. Stoga, ako vaša usluga ne obavlja zadatke dulje od 2 minute i ne sprema ništa na disk, tada možete koristiti spot instance bez gubitka podataka.

Što se tiče diska - AWS nedavno Imam Moguće je koristiti Elastic File System (EFS) zajedno s ECS-om, kod ove sheme čak ni disk nije prepreka, ali to nismo probali jer nam u principu ne treba disk za pohranjivanje stanja. Prema zadanim postavkama, nakon primanja SIGINT-a (šalje se kada se zadatak prebaci u status pražnjenja), svi pokrenuti zadaci bit će zaustavljeni nakon 30 sekundi, čak i ako još nisu dovršeni; ovo vrijeme možete promijeniti pomoću parametra ECS_CONTAINER_STOP_TIMEOUT. Glavna stvar je ne postaviti ga na više od 2 minute za spot strojeve.

Izrada usluge

Prijeđimo na izradu opisane usluge. U procesu ću dodatno opisati nekoliko korisnih točaka koje nisu gore navedene. Općenito, ovo je uputa korak po korak, ali neću razmatrati neke vrlo osnovne ili, naprotiv, vrlo specifične slučajeve. Sve se radnje izvode u AWS vizualnoj konzoli, ali se mogu reproducirati programski pomoću CloudFormation ili Terraform. U Adaptyju koristimo Terraform.

Predložak za pokretanje EC2

Ova usluga stvara konfiguraciju strojeva koji će se koristiti. Predlošcima se upravlja u odjeljku EC2 -> Instance -> Predlošci pokretanja.

Slika Amazon stroja (AMI) — odredite sliku diska s kojom će se pokrenuti sve instance. Za ECS se u većini slučajeva isplati koristiti optimiziranu sliku s Amazona. Redovito se ažurira i sadrži sve što je potrebno za rad ECS-a. Da biste saznali trenutni ID slike, idite na stranicu AMI-ji optimizirani za Amazon ECS, odaberite regiju koju koristite i kopirajte AMI ID za nju. Na primjer, za regiju us-east-1, trenutni ID u vrijeme pisanja je ami-00c7c1cf5bdc913ed. Ovaj ID mora biti umetnut u stavku Specify a custom value.

Vrsta instance — označavaju vrstu instance. Odaberite onaj koji najbolje odgovara vašem zadatku.

Par ključeva (prijava) — odredite certifikat s kojim se možete povezati s instancom putem SSH-a, ako je potrebno.

postavke mreže — odredite mrežne parametre. Mrežna platforma u većini slučajeva trebao bi postojati Virtual Private Cloud (VPC). Sigurnosne skupine — sigurnosne grupe za vaše instance. Budući da ćemo koristiti balanser ispred instanci, preporučujem da ovdje navedete grupu koja dopušta dolazne veze samo od balansera. To jest, imat ćete 2 sigurnosne grupe, jednu za balanser, koja dopušta ulazne veze s bilo kojeg mjesta na portovima 80 (http) i 443 (https), i drugu za strojeve, koja dopušta dolazne veze na bilo kojem portu iz balanser grupe . Izlazne veze u obje grupe moraju se otvoriti korištenjem TCP protokola na sve priključke na sve adrese. Možete ograničiti portove i adrese za odlazne veze, ali tada morate stalno pratiti da ne pokušavate pristupiti nečemu na zatvorenom portu.

Pohrana (volumeni) — odredite parametre diska za strojeve. Veličina diska ne može biti manja od one navedene u AMI-ju; za ECS Optimized to je 30 GiB.

Napredni detalji — navedite dodatne parametre.

Mogućnost kupnje — želimo li kupiti spot instance. Želimo, ali nećemo označiti ovaj okvir ovdje; konfigurirat ćemo ga u grupi za automatsko skaliranje, tamo ima više opcija.

Profil instance IAM-a — označite ulogu s kojom će se instance pokrenuti. Da bi se instance izvodile u ECS-u, potrebne su im dozvole koje se obično nalaze u ulozi ecsInstanceRole. U nekim slučajevima može se stvoriti, ako ne, onda ovdje nastava o tome kako to učiniti. Nakon izrade, označavamo ga u predlošku.
Zatim postoji mnogo parametara, u osnovi možete ostaviti zadane vrijednosti posvuda, ali svaki od njih ima jasan opis. Uvijek omogućujem instancu optimiziranu za EBS i opcije T2/T3 Unlimited ako se koriste rasprsnuti instance.

Korisničko vrijeme — navesti korisničke podatke. Uredit ćemo datoteku /etc/ecs/ecs.config, koji sadrži konfiguraciju ECS agenta.
Primjer kako bi korisnički podaci mogli izgledati:

#!/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 — parametar označava da instanca pripada klasteru s danim imenom, odnosno da će ovaj klaster moći postaviti svoje zadatke na ovaj poslužitelj. Još nismo izradili klaster, ali koristit ćemo ovo ime pri izradi.

ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametar navodi da kada se primi signal za isključivanje spot instance, svi zadaci na njoj trebaju biti prebačeni u status pražnjenja.

ECS_CONTAINER_STOP_TIMEOUT=1m - parametar specificira da nakon primanja signala SIGINT, svi zadaci imaju 1 minutu prije nego što budu ubijeni.

ECS_ENGINE_AUTH_TYPE=docker — parametar označava da se Docker shema koristi kao mehanizam autorizacije

ECS_ENGINE_AUTH_DATA=... — parametri povezivanja s privatnim registrom spremnika, gdje su pohranjene vaše Docker slike. Ako je javno, onda ne morate ništa specificirati.

Za potrebe ovog članka koristit ću javnu sliku iz Docker Huba, pa navedite parametre ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nema potrebe.

Dobro je znati: Preporuča se redovito ažurirati AMI jer nove verzije ažuriraju verzije Dockera, Linuxa, ECS agenta itd. Da ne zaboravite na ovo, možete postaviti obavijesti o izdavanju novih verzija. Obavijesti možete primati e-poštom i ažurirati ručno ili možete napisati Lambda funkciju koja će automatski stvoriti novu verziju predloška pokretanja s ažuriranim AMI-jem.

EC2 grupa za automatsko skaliranje

Grupa za automatsko skaliranje odgovorna je za pokretanje i skaliranje instanci. Grupama se upravlja u odjeljku EC2 -> Auto Scaling -> Auto Scaling Groups.

Predložak pokretanja — odaberite predložak izrađen u prethodnom koraku. Ostavljamo zadanu verziju.

Mogućnosti kupnje i vrste primjeraka — odredite tipove instanci za klaster. Pridržavanje predloška pokretanja koristi vrstu instance iz predloška pokretanja. Kombiniranje opcija kupnje i vrsta instanci omogućuje vam fleksibilnu konfiguraciju vrsta instanci. Iskoristit ćemo ga.

Opcijska baza na zahtjev — broj redovnih instanci bez mjesta koje će uvijek raditi.

Postotak na zahtjev iznad baze — postotni omjer redovnih i spot instanci, 50-50 će se ravnomjerno raspodijeliti, 20-80 za svaku redovnu instancu 4 spot instance će se podići. Za potrebe ovog primjera navest ću 50-50, ali u stvarnosti najčešće radimo 20-80, u nekim slučajevima 0-100.

Vrste instance — ovdje možete navesti dodatne vrste instanci koje će se koristiti u klasteru. Nikada ga nismo koristili jer stvarno ne razumijem smisao priče. Možda je to zbog ograničenja određenih vrsta instanci, ali ona se mogu lako povećati kroz podršku. Ako znate aplikaciju, bit će mi drago pročitati je u komentarima)

mreža — mrežne postavke, odaberite VPC i podmreže za strojeve, u većini slučajeva trebali biste odabrati sve dostupne podmreže.

Balansiranje opterećenja - postavke balansera, ali to ćemo učiniti zasebno, ovdje nećemo ništa dirati. Zdravstveni pregledi također će se kasnije konfigurirati.

Veličina grupe — na početku označavamo ograničenja broja strojeva u klasteru i željeni broj strojeva. Broj strojeva u klasteru nikada neće biti manji od navedenog minimuma i veći od maksimuma, čak i ako bi trebalo doći do skaliranja prema metrici.

Politike skaliranja — parametri skaliranja, ali mi ćemo skalirati na temelju ECS zadataka koji se izvode, pa ćemo skaliranje konfigurirati kasnije.

Zaštita od povećanja instance — zaštita instanci od brisanja prilikom smanjivanja. Omogućujemo ga tako da ASG ne briše stroj koji ima pokrenute zadatke. ECS Capacity Provider će onemogućiti zaštitu za instance koje nemaju zadatke.

Dodaj oznake — možete navesti oznake za instance (za ovo mora biti označen okvir Označi nove instance). Preporučam da navedete oznaku naziva, tada će sve instance koje se pokreću unutar grupe imati isto ime i prikladno ih je pregledati u konzoli.

Nakon što kreirate grupu, otvorite je i idite na odjeljak Napredne konfiguracije Zašto sve opcije nisu vidljive u konzoli u fazi kreiranja.

Pravila o raskidu — pravila koja se uzimaju u obzir prilikom brisanja instanci. Primjenjuju se redom. Obično koristimo one na slici ispod. Prvo se brišu instance s najstarijim predloškom za pokretanje (na primjer, ako smo ažurirali AMI, stvorili smo novu verziju, ali su se sve instance uspjele prebaciti na nju). Zatim se odabiru instance koje su najbliže sljedećem obračunskom satu. Zatim se najstariji odabiru na temelju datuma pokretanja.

Dobro je znati: za ažuriranje svih strojeva u klasteru, pogodno za korištenje Osvježi instancu. Ako ovo kombinirate s Lambda funkcijom iz prethodnog koraka, imat ćete potpuno automatiziran sustav ažuriranja instance. Prije ažuriranja svih strojeva, morate onemogućiti zaštitu od povećanja instance za sve instance u grupi. Ne konfiguracija u grupi, već zaštita od samih strojeva, to se radi na kartici Instance management.

Balansiranje opterećenja aplikacije i EC2 ciljna skupina

Balanser se kreira u odjeljku EC2 → Load Balancing → Load Balancers. Koristit ćemo Application Load Balancer; usporedbu različitih tipova balansera možete pročitati na servisnu stranicu.

slušatelji - ima smisla napraviti portove 80 i 443 i kasnije preusmjeriti s 80 na 443 pomoću pravila balansera.

Zone dostupnosti — u većini slučajeva odabiremo zone pristupačnosti za sve.

Konfigurirajte sigurnosne postavke — ovdje je naznačen SSL certifikat za balanser, najprikladnija opcija je napraviti potvrdu u ACM-u. O razlikama Sigurnosna politika može se pročitati u dokumentacija, možete ga ostaviti odabranim prema zadanim postavkama ELBSecurityPolicy-2016-08. Nakon što izradite balanser, vidjet ćete ga DNS ime, koji vam je potreban da biste konfigurirali CNAME za svoju domenu. Na primjer, ovako to izgleda u Cloudflareu.

Sigurnosna grupa — stvorite ili odaberite sigurnosnu grupu za balanser, o tome sam napisao više u odjeljku EC2 Launch Template → Network settings.

Ciljna skupina — stvaramo grupu koja je odgovorna za usmjeravanje zahtjeva od balansera do strojeva i provjeru njihove dostupnosti kako bismo ih zamijenili u slučaju problema. Ciljna vrsta mora biti instanca, Protokol и luka bilo koji, ako koristite HTTPS za komunikaciju između balansera i instanci, tada morate učitati certifikat na njih. Za potrebe ovog primjera, nećemo to učiniti, jednostavno ćemo napustiti priključak 80.

Zdravstveni pregledi — parametri za provjeru funkcionalnosti usluge. U pravoj usluzi ovo bi trebao biti zaseban zahtjev koji implementira važne dijelove poslovne logike; za potrebe ovog primjera ostavit ću zadane postavke. Zatim možete odabrati interval zahtjeva, vremensko ograničenje, kodove uspjeha itd. U našem primjeru naznačit ćemo kodove uspjeha 200-399 jer Docker slika koja će se koristiti vraća kod 304.

Registrirajte ciljeve — ovdje se odabiru automobili za grupu, ali u našem slučaju to će učiniti ECS, tako da jednostavno preskačemo ovaj korak.

Dobro je znati: na razini balansera možete omogućiti zapise koji će biti spremljeni u S3 u određenom format. Odatle se mogu izvesti u usluge trećih strana za analitiku ili možete postavljati SQL upite izravno na podatke u S3 s pomoću Atene. Praktičan je i radi bez dodatnog koda. Također preporučujem postavljanje uklanjanja trupaca iz S3 spremnika nakon određenog vremenskog razdoblja.

Definicija ECS zadatka

U prethodnim koracima izradili smo sve vezano uz servisnu infrastrukturu, a sada prelazimo na opisivanje spremnika koje ćemo pokrenuti. To se radi u odjeljku ECS → Definicije zadataka.

Kompatibilnost tipa lansiranja - odaberite EC2.

IAM uloga izvršenja zadatka - izabrati ecsTaskExecutionRole. Pomoću njega se pišu dnevnici, daje se pristup tajnim varijablama itd.

U odjeljku Definicije spremnika kliknite Dodaj spremnik.

Slika — poveznica na sliku s kodom projekta; za ovaj primjer koristit ću javnu sliku iz Docker Huba bitnami/čvor-primjer:0.0.1.

Ograničenja memorije — ograničenja memorije za spremnik. Teško ograničenje — tvrdo ograničenje, ako spremnik prijeđe zadanu vrijednost, izvršit će se naredba docker kill, spremnik će odmah umrijeti. Meka granica — meko ograničenje, spremnik može prijeći zadanu vrijednost, ali ovaj će se parametar uzeti u obzir prilikom postavljanja zadataka na strojeve. Na primjer, ako stroj ima 4 GiB RAM-a, a meko ograničenje spremnika je 2048 MiB, tada ovo računalo može imati najviše 2 pokrenuta zadatka s ovim spremnikom. U stvarnosti, 4 GiB RAM-a je nešto manje od 4096 MiB, to se može vidjeti na kartici ECS Instance u klasteru. Meko ograničenje ne može biti veće od tvrdog ograničenja. Važno je razumjeti da ako postoji nekoliko spremnika u jednom zadatku, tada se njihova ograničenja zbrajaju.

Mapiranje luka - u Priključak domaćina Označavamo 0, to znači da će se port dodijeliti dinamički i nadzirat će ga ciljna skupina. Kontejnerska luka — priključak na kojem se pokreće vaša aplikacija često je naveden u naredbi za izvršavanje ili dodijeljen u kodu vaše aplikacije, Docker datoteci itd. Za naš primjer koristit ćemo 3000 jer je naveden u dockerfile slika koja se koristi.

Provjera zdravlja — parametri provjere ispravnosti spremnika, ne smiju se brkati s onim konfiguriranim u ciljnoj skupini.

okolina - postavke okruženja. CPU jedinice - slično ograničenjima memorije, samo o procesoru. Svaka jezgra procesora ima 1024 jedinice, tako da ako poslužitelj ima dvojezgreni procesor i spremnik je postavljen na 512, tada se na jednom poslužitelju mogu pokrenuti 4 zadatka s ovim spremnikom. CPU jedinice uvijek odgovaraju broju jezgri, ne može ih biti malo manje, kao što je slučaj s memorijom.

naredba — naredba za pokretanje usluge unutar spremnika, svi parametri navedeni su odvojeni zarezima. To može biti gunicorn, npm itd. Ako nije navedeno, koristit će se vrijednost CMD direktive iz Dockerfilea. Naznačujemo npm,start.

Varijable okoline — varijable okoline spremnika. To mogu biti jednostavni tekstualni podaci ili tajne varijable iz Upravitelj tajni ili Spremanje parametara.

Pohranjivanje i bilježenje — ovdje ćemo postaviti zapisivanje u CloudWatch Logs (usluga za zapise iz AWS-a). Da biste to učinili, samo uključite potvrdni okvir Auto-configure CloudWatch Logs. Nakon izrade Definicije zadatka, grupa zapisa automatski će se stvoriti u CloudWatchu. Prema zadanim postavkama, zapisnici se u njemu pohranjuju na neodređeno vrijeme; preporučujem promjenu razdoblja zadržavanja s Nikada ne isteći na potrebno razdoblje. To se radi u grupama CloudWatch Log, potrebno je kliknuti na trenutno razdoblje i odabrati novo.

ECS klaster i pružatelj ECS kapaciteta

Idite na odjeljak ECS → Klasteri za stvaranje klastera. Kao predložak odabiremo EC2 Linux + Networking.

Ime klastera - vrlo važno, ovdje stvaramo isto ime kao što je navedeno u parametru Predloška pokretanja ECS_CLUSTER, u našem slučaju - DemoApiClusterProd. Označite potvrdni okvir Stvori prazan klaster. Po izboru, možete omogućiti Container Insights za pregled metrike za usluge u CloudWatchu. Ako ste sve učinili ispravno, tada ćete u odjeljku ECS Instance vidjeti strojeve koji su stvoreni u grupi Auto Scaling.

Idi na karticu Pružatelji kapaciteta i stvoriti novi. Dopustite mi da vas podsjetim da je potrebno kontrolirati stvaranje i isključivanje strojeva ovisno o broju pokrenutih ECS zadataka. Važno je napomenuti da se pružatelj može dodijeliti samo jednoj grupi.

Grupa za automatsko skaliranje — odaberite prethodno stvorenu grupu.

Upravljano skaliranje — omogućite ga kako bi pružatelj mogao skalirati uslugu.

Ciljani kapacitet % — koliki postotak strojeva napunjenih zadacima trebamo. Ako navedete 100%, tada će svi strojevi uvijek biti zauzeti izvršavanjem zadataka. Ako navedete 50%, tada će pola automobila uvijek biti besplatno. U ovom slučaju, ako dođe do oštrog skoka u opterećenju, novi taksiji će odmah doći do slobodnih automobila, bez čekanja da se instance rasporede.

Upravljana zaštita od prekida — omogući, ovaj parametar omogućuje pružatelju da ukloni zaštitu instanci od brisanja. To se događa kada na stroju nema aktivnih zadataka i dopušta ciljni kapacitet%.

ECS usluga i podešavanje skaliranja

Zadnji korak :) Za kreiranje usluge potrebno je otići na prethodno kreirani klaster na kartici Usluge.

Vrsta lansiranja — potrebno je kliknuti na strategiju Prijeđi na pružatelja kapaciteta i odabrati prethodno kreirane pružatelje.

Definicija zadatka — odaberite prethodno kreiranu Definiciju zadatka i njezinu reviziju.

Naziv usluge — da bismo izbjegli zabunu, uvijek označavamo isto što i Definicija zadatka.

Vrsta usluge - uvijek Replika.

Broj zadataka — željeni broj aktivnih zadataka u usluzi. Ovaj se parametar kontrolira skaliranjem, ali se ipak mora navesti.

Minimalni zdravi postotak и Maksimalni postotak — odrediti ponašanje zadataka tijekom postavljanja. Zadane vrijednosti su 100 i 200, što znači da će se u trenutku implementacije broj zadataka povećati nekoliko puta, a zatim se vratiti na željenu vrijednost. Ako imate 1 zadatak koji je pokrenut, min=0 i max=100, tada će tijekom implementacije biti ubijen, a nakon toga će se pokrenuti novi, odnosno bit će zastoj. Ako se izvodi 1 zadatak, min=50, max=150, tada se implementacija uopće neće dogoditi jer se 1 zadatak ne može podijeliti na pola niti povećati jedan i pol puta.

Vrsta raspoređivanja — napustite Tekuće ažuriranje.

Predlošci za postavljanje — pravila za postavljanje zadataka na strojeve. Zadana postavka je AZ Balanced Spread - to znači da će svaki novi zadatak biti postavljen na novu instancu dok se strojevi u svim zonama dostupnosti ne podignu. Obično radimo BinPack - CPU i Spread - AZ; uz ovu politiku, zadaci su postavljeni što je moguće gušće na jednom stroju po CPU-u. Ako je potrebno kreirati novi stroj, on se stvara u novoj zoni dostupnosti.

Vrsta balansera opterećenja — odaberite Application Load Balancer.

Usluga IAM uloga - biraj ecsServiceRole.

Naziv balansera opterećenja — odaberite prethodno stvoreni balanser.

Odgoda za provjeru zdravlja — pauza prije obavljanja zdravstvenih provjera nakon pokretanja novog zadatka, obično je postavljamo na 60 sekundi.

Kontejner za ravnotežu opterećenja — u stavci Naziv ciljne grupe odaberite prethodno kreiranu grupu i sve će se automatski popuniti.

Usluga automatskog skaliranja — parametri skaliranja usluge. Odaberite Konfiguriraj automatsko skaliranje usluge da prilagodite željeni broj svoje usluge. Prilikom skaliranja postavljamo minimalni i maksimalni broj zadataka.

IAM uloga za automatsko skaliranje usluge - biraj AWSServiceRoleForApplicationAutoScaling_ECSService.

Pravila automatskog skaliranja zadataka — pravila za skaliranje. Postoje 2 vrste:

1. Praćenje cilja — praćenje ciljanih metrika (upotreba procesora/RAM-a ili broj zahtjeva za svaki zadatak). Na primjer, želimo da prosječno opterećenje procesora bude 85%, kada ono postane veće, dodavat će se novi zadaci dok ne dosegne ciljanu vrijednost. Ako je opterećenje manje, zadaci će biti uklonjeni, naprotiv, osim ako je omogućena zaštita od smanjivanja (Onemogući skaliranje).
2. Skaliranje koraka - reakcija na proizvoljni događaj. Ovdje možete konfigurirati reakciju na bilo koji događaj (CloudWatch Alarm), kada se dogodi, možete dodati ili ukloniti određeni broj zadataka ili odrediti točan broj zadataka.

Usluga može imati nekoliko pravila skaliranja, to može biti korisno, glavna stvar je osigurati da nisu u sukobu jedni s drugima.

Zaključak

Ako ste slijedili upute i koristili istu Docker sliku, vaša bi usluga trebala vratiti stranicu poput ove.

1. Napravili smo predložak prema kojem se pokreću svi strojevi u servisu. Također smo naučili kako ažurirati strojeve kada se predložak promijeni.
2. Konfigurirali smo obradu signala za zaustavljanje instance, tako da se u roku od jedne minute nakon primitka svi zadaci koji se izvode uklanjaju sa stroja, tako da se ništa ne gubi ili prekida.
3. Podigli smo balanser kako bismo ravnomjerno rasporedili teret na strojeve.
4. Stvorili smo uslugu koja radi na licu mjesta, što smanjuje troškove stroja za oko 3 puta.
5. Konfigurirali smo automatsko skaliranje u oba smjera kako bismo podnijeli povećana radna opterećenja bez snošenja troškova zastoja.
6. Koristimo Capacity Provider kako bi aplikacija upravljala infrastrukturom (strojevima), a ne obrnuto.
7. super smo.

Ako imate predvidljive skokove opterećenja, na primjer, oglašavate u velikoj kampanji putem e-pošte, možete postaviti skaliranje raspored.

Također možete skalirati na temelju podataka iz različitih dijelova vašeg sustava. Na primjer, imamo funkcionalnost slanje pojedinačnih promotivnih ponuda korisnika mobilne aplikacije. Ponekad se kampanja šalje 1M+ ljudima. Nakon takve distribucije uvijek dolazi do velikog porasta zahtjeva prema API-ju, budući da se mnogo korisnika istovremeno prijavljuje u aplikaciju. Dakle, ako vidimo da postoji znatno više standardnih indikatora u redu čekanja za slanje promotivnih push obavijesti, možemo odmah pokrenuti nekoliko dodatnih strojeva i zadataka kako bismo bili spremni za opterećenje.

Bit će mi drago ako mi u komentarima kažete zanimljive slučajeve korištenja spot instanci i ECS-a ili nešto o skaliranju.

Uskoro će biti članaka o tome kako obrađujemo tisuće analitičkih događaja u sekundi na dominantno bezposlužiteljskom stogu (s novcem) i kako funkcionira implementacija usluga koristeći GitLab CI i Terraform Cloud.

Pretplatite se na nas, bit će zanimljivo!

U anketi mogu sudjelovati samo registrirani korisnici. Prijaviti se, molim.

Koristite li spot instance u proizvodnji?

• 22,2%Da6

• 66,7%br.18

• 11,1%Saznao sam za njih iz članka i planiram ih koristiti3

Glasovalo je 27 korisnika. Suzdržano je bilo 5 korisnika.

Izvor: www.habr.com