La lliçó anterior va contenidoritzar la botiga de MercadoFresco i la va posar a córrer en un clúster d'ECS. El resultat va ser bo però incomplet: sota el clúster continuen existint instàncies EC2 que cal dimensionar, l'AMI de les quals cal mantenir, que es paguen tant si són plenes com buides, i que triguen dos minuts a arrencar quan el clúster necessita capacitat nova. Vam amagar el problema darrere d'un proveïdor de capacitat; no el vam eliminar.

AWS Fargate l'elimina. És el motor de còmput sense servidor per a contenidors: es declara quanta CPU i quanta memòria necessita cada tasca, i AWS hi posa la resta —l'amfitrió, el kernel, els pedaços, l'aïllament— sense que existeixi cap instància que ningú pugui veure ni llistar. Aquesta lliçó migra el servei de la botiga a Fargate, ajusta el seu autoescalat al pic dels divendres, posa els treballadors de la cua a Fargate Spot i acaba amb la comparativa honesta entre Fargate, EC2 i Lambda.

Avís de cost. Fargate es factura per vCPU-hora i GB-hora consumits per la tasca, amb arrodoniment al segon i un mínim d'un minut. A eu-west-1 ronda els 0,047 USD per vCPU-hora i 0,0051 USD per GB-hora en x86, i aproximadament un 20 % menys en arm64/Graviton. Fargate Spot descompta al voltant del 70 % a canvi de poder ser interromput. No hi ha capa gratuïta per a Fargate: una tasca oblidada d'1 vCPU i 2 GB costa uns 41 USD al mes. Segueix la secció de neteja del final. Els preus són aproximats i orientatius; l'anàlisi de costos a fons és el mòdul 11. Dades i identificadors ficticis.

1. Què és Fargate i què deixa d'existir
2. El mateix servei sobre EC2 i sobre Fargate
3. Model de recursos: CPU, memòria i emmagatzematge efímer
4. x86 i arm64: Graviton i l'estalvi real
5. Diferències operatives: sense SSH, sense hostPort, sense DaemonSet
6. ECS Exec: depurar sense servidor a tocar
7. Registres amb FireLens i Fluent Bit
8. L'arrencada de tasques i el pic dels divendres
9. Migrar el servei de la botiga a Fargate
10. Punts d'enllaç de VPC: deixar de dependre del NAT
11. Autoescalat: seguiment, passos i programació
12. Fargate Spot i els treballadors de la cua
13. Tasques puntuals i programades amb EventBridge Scheduler
14. Integració al pipeline i blue/green
15. El servei en CDK amb un constructe L3
16. Fargate enfront d'EC2 enfront de Lambda
17. App Runner: un esglaó més de gestió
18. Cost comparat i neteja
19. Errors habituals i consells
20. Exercicis
21. Conclusió

Fargate no és un servei que es contracti a part ni una consola diferent: és un tipus de llançament —i, amb més precisió, un proveïdor de capacitat— dins del mateix Amazon ECS de la lliçó anterior. Les definicions de tasca, els serveis, els grups de destinació, l'autoescalat i els rols són els mateixos objectes. El que canvia és on s'executa la tasca i qui és responsable de la màquina.

La frase que resumeix el canvi: Fargate no elimina la feina d'operar una aplicació, elimina la feina d'operar un servidor. La Marta continua havent de decidir quantes tasques hi ha un divendres a les 19:00; el que ja no ha de decidir és de quina mida són les màquines que les allotgen.

Tècnicament, cada tasca de Fargate s'executa en el seu propi entorn aïllat per virtualització lleugera —la mateixa tecnologia que sustenta Lambda—, cosa que resol l'advertiment de 10-01 sobre el kernel compartit: dues tasques no comparteixen mai kernel, ni tan sols dues tasques teves.

Els dos diagrames tenen el mateix ALB, el mateix servei i les mateixes tasques. La diferència és a la capa intermèdia: al primer hi ha dues caixes que representen màquines —amb la seva AMI, el seu agent i el seu buit pagat—; al segon no n'hi ha cap.

A Fargate, cpu i memory a escala de tasca són obligatoris i només admeten combinacions concretes. No es pot demanar 1 vCPU amb 1 GB, ni 3 vCPU amb el que sigui.

Dues conseqüències pràctiques:

• La combinació es tria abans de conèixer la càrrega real, i gairebé sempre malament. El mètode correcte és el del mòdul 5: mirar CpuUtilized i MemoryUtilized de Container Insights durant dues setmanes, prendre el percentil 95 i afegir-hi un 30 % de marge. Sobredimensionar a Fargate costa diners des del primer segon, perquè no hi ha cap instància ja pagada on amagar l'excés.
• La granularitat castiga les aplicacions amb poca CPU i molta memòria. Una tasca que necessita 6 GB obliga a demanar almenys 1 vCPU, encara que en faci servir el 5 %. Quan això passa molt, convé revisar si l'aplicació hauria de ser una Lambda o si hi ha una fuita de memòria.

L'emmagatzematge efímer són 20 GB per omissió, ampliables fins a 200 GB amb ephemeralStorage. Es cobra només el que excedeixi els 20 GB gratuïts. És un disc temporal que desapareix en acabar la tasca: serveix per descomprimir un fitxer o per a una memòria cau local, mai per a estat. Quan cal persistència compartida, es munta EFS (02-02), que Fargate admet de manera nativa.

Fargate executa tasques en dues arquitectures: X86_64 i ARM64, aquesta última sobre processadors AWS Graviton. El canvi es fa amb un camp de la definició de tasca, però exigeix que la imatge estigui construïda per a aquesta arquitectura.

La construcció multiarquitectura es resol a CodeBuild amb docker buildx:

Per a MercadoFresco l'estalvi és real i mesurable: la botiga són 2 tasques base més fins a 2 al pic, d'1 vCPU i 2 GB. Passar a Graviton baixa el cost mensual del servei d'uns 85 USD a uns 68 USD, un 20 % sense tocar una línia de codi de negoci. El requisit és provar-ho: el Luis construeix la imatge per a les dues arquitectures, desplega arm64 a preproducció durant una setmana, compara latència i errors al tauler mercadofresco-produccion, i només llavors canvia producció.

El risc concret és el de les dependències: una roda de Python que només publica binaris x86 obliga a compilar en la construcció —cosa que l'etapa constructor del Dockerfile de 10-01 ja permet— o a bloquejar el canvi. És preferible descobrir-ho a CodeBuild que en un desplegament.

Fargate imposa restriccions que no són arbitràries: es deriven del fet que l'amfitrió no existeix per a tu.

La restricció que més incomoda al principi és la primera, i la segona que més, la del DaemonSet: molta gent executava un contenidor de recollida de registres per instància. A Fargate aquest patró se substitueix per un sidecar dins de cada tasca, cosa que costa una mica de CPU i memòria per tasca però elimina la coordinació entre nodes.

ECS Exec obre una sessió d'ordres dins d'un contenidor en execució fent servir AWS Systems Manager, sense ports oberts, sense claus SSH i sense bastió. Requereix tres coses:

1. El servei o la tasca amb --enable-execute-command.
2. El rol de la tasca —no el d'execució— amb permisos de canal d'SSM.
3. L'agent d'SSM, que Fargate ja inclou a partir de la versió de plataforma 1.4.

Tres advertiments que cal interioritzar abans de fer-lo servir a producció:

• Tot queda auditat a CloudTrail (05-03) amb l'esdeveniment ExecuteCommand: qui, quan, en quina tasca i amb quina ordre. A més es pot exigir que la sessió es registri a CloudWatch Logs o a S3 amb executeCommandConfiguration al clúster, xifrant amb alias/mercadofresco-datos. A MercadoFresco, fer servir ECS Exec a producció dispara una notificació a alertas-mercadofresco: no està prohibit, està vigilat.
• Els canvis fets dins d'un contenidor no sobreviuen. Editar un fitxer de configuració a la tasca funciona fins que la tasca es reposa, i llavors desapareix silenciosament. ECS Exec serveix per diagnosticar, no per arreglar.
• Amb readonlyRootFilesystem: true el sistema de fitxers és de només lectura, que és exactament el que es vol: si necessites escriure per depurar, la resposta sol ser que falta un registre.

A la pràctica, el 90 % del que la gent anava a buscar per SSH ja és a CloudWatch Logs Insights o a X-Ray. ECS Exec és per al 10 % restant: comprovar una resolució DNS, verificar que una variable d'entorn va arribar com s'esperava o confirmar que el procés escolta al port correcte.

El controlador awslogs de 10-01 continua funcionant i és el correcte per omissió. Quan cal més —encaminar cap a diversos destins, filtrar abans d'enviar, reescriure el format o enviar còpia a un sistema extern—, la resposta a Fargate és FireLens: un sidecar de Fluent Bit que ECS configura automàticament.

El cost de FireLens és un contenidor més per tasca, uns 64 CPU i 128 MB, que en un servei de quatre tasques són diners de debò. La regla de MercadoFresco: awslogs per omissió, FireLens només quan hi hagi un requisit que awslogs no cobreixi, com filtrar els registres d'accés amb dades personals abans que surtin de la tasca.

Aquest és el punt pel qual existeix la lliçó. Una tasca de Fargate travessa aquestes fases:

1. Aprovisionament (PROVISIONING): es crea l'ENI a la subxarxa i se li associa el grup de seguretat. De 3 a 10 segons.
2. Descàrrega de la imatge (PENDING): s'autentica a ECR i es descarreguen les capes que faltin. De 5 a 25 segons segons la mida de la imatge i si hi ha punt d'enllaç de VPC.
3. Arrencada del contenidor: s'executa l'ENTRYPOINT. D'1 a 5 segons.
4. Comprovacions d'estat: l'ALB registra la destinació i espera els encerts consecutius. De 15 a 40 segons segons la configuració del grup de destinació.

El que significa per al divendres a les 19:00 amb 900 comandes/hora és concret: quan l'alarma d'ALBRequestCountPerTarget supera el llindar, la capacitat nova comença a atendre peticions als 40 segons en lloc dels dos minuts. Amb la pujada de trànsit mesurada a MercadoFresco —de 300 a 900 comandes/hora en uns vuit minuts—, aquests 80 segons de diferència són la frontera entre una latència que puja una mica i una latència que dispara mercadofresco-alb-latencia-alta.

I hi ha una conseqüència menys òbvia i més valuosa: amb arrencades de 40 segons, es pot permetre un mínim més baix. Abans calien 2 instàncies sempre enceses per absorbir el que l'ASG trigava a reaccionar. Amb Fargate, el mínim pot continuar sent 2 tasques per disponibilitat —mai menys, per sobreviure a la pèrdua d'una AZ—, però el marge extra que es mantenia «per si de cas» deixa de ser necessari.

La palanca que redueix la fase 2 és la mida de la imatge i la ruta fins a ECR. La imatge de 220 MB de la botiga triga uns 8 segons des d'un punt d'enllaç de VPC i uns 20 a través del NAT. És un altre argument per al Dockerfile acurat de 10-01 i per a la secció següent.

El canvi, sorprenentment, és petit: la definició de tasca de 10-01 ja declarava requiresCompatibilities: ["EC2", "FARGATE"] i mode awsvpc, precisament per a això.

Pas 1: fixar CPU i memòria amb dades, no amb intuïció. Container Insights fa dues setmanes que mesura. La consulta que la Marta executa:

El percentil 95 de CPU és de 0,62 vCPU i el de memòria d'1,4 GB, amb un màxim absolut de 0,81 vCPU al pic del divendres. La combinació vàlida més ajustada per sobre d'això amb marge és 1 vCPU i 2 GB. Baixar a 0,5 vCPU / 2 GB seria temptador —estalvia un 25 %— però deixa la tasca del divendres al 160 % de la seva CPU: la latència es degradaria exactament quan importa.

Pas 2: crear el servei amb el proveïdor de capacitat de Fargate.

Tres detalls de l'ordre:

• assignPublicIp=DISABLED amb subxarxes privades. Les tasques van a snet-mercadofresco-app-a i -b, sense IP pública. Això és el correcte i el que obliga a la secció següent: sense IP pública, la tasca necessita una ruta cap a ECR, S3, CloudWatch Logs i Secrets Manager, i aquesta ruta és un NAT car o uns punts d'enllaç barats.
• No hi ha --placement-strategy. Les estratègies de col·locació són d'EC2. Fargate reparteix les tasques entre les subxarxes declarades, de manera que la disponibilitat s'obté declarant subxarxes de les dues AZ, no amb una estratègia.
• --platform-version LATEST. La versió de plataforma és l'equivalent a l'AMI de l'amfitrió, i la gestiona AWS. Fixar-la a una versió concreta només té sentit si una novetat trenca alguna cosa, i llavors és una mesura temporal, no permanent.

Pas 3: convivència i tall. Igual que a 10-01, l'ALB reparteix per pesos entre el servei d'EC2 i el de Fargate: 90/10, després 50/50, després 0/100 al llarg de dues setmanes, vigilant TargetResponseTime i HTTPCode_Target_5XX. El dia que el pes arriba a 100, l'ASG del clúster d'EC2 s'esborra i amb ell l'AMI, la plantilla de llançament i el cicle d'apedaçament.

Una tasca de Fargate en subxarxa privada parla amb diversos serveis d'AWS només per arrencar. Si aquesta comunicació surt pel NAT, es paga dues vegades: l'hora del NAT i cada gigabyte processat.

El d'S3 és el que més s'oblida i el més important: és de tipus passarel·la, és gratuït i sense ell la descàrrega d'imatges no funciona encara que els dos d'ECR estiguin posats. MercadoFresco ja tenia vpce-mercadofresco-s3 des del mòdul 3, així que aquest està resolt.

El càlcul de l'estalvi per a MercadoFresco, amb 4,8 desplegaments per setmana, reposicions de tasques i escalat diari:

I aquí convé ser honest en lloc de repetir l'eslògan: amb set punts d'enllaç en dues AZ, els punts d'enllaç surten més cars que el NAT en una arquitectura de la mida de MercadoFresco. L'argument a favor no és només el preu, en són altres tres: el trànsit no surt de la xarxa d'AWS, cosa que és un requisit de seguretat defensable davant d'una auditoria; l'arrencada de tasques és més ràpida i més previsible; i el NAT deixa de ser un punt únic de fallada per a l'arrencada. La decisió de la Marta és intermèdia i raonada: punts d'enllaç per a ECR, S3 i Logs —els del camí crític d'arrencada, que són quatre i costen uns 64 USD— i mantenir el NAT per a la resta, sabent que al mòdul 11 es revisarà si compensa.

Els tres tipus de política es combinen, i cadascun resol un problema diferent.

La configuració completa de MercadoFresco fa servir els tres. El seguiment de destinació sobre ALBRequestCountPerTarget de 10-01 es manté com a base. A sobre, l'escalat programat del divendres, que és la peça que faltava:

Tres decisions de disseny en aquestes vuit línies:

• Es programa el mínim, no el nombre desitjat. Fixar DesiredCount desactivaria de fet el seguiment de destinació durant la finestra. Pujant el mínim, la capacitat està garantida i el seguiment continua podent créixer per sobre si el divendres és millor del previst.
• --timezone "Europe/Madrid". Sense això, el cron és UTC i a l'estiu el pic s'avança una hora respecte de l'acció programada. És un error que només apareix en canviar l'hora, a l'octubre, quan ningú no recorda haver tocat res.
• Quinze minuts abans i mitja hora després. Abans, perquè les tasques estiguin sanes quan arribi el trànsit; després, amb generositat, perquè baixar massa aviat és el que provoca l'oscil·lació que es veu com a pics de latència a les 21:05.

El cost d'aquesta finestra és fàcil de calcular i de defensar: 4 tasques extra × 5 hores × 4,3 divendres × 0,057 USD/h ≈ 4,9 USD al mes. És probablement els millors diners que gasta MercadoFresco.

Fargate Spot executa tasques sobre capacitat sobrant d'AWS amb un descompte proper al 70 %, a canvi que AWS la pugui reclamar. Quan ho fa:

1. Emet un esdeveniment de canvi d'estat a EventBridge i envia SIGTERM al contenidor.
2. Espera el stopTimeout de la definició de tasca, amb un màxim de dos minuts.
3. Envia SIGKILL i la tasca desapareix.

Dos minuts d'avís són molt o poc segons la càrrega:

La manera correcta d'aplicar-ho no és «tot Spot» sinó un repartiment per proveïdors de capacitat, que garanteix un terra sota demanda:

base=1 al proveïdor sota demanda significa que la primera tasca sempre és estable; el weight reparteix totes les altres en proporció 1 a 4. Amb 10 tasques: 1 base + 9 repartides com a 1,8 sota demanda i 7,2 Spot, és a dir, aproximadament 3 sota demanda i 7 Spot.

L'estalvi del repartiment 1:4 és de gairebé el 50 % i manté un terra que sobreviu a una retirada massiva de capacitat Spot. El requisit tècnic que ho fa segur és el de l'exercici de 10-01: gestor de SIGTERM que acaba el missatge en curs i no en demana un altre, amb stopTimeout: 120 i temps de visibilitat de la cua folgat.

No tot és un servei. La càrrega nocturna que alimenta wg-mercadofresco-analitica (06-04) s'executa un cop al dia i acaba. A EC2 això era una instància encesa o un cron en una màquina que algú havia de cuidar; a Fargate és una tasca puntual programada.

El que és rellevant d'aquesta configuració: la finestra flexible de 30 minuts deixa que AWS triï el moment dins de la finestra, cosa que redueix la contenció i encaixa perfectament amb Spot; la política de reintents converteix una fallada transitòria en un reintent automàtic; i la DLQ garanteix que una fallada persistent deixa rastre en lloc de desaparèixer. És el mateix patró que 07-05 aplicat a una tasca programada.

Per a una execució puntual —una migració, una reparació de dades— n'hi ha prou amb aws ecs run-task amb la mateixa configuració de xarxa i --launch-type FARGATE. Si la feina té diversos passos amb dependències entre ells, l'eina correcta és Step Functions (07-04), que pot llançar tasques d'ECS i esperar que acabin.

El pipeline-mercadofresco-tienda del mòdul 8 canvia poc: on abans hi havia un desplegament de CodeDeploy sobre un ASG, ara hi ha un desplegament sobre un servei d'ECS.

El blue/green de CodeDeploy sobre ECS funciona diferent que sobre EC2, i la diferència és una millora: CodeDeploy crea un conjunt de tasques nou complet amb la revisió nova, el registra a tg-mercadofresco-verde, permet executar les proves de fum contra el port de proves de l'ALB sense trànsit real, i només llavors desplaça l'oient de producció cap al grup verd. El conjunt blau es manté durant el temps d'espera de terminació, de manera que una reversió és un canvi d'oient: segons.

Amb la configuració de desplegament canària ECSCanary10Percent5Minutes, el 10 % del trànsit va al conjunt verd durant 5 minuts; si mercadofresco-alb-latencia-alta o mercadofresco-pedidos-fallidos salten en aquest interval, CodeDeploy reverteix sol. És la millora sobre el circuit breaker de 10-01: aquell detecta tasques que no arrenquen; aquest detecta tasques que arrenquen i responen malament.

Les mètriques DORA de MercadoFresco milloren on era d'esperar: la restauració passa de 4 minuts a menys d'1, perquè revertir ja no significa desplegar res, només moure un oient.

Tot l'anterior són unes vint línies al projecte infra-cdk/ de 09-02, gràcies a un constructe de nivell 3 que crea l'ALB, el grup de destinació, el servei, la definició de tasca, els rols i el grup de registres.

L'advertiment de 09-02 continua vigent: cdk synth i llegir la plantilla la primera vegada. Aquest constructe pren decisions per tu —crea un ALB públic, obre el seu grup de seguretat al 0.0.0.0/0 al port 80, crea un grup de registres amb retenció per omissió— i cal verificar que coincideixen amb el que vols. A producció, MercadoFresco hi afegeix el certificat i el redirectHTTP: true per no servir mai per HTTP.

Fixa't també en enableExecuteCommand: config.nombre !== 'produccion': ECS Exec activat a desenvolupament i preproducció, i desactivat a producció tret d'activació explícita durant un incident. És una decisió de govern expressada en una línia d'infraestructura.

Tots tres executen codi sense que tu compris maquinari, i l'elecció es fa per criteris objectius.

La decisió raonada de MercadoFresco, component a component:

El criteri que resol la majoria dels dubtes: si el procés viu esperant peticions, és Fargate; si el procés es desperta davant d'un esdeveniment i mor, és Lambda; si necessites el control de la màquina, és EC2. I el criteri econòmic, que s'afina al mòdul 11: per sota d'una utilització sostinguda alta, Fargate guanya a EC2 perquè no paga l'oci; per sobre, EC2 amb Savings Plans (11-05) recupera l'avantatge.

AWS App Runner va un pas més enllà: se li dona una imatge de contenidor o un repositori de codi, i crea el servei, el balancejador, el certificat, el domini i l'autoescalat, inclòs escalar a zero. No hi ha VPC que dissenyar, ni grup de destinació, ni definició de tasca.

El que és rellevant és on deixa d'encaixar, i per això MercadoFresco no el fa servir: dona molt menys control de xarxa —l'accés a la VPC exigeix un connector i continua havent-hi limitacions—, no admet sidecars ni tasques multicontenidor, el model de desplegament no ofereix el blue/green canari de CodeDeploy, i el seu cost per unitat és superior al de Fargate. És una opció excel·lent per a un servei HTTP senzill o un prototip, i un mal encaix per a una botiga amb Aurora en subxarxa privada, cues, memòria cau i un pipeline amb porta de qualitat. Se'n parla perquè és la pregunta que sempre apareix: la resposta és que l'escala de gestió no és una classificació, és un intercanvi entre comoditat i control.

El càlcul complet del servei de la botiga, amb preus aproximats d'eu-west-1:

Fargate x86, tasca d'1 vCPU i 2 GB: 1 × 0,04656 + 2 × 0,00511 = 0,05678 USD/hora.

MercadoFresco passa d'uns 158 USD a uns 70 USD al mes a la botiga, amb arm64, i elimina de passada la feina de mantenir AMI i pedaços. Amb els treballadors a Spot, l'estalvi total del mòdul ronda els 150 USD mensuals.

Amb dos matisos honestos, perquè la comparació no és completa sense ells. El primer: les instàncies EC2 es podrien comprar amb Savings Plans i baixar un 30-40 %, cosa que estreny molt la diferència —i Fargate també admet Compute Savings Plans, tema d'11-05—. El segon: si el clúster d'EC2 estigués molt ben empaquetat, amb la botiga i els treballadors compartint instàncies al 85 % d'ocupació, EC2 seria competitiu. El problema és que aquest empaquetatge cal aconseguir-lo i mantenir-lo, i aquesta és exactament la classe de feina que Fargate elimina.

Neteja, en ordre estricte:

El pas 4 és el residu car d'aquesta lliçó: set punts d'enllaç d'interfície en dues AZ costen uns 112 USD al mes encara que no hi passi ni un sol byte. Un punt d'enllaç oblidat és la fuita silenciosa més habitual després de les adreces IP elàstiques sense associar.

Error: demanar una combinació de CPU i memòria invàlida. RegisterTaskDefinition falla amb un missatge poc clar. Consell: tingues la taula a mà; amb el CDK, memoryLimitMiB i cpu es validen en la síntesi, que és abans.

Error: dimensionar per intuïció. Sobredimensionar a Fargate es paga des del primer segon. Consell: percentil 95 de Container Insights durant dues setmanes, més un 30 %, i revisar-ho al cap d'un mes.

Error: subxarxes privades sense punts d'enllaç ni NAT. La tasca es queda a PROVISIONING i mor amb CannotPullContainerError. Consell: abans de migrar, comprova la ruta a ECR api, ECR dkr, S3, Logs i Secrets Manager; el d'S3 és de passarel·la, és gratis i és el que més s'oblida.

Error: creure que sense NAT sempre és més barat. Set punts d'enllaç d'interfície en dues AZ superen el NAT en una arquitectura mitjana. Consell: posa punts d'enllaç només per al camí crític d'arrencada i decideix la resta amb dades del mòdul 11.

Error: programar DesiredCount en lloc del mínim. Desactiva de fet el seguiment de destinació durant la finestra. Consell: programa MinCapacity i deixa que la política reactiva continuï treballant per sobre.

Error: oblidar --timezone a l'escalat programat. El pic es desplaça una hora en canviar l'hora. Consell: Europe/Madrid explícit en tota acció programada, i revisar l'última setmana d'octubre.

Error: posar la botiga a Fargate Spot per estalviar. Una interrupció amb dos minuts d'avís durant el pic del divendres és just el que el curs porta deu mòduls evitant. Consell: Spot només on la interrupció es reintenta sola, i sempre amb base sota demanda.

Error: no gestionar SIGTERM als treballadors. Amb Spot, cada interrupció es converteix en un missatge reprocessat o perdut. Consell: gestor que acaba el missatge en curs i no en demana un altre, stopTimeout: 120 i temps de visibilitat folgat.

Error: fer servir ECS Exec per arreglar alguna cosa. El canvi desapareix en la reposició següent i deixa un sistema que ningú no pot reproduir. Consell: ECS Exec per diagnosticar; l'arranjament va pel pipeline. I a producció, amb notificació a alertas-mercadofresco.

Error: canviar a arm64 sense provar-ho. Una roda de Python sense binari arm trenca l'arrencada. Consell: docker buildx amb les dues plataformes, una setmana a preproducció i comparació de latència abans de tocar producció.

Consell: fixa --platform-version LATEST i no l'ancoris. Ancorar una versió de plataforma és renunciar a les millores i als pedaços, que és just el que has vingut a comprar.

Consell: mantén minimumHealthyPercent: 100 a producció. Amb Fargate ja no hi ha un buit d'instància que limiti el maximumPercent, així que 100/200 no costa capacitat reservada, només uns minuts de doble facturació per desplegament.

Consell: posa una alarma sobre RunningTaskCount enfront de DesiredTaskCount. És el senyal més primerenc d'un problema d'arrencada, de quota de Fargate o d'esgotament d'IP a la subxarxa.

Els treballadors de cola-mercadofresco-pedidos processen cada missatge en 12 segons de mitjana, amb un pic de 900 missatges/hora els divendres de 17:00 a 21:00 i uns 150 missatges/hora la resta del temps. Container Insights indica que cada treballador fa servir el percentil 95 de 0,31 vCPU i 780 MB. L'acord de servei intern és que cap comanda no esperi més de 3 minuts a la cua. Dissenya: (a) la combinació de CPU i memòria de la tasca, justificada; (b) quantes tasques calen al pic i fora del pic, amb el càlcul; (c) la política d'autoescalat completa, indicant quina mètrica fas servir i per què no la CPU; (d) el repartiment entre FARGATE i FARGATE_SPOT amb la seva base i els seus weight, i què passa si AWS retira tota la capacitat Spot durant el pic; i (e) el cost mensual aproximat del teu disseny.

El Luis migra el servei de la botiga a Fargate en preproducció. Les tasques es queden diversos minuts a PROVISIONING i acaben amb ResourceInitializationError: unable to pull secrets or registry auth. Comprova el següent i tot sembla correcte: el rol d'execució té els permisos d'ECR i de Secrets Manager, la definició de tasca és la mateixa que funcionava a EC2, i les subxarxes són snet-mercadofresco-app-a i -b. Diagnostica (a) les tres causes de xarxa possibles, en ordre de probabilitat, amb la comprovació concreta de cadascuna; (b) per què el mateix rol i la mateixa definició sí que funcionaven al tipus de llançament EC2; (c) quin punt d'enllaç de VPC concret arreglaria el cas més probable i per què el seu tipus importa; i (d) quines dues comprovacions afegiries al pipeline perquè aquesta fallada no torni a arribar a un desplegament.

La Sara torna d'una conferència amb una proposta: eliminar Fargate i passar tota la botiga a Lambda darrere d'API Gateway, «perquè només es paga per petició i escala a zero». Aporta la dada que la botiga rep unes 300 comandes/hora fora de pic i que a les 4 de la matinada no hi ha trànsit. Respon amb criteri tècnic i econòmic: (a) tres raons tècniques concretes per les quals la botiga de MercadoFresco no encaixa bé a Lambda; (b) el càlcul aproximat que compara el cost de totes dues opcions amb el trànsit real; (c) quina part de la seva proposta sí que té raó i on ja s'està aplicant a l'arquitectura actual; (d) què mesuraries abans de descartar-la del tot; i (e) com l'hi explicaries en una frase que no soni a «no».

Solució 1

(a) La combinació. El percentil 95 és 0,31 vCPU i 780 MB. Afegint-hi un 30 % de marge: 0,40 vCPU i 1,01 GB. La combinació vàlida immediatament superior és 512 (0,5 vCPU) amb 1 GB de memòria. Pujar a 1 vCPU duplicaria el cost per a un 20 % de CPU sense fer servir, i baixar a 0,25 vCPU no és possible perquè no hi arriba. Cost per tasca: 0,5 × 0,04656 + 1 × 0,00511 = 0,0279 USD/hora.

(b) Quantes tasques. Un treballador processa 3600 / 12 = 300 missatges/hora. Fora de pic, 150 missatges/hora exigeixen 1 tasca, però el mínim ha de ser 2 per disponibilitat: una sola tasca significa zero capacitat mentre es reposa. Al pic, 900 missatges/hora exigeixen 900 / 300 = 3 tasques per anar al dia, i aquest és exactament el punt on la cua no creix però tampoc no es recupera d'un retard. Per complir els 3 minuts amb marge i absorbir la variabilitat es fan servir 5 tasques al pic, que donen 1500 missatges/hora de capacitat i permeten drenar un retard acumulat.

(c) La política d'autoescalat. La CPU no serveix: un treballador que consumeix missatges està sempre igual d'ocupat, tingui la cua 10 o 10.000 missatges, així que la CPU no reflecteix el retard. La mètrica correcta és el retard per tasca, que es calcula amb una mètrica matemàtica de CloudWatch: ApproximateNumberOfMessagesVisible / RunningTaskCount. Amb un objectiu de 3 minuts i 300 missatges/hora per tasca, la destinació és 300 / 60 × 3 = 15 missatges per tasca.

S'hi afegeix una acció programada per als divendres que puja MinCapacity a 5 a les 16:45 i la torna a 2 a les 21:30, amb --timezone "Europe/Madrid": pujar per rellotge evita els primers minuts de retard que la política reactiva no pot evitar per definició.

(d) El repartiment de capacitat. capacityProvider=FARGATE,weight=1,base=2 més capacityProvider=FARGATE_SPOT,weight=3,base=0. Les dues tasques del terra són estables, i de les tres extra del pic aproximadament 0,75 van sota demanda i 2,25 a Spot. Si AWS retira tota la capacitat Spot durant el pic, queden les 2 tasques sota demanda amb capacitat per a 600 missatges/hora enfront de 900 entrants: la cua creix uns 300 missatges/hora i l'acord de 3 minuts s'incompleix en uns vint minuts. La mitigació té dues parts: la política d'autoescalat detecta el retard i demana tasques noves, que el proveïdor sota demanda sí que pot servir —el repartiment per weight s'aplica a les tasques noves, i amb Spot no disponible ECS llança sota demanda—; i una alarma sobre ApproximateAgeOfOldestMessage avisa alertas-mercadofresco si el missatge més antic supera els 3 minuts. El que no cal fer és posar base=0: el terra estable és el que converteix una retirada de Spot en una degradació en comptes d'una caiguda.

(e) Cost mensual. Fora de pic: 2 tasques × 0,0279 × (730 − 17) ≈ 39,8 USD. Al pic (4 h × 4,3 divendres = 17,2 h): 2 sota demanda × 0,0279 × 17,2 ≈ 0,96 USD, més 3 tasques extra majoritàriament Spot ≈ 3 × 0,0084 × 17,2 ≈ 0,43 USD. Total ≈ 41 USD al mes, enfront dels 156 USD de l'ASG dedicat de treballadors que hi havia abans.

Solució 2

(a) Les tres causes de xarxa, per probabilitat.

1. Falten els punts d'enllaç d'interfície d'ECR i Secrets Manager, i no hi ha NAT a la subxarxa de preproducció. És la causa més probable perquè l'error esmenta registry auth i secrets, que són exactament les dues primeres crides sortints d'una tasca. Comprovació: aws ec2 describe-route-tables sobre les subxarxes -app-a i -b buscant la ruta 0.0.0.0/0, i aws ec2 describe-vpc-endpoints filtrant per la VPC.
2. El grup de seguretat dels punts d'enllaç no permet l'entrada des del de les tasques. Els punts d'enllaç d'interfície són ENI amb grup de seguretat propi: si sg-mercadofresco-endpoints no accepta el port 443 des de sg-mercadofresco-tienda, existeixen però no es poden fer servir. Comprovació: regles d'entrada de sg-mercadofresco-endpoints.
3. El DNS privat del punt d'enllaç està desactivat. Sense --private-dns-enabled, el nom secretsmanager.eu-west-1.amazonaws.com continua resolent a la IP pública i el trànsit intenta sortir per on no hi ha sortida. Comprovació: el camp PrivateDnsEnabled del punt d'enllaç.

(b) Per què sí que funcionava a EC2. Perquè al tipus de llançament EC2, qui descarrega la imatge i resol els secrets és l'agent d'ECS de la instància, que fa servir la ruta de xarxa de la instància i el seu grup de seguretat. Si aquestes instàncies eren en una subxarxa amb NAT o tenien un grup de seguretat més permissiu, tot funcionava. En passar a Fargate, la connectivitat passa a dependre de l'ENI de la tasca, amb les subxarxes i el grup de seguretat declarats a networkConfiguration. És el mateix canvi de frontera del qual parlava awsvpc a 10-01, ara visible: la xarxa ja no és de la màquina, és de la tasca.

(c) El punt d'enllaç concret i per què importa el seu tipus. Per al cas més probable en calen tres: ecr.api, ecr.dkr i secretsmanager, tots tres d'interfície (ENI privada amb grup de seguretat, es paga per hora i per GB). Però el que sol faltar i no dona la cara és s3, que és de passarel·la: no és una ENI sinó una entrada a la taula de rutes, és gratuït, i sense ell les capes de la imatge —que s'emmagatzemen a S3— no es descarreguen encara que els dos punts d'enllaç d'ECR siguin perfectes. Confondre els dos tipus porta a posar un punt d'enllaç d'interfície per a S3, que funciona però costa diners innecessàriament en aquest cas.

(d) Dues comprovacions al pipeline. La primera, una prova de desplegament a preproducció amb la mateixa configuració de xarxa que producció: la fallada apareix on ha d'aparèixer. La segona, una regla d'AWS Config (05-04) o una prova del CDK (09-02) que verifiqui que tota subxarxa feta servir per un servei d'ECS té, o bé ruta cap a un NAT, o bé els cinc punts d'enllaç del camí crític. És una invariant d'arquitectura i per tant es prova com a codi, no es recorda. Com a reforç, la comprovació que el circuit breaker està activat amb rollback: true hauria convertit aquest incident en una reversió automàtica en lloc de en tasques girant en va.

Solució 3

(a) Tres raons tècniques.

1. La connexió a Aurora. Cada Lambda concurrent obre la seva pròpia connexió, i amb 300 comandes/hora en pics de concurrència això esgota el pool d'aurora-mercadofresco-pedidos ràpidament. Es resol amb RDS Proxy, que afegeix cost i una peça més; a Fargate, cada tasca manté un pool estable i el problema no existeix.
2. L'arrencada en fred amb estat calent. La botiga manté en memòria la memòria cau del catàleg que precarrega des de mercadofresco-catalogo en arrencar. A Fargate aquest cost es paga un cop per tasca i dura hores; a Lambda es pagaria a cada arrencada en fred, i la primera petició de cada entorn d'execució seria lenta just quan arriba un pic.
3. La reescriptura. La botiga és una aplicació WSGI amb Gunicorn; portar-la a Lambda exigeix un adaptador o partir-la en funcions, més un canvi del model de sessions, dels fitxers estàtics i de l'observabilitat. És un projecte de setmanes el benefici del qual és dubtós, just després d'acabar la migració a contenidors.

(b) El càlcul. Amb 300 comandes/hora de mitjana i unes 8 peticions HTTP per comanda, en surten unes 2.400 peticions/hora, és a dir, 1,75 milions al mes. Suposant 250 ms de mitjana i 2 GB de memòria: 1,75 M × 0,25 s × 2 GB = 875.000 GB-s. A 0,0000167 USD per GB-s són uns 14,6 USD, més 0,35 USD d'invocacions, més API Gateway: 1,75 M × 3,5 USD/milió ≈ 6,1 USD. Total ≈ 21 USD, enfront dels 70 USD de Fargate arm64. La Sara té raó en el número brut. Però hi falten tres partides que canvien la conclusió: RDS Proxy (uns 30 USD/mes), el cost de la reescriptura (setmanes de feina, que a cost d'equip supera de llarg l'estalvi anual de 588 USD) i el risc de latència per arrencades en fred durant el pic del divendres, que és precisament el problema que aquest mòdul acaba de resoldre.

(c) En què té raó i on ja s'aplica. Té raó en el principi: no pagar per capacitat ociosa. I aquest principi ja està aplicat on encaixa: mercadofresco-generar-miniaturas es dispara per esdeveniment d'S3 i no es paga entre pujades de foto; -cobrar-pago, -reservar-stock i -asignar-reparto són passos curts de la màquina d'estats; i els treballadors de la cua escalen fins al mínim fora del pic. L'arquitectura ja és híbrida per disseny: Lambda on la feina és esporàdica i curta, Fargate on el procés viu esperant peticions.

(d) Què mesuraria abans de descartar-la. Tres coses concretes: la distribució real de la latència de la botiga per percentils a X-Ray, per saber quant pesaria una arrencada en fred al p99; el nombre de connexions simultànies a Aurora al pic del divendres, per dimensionar si RDS Proxy seria suficient; i el cost real de Fargate durant un mes complet amb arm64 i l'escalat programat ja aplicat, perquè la comparació s'està fent contra un número que encara no s'ha mesurat. Sense aquestes tres dades, totes dues postures són opinions.

(e) La frase. «Tens raó en el principi i per això ja ho estem aplicant: tot el que es dispara per un esdeveniment i mor en segons ja és a Lambda. La botiga és el contrari —un procés que viu esperant peticions i manté memòria cau i connexions—, i per a això Fargate costa cinquanta dòlars més al mes i ens estalvia una reescriptura, un RDS Proxy i les arrencades en fred del divendres a les set.»

Les instàncies han desaparegut. La botiga de MercadoFresco s'executa ara sobre Fargate, i ja no existeix cap màquina que la Marta pugui llistar, dimensionar, apedaçar o deixar-se encesa.

Tens clar què desapareix —l'AMI, l'apedaçament de l'amfitrió, l'escalat del clúster, l'empaquetatge de tasques, la capacitat ociosa i fins i tot el límit d'ENI per instància— i què continua sent teu: la imatge, la CPU i la memòria, la xarxa i els permisos. Amb la frase que ordena la resta: Fargate no elimina la feina d'operar una aplicació, elimina la feina d'operar un servidor. I amb el model de recursos real: les combinacions vàlides de CPU i memòria, els 20 GB d'emmagatzematge efímer ampliables a 200, i la decisió de dimensionar amb el percentil 95 de Container Insights més un 30 %, perquè aquí sobredimensionar es paga des del primer segon. Més arm64 amb Graviton, que baixa el servei de 88 a 70 USD mensuals amb docker buildx i una setmana de prova a preproducció.

Tens les diferències operatives i què fer amb cadascuna: ECS Exec en lloc d'SSH, auditat a CloudTrail i amb la regla que serveix per diagnosticar i no per arreglar; FireLens amb Fluent Bit com a sidecar on abans hi havia un DaemonSet, amb awslogs com a opció per omissió perquè el sidecar costa CPU a cada tasca; i awsvpc com a únic mode de xarxa, que ja no és una restricció sinó la manera normal de treballar. I tens el número que justifica el mòdul sencer: de 120 segons a 35-45 fins que una tasca nova rep trànsit, amb el desglossament per fases i el que significa el divendres a les 19:00 quan el trànsit passa de 300 a 900 comandes/hora en vuit minuts.

Tens la migració completa: definició de tasca sense canvis perquè ja declarava FARGATE, subxarxes privades snet-mercadofresco-app-a i -b sense IP pública, grup de seguretat per tasca, i els punts d'enllaç de VPC del camí crític —amb l'anàlisi honesta que set punts d'enllaç en dues AZ surten més cars que el NAT, i la decisió raonada de posar només els quatre que importen—. L'autoescalat en tres capes: seguiment de destinació com a base, i sobretot l'escalat programat del divendres, que puja el mínim a 6 a les 16:45 amb Europe/Madrid explícit i costa 4,9 USD al mes. Fargate Spot amb el repartiment base=1, weight 1:4 per als treballadors i el criteri que decideix on entra: només on la interrupció amb dos minuts d'avís es reintenta sola. Les tasques programades amb EventBridge Scheduler per a la càrrega nocturna a Redshift, amb finestra flexible, reintents i DLQ. I el pipeline amb blue/green canari de CodeDeploy sobre tg-mercadofresco-tienda i -verde, que baixa la restauració de 4 minuts a menys d'1 perquè revertir és moure un oient; tot això en vint línies de CDK amb ApplicationLoadBalancedFargateService.

I tens la comparativa honesta Fargate enfront d'EC2 enfront de Lambda, amb el criteri que resol la majoria dels dubtes —si el procés viu esperant peticions, és Fargate; si es desperta davant d'un esdeveniment i mor, és Lambda; si necessites el control de la màquina, és EC2— i la decisió component a component de MercadoFresco, en la qual EC2 ja no apareix en cap fila.

Queda una pregunta que algú de l'equip farà aquesta mateixa setmana, i que mereix una resposta seriosa en lloc d'un arronsament d'espatlles: tothom parla de Kubernetes. És l'estàndard de facto de l'orquestració de contenidors, té un ecosistema enorme, funciona igual a qualsevol núvol i hi ha moltíssima gent que en sap. Ens estem equivocant quedant-nos a ECS?

A 10-03, «Amazon EKS», es respon amb dades i no amb preferències. Veuràs què és Kubernetes i què resol que ECS no, el seu vocabulari mínim però real, què gestiona EKS i què continua sent teu, les quatre opcions de còmput inclòs Auto Mode, els manifests complets del desplegament de la botiga amb sondes, Ingress i l'AWS Load Balancer Controller, IRSA i Pod Identity com a equivalents del rol de tasca, Karpenter per als nodes, i l'argument central que gairebé ningú no posa per escrit: el cost ocult de les actualitzacions de versió. Amb la comparativa ECS enfront d'EKS i la decisió raonada de MercadoFresco, juntament amb els criteris objectius que la canviarien.