Cada año se repite una escena poco tecnológica en apariencia, pero que pone a prueba algunas de las arquitecturas cloud más sofisticadas: miles de personas intentando formalizar una matrícula, consultar horarios o acceder a una plataforma educativa prácticamente al mismo tiempo. Y entonces aparece uno de los mensajes más temidos de Internet: “Error 503: servicio no disponible”
Detrás intervienen conceptos como Cloud Computing, arquitecturas escalables, balanceadores de carga, autoscaling y Serverless. En este ámbito pone el foco nuestro Máster en Data & Cloud Engineering, un programa especializado que aborda desde los fundamentos del cloud hasta AWS, Google Cloud, Azure, DevOps y contenedores.
El problema no es exclusivo del sector educativo. Una oferta flash, la venta de entradas para un concierto, la publicación de una noticia de última hora o el lanzamiento de un producto pueden provocar el mismo fenómeno: un pico repentino de tráfico que obliga a una aplicación a gestionar en poco tiempo muchas más peticiones de las habituales.
¿Cómo consigue la nube responder a esa avalancha sin que la infraestructura se venga abajo?
Cuando 10 peticiones se convierten en miles
Una aplicación web necesita recursos de computación para procesar cada solicitud. En una infraestructura convencional, esos recursos están asociados a un número determinado de servidores.
Si una aplicación recibe normalmente 10 peticiones por segundo y, de repente, miles de usuarios empiezan a utilizarla simultáneamente, los recursos disponibles pueden ser insuficientes. La CPU y la memoria se saturan, las peticiones empiezan a acumularse y el tiempo de respuesta aumenta hasta que el sistema puede terminar rechazando nuevas conexiones.
Una solución sencilla sería utilizar un servidor mucho más potente del necesario durante todo el año, el problema es que supondría mantener capacidad preparada para un escenario excepcional incluso cuando la demanda es normal. Pero uno de los principios fundamentales de la nube es que, en lugar de tener siempre más recursos, se pueden añadir cuando hacen falta.
Para conseguirlo, una de las piezas fundamentales es el Load Balancer o balanceador de carga. Su función puede entenderse como la de un repartidor, en lugar de enviar todas las peticiones al mismo servidor, recibe el tráfico y lo distribuye entre diferentes partes de la aplicación.
Si hay tres servidores disponibles, por ejemplo, las solicitudes pueden repartirse entre ellos. Si uno deja de estar disponible, el balanceador puede dejar de enviarle tráfico y utilizar los que siguen funcionando. Por ejemplo, los servicios de Elastic Load Balancing de AWS realizan esta distribución entre diferentes destinos y comprueban además el estado de los recursos para dirigir las peticiones hacia los que están disponibles.
Esto permite pasar de una arquitectura basada en un único servidor a otra en la que varias máquinas trabajan como un conjunto. Pero ¿qué ocurre cuando esas máquinas también empiezan a quedarse pequeñas?
Autoscaling: más capacidad cuando llega la avalancha
En lugar de aumentar indefinidamente la potencia de un único servidor, el autoscaling horizontal permite al sistema crear nuevas instancias de la aplicación cuando aumenta la demanda. El balanceador distribuye entonces el tráfico entre todas ellas.
Cuando el tráfico vuelve a niveles normales, las instancias adicionales pueden eliminarse. Esta elasticidad es una de las grandes diferencias respecto a una infraestructura dimensionada de forma fija. Una plataforma educativa no necesita mantener permanentemente la capacidad necesaria para el día de matriculación más intenso del año, puede aumentar sus recursos cuando la demanda lo exige y reducirlos posteriormente.
Serverless: cuando la infraestructura deja de ser problema
El siguiente paso es el modelo Serverless. En lugar de que el equipo tenga que aprovisionar y administrar directamente las máquinas que ejecutan la aplicación, el proveedor cloud gestiona esa infraestructura y proporciona entornos de ejecución según las necesidades del servicio.
AWS Lambda es uno de los ejemplos más conocidos. En este modelo, las funciones se ejecutan cuando reciben solicitudes y AWS crea los entornos de ejecución necesarios para atenderlas. Lambda escala automáticamente la cantidad de entornos cuando aumenta el número de peticiones, aunque existen límites de concurrencia y de velocidad de escalado.
Por otro lado, Google Cloud Run utiliza otro enfoque, permite ejecutar aplicaciones empaquetadas en contenedores y ajusta automáticamente el número de instancias necesarias para atender las solicitudes. Su autoscaling tiene en cuenta factores como la utilización de CPU y la concurrencia, y permite establecer límites máximos y mínimos.
La diferencia fundamental frente a una infraestructura tradicional es que el equipo de desarrollo no necesita preocuparse directamente de levantar cada servidor cuando llega el pico.
El verdadero reto: construir una arquitectura sólida
Sin embargo, que la capacidad de computación pueda escalar no significa necesariamente que toda la aplicación esté preparada para hacerlo al mismo ritmo.
Una plataforma puede contar con recursos suficientes para gestionar miles de peticiones y, aun así, encontrarse con un cuello de botella si todas dependen de una base de datos que no puede asumir ese volumen de operaciones. Lo mismo ocurre con otros componentes de la arquitectura, como una API externa, un sistema de autenticación o un servicio de pagos.
Por eso, las arquitecturas preparadas para grandes picos suelen incorporar otras estrategias:
- Una CDN puede servir directamente contenidos estáticos y evitar que todas las peticiones lleguen al servidor de origen.
- Una caché puede almacenar temporalmente información muy consultada para reducir las operaciones sobre la base de datos.
- Las colas de procesamiento permiten poner determinadas tareas en espera para ejecutarlas de forma controlada, en lugar de intentar procesarlas todas simultáneamente.
La idea es que no todo tiene que escalar al mismo ritmo ni todo tiene que suceder inmediatamente.
La infraestructura que se prepara para lo excepcional
La vuelta al cole ofrece un buen ejemplo de cómo ha cambiado la forma de diseñar las infraestructuras digitales. Ya no se trata únicamente de construir sistemas capaces de soportar una cantidad determinada de usuarios, sino de crear arquitecturas que puedan adaptarse a situaciones que no se producen todos los días.
Porque el próximo pico de tráfico puede llegar con la apertura de unas matrículas, pero también con una campaña viral, una final deportiva, una oferta inesperada o cualquier acontecimiento capaz de concentrar a miles de personas frente a una misma pantalla.
En la nube, la capacidad deja así de ser una cifra fija para convertirse en una variable que puede crecer, y después reducirse, según las circunstancias. Y esa elasticidad es, la que permite que una avalancha de usuarios no termine convirtiéndose en una avalancha de errores.
