Fundamentos de la computación en la nube
Escalabilidad y elasticidad
Por qué un sistema que puede crecer y un sistema que crece y se encoge solo, en automático, son 2 habilidades distintas, y cómo las configuraciones de capacidad y las políticas de escalado de un grupo de Auto Scaling entregan la segunda.
- Distinguir la escalabilidad de la elasticidad y explicar por qué responden preguntas distintas
- Explicar cómo trabajan juntas la capacidad mínima, deseada y máxima de un grupo de Auto Scaling
- Comparar el escalado por seguimiento de destino, por pasos y programado, e identificar cuál conviene según el patrón de demanda
- Aplicar la elasticidad a un ejemplo trabajado que muestra el impacto en el costo de ajustar la capacidad a la demanda en tiempo real
Las 2 formas en que un plan para más tráfico puede salir mal
Un retailer dimensiona sus servidores de checkout para un día promedio de ventas y se ve superado la primera vez que una oferta relámpago duplica el tráfico de la noche a la mañana: las solicitudes se acumulan, las páginas se caen por tiempo de espera, y la oferta se vuelve la historia de la caída en vez de la historia de los ingresos. Otro equipo se pasa de precavido: aprovisiona suficientes servidores para sobrevivir a su día de ventas más grande del año, y después paga por esa misma flota los otros 364 días, la mayoría corriendo muy por debajo de su capacidad. Ninguno de los 2 equipos resolvió el problema real, que tiene 2 partes separadas: si el sistema puede crecer, y si crece (y se encoge) solo para ajustarse a lo que está pasando ahora mismo.
Repaso: el crecimiento que ya sabes hacer
La lección de cómputo, antes en este curso, cubrió el escalado horizontal, agregar más instancias del mismo tamaño detrás de un balanceador de carga, como una respuesta a quedarse sin capacidad. Lo que no cubrió fue quién decide cuándo agregar esas instancias, ni cuándo quitarlas una vez que la carga pasa. Esa brecha, la capa de decisión que se sienta encima del escalado horizontal, es justo lo que llena esta lección.
Escalabilidad: la capacidad de crecer
La escalabilidad es la capacidad de un sistema para manejar más carga agregando recursos, ya sea redimensionando 1 máquina (escalado vertical) o agregando más máquinas del mismo tamaño (escalado horizontal). Nada en esa definición dice que el crecimiento tenga que ser automático. Un equipo que nota que sube el tráfico y lanza 3 instancias más a mano escaló el sistema. También lo hizo un departamento de TI on-premises que pide y monta 2 servidores físicos nuevos a lo largo de un mes. Los 2 mejoraron la capacidad del sistema para manejar carga; ninguno de los 2 lo hizo solo, en tiempo real, ni devolvió capacidad alguna una vez que dejó de necesitarse.
Elasticidad: ajustar la capacidad a la demanda, en automático
La elasticidad es lo que pasa cuando esa toma de decisiones se automatiza en las 2 direcciones: la capacidad sube cuando la demanda sube y baja cuando la demanda baja, sin que una persona vigile un tablero y presione un botón cada vez. Es una idea genuinamente nativa de la nube. Un servidor físico que ya compraste no reduce tu factura cuando queda inactivo en la madrugada; una instancia en la nube que se termina durante un periodo tranquilo deja de costarte apenas desaparece. La elasticidad es la razón de que "paga solo por lo que usas" sea más que un eslogan: exige que el sistema realmente note cuándo cambió "lo que usas", y que actúe sobre eso, de forma continua, sin esperar a una persona.
Imagina una autopista que un equipo de ingenieros puede ampliar con una cuadrilla de construcción durante varios meses, frente a una autopista con un carril reversible que se abre solo cuando los sensores detectan tráfico de hora pico y se cierra de nuevo cuando pasa. Ampliar la autopista es escalabilidad: capacidad real, esfuerzo real, y ninguna razón para deshacerla jamás. El carril reversible es elasticidad: el mismo camino, ajustado al instante y en automático al tráfico que realmente tiene ahora, y cerrado en cuanto deja de necesitarse. Lleva la comparación más lejos y se rompe: un carril reversible es infraestructura fija que se enciende y se apaga, no algo que se crea y se destruye, mientras que una instancia en la nube se aprovisiona y se elimina por completo cada vez, que es justo lo que hace que no cueste nada mientras no existe.
Ejemplo trabajado: 1 día dentro de un grupo de Auto Scaling
Un grupo de Auto Scaling es el mecanismo de AWS que automatiza esto. Digamos que un grupo está configurado con un mínimo de 4 instancias, una capacidad deseada de 6 y un máximo de 12. El mínimo y el máximo son límites duros que el grupo nunca cruza en ninguna dirección; la capacidad deseada es el punto de partida desde el que ajusta una política de escalado dentro de ese rango.
A las 9 a.m., el tráfico sube y el uso promedio de CPU del grupo pasa su objetivo. Una política de seguimiento de destino lanza instancias nuevas, de 1 en 1 o de 2 en 2, hasta que el uso de CPU se estabiliza cerca del objetivo, y la capacidad llega a unas 10 instancias a media mañana. El tráfico se sostiene durante el día y baja hacia las 6 p.m.; la misma política ahora termina instancias mientras el uso de CPU cae bajo el objetivo, bajando la capacidad de vuelta hacia 6, y más adelante hacia el mínimo de 4 durante la noche. El grupo nunca toca su techo de 12 instancias ese día, y nunca corre por debajo de 4. El equipo paga por unas 10 instancias durante las 9 horas ocupadas que las necesitaron, y muchas menos durante la noche, en vez de correr 12 (o incluso un fijo de 10) las 24 horas.
Políticas de escalado: 3 formas de decirle al grupo cuándo actuar
| Política | Cómo decide | Mejor para |
|---|---|---|
| Seguimiento de destino | Ajusta la capacidad de forma continua para mantener una métrica elegida, como el uso promedio de CPU, cerca de un valor objetivo | Demanda en vivo, algo impredecible |
| Escalado por pasos | Agrega o quita capacidad en pasos definidos, según cuánto se alejó una métrica de su umbral | Demanda que puede subir de golpe y necesita una respuesta proporcionalmente mayor |
| Escalado programado | Fija la capacidad antes de un momento conocido, sin depender de ninguna métrica en vivo | Patrones predecibles, como el tráfico diario a las 9 a.m. de un retailer o un trabajo por lotes mensual |
Estas políticas no se excluyen entre sí. Un equipo de retail podría usar escalado programado para precalentar capacidad justo antes de su pico conocido de las 9 a.m., y dejar que el seguimiento de destino maneje las fluctuaciones más pequeñas del resto del día encima de esa ventaja inicial.
La elasticidad también significa autorreparación
Los grupos de Auto Scaling hacen más que redimensionarse según la demanda. Revisan la salud de cada instancia de forma continua y reemplazan las que fallan, en automático, para mantener al grupo en su capacidad deseada incluso cuando nada cambió sobre el tráfico. Eso conecta directo con la lección anterior: un grupo de Auto Scaling repartido entre varias zonas de disponibilidad es parte de cómo se construye una arquitectura altamente disponible desde el inicio, no un asunto aparte de ella.
Error de concepto: "Auto Scaling" no es solo escalar hacia arriba
Es tentador escuchar "Auto Scaling" e imaginar solo la mitad emocionante: agregar capacidad automáticamente para sobrevivir un pico de tráfico. La mitad que realmente ahorra dinero es escalar hacia adentro, quitar capacidad cuando baja la demanda. Un grupo sin un mínimo que valga la pena respetar, o sin una política de reducción configurada, se vuelve solo una versión cara de la escalabilidad simple que se lanza sola: crece por su cuenta, pero nunca devuelve nada, y la ventaja de costo que promete la elasticidad nunca aparece en la factura.
Pistas de examen: cómo leer una pregunta de escalabilidad frente a elasticidad
| Si el escenario dice... | Apunta a |
|---|---|
| "Manejar una cantidad creciente de carga agregando recursos" | Escalabilidad |
| "Se ajusta en automático a la demanda en tiempo real", "paga solo por lo que usas", "reduce capacidad cuando está inactivo" | Elasticidad |
| "Mínimo", "deseado", "capacidad máxima" | Configuraciones de un grupo de Auto Scaling |
| "Un pico conocido y predecible a una hora específica" | Escalado programado |
| "Mantener un uso objetivo de CPU" | Seguimiento de destino |
Dónde te deja esto
La escalabilidad responde si un sistema puede crecer siquiera; la elasticidad responde si crece, y se encoge, solo, en automático, al ritmo de una demanda que cambia minuto a minuto. Toda carga de trabajo en la nube necesita lo primero. Solo las cargas con demanda genuinamente variable sacan valor real de lo segundo, que son la mayoría, porque el tráfico que nunca varía es raro fuera de un puñado de sistemas internos estables. La próxima lección da por sentado todo esto, redundancia, health checks, capacidad bien dimensionada, y pregunta qué pasa de todos modos: cuando una falla es más grande de lo que cualquiera de estas piezas puede absorber, y un equipo tiene que recurrir a respaldos y a un plan de recuperación ante desastres.