Hola a tots! Em dic Kirill, sóc CTO d'Adapty. La major part de la nostra arquitectura està a AWS i avui parlaré de com vam reduir els costos del servidor en 3 vegades mitjançant l'ús d'instàncies puntuals en un entorn de producció, així com de com configurar-ne l'escalat automàtic. Primer hi haurà una visió general de com funciona, i després instruccions detallades per començar.
Què són les instàncies puntuals?
les instàncies són servidors d'altres usuaris d'AWS que actualment estan inactius i els venen amb un gran descompte (Amazon escriu fins a un 90%, segons la nostra experiència ~ 3x, varia segons la regió, l'AZ i el tipus d'instància). La seva principal diferència amb els habituals és que es poden apagar en qualsevol moment. Per això, durant molt de temps vam creure que era normal utilitzar-los per a entorns verges, o per a tasques de càlcul d'alguna cosa, amb resultats intermedis guardats a S3 o a la base de dades, però no per a vendes. Hi ha solucions de tercers que permeten utilitzar espots en producció, però hi ha moltes crosses per al nostre cas, així que no les vam implementar. L'enfocament descrit a l'article funciona completament dins de la funcionalitat estàndard d'AWS, sense scripts addicionals, corones, etc.
A continuació es mostren algunes captures de pantalla que mostren l'historial de preus de les instàncies puntuals.
m5.gran a la regió eu-west-1 (Irlanda). El preu ha estat majoritàriament estable durant 3 mesos, actualment estalviant 2.9 vegades.
m5.gran a la regió us-east-1 (N. Virgínia). El preu canvia constantment durant 3 mesos, actualment s'estalvia de 2.3x a 2.8x depenent de la zona de disponibilitat.
t3.small a la regió us-east-1 (N. Virgínia). El preu ha estat estable durant 3 mesos, actualment s'estalvia 3.4 vegades.
Arquitectura de serveis
L'arquitectura bàsica del servei de la qual parlarem en aquest article es mostra al diagrama següent.
Aplicació Load Balancer → EC2 Target Group → Elastic Container Service
L'Application Load Balancer (ALB) s'utilitza com a equilibrador, que envia sol·licituds al grup objectiu (TG) d'EC2. TG és responsable d'obrir ports a les instàncies per als ALB i connectar-los als ports dels contenidors Elastic Container Service (ECS). ECS és un anàleg de Kubernetes a AWS, que gestiona contenidors Docker.
Una instància pot tenir diversos contenidors en execució amb els mateixos ports, de manera que no els podem configurar de manera fixa. ECS diu a TG que està llançant una tasca nova (en terminologia de Kubernetes això s'anomena pod), comprova si hi ha ports lliures a la instància i n'assigna un a la tasca llançada. TG també comprova regularment si la instància i l'API hi treballen mitjançant la comprovació de salut i, si veu algun problema, deixa d'enviar sol·licituds allà.
EC2 Auto Scaling Groups + Proveïdors de capacitat ECS
El diagrama anterior no mostra el servei EC2 Auto Scaling Groups (ASG). Pel nom es pot entendre que és responsable d'escalar les instàncies. Tanmateix, fins fa poc, AWS no tenia una capacitat integrada per gestionar el nombre de màquines en funcionament des d'ECS. ECS va permetre escalar el nombre de tasques, per exemple, per l'ús de la CPU, la memòria RAM o el nombre de peticions. Però si les tasques ocupaven totes les instàncies gratuïtes, llavors no es van crear màquines noves automàticament.
Això ha canviat amb l'arribada dels ECS Capacity Providers (ECS CP). Ara, cada servei d'ECS es pot associar a un ASG, i si les tasques no s'ajusten a les instàncies en execució, se'n generaran de noves (però dins dels límits ASG establerts). Això també funciona en la direcció oposada, si ECS CP veu instàncies inactives sense tasques, donarà l'ordre ASG per tancar-les. ECS CP té la capacitat d'especificar un percentatge objectiu de càrrega de la instància, de manera que un cert nombre de màquines sempre estiguin lliures per a les tasques d'escalat ràpid; en parlaré una mica més endavant.
Plantilles de llançament EC2
L'últim servei del qual parlaré abans d'entrar en detalls sobre la creació d'aquesta infraestructura és EC2 Launch Templates. Permet crear una plantilla segons la qual començaran totes les màquines, per no repetir-ho des de zero cada vegada. Aquí podeu seleccionar el tipus de màquina per iniciar, el grup de seguretat, la imatge del disc i molts altres paràmetres. També podeu especificar les dades d'usuari que es penjaran a totes les instàncies llançades. Podeu executar scripts a les dades d'usuari, per exemple, podeu editar el contingut d'un fitxer .
Un dels paràmetres de configuració més importants d'aquest article és = cert. Si aquest paràmetre està habilitat, tan bon punt l'ECS rep un senyal que s'està eliminant una instància puntual, transfereix totes les tasques que hi treballen a l'estat d'esgotament. No s'assignarà cap tasca nova a aquesta instància; si hi ha tasques que es vulguin implementar ara mateix, es cancel·laran. Les peticions de l'equilibrador també deixen de venir. La notificació de la supressió de la instància arriba 2 minuts abans de l'esdeveniment real. Per tant, si el vostre servei no realitza tasques de més de 2 minuts i no desa res al disc, podeu utilitzar instàncies puntuals sense perdre dades.
Pel que fa al disc - AWS recentment És possible utilitzar el Elastic File System (EFS) juntament amb ECS; amb aquest esquema, fins i tot el disc no és un obstacle, però no ho vam provar, ja que en principi no necessitem el disc per emmagatzemar l'estat. Per defecte, després de rebre SIGINT (s'envia quan una tasca es transfereix a l'estat d'esgotament), totes les tasques en execució s'aturaran al cap de 30 segons, encara que encara no s'hagin completat; podeu canviar aquest temps mitjançant el paràmetre . El més important és no configurar-lo durant més de 2 minuts per a màquines puntuals.
Creació d'un servei
Passem a la creació del servei descrit. Durant el procés, també descriuré diversos punts útils que no s'han esmentat anteriorment. En general, aquesta és una instrucció pas a pas, però no consideraré alguns casos molt bàsics o, per contra, molt concrets. Totes les accions es realitzen a la consola visual d'AWS, però es poden reproduir mitjançant programació mitjançant CloudFormation o Terraform. A Adapty fem servir Terraform.
Plantilla de llançament EC2
Aquest servei crea una configuració de màquines que s'utilitzaran. Les plantilles es gestionen a la secció EC2 -> Instàncies -> Llançar plantilles.
Imatge de màquina d'Amazon (AMI) — especifiqueu la imatge de disc amb la qual s'iniciaran totes les instàncies. Per a ECS, en la majoria dels casos val la pena utilitzar la imatge optimitzada d'Amazon. S'actualitza regularment i conté tot el necessari perquè ECS funcioni. Per esbrinar l'identificador de la imatge actual, aneu a la pàgina , seleccioneu la regió que utilitzeu i copieu-ne l'ID AMI. Per exemple, per a la regió us-east-1, l'identificador actual en el moment d'escriure és ami-00c7c1cf5bdc913ed. Aquest identificador s'ha d'inserir a l'element Especifica un valor personalitzat.
Tipus d'instància - indicar el tipus d'instància. Trieu el que millor s'adapti a la vostra tasca.
Parell de claus (inici de sessió) — especifiqueu un certificat amb el qual us podeu connectar a la instància mitjançant SSH, si cal.
Configuració de xarxa — Especifiqueu els paràmetres de xarxa. Plataforma de treball en xarxa en la majoria dels casos hauria d'haver un núvol privat virtual (VPC). Grups de seguretat — grups de seguretat per a les vostres instàncies. Com que utilitzarem un equilibrador davant les instàncies, recomano especificar aquí un grup que permeti connexions entrants només des de l'equilibrador. És a dir, tindreu 2 grups de seguretat, un per a l'equilibrador, que permet connexions entrants des de qualsevol punt dels ports 80 (http) i 443 (https), i el segon per a màquines, que permet connexions entrants a qualsevol port del grup d'equilibri. . Les connexions de sortida d'ambdós grups s'han d'obrir mitjançant el protocol TCP a tots els ports a totes les adreces. Podeu limitar els ports i les adreces per a les connexions sortints, però llavors heu de controlar constantment que no intenteu accedir a alguna cosa en un port tancat.
Emmagatzematge (volums) — Especifiqueu els paràmetres del disc per a les màquines. La mida del disc no pot ser inferior a l'especificada a l'AMI; per a ECS Optimized és de 30 GiB.
Detalls avançats — Especifiqueu paràmetres addicionals.
Opció de compra — si volem comprar instàncies puntuals. Volem, però no marcarem aquesta casella aquí; la configurarem al grup Auto Scaling, hi ha més opcions.
Perfil d'instància IAM — indicar la funció amb la qual es posaran en marxa les instàncies. Perquè les instàncies s'executin a ECS, necessiten permisos, que normalment es troben al rol ecsInstanceRole. En alguns casos es pot crear, si no, aquí sobre com fer-ho. Després de la creació, ho indiquem a la plantilla.
A continuació, hi ha molts paràmetres, bàsicament podeu deixar els valors per defecte a tot arreu, però cadascun d'ells té una descripció clara. Sempre habilito la instància optimitzada per EBS i les opcions T2/T3 Unlimited si s'utilitzen instàncies.
Dades de l'usuari - indicar les dades de l'usuari. Editarem el fitxer /etc/ecs/ecs.config, que conté la configuració de l'agent ECS.
Un exemple de com poden ser les dades d'usuari:
#!/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 — el paràmetre indica que la instància pertany a un clúster amb el nom donat, és a dir, aquest clúster podrà col·locar les seves tasques en aquest servidor. Encara no hem creat un clúster, però utilitzarem aquest nom en crear-lo.
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true — el paràmetre especifica que quan es rep un senyal per desactivar una instància puntual, totes les tasques d'aquesta s'han de transferir a l'estat d'esgotament.
ECS_CONTAINER_STOP_TIMEOUT=1m - el paràmetre especifica que després de rebre un senyal SIGINT, totes les tasques tenen 1 minut abans de ser eliminades.
ECS_ENGINE_AUTH_TYPE=docker — el paràmetre indica que s'utilitza l'esquema Docker com a mecanisme d'autorització
ECS_ENGINE_AUTH_DATA=... — paràmetres de connexió al registre de contenidors privat, on s'emmagatzemen les imatges de Docker. Si és públic, no cal que especifiqueu res.
Als efectes d'aquest article, utilitzaré una imatge pública de Docker Hub, així que especifiqueu els paràmetres ECS_ENGINE_AUTH_TYPE и ECS_ENGINE_AUTH_DATA no cal
El que convé saber: Es recomana actualitzar l'AMI regularment, perquè les noves versions actualitzen versions de Docker, Linux, agent ECS, etc. Per no oblidar-ho, podeu sobre el llançament de noves versions. Podeu rebre notificacions per correu electrònic i actualitzar manualment, o podeu escriure una funció Lambda que crearà automàticament una nova versió de Launch Template amb una AMI actualitzada.
Grup EC2 Auto Scaling
Auto Scaling Group és responsable de llançar i escalar les instàncies. Els grups es gestionen a la secció EC2 -> Auto Scaling -> Auto Scaling Groups.
Plantilla de llançament — seleccioneu la plantilla creada al pas anterior. Deixem la versió per defecte.
Opcions de compra i tipus d'instàncies — Especifiqueu els tipus d'instàncies per al clúster. La plantilla d'adhesió a llançament utilitza el tipus d'instància de la plantilla de llançament. Combinar opcions de compra i tipus d'instàncies us permet configurar de manera flexible els tipus d'instàncies. La farem servir.
Base opcional sota demanda — el nombre d'instàncies regulars i no puntuals que sempre funcionaran.
Percentatge sota demanda per sobre de la base — ràtio percentual d'instàncies regulars i puntuals, 50-50 es repartiran a parts iguals, 20-80 per cada instància regular s'elevaran 4 punts puntuals. Als efectes d'aquest exemple, indicaré 50-50, però en realitat sovint fem 20-80, en alguns casos 0-100.
Tipus d'instància — aquí podeu especificar tipus addicionals d'instàncies que s'utilitzaran al clúster. Mai el vam utilitzar perquè no entenc realment el significat de la història. Potser això es deu als límits de tipus específics d'instàncies, però es poden augmentar fàcilment mitjançant el suport. Si coneixeu l'aplicació, estaré encantada de llegir-la als comentaris)
Xarxa — configuració de xarxa, seleccioneu VPC i subxarxes per a les màquines; en la majoria dels casos, hauríeu de seleccionar totes les subxarxes disponibles.
Equilibri de càrregues - configuració de l'equilibrador, però ho farem per separat, aquí no tocarem res. Revisions de salut també es configurarà més endavant.
Mida del grup — indiquem els límits del nombre de màquines del clúster i el nombre desitjat de màquines a l'inici. El nombre de màquines del clúster mai serà inferior al mínim especificat i superior al màxim, fins i tot si l'escala s'ha de produir segons les mètriques.
Polítiques d'escala — paràmetres d'escala, però escalarem en funció de les tasques ECS en execució, de manera que configurarem l'escalat més endavant.
Protecció d'escala d'instàncies — protecció de les instàncies contra la supressió quan es redueix l'escala. L'activem perquè ASG no esborri la màquina que té tasques en execució. ECS Capacity Provider desactivarà la protecció per a les instàncies que no tinguin tasques.
Afegeix etiquetes — podeu especificar etiquetes per a instàncies (per a això, s'ha de marcar la casella de selecció Etiquetar noves instàncies). Us recomano que especifiqueu l'etiqueta de nom, aleshores totes les instàncies que es llancen dins del grup tindran el mateix nom i és convenient veure-les a la consola.
Després de crear el grup, obriu-lo i aneu a la secció Configuracions avançades Per què no totes les opcions són visibles a la consola en l'etapa de creació.
Polítiques de terminació — regles que es tenen en compte a l'hora de suprimir instàncies. S'apliquen en ordre. Normalment fem servir els de la imatge següent. En primer lloc, se suprimeixen les instàncies amb la plantilla de llançament més antiga (per exemple, si actualitzem l'AMI, vam crear una versió nova, però totes les instàncies van aconseguir canviar-hi). A continuació, es seleccionen les instàncies més properes a la següent hora de facturació. I després es seleccionen els més antics en funció de la data de llançament.
El que convé saber: per actualitzar totes les màquines d'un clúster, fàcil d'utilitzar . Si ho combineu amb la funció Lambda del pas anterior, tindreu un sistema d'actualització d'instàncies totalment automatitzat. Abans d'actualitzar totes les màquines, heu de desactivar la protecció d'escala-in de les instàncies per a totes les instàncies del grup. No la configuració al grup, sinó la protecció de les mateixes màquines, això es fa a la pestanya Gestió d'instàncies.
Aplicació Load Balancer i EC2 Target Group
L'equilibrador es crea a la secció EC2 → Balanç de càrrega → Equilibradors de càrrega. Utilitzarem Application Load Balancer; es pot llegir una comparació de diferents tipus d'equilibradors a .
Oients - Té sentit fer els ports 80 i 443 i redirigir del 80 al 443 mitjançant regles d'equilibrador més endavant.
Zones de disponibilitat — en la majoria dels casos, seleccionem zones d'accessibilitat per a tothom.
Configura la configuració de seguretat — aquí s'indica el certificat SSL de l'equilibrador, l'opció més convenient és en ACM. Sobre les diferències Política de seguretat es pot llegir , podeu deixar-lo seleccionat per defecte ELBSecurityPolicy-2016-08. Després de crear l'equilibrador, el veureu Nom DNS, que necessiteu per configurar el CNAME per al vostre domini. Per exemple, així es veu a Cloudflare.
Grup de seguretat — creeu o seleccioneu un grup de seguretat per a l'equilibrador, vaig escriure més sobre això just més amunt a la secció Plantilla de llançament EC2 → Configuració de xarxa.
Grup objectiu — creem un grup que s'encarrega d'enviar les peticions de l'equilibrador a les màquines i comprovar-ne la disponibilitat per substituir-les en cas de problemes. Tipus d’objectiu ha de ser una instància, Protocol и Port qualsevol, si feu servir HTTPS per a la comunicació entre l'equilibrador i les instàncies, haureu de carregar-hi un certificat. Als efectes d'aquest exemple, no ho farem, simplement deixarem el port 80.
Revisions de salut — paràmetres per comprovar la funcionalitat del servei. En un servei real, aquesta hauria de ser una sol·licitud independent que implementi parts importants de la lògica empresarial; per als propòsits d'aquest exemple, deixaré la configuració predeterminada. A continuació, podeu seleccionar l'interval de sol·licitud, el temps d'espera, els codis d'èxit, etc. En el nostre exemple, indicarem els codis d'èxit 200-399, perquè la imatge Docker que s'utilitzarà retorna un codi 304.
Registre objectius — aquí es seleccionen els cotxes per al grup, però en el nostre cas això ho farà ECS, així que ens ometem aquest pas.
El que convé saber: al nivell d'equilibrador podeu habilitar registres que es desaran a S3 en un cert temps . Des d'allà es poden exportar a serveis de tercers per a l'anàlisi, o podeu fer consultes SQL directament a les dades a S3 amb . És convenient i funciona sense cap codi addicional. També recomano configurar l'eliminació de registres del cub S3 després d'un període de temps especificat.
Definició de la tasca ECS
En els passos anteriors hem creat tot allò relacionat amb la infraestructura del servei; ara passem a la descripció dels contenidors que llançarem. Això es fa a la secció ECS → Definicions de tasques.
Compatibilitat de tipus de llançament - seleccioneu EC2.
Funció IAM d'execució de tasques - triar ecsTaskExecutionRole. Utilitzant-lo, s'escriuen registres, es dóna accés a variables secretes, etc.
A la secció Definicions del contenidor, feu clic a Afegeix un contenidor.
Imatge — enllaça a la imatge amb el codi del projecte; per a aquest exemple faré servir una imatge pública de Docker Hub .
Límits de memòria — límits de memòria per al contenidor. Límit dur — Límit dur, si el contenidor supera el valor especificat, s'executarà l'ordre Docker kill i el contenidor morirà immediatament. Límit suau — límit suau, el contenidor pot anar més enllà del valor especificat, però aquest paràmetre es tindrà en compte a l'hora de col·locar tasques a les màquines. Per exemple, si una màquina té 4 GiB de RAM i el límit suau d'un contenidor és de 2048 MiB, aquesta màquina pot tenir un màxim de 2 tasques en execució amb aquest contenidor. En realitat, 4 GiB de RAM són una mica menys de 4096 MiB, això es pot veure a la pestanya Instàncies ECS del clúster. El límit suau no pot ser superior al límit dur. És important entendre que si hi ha diversos contenidors en una tasca, els seus límits es resumeixen.
Mapes de ports - dins Port amfitrió Indiquem 0, això vol dir que el port s'assignarà de forma dinàmica i serà monitoritzat pel grup objectiu. Port de contenidors — el port on s'executa la vostra aplicació sovint s'especifica a l'ordre d'execució o s'assigna al codi de l'aplicació, Dockerfile, etc. Per al nostre exemple farem servir 3000 perquè apareix a la llista la imatge que s'utilitza.
Revisió de salut — paràmetres de comprovació de l'estat del contenidor, que no s'han de confondre amb el configurat al grup objectiu.
Mediambient - Configuració de l'entorn. unitats CPU - similar als límits de memòria, només sobre el processador. Cada nucli de processador té 1024 unitats, de manera que si el servidor té un processador de doble nucli i el contenidor està configurat en 512, es poden iniciar 4 tasques amb aquest contenidor en un servidor. Les unitats de CPU sempre corresponen al nombre de nuclis; no pot haver-ne una mica menys, com és el cas de la memòria.
Comando — una ordre per iniciar un servei dins d'un contenidor, tots els paràmetres s'especifiquen separats per comes. Això podria ser gunicorn, npm, etc. Si no s'especifica, s'utilitzarà el valor de la directiva CMD del Dockerfile. Indiquem npm,start.
Variables del mediambient — variables d'entorn del contenidor. Això pot ser dades de text simples o variables secretes de o .
Emmagatzematge i registre — aquí configurarem el registre a CloudWatch Logs (un servei per als registres d'AWS). Per fer-ho, només cal que activeu la casella de selecció Configura automàticament els registres de CloudWatch. Després de crear la definició de la tasca, es crearà automàticament un grup de registres a CloudWatch. De manera predeterminada, els registres s'emmagatzemen indefinidament; recomano canviar el període de retenció de Mai caduca al període requerit. Això es fa als grups de registre de CloudWatch, heu de fer clic al període actual i seleccionar-ne un de nou.
Clúster ECS i proveïdor de capacitat ECS
Aneu a la secció ECS → Clústers per crear un clúster. Seleccionem EC2 Linux + Networking com a plantilla.
Nom del clúster - molt important, fem aquí el mateix nom que s'especifica al paràmetre Launch Template ECS_CLUSTER, en el nostre cas - DemoApiClusterProd. Marqueu la casella de selecció Crea un clúster buit. Opcionalment, podeu habilitar Container Insights per veure mètriques dels serveis a CloudWatch. Si ho heu fet tot correctament, a la secció Instàncies ECS veureu les màquines que s'han creat al grup Auto Scaling.
Vés a la pestanya Proveïdors de capacitat i crear-ne un de nou. Us recordo que és necessari controlar la creació i l'aturada de les màquines en funció del nombre de tasques ECS en execució. És important tenir en compte que un proveïdor només es pot assignar a un grup.
Grup Auto Scaling — seleccioneu el grup creat anteriorment.
Escalat gestionat — habiliteu-lo perquè el proveïdor pugui escalar el servei.
Capacitat objectiu % — quin percentatge de màquines carregades de tasques necessitem. Si especifiqueu el 100%, totes les màquines estaran sempre ocupades amb tasques en execució. Si especifiqueu el 50%, la meitat dels cotxes sempre seran gratuïts. En aquest cas, si hi ha un fort salt de càrrega, els nous taxis arribaran immediatament a cotxes lliures, sense haver d'esperar que es desplegaran instàncies.
Protecció de terminació gestionada — habilitar, aquest paràmetre permet al proveïdor eliminar la protecció de les instàncies contra la supressió. Això passa quan no hi ha tasques actives a la màquina i permet la capacitat de destinació%.
Servei d'ECS i configuració d'escala
Últim pas :) Per crear un servei, heu d'anar al clúster creat anteriorment a la pestanya Serveis.
Tipus de llançament — heu de fer clic a Canvia a l'estratègia de proveïdor de capacitat i seleccionar els proveïdors creats anteriorment.
Definició de la tasca — seleccioneu la definició de tasca creada anteriorment i la seva revisió.
Nom del servei — per evitar confusions, sempre indiquem el mateix que Definició de la tasca.
Tipus de servei - sempre rèplica.
Nombre de tasques — el nombre desitjat de tasques actives al servei. Aquest paràmetre es controla mitjançant l'escala, però encara s'ha d'especificar.
Percentatge mínim saludable и Percentatge màxim — determinar el comportament de les tasques durant el desplegament. Els valors predeterminats són 100 i 200, cosa que indica que en el moment del desplegament el nombre de tasques augmentarà diverses vegades i després tornarà al valor desitjat. Si teniu 1 tasca en execució, min=0 i max=100, durant el desplegament s'eliminarà i, després, se n'aixecarà una de nova, és a dir, serà temps d'inactivitat. Si s'està executant 1 tasca, min=50, max=150, el desplegament no es produirà en absolut, perquè 1 tasca no es pot dividir per la meitat ni augmentar-ne una vegada i mitja.
Tipus de desplegament - deixeu l'actualització de Rolling.
Plantilles d'ubicació — normes per a la col·locació de tasques a les màquines. El valor predeterminat és AZ Balanced Spread; això vol dir que cada tasca nova es col·locarà en una instància nova fins que pugin les màquines de totes les zones de disponibilitat. Normalment fem BinPack - CPU i Spread - AZ; amb aquesta política, les tasques es col·loquen tan densament com sigui possible en una màquina per CPU. Si és necessari crear una màquina nova, es crea en una nova zona de disponibilitat.
Tipus d'equilibrador de càrrega — seleccioneu Equilibrador de càrrega de l'aplicació.
Rol de servei IAM - triar ecsServiceRole.
Nom de l'equilibrador de càrrega — seleccioneu l'equilibrador creat anteriorment.
Període de gràcia del control de salut — fer una pausa abans de realitzar comprovacions de salut després de llançar una tasca nova, normalment la fixem en 60 segons.
Contenidor per equilibrar la càrrega — a l'element Nom del grup objectiu, seleccioneu el grup creat anteriorment i tot s'emplenarà automàticament.
Servei Auto Scaling — Paràmetres d'escala del servei. Seleccioneu Configura l'escala automàtica del servei per ajustar el recompte desitjat del vostre servei. Establem el nombre mínim i màxim de tasques en escalar.
Rol IAM per a Service Auto Scaling - triar AWSServiceRoleForApplicationAutoScaling_ECSService.
Polítiques d'escala automàtica de tasques - Normes d'escala. Hi ha 2 tipus:
- Seguiment d'objectius — seguiment de mètriques de destinació (ús de CPU/RAM o nombre de sol·licituds per a cada tasca). Per exemple, volem que la càrrega mitjana del processador sigui del 85%, quan sigui superior, s'afegiran noves tasques fins que assoleixi el valor objectiu. Si la càrrega és menor, les tasques s'eliminaran, per contra, tret que la protecció contra la reducció d'escala estigui habilitada (Desactiva l'escalada).
- Escala de passos - Reacció davant un esdeveniment arbitrari. Aquí podeu configurar una reacció a qualsevol esdeveniment (alarma de CloudWatch), quan es produeixi, podeu afegir o eliminar el nombre especificat de tasques, o especificar el nombre exacte de tasques.
Un servei pot tenir diverses regles d'escala, això pot ser útil, el més important és assegurar-se que no entren en conflicte entre si.
Conclusió
Si heu seguit les instruccions i heu utilitzat la mateixa imatge de Docker, el vostre servei hauria de tornar una pàgina com aquesta.
- Hem creat una plantilla segons la qual es posen en marxa totes les màquines del servei. També hem après com actualitzar les màquines quan canvia la plantilla.
- Hem configurat el processament del senyal d'aturada de la instància puntual, de manera que en un minut després de rebre-lo, totes les tasques en execució s'eliminen de la màquina, de manera que no es perd ni s'interromp res.
- Vam aixecar l'equilibrador per distribuir la càrrega uniformement entre les màquines.
- Hem creat un servei que s'executa en instàncies puntuals, que redueix els costos de les màquines aproximadament 3 vegades.
- Hem configurat l'escala automàtica en ambdues direccions per gestionar l'augment de les càrregues de treball sense incórrer en costos de temps d'inactivitat.
- Utilitzem Capacity Provider perquè l'aplicació gestioni la infraestructura (màquines) i no al revés.
- Estem genials.
Si teniu pics de càrrega previsibles, per exemple, anuncieu una campanya de correu electrònic gran, podeu configurar l'escala mitjançant .
També podeu escalar en funció de les dades de diferents parts del vostre sistema. Per exemple, tenim la funcionalitat usuaris de l'aplicació mòbil. De vegades s'envia una campanya a més d'1 milió de persones. Després d'aquesta distribució, sempre hi ha un gran augment de les sol·licituds a l'API, ja que molts usuaris inicien sessió a l'aplicació al mateix temps. Així, si veiem que hi ha indicadors molt més estàndard a la cua per enviar notificacions push promocionals, podem llançar immediatament diverses màquines i tasques addicionals per estar preparats per a la càrrega.
Estaré encantat si m'expliqueu als comentaris casos interessants d'ús d'instàncies puntuals i ECS o alguna cosa sobre l'escala.
Aviat hi haurà articles sobre com processem milers d'esdeveniments analítics per segon en una pila predominantment sense servidor (amb diners) i com funciona el desplegament de serveis mitjançant GitLab CI i Terraform Cloud.
Subscriu-te a nosaltres, serà interessant!
Només els usuaris registrats poden participar en l'enquesta. si us plau.
Utilitzeu instàncies puntuals en producció?
-
22,2%Sí 6
-
66,7%No18
-
11,1%Vaig aprendre sobre ells a partir d'un article i penso utilitzar-los3
Han votat 27 usuaris. 5 usuaris es van abstenir.
Font: www.habr.com