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 más allá de la capacidad de entrega disponible. Este artículo explica cómo el uso del balanceo de cargas de Cloud puede abordar estos problemas y optimizar la capacidad de tu aplicación global. 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 recomendaciones centradas en los productos de balanceo de cargas en la nube de Google. Para ver un instructivo que acompaña este artículo, consulta Administración de capacidad con balanceo de cargas. Para una inmersión profunda en 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 que no son estables. En entornos públicos de la nube como Google Cloud Platform (GCP), la flexibilidad proporcionada por funciones como el ajuste de escala automático y el balanceo de cargas puede ser útil. Sin embargo, los escaladores automáticos tienen algunas limitaciones como se explica en esta sección.

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 tu tráfico. Dependiendo de 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, se tarda unos minutos antes de que el balanceo de cargas pueda dirigir a los usuarios a nuevas instancias de VM. Durante ese tiempo, el tráfico se distribuye a las instancias de VM existentes, lo que ya podría ser un exceso de capacidad.

Aplicaciones limitadas por capacidad de backend

Algunas aplicaciones no se pueden ajustar automáticamente. Por ejemplo, las bases de datos a menudo tienen una capacidad de backend limitada. Solo un número específico de interfaces puede acceder a una base de datos que no se ajusta 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 se puede ajustar automáticamente.

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 puede estar restringida porque no puedes agregar licencias sobre la marcha.

Muy poco espacio para la instancia de VM

Para tener en cuenta las ráfagas repentinas de tráfico, 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). Para ahorrar costos, puedes estar tentado de establecer este objetivo más alto, como el 90% de la capacidad de la CPU. Sin embargo, los valores de los activadores más altos pueden dar lugar a un escalamiento de cuellos de botella cuando se enfrentan a ráfagas 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 ráfagas inesperadas en una región, tus cuotas de recursos existentes podrían limitar el número de instancias que puedes escalar por debajo del nivel requerido para admitir la ráfaga actual. El procesamiento de un aumento en tu cuota de recursos puede tomar algunas horas o días.

Cómo abordar estos desafíos con el balanceo de cargas global

El balanceo de cargas de HTTP(S), el balanceo de cargas proxy SSL, y el balanceo de cargas de proxy TCP son productos de balanceo de cargas global que se distribuyen a través de servidores de Google frontend (GFE) sincronizados globalmente, lo cual ayuda a mitigar este tipo 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:

  • Round-robin Los paquetes se distribuyen de forma equitativa entre todos los backends, independientemente del origen y destino de los paquetes.
  • Hashing Los flujos de paquetes se identifican según los hashes de la información de tráfico, incluida la IP de origen, la IP de destino, el puerto y el protocolo. Todo el tráfico que produce el mismo valor hash fluye al mismo backend.

El balanceo de cargas de hash es el algoritmo disponible actualmente en el Balanceador de cargas de 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, la carga actual en los backends rara vez es un factor en la distribución de la carga.

Algunos balanceadores de cargas de hardware o software usan algoritmos que envían tráfico en función de otras métricas, como el round-robin 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 en el nivel esperado debido a las ráfagas de tráfico repentinas, el tráfico aún se distribuye a las instancias de backend que tienen capacidad excesiva, 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 efectivamente este tráfico y enviar un mensaje de "servicio no disponible, inténtelo de nuevo más tarde". Algunos balanceadores de cargas te dan la opción de poner solicitudes en una cola.

Las soluciones de balanceo de cargas global a menudo se implementan con un algoritmo basado en DNS, que entrega a diferentes direcciones 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 o parte del tráfico en una implementación regional. Sin embargo, en cualquier solución basada en DNS, la conmutación por error generalmente toma minutos, dependiendo del 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 más allá del tiempo en que el TTL debería haber expirado 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 funciona el balanceo de cargas HTTP(S)

El balanceo de cargas de HTTP(S) usa un enfoque diferente. El tráfico se envía mediante servidores GFE implementados en la mayoría de las ubicaciones de la red 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 GFE.

Mapa que muestra cerca de 80 puntos de presencia por todo el mundo

El balanceo de cargas de HTTP(S) está disponible a través de una única dirección IP estable que se anuncia globalmente en los nodos de borde, y las conexiones se finalizan por cualquiera de los GFE.

Las GFE están interconectadas a través de la red global de Google. Los datos que describen los backends disponibles y la capacidad de entrega disponible para cada recurso con cargas balanceadas se distribuyen continuamente a todas las GFE mediante un plano de control global.

Diagrama que muestra cómo pasan las solicitudes a través del GFE antes de ir a los Centros de datos de Google

El tráfico a direcciones IP de carga balanceada 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, teniendo en cuenta 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 capacidad mundial.

El balanceo de cargas de HTTP(S) distribuye el tráfico según las instancias disponibles. Para agregar nuevas instancias basadas en 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 más cercana al usuario. El balanceo de cargas se realiza de acuerdo con estas pautas:

  • Dentro de cada región, el tráfico se distribuye entre grupos de instancias, las cuales 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 la sesión.

  • A menos que el backend no esté disponible, las conexiones TCP existentes nunca se mueven a un backend diferente.

El siguiente diagrama muestra la distribución de carga en este caso, en el cual cada región tiene la capacidad y puede manejar la carga de los usuarios más cercanos a esa región.

Diagrama que muestra 50 RPS dirigiéndose a 3 regiones diferentes que pueden controlar cada carga

Tráfico ampliado 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 amplía a la región más cercana que tenga capacidad disponible. A medida que cada región alcanza su capacidad, el tráfico se derrama 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.

El siguiente diagrama muestra la ampliación a la siguiente región más cercana cuando una región recibe más tráfico del que puede manejar de manera regional.

Diagrama que muestra una sobrecarga de 150 RPS en una región que causa un exceso a la siguiente región más cercana

Ampliación interregional debido a backends en mal estado

Si la verificación de estado descubre que más de la mitad de los backends en una región están en mal estado, las GFE amplían 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. Esta ampliación ocurre incluso si la capacidad restante en la región con los backends en mal estado es suficiente.

El siguiente diagrama muestra el mecanismo de ampliación en efecto porque la mayoría de los backends en una zona están en mal estado.

Diagrama que muestra una falla parcial del backend en una región que causa un exceso a la siguiente región más cercana

Todas las regiones por encima de la capacidad

Cuando el tráfico a todas las regiones tiene una capacidad igual o superior, el tráfico se equilibra de modo que cada región se encuentre al mismo nivel relativo de ampliación en comparación con su capacidad. Por ejemplo, si la demanda global excede la capacidad global en un 20%, el tráfico se distribuye para que todas las regiones reciban solicitudes al 20% sobre su capacidad regional al tiempo que mantienen el tráfico lo más local posible.

El siguiente diagrama muestra esta regla de ampliación global vigente. 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 que muestra todas las regiones por encima de su capacidad con solicitudes distribuidas globalmente

Ampliación 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 nuevas instancias cuando el tráfico se acerca a los límites de capacidad configurados. Dependiendo de la rapidez con la que aumentan los niveles de solicitud y de la rapidez con que las nuevas instancias estén en línea, la ampliación a otras regiones puede ser innecesaria. En otros casos, la ampliación 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 expandida 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 de la ampliación

De acuerdo con el algoritmo de cascada por región, puede ocurrir una ampliación de una parte del tráfico por el balanceo de cargas HTTP(S) hacia otras regiones. Sin embargo, las sesiones TCP y el tráfico SSL siguen siendo determinados por el GFE más cercano al usuario. Esto es beneficioso para la latencia de la aplicación. A fin de obtener más información, consulta Optimización de la latencia de la aplicación con balanceo de cargas.

Práctica: Medición de 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.

Cómo usar 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 de HTTP(S), el balanceo de cargas de proxy de TCP y el balanceo de cargas de proxy de SSL pueden ampliar la capacidad a otras regiones. Para las aplicaciones globales, que responden 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 pueden sobrecargarse.

Revisemos cómo el balanceo de cargas de 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 las ráfagas de tráfico locales, el balanceo de cargas de HTTP(S) amplía temporalmente las conexiones a la siguiente región más cercana. 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. Tan pronto como las instancias de backend adicionales se amplíen en la región original, el nuevo tráfico se enruta nuevamente a la región más cercana a los usuarios.

  • Aplicaciones limitadas por capacidad de backend. Las aplicaciones que no se pueden ajustar automáticamente, pero que están disponibles en varias regiones, aún pueden ampliarse a la siguiente región más cercana cuando la demanda en una región está más allá de la capacidad implementada para las necesidades de tráfico habituales.

  • Licencias inflexibles. Si el número de licencias de software es limitado, y si se ha agotado el conjunto de licencias en la región actual, el balanceo de cargas de 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 una ampliación regional ayuda a ahorrar dinero, ya que puede configurar el ajuste de escala automático con un alto activador de uso de la CPU. También puedes configurar la capacidad de backend disponible por debajo de cada pico regional, porque la ampliación a 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, la ampliación de balanceo de cargas de HTTP(S) redirecciona automáticamente parte del tráfico a una región que aún puede escalar dentro de su cuota regional.

¿Qué sigue?

Las siguientes páginas proporcionan más información y antecedentes sobre las opciones de balanceo de cargas de Google:

Prueba otras funciones de Google Cloud Platform tú mismo. Revisa nuestros instructivos.

¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…