El futuro del balanceo de carga se basa en los datos
Las aplicações nativas de la nube se están creando a un ritmo excelente. Si bien aún no dominan las carteras de aplicaciones, su número está aumentando. El interés en los contenedores está estrechamente asociado con las arquitecturas nativas de la nube (basadas en microservicios) debido a la dependencia inherente de la infraestructura para las comunicaciones y la escala.
Normalmente, el escalamiento de microservicios se logra mediante la clonación horizontal. Es decir, si necesitamos más instancias de un servicio determinado, simplemente lo clonamos y lo agregamos al grupo disponible desde el cual un balanceador de carga elige responder a las solicitudes. Fácil y pan comido. Cuando esos microservicios representan de cerca 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 round robin basado en TCP, estándar de la industria. Esto significa que llega una solicitud y el balanceador de carga elige el recurso "siguiente en la línea" para responder.
Este método suele compararse con la fila en un banco o en el DMV. Pero no es del todo exacto. En un verdadero escenario de todos contra todos, no se le dirige al "siguiente recurso disponible". Se le dirigirá al recurso "siguiente en la fila", incluso si ese recurso está ocupado. Irónicamente, los métodos de distribución en el DMV y su banco local son más eficientes que un verdadero algoritmo de reparto circular.
¿Yo se, verdad?
Esto también es válido para las aplicações . El mismo servicio, incluso a nivel funcional, puede clonarse porque atiende el mismo conjunto de solicitudes. Pero esas solicitudes no siempre son iguales en términos de ejecución debido a los datos. Así es, datos. La misma solicitud funcional (o llamada API) puede tardar más o menos tiempo en ejecutarse dependiendo de los datos que se envíen o soliciten. Después de todo, tomará menos tiempo recuperar y serializar un solo registro de cliente que recuperar y serializar diez o cien registros de clientes.
Y ahí es donde el sistema round robin falla un poco e introduce una variabilidad que puede afectar el rendimiento. El axioma operativo n.° 2 todavía se aplica a las arquitecturas nativas de la nube y basadas en microservicios: a medida que aumenta la carga, el rendimiento disminuye .
El juego de todos contra todos es como el juego del tejón de miel. No le importa si un recurso se sobrecarga con solicitudes con conjuntos de datos importantes como respuestas. El sistema de todos contra todos dice "eres el siguiente", estés preparado o no. Esto puede generar un rendimiento desigual para aquellos usuarios cuyas solicitudes terminan en una cola en un recurso cada vez más sobrecargado.
Si le preocupa el rendimiento (y debería estarlo), entonces una mejor alternativa es, bueno, cualquiera de los otros algoritmos estándar, como el de menos conexiones o el de tiempo de respuesta más rápido. Básicamente, desea que su algoritmo tenga en cuenta la carga y/o la velocidad en lugar de simplemente asignar solicitudes a ciegas a recursos que pueden no ser una opción óptima.
El futuro del equilibrio de carga
Algunos podrían pensar que a medida que subimos en la pila de TCP a HTTP a HTTP+, este problema se resolverá por sí solo. Éste no es el caso en absoluto. El método de distribución (el algoritmo de equilibrio de carga) sigue siendo relevante independientemente de la capa en la que lo base. Al método round robin no le importa la arquitectura, le importan los recursos y toma decisiones basadas en un grupo disponible. No hay diferencia alguna para el algoritmo si ese grupo está destinado a escalar una única llamada API o un monolito entero.
Por lo tanto, sería bueno que el balanceador de carga fuera lo suficientemente inteligente como para reconocer cuándo una consulta generaría datos "superiores al promedio" antes de ejecutarse. Los firewalls de aplicação web como F5 WAF pueden reconocer cuando un resultado está fuera de lo normal, pero eso depende de la respuesta y, principalmente, permite una mejor seguridad de las aplicação . Lo que necesitamos es que el balanceador de carga sea lo suficientemente inteligente como para predecir una respuesta legítima "extra grande".
Si el balanceador de carga fuera capaz de ese tipo de discernimiento, podría tenerlo en cuenta en su toma de decisiones y distribuir de manera más uniforme las solicitudes entre los recursos disponibles. Lo que realmente queremos es no vernos obligados a especificar un algoritmo rígido sobre el cual tomar decisiones. Sería mejor si el balanceador de carga pudiera tomar la decisión en función de los umbrales comerciales y las características técnicas, como los tiempos de respuesta, el tiempo de ejecución previsto, el tamaño de los datos devueltos y la carga actual de cada recurso.
En última instancia, este es el tipo de inteligencia que solo se puede lograr mediante una mejor visibilidad y aprendizaje automático. Si el balanceador de carga puede aprender a través de la experiencia a reconocer qué consultas toman más tiempo que otras, puede aplicar ese conocimiento para distribuir mejor las solicitudes de modo que se pueda lograr un tiempo de respuesta consistente y predecible.
El equilibrio de carga no desaparecerá. Es nuestra mejor respuesta técnica para escalar todo, desde la red hasta las aplicações. Pero necesita evolucionar junto con el resto de la infraestructura para ser más dinámica, autónoma e inteligente.