La mayoría de los balanceadores de cargas usan un método de hashing del tipo round robin o basado en el flujo para distribuir el tráfico. Sin embargo, los balanceadores de cargas que usan este enfoque pueden tener dificultades para adaptarse cuando la demanda aumenta de forma repentina más allá de la capacidad de entrega disponible. En este artículo, se explica cómo el uso de Cloud Load Balancing puede abordar estos problemas y optimizar la capacidad de la aplicación global. A menudo, esto da como resultado una mejor experiencia del usuario y costos menores en comparación con las implementaciones tradicionales del balanceo de cargas.
Este artículo forma parte de una serie de prácticas recomendadas que se enfocan en los productos de Cloud Load Balancing de Google. Para ver el instructivo que acompaña este artículo, consulta Administración de la capacidad con balanceo de cargas. Para obtener un análisis detallado sobre la latencia, consulta Optimiza la latencia de la aplicación con el balanceo de cargas.
Desafíos de capacidad en aplicaciones globales
El escalamiento de las aplicaciones globales puede ser un desafío, en especial si tienes presupuestos de TI limitados y cargas de trabajo impredecibles y poco estables. En entornos de nube pública, como Google Cloud, la flexibilidad proporcionada por características como el ajuste de escala automático y el balanceo de cargas puede ser útil. Sin embargo, como se explica en esta sección, los escaladores automáticos tienen algunas limitaciones.
Latencia en el inicio de instancias nuevas
El problema más común con el ajuste de escala automático es que la aplicación solicitada no esté lista para entregar tráfico con suficiente rapidez. Según las imágenes de la instancia de VM, por lo general, las secuencias de comandos deben ejecutarse y la información debe cargarse antes de que estén listas las instancias de VM. A menudo, el balanceo de cargas demora unos minutos en dirigir a los usuarios a instancias de VM nuevas. Durante ese tiempo, el tráfico se distribuye a las instancias de VM existentes, cuya capacidad quizás ya está excedida.
Aplicaciones limitadas por la capacidad de backend
Algunas aplicaciones no admiten el ajuste de escala automático. Por ejemplo, a menudo, las bases de datos tienen una capacidad de backend limitada. Solo una cantidad específica de frontends puede acceder a una base de datos que no se escala de forma horizontal. Si la aplicación se basa en API externas que solo admiten una cantidad limitada de solicitudes por segundo, la aplicación tampoco puede realizar un ajuste de escala automático.
Licencias inflexibles
Cuando usas un software con licencia, esta te limita, a menudo, a una capacidad máxima preestablecida. Por lo tanto, es posible que la capacidad de ajuste de escala automático esté restringida porque no puedes agregar licencias sobre la marcha.
Muy poco espacio para la instancia de VM
Para justificar los picos de actividad de tráfico repentinos, un escalador automático debe incluir un espacio amplio (por ejemplo, el escalador automático se activa al 70% de la capacidad de la CPU). A fin de ahorrar costos, es posible que te parezca una buena idea establecer valores más altos para este objetivo, como el 90% de la capacidad de la CPU. Sin embargo, los valores más altos de activación pueden generar un escalamiento de cuellos de botella cuando se enfrentan a picos de actividad de tráfico, como una campaña publicitaria que aumenta la demanda de forma repentina. Debes equilibrar el tamaño del espacio en función de los picos del tráfico y del tiempo que tardan en prepararse las instancias de VM nuevas.
Cuotas regionales
Si tienes picos de actividad inesperados en una región, es posible que las cuotas de recursos existentes limiten la cantidad de instancias que puedes escalar por debajo del nivel requerido para admitir el pico de actividad actual. Procesar un aumento en la cuota de recursos puede demorar algunas horas o días.
Aborda estos desafíos con el balanceo de cargas global
Los balanceadores de cargas de aplicaciones externos y los balanceadores de cargas de red de proxy externos son productos de balanceo de cargas globales que se envían mediante proxy a través de Google Front End (GFE) sincronizado de forma global, lo que facilita la mitigación de estos tipos de desafíos de balanceo de cargas. Estos productos ofrecen una solución a los desafíos porque el tráfico se distribuye a los backends de manera diferente a la mayoría de las soluciones de balanceo de cargas regionales.
Estas diferencias se describen en las siguientes secciones.
Algoritmos usados por otros balanceadores de cargas
La mayoría de los balanceadores de cargas usan los mismos algoritmos para distribuir el tráfico entre los backends:
- Turno rotativo. Los paquetes se distribuyen de forma equitativa entre todos los backends, sin importar el origen o el destino.
- Hashing. Los flujos de paquetes se identifican según los hashes de la información de tráfico, incluidos la IP de origen, la IP de destino, el puerto y el protocolo. Todo el tráfico que produce el mismo valor de hash fluye al mismo backend.
El balanceo de cargas de hash es el algoritmo que se encuentra disponible en la actualidad para los balanceadores de cargas de red de transferencia externos. Este balanceador de cargas admite el hash de 2 tuplas (basado en la IP de origen y la de destino), el hash de 3 tuplas (basado en la IP de origen, la IP de destino y el protocolo) y el hash de 5 tuplas (basado en la IP de origen, la IP de destino, el puerto de origen, el puerto de destino y el protocolo).
Con estos dos algoritmos, las instancias en mal estado se eliminan de la distribución. Sin embargo, rara vez la carga actual en los backends es un factor en la distribución de la carga.
Algunos balanceadores de cargas de hardware o software usan algoritmos que reenvían tráfico en función de otras métricas, como el turno rotativo ponderado, la carga más baja, el tiempo de respuesta más rápido o la cantidad de conexiones activas. Sin embargo, si la carga aumenta más que el nivel esperado debido a los picos de actividad de tráfico repentinos, el tráfico aún se distribuye a las instancias de backend que están por encima de su capacidad, lo que lleva a aumentos drásticos en la latencia.
Algunos balanceadores de cargas permiten reglas avanzadas en las que el tráfico que excede la capacidad del backend se reenvía a otro grupo o se redirecciona a un sitio web estático. Esto te permite rechazar este tráfico de forma efectiva y enviar un mensaje que indique “Servicio no disponible. Vuelve a intentarlo más tarde”. Algunos balanceadores de cargas te dan la opción de poner las solicitudes en cola.
A menudo, las soluciones del balanceo de cargas global se implementan con un algoritmo basado en DNS, que realiza entregas a diferentes IP de balanceo de cargas regionales según la ubicación del usuario y la carga del backend. Estas soluciones ofrecen conmutación por error a otra región para todo el tráfico, o parte de él, de una implementación regional. Sin embargo, en cualquier solución basada en DNS, la conmutación por error suele tomar minutos, según el valor de tiempo de actividad (TTL) de las entradas de DNS. En general, una pequeña cantidad de tráfico continuará dirigiéndose a los servidores anteriores mucho después de que el TTL expire en todas partes. Por lo tanto, el balanceo de cargas global basado en DNS no es la solución óptima para lidiar con el tráfico en situaciones con picos.
Cómo funcionan los balanceadores de cargas de aplicaciones externos
El balanceador de cargas de aplicaciones externo usa un enfoque diferente. El tráfico se envía mediante servidores de GFE implementados en la mayoría de las ubicaciones de la red perimetral global de Google. En la actualidad, esto constituye más de 80 ubicaciones en todo el mundo. El algoritmo de balanceo de cargas se aplica en los servidores de GFE.
El balanceador de cargas de aplicaciones externo está disponible a través de una única dirección IP estable que se anuncia de manera global en los nodos perimetrales y cualquiera de los GFE finalizan las conexiones.
Los GFE están interconectados a través de la red global de Google. Los datos que describen los backends y la capacidad de entrega disponibles para cada recurso con balanceo de cargas se distribuyen de forma continua a todos los GFE mediante un plano de control global.
El tráfico a direcciones IP con balanceo de cargas se envía a las instancias de backend definidas en la configuración del balanceador de cargas de aplicaciones externo mediante un algoritmo especial de balanceo de cargas llamado Cascada por región. Este algoritmo determina el backend óptimo para entregar la solicitud mediante la consideración de la proximidad de las instancias a los usuarios, la carga entrante y la capacidad disponible de los backends en cada zona y región. Por último, también se tiene en cuenta la carga y la capacidad mundial.
El balanceador de cargas de aplicaciones externo distribuye el tráfico según las instancias disponibles. Para agregar instancias nuevas según la carga, el algoritmo funciona en conjunto con los grupos de instancias de ajuste de escala automático.
Flujo de tráfico dentro de una región
En circunstancias normales, todo el tráfico se envía a la región que se encuentra más cerca del usuario. El balanceo de cargas se realiza de acuerdo con estos lineamientos:
Dentro de cada región, el tráfico se distribuye entre grupos de instancias, que pueden estar en varias zonas según la capacidad de cada grupo.
Si la capacidad es desigual entre las zonas, estas se cargan en proporción a la capacidad de entrega disponible.
Dentro de las zonas, las solicitudes se distribuyen de manera uniforme en las instancias de cada grupo de instancias.
Las sesiones se conservan en función de la dirección IP de cliente o de un valor de cookie, según la configuración de afinidad de sesión.
A menos que el backend no esté disponible, las conexiones TCP existentes nunca se trasladan a un backend diferente.
En el siguiente diagrama, se muestra la distribución de carga en este caso, en el cual cada región está por debajo de su capacidad y puede manejar la carga de los usuarios más cercanos a ella.
Desbordamiento de tráfico a otras regiones
Si una región completa alcanza la capacidad determinada por la capacidad de entrega establecida en los servicios de backend, se activa el algoritmo de Cascada por región y el tráfico se desborda hacia la región más cercana que tenga capacidad disponible. A medida que cada región alcanza su capacidad, el tráfico se dirige hacia la siguiente región más cercana y así sucesivamente. La proximidad de una región al usuario se define por el tiempo de ida y vuelta de la red desde el GFE hasta los backends de la instancia.
En el siguiente diagrama, se muestra el desbordamiento hacia la siguiente región más cercana cuando una región recibe más tráfico del que puede manejar de manera regional.
Desbordamiento interregional debido a backends en mal estado
Si en la verificación de estado se descubre que más de la mitad de los backends en una región están en mal estado, los GFE desbordarán sin interrupción algo de tráfico a la siguiente región más cercana. Esto sucede para evitar que el tráfico falle por completo, ya que la región está en mal estado. Este desbordamiento ocurre incluso si la capacidad restante en la región con los backends en mal estado es suficiente.
En el siguiente diagrama, se muestra el mecanismo de desbordamiento activo porque la mayoría de los backends en una zona están en mal estado.
Todas las regiones por encima de la capacidad
Cuando el tráfico a todas las regiones está en su capacidad máxima o por encima de ella, el tráfico se equilibra de modo que cada región se encuentre al mismo nivel relativo de desbordamiento en comparación con su capacidad. Por ejemplo, si la demanda global supera la capacidad global en un 20%, el tráfico se distribuye para que todas las regiones reciban solicitudes que superen en un 20% su capacidad regional al tiempo que mantienen el tráfico lo más local posible.
En el siguiente diagrama, se muestra esta regla de desbordamiento global activa. En este caso, una sola región recibe tanto tráfico que no se puede distribuir en absoluto con la capacidad de entrega disponible de manera global.
Desbordamiento temporal durante el ajuste de escala automático
El ajuste de escala automático se basa en los límites de capacidad configurados en cada servicio de backend y muestra instancias nuevas cuando el tráfico se acerca a los límites de capacidad configurados. Según la rapidez con la que aumenten los niveles de solicitud y con la que las instancias nuevas estén en línea, el desbordamiento hacia otras regiones podría ser innecesario. En otros casos, el desbordamiento puede actuar como un búfer temporal hasta que las instancias locales nuevas estén en línea y listas para entregar el tráfico en vivo. Cuando la capacidad que se expande por el ajuste de escala automático es suficiente, todas las sesiones nuevas se distribuyen a la región más cercana.
Efectos de latencia del desbordamiento
De acuerdo con el algoritmo de Cascada por región, puede ocurrir un desbordamiento de una parte del tráfico por el balanceador de cargas de aplicaciones externo hacia otras regiones. Sin embargo, el GFE más cercano al usuario sigue siendo el que finaliza las sesiones TCP y el tráfico SSL. Esto es beneficioso para la latencia de la aplicación. A fin de obtener más información, consulta Optimiza la latencia de la aplicación con balanceo de cargas.
Práctica: Mide los efectos de la administración de la capacidad
Para comprender cómo se produce el desbordamiento y cómo puedes administrarlo mediante el balanceador de cargas HTTP, consulta el instructivo de Administración de la capacidad con balanceo de cargas que acompaña este artículo.
Usa un balanceador de cargas de aplicaciones externo para abordar los desafíos de capacidad
Para ayudar a abordar los desafíos analizados antes, los balanceadores de cargas de aplicaciones externos y los balanceadores de cargas de red de proxy externos pueden desbordar la capacidad hacia otras regiones. Para las aplicaciones globales, la respuesta a los usuarios con una latencia general algo más alta da como resultado una mejor experiencia que el uso de un backend regional. Las aplicaciones que usan un backend regional tienen una latencia nominal más baja, pero se pueden sobrecargar.
Revisemos cómo un balanceador de cargas de aplicaciones externo puede ayudar a abordar las situaciones mencionadas en el inicio del artículo:
Latencia en el inicio de instancias nuevas. Si el escalador automático no puede agregar capacidad con la suficiente rapidez durante los picos de actividad de tráfico local, el balanceador de cargas de aplicaciones externo desborda las conexiones hacia la siguiente región más cercana de forma temporal. Esto garantiza que las sesiones de usuarios existentes en la región original se manejen a una velocidad óptima, ya que permanecen en los backends existentes, mientras que las sesiones de usuarios nuevos experimentan solo un ligero golpe de latencia. En cuanto las instancias de backend adicionales escalen verticalmente en la región original, el tráfico nuevo se enruta otra vez a la región más cercana a los usuarios.
Aplicaciones limitadas por la capacidad de backend. Las aplicaciones a las que no se les puede realizar un ajuste de escala automático, pero que están disponibles en varias regiones, aún pueden desbordarse a la siguiente región más cercana cuando la demanda en una región supera la capacidad implementada para las necesidades de tráfico habituales.
Licencias inflexibles. Si la cantidad de licencias de software es limitada y se agotó el conjunto de licencias en la región actual, el balanceador de cargas de aplicaciones externo puede trasladar el tráfico a una región en la que las licencias estén disponibles. Para que esto funcione, la cantidad máxima de instancias se establece en la cantidad máxima de licencias en el escalador automático.
Muy poco espacio de VM. La posibilidad de un desbordamiento regional ayuda a ahorrar dinero, ya que puedes configurar el ajuste de escala automático con un activador de uso de CPU alto. También puedes configurar la capacidad de backend disponible por debajo de cada pico regional, ya que el desbordamiento hacia otras regiones garantiza que la capacidad global siempre será suficiente.
Cuotas regionales. Si las cuotas de recursos de Compute Engine no coinciden con la demanda, el desbordamiento del balanceador de cargas de aplicaciones externo redirecciona automáticamente parte del tráfico hacia una región que aún puede escalar dentro de su cuota regional.
¿Qué sigue?
En las siguientes páginas, se proporciona más información y antecedentes sobre las opciones de balanceo de cargas de Google:
- Administración de la capacidad con balanceo de cargas (instructivo)
- Optimiza la latencia de las aplicaciones con el balanceo de cargas
- Codelab para Herramientas de redes 101
- Balanceador de cargas de red de transferencia externo
- Balanceador de cargas de aplicaciones externo
- Balanceador de cargas de red del proxy externo