Una aplicación funciona bien con cien usuarios. Luego llega una campaña, un plazo o un evento en directo, y los usuarios pasan a ser miles al mismo tiempo: las páginas se ralentizan, las peticiones fallan, y el problema no es una función concreta sino la forma en que está construido todo el sistema.
La escalabilidad es la capacidad de un sistema para gestionar más carga (más usuarios, más datos, más peticiones) sin perder rendimiento ni calidad de servicio, a ser posible con costes que crecen de forma proporcional. En este artículo contamos cómo la diseñamos en nuestros proyectos: las técnicas que usamos, en qué orden y por qué medir va antes que optimizar.
Escalar en vertical o en horizontal
Hay dos formas de dar más capacidad a un sistema. Escalar en vertical significa usar una máquina más potente, con más CPU y más memoria: es sencillo y a menudo es el primer paso correcto, pero tiene un límite físico y económico, y esa máquina sigue siendo un punto único de fallo.
Escalar en horizontal significa añadir más copias (réplicas) del mismo servicio y repartir el trabajo entre ellas. Permite crecer mucho más y además mejora la fiabilidad, pero la aplicación tiene que estar pensada para funcionar en varias copias a la vez. Aquí es donde cuentan las decisiones de arquitectura.
Servicios sin estado, balanceo y caché
El primer requisito para escalar en horizontal son los servicios sin estado (stateless): ninguna réplica debe guardar en memoria datos que necesiten las peticiones siguientes, como la sesión del usuario o los archivos subidos. Sesiones y archivos van a un almacenamiento compartido, así cualquier copia puede responder a cualquier petición.
Delante de las réplicas hay un balanceador de carga (load balancer), que reparte las peticiones y deja de enviarlas a las copias que no responden. Al lado casi siempre hay una caché, es decir, una memoria rápida para los datos que se leen a menudo y cambian poco: con una herramienta como Redis, una respuesta que exigiría una consulta compleja a la base de datos se sirve en una fracción del tiempo.
La base de datos, a menudo el verdadero cuello de botella
Multiplicar la aplicación es relativamente fácil; la base de datos es más delicada, porque es el punto donde se encuentran todas las copias. Estas son las técnicas principales:
- Índices: la primera comprobación y a menudo la más eficaz; una consulta lenta sobre una tabla grande suele carecer de un índice adecuado.
- Réplicas de lectura: copias de la base de datos que solo atienden lecturas, mientras las escrituras siguen en la base de datos principal.
- Particionado: las tablas más grandes se dividen por fecha, por cliente o por zona, así cada consulta trabaja sobre una parte de los datos.
- Bases de datos gestionadas: servicios como Amazon RDS, o sus equivalentes en Microsoft Azure y Google Cloud, se ocupan de copias de seguridad, actualizaciones y réplicas.
Colas, CDN y trabajo en segundo plano
No todo tiene que ocurrir mientras el usuario espera. Las operaciones pesadas, como convertir un vídeo, generar un informe o enviar emails, se ponen en una cola (por ejemplo Amazon SQS o Apache Kafka) y las ejecutan procesos dedicados, que se pueden multiplicar cuando la cola crece. El usuario recibe enseguida una confirmación y el sistema absorbe los picos sin bloquearse.
Para los contenidos estáticos y los medios, una CDN (Content Delivery Network, una red de servidores distribuidos en muchos países) acerca los archivos a quien los pide, quita carga a los servidores y reduce los tiempos de espera.
Artika, nuestra plataforma de streaming para el teatro, está construida así con servicios gestionados de AWS. Vídeos y libretos van a Amazon S3 directamente desde el navegador, con enlaces firmados de corta duración, sin pasar por el servidor; AWS Elemental MediaConvert crea el streaming HLS; Amazon Transcribe y Amazon Rekognition se encargan de subtítulos y moderación, y la API recoge sus resultados cada minuto; Amazon CloudFront lleva vídeos y miniaturas a los espectadores.
Contenedores, Kubernetes y cloud gestionado
Los contenedores hacen práctica la escalabilidad horizontal: cada servicio se convierte en un paquete estándar, con su código y todo lo que necesita, que arranca rápido y es idéntico en cualquier entorno. Kubernetes, la plataforma open source más extendida para orquestar contenedores, puede añadir o quitar réplicas automáticamente según métricas como el uso de CPU (autoscaling) y reiniciar las que se bloquean.
No siempre hace falta gestionar Kubernetes por cuenta propia. Los servicios gestionados de AWS, Microsoft Azure y Google Cloud (contenedores, bases de datos, colas, CDN) trasladan al proveedor parte del trabajo operativo. En 2VitaBCognitive para Atlantia, por ejemplo, los 6 microservicios funcionan en contenedores Docker sobre Amazon ECS y los contenidos llegan a los usuarios desde Amazon S3 a través de CloudFront.
Medir antes de optimizar, y vigilar los costes
La escalabilidad no se adivina: se mide. Antes de cambiar la arquitectura hacemos pruebas de carga que simulan el tráfico previsto y el de los picos, y recogemos métricas de tiempos de respuesta, errores, uso de recursos y longitud de las colas. A menudo el cuello de botella es uno solo y está donde nadie lo espera: una consulta, una llamada a un servicio externo, un archivo servido por el servidor en lugar de por la CDN.
- Objetivos claros: por ejemplo, el tiempo en el que debe responder la gran mayoría de las peticiones.
- Pruebas de carga repetibles, que se vuelven a lanzar tras cada cambio importante.
- Monitorización en producción, con alertas que saltan antes de que el problema llegue a los usuarios.
- Control de costes: límites al autoscaling, recursos apagados cuando no se necesitan, presupuestos y avisos sobre el gasto en la nube.
El autoscaling sin límites resuelve los picos, pero puede convertirlos en una factura inesperada. Por eso, para cada componente, decidimos junto con el cliente cuánto debe poder crecer y cuánto está dispuesto a gastar.
Si tu aplicación está creciendo, o tiene que prepararse para hacerlo, podemos empezar midiendo su estado actual e indicarte las intervenciones con la mejor relación entre coste y beneficio. Contáctanos y lo hablamos.
