Pozdravljeni vsi skupaj! Moje ime je Kirill, sem tehnični direktor pri Adapty. Večina naše arhitekture je na AWS in danes bom govoril o tem, kako smo zmanjšali stroške strežnika za 3-krat z uporabo točkovnih primerkov v produkcijskem okolju, pa tudi o tem, kako nastaviti njihovo samodejno skaliranje. Najprej bo na voljo pregled delovanja, nato pa podrobna navodila za začetek.
Kaj so točkovni primerki?
instance so strežniki drugih uporabnikov AWS, ki trenutno mirujejo, in jih prodajajo z velikim popustom (Amazon piše do 90%, po naših izkušnjah ~3x, razlikuje se glede na regijo, AZ in tip instance). Njihova glavna razlika od običajnih je, da se lahko kadar koli izklopijo. Zato smo dolgo verjeli, da je normalno, da jih uporabljamo za deviška okolja ali za naloge računanja nečesa, vmesne rezultate pa shranimo na S3 ali v bazo podatkov, ne pa za prodajo. Obstajajo rešitve tretjih oseb, ki vam omogočajo uporabo točk v proizvodnji, vendar je za naš primer veliko bergel, zato jih nismo implementirali. Pristop, opisan v članku, deluje v celoti v okviru standardne funkcionalnosti AWS, brez dodatnih skript, kron ipd.
Spodaj je nekaj posnetkov zaslona, ki prikazujejo zgodovino cen za promptne primerke.
m5.large v regiji eu-west-1 (Irska). Cena je bila večinoma stabilna 3 mesece, trenutno prihranek 2.9x.
m5.large v regiji us-east-1 (N. Virginia). Cena se nenehno spreminja v 3 mesecih, trenutno prihranek od 2.3x do 2.8x, odvisno od območja razpoložljivosti.
t3.majhen v regiji us-east-1 (N. Virginia). Cena je stabilna že 3 mesece, trenutno prihranek 3.4x.
Storitvena arhitektura
Osnovna arhitektura storitve, o kateri bomo govorili v tem članku, je prikazana v spodnjem diagramu.
Izravnalnik obremenitve aplikacije → Ciljna skupina EC2 → Storitev elastičnega vsebnika
Kot izravnavalec se uporablja Application Load Balancer (ALB), ki pošilja zahteve ciljni skupini (TG) EC2. TG je odgovoren za odpiranje vrat na instancah za ALB in njihovo povezovanje z vrati vsebnikov Elastic Container Service (ECS). ECS je analog Kubernetesa v AWS, ki upravlja vsebnike Docker.
En primerek ima lahko več delujočih vsebnikov z enakimi vrati, zato jih ne moremo fiksno nastaviti. ECS pove TG, da zaganja novo nalogo (v terminologiji Kubernetes se temu reče pod), preveri prosta vrata na instanci in enega od njih dodeli zagnani nalogi. TG tudi redno preverja, ali primerek in API delujeta na njem s pregledom zdravja, in če opazi kakršne koli težave, preneha pošiljati zahteve tam.
Skupine za samodejno skaliranje EC2 + ponudniki zmogljivosti ECS
Zgornji diagram ne prikazuje storitve EC2 Auto Scaling Groups (ASG). Iz imena lahko razumete, da je odgovoren za skaliranje primerkov. Vendar do nedavnega AWS ni imel vgrajene zmožnosti upravljanja števila delujočih strojev iz ECS. ECS je omogočil skaliranje števila opravil, na primer glede na porabo procesorja, RAM-a ali število zahtev. Če pa so opravila zasedla vse proste primerke, novi stroji niso bili samodejno ustvarjeni.
To se je spremenilo s prihodom ponudnikov zmogljivosti ECS (ECS CP). Zdaj je lahko vsaka storitev v ECS povezana z ASG in če naloge ne ustrezajo delujočim primerkom, bodo postavljene nove (vendar znotraj uveljavljenih omejitev ASG). To deluje tudi v nasprotni smeri, če ECS CP vidi nedejavne primerke brez opravil, bo dal ukaz ASG, da jih zaustavi. ECS CP ima možnost določiti ciljni odstotek obremenitve instance, tako da je določeno število strojev vedno prostih za opravila hitrega spreminjanja velikosti; o tem bom govoril malo kasneje.
Predloge za zagon EC2
Zadnja storitev, o kateri bom govoril, preden grem v podrobnosti o ustvarjanju te infrastrukture, so EC2 Launch Templates. Omogoča vam, da ustvarite predlogo, po kateri se bodo zagnali vsi stroji, da tega ne bi ponavljali vsakič iz nič. Tukaj lahko izberete vrsto stroja za zagon, varnostno skupino, sliko diska in številne druge parametre. Določite lahko tudi uporabniške podatke, ki bodo naloženi v vse zažene primerke. V uporabniških podatkih lahko izvajate skripte, na primer lahko urejate vsebino datoteke .
Eden najpomembnejših konfiguracijskih parametrov za ta članek je =res. Če je ta parameter omogočen, ECS takoj, ko prejme signal, da se točkovni primerek odvzema, prenese vsa opravila, ki delajo na njem, v stanje Izpraznitev. Temu primerku ne bodo dodeljena nobena nova opravila; če obstajajo opravila, ki jih želite takoj uvesti, bodo preklicana. Prav tako nehajo prihajati zahteve uravnoteženja. Obvestilo o izbrisu instance pride 2 minuti pred dejanskim dogodkom. Torej, če vaša storitev ne izvaja nalog, daljših od 2 minut in ne shrani ničesar na disk, potem lahko uporabite promptne primerke brez izgube podatkov.
Glede diska - AWS pred kratkim Elastični datotečni sistem (EFS) je možno uporabljati skupaj z ECS, pri tej shemi tudi disk ni ovira, vendar tega nismo poskusili, saj diska za shranjevanje stanja načeloma ne potrebujemo. Privzeto bodo po prejemu SIGINT (poslano, ko je opravilo preneseno v stanje izpraznitve) vsa opravila, ki se izvajajo, ustavljena po 30 sekundah, tudi če še niso dokončana; ta čas lahko spremenite s parametrom . Glavna stvar je, da ne nastavite več kot 2 minuti za točkovne stroje.
Ustvarjanje storitve
Preidimo na ustvarjanje opisane storitve. V procesu bom dodatno opisal več uporabnih točk, ki niso bile omenjene zgoraj. Na splošno je to navodilo po korakih, vendar ne bom upošteval nekaterih zelo osnovnih ali, nasprotno, zelo specifičnih primerov. Vsa dejanja se izvajajo v vizualni konzoli AWS, vendar jih je mogoče programsko reproducirati z uporabo CloudFormation ali Terraform. Pri Adapty uporabljamo Terraform.
Predloga za zagon EC2
Ta storitev ustvari konfiguracijo strojev, ki bodo uporabljeni. Predloge se upravljajo v razdelku EC2 -> Primerki -> Predloge za zagon.
Slika stroja Amazon (AMI) — določite sliko diska, s katero bodo zagnani vsi primerki. Za ECS je v večini primerov vredno uporabiti optimizirano sliko iz Amazona. Redno se posodablja in vsebuje vse potrebno za delovanje ECS. Če želite izvedeti trenutni ID slike, pojdite na stran , izberite regijo, ki jo uporabljate, in kopirajte AMI ID zanjo. Na primer, za regijo us-east-1 je trenutni ID v času pisanja ami-00c7c1cf5bdc913ed. Ta ID je treba vstaviti v postavko Določite vrednost po meri.
Vrsta primerka — označite vrsto primerka. Izberite tisto, ki najbolj ustreza vaši nalogi.
Par ključev (prijava) — določite potrdilo, s katerim se lahko po potrebi povežete z instanco prek SSH.
omrežne nastavitve — določite omrežne parametre. Omrežna platforma v večini primerov bi moral obstajati virtualni zasebni oblak (VPC). Varnostne skupine — varnostne skupine za vaše primere. Ker bomo pred instancami uporabili izravnalnik, priporočam, da tukaj določite skupino, ki dovoljuje dohodne povezave samo iz izravnalnika. To pomeni, da boste imeli 2 varnostni skupini, eno za izravnalnik, ki omogoča vhodne povezave od koder koli na vratih 80 (http) in 443 (https), in drugo za stroje, ki omogoča dohodne povezave na poljubnih vratih iz skupine za izravnavo . Odhodne povezave v obeh skupinah je treba odpreti s protokolom TCP do vseh vrat do vseh naslovov. Omejite lahko vrata in naslove za odhodne povezave, vendar morate potem nenehno spremljati, da ne poskušate dostopati do nečesa na zaprtih vratih.
Shranjevanje (količine) — določite parametre diska za stroje. Velikost diska ne sme biti manjša od tiste, ki je navedena v AMI; za ECS Optimized je 30 GiB.
Napredne podrobnosti — določite dodatne parametre.
Možnost nakupa — ali želimo kupiti promptne primerke. Želimo, vendar tega polja tukaj ne bomo označili; konfigurirali ga bomo v skupini za samodejno skaliranje, tam je več možnosti.
Profil primerka IAM — navedite vlogo, s katero bodo primerki zagnani. Da se primerki izvajajo v ECS, potrebujejo dovoljenja, ki jih običajno najdete v vlogi ecsInstanceRole. V nekaterih primerih se lahko ustvari, če ne, potem tukaj kako to narediti. Po izdelavi jo označimo v predlogi.
Nato je veliko parametrov, v bistvu lahko povsod pustite privzete vrednosti, vendar ima vsak od njih jasen opis. Vedno omogočim primerek, optimiziran za EBS, in možnosti T2/T3 Unlimited, če jih uporabljam primerki.
Čas uporabnik — navedite uporabniške podatke. Uredili bomo datoteko /etc/ecs/ecs.config, ki vsebuje konfiguracijo agenta ECS.
Primer, kako bi lahko izgledali uporabniški podatki:
#!/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 — parameter označuje, da primerek pripada gruči z danim imenom, kar pomeni, da bo ta gruča lahko postavila svoje naloge na ta strežnik. Grozda še nismo ustvarili, vendar bomo pri ustvarjanju uporabili to ime.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parameter določa, da se ob prejemu signala za izklop točkovne instance vsa opravila na njej prenesejo v stanje izčrpavanja.
ECS_CONTAINER_STOP_TIMEOUT=1m - parameter določa, da imajo vse naloge po prejemu signala SIGINT 1 minuto časa, preden so uničene.
ECS_ENGINE_AUTH_TYPE=docker — parameter označuje, da se kot avtorizacijski mehanizem uporablja shema Docker
ECS_ENGINE_AUTH_DATA=... — parametri povezave z zasebnim registrom vsebnikov, kjer so shranjene vaše slike Docker. Če je javno, vam ni treba ničesar navesti.
Za namene tega članka bom uporabil javno sliko iz Docker Huba, zato določite parametre ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA ni potrebe.
Dobro je vedeti: Priporočljivo je, da redno posodabljate AMI, ker nove različice posodabljajo različice Dockerja, Linuxa, agenta ECS itd. Da ne pozabite na to, lahko o izdaji novih različic. Obvestila lahko prejmete po e-pošti in posodobite ročno ali pa napišete funkcijo Lambda, ki bo samodejno ustvarila novo različico predloge za zagon s posodobljenim AMI.
Skupina za samodejno skaliranje EC2
Skupina za samodejno skaliranje je odgovorna za zagon in skaliranje primerkov. Skupine se upravljajo v razdelku EC2 -> Auto Scaling -> Auto Scaling Groups.
Predloga za zagon — izberite predlogo, ustvarjeno v prejšnjem koraku. Pustimo privzeto različico.
Možnosti nakupa in vrste primerkov — določite vrste primerkov za gručo. Upoštevanje zagonske predloge uporablja vrsto primerka iz zagonske predloge. Kombinacija možnosti nakupa in vrst instanc vam omogoča prilagodljivo konfiguracijo vrst instanc. Uporabili ga bomo.
Izbirna baza na zahtevo — število rednih, netočkovnih primerkov, ki bodo vedno delovali.
Odstotek na zahtevo nad osnovo — odstotno razmerje rednih in promptnih primerkov, 50-50 bo enakomerno porazdeljenih, 20-80 za vsako navadno instanco, 4 promptne bodo zvišane. Za namene tega primera bom navedel 50-50, vendar v resnici najpogosteje naredimo 20-80, v nekaterih primerih 0-100.
Vrste primerkov — tukaj lahko določite dodatne vrste instanc, ki bodo uporabljene v gruči. Nikoli je nismo uporabili, ker res ne razumem pomena zgodbe. Morda je to posledica omejitev določenih vrst primerkov, vendar jih je mogoče preprosto povečati s podporo. Če poznate aplikacijo, jo bom z veseljem prebral v komentarjih)
mreža — omrežne nastavitve, izberite VPC in podomrežja za stroje, v večini primerov morate izbrati vsa razpoložljiva podomrežja.
Izravnava obremenitve - nastavitve uravnoteženja, vendar bomo to storili ločeno, tukaj se ne bomo ničesar dotaknili. Zdravstveni pregledi bo tudi konfiguriran kasneje.
Velikost skupine — na začetku navedemo omejitve števila strojev v gruči in želeno število strojev. Število strojev v gruči nikoli ne bo manjše od najmanjšega določenega in večjega od največjega, tudi če bi prišlo do skaliranja v skladu z metriko.
Politike skaliranja — parametri skaliranja, vendar bomo skalirali na podlagi izvajajočih se nalog ECS, zato bomo skaliranje konfigurirali pozneje.
Zaščita pred povečano instanco — zaščita primerkov pred brisanjem pri pomanjšanju. Omogočimo ga tako, da ASG ne izbriše stroja, ki ima delujoče naloge. ECS Capacity Provider bo onemogočil zaščito za primerke, ki nimajo nalog.
Dodajte oznake — lahko določite oznake za primerke (za to mora biti potrjeno polje Označi nove primerke). Priporočam, da določite oznako imena, potem bodo vsi primerki, ki se zaženejo v skupini, imeli isto ime in si jih je priročno ogledati v konzoli.
Ko ustvarite skupino, jo odprite in pojdite na razdelek Napredne konfiguracije. Zakaj niso vse možnosti vidne v konzoli v fazi ustvarjanja.
Politike odpovedi — pravila, ki se upoštevajo pri brisanju primerkov. Uporabljajo se po vrstnem redu. Običajno uporabljamo tiste na spodnji sliki. Najprej se izbrišejo primerki z najstarejšo zagonsko predlogo (na primer, če smo posodobili AMI, smo ustvarili novo različico, vendar je vsem primerkom uspelo preklopiti nanjo). Nato se izberejo primerki, ki so najbližje naslednji obračunski uri. Nato so najstarejši izbrani glede na datum lansiranja.
Dobro je vedeti: za posodobitev vseh strojev v gruči, priročno za uporabo . Če to združite s funkcijo Lambda iz prejšnjega koraka, boste imeli popolnoma avtomatiziran sistem za posodabljanje primerkov. Preden posodobite vse naprave, morate onemogočiti zaščito pred povečavo instance za vse instance v skupini. Ne konfiguracija v skupini, ampak zaščita pred stroji samimi, to se naredi na zavihku Upravljanje primerkov.
Izravnalnik obremenitve aplikacij in ciljna skupina EC2
Balansir se ustvari v razdelku EC2 → Load Balancing → Load Balancers. Uporabili bomo Application Load Balancer, primerjavo različnih tipov balancerjev si lahko preberete na .
Poslušalci - smiselno je narediti vrata 80 in 443 in pozneje preusmeriti z 80 na 443 z uporabo pravil za izravnavo.
Območja razpoložljivosti — v večini primerov izberemo območja dostopnosti za vse.
Konfigurirajte varnostne nastavitve — tukaj je navedeno potrdilo SSL za izravnalnik, najbolj priročna možnost je v ACM. O razlikah Varnostna politika lahko preberete v , lahko pustite izbrano privzeto ELBSecurityPolicy-2016-08. Ko ustvarite balanser, ga boste videli Ime DNS, ki ga potrebujete za konfiguracijo CNAME za svojo domeno. Tako je na primer videti v Cloudflareju.
Varnostna skupina — ustvarite ali izberite varnostno skupino za izravnalnik, več o tem sem napisal zgoraj v razdelku EC2 Launch Template → Network settings.
Ciljna skupina — ustvarimo skupino, ki je odgovorna za usmerjanje zahtev od izravnalnika do strojev in preverjanje njihove razpoložljivosti, da jih v primeru težav zamenjamo. Vrsta cilja mora biti primerek, Protokol и port kateri koli, če uporabljate HTTPS za komunikacijo med izravnalnikom in primerki, morate nanje naložiti potrdilo. Za namene tega primera tega ne bomo storili, preprosto bomo zapustili vrata 80.
Zdravstveni pregledi — parametri za preverjanje funkcionalnosti storitve. V resnični storitvi bi morala biti to ločena zahteva, ki izvaja pomembne dele poslovne logike; za namene tega primera bom pustil privzete nastavitve. Nato lahko izberete interval zahteve, časovno omejitev, kode uspeha itd. V našem primeru bomo navedli kode uspeha 200–399, ker slika Dockerja, ki bo uporabljena, vrne kodo 304.
Registrirajte cilje — tukaj so izbrani avtomobili za skupino, vendar bo v našem primeru to naredil ECS, zato ta korak preprosto preskočimo.
Dobro je vedeti: na ravni izravnalnika lahko omogočite dnevnike, ki bodo shranjeni v S3 v določenem . Od tam jih je mogoče izvoziti v storitve tretjih oseb za analitiko ali pa izvajati poizvedbe SQL neposredno na podatkih v S3 z . Je priročen in deluje brez dodatne kode. Priporočam tudi nastavitev odstranjevanja hlodov iz vedra S3 po določenem časovnem obdobju.
Opredelitev nalog ECS
V prejšnjih korakih smo ustvarili vse, kar je povezano s storitveno infrastrukturo, zdaj pa nadaljujemo z opisom vsebnikov, ki jih bomo lansirali. To naredite v razdelku ECS → Definicije opravil.
Združljivost vrste zagona - izberite EC2.
Vloga IAM za izvajanje nalog - izberite ecsTaskExecutionRole. Z njim se pišejo dnevniki, omogoča dostop do tajnih spremenljivk itd.
V razdelku Definicije vsebnika kliknite Dodaj vsebnik.
Image — povezava do slike s kodo projekta; za ta primer bom uporabil javno sliko iz Docker Huba .
Omejitve pomnilnika — omejitve pomnilnika za vsebnik. Trda meja — trda omejitev, če vsebnik preseže določeno vrednost, bo izveden ukaz za uničenje dockerja, vsebnik bo takoj umrl. Mehka meja — mehka omejitev, vsebnik lahko preseže določeno vrednost, vendar bo ta parameter upoštevan pri postavljanju nalog na stroje. Na primer, če ima stroj 4 GiB RAM-a in je mehka omejitev vsebnika 2048 MiB, ima ta stroj lahko največ 2 izvajajoči se nalogi s tem vsebnikom. V resnici je 4 GiB RAM-a nekoliko manj kot 4096 MiB, to si lahko ogledate na zavihku ECS Instances v gruči. Mehka omejitev ne more biti višja od trde omejitve. Pomembno je razumeti, da če je v enem opravilu več vsebnikov, se njihove omejitve seštejejo.
Preslikave vrat - v Gostiteljska vrata Označimo 0, to pomeni, da bodo vrata dodeljena dinamično in jih bo nadzorovala ciljna skupina. Pristanišče za kontejnerje — vrata, na katerih se izvaja vaša aplikacija, so pogosto navedena v ukazu za izvajanje ali dodeljena v kodi vaše aplikacije, Dockerfile itd. Za naš primer bomo uporabili 3000, ker je naveden v uporabljena slika.
Zdravstveni pregled — parametrov preverjanja zdravja vsebnika, ki se ne smejo zamenjati s tistimi, ki so konfigurirani v ciljni skupini.
okolje — nastavitve okolja. CPE enote - podobno kot omejitve pomnilnika, le glede procesorja. Vsako procesorsko jedro ima 1024 enot, tako da če ima strežnik dvojedrni procesor in je vsebnik nastavljen na 512, se lahko na enem strežniku zaženejo 4 naloge s tem vsebnikom. CPE enote vedno ustrezajo številu jeder, ne more jih biti malo manj, kot je to pri pomnilniku.
Ukaz — ukaz za zagon storitve znotraj vsebnika, vsi parametri so podani ločeni z vejicami. To je lahko gunicorn, npm itd. Če ni navedeno, bo uporabljena vrednost direktive CMD iz datoteke Dockerfile. Navajamo npm,start.
Spremenljivke okolja — spremenljivke okolja vsebnika. To so lahko preprosti besedilni podatki ali skrivne spremenljivke iz ali .
Shranjevanje in beleženje — tukaj bomo nastavili beleženje v CloudWatch Logs (storitev za dnevnike iz AWS). Če želite to narediti, samo omogočite potrditveno polje Samodejno konfiguriraj dnevnike CloudWatch. Po ustvarjanju definicije opravila bo v CloudWatchu samodejno ustvarjena skupina dnevnikov. Privzeto so dnevniki v njem shranjeni za nedoločen čas; priporočam, da spremenite obdobje hrambe iz Nikoli ne poteče na zahtevano obdobje. To se naredi v skupinah CloudWatch Log, morate klikniti trenutno obdobje in izbrati novo.
Grozd ECS in ponudnik zmogljivosti ECS
Pojdite v razdelek ECS → Grozdi, da ustvarite gručo. Za predlogo izberemo EC2 Linux + Networking.
Ime gruče - zelo pomembno, tukaj naredimo isto ime, kot je navedeno v parametru Launch Template ECS_CLUSTER, v našem primeru - DemoApiClusterProd. Označite potrditveno polje Ustvari prazno gručo. Po želji lahko omogočite Container Insights za ogled meritev za storitve v CloudWatchu. Če ste vse naredili pravilno, boste v razdelku ECS Instances videli stroje, ki so bili ustvarjeni v skupini Auto Scaling.
Pojdite na zavihek Ponudniki zmogljivosti in ustvarite novo. Naj vas spomnim, da je potrebno nadzorovati ustvarjanje in zaustavitev strojev glede na število izvajanih nalog ECS. Pomembno je vedeti, da je ponudnik lahko dodeljen le eni skupini.
Skupina za samodejno skaliranje — izberite predhodno ustvarjeno skupino.
Upravljano skaliranje — omogočite, da lahko ponudnik storitev poveča.
Ciljna zmogljivost % — kolikšen odstotek strojev, obremenjenih z nalogami, potrebujemo. Če podate 100 %, bodo vsi stroji vedno zaposleni z izvajajočimi se opravili. Če določite 50 %, bo polovica avtomobilov vedno brezplačna. V tem primeru, če pride do močnega skoka obremenitve, bodo novi taksiji takoj prišli do prostih avtomobilov, ne da bi morali čakati na namestitev primerkov.
Upravljana zaščita pred prekinitvijo — omogoči, ta parameter omogoča ponudniku, da odstrani zaščito primerkov pred brisanjem. To se zgodi, ko na napravi ni aktivnih opravil in dovoljuje ciljno kapaciteto %.
Storitev ECS in nastavitev skaliranja
Zadnji korak :) Če želite ustvariti storitev, morate iti v predhodno ustvarjeno gručo na zavihku Storitve.
Vrsta zagona — morate klikniti Preklopi na strategijo ponudnika zmogljivosti in izbrati predhodno ustvarjene ponudnike.
Opredelitev naloge — izberite predhodno ustvarjeno definicijo naloge in njeno revizijo.
Ime storitve — da se izognemo zmedi, vedno navedemo isto kot Opredelitev naloge.
Vrsta storitve - vedno Replika.
Število nalog — želeno število aktivnih opravil v storitvi. Ta parameter je nadzorovan s skaliranjem, vendar mora biti še vedno določen.
Najmanjši zdrav odstotek и Največji odstotek — določitev obnašanja nalog med razmestitvijo. Privzeti vrednosti sta 100 in 200, kar pomeni, da se bo v času uvajanja število nalog večkrat povečalo in nato vrnilo na želeno vrednost. Če imate 1 nalogo v teku, min=0 in max=100, bo med uvajanjem ukinjena, nato pa bo postavljena nova, kar pomeni, da bo prišlo do izpada. Če se izvaja 1 opravilo, min=50, največ=150, se uvedba sploh ne bo zgodila, ker 1 opravila ni mogoče razdeliti na pol ali povečati za eninpolkrat.
Vrsta namestitve — zapustite tekočo posodobitev.
Predloge umestitev — pravila za dajanje nalog na stroje. Privzeto je AZ Balanced Spread – to pomeni, da bo vsako novo opravilo postavljeno na novo instanco, dokler se stroji v vseh območjih razpoložljivosti ne dvignejo. Običajno izvajamo BinPack - CPU in Spread - AZ; s tem pravilnikom so opravila čim bolj gosto postavljena na en stroj na CPE. Če je treba ustvariti nov stroj, se ta ustvari v novem območju razpoložljivosti.
Vrsta izravnalnika obremenitve — izberite Application Load Balancer.
Storitvena vloga IAM - izberite ecsServiceRole.
Ime izravnalnika obremenitve — izberite predhodno ustvarjeni balanser.
Odlog za pregled zdravstvenega stanja — premor pred izvajanjem zdravstvenih pregledov po uvedbi nove naloge, običajno ga nastavimo na 60 sekund.
Ravnotežje posode za obremenitev — v postavki Ime ciljne skupine izberite predhodno ustvarjeno skupino in vse se samodejno izpolni.
Storitev Samodejno skaliranje — parametri skaliranja storitve. Izberite Konfiguriraj samodejno skaliranje storitve, da prilagodite želeno število storitev. Pri skaliranju določimo najmanjše in največje število nalog.
Vloga IAM za samodejno skaliranje storitev - izberite AWSServiceRoleForApplicationAutoScaling_ECSService.
Politike samodejnega skaliranja opravil — pravila za skaliranje. Obstajata 2 vrsti:
- Sledenje ciljem — sledenje ciljnim meritvam (uporaba procesorja/RAM-a ali število zahtev za vsako nalogo). Na primer, želimo, da je povprečna obremenitev procesorja 85 %, ko postane višja, se dodajajo nove naloge, dokler ne doseže ciljne vrednosti. Če je obremenitev manjša, bodo naloge odstranjene, nasprotno, razen če je omogočena zaščita pred pomanjšanjem (Onemogoči povečavo).
- Stopenjsko skaliranje - odziv na samovoljni dogodek. Tukaj lahko konfigurirate reakcijo na vsak dogodek (CloudWatch Alarm), ko se zgodi, lahko dodate ali odstranite določeno število opravil ali določite natančno število opravil.
Storitev ima lahko več pravil skaliranja, to je lahko koristno, glavna stvar je zagotoviti, da niso v nasprotju med seboj.
Zaključek
Če ste sledili navodilom in uporabili isto sliko Dockerja, bi morala vaša storitev vrniti takšno stran.
- Ustvarili smo predlogo, po kateri se zaženejo vsi stroji v storitvi. Naučili smo se tudi, kako posodobiti stroje, ko se predloga spremeni.
- Konfigurirali smo obdelavo zaustavitvenega signala na kraju samem, tako da so v eni minuti po prejemu vsa tekoča opravila odstranjena iz stroja, tako da se nič ne izgubi ali prekine.
- Balanser smo dvignili, da se obremenitev enakomerno porazdeli po strojih.
- Ustvarili smo storitev, ki deluje na kraju samem, kar zmanjša stroške stroja za približno 3-krat.
- Konfigurirali smo samodejno skaliranje v obe smeri za obvladovanje povečanih delovnih obremenitev, ne da bi pri tem nastali stroški izpadov.
- Capacity Provider uporabljamo tako, da aplikacija upravlja infrastrukturo (stroje) in ne obratno.
- Super smo.
Če imate predvidljive skoke obremenitve, na primer oglašujete v veliki e-poštni kampanji, lahko nastavite skaliranje tako, da .
Prav tako lahko prilagajate na podlagi podatkov iz različnih delov vašega sistema. Na primer, imamo funkcionalnost uporabniki mobilne aplikacije. Včasih je oglaševalska akcija poslana več kot milijonu ljudi. Po takšni distribuciji vedno pride do velikega porasta zahtevkov za API, saj se v aplikacijo prijavi veliko uporabnikov hkrati. Če torej vidimo, da je v čakalni vrsti bistveno več standardnih indikatorjev za pošiljanje promocijskih potisnih obvestil, lahko takoj zaženemo več dodatnih strojev in opravil, da bomo pripravljeni na obremenitev.
Vesel bom, če mi v komentarjih poveste zanimive primere uporabe spotov in ECS ali kaj o skaliranju.
Kmalu bodo objavljeni članki o tem, kako obdelujemo na tisoče analitičnih dogodkov na sekundo na pretežno brezstrežniškem skladu (z denarjem) in kako deluje uvajanje storitev z uporabo GitLab CI in Terraform Cloud.
Naročite se na nas, zanimivo bo!
V anketi lahko sodelujejo samo registrirani uporabniki. , prosim.
Ali uporabljate promptne primerke v proizvodnji?
-
22,2%Da6
-
66,7%št.18
-
11,1%Zanje sem izvedel iz članka in jih nameravam uporabiti3
Glasovalo je 27 uporabnikov. 5 uporabnikov se je vzdržalo.
Vir: www.habr.com