Informàtica al núvol explicada: els 11 conceptes d'arquitectura que has de saber (Masterclass 4K).

Què cobreix aquest vídeo

• - La Muralla de l'Arquitectura i el Projecte Mestre
• - 01. Escalada Vertical vs. Horitzontal
• - 02. Arquitectura d'Equilibri de Càrrega (L4 vs. L7 i Comprovacions de Salut)
• - 03. Autoescalat i Elasticitat
• - 04. Sense Servidor (FaaS i Firecracker MicroVMs)

Transcripció traduïda

Traduït de la narració original en anglès. L'àudio i els subtítols disponibles estan controlats per YouTube.

- La Muralla de l'Arquitectura i el Projecte Mestre

0:00 Tot enginyer de programari eventualment s'enfronta a la muralla de l'arquitectura al núvol. Construeixes una aplicació al teu portàtil, la publiques en producció, i en el moment en què arriben usuaris reals, els servidors fallen, les connexions de la base de dades s'esgoten i la teva factura d'AWS sembla un número de telèfon. La majoria dels desenvolupadors intenten resoldre l'enginyeria al núvol memoritzant tres-cents acrònims de productes d'AWS diferents. Però la computació al núvol real no consisteix a memoritzar catàlegs de venedors: es construeix sobre onze primitives arquitectòniques fonamentals.

0:34 En aquesta masterclass, recorrerem tot el pla empresarial: des de l'escalat i l'equilibri de càrrega fins a la tecnologia sense servidor, el desacoblament basat en esdeveniments, les jerarquies d'emmagatzematge i la xarxa al núvol. Dominant aquests onze conceptes, podràs dissenyar qualsevol backend a AWS, GCP o Azure. Això és The Daily Diff, des de dins.

- 01. Escalada Vertical vs. Horitzontal

0:57 Concepte número u: Escalabilitat. Quan la teva aplicació experimenta un creixement de tràfic, tens dues maneres fonamentalment diferents de gestionar la càrrega: l'escalabilitat vertical o l'escalabilitat horitzontal. L'escalabilitat vertical, o "escalar cap amunt", significa agafar la teva màquina existent i afegir-hi més recursos: actualitzar de quatre nuclis de CPU a trenta-dos, o canviar trenta-dos gigabytes de RAM per cent vint-i-vuit. L'escalabilitat vertical no requereix canvis arquitectònics: el teu codi

1:28 i la base de dades es mantenen exactament iguals. Però arriba a un brutal límit de hardware. Cap màquina del món té deu mil nuclis de CPU, i les instàncies de gamma alta tenen un preu exponencialment superior. L'escalabilitat horitzontal, o "escalar cap a fora", significa mantenir els teus servidors petits i de preu de mercaderia, però executant múltiples instàncies en paral·lel darrere d'un encaminador. Si una instància cau, els nodes restants absorbeixen el tràfic amb zero temps d'inactivitat. La regla d'or de l'escalabilitat horitzontal és

2:01 la manca d'estat: els servidors de la teva aplicació no poden emmagatzemar sessions d'usuari, arxius pujats o l'estat als seus discos locals. L'estat ha de residir en una base de dades o memòria cau externa, permetent que qualsevol node gestioni qualsevol sol·licitud d'usuari.

- 02. Arquitectura d'Equilibri de Càrrega (L4 vs. L7 i Comprovacions de Salut)

2:17 Concepte número dos: Balanç de Càrrega. L'escalabilitat horitzontal sona molt bé sobre el paper, però introdueix un problema immediat: quan deu mil usuaris accedeixen al teu nom de domini, quin servidor específic rep el seu tràfic? Un balancejador de càrrega actua com un proxy invers situat entre la internet pública i el teu clúster de backend privat. Accepta connexions TCP o HTTP entrants i distribueix les sol·licituds entre les teves instàncies sanes.

2:47 Els balancejadors de càrrega operen en dues capes de xarxa principals. Els balancejadors de càrrega de xarxa de capa 4 operen a la capa de transport, encaminant paquets TCP i UDP bruts basats en l'adreça IP i el port amb latència de microsegons i milions de sol·licituds per segon. Els balancejadors de càrrega d'aplicació de capa 7 inspeccionen el protocol HTTP en si mateix: llegint rutes d'URL, capçaleres de sol·licitud, cookies i mètodes HTTP. Això permet l'encaminament basat en rutes: enviar sol·licituds /api al teu clúster de backend i sol·licituds /static a un

3:25 emmagatzematge d'objectes. Crucialment, els balancejadors de càrrega realitzen comprovacions de salut actives. Cada pocs segons, el balancejador fa ping a un punt final de salut de cada instància. Si una instància llança tres errors consecutius de cinc-cents o no respon, és automàticament expulsada del pool amb zero sol·licituds perdudes.

- 03. Autoescalat i Elasticitat

3:45 Concepte número tres: Autoescalat. Si la teva aplicació web necessita dos servidors a les tres del matí, però vint servidors durant un llançament al migdia, fer clic manualment als botons de la consola del núvol és un camí garantit cap a temps d'inactivitat i fallida. L'autoescalat aporta elasticitat dinàmica als grups de servidors horitzontals. Un Grup d'Autoescalat monitoritza mètriques de rendiment com l'ús mitjà de la CPU, l'E/S de xarxa o la profunditat de la cua d'espera. Quan l'ús mitjà de la CPU supera un llindar definit —digues,

4:19 el setanta per cent durant tres minuts consecutius— l'autoescalador llança automàticament noves màquines virtuals, les registra amb el teu balancejador de càrrega i comença a encaminar el tràfic. Igualment important és l'escalat "cap a dins": quan l'onada de tràfic retrocedeix, l'autoescalador tanca les instàncies sobrants perquè deixis de pagar per la computació inactiva. Per evitar el "flapping" —on els servidors es creen i destrueixen ràpidament en un bucle sense fi—, els arquitectes del núvol configuren períodes de refredament. Concepte número quatre: Sense servidor.

- 04. Sense Servidor (FaaS i Firecracker MicroVMs)

4:53 Durant anys, els equips de màrqueting van presentar el "sense servidor" com a codi màgic executant-se al cel. En realitat, "sense servidor" encara utilitza servidors, però no els posseeixes, els parcheges ni els pagues quan no s'executa cap codi. Amb Function-as-a-Service com AWS Lambda o Google Cloud Functions, escrius una funció de controlador independent. Quan es produeix una sol·licitud HTTP, una càrrega de fitxers S3 o un canvi de base de dades, el temps d'execució al núvol inicia una

5:23 micro-màquina virtual efímera com Firecracker en menys de cinc mil·lisegons. El teu codi s'executa, retorna una resposta i s'apaga. Si ningú visita la teva pàgina web durant tres mesos, la teva factura de computació és exactament zero dòlars i zero cèntims. Si un milió d'usuaris l'ataquen simultàniament, el proveïdor posa en marxa un milió de micro-VMs concurrents. Les compensacions d'enginyeria són reals: latència de "cold start" en l'engegada de nous temps d'execució, un límit d'execució estricte de quinze minuts a Lambda, i una estricta absència d'estat.

5:55 El "sense servidor" és insuperable per a canals d'esdeveniments i APIs esporàdiques, però pobre per a WebSockets persistents o execucions d'entrenament de diverses hores.

- 05. Arquitectura Orientada a Esdeveniments (EDA i Desacoblament)

6:05 Concepte número cinc: Arquitectura Orientada a Esdeveniments, o EDA. En les arquitectures tradicionals, els serveis es comuniquen de forma síncrona. El teu servei de pagament truca a pagament, pagament truca a inventari, inventari truca a frau i frau truca a correu electrònic. Això crea la cascada síncrona de la fatalitat. Si el proveïdor de correu electrònic de tercers experimenta un problema de xarxa i triga deu segons a respondre, tota la sol·licitud de pagament del teu client s'esgota amb un error. En una arquitectura orientada a esdeveniments, els serveis estan completament desacoblats.

6:37 Quan un client fa clic a comprar, el servei de pagament no truca a serveis posteriors. Simplement publica un esdeveniment anomenat OrderPlaced a un Bus d'Esdeveniments central com Amazon EventBridge o un tema SNS. El pagament es completa en cinquanta mil·lisegons. Els treballadors posteriors per al pagament, la deducció d'inventari i els rebuts per correu electrònic extreuen missatges independentment de les seves pròpies cues SQS dedicades. Si el servei de correu electrònic cau durant una hora, els missatges esperen de forma segura emmagatzemats en la cua sense cap comanda perduda.

- 06. Orquestració de Contenidors (Docker i Kubernetes)

7:13 Concepte número sis: Orquestració de Contenidors. Docker va resoldre l'empaquetatge: encapsula el codi de la teva aplicació, les biblioteques del sistema, la configuració i l'entorn d'execució en una imatge immutable que s'executa de manera idèntica al teu MacBook i al núvol. Però empaquetar un contenidor és fàcil. Executar cinc-cents contenidors en cinquanta màquines virtuals físiques és on l'enginyeria es trenca. Per això existeixen els orquestradors de contenidors com Kubernetes i AWS ECS.

7:41 Un orquestrador proporciona un pla de control: un servidor API, un magatzem d'estats etcd i un planificador intel·ligent. Declares l'estat desitjat: vull deu rèpliques del meu servei d'autenticació amb dos gigabytes de RAM cadascuna. El planificador inspecciona el clúster, col·loca els "pods" als nodes amb memòria lliure, configura la xarxa interna i reconcilia contínuament la realitat. Si un node pateix un error de hardware, Kubernetes detecta la pèrdua i reprograma instantàniament tots els "pods" desplaçats a

- 07. Els 4 Pilars de l'Emmagatzematge al Núvol (S3, EBS, DBs i Redis)

8:16 nodes saludables. Concepte número set: La Jerarquia d'Emmagatzematge al Núvol. Els principiants sovint tracten l'emmagatzematge al núvol com un únic cub on aboquen fitxers. En l'arquitectura de producció, l'emmagatzematge es divideix en quatre pilars diferents basats en patrons d'accés i latència. El primer és l'Emmagatzematge d'Objectes, com Amazon S3 o Google Cloud Storage. Accedeixes als fitxers mitjançant API REST HTTP utilitzant simples crides PUT i GET. Ofereix capacitat horitzontal infinita a dos cèntims per gigabyte al mes,

8:49 fent-lo ideal per a vídeo, càrregues d'usuaris, registres i còpies de seguretat. El segon és l'Emmagatzematge en Bloc, com Amazon EBS. Són discos durs virtuals muntats directament a una màquina virtual específica mitjançant interconnexions d'alta velocitat. Es formaten en sistemes de fitxers estàndard com ext4, suportant un accés ràpid de lectura i escriptura aleatori requerit pels motors de bases de dades. El tercer són les Bases de Dades Gestionades: motors relacionals com PostgreSQL a RDS que proporcionen transaccions ACID i unions complexes,

9:21 i motors NoSQL com DynamoDB que ofereixen una latència d'un sol dígits de mil·lisegons a escala massiva. I el quart són les Caches en Memòria com Redis. Llegir dades de la RAM triga microsegons en lloc de mil·lisegons. Les caches se situen davant de la teva base de dades, protegint-la del tràfic de lectura repetit i gestionant les fitxes de sessió d'usuari volàtils.

- 08. Alta Disponibilitat i els Nous (Conmutació per Error Multi-AZ)

9:44 Concepte número vuit: Alta Disponibilitat, o HA. La disponibilitat respon a una pregunta: quin percentatge de temps la teva aplicació està operativa i accessible pels usuaris? En els contractes empresarials, la disponibilitat es mesura en nous. Dos nous, o noranta-nou per cent de disponibilitat, permet més de tres dies i mig d'inactivitat cada any. Quatre nous redueix el temps d'inactivitat permès a cinquanta-dos minuts, i cinc nous permet amb prou feines cinc minuts de temps d'inactivitat total per

10:15 any. Per aconseguir alta disponibilitat, has d'eliminar punts únics de fallada en diferents dominis de fallada. Al núvol, això significa desplegar en múltiples zones de disponibilitat. Una zona de disponibilitat no és un sol rack: és un o més centres de dades físics diferents a quilòmetres de distància amb energia i refrigeració independents. En executar instàncies actives a la Zona A i la Zona B amb replicació síncrona de la base de dades, un llamp o un tall de fibra que desconnecta tota una instal·lació física resulta en una conmutació per error automatitzada.

10:50 en trenta segons sense intervenció humana.

- 09. Durabilitat vs. Disponibilitat (Per què 11 Nous no és Temps d'Activitat)

10:53 Concepte número nou: Durabilitat versus Disponibilitat. Aquesta és la trampa conceptual més comuna en les entrevistes d'arquitectura al núvol. Els enginyers sovint utilitzen les paraules de manera intercanviable, però mesuren propietats completament diferents. La Disponibilitat mesura el temps d'activitat: puc fer una trucada a l'API per llegir o escriure les meves dades ara mateix? dades ara mateix? La Durabilitat mesura la preservació: les meves dades sobreviuran sense corrupció permanent de bits, corrupció o destrucció durant deu anys?

11:24 Mireu Amazon S3 Standard. El seu Acord de Nivell de Servei ofereix un noranta-nou coma nou per cent de disponibilitat, que permet aproximadament quaranta-tres minuts de temps d'inactivitat cada mes on una sol·licitud d'API podria retornar un error cinc-cents. Però S3 promet onze nous de durabilitat: noranta-nou coma nou nou nou nou nou nou nou nou nou per cent. Si emmagatzemeu deu milions de fitxers a S3, estadísticament podeu esperar perdre de mitjana un fitxer cada deu mil anys.

11:56 de mitjana un fitxer cada deu mil anys. S3 aconsegueix això codificant objectes per esborrat i replicant fragments a través d'almenys tres centres de dades geogràficament separats. menys tres centres de dades geogràficament separats. Durant una interrupció important de la xarxa regional, S3 podria estar temporalment no disponible, però les vostres dades mai es destrueixen.

- 10. Infraestructura com a Codi (Terraform vs. Console Drift)

12:14 Concepte número deu: Infraestructura com a Codi, o IaC. En els inicis de la computació al núvol, els enginyers iniciaven sessió a la consola de gestió web d'AWS i feien clic manualment per crear màquines virtuals, configurar subxarxes i adjuntar grups de seguretat. La indústria anomena això ClickOps, i en producció, és un desastre absolut. Els canvis manuals a la consola no tenen registre d'auditoria, ni mecanisme de retrocés, i inevitablement causen una deriva de configuració entre els entorns de preparació i producció. amb eines d'infraestructura com a Codi com Terraform,

12:48 com a Codi com Terraform, OpenTofu, Pulumi o AWS CDK, definiu la vostra arquitectura completa al núvol en fitxers de configuració declaratius emmagatzemats a Git. Cada canvi a un port obert o a una rèplica de base de dades passa per una sol·licitud d'extracció i una revisió per parells. sol·licitud d'extracció i revisió per parells. Executar terraform plan previsualitza la diferència exacta de l'API abans que es toqui res, i posar en marxa una rèplica idèntica de la vostra pila de producció triga quatre minuts en lloc de quatre setmanes.

- 11. Xarxes al Núvol (VPC, Subxarxes, NAT i Grups de Seguretat)

13:20 Concepte número onze: Xarxes al Núvol i Núvols Privats Virtuals. Quan desplegueu servidors al núvol, no estan exposats a la Internet pública en brut. Viuen dins d'un límit aïllat definit per programari anomenat VPC. anomenat VPC. Dins de la vostra VPC, assigneu un espai d'adreces IP privades com deu-punt-zero-punt-zero-punt-zero barra setze, i el dividiu en subxarxes públiques i privades. en subxarxes públiques i privades. Una subxarxa pública té una ruta directa a una passarel·la d'Internet.

13:51 Conté actius orientats al públic com els vostres balancejadors de càrrega d'aplicacions i passarel·les NAT. És l'única part de la vostra xarxa que posseeix adreces IP públiques. Els vostres servidors d'aplicacions i bases de dades de producció viuen estrictament en subxarxes privades sense IP públiques i zero rutes d'entrada des d'Internet. internet. Quan els vostres servidors backend necessiten descarregar actualitzacions de seguretat, el seu trànsit de sortida es dirigeix a través de la passarel·la NAT a la subxarxa pública. el seu trànsit de sortida es dirigeix a través de la passarel·la NAT a la subxarxa pública. Envoltant cada instància hi ha Grups de Seguretat: tallafocs virtuals amb estat que fan complir el principi de mínim privilegi. virtuals que fan complir el principi de mínim privilegi.

- 12. El Projecte Empresarial Complet i Veredicte

14:28 El vostre grup de seguretat de bases de dades només accepta connexions al port 5432 estrictament del grup de seguretat dels vostres servidors d'aplicacions, fent matemàticament impossible la penetració externa. Quan s'amplia, aquests onze primitives es connecten en un sistema cohesionat. El vostre DNS es dirigeix a un balancejador de càrrega en una subxarxa pública, els grups d'escalat automàtic gestionen els pics de trànsit en diverses zones de disponibilitat, els busos d'esdeveniments desacoblen els treballadors del backend, i tota la vostra pila es desplega des de Git utilitzant Infraestructura com a Codi. desplegada des de Git utilitzant Infraestructura com a Codi.

15:02 Veredicte de la classe magistral d'avui: SHIP IT. Deixeu de memoritzar centenars d'acrònims de màrqueting al núvol. Dominar aquests onze patrons d'arquitectura, desacoblar el vostre estat, i construir sistemes que no puguin fallar. Digueu-me quin concepte de núvol us va donar el major maldecap quan vau començar a construir als comentaris. construint als comentaris. I per obtenir la fulla de trucs d'arquitectura completa, subscriviu-vos al butlletí a the daily diff dot dev,

15:28 enllaç a continuació. I aquesta és la diferència per avui. Sóc en Niko d'Axrisi. Fusionar amb responsabilitat.

Fonts

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io