Amb la cistella i les sessions fora, mercadofresco-pedidos respira. Les 180.000 escriptures diàries han desaparegut, el VACUUM ja no competeix per l'E/S els divendres a la tarda i el 35 % de la capacitat de la instància ha quedat lliure. Però la instància continua sent la mateixa que vam crear a 02-04: una db.t3.small amb PostgreSQL 16, Multi-AZ, una rèplica de lectura i un emmagatzematge que creix 12 GB al mes.

I continua tenint tres problemes que el mòdul 5 va deixar documentats. La commutació per error de Multi-AZ triga entre 60 i 120 segons, que un divendres a les 19:00 són entre 900 i 1.800 comandes en l'aire. El retard de la rèplica de lectura puja a 8 segons al pic, prou perquè un client confirmi una comanda i no la vegi al seu historial. I la instància es paga sencera les 24 hores, també de matinada, quan hi ha tres comandes per hora.

Amazon Aurora és la base de dades relacional que AWS va dissenyar específicament per al núvol, compatible amb PostgreSQL i MySQL, però amb una arquitectura interna completament diferent de la d'RDS. En aquesta lliçó la Marta entén aquesta arquitectura, decideix entre instàncies aprovisionades i Serverless v2 amb el perfil de càrrega real de MercadoFresco, i migra mercadofresco-pedidos amb una aturada de servei de menys de dos minuts.

Avís de cost. Aurora és més car per hora de còmput que RDS i, segons el model, cobra l'E/S a part. Un clúster de proves oblidat costa desenes de dòlars al mes. Esborra el que creïs per practicar. Totes les dades són fictícies i les xifres, estimacions d'eu-west-1.

Avís de compliment. mercadofresco-pedidos conté dades personals de clients (nom, adreça de repartiment, telèfon, historial de compra). Qualsevol operació d'aquest mòdul —clonació, restauració de còpia, rèplica— crea una còpia completa d'aquestes dades i queda subjecta al RGPD. El xifratge amb alias/mercadofresco-datos és obligatori, i l'anonimització abans de lliurar dades a desenvolupament ha d'estar revisada pel responsable de protecció de dades.

1. Què és Aurora i en què es diferencia d'RDS
2. La separació entre còmput i emmagatzematge
3. El volum distribuït: sis còpies sobre tres zones
4. Per què desapareixen els checkpoints
5. Components del clúster
6. Punts d'enllaç: clúster, lectura i personalitzats
7. Commutació per error i temps reals
8. Rèpliques de lectura amb retard de mil·lisegons
9. Compatibilitat amb PostgreSQL i MySQL
10. Aurora Serverless v2 i les unitats ACU
11. Quan compensa Serverless v2 i quan no
12. Escalat automàtic de rèpliques de lectura
13. Còpies contínues, PITR i backtrack
14. Clonació ràpida per còpia en escriptura
15. Global Database, Aurora ML i consultes paral·leles
16. Migració de mercadofresco-pedidos a Aurora
17. Comprovacions abans i després amb les mètriques del mòdul 5
18. Blue/Green deployments per a esquema i versions
19. Costos i el model I/O-Optimized
20. Errors habituals i consells
21. Exercicis
22. Conclusió

RDS és PostgreSQL —el mateix programari que s'instal·laria en un servidor propi— gestionat per AWS: AWS aplica els pedaços, fa les còpies i gestiona la commutació per error, però el motor i el seu emmagatzematge són els de sempre, amb un volum EBS connectat a una instància.

Aurora reescriu la capa d'emmagatzematge. Conserva el motor de consultes de PostgreSQL —per això els SELECT de MercadoFresco funcionen sense tocar ni una línia— però substitueix tot el que hi ha per sota per un servei d'emmagatzematge distribuït propi.

Aquesta és la idea central i d'ella se'n deriven gairebé tots els avantatges. En una base de dades tradicional, la instància és la base de dades: conté el motor, la memòria cau i els fitxers de dades. Si la instància mor, cal arrencar-ne una altra i recuperar les dades.

A Aurora, la instància només conté el motor de consultes i la memòria cau. Les dades viuen en un servei d'emmagatzematge independent, compartit per totes les instàncies del clúster.

Les conseqüències pràctiques són directes:

• Afegir una rèplica no copia dades. S'arrenca una instància que es connecta al volum que ja existeix. Triga minuts, no hores, i no consumeix E/S de l'escriptor.
• L'emmagatzematge creix sol. No cal aprovisionar 500 GB «per si de cas» ni ampliar el volum a les tres de la matinada. Es paga pel que es fa servir, en increments de 10 GB.
• La commutació per error no mou dades. Es promou una rèplica que ja està connectada al mateix volum; és un canvi de rol, no una recuperació.
• Canviar la mida de la instància és ràpid, perquè les dades no es mouen.

Aurora manté sis còpies de cada bloc de dades, repartides entre tres zones de disponibilitat, dues per zona. El quòrum d'escriptura és de 4 de 6 i el de lectura, de 3 de 6.

Aquests números tenen una conseqüència concreta i verificable:

És a dir, Aurora tolera perdre una zona de disponibilitat sencera sense perdre capacitat d'escriptura, i una zona més un disc addicional sense perdre capacitat de lectura. Compareu-ho amb mercadofresco-pedidos a RDS Multi-AZ: dues còpies, i perdre la principal exigeix una commutació d'un a dos minuts.

A més, la reparació és automàtica i per blocs: si un segment es corromp, Aurora el reconstrueix des del quòrum en segon pla sense que ningú se n'assabenti.

PostgreSQL escriu primer al registre de refer (WAL) i periòdicament aboca les pàgines modificades de memòria al disc: això és un checkpoint. És una operació d'E/S intensa i periòdica que produeix els pics de latència que es veuen al tauler mercadofresco-produccion cada pocs minuts.

Aurora només envia el registre de refer a l'emmagatzematge. No envia pàgines de dades: són els nodes d'emmagatzematge els que apliquen els registres i materialitzen les pàgines, de manera contínua i distribuïda. Conseqüències:

• No hi ha checkpoints i desapareixen els seus pics de latència.
• El trànsit d'escriptura cap a l'emmagatzematge es redueix molt —AWS parla d'un ordre de magnitud— perquè s'envia el registre, no les pàgines completes.
• La recuperació després d'una fallada és gairebé instantània: no cal reproduir un registre llarg, perquè l'emmagatzematge ja està al dia.

Aquesta és la raó tècnica que Aurora rendeixi més que PostgreSQL sobre EBS amb la mateixa classe d'instància, i que la commutació per error baixi de minuts a segons.

Detall que confon molta gent: hi ha dos grups de paràmetres. El de clúster conté el que afecta totes les instàncies i el volum (rds.logical_replication, zona horària); el d'instància conté l'específic de cadascuna (work_mem, max_connections). Canviar el paràmetre al lloc equivocat no dona error: simplement no fa res.

Aurora ofereix diversos noms DNS, i fer servir el que no toca és un error habitual i car.

El punt d'enllaç de clúster segueix la commutació per error: quan es promou una rèplica, el DNS hi apunta en segons. Per això l'aplicació l'ha de fer servir sempre, i per això cal assegurar-se que el client no guarda el DNS a la memòria cau més enllà del TTL (Java, per defecte, el guarda per sempre: cal ajustar networkaddress.cache.ttl).

Els punts d'enllaç personalitzats resolen un problema real que MercadoFresco tenia a 02-04: si la Sara llança una consulta pesada contra el punt d'enllaç de lectura, pot caure-li a la mateixa rèplica que serveix la botiga. Amb un punt d'enllaç personalitzat que agrupi només aurora-mf-lector-informes, les seves consultes queden aïllades en una instància que ningú més fa servir.

Quan la instància d'escriptura falla, Aurora promou una rèplica. Com que totes comparteixen volum, no hi ha dades per copiar ni registre per reproduir.

La prioritat de nivells (tiers) mereix atenció: Aurora promou la rèplica de nivell més baix i, en cas d'empat, la de més mida. Si MercadoFresco posa la rèplica d'informes al nivell 15, es garanteix que mai acabi sent l'escriptor de producció una instància dimensionada per a una altra cosa.

Traduït al divendres a les 19:00: amb RDS es perden entre 900 i 1.800 comandes de finestra; amb Aurora, entre 150 i 450. No és zero —cal reintentar igualment— però és la diferència entre un incident i un parpelleig.

A RDS, una rèplica de lectura és una altra base de dades que rep el registre i l'aplica. Aquesta feina triga, i al pic del divendres mercadofresco-pedidos-lectura acumula 8 segons de retard.

A Aurora, la rèplica llegeix del mateix volum. No aplica registres per materialitzar dades: només invalida les pàgines que tingui a la memòria cau. El retard típic és de 10 a 20 mil·lisegons.

La conseqüència funcional és la que li importa al Luis: avui, després de confirmar una comanda, l'aplicació no pot llegir de la rèplica perquè la comanda podria no ser-hi. Amb 15 ms de retard, aquesta lectura passa a ser segura a la pràctica, i tota la càrrega de «mostrar l'historial» pot anar al punt d'enllaç de lectura. Amb un advertiment honest: 15 ms no és zero. Per a la lectura immediatament posterior a una escriptura crítica —comprovar l'estoc abans de cobrar— es fa servir el de clúster.

Aurora ofereix dues edicions i cal triar la que coincideix amb el motor d'origen. MercadoFresco fa servir PostgreSQL 16, així que va a Aurora PostgreSQL: l'aplicació, el controlador, les consultes i les extensions funcionen igual.

El que cal revisar abans de donar la migració per trivial:

• Extensions. Aurora admet un catàleg ampli, però no idèntic al de PostgreSQL. Cal comprovar amb SELECT * FROM pg_available_extensions que les que fa servir MercadoFresco (pg_trgm, postgis per a les zones de repartiment) estan disponibles.
• Versions. Aurora va per darrere de la versió més recent de PostgreSQL. Si l'origen és 16 i Aurora ofereix 16.x, no hi ha problema; si l'origen fos 17, caldria esperar.
• Paràmetres. Alguns paràmetres de PostgreSQL no existeixen a Aurora perquè el seu emmagatzematge els fa irrellevants; els relacionats amb els checkpoints en són l'exemple evident.
• Rèplica lògica cap enfora. Funciona, però convé verificar-la si hi ha integracions que la usin.

Aurora Serverless v2 substitueix la classe d'instància fixa per una capacitat que escala de manera contínua, mesurada en ACU (Aurora Capacity Units). Una ACU equival aproximadament a 2 GiB de memòria amb la CPU i la xarxa proporcionals.

Es configura un mínim i un màxim —de 0 a 256 ACU, en increments de 0,5— i Aurora ajusta la capacitat en segons, sense tallar connexions. És la diferència essencial amb la v1, que pausava i reprenia amb aturades de desenes de segons.

Tres decisions de l'ordre que convé entendre. --manage-master-user-password fa que Aurora creï i roti la contrasenya a Secrets Manager, integrant-se amb el que vam muntar a 04-03 en comptes de duplicar el mecanisme. MinCapacity=0.5 no és zero: el clúster no s'atura mai del tot, així que la primera consulta del dia no espera cap arrencada. I MaxCapacity=8 és el sostre que limita la factura si una consulta es descontrola: sense ell, un Seq Scan accidental pot escalar molt i cobrar-ho.

La resposta depèn del perfil de càrrega. Aquest és el de MercadoFresco, mesurat al mòdul 5:

Mitjana ponderada: ≈2,4 ACU. Amb instàncies aprovisionades caldria dimensionar per al pic —una db.r6g.large, 2 vCPU i 16 GiB— i pagar-la les 168 hores de la setmana.

Serverless v2 compensa amb càrrega variable amb valls profundes (el cas de MercadoFresco), en entorns de desenvolupament i preproducció que només es fan servir en horari d'oficina, i quan el pic és difícil de predir. No compensa amb càrrega plana 24×7 —una instància aprovisionada amb Reserved Instances és més barata—, quan cal una factura exactament previsible, o quan la càrrega sostinguda és tan alta que el màxim es toca sempre.

Un matís honest: per ACU, Serverless v2 és més car per unitat de capacitat que una instància aprovisionada equivalent. Només guanya si de debò s'aprofita la vall. Amb la càrrega de MercadoFresco, la vall nocturna són 49 de 168 hores setmanals: s'aprofita, i molt.

Independentment de Serverless v2, Aurora escala el nombre de rèpliques amb Application Auto Scaling, en funció de la CPU mitjana de les rèpliques o del nombre de connexions.

El refredament de reducció (600 s) és més gran que el d'augment (300 s) per la mateixa raó que a l'ASG de 02-01: és preferible escalar ràpid i reduir a poc a poc. I amb Serverless v2, cada rèplica nova escala també la seva capacitat, així que tots dos mecanismes es combinen.

Les còpies són contínues i cap a S3, sense finestra ni impacte en el rendiment, perquè les fa l'emmagatzematge i no la instància. La retenció va d'1 a 35 dies; MercadoFresco en fa servir 14.

El PITR permet restaurar a qualsevol segon dins de la retenció, sempre a un clúster nou. Això és important: no es «desfà» sobre el clúster existent. Restaurar i redirigir l'aplicació porta de 10 a 20 minuts.

El backtrack és diferent i només existeix a Aurora MySQL: rebobina el clúster al mateix lloc, en segons, fins a 72 hores enrere. És l'eina ideal per desfer un UPDATE sense WHERE. Com que MercadoFresco fa servir PostgreSQL, no en disposa, i convé dir-ho clarament perquè és un error freqüent comptar amb backtrack en un clúster PostgreSQL. L'alternativa a PostgreSQL és la restauració PITR a un clúster nou, més lenta però igual d'efectiva.

La clonació crea un clúster nou que comparteix el volum de l'original i només consumeix emmagatzematge propi per als blocs que canviïn: és copy-on-write. Un clon d'una base de dades de 340 GB triga minuts i arrenca ocupant pràcticament zero.

Usos: provar una migració d'esquema amb volum real, reproduir una incidència amb les dades exactes del moment, mesurar l'impacte d'un índex nou abans de crear-lo a producció.

Advertiment de RGPD. Un clon conté totes les dades personals dels clients: noms, adreces, telèfons i historial de compra. Lliurar-lo a desenvolupament sense més és una cessió interna de dades personals que gairebé amb tota seguretat no està emparada per la base legal amb què es van recollir. El procediment correcte a MercadoFresco és: clonar, executar immediatament un guió d'anonimització que substitueixi les dades identificatives per valors sintètics mantenint la distribució estadística, i només llavors donar accés al clon; xifrar-lo amb la mateixa clau, i establir un esborrat automàtic als 7 dies. Aquest procediment ha d'estar documentat i revisat pel responsable de protecció de dades abans de fer-se servir, i la seva execució queda registrada a trail-mercadofresco. Un clon anonimitzat és una eina excel·lent; un clon sense anonimitzar en un portàtil és una bretxa de dades esperant a passar.

I un advertiment de cost: el clon comença barat però creix a mesura que divergeix. Si el Luis executa una migració que reescriu la meitat de les taules, el clon acaba ocupant la meitat de l'original. Els clons són d'usar i llençar; l'esborrat automàtic als 7 dies també és una mesura de cost.

Aurora Global Database replica el clúster a altres regions amb un retard típic inferior a un segon, mitjançant replicació a la capa d'emmagatzematge que no consumeix capacitat de l'escriptor. Permet lectures locals de baixa latència i recuperació regional amb RPO d'aproximadament un segon i RTO d'un minut. MercadoFresco no ho necessita avui —opera a Espanya des d'eu-west-1—, però és la palanca del pla d'expansió a França o Portugal: la lectura del catàleg i de l'historial se serviria localment i les escriptures continuarien viatjant a Irlanda.

Aurora Machine Learning permet cridar SageMaker o Bedrock des de SQL, amb funcions que reben columnes i retornen prediccions. Un cas plausible per a MercadoFresco seria puntuar el risc d'impagament d'una comanda dins de la mateixa consulta. Es menciona perquè se sàpiga que existeix; el seu desenvolupament queda fora d'aquest curs.

Les consultes paral·leles (només a Aurora MySQL) empenyen part del filtratge i l'agregació a la capa d'emmagatzematge, i acceleren molt les consultes analítiques. És temptador per als informes de la Sara, però MercadoFresco fa servir PostgreSQL i, sobretot, aquest problema té una resposta millor: Redshift, a 06-04. Aurora no s'ha de convertir en el magatzem analític.

Hi ha dos camins, i la tria depèn de quanta aturada es tolera.

MercadoFresco fa servir la segona: es crea una rèplica de lectura d'Aurora a partir de la instància RDS, que es manté sincronitzada mitjançant replicació; quan el retard és zero, es promou.

La finestra de commutació, minut a minut: s'activa el mode manteniment de la botiga (una resposta 503 servida des de CloudFront, que es prepara a 03-04); es comprova que el retard és 0; es promou el clúster amb promote-read-replica-db-cluster; es canvia el punt d'enllaç al paràmetre /mercadofresco/produccion/basedatos/endpoint de Parameter Store; es reinicia l'ASG amb una actualització contínua; i es desactiva el mode manteniment. Temps objectiu: 90 segons.

I la regla que no es negocia: la instància RDS original no s'esborra fins passats 7 dies de funcionament estable. Costa 118 USD al mes; una reversió d'emergència sense ella costa moltíssim més.

Sense línia base no hi ha manera de demostrar que la migració va valer la pena. Es captura la setmana anterior i es compara amb la setmana posterior:

Dues comprovacions que no són mètriques i són igual d'obligatòries. Primera, provocar una commutació per error a propòsit amb failover-db-cluster fora d'hora punta i mesurar quant triga de debò l'aplicació a recuperar-se: gairebé sempre el coll d'ampolla no és Aurora sinó el pool de connexions del client, que continua intentant la connexió antiga. Segona, restaurar una còpia i comprovar que les dades estan completes, que és la lliçó que 05-05 va deixar apresa.

Un desplegament blau/verd d'Aurora crea un clúster verd que és una còpia sincronitzada del clúster blau de producció. S'apliquen els canvis en verd —una versió nova del motor, un ALTER TABLE llarg, un índex nou— mentre el blau continua servint; es prova; i el canvi de rol triga menys d'un minut, amb AWS verificant abans que la replicació està al dia.

Avantatges respecte a fer-ho en calent: l'ALTER TABLE sobre una taula de 340 GB no bloqueja res a producció, es pot provar el rendiment real amb la càrrega replicada, i la reversió és tornar a canviar el rol.

Limitacions que cal conèixer: el clúster verd costa diners mentre existeix (es duplica el còmput), no s'admet qualsevol canvi d'esquema —els que trenquen la replicació lògica, com eliminar una columna usada a la clau primària, no— i cal revisar què passa amb les seqüències després del canvi de rol. Per a MercadoFresco és la via per defecte de les actualitzacions de versió i de les migracions d'esquema grans, i es combina amb el que es veurà al mòdul 8.

Aurora cobra quatre conceptes: còmput (per hora d'instància o per ACU-hora), emmagatzematge (per GB-mes), E/S (per milió d'operacions de lectura i escriptura contra el volum) i còpies de seguretat per sobre de la mida del clúster.

L'E/S és la partida imprevisible, i per això existeixen dos models:

Estimació mensual per a MercadoFresco:

Cal dir-ho sense adorns: Aurora surt més car. La justificació no és l'estalvi, és el que es compra amb aquests 162 USD addicionals: una commutació per error de 20 segons en comptes de 96, un retard de rèplica de mil·lisegons en comptes de 8 segons, sis còpies en tres AZ en comptes de dues, clonació per a desenvolupament, blue/green per als canvis d'esquema i capacitat que segueix la demanda. Per a una botiga que factura al pic del divendres, 162 USD al mes és menys que un sol minut de caiguda.

I dues palanques per abaixar-lo: reduir MaxCapacity quan 06-05 tregui la càrrega del catàleg, i avaluar I/O-Optimized si l'E/S creix —amb 36 USD de 280, avui no compensa.

Fer servir el punt d'enllaç d'instància a l'aplicació. Funciona, fins a la commutació per error: llavors l'aplicació continua apuntant a una instància que ara és rèplica i totes les escriptures fallen. Fes servir sempre el punt d'enllaç de clúster.

No ajustar la memòria cau de DNS del client. El punt d'enllaç canvia en segons, però si el client guarda el DNS indefinidament —el comportament per defecte de la JVM— l'aplicació triga minuts o hores a assabentar-se'n. És el motiu més freqüent que una commutació «ràpida» no ho sembli.

Comptar amb backtrack a Aurora PostgreSQL. No existeix: és exclusiu d'Aurora MySQL. A PostgreSQL, el pla per desfer un error humà és la restauració PITR a un clúster nou, i cal haver-lo assajat abans de necessitar-lo.

Posar MinCapacity massa baix. Amb 0,5 ACU, un clúster que porta hores inactiu té la memòria cau freda: la primera consulta del pic pot ser lenta mentre escala. Si el pic és predictible —el divendres ho és— convé pujar el mínim en aquesta franja.

Posar MaxCapacity massa alt «per si de cas». Serverless v2 escala fins on el deixis, i una consulta descontrolada pot passar setmanes facturant 64 ACU sense que ningú se n'adoni. El màxim és un límit de despesa, no una aspiració; acompanya'l d'una alarma sobre ServerlessDatabaseCapacity.

Clonar producció i donar-ho a desenvolupament sense anonimitzar. És un incident de protecció de dades, no una drecera. Anonimitzar és part del procediment, no un extra.

Canviar un paràmetre al grup equivocat. Els paràmetres de clúster i els d'instància són grups diferents i no donen error quan t'equivoques: simplement no fan efecte.

Tractar Aurora com si fos un magatzem analític. És temptador quan es descobreixen les 15 rèpliques i les consultes paral·leles. Continua sent un motor orientat a files: una agregació sobre 40 milions de files serà lenta i cara. Aquesta feina és de Redshift (06-04).

Consell: assaja la commutació per error el primer dia. aws rds failover-db-cluster fora d'hora punta, cronòmetre a la mà i mesurant el que triga l'aplicació, no el clúster. És l'única manera de descobrir el problema de la memòria cau de DNS abans que el descobreixi un divendres.

Consell: posa una alarma sobre ServerlessDatabaseCapacity. Si el clúster porta dies enganxat al màxim, o no està ben dimensionat o hi ha una consulta que s'ha degradat. Totes dues coses convé saber-les abans que arribi la factura.

Dissenya la topologia completa d'aurora-mercadofresco-pedidos sabent que ha d'atendre: la botiga (escriptures i lectures crítiques), l'historial de comandes del client (lectures tolerants a 20 ms de retard), les consultes d'atenció al client (exploratòries, ocasionalment pesades) i l'exportació nocturna cap al magatzem analític.

Especifica: quantes instàncies i en quina AZ, quin nivell de prioritat de promoció assignes a cadascuna, quin punt d'enllaç fa servir cada càrrega, i quina configuració d'escalat automàtic de lectors posaries. Justifica per què l'exportació nocturna no ha de fer servir el punt d'enllaç de lectura general.

Una empresa de subscripció de menjar preparat, amb arquitectura semblant a la de MercadoFresco, té aquest perfil: trànsit pràcticament constant les 24 hores (entre 400 i 600 comandes/hora, sense vall nocturna perquè opera en tres fusos horaris), 1,2 TB de dades, i un pic de tres vegades la càrrega normal el primer dia de cada mes, quan es renoven les subscripcions. La seva factura d'E/S a Aurora seria aproximadament el 34 % del total.

Respon: (a) Serverless v2 o instàncies aprovisionades, i per què?; (b) Standard o I/O-Optimized?; (c) com gestionaries el pic mensual amb l'opció triada?; (d) quines dues mètriques vigilaries per saber si la decisió va ser correcta al cap de tres mesos?

MercadoFresco necessita afegir una columna franja_reparto a la taula pedidos (340 GB, 48 milions de files) amb un valor calculat a partir de l'adreça, i crear un índex sobre ella. A PostgreSQL, ALTER TABLE ... ADD COLUMN amb valor per defecte no volàtil és ràpid, però l'UPDATE massiu posterior i el CREATE INDEX no ho són.

Escriu el pla complet: quin mecanisme d'Aurora fas servir, els passos ordenats, com comproves que el resultat és correcte abans d'exposar-lo, quin és el pla de reversió a cada punt, quin cost addicional té l'operació i en quina franja horària la programaries. Indica també què hauries fet diferent si la base de dades continués a RDS.

Solució 1

Topologia: 4 instàncies.

Punts d'enllaç per càrrega: la botiga fa servir el punt d'enllaç de clúster per a escriptures i per a la lectura immediatament posterior a una escriptura (comprovar l'estoc abans de cobrar). L'historial de comandes fa servir el punt d'enllaç de lectura, perquè 20 ms de retard són acceptables. Atenció al client i l'exportació nocturna fan servir un punt d'enllaç personalitzat que conté només aurora-mf-lector-lotes.

Escalat automàtic: mínim 1 lector i màxim 3 al grup general, amb seguiment d'objectiu sobre RDSReaderAverageCPUUtilization al 60 %, refredament de 300 s en augmentar i 600 s en reduir. aurora-mf-lector-lotes queda fora del grup escalable perquè la seva capacitat es decideix per la finestra nocturna, no per la CPU mitjana.

Per què l'exportació no fa servir el punt d'enllaç de lectura general: perquè aquest punt reparteix entre totes les rèpliques del grup i no hi ha manera d'excloure'n una consulta. Una exportació que llegeix 40 milions de files omple la memòria cau de la rèplica amb pàgines històriques i n'expulsa les pàgines calentes del catàleg —exactament la interferència de rendiment que vam diagnosticar a 06-01, reproduïda dins d'Aurora—. El punt d'enllaç personalitzat l'aïlla en una instància que ningú més fa servir. I el nivell 15 d'aquesta instància garanteix que, si l'escriptor cau, no es promogui la màquina configurada per a lots.

Solució 2

(a) Instàncies aprovisionades. No hi ha vall: la càrrega està entre 400 i 600 comandes/hora les 24 hores, així que l'avantatge estructural de Serverless v2 —deixar de pagar quan no hi ha ningú— no es materialitza mai. Com que per ACU és més car que la capacitat aprovisionada equivalent, en càrrega plana hi surt perdent. A més, amb càrrega constant es poden contractar Reserved Instances a un o tres anys, amb descomptes que Serverless v2 no ofereix de la mateixa manera. La decisió correcta és una instància aprovisionada reservada, dimensionada per a la càrrega normal.

(b) I/O-Optimized. La regla pràctica és que compensa quan l'E/S supera aproximadament el 25 % de la factura, i aquí és el 34 %. I/O-Optimized encareix el còmput un 30 % i l'emmagatzematge força més, però elimina del tot la partida d'E/S; amb 1,2 TB convé fer el càlcul concret d'emmagatzematge, perquè és la partida que més puja. Amb un 34 % d'E/S surt a favor, i com a efecte secundari valuós, la factura passa a ser predictible, que és justament el que una empresa de subscripció necessita per pressupostar.

(c) El pic mensual. Amb instàncies aprovisionades hi ha dues palanques. La principal és l'escalat automàtic de rèpliques de lectura, programat amb antelació per al primer dia del mes: es puja el mínim de lectors la nit anterior i es baixa 24 hores després. Si el pic afecta també l'escriptura —la renovació de subscripcions genera escriptures—, la segona palanca és canviar la classe de la instància d'escriptura, que a Aurora és ràpid perquè les dades no es mouen, aprofitant una finestra de baix trànsit i acceptant una commutació d'uns 20 segons. El que no cal fer és dimensionar la instància per al pic del dia 1 i pagar-la els altres 30.

(d) Dues mètriques al cap de tres mesos. Primera, la utilització mitjana de CPU i memòria de la instància d'escriptura: si està per sota del 30 % de manera sostinguda, es va sobredimensionar i hi ha diners sobre la taula; si supera el 70 % habitualment, no queda marge per al dia 1. Segona, el cost d'E/S que s'hauria pagat a Standard, calculable a partir de VolumeReadIOPs i VolumeWriteIOPs, per verificar que I/O-Optimized continua sent l'opció correcta; si l'aplicació canvia i l'E/S baixa, convé revisar la decisió.

Solució 3

Mecanisme: blue/green deployment d'Aurora. És exactament el cas d'ús per al qual existeix: un canvi d'esquema llarg sobre una taula enorme, que en calent bloquejaria escriptures durant molt de temps.

Passos:

1. Clonar i assajar primer. Abans de tocar producció, un clon per còpia en escriptura per mesurar quant triga de debò l'UPDATE i el CREATE INDEX amb 48 milions de files. Sense aquesta dada, la finestra es planifica a cegues. El clon s'anonimitza i s'esborra en acabar.
2. Crear l'entorn verd amb create-blue-green-deployment. Aurora crea el clúster còpia i el manté sincronitzat per replicació lògica.
3. En verd: ALTER TABLE pedidos ADD COLUMN franja_reparto text; (ràpid, sense valor per defecte volàtil), després l'UPDATE per lots de 50.000 files amb pauses, per no generar una transacció gegant ni disparar el retard de replicació, i finalment CREATE INDEX CONCURRENTLY idx_pedidos_franja ON pedidos (franja_reparto);.
4. Verificar en verd: recompte de files amb la columna emplenada igual al total, distribució de valors raonable, EXPLAIN de les consultes afectades fent servir l'índex nou, i la bateria de proves de l'aplicació apuntant a verd.
5. Comprovar que el retard de replicació és zero i executar el canvi de rol. Menys d'un minut.
6. Vigilar 24 hores amb les alarmes de 05-01, mantenint el clúster antic disponible.
7. Esborrar l'entorn antic als 7 dies.

Reversió: fins al pas 5, s'elimina l'entorn verd i no ha passat res —producció no s'ha tocat en cap moment—. Després del canvi de rol, el clúster antic continua existint i s'hi pot tornar, amb la salvetat important que les escriptures ocorregudes després del canvi no hi són: per això el pas 6 vigila de prop i per això la finestra es tria en baixa activitat.

Cost addicional: el clúster verd duplica el còmput mentre existeix. Si l'operació dura 8 hores i el clúster corre a 4 ACU, són unes 32 ACU-hora, menys de 4 USD, més l'emmagatzematge divergent. És menyspreable davant del risc que elimina.

Franja: dimarts o dimecres de matinada, entre les 02:00 i les 05:00, que és la vall més profunda. Mai un dijous o un divendres, per proximitat al pic; mai un dilluns, perquè si alguna cosa surt malament cal tenir dies laborables al davant.

Què hauria canviat a RDS: no existeix blue/green amb canvi de rol en un minut per a aquest cas, així que el pla hauria estat crear una rèplica de lectura, aplicar-hi els canvis, promoure-la i redirigir —més manual, més lent i amb més aturada—, o bé executar l'UPDATE per lots directament a producció durant diverses nits, vigilant bloquejos i el retard de la rèplica. A més, l'assaig del pas 1 hauria exigit restaurar una instantània completa de 340 GB, amb hores d'espera i cost d'emmagatzematge complet, en comptes d'un clon que arrenca en minuts i gairebé sense ocupar espai. Aquesta diferència —poder assajar barat— és una de les raons menys citades i més útils d'Aurora.

mercadofresco-pedidos ja no és una instància de PostgreSQL sobre EBS: és aurora-mercadofresco-pedidos, un clúster amb el mateix motor i una capa d'emmagatzematge completament diferent. Entens aquesta diferència i d'on surten els seus avantatges: la separació entre còmput i emmagatzematge, que converteix afegir una rèplica en arrencar una instància sobre dades que ja existeixen; el volum distribuït en sis còpies sobre tres AZ, amb quòrum de 4 de 6 per escriure i 3 de 6 per llegir, que tolera perdre una zona sencera sense deixar d'acceptar comandes; i la desaparició dels checkpoints, perquè Aurora només envia el registre de refer i són els nodes d'emmagatzematge els que materialitzen les pàgines.

Coneixes els components del clúster i —el que més incidents evita— els punts d'enllaç: el de clúster que segueix la commutació per error i que l'aplicació ha de fer servir sempre, el de lectura per al que tolera 15 ms de retard, el d'instància que mai ha d'aparèixer a l'aplicació, i els personalitzats que aïllen els informes i l'exportació nocturna perquè no enverinin la memòria cau de la rèplica que serveix la botiga. Amb la commutació per error de 10 a 30 segons en comptes de 96, la prioritat per nivells perquè mai es promogui la instància de lots, i el retard de rèplica en mil·lisegons que per fi permet servir l'historial del client des d'una rèplica.

Saps decidir entre Serverless v2 i aprovisionada amb el perfil de càrrega real: 2,4 ACU de mitjana davant d'un pic de 8, amb 49 de 168 hores setmanals en vall nocturna, és el cas en què Serverless v2 guanya; càrrega plana 24×7 és el cas en què perd, perquè per ACU és més car. I saps que un MinCapacity massa baix deixa la memòria cau freda i un MaxCapacity massa alt és una factura sense fre. Domines les còpies contínues cap a S3 sense impacte, el PITR que sempre restaura a un clúster nou, que el backtrack no existeix a PostgreSQL per molt que es digui el contrari, i la clonació per còpia en escriptura que permet al Luis assajar una migració amb 340 GB reals en minuts —amb el procediment d'anonimització, xifratge i esborrat als 7 dies que el RGPD exigeix i que ha de revisar el responsable de protecció de dades—.

La migració es va fer amb rèplica de lectura promoguda i 90 segons d'aturada, no amb instantània i quatre hores, i es va mesurar: TiempoConfirmacionPedido p99 d'1.900 ms a menys de 900, ReplicaLag de 8 segons a menys de 100 ms, commutació de 96 s a menys de 30. Amb la instància RDS original intacta durant set dies, un simulacre de commutació executat a propòsit i una restauració verificada. I amb el compte posat sobre la taula sense adorns: de 118 a 280 USD al mes, perquè Aurora no es tria per estalviar sinó per comprar disponibilitat, i 162 USD és menys que un minut de caiguda un divendres. Més blue/green com a via per defecte per als canvis d'esquema grans i les versions del motor.

Queda una càrrega que Aurora no resoldrà per moltes rèpliques que hi posem. Els informes de la Sara continuen agregant entre 6 i 40 milions de files per fer servir 4 columnes de 40, i continuen llegint files completes, sense comprimir i sense paral·lelitzar, perquè Aurora —com PostgreSQL— és un motor orientat a files i a transaccions. Aïllar-los en un punt d'enllaç personalitzat evita que enverinin la botiga, però no els fa ràpids: continuen trigant minuts, i la Sara continua esperant. A 06-04, «Amazon Redshift», aquests informes surten definitivament de la base de dades transaccional: veurem l'emmagatzematge columnar i l'execució massivament paral·lela, el model en estrella amb hechos_pedidos i les seves dimensions, les claus de distribució i d'ordenació, la càrrega amb COPY des de mercadofresco-informes-analitica, Redshift Serverless, i la comparació honesta amb Athena per saber quan cal un magatzem de dades i quan no.