Balanceo de carga. Está ampliamente aceptado que lo necesitamos, dependemos de él y lo utilizamos a diario para ampliar (y, con suerte, reducir) la capacidad de las aplicaciones. Se ha convertido en una infraestructura crítica que no solo permite escalar para satisfacer la demanda, sino que también garantiza la disponibilidad continua de las aplicaciones y los servicios de los que dependen las empresas tanto para su productividad como para su rentabilidad.
Por eso es algo que debemos replantearnos. El balanceo de carga no debería tratarse como una cuestión meramente táctica, como hacen cada vez más los equipos de operaciones, que ahora suelen tener que aprovisionar, configurar e implementar estos servicios casi mágicos. Desde una perspectiva estratégica, el balanceo de carga puede mejorar el rendimiento, reducir los riesgos y ayudar a utilizar de forma más eficiente los recursos necesarios para ofrecer aplicaciones. Es más inteligente de lo que su habitual etiqueta de «fontanería» da a entender, y comprender algunos aspectos clave ayudará a los equipos de operaciones a reflexionar mejor sobre cómo utilizan el balanceo de carga para dar soporte a las aplicaciones.
Así que, sin más preámbulos, estas son las tres cosas que el equipo de operaciones realmente debe saber sobre el balanceo de carga.
1. Los algoritmos son relativos
Empezaría mencionando que round robin es el último algoritmo del que deberías hablar, pero eso ya lo sabías, ¿verdad? Así que nos lo saltaremos y abordaremos algoritmos más inteligentes, como el de menos conexiones y el de menor tiempo de respuesta. Por supuesto, son opciones mucho mejores a la hora de plantear cómo equilibrar el rendimiento con un uso eficiente de los recursos. Cada uno tiene en cuenta características de la aplicación (o, al menos, de las plataformas que sirven las aplicaciones) que son fundamentales para decidir qué instancia de la aplicación (o contenedor, si lo prefieres) debe recibir la siguiente solicitud. El algoritmo de menos conexiones presupone que, si una instancia tiene menos conexiones, dispone de más capacidad y, por tanto, puede atender mejor la solicitud en ese preciso momento. Prioriza la eficiencia de la capacidad frente al rendimiento.
El menor tiempo de respuesta, en el otro extremo del espectro, opta por dirigir las solicitudes en función del rendimiento. Cuanto más rápida sea la instancia, más a menudo será seleccionada. Dados los axiomas operativos (a medida que aumenta la carga, disminuye el rendimiento), esto significa que, con el tiempo, un servidor menos sobrecargado responderá más rápido y, por tanto, será elegido. Aunque esto supone un cierto reconocimiento de la eficiencia de la capacidad, este algoritmo siempre prioriza el rendimiento frente a la capacidad.
Pero fijémonos ahora en los nombres de los algoritmos: menor número de conexiones y menor tiempo de respuesta. Pensemos ahora que, si dos tortugas compiten en una carrera por la acera, una de ellas es más rápida, aunque ambas se desplacen a una velocidad que todos calificaríamos de «lenta». Lo mismo ocurre con el menor número de conexiones. Si hay que elegir entre 99 y 100, 99 es, sin duda, el menor de los dos.
Por qué es importante
La forma en que el balanceo de carga gestiona las solicitudes tiene un impacto directo e inmediato en el rendimiento y la disponibilidad. Ambas son características fundamentales que, en última instancia, afectan a la interacción con los clientes y a la productividad de los empleados. Optimizar las arquitecturas que incluyen balanceo de carga contribuirá al éxito empresarial al permitir alcanzar los objetivos de mayor productividad y rentabilidad.
Análisis en profundidad:
- Volver a lo básico: la teoría de la relatividad (del rendimiento)
- Vuelta a los fundamentos: el menor número de conexiones no implica la menor carga
2. Fallar al instante es (a menudo) un mito
Desde el auge de la nube y los centros de datos definidos por software, la elasticidad se ha convertido en el método habitual para escalar aplicaciones. La elasticidad exige poder ampliar —y reducir— la capacidad bajo demanda para optimizar el uso de los recursos (y los presupuestos). ¿Por qué sobredimensionar los recursos si se puede ampliar la capacidad bajo demanda? Del mismo modo, las arquitecturas de alta disponibilidad (HA) basadas en los principios de redundancia se han quedado casi obsoletas. ¿Por qué mantener recursos inactivos en espera ante la (improbable) posibilidad de que falle la instancia principal de la aplicación? ¡Es un despilfarro de los presupuestos de capital y operativos! ¡Fuera, fuera, maldito modo de espera!
Aunque la conmutación por error y el escalado bajo demanda son una teoría muy atractiva, en la práctica no resultan tan sencillos. La realidad es que incluso los servidores virtuales (o servidores en la nube, o como prefiera llamarlos) tardan un tiempo en ponerse en marcha. Si usted (o su sistema automatizado) espera a que el servidor principal falle o alcance su capacidad máxima antes de iniciar otro, ya será demasiado tarde. La planificación de la capacidad en entornos de nube no puede basarse en los mismos cálculos que funcionaban en un entorno tradicional. Ahora, los umbrales de capacidad deben tener en cuenta tanto la tasa de consumo como el tiempo necesario para iniciar otro servidor, a fin de escalar de forma fluida en función de la demanda.
Y lo mismo ocurre con la conmutación por error. Si el servidor principal falla, poner en marcha uno de sustitución llevará tiempo. Durante ese intervalo, los usuarios perderán la conexión, se agotará el tiempo de espera y probablemente acabarán recurriendo a la competencia o viendo el último vídeo de gatos. Aunque mantener un servidor de reserva inactivo pueda parecer un desperdicio (como un seguro), cuando lo necesite se alegrará de tenerlo. En particular, si esa aplicación es responsable de la interacción con los clientes o de generar ingresos, el riesgo de sufrir incluso unos pocos minutos de inactividad (y el coste derivado) puede compensar con creces el coste de mantener un servidor de reserva listo para entrar en funcionamiento.
Curiosamente, los contenedores parecen ofrecer una posible solución a estos problemas gracias a unos tiempos de arranque ultrarrápidos. Si la disponibilidad, el rendimiento y el coste son igual de importantes, quizá sea el momento de empezar a explorar el valor que pueden aportar los contenedores para lograr un equilibrio entre los tres.
Por qué es importante
El tiempo de inactividad resulta costoso. La causa no es ni mucho menos tan importante como evitar que se produzca. Contar con la arquitectura adecuada y con planes de conmutación por error ante posibles fallos es imprescindible para mantener la disponibilidad continua, un factor fundamental para el éxito empresarial.
Análisis en profundidad:
3. La IP del cliente no es la IP real del cliente.
De todos los problemas que surgen cuando una aplicación pasa del entorno de desarrollo al de producción, este es probablemente el más habitual y uno de los más fáciles de evitar. La mayoría de los servicios de balanceo de carga (al menos, todos los buenos) son proxies. Esto significa que el cliente se conecta al proxy y este, a su vez, se conecta a tu aplicación. Ambos utilizan TCP para transportar el tráfico HTTP, por lo que deben cumplir las reglas de las redes. La IP de origen (la que crees que es la IP del cliente) es en realidad la dirección IP del proxy. Si aplicas medidas de seguridad, autenticación o medición basadas en la dirección IP, esto supone un grave problema. El valor que extraes de la cabecera HTTP no es el que necesitas.
El sector prácticamente ha estandarizado la forma de abordar este problema mediante el uso de cabeceras HTTP personalizadas. La cabecera X-Forwarded-For es probablemente lo que realmente buscas: ahí es donde un proxy incluye la dirección IP real del cliente al reenviar las solicitudes. Por desgracia, no es un estándar oficial, sino más bien un estándar de facto en el que «más o menos todos estamos de acuerdo», así que tendrás que comprobarlo.
La cuestión es que la dirección IP del cliente que buscas no es la que crees, por lo que los desarrolladores deben tenerlo en cuenta antes de que las aplicaciones que necesitan esa información pasen a un entorno de producción y dejen de funcionar de repente.
Por qué es importante para la empresa
La resolución de problemas en producción es mucho más costosa que en entornos de desarrollo o pruebas. Tanto el tiempo necesario para localizar y solucionar el problema como sus consecuencias afectan negativamente a los plazos del proyecto y retrasan la comercialización, un factor crucial para obtener una ventaja competitiva y lograr el éxito empresarial en un mundo basado en aplicaciones. Identificar este problema habitual y abordarlo durante la fase de desarrollo o pruebas puede garantizar un despliegue en producción y un lanzamiento al mercado más rápidos y fluidos.
Análisis en profundidad:
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.