Tens un balancejador repartint tràfic entre diversos servidors. Però queda una pregunta: qui crea aquests servidors i quants n'hi ha d'haver? Si en poses 10 fixos, pagues de més a la nit quan hi ha poc tràfic; si en poses 2, et satures en hora punta. La solució és l'Auto Scaling Group (ASG): el component que crea i elimina servidors automàticament segons la demanda. Aquesta és l'altra meitat d'una arquitectura elàstica.

El tràfic de gairebé qualsevol aplicació puja i baixa:

Si dimensions pel pic, malgastes diners la major part del temps. Si dimensions per la mitjana, caus en els pics. La resposta és no tenir un nombre fix: ajustar la quantitat de servidors en temps real. Això és l'autoescalat, i és un dels grans avantatges del núvol que vam veure al Capítol 1 (elasticitat).

Un Auto Scaling Group (ASG) és un grup d'instàncies EC2 que AWS manté i ajusta automàticament. Tu defineixes uns límits i unes regles, i l'ASG s'encarrega de crear o destruir servidors per complir-les.

Es configura amb tres números clau:

• Mínim: el nombre que sempre hi haurà, encara que no hi hagi tràfic (garanteix disponibilitat).
• Desitjat: quants n'hi ha en aquest moment; aquest és el que l'ASG va ajustant.
• Màxim: el límit, perquè un pic (o un error) no dispari la factura sense control.

L'ASG no només escala: també s'autorepara. Si una instància cau o falla el seu health check, l'ASG la detecta i en crea una de nova per mantenir el nombre desitjat.

Això és potentíssim: combinat amb el balancejador del subcapítol anterior, la teva aplicació es cura sola. Si un servidor mor a les 3 de la matinada, ningú s'ha d'aixecar: l'ASG en crea un de nou i el balancejador comença a usar-lo tan bon punt està sa. Aquí pren sentit el user_data del subcapítol 12.2: cada servidor nou s'autoconfigura sol en néixer.

Com decideix l'ASG que cal escalar? Mitjançant polítiques d'escalat basades en mètriques (dades de CloudWatch, que veurem al Capítol 24). La més comuna és l'ús de CPU.

Li dius a l'ASG un objectiu i ell fa el necessari per mantenir-lo. Per exemple: «mantén l'ús mitjà de CPU al 50 %».

És com el climatitzador d'un cotxe: li dius «mantén 22 graus» i ell solet encén o apaga l'aire segons calgui. No t'amoïnes pels detalls. Per la seva senzillesa, és la política recomanada per començar.

Un exemple d'escalat programat (scheduled): una web de venda d'entrades sap que cada dilluns a les 10:00 treu entrades i rep una allau. Programa l'ASG per pujar a 20 servidors a les 9:55, abans que arribi la gent, en comptes d'esperar que la CPU pugi.

Les polítiques reaccionen a mètriques. Les més habituals:

• Ús de CPU: la més comuna; CPU alta = servidors saturats.
• Nombre de peticions per servidor: molt útil amb un balancejador (peticions del Target Group).
• Ús de memòria o de xarxa.
• Mètriques personalitzades: per exemple, el nombre de missatges en una cua (ho veurem amb SQS, Capítol 15).

Juntant els tres subcapítols, aquesta és l'arquitectura elàstica clàssica:

El balancejador reparteix entre els servidors que hi hagi; l'ASG ajusta quants n'hi ha i els manté sans. Junts donen una aplicació que escala sola i es cura sola.

• Un Auto Scaling Group (ASG) crea i elimina servidors automàticament segons la demanda, dins d'uns límits: mínim, desitjat i màxim.
• L'ASG també s'autorepara: si un servidor falla, en crea un de nou per mantenir el nombre desitjat (aquí brilla el user_data que autoconfigura cada servidor).
• Les polítiques d'escalat decideixen quan escalar segons mètriques (la més comuna, l'ús de CPU).
• Target Tracking («mantén la CPU al 50 %») és la política més senzilla i recomanada per començar; existeixen també Step i Scheduled (escalat programat per a pics predictibles).
• Balancejador + ASG = arquitectura que escala sola i es cura sola.

A l'últim subcapítol del capítol veurem dues tècniques avançades per afinar l'autoescalat: els warm pools i els lifecycle hooks.