Salutare tuturor! Numele meu este Kirill, sunt CTO la Adapty. Cea mai mare parte a arhitecturii noastre este pe AWS și astăzi voi vorbi despre modul în care am redus costurile serverului de 3 ori prin utilizarea instanțelor spot într-un mediu de producție, precum și despre cum să le setăm scalarea automată. Mai întâi va fi o privire de ansamblu asupra modului în care funcționează și apoi instrucțiuni detaliate pentru a începe.
Ce sunt Instanțele Spot?
Instanțele sunt servere ale altor utilizatori AWS care sunt în prezent inactiv și le vând cu o reducere mare (Amazon scrie până la 90%, din experiența noastră de ~3x, variază în funcție de regiune, AZ și tipul de instanță). Principala lor diferență față de cele obișnuite este că se pot opri în orice moment. De aceea, multă vreme am crezut că este normal să le folosim pentru medii virgine, sau pentru sarcini de calcul a ceva, cu rezultate intermediare salvate pe S3 sau în baza de date, dar nu pentru vânzări. Există soluții de la terți care vă permit să utilizați spoturi în producție, dar există multe cârje pentru cazul nostru, așa că nu le-am implementat. Abordarea descrisă în articol funcționează în întregime în cadrul funcționalității standard AWS, fără scripturi suplimentare, coroane etc.
Mai jos sunt câteva capturi de ecran care arată istoricul prețurilor pentru instanțe spot.
m5.mare în regiunea eu-vest-1 (Irlanda). Prețul a fost în mare parte stabil timp de 3 luni, economisind în prezent de 2.9 ori.
m5.mare în regiunea us-est-1 (N. Virginia). Prețul se modifică constant pe parcursul a 3 luni, economisind în prezent de la 2.3x la 2.8x, în funcție de zona de disponibilitate.
t3.mic în regiunea us-est-1 (N. Virginia). Prețul a fost stabil timp de 3 luni, economisind în prezent de 3.4 ori.
Arhitectura serviciului
Arhitectura de bază a serviciului despre care vom vorbi în acest articol este prezentată în diagrama de mai jos.
Aplicație Load Balancer → EC2 Target Group → Elastic Container Service
Aplicația Load Balancer (ALB) este utilizat ca echilibrator, care trimite cereri către EC2 Target Group (TG). TG este responsabil pentru deschiderea porturilor pe instanțe pentru ALB-uri și conectarea acestora la porturile containerelor Elastic Container Service (ECS). ECS este un analog al Kubernetes în AWS, care gestionează containerele Docker.
O instanță poate avea mai multe containere care rulează cu aceleași porturi, așa că nu le putem seta fix. ECS îi spune TG că lansează o nouă sarcină (în terminologia Kubernetes aceasta se numește un pod), verifică porturile libere pe instanță și atribuie una dintre ele sarcinii lansate. De asemenea, TG verifică în mod regulat dacă instanța și API-ul lucrează la ea folosind verificarea sănătății și, dacă vede probleme, nu mai trimite cereri acolo.
EC2 Auto Scaling Groups + ECS Capacity Providers
Diagrama de mai sus nu arată serviciul EC2 Auto Scaling Groups (ASG). Din nume puteți înțelege că este responsabil pentru scalarea instanțelor. Cu toate acestea, până de curând, AWS nu a avut o capacitate încorporată de a gestiona numărul de mașini care rulează de la ECS. ECS a făcut posibilă scalarea numărului de sarcini, de exemplu, în funcție de utilizarea CPU, RAM sau numărul de solicitări. Dar dacă sarcinile au ocupat toate instanțele gratuite, atunci mașinile noi nu au fost create automat.
Acest lucru s-a schimbat odată cu apariția ECS Capacity Providers (ECS CP). Acum fiecare serviciu din ECS poate fi asociat cu un ASG, iar dacă sarcinile nu se potrivesc pe instanțele care rulează, atunci vor fi ridicate altele noi (dar în limitele ASG stabilite). Acest lucru funcționează și în direcția opusă, dacă ECS CP vede instanțe inactive fără sarcini, atunci va da comanda ASG pentru a le închide. ECS CP are capacitatea de a specifica un procent țintă de încărcare a instanței, astfel încât un anumit număr de mașini să fie întotdeauna liber pentru sarcini de scalare rapidă; voi vorbi despre asta puțin mai târziu.
Șabloane de lansare EC2
Ultimul serviciu despre care voi vorbi înainte de a intra în detalii despre crearea acestei infrastructuri este EC2 Launch Templates. Vă permite să creați un șablon conform căruia toate mașinile vor porni, pentru a nu repeta acest lucru de la zero de fiecare dată. Aici puteți selecta tipul de mașină de pornit, grupul de securitate, imaginea discului și mulți alți parametri. De asemenea, puteți specifica datele utilizatorului care vor fi încărcate în toate instanțele lansate. Puteți rula scripturi în datele utilizatorului, de exemplu, puteți edita conținutul unui fișier .
Unul dintre cei mai importanți parametri de configurare pentru acest articol este =adevarat. Dacă acest parametru este activat, atunci de îndată ce ECS primește un semnal că o instanță spot este eliminată, transferă toate sarcinile care lucrează asupra acesteia în starea Scurgere. Nu vor fi alocate sarcini noi acestei instanțe; dacă există sarcini care doresc să fie implementate în ea chiar acum, acestea vor fi anulate. Solicitările de la echilibrator încetează să mai vină. Notificarea ștergerii instanței vine cu 2 minute înainte de evenimentul real. Prin urmare, dacă serviciul dvs. nu efectuează sarcini mai lungi de 2 minute și nu salvează nimic pe disc, atunci puteți utiliza instanțe spot fără a pierde date.
În ceea ce privește discul - AWS recent Este posibil să folosiți Elastic File System (EFS) împreună cu ECS; cu această schemă, nici discul nu este un obstacol, dar nu am încercat acest lucru, deoarece în principiu nu avem nevoie de disc pentru a stoca starea. În mod implicit, după primirea SIGINT (trimis atunci când o sarcină este transferată în starea Scurgere), toate sarcinile care rulează vor fi oprite după 30 de secunde, chiar dacă nu s-au finalizat încă; puteți modifica acest timp utilizând parametrul . Principalul lucru este să nu-l setați mai mult de 2 minute pentru aparatele spot.
Crearea unui serviciu
Să trecem la crearea serviciului descris. În acest proces, voi descrie în plus câteva puncte utile care nu au fost menționate mai sus. În general, aceasta este o instrucțiune pas cu pas, dar nu voi lua în considerare unele cazuri foarte de bază sau, dimpotrivă, foarte specifice. Toate acțiunile sunt efectuate în consola vizuală AWS, dar pot fi reproduse programatic folosind CloudFormation sau Terraform. La Adapty folosim Terraform.
Șablon de lansare EC2
Acest serviciu creează o configurație de mașini care vor fi utilizate. Șabloanele sunt gestionate în secțiunea EC2 -> Instanțe -> Lansare șabloane.
Imaginea mașinii Amazon (AMI) — specificați imaginea de disc cu care vor fi lansate toate instanțele. Pentru ECS, în majoritatea cazurilor merită să folosiți imaginea optimizată de la Amazon. Este actualizat regulat și conține tot ce este necesar pentru ca ECS să funcționeze. Pentru a afla ID-ul actual al imaginii, accesați pagina , selectați regiunea pe care o utilizați și copiați ID-ul AMI pentru aceasta. De exemplu, pentru regiunea us-east-1, ID-ul curent la momentul scrierii este ami-00c7c1cf5bdc913ed. Acest ID trebuie inserat în elementul Specificați o valoare personalizată.
Tipul instanței — indicați tipul instanței. Alege-l pe cel care se potrivește cel mai bine sarcinii tale.
Pereche de chei (autentificare) — specificați un certificat cu care vă puteți conecta la instanță prin SSH, dacă este necesar.
Setari de retea — specificați parametrii rețelei. Platformă de rețea în cele mai multe cazuri ar trebui să existe un Virtual Private Cloud (VPC). Grupuri de securitate — grupuri de securitate pentru instanțele dvs. Deoarece vom folosi un echilibrator în fața instanțelor, recomand să specificați aici un grup care să permită conexiuni de intrare doar de la echilibrator. Adică veți avea 2 grupuri de securitate, unul pentru echilibrator, care permite conexiuni de intrare de oriunde pe porturile 80 (http) și 443 (https), iar al doilea pentru mașini, care permite conexiuni de intrare pe orice porturi din grupul de echilibrare . Conexiunile de ieșire din ambele grupuri trebuie să fie deschise folosind protocolul TCP către toate porturile la toate adresele. Puteți limita porturile și adresele pentru conexiunile de ieșire, dar apoi trebuie să monitorizați în mod constant că nu încercați să accesați ceva pe un port închis.
Stocare (volume) — specificați parametrii discului pentru mașini. Dimensiunea discului nu poate fi mai mică decât cea specificată în AMI; pentru ECS Optimized este de 30 GiB.
Detalii avansate — specificați parametri suplimentari.
Opțiune de cumpărare — dacă vrem să cumpărăm instanțe spot. Vrem, dar nu vom bifa această casetă aici; o vom configura în Auto Scaling Group, există mai multe opțiuni acolo.
Profilul instanței IAM — indicați rolul cu care vor fi lansate instanțele. Pentru ca instanțe să ruleze în ECS, au nevoie de permisiuni, care se găsesc de obicei în rol ecsInstanceRole. În unele cazuri poate fi creat, dacă nu, atunci aici despre cum să faci asta. După creare, îl indicăm în șablon.
În continuare, există mulți parametri, practic puteți lăsa valori implicite peste tot, dar fiecare dintre ei are o descriere clară. Activez întotdeauna instanța optimizată pentru EBS și opțiunile T2/T3 Unlimited dacă sunt folosite instanțe.
Datele utilizatorului — indicați datele utilizatorului. Vom edita fișierul /etc/ecs/ecs.config, care conține configurația agentului ECS.
Un exemplu de cum ar putea arăta datele utilizatorului:
#!/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 — parametrul indică faptul că instanța aparține unui cluster cu numele dat, adică acest cluster își va putea plasa sarcinile pe acest server. Nu am creat încă un cluster, dar vom folosi acest nume atunci când îl creăm.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — parametrul specifică faptul că, atunci când se primește un semnal pentru a opri o instanță spot, toate sarcinile de pe aceasta ar trebui să fie transferate în starea de golire.
ECS_CONTAINER_STOP_TIMEOUT=1m - parametrul specifică că după primirea unui semnal SIGINT, toate sarcinile au 1 minut înainte de a fi ucise.
ECS_ENGINE_AUTH_TYPE=docker — parametrul indică faptul că schema Docker este utilizată ca mecanism de autorizare
ECS_ENGINE_AUTH_DATA=... — parametrii de conectare la registrul privat al containerelor, unde sunt stocate imaginile dvs. Docker. Dacă este public, atunci nu trebuie să specificați nimic.
În scopul acestui articol, voi folosi o imagine publică din Docker Hub, așa că specificați parametrii ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA nu este nevoie.
E bine de știut: Este recomandat să actualizați AMI-ul în mod regulat, deoarece versiunile noi actualizează versiunile de Docker, Linux, agent ECS etc. Pentru a nu uita de acest lucru, puteți despre lansarea de noi versiuni. Puteți primi notificări prin e-mail și actualiza manual, sau puteți scrie o funcție Lambda care va crea automat o nouă versiune de Launch Template cu un AMI actualizat.
EC2 Auto Scaling Group
Auto Scaling Group este responsabil pentru lansarea și scalarea instanțelor. Grupurile sunt gestionate în secțiunea EC2 -> Auto Scaling -> Auto Scaling Groups.
Șablon de lansare — selectați șablonul creat la pasul anterior. Lăsăm versiunea implicită.
Opțiuni de cumpărare și tipuri de instanțe — specificați tipurile de instanțe pentru cluster. Aderarea la șablonul de lansare folosește tipul de instanță din șablonul de lansare. Combinarea opțiunilor de achiziție și a tipurilor de instanțe vă permite să configurați în mod flexibil tipurile de instanțe. O vom folosi.
O bază opțională la cerere — numărul de instanțe obișnuite, non-spot, care vor funcționa întotdeauna.
Procent la cerere peste bază — raport procentual dintre instanțe obișnuite și spot, 50-50 vor fi distribuite în mod egal, 20-80 pentru fiecare instanță obișnuită se vor ridica 4 spot. În sensul acestui exemplu, voi indica 50-50, dar în realitate facem cel mai adesea 20-80, în unele cazuri 0-100.
Tipuri de instanțe — aici puteți specifica tipuri suplimentare de instanțe care vor fi utilizate în cluster. Nu l-am folosit niciodată pentru că nu prea înțeleg sensul poveștii. Poate că acest lucru se datorează limitelor pe anumite tipuri de instanțe, dar acestea pot fi crescute cu ușurință prin suport. Dacă știți aplicația, voi fi bucuros să o citesc în comentarii)
Reţea — setări de rețea, selectați VPC și subrețele pentru mașini, în majoritatea cazurilor ar trebui să selectați toate subrețelele disponibile.
Echilibrarea sarcinii - setările echilibrului, dar vom face acest lucru separat, nu vom atinge nimic aici. Verificări de sănătate va fi de asemenea configurat ulterior.
Mărimea grupului — indicăm limitele numărului de mașini din cluster și numărul dorit de mașini la pornire. Numărul de mașini din cluster nu va fi niciodată mai mic decât minimul specificat și mai mare decât maximul, chiar dacă scalarea ar trebui să aibă loc în funcție de metrici.
Politici de scalare — parametrii de scalare, dar vom scala în funcție de sarcinile ECS care rulează, așa că vom configura scalarea mai târziu.
Protecție la scalare a instanțelor — protecția instanțelor împotriva ștergerii la reducere. Îl activăm astfel încât ASG să nu ștergă mașina care are sarcini în execuție. ECS Capacity Provider va dezactiva protecția pentru cazurile care nu au sarcini.
Adaugă etichete — puteți specifica etichete pentru instanțe (pentru aceasta, caseta de selectare Etichetare instanțe noi trebuie bifată). Recomand să specificați eticheta Name, apoi toate instanțele care sunt lansate în cadrul grupului vor avea același nume și este convenabil să le vizualizați în consolă.
După crearea grupului, deschideți-l și accesați secțiunea Configurații avansate.De ce nu sunt vizibile toate opțiunile în consolă în etapa de creare.
Politici de reziliere — reguli care sunt luate în considerare la ștergerea instanțelor. Se aplică în ordine. De obicei le folosim pe cele din imaginea de mai jos. În primul rând, sunt șterse instanțele cu cel mai vechi șablon de lansare (de exemplu, dacă am actualizat AMI, am creat o nouă versiune, dar toate instanțele au reușit să treacă la el). Apoi sunt selectate cazurile care sunt cele mai apropiate de următoarea oră de facturare. Și apoi cele mai vechi sunt selectate în funcție de data lansării.
E bine de știut: pentru a actualiza toate mașinile dintr-un cluster, ușor de utilizat . Dacă combinați acest lucru cu funcția Lambda de la pasul anterior, veți avea un sistem de actualizare a instanțelor complet automatizat. Înainte de a actualiza toate mașinile, trebuie să dezactivați protecția de scalare a instanțelor pentru toate instanțele din grup. Nu configurație în grup, ci protecție împotriva mașinilor în sine, aceasta se face în fila Gestionare instanțe.
Aplicație Load Balancer și EC2 Target Group
Echilibratorul este creat în secțiunea EC2 → Load Balancing → Load Balancers. Vom folosi Application Load Balancer; o comparație a diferitelor tipuri de echilibrare poate fi citită la .
ascultătorii - are sens să faceți porturile 80 și 443 și să redirecționați de la 80 la 443 folosind regulile de echilibrare mai târziu.
Zonele de disponibilitate — în majoritatea cazurilor, selectăm zone de accesibilitate pentru toată lumea.
Configurați setările de securitate — aici este indicat certificatul SSL pentru echilibrator, cea mai convenabilă opțiune este în ACM. Despre diferente Politică de securitate poate fi citit în , îl puteți lăsa selectat în mod implicit ELBSecurityPolicy-2016-08. După ce ați creat echilibrul, îl veți vedea Numele DNS, de care trebuie să configurați CNAME pentru domeniul dvs. De exemplu, așa arată în Cloudflare.
Grupul de securitate — creați sau selectați un grup de securitate pentru echilibrator, am scris mai multe despre asta chiar mai sus în secțiunea EC2 Launch Template → Network settings.
Grup țintă — creăm un grup care este responsabil de direcționarea cererilor de la echilibrator către mașini și de verificarea disponibilității acestora pentru a le înlocui în caz de probleme. Tipul țintei trebuie să fie Instanță, Protocol и Port oricare, dacă utilizați HTTPS pentru comunicarea între echilibrator și instanțe, atunci trebuie să încărcați un certificat la acestea. În scopul acestui exemplu, nu vom face acest lucru, pur și simplu vom părăsi portul 80.
Verificări de sănătate — parametrii pentru verificarea funcționalității serviciului. Într-un serviciu real, aceasta ar trebui să fie o solicitare separată care implementează părți importante ale logicii de afaceri; în scopul acestui exemplu, voi lăsa setările implicite. În continuare, puteți selecta intervalul de solicitare, timeout, codurile de succes etc. În exemplul nostru, vom indica codurile de succes 200-399, deoarece imaginea Docker care va fi folosită returnează un cod 304.
Înregistrați ținte — aici sunt selectate mașinile pentru grup, dar în cazul nostru acest lucru va fi făcut de ECS, așa că omitem doar acest pas.
E bine de știut: la nivel de echilibrare puteți activa jurnalele care vor fi salvate în S3 într-o anumită perioadă . De acolo pot fi exportate către servicii terțe pentru analiză sau puteți face interogări SQL direct pe datele din S3 cu . Este convenabil și funcționează fără niciun cod suplimentar. De asemenea, recomand configurarea eliminării buștenilor din găleată S3 după o anumită perioadă de timp.
Definirea sarcinii ECS
În pașii anteriori, am creat tot ce ține de infrastructura de servicii; acum trecem la descrierea containerelor pe care le vom lansa. Acest lucru se face în secțiunea ECS → Definiții sarcini.
Compatibilitate tip lansare - selectați EC2.
Rolul IAM de execuție a sarcinilor - alege ecsTaskExecutionRole. Folosind-o, se scriu jurnalele, se oferă acces la variabile secrete etc.
În secțiunea Definiții container, faceți clic pe Adăugare container.
Imagine — link la imagine cu codul proiectului; pentru acest exemplu voi folosi o imagine publică din Docker Hub .
Limite de memorie — limitele de memorie pentru container. Limită dură — limită rigidă, dacă containerul depășește valoarea specificată, comanda docker kill va fi executată, containerul va muri imediat. Limită moale — limită moale, containerul poate depăși valoarea specificată, dar acest parametru va fi luat în considerare la plasarea sarcinilor pe mașini. De exemplu, dacă o mașină are 4 GiB de RAM, iar limita soft a unui container este de 2048 MiB, atunci această mașină poate avea maximum 2 sarcini de rulare cu acest container. În realitate, 4 GiB de RAM este puțin mai puțin de 4096 MiB, acest lucru poate fi vizualizat în fila Instanțe ECS din cluster. Limita soft nu poate fi mai mare decât limita dura. Este important să înțelegeți că, dacă există mai multe containere într-o singură sarcină, atunci limitele lor sunt însumate.
Mapări porturi - în Port gazdă Indicăm 0, asta înseamnă că portul va fi alocat dinamic și va fi monitorizat de Grupul țintă. Port container — portul pe care rulează aplicația dvs. este adesea specificat în comanda de execuție sau atribuit în codul aplicației dvs., Dockerfile etc. Pentru exemplul nostru vom folosi 3000 deoarece este listat în imaginea folosită.
Control medical — parametrii de verificare a stării containerului, care nu trebuie confundați cu cei configurați în Grupul țintă.
Mediu inconjurator - setări de mediu. unități CPU - similar cu Limitele de memorie, doar despre procesor. Fiecare nucleu de procesor este de 1024 de unități, așa că dacă serverul are un procesor dual-core și containerul este setat la 512, atunci 4 sarcini cu acest container pot fi lansate pe un server. Unitățile CPU corespund întotdeauna numărului de nuclee; nu poate fi puțin mai puțin, așa cum este cazul memoriei.
Comandă — o comandă pentru a porni un serviciu în interiorul unui container, toți parametrii sunt specificați separați prin virgule. Acesta ar putea fi gunicorn, npm etc. Dacă nu este specificată, va fi utilizată valoarea directivei CMD din Dockerfile. Indicăm npm,start.
Variabile de mediu — variabilele de mediu ale containerului. Acestea pot fi fie date simple text, fie variabile secrete de la sau .
Stocare și înregistrare — aici vom configura înregistrarea în CloudWatch Logs (un serviciu pentru jurnalele de la AWS). Pentru a face acest lucru, activați caseta de selectare Auto-configure CloudWatch Logs. După crearea definiției sarcinii, un grup de jurnale va fi creat automat în CloudWatch. În mod implicit, jurnalele sunt stocate în el pe termen nelimitat; vă recomand să schimbați perioada de păstrare de la Never Expire la perioada necesară. Acest lucru se face în grupurile CloudWatch Log, trebuie să faceți clic pe perioada curentă și să selectați una nouă.
ECS Cluster și ECS Capacity Provider
Accesați secțiunea ECS → Clustere pentru a crea un cluster. Selectăm EC2 Linux + Networking ca șablon.
Numele clusterului - foarte important, facem aici același nume cu cel specificat în parametrul Launch Template ECS_CLUSTER, în cazul nostru - DemoApiClusterProd. Bifați caseta de selectare Creați un cluster gol. Opțional, puteți activa Container Insights pentru a vedea valorile pentru servicii în CloudWatch. Dacă ați făcut totul corect, atunci în secțiunea Instanțe ECS veți vedea mașini care au fost create în grupul Auto Scaling.
Accesați fila Furnizori de capacitate și creați unul nou. Permiteți-mi să vă reamintesc că este necesar să controlați crearea și oprirea mașinilor în funcție de numărul de sarcini ECS care rulează. Este important de reținut că un furnizor poate fi alocat doar unui grup.
Grup Auto Scaling — selectați grupul creat anterior.
Scalare gestionată — activați-l astfel încât furnizorul să poată scala serviciul.
Capacitate țintă % — de ce procent de mașini încărcate cu sarcini avem nevoie. Dacă specificați 100%, atunci toate mașinile vor fi întotdeauna ocupate cu sarcini de rulare. Dacă specificați 50%, atunci jumătate din mașini vor fi întotdeauna gratuite. În acest caz, dacă există un salt brusc de încărcare, taxiurile noi vor ajunge imediat la mașini libere, fără a fi nevoie să aștepte ca instanțe să fie desfășurate.
Protecție de terminare gestionată — activați, acest parametru permite furnizorului să elimine protecția instanțelor împotriva ștergerii. Acest lucru se întâmplă atunci când nu există sarcini active pe mașină și permite Capacitatea țintă%.
Serviciu ECS și configurare de scalare
Ultimul pas :) Pentru a crea un serviciu, trebuie să mergeți la clusterul creat anterior din fila Servicii.
Tip de lansare — trebuie să faceți clic pe Comutare la strategia furnizorului de capacitate și să selectați furnizorii creați anterior.
Definiția sarcinii — selectați definiția sarcinii create anterior și revizuirea acesteia.
Numele serviciului — pentru a evita confuzia, indicăm întotdeauna același lucru cu definiția sarcinii.
Tip de serviciu - întotdeauna Replica.
Numărul de sarcini — numărul dorit de sarcini active în serviciu. Acest parametru este controlat prin scalare, dar trebuie încă specificat.
Procentul minim de sănătate и Procent maxim — determinarea comportamentului sarcinilor în timpul desfășurării. Valorile implicite sunt 100 și 200, ceea ce indică faptul că, în momentul implementării, numărul de sarcini va crește de mai multe ori, apoi va reveni la valoarea dorită. Dacă aveți 1 sarcină care rulează, min=0 și max=100, atunci în timpul implementării va fi ucisă, iar după aceea va fi ridicată una nouă, adică va fi timp de nefuncționare. Dacă rulează 1 sarcină, min=50, max=150, atunci implementarea nu se va întâmpla deloc, deoarece 1 sarcină nu poate fi împărțită la jumătate sau mărită de o dată și jumătate.
Tip de implementare — lăsați actualizarea Rolling.
Șabloane de plasare — reguli pentru plasarea sarcinilor pe mașini. Valoarea implicită este AZ Balanced Spread - aceasta înseamnă că fiecare sarcină nouă va fi plasată pe o instanță nouă până când mașinile din toate zonele de disponibilitate vor crește. De obicei facem BinPack - CPU și Spread - AZ; cu această politică, sarcinile sunt plasate cât mai dens posibil pe o singură mașină per CPU. Dacă este necesar să se creeze o nouă mașină, aceasta este creată într-o nouă zonă de disponibilitate.
Tip echilibrator de sarcină — selectați Aplicație Load Balancer.
Rolul IAM de serviciu - alege ecsServiceRole.
Numele echilibratorului de încărcare — selectați echilibrul creat anterior.
Perioada de grație pentru verificarea sănătății — faceți o pauză înainte de a efectua verificări de sănătate după lansarea unei noi sarcini, de obicei o setăm la 60 de secunde.
Container pentru echilibrarea încărcăturii — în elementul Nume grup țintă, selectați grupul creat anterior și totul va fi completat automat.
Serviciu Auto Scaling — parametrii de scalare a serviciului. Selectați Configure Service Auto Scaling pentru a ajusta numărul dorit al serviciului dvs. Am stabilit numărul minim și maxim de sarcini la scalare.
Rolul IAM pentru Service Auto Scaling - alege AWSServiceRoleForApplicationAutoScaling_ECSService.
Politici de scalare automată a sarcinilor — reguli de scalare. Există 2 tipuri:
- Urmărirea țintei — urmărirea valorilor țintă (utilizarea CPU/RAM sau numărul de solicitări pentru fiecare sarcină). De exemplu, dorim ca sarcina medie a procesorului să fie de 85%, când aceasta devine mai mare, se vor adăuga noi sarcini până când va atinge valoarea țintă. Dacă sarcina este mai mică, atunci sarcinile vor fi eliminate, dimpotrivă, dacă nu este activată protecția împotriva reducerii (Dezactivați scalarea).
- Scalare în trepte - reacția la un eveniment arbitrar. Aici puteți configura o reacție la orice eveniment (CloudWatch Alarm), atunci când are loc, puteți adăuga sau elimina numărul specificat de sarcini sau specifica numărul exact de sarcini.
Un serviciu poate avea mai multe reguli de scalare, acest lucru poate fi util, principalul lucru este să vă asigurați că nu intră în conflict unul cu celălalt.
Concluzie
Dacă ați urmat instrucțiunile și ați folosit aceeași imagine Docker, serviciul dvs. ar trebui să returneze o pagină ca aceasta.
- Am creat un șablon conform căruia sunt lansate toate mașinile din serviciu. De asemenea, am învățat cum să actualizăm mașinile atunci când șablonul se schimbă.
- Am configurat procesarea semnalului de oprire a instanței spot, astfel încât, într-un minut de la primirea acestuia, toate sarcinile care rulează sunt eliminate din mașină, astfel încât nimic nu este pierdut sau întrerupt.
- Am ridicat balansierul pentru a distribui sarcina uniform pe mașini.
- Am creat un serviciu care rulează pe instanțe spot, care reduce costurile mașinii de aproximativ 3 ori.
- Am configurat scalarea automată în ambele direcții pentru a face față sarcinilor de lucru crescute fără a implica costuri de nefuncționare.
- Folosim Capacity Provider astfel încât aplicația să gestioneze infrastructura (mașini) și nu invers.
- Suntem grozavi.
Dacă aveți vârfuri previzibile de încărcare, de exemplu, faceți publicitate într-o campanie mare de e-mail, puteți configura scalarea prin .
De asemenea, puteți scala pe baza datelor din diferite părți ale sistemului dvs. De exemplu, avem funcționalitatea utilizatorii aplicației mobile. Uneori, o campanie este trimisă la peste 1 milion de persoane. După o astfel de distribuție, există întotdeauna o creștere mare a solicitărilor către API, deoarece mulți utilizatori se conectează la aplicație în același timp. Deci, dacă vedem că în coadă există mult mai mulți indicatori standard pentru trimiterea notificărilor push promoționale, putem lansa imediat mai multe mașini și sarcini suplimentare pentru a fi gata de încărcare.
Mă voi bucura dacă îmi spuneți în comentarii cazuri interesante de utilizare a instanțelor spot și ECS sau ceva despre scalare.
În curând vor apărea articole despre modul în care procesăm mii de evenimente analitice pe secundă pe o stivă predominant fără server (cu bani) și despre cum funcționează implementarea serviciilor folosind GitLab CI și Terraform Cloud.
Abonați-vă la noi, va fi interesant!
Numai utilizatorii înregistrați pot participa la sondaj. , Vă rog.
Folosiți instanțe spot în producție?
-
22,2%Da6
-
66,7%Nr.18
-
11,1%Am aflat despre ele dintr-un articol și plănuiesc să le folosesc3
Au votat 27 utilizatori. 5 utilizatori s-au abținut.
Sursa: www.habr.com