Optimizaciones de la capacidad de la aplicación con balanceo de cargas global

La mayoría de los balanceadores de cargas usan un método de hashing de turno rotativo o basado en 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 repentinamente 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 global de tu aplicación. A menudo, esto da como resultado una mejor experiencia del usuario y menores costos en comparación con las implementaciones tradicionales de 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 Optimización de 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, especialmente si tienes presupuestos limitados de TI 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 nuevas instancias

El problema más común con el ajuste de escala automático es que la aplicación solicitada no esté lista lo suficientemente rápido para entregar tráfico. Según las imágenes de tu instancia de VM, las secuencias de comandos normalmente 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 para dirigir a los usuarios a nuevas instancias de VM. Durante ese tiempo, el tráfico se distribuye a las instancias de VM existentes, que podrían ya estar excedidas en la capacidad.

Aplicaciones limitadas por la capacidad de backend

Algunas aplicaciones no admiten el ajuste de escala automático. Por ejemplo, las bases de datos a menudo tienen una capacidad de backend limitada. Solo un número específico de frontends puede acceder a una base de datos que no escala horizontalmente. Si tu aplicación se basa en API externas que solo admiten un número limitado de solicitudes por segundo, la aplicación tampoco puede realizar un ajuste de escala automático.

Licencias inflexibles

Cuando usas un software con licencia, tu licencia a menudo te limita a una capacidad máxima preestablecida. Por lo tanto, tu capacidad de ajuste de escala automático puede estar 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 los activadores 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 repentinamente la demanda. Debes equilibrar el tamaño del espacio en función de los picos de tu tráfico y del tiempo que tardan en prepararse las nuevas instancias de VM.

Cuotas regionales

Si tienes picos de actividad inesperados en una región, tus cuotas de recursos existentes podrían limitar por debajo del nivel requerido el número de instancias que puedes escalar para admitir el pico de actividad actual. Procesar un aumento en tu cuota de recursos puede demorar algunas horas o días.

Aborda estos desafíos con el balanceo de cargas global

El balanceo de cargas HTTP(S), el balanceo de cargas de proxy SSL, y el balanceo de cargas de proxy TCP son productos de balanceo de cargas global que se procesan a través de servidores de Google Front End (GFE) sincronizados globalmente, lo cual ayuda a mitigar este tipo de desafíos relacionados con el 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 secciones siguientes.

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, independientemente de sus orígenes o destinos.
  • 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 el balanceador de cargas de la red de Google. Este balanceador de cargas admite el hash de 2 tuplas (basado en la IP de origen y 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 el número 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 donde 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 el 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.

Las soluciones de balanceo de cargas global a menudo se implementan con un algoritmo basado en DNS, que realiza entregas a diferentes IP de balanceo de cargas regional según la ubicación del usuario y la carga de backend. Estas soluciones ofrecen conmutación por error a otra región para todo el tráfico (o una parte) de una implementación regional. Sin embargo, en cualquier solución basada en DNS, la conmutación por error generalmente toma 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 antiguos mucho después de que el TTL se haya vencido 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 poco estables.

Cómo funciona el balanceo de cargas HTTP(S)

El balanceo de cargas HTTP(S) 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. Esto constituye actualmente más de 80 ubicaciones en todo el mundo. El algoritmo de balanceo de cargas se aplica en los servidores de GFE.

Mapa en el que se muestran cerca de 80 puntos de presencia en todo el mundo

El balanceo de cargas HTTP(S) está disponible a través de una única dirección IP estable que se anuncia globalmente 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 continuamente a todos los GFE mediante un plano de control global.

Diagrama en el que se muestra de qué forma las solicitudes pasan a través del GFE antes de dirigirse a los centros de datos de Google

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 HTTP(S) 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 mundiales.

El balanceo de cargas HTTP(S) distribuye el tráfico según las instancias disponibles. Para agregar nuevas instancias 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, las zonas se cargan en proporción a su capacidad de entrega disponible.

  • Dentro de las zonas, las solicitudes se distribuyen uniformemente 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 mueven 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.

Diagrama en el que se muestran 50 RPS que se dirigen a 3 regiones diferentes que pueden controlar esta carga

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.

Diagrama en el que se muestra una sobrecarga de 150 RPS en una región, que causa un desborde hacia la siguiente región más cercana

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 algo de tráfico a la siguiente región más cercana sin interrupción. 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.

Diagrama en el que se muestra una falla parcial del backend en una región, que causa un desbordamiento hacia la siguiente región más cercana

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 su capacidad, el tráfico se equilibra de modo tal 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.

Diagrama en el que se muestran todas las regiones por encima de su capacidad, con solicitudes distribuidas globalmente

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 activa nuevas instancias 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 que las nuevas instancias 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 nuevas instancias locales 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 algo de tráfico por el balanceo de cargas HTTP(S) 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 cómo optimizar la latencia de la aplicación con el 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 Administración de la capacidad con balanceo de cargas (instructivo) que acompaña este artículo.

Usa el balanceo de cargas HTTP(S) para enfrentar los desafíos de capacidad

Para ayudar a abordar los desafíos analizados anteriormente, el balanceo de cargas HTTP(S), el balanceo de cargas de proxy TCP y el balanceo de cargas de proxy SSL pueden desbordar la capacidad hacia otras regiones. Para las aplicaciones globales, la respuesta a los usuarios con una latencia general ligeramente 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 el balanceo de cargas HTTP(S) puede ayudar a abordar las situaciones mencionadas en el inicio del artículo:

  • Latencia en el inicio de nuevas instancias. Si el escalador automático no puede agregar capacidad lo suficientemente rápido durante los picos de actividad de tráfico locales, el balanceo de cargas HTTP(S) 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 nuevo tráfico se enruta de nuevo 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 el número de licencias de software es limitado y se agotó el conjunto de licencias en la región actual, el balanceo de cargas HTTP(S) puede mover el tráfico a una región donde las licencias estén disponibles. Para que esto funcione, el número máximo de instancias se establece en el número máximo 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 balanceo de cargas HTTP(S) redirecciona automáticamente parte del tráfico hacia una región que aún puede escalar dentro de su cuota regional.

Próximos pasos

En las siguientes páginas, se proporciona más información y antecedentes sobre las opciones de balanceo de cargas de Google:

Prueba otras funciones de Google Cloud. Revisa nuestros instructivos.