{"id":87393,"date":"2020-07-08T01:42:02","date_gmt":"2020-07-07T23:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws"},"modified":"2020-07-08T01:42:02","modified_gmt":"2020-07-07T23:42:02","slug":"sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/sozdanie-masshtabiruemogo-api-na-spotovyh-instansah-aws","title":{"rendered":"Crearea unui API scalabil pe instan\u021be spot AWS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bun\u0103 ziua tuturor! M\u0103 numesc Kirill, sunt CTO la Adapty. O mare parte din arhitectura noastr\u0103 se afl\u0103 pe AWS, iar ast\u0103zi v\u0103 voi povesti despre cum am redus costurile cu serverele de 3 ori prin utilizarea instan\u021belor spot \u00een mediu de produc\u021bie, precum \u0219i despre cum s\u0103 le configur\u0103m pentru auto-scalare. \u00cen primul r\u00e2nd, va fi o prezentare general\u0103 despre cum func\u021bioneaz\u0103, iar apoi un ghid detaliat pentru implementare.<\/p>\n

<\/p>\n

Ce sunt instan\u021bele spot?<\/h2>\n

<\/p>\n

Instan\u021bele<\/a><\/noindex> spot sunt servere ale altor utilizatori AWS, care \u00een prezent sunt inactive \u0219i le v\u00e2nd cu reduceri mari (Amazon afirm\u0103 p\u00e2n\u0103 la 90%, dar din experien\u021ba noastr\u0103 ~3x, variind \u00een func\u021bie de regiune, AZ \u0219i tipul de instan\u021b\u0103). Principalul lor dezavantaj \u00een compara\u021bie cu cele obi\u0219nuite este c\u0103 se pot opri \u00een orice moment. De aceea, mult timp am considerat c\u0103 utilizarea lor \u00een medii de dezvoltare este acceptabil\u0103, sau pentru calcule, p\u0103str\u00e2nd rezultatele intermediare pe S3 sau \u00eentr-o baz\u0103 de date, dar nu \u00een produc\u021bie. Exist\u0103 solu\u021bii ter\u021be care permit utilizarea spot-urilor \u00een produc\u021bie, dar pentru cazul nostru implic\u0103 multe compromisuri, a\u0219a c\u0103 nu le-am implementat. Abordarea descris\u0103 \u00een articol func\u021bioneaz\u0103 pe deplin \u00een cadrul func\u021bionalit\u0103\u021bilor standard AWS, f\u0103r\u0103 scripturi suplimentare, cron-uri etc.<\/p>\n

<\/a><\/noindex><\/p>\n

Mai jos sunt c\u00e2teva capturi de ecran care arat\u0103 istoricul pre\u021burilor pentru instan\u021bele spot.<\/p>\n

<\/p>\n

m5.large \u00een regiunea eu-west-1 (Irlanda). Pre\u021bul a fost \u00een mare parte stabil timp de 3 luni, \u00een prezent economisind 2.9x.<\/p>\n

<\/p>\n

\"Crearea<\/p>\n

<\/p>\n

m5.large \u00een regiunea us-east-1 (N. Virginia). Pre\u021bul variaz\u0103 continuu de-a lungul a 3 luni, \u00een prezent economisind \u00eentre 2.3x \u0219i 2.8x, \u00een func\u021bie de zona de disponibilitate.<\/p>\n

<\/p>\n

\"Crearea<\/p>\n

<\/p>\n

t3.small \u00een regiunea us-east-1 (N. Virginia). Pre\u021bul este stabil timp de 3 luni, \u00een prezent economisind 3.4x.<\/p>\n

<\/p>\n

\"Crearea<\/p>\n

<\/p>\n

Arhitectura serviciului<\/h2>\n

<\/p>\n

Arhitectura de baz\u0103 a serviciului despre care vom discuta \u00een acest articol este ilustrat\u0103 \u00een diagrama de mai jos.<\/p>\n

<\/p>\n

\"Crearea<\/p>\n

<\/p>\n

Application Load Balancer \u2192 EC2 Target Group \u2192 Elastic Container Service<\/h3>\n

<\/p>\n

Ca echilibror de sarcin\u0103, se folose\u0219te Application Load Balancer (ALB), care trimite cererile c\u0103tre EC2 Target Group (TG). TG are responsabilitatea de a deschide porturile pentru instan\u021be pentru ALB \u0219i de a le lega de porturile containerelor Elastic Container Service (ECS). ECS este un echivalent al Kubernetes pe AWS, care se ocup\u0103 cu managementul containerelor Docker.<\/p>\n

<\/p>\n

Pe un instan\u021b\u0103 pot exista mai multe containere active cu acelea\u0219i porturi, a\u0219a c\u0103 nu putem s\u0103 le stabilim fix. ECS informeaz\u0103 TG c\u0103 lanseaz\u0103 o nou\u0103 sarcin\u0103 (denumit\u0103 pod \u00een terminologia Kubernetes), aceasta verific\u0103 porturile disponibile pe instan\u021b\u0103 \u0219i aloc\u0103 unul dintre ele pentru sarcina lansat\u0103. De asemenea, TG verific\u0103 \u00een mod regulat dac\u0103 instan\u021ba \u0219i API-ul de pe aceasta func\u021bioneaz\u0103 prin health check \u0219i, \u00een cazul \u00een care observ\u0103 probleme, \u00eenceteaz\u0103 s\u0103 trimit\u0103 cereri acolo.<\/p>\n

<\/p>\n

EC2 Auto Scaling Groups + ECS Capacity Providers<\/h3>\n

<\/p>\n

\u00cen diagrama de mai sus nu este prezentat serviciul EC2 Auto Scaling Groups (ASG). Din denumire se poate \u00een\u021belege c\u0103 se ocup\u0103 de scalarea instan\u021belor. P\u00e2n\u0103 de cur\u00e2nd, AWS nu avea o capacitate \u00eencorporat\u0103 de a gestiona num\u0103rul de ma\u0219ini lansate din ECS. ECS permitea scalarea num\u0103rului de sarcini, de exemplu, \u00een func\u021bie de utilizarea CPU, RAM sau de num\u0103rul de cereri. Dar dac\u0103 sarcinile ocupau toate instan\u021bele disponibile, nu erau lansate automat ma\u0219ini noi.<\/p>\n

<\/p>\n

Aceasta s-a schimbat odat\u0103 cu apari\u021bia ECS Capacity Providers (ECS CP). Acum, fiecare serviciu din ECS poate fi legat de ASG, iar dac\u0103 sarcinile nu se \u00eencadreaz\u0103 pe instan\u021bele active, vor fi lansate ma\u0219ini noi (dar \u00een limitele stabilite de ASG). Acest lucru func\u021bioneaz\u0103 \u0219i \u00een sens invers; dac\u0103 ECS CP observ\u0103 instan\u021be idle f\u0103r\u0103 sarcini, va comanda ASG s\u0103 le opreasc\u0103. ECS CP are capacitatea de a specifica un procent \u021bint\u0103 de utilizare a instan\u021belor, astfel \u00eenc\u00e2t un anumit num\u0103r de ma\u0219ini s\u0103 fie \u00eentotdeauna liber pentru scalarea rapid\u0103 a sarcinilor, voi detalia acest aspect mai t\u00e2rziu.<\/p>\n

<\/p>\n

EC2 Launch Templates<\/h3>\n

<\/p>\n

Ultimul serviciu despre care voi vorbi \u00eenainte de a trece la detalii despre cum se creeaz\u0103 aceast\u0103 infrastructur\u0103 este EC2 Launch Templates. Acesta permite crearea unui \u0219ablon conform c\u0103ruia vor fi lansate toate ma\u0219inile, pentru a nu repeta procesul de la zero de fiecare dat\u0103. Aici po\u021bi alege tipul ma\u0219inii lansate, grupul de securitate, imaginea discului \u0219i multe alte parametri. De asemenea, po\u021bi specifica datele utilizatorului, care vor fi instalate pe toate instan\u021bele lansate. \u00cen datele utilizatorului se pot rula scripturi, de exemplu, se poate edita con\u021binutul fi\u0219ierului configura\u021biei agentului ECS<\/a><\/noindex>.<\/p>\n

<\/p>\n

Unul dintre parametrii cei mai importan\u021bi \u00een cadrul acestui articol este ECS_ENABLE_SPOT_INSTANCE_DRAINING<\/a><\/noindex>=true. Dac\u0103 acest parametru este activat, de \u00eendat\u0103 ce ECS prime\u0219te semnalul c\u0103 instan\u021ba spot este retras\u0103, toate sarcinile care func\u021bioneaz\u0103 pe aceasta vor fi mutate \u00een statusul Draining. Nici o sarcin\u0103 nou\u0103 nu va fi alocat\u0103 acestei instan\u021be, iar dac\u0103 exist\u0103 sarcini care doresc s\u0103 fie desf\u0103\u0219urate pe ea, acestea vor fi anulate. Solicit\u0103rile de la echilibratorul de sarcin\u0103 vor \u00eenceta s\u0103 mai vin\u0103. Notificarea despre eliminarea instan\u021bei vine cu dou\u0103 minute \u00eenainte de evenimentul efectiv. A\u0219adar, dac\u0103 serviciul dvs. nu \u00eendepline\u0219te sarcini mai mult de 2 minute \u0219i nu salveaz\u0103 nimic pe disc, pute\u021bi utiliza instan\u021be spot f\u0103r\u0103 pierderi de date.<\/p>\n

<\/p>\n

\u00cen ceea ce prive\u0219te discul \u2014 AWS a f\u0103cut recent posibil\u0103<\/a><\/noindex> utilizarea Elastic File System (EFS) \u00eempreun\u0103 cu ECS, cu acest sistem chiar discul nu reprezint\u0103 o barier\u0103, dar nu am \u00eencercat acest lucru, deoarece, \u00een principiu, nu avem nevoie de disc pentru a stoca starea. \u00cen mod implicit, dup\u0103 primirea SIGINT (trimis \u00een momentul mut\u0103rii sarcinii \u00een statusul Draining), toate sarcinile active vor fi oprite \u00een 30 de secunde, chiar dac\u0103 nu au reu\u0219it s\u0103 finalizeze, aceast\u0103 perioad\u0103 poate fi modificat\u0103 cu ajutorul parametrului ECS_CONTAINER_STOP_TIMEOUT<\/a><\/noindex>. Este esen\u021bial s\u0103 nu \u00eel seta\u021bi mai mare de 2 minute pentru ma\u0219inile spot.<\/p>\n

<\/p>\n

Crearea serviciului<\/h2>\n

<\/p>\n

S\u0103 trecem direct la crearea serviciului descris. \u00cen timpul procesului, voi descrie c\u00e2teva puncte utile suplimentare despre care nu s-a men\u021bionat anterior. \u00cen general, aceasta este o instruc\u021biune pas cu pas, dar nu voi considera unele cazuri foarte de baz\u0103 sau, dimpotriv\u0103, foarte specifice. Toate ac\u021biunile sunt efectuate \u00een consola vizual\u0103 AWS, dar pot fi reproduse programatic folosind CloudFormation sau Terraform. \u00cen Adapty, utiliz\u0103m Terraform.<\/p>\n

<\/p>\n

\u0218ablon de lansare EC2<\/strong><\/h3>\n

<\/p>\n

\u00cen acest serviciu, se creeaz\u0103 o configura\u021bie a ma\u0219inilor care vor fi utilizate. Managementul \u0219abloanelor se desf\u0103\u0219oar\u0103 \u00een sec\u021biunea EC2 -> Instan\u021be -> \u0218abloane de lansare.<\/p>\n

<\/p>\n

Imaginea de ma\u0219in\u0103 Amazon (AMI)<\/strong> \u2014 specific\u0103m imaginea discului cu care vor fi lansate toate instan\u021bele. Pentru ECS, \u00een cele mai multe cazuri, este recomandat s\u0103 folosi\u021bi o imagine optimizat\u0103 de la Amazon. Aceasta este actualizat\u0103 regulat \u0219i con\u021bine tot ce este necesar pentru func\u021bionarea ECS. Pentru a afla ID-ul actual al imaginii, acces\u0103m pagina AMIs optimizate pentru Amazon ECS<\/a><\/noindex>, alegem regiunea utilizat\u0103 \u0219i copiem ID-ul AMI pentru aceasta. De exemplu, pentru regiunea us-east-1, ID-ul actual la momentul scrierii acestui articol este ami-00c7c1cf5bdc913ed<\/em>. Acest ID trebuie introdus \u00een sec\u021biunea Specifica\u021bi o valoare personalizat\u0103.<\/p>\n

<\/p>\n

Tipul instan\u021bei<\/strong> \u2014 specifica\u021bi tipul instan\u021bei. Alege\u021bi-l pe cel care se potrive\u0219te cel mai bine nevoilor dumneavoastr\u0103.<\/p>\n

<\/p>\n

Cheie de acces (login)<\/strong> \u2014 specifica\u021bi certificatul prin care v\u0103 pute\u021bi conecta la instan\u021b\u0103 prin SSH, dac\u0103 este necesar.<\/p>\n

<\/p>\n

Set\u0103rile re\u021belei<\/strong> \u2014 specifica\u021bi parametrii de re\u021bea. Platforma de re\u021bea<\/strong> \u00een majoritatea cazurilor ar trebui s\u0103 fie Cloud Privat Virtual (VPC). Grupuri de securitate<\/strong> \u2014 grupuri de securitate pentru instan\u021bele dumneavoastr\u0103. Deoarece vom utiliza un balansor \u00eenaintea instan\u021belor, recomand s\u0103 specifica\u021bi aici un grup care permite conexiuni de s\u0103n\u0103tate doar de la balansor. Astfel, ve\u021bi avea 2 grupuri de securitate, unul pentru balansor, care permite conexiuni de intrare (inbound) din toate sursele pe porturile 80 (http) \u0219i 443 (https), iar al doilea pentru ma\u0219ini, care permite conexiuni de intrare pe orice port din grupul balansor. Conexiunile de ie\u0219ire (outbound) \u00een ambele grupuri trebuie s\u0103 fie deschise pe protocol TCP pentru toate porturile c\u0103tre toate adresele. Pute\u021bi restric\u021biona porturile \u0219i adresele pentru conexiunile de ie\u0219ire, dar \u00een acest caz trebuie s\u0103 monitoriza\u021bi constant pentru a v\u0103 asigura c\u0103 nu \u00eencerca\u021bi s\u0103 accesa\u021bi ceva pe un port \u00eenchis.<\/p>\n

<\/p>\n

Stocare (volum)<\/strong> \u2014 specifica\u021bi parametrii discurilor pentru ma\u0219ini. Dimensiunea discului nu poate fi mai mic\u0103 dec\u00e2t cea specificat\u0103 \u00een AMI, pentru ECS Optimized \u2014 30 GiB.<\/p>\n

<\/p>\n

Detalii avansate<\/strong> \u2014 specifica\u021bi parametrii suplimentari.<\/p>\n

<\/p>\n

Op\u021biunea de achizi\u021bie<\/strong> \u2014 dorim s\u0103 achizi\u021bion\u0103m instan\u021be spot. Vrem, dar nu vom bifa aceast\u0103 op\u021biune aici, o vom configura \u00een Grupul de Auto Scaling, acolo sunt mai multe op\u021biuni.<\/p>\n

<\/p>\n

Profilul de instan\u021b\u0103 IAM<\/strong> \u2014 specifica\u021bi rolul cu care vor fi lansate instan\u021bele. Pentru ca instan\u021bele s\u0103 func\u021bioneze \u00een ECS, au nevoie de permisiuni, care de obicei sunt incluse \u00een rolul ecsInstanceRole<\/em>. \u00cen unele cazuri, acesta poate fi creat; dac\u0103 nu, aici instruc\u021biunea<\/a><\/noindex> sunt informa\u021bii despre cum s\u0103 face\u021bi asta. Dup\u0103 crearea sa, specifica\u021bi-l \u00een \u0219ablon.
\nUrmeaz\u0103 multe parametrii, \u00een general, majoritatea pot fi l\u0103sate la valorile implicite, dar fiecare dintre ele are o descriere clar\u0103. Eu \u00eentotdeauna includ parametrii instan\u021bei EBS-optimized \u0219i T2\/T3 Unlimited, dac\u0103 sunt utilizate burstable<\/a><\/noindex> instan\u021be.<\/p>\n

<\/p>\n

Date utilizator<\/strong> \u2014 specifica\u021bi datele utilizatorului. Vom edita fi\u0219ierul \/etc\/ecs\/ecs.config<\/code>, \u00een care se afl\u0103 configura\u021bia agentului ECS.
\nExemplu despre cum ar putea ar\u0103ta datele utilizatorului:<\/p>\n

<\/p>\n

#!\/bin\/bash\necho ECS_CLUSTER=DemoApiClusterProd >> \/etc\/ecs\/ecs.config\necho ECS_ENABLE_SPOT_INSTANCE_DRAINING=true >> \/etc\/ecs\/ecs.config\necho ECS_CONTAINER_STOP_TIMEOUT=1m >> \/etc\/ecs\/ecs.config\necho ECS_ENGINE_AUTH_TYPE=docker >> \/etc\/ecs\/ecs.config\necho "ECS_ENGINE_AUTH_DATA={"registry.gitlab.com":{"username":"username","password":"password"}}" >> \/etc\/ecs\/ecs.config<\/code><\/pre>\n
<\/p>\n
ECS_CLUSTER=DemoApiClusterProd<\/code> \u2014 parametrul indic\u0103 faptul c\u0103 instan\u021ba apar\u021bine unui cluster cu numele specificat, adic\u0103 acest cluster va putea desf\u0103\u0219ura sarcinile sale pe acest server. Deocamdat\u0103 nu am creat un cluster, dar la crearea acestuia vom folosi acest nume.<\/p>\n
<\/p>\n
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true<\/code> \u2014 parametrul indic\u0103 faptul c\u0103, la primirea semnalului de oprire a instan\u021bei spot, toate sarcinile de pe aceasta trebuie s\u0103 fie transmise \u00een statutul Draining.<\/p>\n
<\/p>\n
ECS_CONTAINER_STOP_TIMEOUT=1m<\/code> \u2014 parametrul indic\u0103 faptul c\u0103, dup\u0103 primirea semnalului SIGINT, toate sarcinile au la dispozi\u021bie 1 minut \u00eenainte de a fi terminate.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_TYPE=docker<\/code> \u2014 parametrul indic\u0103 faptul c\u0103 se utilizeaz\u0103 schema docker ca mecanism de autorizare.<\/p>\n
<\/p>\n
ECS_ENGINE_AUTH_DATA=...<\/code> \u2014 parametrii de conectare la un registry privat de containere, unde sunt stocate imaginile dvs. Docker. Dac\u0103 este public, nu este necesar s\u0103 specifica\u021bi nimic.<\/p>\n
<\/p>\n
\u00cen cadrul acestui articol, voi folosi o imagine public\u0103 din Docker Hub, a\u0219a c\u0103 nu voi specifica parametrii ECS_ENGINE_AUTH_TYPE<\/code> \u0219i ECS_ENGINE_AUTH_DATA<\/code> nu este necesar.<\/p>\n
<\/p>\n
Util de \u0219tiut<\/strong>: se recomand\u0103 actualizarea regulat\u0103 a AMI-urilor, deoarece \u00een versiunile noi se actualizeaz\u0103 versiunile Docker, Linux, agentul ECS etc. Pentru a nu uita despre acest lucru, pute\u021bi configura notific\u0103ri<\/a><\/noindex> privind lansarea de versiuni noi. Pute\u021bi primi notific\u0103ri pe email \u0219i s\u0103 actualiza\u021bi manual sau pute\u021bi scrie o func\u021bie Lambda care va crea automat o nou\u0103 versiune a \u0219ablonului de lansare cu AMI-ul actualizat.<\/p>\n
<\/p>\n
EC2 Auto Scaling Group<\/strong><\/h3>\n
<\/p>\n
Grupul Auto Scaling este responsabil pentru lansarea \u0219i scalarea instan\u021belor. Managementul grupurilor se face \u00een sec\u021biunea EC2 -> Auto Scaling -> Auto Scaling Groups.<\/p>\n
<\/p>\n
\u0218ablon de lansare<\/strong> \u2014 alegem \u0219ablonul creat la pasul anterior. L\u0103s\u0103m versiunea implicit\u0103.<\/p>\n
<\/p>\n
Op\u021biuni de achizi\u021bie \u0219i tipuri de instan\u021be<\/strong> \u2014 specific\u0103m tipurile de instan\u021be pentru cluster. 'Adhere to launch template' folose\u0219te tipul de instan\u021b\u0103 din \u0219ablonul de lansare. 'Combine purchase options and instance types' permite configurarea flexibil\u0103 a tipurilor de instan\u021be. Vom folosi aceasta.<\/p>\n
<\/p>\n
Baza op\u021bional\u0103 On-Demand<\/strong> \u2014 num\u0103rul de instan\u021be obi\u0219nuite, non-spot, care vor func\u021biona \u00eentotdeauna.<\/p>\n
<\/p>\n
Procentul On-Demand deasupra bazei<\/strong> \u2014 raportul procentual \u00eentre instan\u021bele obi\u0219nuite \u0219i cele spot, 50-50 va distribui la egal, 20-80 pentru fiecare instan\u021b\u0103 obi\u0219nuit\u0103 va ridica 4 instan\u021be spot. \u00cen acest exemplu, voi specifica 50-50, dar \u00een realitate, de cele mai multe ori facem 20-80, \u00een unele cazuri 0-100.<\/p>\n
<\/p>\n
Tipuri de instan\u021be<\/strong> \u2014 aici po\u021bi specifica tipuri suplimentare de instan\u021be care vor fi utilizate \u00een cluster. Nu le-am folosit niciodat\u0103, deoarece nu \u00een\u021beleg foarte bine sensul acestei op\u021biuni. Poate c\u0103 este vorba de limitele pentru anumite tipuri de instan\u021be, dar acestea se pot cre\u0219te u\u0219or prin suport. Dac\u0103 \u0219tii o utilizare, a\u0219 fi bucuros s\u0103 citesc \u00een comentarii)<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Re\u021bea<\/strong> \u2014 set\u0103rile re\u021belei, alegi VPC \u0219i subre\u021bele pentru ma\u0219ini, \u00een cele mai multe cazuri este indicat s\u0103 alegi toate subre\u021belele disponibile.<\/p>\n
<\/p>\n
\u00cenc\u0103rcarea echilibrat\u0103<\/strong> \u2014 set\u0103rile balansoarului, dar vom face asta separat, aici nu intervenim. Controale de s\u0103n\u0103tate<\/strong> se vor configura de asemenea mai t\u00e2rziu.<\/p>\n
<\/p>\n
Dimensiunea grupului<\/strong> \u2014 specific\u0103m limitele pentru num\u0103rul de ma\u0219ini din cluster \u0219i num\u0103rul dorit de ma\u0219ini la \u00eenceput. Num\u0103rul de ma\u0219ini din cluster nu va fi niciodat\u0103 mai mic dec\u00e2t minimul specificat \u0219i nici mai mare dec\u00e2t maximul, chiar dac\u0103 \u00een metrici ar trebui s\u0103 se \u00eent\u00e2mple scalarea.<\/p>\n
<\/p>\n
Politici de scalare<\/strong> \u2014 parametrii de scalare, dar vom scala baz\u00e2ndu-ne pe sarcinile ECS pornite, a\u0219a c\u0103 vom configura scalarea mai t\u00e2rziu.<\/p>\n
<\/p>\n
Protec\u021bia la scalarea instan\u021belor<\/strong> \u2014 protec\u021bia instan\u021belor de \u0219tergere la scalarea descendent\u0103. Activ\u0103m pentru ca ASG s\u0103 nu \u0219tearg\u0103 ma\u0219ina pe care exist\u0103 sarcini active. Dezactivarea protec\u021biei pentru instan\u021bele f\u0103r\u0103 sarcini va fi gestionat\u0103 de ECS Capacity Provider.<\/p>\n
<\/p>\n
Adaug\u0103 etichete<\/strong> \u2014 po\u021bi specifica etichete pentru instan\u021be (pentru aceasta trebuie s\u0103 fie bifat\u0103 op\u021biunea Tag new instances). Recomand s\u0103 specifici eticheta Name, astfel toate instan\u021bele care sunt lansate \u00een cadrul grupului vor avea acela\u0219i nume, ceea ce este convenabil pentru a le vizualiza \u00een consol\u0103.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Dup\u0103 crearea grupului, deschide-l \u0219i acceseaz\u0103 sec\u021biunea Advanced configurations, deoarece \u00een etapa de crea\u021bie nu toate op\u021biunile sunt vizibile \u00een consol\u0103.<\/p>\n
<\/p>\n
Politici de terminare<\/strong> \u2014 reguli care sunt luate \u00een considerare la \u0219tergerea instan\u021belor. Acestea se aplic\u0103 \u00een ordinea specificat\u0103. De obicei, folosim astfel de politici, ca \u00een imaginea de mai jos. Mai \u00eent\u00e2i se \u0219terg instan\u021bele cu cel mai vechi Launch Template (de exemplu, dac\u0103 am actualizat AMI, ne-a fost creat\u0103 o nou\u0103 versiune, dar toate instan\u021bele au avut timp s\u0103 treac\u0103 la aceasta). Apoi, se aleg instan\u021bele care sunt cel mai aproape de urm\u0103toarea or\u0103 de calcul pentru facturare. \u0218i mai departe, se aleg cele mai vechi dup\u0103 data lans\u0103rii.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Util de \u0219tiut<\/strong>: pentru actualizarea tuturor ma\u0219inilor din cluster, este convenabil s\u0103 folose\u0219ti Refresh instan\u021bei<\/a><\/noindex>. Dac\u0103 combina\u021bi acest lucru cu func\u021bia Lambda din pasul anterior, ve\u021bi avea un sistem complet automatizat de actualizare a instan\u021belor. \u00cenainte de a actualiza toate ma\u0219inile, este necesar s\u0103 dezactiva\u021bi protec\u021bia \u00eempotriva scal\u0103rii \u00eenapoi pentru toate instan\u021bele din grup. Nu setarea din grup, ci protec\u021bia de pe ma\u0219ini, se face \u00een tab-ul Management Instan\u021be.<\/p>\n
<\/p>\n
Application Load Balancer \u0219i EC2 Target Group<\/h3>\n
<\/p>\n
Balansorul se creeaz\u0103 \u00een sec\u021biunea EC2 \u2192 Load Balancing \u2192 Load Balancers. Vom folosi Application Load Balancer; compara\u021bia diferitelor tipuri de balansor poate fi citit\u0103 pe pagina serviciului<\/a><\/noindex>.<\/p>\n
<\/p>\n
Listeners<\/strong> \u2014 are sens s\u0103 crea\u021bi porturile 80 \u0219i 443 \u0219i s\u0103 face\u021bi redirec\u021bionare de la 80 la 443 ulterior folosind regulile balansorului.<\/p>\n
<\/p>\n
Availability Zones<\/strong> \u2014 \u00een majoritatea cazurilor alegem toate zonele de disponibilitate.<\/p>\n
<\/p>\n
Configure Security Settings<\/strong> \u2014 aici se specific\u0103 certificatul SSL pentru balansor; cea mai convenabil\u0103 op\u021biune este s\u0103 face\u021bi certificatul<\/a><\/noindex> \u00een ACM. Despre diferen\u021be Security Policy<\/strong> poate fi citit\u0103 \u00een documentation<\/a><\/noindex>, se poate l\u0103sa pe cel ales \u00een mod implicit ELBSecurityPolicy-2016-08<\/code>. Dup\u0103 crearea balansorului, ve\u021bi vedea DNS name<\/strong>, pe care trebuie s\u0103 \u00eel configura\u021bi CNAME pentru domeniul dumneavoastr\u0103. De exemplu, a\u0219a arat\u0103 \u00een Cloudflare.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Security Group<\/strong> \u2014 cre\u0103m sau alegem un grup de securitate pentru balansor; mai multe detalii despre acest lucru am scris mai sus \u00een sec\u021biunea EC2 Launch Template \u2192 Network settings.<\/p>\n
<\/p>\n
Target group<\/strong> \u2014 cre\u0103m un grup care se ocup\u0103 de rutarea cererilor de la balansor c\u0103tre ma\u0219ini \u0219i verific\u0103 disponibilitatea acestora, pentru a le \u00eenlocui \u00een caz de probleme. Target type<\/strong> trebuie s\u0103 fie Instance, Protocol<\/strong> \u0219i Port<\/strong> orice, dac\u0103 utiliza\u021bi HTTPS pentru comunicarea \u00eentre balansor \u0219i instan\u021be, atunci pe acestea trebuie s\u0103 \u00eenc\u0103rca\u021bi certificatul. \u00cen cadrul acestui exemplu, nu vom face asta, ci vom l\u0103sa pur \u0219i simplu portul 80.<\/p>\n
<\/p>\n
Controale de s\u0103n\u0103tate<\/strong> \u2014 parametrii de verificare a disponibilit\u0103\u021bii serviciului. \u00cen acest serviciu, acesta ar trebui s\u0103 fie un apel separat, care realizeaz\u0103 p\u0103r\u021bi importante din logica de afaceri; \u00een cadrul acestui exemplu, voi l\u0103sa set\u0103rile implicite. Apoi, se poate alege intervalul de cereri, timeout-ul, codurile de r\u0103spuns de succes etc. \u00cen exemplul nostru, vom specifica codurile de succes 200-399, deoarece imaginea Docker care va fi utilizat\u0103 returneaz\u0103 codul 304.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Register Targets<\/strong> \u2014 aici se aleg ma\u0219inile pentru grup, dar \u00een cazul nostru acest lucru va fi gestionat de ECS, a\u0219a c\u0103 vom s\u0103ri peste acest pas.<\/p>\n
<\/p>\n
Util de \u0219tiut<\/strong>: la nivelul balansorului se pot activa jurnalele, care vor fi salvate \u00een S3 \u00eentr-un anumit interval. \u00een formatul<\/a><\/noindex>. De acolo pot fi exportate \u00een servicii externe pentru analize, sau se pot realiza interog\u0103ri SQL direct pe datele din S3 cu ajutorul lui Athena<\/a><\/noindex>. Este convenabil \u0219i func\u021bioneaz\u0103 f\u0103r\u0103 cod suplimentar. De asemenea, recomand configurarea \u0219tergerii jurnalelor din bucket-ul S3 dup\u0103 o anumit\u0103 perioad\u0103 de timp.<\/p>\n
<\/p>\n
Defini\u021bia sarcinii ECS<\/h3>\n
<\/p>\n
\u00cen pa\u0219ii anteriori am creat tot ce \u021bine de infrastructura serviciului, acum trecem la descrierea containerelor pe care le vom lansa. Aceasta se face \u00een sec\u021biunea ECS \u2192 Defini\u021bii de sarcin\u0103.<\/p>\n
<\/p>\n
Compatibilitatea tipului de lansare<\/strong> \u2014 alegem EC2.<\/p>\n
<\/p>\n
Rolul IAM pentru executarea sarcinii<\/strong> \u2014 alegem ecsTaskExecutionRole<\/code>. Cu ajutorul acesta se scriu jurnalele, se ofer\u0103 acces la variabilele secrete etc.<\/p>\n
<\/p>\n
\u00cen sec\u021biunea Defini\u021bii de container, facem clic pe Adaug\u0103 container.<\/p>\n
<\/p>\n
Imagine<\/strong> \u2014 link c\u0103tre imaginea cu codul proiectului, \u00een cadrul acestui exemplu voi folosi o imagine public\u0103 de pe Docker Hub bitnami\/node-example:0.0.1<\/a><\/noindex>.<\/p>\n
<\/p>\n
Limitele de memorie<\/strong> \u2014 limitele de memorie pentru container. Limita dur\u0103<\/strong> \u2014 limit\u0103 dur\u0103, dac\u0103 containerul dep\u0103\u0219e\u0219te valoarea specificat\u0103, comanda docker kill va fi executat\u0103, containerul va \u00eenceta imediat s\u0103 func\u021bioneze. Limita moale<\/strong> \u2014 limit\u0103 moale, containerul poate dep\u0103\u0219i valoarea specificat\u0103, dar la plasarea sarcinilor pe ma\u0219ini va fi luat \u00een considerare acest parametru. De exemplu, dac\u0103 pe ma\u0219in\u0103 sunt 4 GiB de memorie RAM, iar limita moale a containerului este de 2048 MiB, atunci pe aceast\u0103 ma\u0219in\u0103 pot fi maximum 2 sarcini lansate cu acest container. \u00cen realitate, 4 GiB de memorie RAM sunt pu\u021bin mai pu\u021bin dec\u00e2t 4096 MiB, acest lucru poate fi v\u0103zut \u00een tab-ul ECS Instances din cluster. Limita moale nu poate fi mai mare dec\u00e2t limita dur\u0103. Este important de \u00een\u021beles c\u0103, dac\u0103 \u00eentr-o sarcin\u0103 exist\u0103 mai multe containere, limitele lor se cumuleaz\u0103.<\/p>\n
<\/p>\n
Map\u0103rile de porturi<\/strong> \u2014 \u00een Portul gazd\u0103<\/strong> indic\u0103m 0, ceea ce \u00eenseamn\u0103 c\u0103 portul va fi atribuit dinamic, acesta va fi monitorizat de Grupul \u021bint\u0103. Portul containerului<\/strong> \u2014 portul pe care ruleaz\u0103 aplica\u021bia dumneavoastr\u0103, adesea este specificat \u00een comanda de execu\u021bie, sau este atribuit \u00een codul aplica\u021biei dumneavoastr\u0103, Dockerfile etc. Pentru exemplul nostru folosim 3000, deoarece este specificat \u00een Dockerfile<\/a><\/noindex> imaginea folosit\u0103.<\/p>\n
<\/p>\n
Verificarea st\u0103rii de s\u0103n\u0103tate<\/strong> \u2014 parametrii pentru verificarea func\u021bionalit\u0103\u021bii containerului, nu trebuie confundat cu cel care este configurat \u00een Grupul \u021bint\u0103.<\/p>\n
<\/p>\n
Mediu<\/strong> \u2014 set\u0103rile de mediu. Unit\u0103\u021bi CPU<\/strong> \u2014 asem\u0103n\u0103tor cu limitele de memorie, doar c\u0103 se refer\u0103 la procesor. Fiecare nucleu de procesor reprezint\u0103 1024 unit\u0103\u021bi, a\u0219a c\u0103 dac\u0103 serverul are un procesor cu dou\u0103 nuclee, iar valoarea setat\u0103 pentru container este 512, atunci pe un server pot fi rulate 4 sarcini cu acest container. Unit\u0103\u021bile CPU corespund \u00eentotdeauna num\u0103rului de nuclee, nu pot fi pu\u021bin mai pu\u021bine, ca \u00een cazul memoriei.<\/p>\n
<\/p>\n
Comand\u0103<\/strong> \u2014 comanda pentru a lansa un serviciu \u00een interiorul containerului, toate parametrii sunt specifica\u021bi prin virgul\u0103. Acesta poate fi gunicorn, npm etc. Dac\u0103 nu este specificat, se va folosi valoarea directivei CMD din Dockerfile. Specific\u0103m npm,start<\/code>.<\/p>\n
<\/p>\n
Variabile de mediu<\/strong> \u2014 variabilele de mediu ale containerului. Acestea pot fi at\u00e2t date textuale simple, c\u00e2t \u0219i variabile secrete din Secrets Manager<\/a><\/noindex> sau Parameter Store<\/a><\/noindex>.<\/p>\n
<\/p>\n
Stocare \u0219i Jurnalizare<\/strong> \u2014 aici vom configura jurnalizarea \u00een CloudWatch Logs (serviciul de log-uri de la AWS). Pentru aceasta, este suficient s\u0103 activ\u0103m op\u021biunea Auto-configure CloudWatch Logs. Dup\u0103 ce se creeaz\u0103 Task Definition, se va crea automat un grup de loguri \u00een CloudWatch. \u00cen mod implicit, logurile sunt stocate acolo pentru totdeauna, recomand s\u0103 schimbi perioada de reten\u021bie din Never Expire la perioada dorit\u0103. Acest lucru se face \u00een grupurile de loguri CloudWatch, trebuie s\u0103 dai clic pe perioada curent\u0103 \u0219i s\u0103 alegi una nou\u0103.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
ECS Cluster \u0219i ECS Capacity Provider<\/h3>\n
<\/p>\n
Trecem \u00een sec\u021biunea ECS \u2192 Clusters pentru a crea un cluster. Ca \u0219ablon alegem EC2 Linux + Networking.<\/p>\n
<\/p>\n
Numele cluster-ului<\/strong> \u2014 foarte important, facem aici un nume similar cu cel specificat \u00een Launch Template \u00een parametrul ECS_CLUSTER<\/code>, \u00een cazul nostru \u2014 DemoApiClusterProd<\/code>. Bif\u0103m op\u021biunea Create an empty cluster. Op\u021bional, putem activa Container Insights pentru a vedea metricile serviciilor \u00een CloudWatch. Dac\u0103 ai f\u0103cut totul corect, atunci \u00een sec\u021biunea ECS Instances vei vedea ma\u0219inile care au fost create \u00een grupul Auto Scaling.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Trecem la pesta Provideri de capacitate<\/strong> \u0219i cre\u0103m unul nou. Reamintesc c\u0103 acesta este necesar pentru a gestiona crearea \u0219i oprirea ma\u0219inilor \u00een func\u021bie de num\u0103rul de sarcini ECS active. Este important de men\u021bionat c\u0103 provider-ul poate fi legat doar de un singur grup.<\/p>\n
<\/p>\n
Grup Auto Scaling<\/strong> \u2014 alegem grupul creat anterior.<\/p>\n
<\/p>\n
Scalare gestionat\u0103<\/strong> \u2014 activ\u0103m, astfel \u00eenc\u00e2t providerul s\u0103 poat\u0103 scala serviciul.<\/p>\n
<\/p>\n
Capacitate \u021bint\u0103 %<\/strong> \u2014 ce procent din \u00eenc\u0103rcarea ma\u0219inilor cu sarcini ne este necesar. Dac\u0103 specific\u0103m 100%, atunci toate ma\u0219inile vor fi \u00eentotdeauna ocupate cu sarcini active. Dac\u0103 specific\u0103m 50%, atunci jum\u0103tate dintre ma\u0219ini vor fi \u00eentotdeauna libere. \u00cen acest caz, dac\u0103 apare o cre\u0219tere brusc\u0103 a \u00eenc\u0103rc\u0103turii, noile sarcini se vor direc\u021biona imediat c\u0103tre ma\u0219inile libere, f\u0103r\u0103 a fi nevoie s\u0103 a\u0219tepte desf\u0103\u0219urarea instan\u021belor.<\/p>\n
<\/p>\n
Protec\u021bie gestionat\u0103 la finalizare<\/strong> \u2014 activat, acest parametru permite providerului s\u0103 elimine protec\u021bia instan\u021belor de la \u0219tergere. Aceasta se \u00eent\u00e2mpl\u0103 atunci c\u00e2nd nu exist\u0103 sarcini active pe ma\u0219in\u0103 \u0219i permite procentajul de capacitate \u021bint\u0103 %.<\/p>\n
<\/p>\n
Serviciul ECS \u0219i configurarea scal\u0103rii<\/h3>\n
<\/p>\n
Pasul final:) Pentru a crea un serviciu, trebuie s\u0103 accesa\u021bi clusterul creat anterior \u00een tab-ul Services.<\/p>\n
<\/p>\n
Tip de lansare<\/strong> \u2014 trebuie s\u0103 face\u021bi clic pe Switch to capacity provider strategy \u0219i s\u0103 alege\u021bi providerul creat anterior.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Defini\u021bia sarcinii<\/strong> \u2014 alegem Defini\u021bia sarcinii creat\u0103 anterior \u0219i revizia acesteia.<\/p>\n
<\/p>\n
Numele serviciului<\/strong> \u2014 pentru a nu ne confunda, \u00eentotdeauna indic\u0103m acela\u0219i nume ca la Defini\u021bia sarcinii.<\/p>\n
<\/p>\n
Tipul serviciului<\/strong> \u2014 \u00eentotdeauna Replica.<\/p>\n
<\/p>\n
Num\u0103rul de sarcini<\/strong> \u2014 num\u0103rul dorit de sarcini active \u00een serviciu. Acest parametru este gestionat prin scalare, dar tot trebuie s\u0103 fie specificat.<\/p>\n
<\/p>\n
Procentajul minim s\u0103n\u0103tos<\/strong> \u0219i Procentaj maxim<\/strong> \u2014 definesc comportamentul sarcinilor \u00een timpul desf\u0103\u0219ur\u0103rii. Valorile implicite sunt 100 \u0219i 200, ceea ce \u00eenseamn\u0103 c\u0103, \u00een momentul desf\u0103\u0219ur\u0103rii, num\u0103rul de sarcini va cre\u0219te de dou\u0103 ori, iar apoi va reveni la forma dorit\u0103. Dac\u0103 ave\u021bi 1 sarcin\u0103, min=0, iar max=100, atunci \u00een timpul desf\u0103\u0219ur\u0103rii aceasta va fi eliminat\u0103, iar apoi va fi pornit\u0103 o nou\u0103, adic\u0103 va exista o perioad\u0103 de inactivitate. Dac\u0103 lucreaz\u0103 1 sarcin\u0103, min=50, max=150, atunci desf\u0103\u0219urarea nu va avea loc, deoarece nu se poate \u00eemp\u0103r\u021bi o sarcin\u0103 \u00een dou\u0103 sau cre\u0219te cu 50%.<\/p>\n
<\/p>\n
Tip de desf\u0103\u0219urare<\/strong> \u2014 l\u0103s\u0103m Rolling update.<\/p>\n
<\/p>\n
\u0218abloane de plasare<\/strong> \u2014 reguli de plasare a sarcinilor pe ma\u0219ini. Implicit este setat AZ Balanced Spread \u2014 aceasta \u00eenseamn\u0103 c\u0103 fiecare nou\u0103 sarcin\u0103 va fi plasat\u0103 pe o nou\u0103 instan\u021b\u0103 p\u00e2n\u0103 c\u00e2nd ma\u0219inile din toate zonele de disponibilitate sunt pornite. De obicei facem BinPack \u2014 CPU \u0219i Spread \u2014 AZ, \u00een aceast\u0103 politic\u0103 sarcinile sunt plasate c\u00e2t mai compact posibil pe o singur\u0103 ma\u0219in\u0103 pe CPU. Dac\u0103 este necesar s\u0103 se creeze o nou\u0103 ma\u0219in\u0103, aceasta se va crea \u00eentr-o nou\u0103 zon\u0103 de disponibilitate.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Tip de balansare a sarcinilor<\/strong> \u2014 alegem Application Load Balancer.<\/p>\n
<\/p>\n
Rol IAM al serviciului<\/strong> \u2014 alegem ecsServiceRole<\/code>.<\/p>\n
<\/p>\n
Numele balansorului de sarcini<\/strong> \u2014 alegem balansorul creat anterior.<\/p>\n
<\/p>\n
Perioada de gra\u021bie pentru verificarea st\u0103rii<\/strong> \u2014 pauz\u0103 \u00eenainte de a efectua verific\u0103rile de func\u021bionalitate dup\u0103 desf\u0103\u0219urarea unei noi sarcini, de obicei, set\u0103m 60 de secunde.<\/p>\n
<\/p>\n
Container pentru balansarea sarcinilor<\/strong> \u2014 \u00een punctul Numele grupului \u021bint\u0103 alegem grupul creat anterior, iar totul se va completa automat.<\/p>\n
<\/p>\n
\"Crearea<\/p>\n
<\/p>\n
Scalarea automat\u0103 a serviciului<\/strong> \u2014 parametrii de scalare ai serviciului. Alegem Configure Service Auto Scaling to adjust your service\u2019s desired count. Set\u0103m num\u0103rul minim \u0219i maxim de sarcini la scalare.<\/p>\n
<\/p>\n
Rol IAM pentru scalarea automat\u0103 a serviciului<\/strong> \u2014 alegem AWSServiceRoleForApplicationAutoScaling_ECSService<\/code>.<\/p>\n
<\/p>\n
Politici automate de scalare a sarcinilor<\/strong> \u2014 reguli pentru scalare. Exist\u0103 2 tipuri:<\/p>\n
<\/p>\n
    \n
  1. Urm\u0103rirea obiectivelor<\/strong> \u2014 urm\u0103rirea metricii \u021bint\u0103 (utilizarea CPU\/RAM sau num\u0103rul de cereri pentru fiecare task). De exemplu, dorim ca \u00eenc\u0103rcarea medie a procesorului s\u0103 fie de 85%. Atunci c\u00e2nd aceasta dep\u0103\u0219e\u0219te acest prag, vor fi ad\u0103ugate noi task-uri p\u00e2n\u0103 c\u00e2nd se va ajunge la valoarea \u021bint\u0103. Dac\u0103 \u00eenc\u0103rcarea este mai mic\u0103, atunci task-urile vor fi eliminate, cu condi\u021bia ca protec\u021bia \u00eempotriva scal\u0103rii \u00een jos s\u0103 nu fie activat\u0103 (Dezactiveaz\u0103 scalarea \u00een jos<\/strong>).<\/li>\n
  2. Scaling pas cu pas<\/strong> \u2014 reac\u021bia la un eveniment aleatoriu. Aici po\u021bi configura reac\u021bia la orice eveniment (Alarm\u0103 CloudWatch), atunci c\u00e2nd acesta se \u00eent\u00e2mpl\u0103, po\u021bi ad\u0103uga sau elimina un num\u0103r specific de task-uri, sau po\u021bi specifica exact c\u00e2te task-uri s\u0103 fie.<\/li>\n<\/ol>\n
    <\/p>\n
    Serviciul poate avea mai multe reguli de scalare, ceea ce poate fi util, \u00eens\u0103 este important s\u0103 te asiguri c\u0103 acestea nu intr\u0103 \u00een conflict \u00eentre ele.<\/p>\n
    <\/p>\n
    Concluzie<\/h2>\n
    <\/p>\n
    Dac\u0103 ai urmat instruc\u021biunile \u0219i ai folosit aceea\u0219i imagine Docker, serviciul t\u0103u ar trebui s\u0103 returneze o astfel de pagin\u0103.<\/p>\n
    <\/p>\n
    \"Crearea<\/p>\n
    <\/p>\n
      \n
    1. Am creat un \u0219ablon pe care se desf\u0103\u0219oar\u0103 toate ma\u0219inile din serviciu. De asemenea, am \u00eenv\u0103\u021bat s\u0103 actualiz\u0103m ma\u0219inile atunci c\u00e2nd \u0219ablonul se schimb\u0103.<\/li>\n
    2. Am configurat gestionarea semnalului de oprire a instan\u021bei spot, astfel \u00eenc\u00e2t \u00een decurs de un minut de la primirea acestuia, toate task-urile active sunt eliminate de pe ma\u0219in\u0103, astfel \u00eenc\u00e2t nimic nu se pierde \u0219i nu se \u00eentrerupe.<\/li>\n
    3. Am ales un balancer de \u00eenc\u0103rcare pentru a distribui uniform sarcina \u00eentre ma\u0219ini.<\/li>\n
    4. Am creat un serviciu care func\u021bioneaz\u0103 pe instan\u021be spot, reduc\u00e2nd astfel costurile pentru ma\u0219ini de aproximativ 3 ori.<\/li>\n
    5. Am configurat auto-scaling \u00een ambele direc\u021bii pentru a gestiona cre\u0219terea sarcinilor, \u00eens\u0103 \u00een acela\u0219i timp pentru a nu pl\u0103ti pentru timpul de inactivitate.<\/li>\n
    6. Folosim Capacity Provider pentru ca aplica\u021bia s\u0103 gestioneze infrastructura (ma\u0219inile), nu invers.<\/li>\n
    7. Suntem buni.<\/li>\n<\/ol>\n
      <\/p>\n
      Dac\u0103 ai cre\u0219teri previzibile ale sarcinii, de exemplu, c\u00e2nd te promovezi printr-o mare campanie de email, po\u021bi configura scalarea pe program<\/a><\/noindex>.<\/p>\n
      <\/p>\n
      De asemenea, po\u021bi efectua scalarea pe baza datelor din diferite p\u0103r\u021bi ale sistemului t\u0103u. De exemplu, avem o func\u021bionalitate de trimitere a ofertelor promo\u021bionale personalizate<\/a><\/noindex> utilizatorii aplica\u021biei mobile. Uneori campania este trimis\u0103 c\u0103tre peste 1M de persoane. Dup\u0103 o astfel de expediere, se observ\u0103 \u00eentotdeauna o cre\u0219tere semnificativ\u0103 a cererilor API, deoarece mul\u021bi utilizatori acceseaz\u0103 aplica\u021bia simultan. A\u0219adar, dac\u0103 vedem c\u0103 \u00een coada pentru trimiterea notific\u0103rilor promo\u021bionale sunt mult mai multe dec\u00e2t indicatorii standard, putem imediat s\u0103 lans\u0103m c\u00e2teva ma\u0219ini \u0219i sarcini suplimentare pentru a fi preg\u0103ti\u021bi pentru \u00eenc\u0103rcare.<\/p>\n
      <\/p>\n
      A\u0219 fi bucuros dac\u0103 a\u021bi \u00eemp\u0103rt\u0103\u0219i \u00een comentarii cazuri interesante de utilizare a instan\u021belor spot \u0219i ECS sau orice altceva despre scalare.<\/p>\n
      <\/p>\n
      \u00cen cur\u00e2nd vor ap\u0103rea articole despre cum proces\u0103m mii de evenimente analitice pe secund\u0103 pe un stack \u00een mare parte serverless (cu fonduri) \u0219i cum func\u021bioneaz\u0103 implementarea serviciilor folosind GitLab CI \u0219i Terraform Cloud.<\/p>\n
      <\/p>\n
      Abona\u021bi-v\u0103 la noi, va fi interesant!<\/p>\n
      Numai utilizatorii \u00eenregistra\u021bi pot participa la sondaj. Conecta\u021bi-v\u0103<\/a><\/noindex>, v\u0103 rug\u0103m.<\/p>\n
      Folosi\u021bi instan\u021be spot \u00een produc\u021bie?<\/h2>\n