El futuro del balanceo de carga depende de los datos

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Las aplicaciones nativas de la nube se están desarrollando a buen ritmo. Aunque todavía no dominan por completo las carteras de aplicaciones, su número va en aumento. El interés por los contenedores está estrechamente relacionado con las arquitecturas nativas de la nube (basadas en microservicios), debido a su dependencia inherente de la infraestructura para las comunicaciones y el escalado.

Normalmente, el escalado de microservicios se consigue mediante la clonación horizontal. Es decir, si necesitamos más instancias de un servicio determinado, simplemente lo clonamos y lo añadimos al conjunto disponible, del que un equilibrador de carga selecciona una instancia para responder a las solicitudes. Así de fácil. Cuando esos microservicios representan fielmente elementos funcionales, este modelo funciona aún mejor.

El balanceador de carga en cuestión suele ser un componente del orquestador de contenedores y utiliza de forma predeterminada el algoritmo estándar del sector basado en TCP y de tipo round-robin. Esto significa que, cuando llega una solicitud, el balanceador de carga elige el siguiente recurso de la cola para responder.

Este método suele compararse con la cola de un banco o de la oficina de tráfico. Pero la comparación no es del todo acertada. En un verdadero sistema round robin, no se le dirige al «siguiente» recurso disponible, sino al recurso que «sigue en la lista», aunque esté ocupado. Irónicamente, los métodos de distribución de la oficina de tráfico y de su banco local son más eficientes que un verdadero algoritmo round robin.

Lo sé, ¿verdad?

Esto también se aplica a las aplicaciones. Un mismo servicio —incluso a nivel funcional— puede clonarse porque las distintas instancias atienden el mismo conjunto de solicitudes. Sin embargo, esas solicitudes no siempre requieren el mismo tiempo de ejecución debido a los datos. Sí, los datos. Una misma solicitud funcional —o llamada a una API— puede tardar más o menos en ejecutarse en función de los datos enviados o solicitados. Al fin y al cabo, recuperar y serializar el registro de un solo cliente llevará menos tiempo que recuperar y serializar diez o cien registros de clientes.

Y es ahí donde el método round robin empieza a fallar un poco e introduce una variabilidad que puede afectar al rendimiento. El axioma operativo n.º 2 sigue siendo aplicable a las arquitecturas nativas de la nube y basadas en microservicios: a medida que aumenta la carga, disminuye el rendimiento.

El algoritmo round robin es como el tejón de la miel: no le importa que un recurso se esté sobrecargando con solicitudes cuyas respuestas contienen conjuntos de datos de gran tamaño. El round robin dice «eres el siguiente», estés preparado o no. Esto puede provocar un rendimiento desigual para aquellos usuarios cuyas solicitudes acaben en una cola en un recurso cada vez más sobrecargado.

Si te preocupa el rendimiento —y debería preocuparte—, una alternativa mejor es, en fin, prácticamente cualquiera de los demás algoritmos estándar, como el de menor número de conexiones o el de menor tiempo de respuesta. En esencia, lo ideal es que el algoritmo tenga en cuenta la carga o la velocidad, o ambas, en lugar de limitarse a asignar solicitudes a ciegas a recursos que quizá no sean la opción más adecuada.

El futuro del balanceo de carga

Algunos podrían pensar que, a medida que ascendemos en la pila de TCP a HTTP y a HTTP+, este problema se resolverá por sí solo. Pero no es así en absoluto. El método de distribución —el algoritmo de balanceo de carga— sigue siendo relevante, independientemente de la capa en la que se base. Al método round robin no le importa la arquitectura, sino los recursos, y toma decisiones en función de un conjunto disponible. Para el algoritmo, es indiferente que ese conjunto esté destinado a escalar una única llamada a una API o un monolito completo.

Por tanto, sería conveniente que el equilibrador de carga fuera lo bastante inteligente como para reconocer cuándo una consulta generaría una cantidad de datos «superior a la media» antes de ejecutarse. Los cortafuegos de aplicaciones web como F5 WAF pueden detectar cuándo un resultado se sale de lo habitual, pero lo hacen en la respuesta y su función principal es mejorar la seguridad de las aplicaciones. Lo que necesitamos es que el equilibrador de carga sea lo bastante inteligente como para predecir una respuesta legítima «extragrande».

Si el equilibrador de carga tuviera esa capacidad de discernimiento, podría tener ese factor en cuenta al tomar decisiones y distribuir las solicitudes de manera más uniforme entre los recursos disponibles. Lo que realmente queremos es no vernos obligados a especificar un algoritmo rígido en el que basar las decisiones. Sería mejor que el equilibrador de carga pudiera decidir en función de umbrales de negocio y características técnicas como los tiempos de respuesta, el tiempo de ejecución previsto, el volumen de datos devueltos y la carga que soporta en ese preciso momento cada recurso.

En última instancia, este tipo de inteligencia solo puede lograrse mediante una mayor visibilidad y el aprendizaje automático. Si el equilibrador de carga puede aprender de la experiencia a reconocer qué consultas tardan más que otras, podrá aplicar ese conocimiento para distribuir mejor las solicitudes y lograr así un tiempo de respuesta uniforme y predecible.

El balanceo de carga no va a desaparecer. Es nuestra mejor respuesta técnica para escalarlo todo, desde la red hasta las aplicaciones. Pero debe evolucionar junto con el resto de la infraestructura para ser más dinámico, autónomo e inteligente.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie