Zdravo svima! Moje ime je Kirill, ja sam CTO u Adapty. Većina naše arhitekture je na AWS-u, a danas ću govoriti o tome kako smo smanjili troškove servera za 3 puta korištenjem spot instanci u proizvodnom okruženju, kao i kako podesiti njihovo automatsko skaliranje. Prvo će biti pregled kako to funkcionira, a zatim detaljna uputstva za početak.
Šta su Spot Instance?
instance su serveri drugih AWS korisnika koji su trenutno neaktivni i prodaju ih uz veliki popust (Amazon piše do 90%, prema našem iskustvu ~3x, varira ovisno o regiji, AZ-u i tipu instance). Njihova glavna razlika od običnih je u tome što se mogu isključiti u bilo kojem trenutku. Stoga smo dugo vremena vjerovali da je normalno koristiti ih za djevičanska okruženja, ili za zadatke izračunavanja nečega, sa međurezultatima koji se čuvaju na S3 ili u bazi podataka, ali ne i za prodaju. Postoje rješenja treće strane koja vam omogućavaju korištenje spotova u proizvodnji, ali postoji mnogo štaka za naš slučaj, pa ih nismo implementirali. Pristup opisan u članku radi u potpunosti u okviru standardne AWS funkcionalnosti, bez dodatnih skripti, krunica itd.
Ispod je nekoliko snimaka ekrana koji pokazuju istoriju cena 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-istok-1 (N. Virginia). Cijena se konstantno mijenja tokom 3 mjeseca, trenutno se štedi od 2.3x do 2.8x u zavisnosti od zone dostupnosti.
t3.mali u regionu us-istok-1 (N. Virginia). Cijena je stabilna 3 mjeseca, trenutno ušteda 3.4x.
Arhitektura servisa
Osnovna arhitektura servisa o kojoj ćemo govoriti u ovom članku prikazana je na dijagramu ispod.
Aplikacija za balansiranje opterećenja → EC2 ciljna grupa → usluga elastičnog kontejnera
Balanser opterećenja aplikacije (ALB) se koristi kao balansir, koji šalje zahtjeve EC2 ciljnoj grupi (TG). TG je odgovoran za otvaranje portova na instancama za ALB i njihovo povezivanje sa portovima kontejnera Elastic Container Service (ECS). ECS je analog Kubernetesa u AWS-u, koji upravlja Docker kontejnerima.
Jedna instanca može imati nekoliko pokrenutih kontejnera sa istim portovima, tako da ih ne možemo postaviti fiksno. ECS govori TG-u da pokreće novi zadatak (u Kubernetes terminologiji to se zove pod), provjerava slobodne portove na instanci i dodjeljuje jedan od njih pokrenutom zadatku. TG također redovno provjerava da li instanca i API rade na njoj koristeći provjeru zdravlja, i ako uoči bilo kakve probleme, prestaje da šalje zahtjeve tamo.
EC2 Auto Scaling Groups + ECS Capacity Providers
Gornji dijagram ne prikazuje uslugu EC2 Auto Scaling Groups (ASG). Iz imena možete razumjeti da je odgovoran za skaliranje instanci. Međutim, do nedavno, AWS nije imao ugrađenu mogućnost upravljanja brojem pokrenutih mašina iz ECS-a. ECS je omogućio skaliranje broja zadataka, na primjer, prema korištenju CPU-a, RAM-a ili broja zahtjeva. Ali ako su zadaci zauzeli sve slobodne instance, tada nove mašine nisu automatski kreirane.
Ovo se promijenilo pojavom ECS dobavljača kapaciteta (ECS CP). Sada svaka usluga u ECS-u može biti povezana sa ASG-om, i ako se zadaci ne uklapaju u pokrenute instance, tada će se pokrenuti novi (ali unutar utvrđenih ASG ograničenja). Ovo takođe radi u suprotnom smeru, ako ECS CP vidi neaktivne instance bez zadataka, tada će dati ASG komandu da ih isključi. ECS CP ima mogućnost specificiranja ciljanog postotka opterećenja instance, tako da je određeni broj mašina uvijek slobodan za brzo skaliranje zadataka; o tome ću malo kasnije.
EC2 predlošci za pokretanje
Posljednja usluga o kojoj ću govoriti prije nego što uđem u detalje o kreiranju ove infrastrukture su EC2 Launch Templates. Omogućava vam da kreirate šablon prema kojem će se sve mašine pokrenuti, kako se to ne bi ponavljalo svaki put od nule. Ovdje možete odabrati tip stroja za pokretanje, sigurnosnu grupu, sliku diska i mnoge druge parametre. Također možete odrediti korisničke podatke koji će biti učitani na sve pokrenute instance. Možete pokrenuti skripte u korisničkim podacima, na primjer, možete uređivati sadržaj datoteke .
Jedan od najvažnijih parametara konfiguracije za ovaj članak je =tačno. Ako je ovaj parametar uključen, onda čim ECS primi signal da se spot instanca oduzima, sve zadatke koji rade na njoj prenosi u status Draining. Ovoj instanci neće biti dodijeljeni novi zadaci; ako postoje zadaci koji se žele uvesti u nju upravo sada, oni će biti otkazani. Zahtjevi od balansera također prestaju da stižu. Obavijest o brisanju instance dolazi 2 minute prije stvarnog događaja. Stoga, ako vaš servis ne izvršava zadatke duže 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 Moguće je koristiti Elastic File System (EFS) zajedno sa ECS-om, kod ove šeme ni disk nije prepreka, ali ovo nismo pokušali, jer nam u principu ne treba disk za pohranjivanje stanja. Prema zadanim postavkama, nakon prijema SIGINT (poslanog kada je zadatak prebačen u status Draining), svi pokrenuti zadaci će biti zaustavljeni nakon 30 sekundi, čak i ako još nisu završeni; ovo vrijeme možete promijeniti pomoću parametra . Glavna stvar je da ga ne postavite na više od 2 minute za spot mašine.
Kreiranje usluge
Pređimo na kreiranje opisane usluge. U procesu ću dodatno opisati nekoliko korisnih tačaka koje nisu gore navedene. Općenito, ovo je instrukcija korak po korak, ali neću razmatrati neke vrlo osnovne ili, naprotiv, vrlo specifične slučajeve. Sve radnje se izvode u AWS vizuelnoj konzoli, ali se mogu programski reprodukovati pomoću CloudFormation ili Terraform. U Adaptyju koristimo Terraform.
EC2 predložak za pokretanje
Ova usluga kreira konfiguraciju mašina koje će se koristiti. Predlošcima se upravlja u odjeljku EC2 -> Instance -> Predlošci pokretanja.
slika Amazon mašine (AMI) — navedite sliku diska s kojom će se pokrenuti sve instance. Za ECS, u većini slučajeva vrijedi koristiti optimiziranu sliku od Amazona. Redovno se ažurira i sadrži sve što je potrebno za rad ECS-a. Da biste saznali trenutni ID slike, idite na stranicu , 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 Specificiranje prilagođene vrijednosti.
Tip instance — označite tip instance. Odaberite onaj koji najbolje odgovara vašem zadatku.
Par ključeva (prijava) — navedite certifikat s kojim se možete povezati s instancom putem SSH-a, ako je potrebno.
Postavke mreže — navedite parametre mreže. Mrežna platforma u većini slučajeva trebalo bi da postoji virtuelni privatni oblak (VPC). Sigurnosne grupe — sigurnosne grupe za vaše instance. Budući da ćemo koristiti balanser ispred instanci, preporučujem da ovdje navedete grupu koja dozvoljava dolazne veze samo iz balansera. To jest, imat ćete 2 sigurnosne grupe, jednu za balanser, koja omogućava dolazne veze s bilo kojeg mjesta na portovima 80 (http) i 443 (https), a drugu za mašine, koja dozvoljava dolazne veze na bilo kojim portovima iz balansirne grupe . Odlazne veze u obje grupe moraju se otvoriti korištenjem TCP protokola za sve portove 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 (volume) — navedite parametre diska za mašine. Veličina diska ne može biti manja od one navedene u AMI-ju; za ECS Optimized je 30 GiB.
Napredni detalji — navedite dodatne parametre.
Mogućnost kupovine — da li želimo da kupujemo 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 IAM instance — naznačite ulogu s kojom će se instance pokrenuti. Da bi se instance pokrenule u ECS-u, potrebne su im dozvole, koje se obično nalaze u ulozi ecsInstanceRole. U nekim slučajevima može se kreirati, ako ne, onda ovdje o tome kako to uraditi. Nakon kreiranja, to označavamo u predlošku.
Dalje postoji mnogo parametara, u osnovi možete ostaviti zadane vrijednosti posvuda, ali svaki od njih ima jasan opis. Uvijek omogućavam instancu optimiziranu za EBS i T2/T3 Unlimited opcije ako se koriste instance.
Podaci korisnika — označava korisničke podatke. Uredit ćemo fajl /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.configECS_CLUSTER=DemoApiClusterProd — parametar označava da instanca pripada klasteru sa datim imenom, odnosno da će ovaj klaster moći da postavlja svoje zadatke na ovaj server. Još nismo kreirali klaster, ali ćemo koristiti ovo ime prilikom kreiranja.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametar specificira da kada se primi signal za isključivanje spot instance, svi zadaci na njoj trebaju biti prebačeni u status Draining.
ECS_CONTAINER_STOP_TIMEOUT=1m - parametar specificira da nakon prijema signala SIGINT svi zadaci imaju 1 minut prije nego što budu ubijeni.
ECS_ENGINE_AUTH_TYPE=docker — parametar označava da se Docker šema koristi kao mehanizam autorizacije
ECS_ENGINE_AUTH_DATA=... — parametri povezivanja s privatnim registrom kontejnera, 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 Hub-a, pa navedite parametre ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nije potrebno.
Dobro je znati: Preporučuje se redovno ažuriranje AMI-ja, jer nove verzije ažuriraju verzije Dockera, Linuxa, ECS agenta, itd. Da ne zaboravite na ovo, možete o izdavanju novih verzija. Možete primati obavještenja putem e-pošte i ručno ažurirati, ili možete napisati Lambda funkciju koja će automatski kreirati novu verziju predloška za pokretanje s ažuriranim AMI-jem.
EC2 Auto Scaling Group
Auto Scaling Group je odgovorna za pokretanje i skaliranje instanci. Grupama se upravlja u odjeljku EC2 -> Auto Scaling -> Auto Scaling Groups.
Šablon za pokretanje — izaberite šablon kreiran u prethodnom koraku. Ostavljamo zadanu verziju.
Opcije kupovine i vrste instanci — specificirajte tipove instanci za klaster. Adhere to launch template koristi tip instance iz predloška za pokretanje. Kombinacija opcija kupovine i tipova instanci omogućava vam da fleksibilno konfigurirate tipove instanci. Mi ćemo to iskoristiti.
Opciona baza na zahtjev — broj redovnih, non-spot instanci koje će uvijek raditi.
Procenat na zahtjev iznad osnove — procentualni odnos regularnih i spot instanci, 50-50 će se ravnomjerno raspodijeliti, 20-80 za svaku regularnu instancu 4 spot instance će se povećati. Za potrebe ovog primjera naznačiću 50-50, ali u stvarnosti najčešće radimo 20-80, u nekim slučajevima 0-100.
Tipovi instance — ovdje možete odrediti dodatne tipove instanci koje će se koristiti u klasteru. Nikad ga nismo koristili jer ne razumijem značenje priče. Možda je to zbog ograničenja određenih tipova instanci, ali ona se lako mogu povećati kroz podršku. Ako znate aplikaciju, bit će mi drago pročitati je u komentarima)
mreža — mrežna podešavanja, izaberite VPC i podmreže za mašine, u većini slučajeva trebalo bi da izaberete sve dostupne podmreže.
Balansiranje opterećenja - postavke balansera, ali to ćemo učiniti zasebno, ovdje nećemo ništa dirati. Zdravstveni pregledi će također biti kasnije konfigurisan.
Veličina grupe — označavamo ograničenja broja mašina u klasteru i željeni broj mašina na početku. Broj strojeva u klasteru nikada neće biti manji od specificiranog minimuma i veći od maksimuma, čak i ako bi se skaliranje trebalo dogoditi prema metrici.
Politike skaliranja — parametri skaliranja, ali ćemo skalirati na osnovu pokrenutih ECS zadataka, tako da ćemo kasnije konfigurirati skaliranje.
Zaštita od skaliranja instance — zaštita instanci od brisanja prilikom smanjivanja. Omogućavamo ga tako da ASG ne izbriše mašinu koja ima pokrenute zadatke. ECS Capacity Provider će onemogućiti zaštitu za instance koje nemaju zadatke.
Dodajte oznake — možete navesti oznake za instance (za ovo mora biti označeno polje za potvrdu Označi nove instance). Preporučujem da navedete oznaku Name, tada će sve instance koje se pokreću unutar grupe imati isto ime i zgodno ih je pregledati u konzoli.
Nakon kreiranja grupe, otvorite je i idite na odjeljak Napredne konfiguracije.Zašto sve opcije nisu vidljive u konzoli u fazi kreiranja.
Politike raskida — pravila koja se uzimaju u obzir prilikom brisanja instanci. Primjenjuju se po redu. Obično koristimo one na slici ispod. Prvo se brišu instance sa najstarijim predloškom za pokretanje (na primjer, ako smo ažurirali AMI, kreirali smo novu verziju, ali su se sve instance uspjele prebaciti na nju). Zatim se biraju instance koje su najbliže sljedećem satu obračuna. Zatim se biraju najstariji na osnovu datuma lansiranja.
Dobro je znati: za ažuriranje svih mašina u klasteru, pogodno za upotrebu . Ako ovo kombinirate s Lambda funkcijom iz prethodnog koraka, imat ćete potpuno automatizirani sistem ažuriranja instance. Prije ažuriranja svih strojeva, morate onemogućiti zaštitu instance skaliranja za sve instance u grupi. Ne konfigurisanje u grupi, već zaštita od samih mašina, to se radi na kartici Upravljanje instancom.
Aplikacija za balansiranje opterećenja i EC2 ciljna grupa
Balanser se kreira u sekciji EC2 → Balansiranje opterećenja → Balanseri opterećenja. Koristićemo aplikaciju za balansiranje opterećenja; poređenje različitih tipova balansera može se pročitati na .
Slušalice - ima smisla napraviti portove 80 i 443 i kasnije preusmjeriti sa 80 na 443 koristeći pravila balansiranja.
Zone dostupnosti — u većini slučajeva biramo zone pristupačnosti za sve.
Konfigurišite sigurnosne postavke — ovdje je naznačen SSL certifikat za balanser, najpogodnija opcija je u ACM. O razlikama sigurnosnu politiku može se pročitati , možete ga ostaviti odabranim prema zadanim postavkama ELBSecurityPolicy-2016-08. Nakon kreiranja balansera, vidjet ćete ga DNS ime, koji trebate da konfigurirate CNAME za svoju domenu. Na primjer, ovako to izgleda u Cloudflareu.
Security Group — kreirajte ili odaberite sigurnosnu grupu za balanser, pisao sam više o tome malo gore u EC2 Launch Template → Network settings section.
Ciljna grupa — kreiramo grupu koja je odgovorna za usmjeravanje zahtjeva sa balansera na mašine i provjeravanje njihove dostupnosti kako bi ih zamijenili u slučaju problema. Tip cilja 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 port 80.
Zdravstveni pregledi — parametri za provjeru funkcionalnosti usluge. U stvarnom servisu, ovo bi trebao biti poseban zahtjev koji implementira važne dijelove poslovne logike; za potrebe ovog primjera, ostavit ću zadana podešavanja. Zatim možete odabrati interval zahtjeva, vremensko ograničenje, kodove uspjeha, itd. U našem primjeru ćemo naznačiti šifre uspjeha 200-399, jer Docker slika koja će se koristiti vraća kod 304.
Registrirajte mete — ovdje su odabrani automobili za grupu, ali u našem slučaju to će uraditi ECS, tako da samo preskačemo ovaj korak.
Dobro je znati: na nivou balansera možete omogućiti zapisnike koji će biti sačuvani u S3 u određenom . Odatle se mogu izvesti u usluge treće strane za analitiku, ili možete napraviti SQL upite direktno na podacima u S3 pomoću . Zgodno je i radi bez dodatnog koda. Također preporučujem postavljanje uklanjanja trupaca iz S3 kante nakon određenog vremenskog perioda.
ECS definicija zadatka
U prethodnim koracima kreirali smo sve što se tiče servisne infrastrukture, a sada prelazimo na opis kontejnera koje ćemo pokrenuti. Ovo se radi u odeljku ECS → Definicije zadataka.
Kompatibilnost tipa lansiranja - izaberite EC2.
IAM uloga izvršenja zadatka - biraj ecsTaskExecutionRole. Pomoću njega se pišu zapisnici, daje pristup tajnim varijablama itd.
U odjeljku Definicije kontejnera kliknite na Dodaj kontejner.
slika — link do slike sa kodom projekta; za ovaj primjer koristiću javnu sliku iz Docker Hub-a .
Memory Limits — ograničenja memorije za kontejner. Hard Limit — tvrdo ograničenje, ako kontejner prijeđe zadanu vrijednost, naredba docker kill će se izvršiti, kontejner će odmah umrijeti. Soft Limit — meko ograničenje, kontejner može ići preko navedene vrijednosti, ali će se ovaj parametar uzeti u obzir prilikom postavljanja zadataka na mašine. Na primjer, ako mašina ima 4 GiB RAM-a, a meka granica kontejnera je 2048 MiB, tada ova mašina može imati najviše 2 pokrenuta zadatka s ovim kontejnerom. U stvarnosti, 4 GiB RAM-a je nešto manje od 4096 MiB, ovo 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 kontejnera u jednom zadatku, onda se njihova ograničenja sumiraju.
Mapa portova - u Host port Označavamo 0, što znači da će port biti dodijeljen dinamički i da će ga ciljna grupa nadzirati. Kontejnerska luka — port na kojem se pokreće vaša aplikacija često je naveden u naredbi za izvršavanje ili je dodijeljen u kodu vaše aplikacije, Dockerfile-u, itd. Za naš primjer koristit ćemo 3000 jer je navedeno u sliku koja se koristi.
Provjera zdravlja — parametre provjere zdravlja kontejnera, ne treba ih brkati s onim konfiguriranim u ciljnoj grupi.
ambijent — postavke okruženja. CPU jedinice - slično ograničenjima memorije, samo o procesoru. Svaka procesorska jezgra ima 1024 jedinice, tako da ako server ima dual-core procesor i kontejner je postavljen na 512, onda se 4 zadatka sa ovim kontejnerom mogu pokrenuti na jednom serveru. CPU jedinice uvijek odgovaraju broju jezgara, ne može ih biti malo manje, kao što je slučaj s memorijom.
naredba — naredba za pokretanje usluge unutar kontejnera, svi parametri su navedeni odvojeni zarezima. Ovo može biti gunicorn, npm, itd. Ako nije navedeno, koristit će se vrijednost CMD direktive iz Dockerfile-a. Mi ukazujemo npm,start.
Varijable okoline — varijable okruženja kontejnera. To mogu biti ili jednostavni tekstualni podaci ili tajne varijable iz ili .
Skladištenje i evidentiranje — ovdje ćemo podesiti prijavu u CloudWatch Logs (usluga za logove iz AWS-a). Da biste to učinili, samo omogućite potvrdni okvir Auto-configure CloudWatch Logs. Nakon kreiranja definicije zadatka, grupa dnevnika će se automatski kreirati u CloudWatchu. Prema zadanim postavkama, dnevnici se u njemu pohranjuju na neograničeno vrijeme; preporučujem da promijenite period zadržavanja sa Never Expire na traženi period. To se radi u CloudWatch Log grupama, potrebno je kliknuti na trenutni period i odabrati novi.
ECS klaster i ECS provajder kapaciteta
Idite na odjeljak ECS → Klasteri da kreirate klaster. Kao predložak biramo EC2 Linux + Networking.
Ime klastera - vrlo važno, ovdje pravimo isto ime kao što je navedeno u parametru Launch Template ECS_CLUSTER, u našem slučaju - DemoApiClusterProd. Označite polje za potvrdu Kreiraj prazan klaster. Opciono, možete omogućiti Container Insights za pregled metrike za usluge u CloudWatchu. Ako ste sve uradili ispravno, tada ćete u odeljku ECS Instance videti mašine koje su kreirane u grupi za automatsko skaliranje.
Idi na karticu Capacity Providers i kreirajte novu. Da vas podsjetim da je potrebno kontrolirati kreiranje i gašenje strojeva ovisno o broju pokrenutih ECS zadataka. Važno je napomenuti da se provajder može dodijeliti samo jednoj grupi.
Grupa za automatsko skaliranje — izaberite prethodno kreiranu grupu.
Upravljano skaliranje — omogućite ga tako da provajder može skalirati uslugu.
Ciljni kapacitet % — koliki procenat mašina napunjenih zadacima nam je potreban. Ako navedete 100%, onda će sve mašine uvijek biti zauzete izvršavanjem zadataka. Ako navedete 50%, tada će polovina automobila uvijek biti besplatna. U tom slučaju, ako dođe do naglog skoka opterećenja, novi taksiji će odmah stići do besplatnih automobila, bez čekanja da se instance pokrenu.
Upravljana zaštita od prekida — omogući, ovaj parametar omogućava provajderu da ukloni zaštitu instanci od brisanja. Ovo se dešava kada na mašini nema aktivnih zadataka i dozvoljava Ciljni kapacitet%.
ECS servis i podešavanje skaliranja
Poslednji korak :) Za kreiranje usluge potrebno je da odete na prethodno kreirani klaster na kartici Usluge.
Tip lansiranja — potrebno je da kliknete na Prebaci na strategiju provajdera kapaciteta i odaberete prethodno kreirane provajdere.
Definicija zadatka — izaberite prethodno kreiranu definiciju zadatka i njenu reviziju.
Naziv usluge — da bismo izbjegli zabunu, uvijek označavamo isto što i definicija zadatka.
Vrsta usluge - uvek replika.
Broj zadataka — željeni broj aktivnih zadataka u servisu. Ovaj parametar se kontrolira skaliranjem, ali se ipak mora specificirati.
Minimalni zdrav procenat и Maksimalni procenat — odrediti ponašanje zadataka tokom raspoređivanja. Zadane vrijednosti su 100 i 200, što ukazuje da će se u trenutku implementacije broj zadataka povećati nekoliko puta, a zatim vratiti na željenu vrijednost. Ako imate 1 zadatak koji je pokrenut, min=0 i max=100, tada će tokom implementacije on biti ubijen, a nakon toga će se pokrenuti novi, odnosno bit će zastoj. Ako je 1 zadatak pokrenut, min=50, max=150, tada se do raspoređivanja neće uopće dogoditi, jer se 1 zadatak ne može podijeliti na pola ili povećati za jedan i po puta.
Vrsta implementacije — napustite Rolling update.
Placement Templates — pravila za postavljanje zadataka na mašine. Podrazumevano je AZ Balanced Spread - to znači da će svaki novi zadatak biti postavljen na novu instancu dok se mašine u svim zonama dostupnosti ne podignu. Obično radimo BinPack - CPU i Spread - AZ; sa ovom politikom, zadaci se postavljaju što je gušće moguće na jednu mašinu po CPU-u. Ako je potrebno kreirati novu mašinu, ona se kreira u novoj zoni dostupnosti.
Tip balansera opterećenja — izaberite Application Load Balancer.
Uloga usluge IAM - biraj ecsServiceRole.
Naziv balansera opterećenja — izaberite prethodno kreirani balanser.
Grejs period za zdravstveni pregled — pauzirajte prije obavljanja provjere zdravlja nakon uvođenja novog zadatka, obično ga postavljamo na 60 sekundi.
Kontejner za balans opterećenja — u stavci Naziv ciljne grupe izaberite prethodno kreiranu grupu i sve će se automatski popuniti.
Usluga automatskog skaliranja — parametri skaliranja usluge. Odaberite Konfiguriraj automatsko skaliranje usluge da prilagodite željeni broj usluge. Postavljamo minimalni i maksimalni broj zadataka prilikom skaliranja.
IAM uloga za automatsko skaliranje usluge - biraj AWSServiceRoleForApplicationAutoScaling_ECSService.
Politike automatskog skaliranja zadataka — pravila za skaliranje. Postoje 2 vrste:
- Praćenje cilja — praćenje ciljnih metrika (upotreba CPU/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 dostigne ciljnu vrijednost. Ako je opterećenje niže, tada će zadaci biti uklonjeni, naprotiv, osim ako nije omogućena zaštita od smanjenja (Onemogući skaliranje).
- Stepen skaliranja - reakcija na proizvoljan 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 tačan broj zadataka.
Usluga može imati nekoliko pravila skaliranja, to može biti korisno, glavna stvar je osigurati da se ne sukobljavaju jedno s drugim.
zaključak
Ako ste slijedili upute i koristili istu Docker sliku, vaša usluga bi trebala vratiti stranicu poput ove.
- Napravili smo šablon prema kojem se pokreću sve mašine u servisu. Takođe smo naučili kako da ažuriramo mašine kada se šablon promeni.
- Konfigurisali smo obradu signala zaustavljanja spot instance, tako da se u roku od jedne minute nakon prijema svi zadaci u toku uklanjaju sa mašine, tako da ništa nije izgubljeno ili prekinuto.
- Podigli smo balanser da ravnomerno rasporedimo opterećenje na mašine.
- Napravili smo uslugu koja radi na licu mjesta, što smanjuje troškove stroja za oko 3 puta.
- Konfigurirali smo automatsko skaliranje u oba smjera kako bismo se nosili s povećanim radnim opterećenjem bez troškova zastoja.
- Koristimo Capacity Provider tako da aplikacija upravlja infrastrukturom (mašinama), a ne obrnuto.
- Odlični smo.
Ako imate predvidljive skokove opterećenja, na primjer, oglašavate u velikoj kampanji e-pošte, možete postaviti skaliranje tako da .
Također možete skalirati na osnovu podataka iz različitih dijelova vašeg sistema. Na primjer, imamo funkcionalnost korisnika mobilne aplikacije. Ponekad se kampanja šalje na 1M+ ljudi. Nakon takve distribucije uvijek dolazi do velikog porasta zahtjeva prema API-ju, jer se u aplikaciju istovremeno prijavljuje mnogo korisnika. Dakle, ako vidimo da ima znatno više standardnih indikatora u redu za slanje promotivnih push notifikacija, možemo odmah pokrenuti nekoliko dodatnih mašina 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 hiljade analitičkih događaja u sekundi na pretežno bezserverskom stogu (sa novcem) i kako funkcionira implementacija usluga koristeći GitLab CI i Terraform Cloud.
Pretplatite se na nas, biće zanimljivo!
Samo registrovani korisnici mogu učestvovati u anketi. molim.
Koristite li spot instance u proizvodnji?
-
22,2%Da6
-
66,7%No18
-
11,1%O njima sam saznao iz članka i planiram ih koristiti3
Glasalo je 27 korisnika. Uzdržano je bilo 5 korisnika.
izvor: www.habr.com