Comencem la Part IV fent un salt: de servidors solts a arquitectures que escalen. La primera peça clau és el balancejador de càrrega, el component que reparteix el trànsit entre diversos servidors. En aquest capítol aprendràs a fer-lo servir i, en aquest primer subcapítol, a triar entre els dos tipus principals d’AWS: l’Application Load Balancer (ALB) i el Network Load Balancer (NLB).

Al Capítol 12 vas muntar un servidor. Però què passa si...?

• Reps molt trànsit i un servidor no dona l’abast.
• Aquest servidor cau: la teva web sencera deixa de funcionar.

La solució és tenir diversos servidors i posar alguna cosa davant que reparteixi les peticions entre ells. Aquest «alguna cosa» és el balancejador de càrrega (load balancer).

Un balancejador de càrrega és com el maître d’un restaurant molt concorregut: a la porta, va assignant a cada client que arriba una taula lliure, repartint-los entre tots els cambrers perquè cap d’ells se saturi.

Beneficis immediats:

• Reparteix la càrrega: cap servidor se satura.
• Alta disponibilitat: si un servidor cau, el balancejador deixa d’enviar-li trànsit i utilitza els altres. Els usuaris ni se n’adonen.
• Punt d’entrada únic: els usuaris accedeixen a una sola adreça, sense saber quants servidors hi ha al darrere.

AWS ofereix diversos balancejadors, però els dos que has de conèixer són l’ALB i el NLB. La diferència clau és a quin nivell treballen.

Treballa a nivell d’aplicació (capa 7): entén de HTTP i HTTPS. Això vol dir que «sap llegir» les peticions web i pot prendre decisions intel·ligents segons el seu contingut:

• Enviar /api/* a uns servidors i /imatges/* a uns altres (enrutament per ruta).
• Enviar botiga.elmeudomini.com i blog.elmeudomini.com a grups diferents (enrutament per host).
• Gestionar certificats HTTPS, capçaleres, galetes de sessió, etc.

És el balancejador per defecte per a aplicacions web i APIs.

Treballa a nivell de xarxa (capa 4): només entén de TCP/UDP, sense mirar el contingut. A canvi, és extremadament ràpid i suporta moltíssim trànsit amb latència mínima.

• No llegeix HTTP; només reparteix connexions de xarxa.
• Ideal per a rendiment extrem, protocols que no són HTTP (per exemple, bases de dades, jocs en línia, IoT, streaming) o quan necessites una IP fixa.

• L’ALB és com un recepcionista d’hotel que llegeix la teva petició («vull l’spa», «busco el restaurant») i et dirigeix al lloc adequat. És intel·ligent, però aquesta lectura triga un instant.
• El NLB és com un torniquet de metro: no li importa qui ets ni on vas, només deixa passar la gent tan ràpid com pot. És tremendament veloç, però «no pensa».

La regla pràctica per començar és senzilla:

• És una aplicació web o una API (HTTP/HTTPS)? → ALB. És el cas del 90 % dels projectes. És el que faràs servir gairebé sempre.
• Necessites màxim rendiment, una IP fixa, o treballes amb protocols que no són HTTP? → NLB.

Per a principiants: centra’t en l’ALB. És el que faràs servir en la immensa majoria d’aplicacions web, i és el que veurem a la resta del capítol (Target Groups, listeners, autoescalat). El NLB el tindràs per a casos especials d’alt rendiment.

• Un balancejador de càrrega reparteix el trànsit entre diversos servidors: dona escalabilitat i alta disponibilitat (si un cau, utilitza els altres).
• L’ALB (capa 7) entén de HTTP/HTTPS i és intel·ligent: enruta per ruta, host, capçaleres. És l’estàndard per a webs i APIs.
• El NLB (capa 4) només entén de TCP/UDP, és extremadament ràpid i permet IP fixa. Per a rendiment extrem o protocols no-HTTP.
• Regla pràctica: aplicació web? → ALB. Casos especials de rendiment o no-HTTP → NLB.

Al següent subcapítol veurem com el balancejador sap a quins servidors enviar el trànsit: els Target Groups, els listeners i les regles.