La infraestructura de Google se ha diseñado para operar de forma flexible a gran escala: la mayoría de las capas pueden adaptarse a las demandas de tráfico crecientes hasta alcanzar una escala masiva. Un patrón de diseño principal que lo hace posible son las capas adaptativas, es decir, los componentes de infraestructura que reasignan la carga de forma dinámica en función de los patrones de tráfico. Sin embargo, esta adaptación lleva tiempo. Como Cloud Tasks permite enviar volúmenes de tráfico muy altos, expone los riesgos de producción en situaciones en las que el tráfico puede aumentar más rápido de lo que la infraestructura puede adaptarse.
Información general
En este documento se proporcionan directrices sobre las prácticas recomendadas para mantener el alto rendimiento de Cloud Tasks en las colas de tráfico alto. Una cola de alta TPS es una cola que tiene 500 tareas creadas o distribuidas por segundo (TPS) o más. Un grupo de colas de TPS alto es un conjunto contiguo de colas, por ejemplo [queue0001, queue0002, …, queue0099], que tienen al menos 2000 tareas creadas o enviadas en total. El TPS histórico de una cola o un grupo de colas se puede consultar mediante las métricas de Cloud Monitoring, api/request_count
para las operaciones "CreateTask" y queue/task_attempt_count para los intentos de tarea. Las colas de tráfico alto y los grupos de colas son propensos a dos grandes clases diferentes de fallos:
La sobrecarga de la cola se produce cuando la creación de tareas y el envío a una cola o a un grupo de colas concretos aumenta más rápido de lo que la infraestructura de la cola puede adaptarse. Del mismo modo, se produce una sobrecarga de destino cuando la velocidad a la que se envían las tareas provoca picos de tráfico en la infraestructura de destino. En ambos casos, te recomendamos que sigas un patrón de 500/50/5: cuando superes las 500 TPS, aumenta el tráfico en no más de un 50% cada 5 minutos. En este documento se analizan diferentes escenarios que pueden provocar riesgos de escala y se proporcionan ejemplos sobre cómo aplicar este patrón.
Sobrecarga de cola
Las colas o los grupos de colas pueden sobrecargarse cada vez que el tráfico aumenta de forma repentina. Como resultado, estas colas pueden experimentar estos efectos:
- Mayor latencia en la creación de tareas
- Aumento del intervalo de error de creación de tareas
- Reducción del intervalo de envío
Si quieres evitar esto, recomendamos establecer controles en cualquier situación en la que el intervalo de creación o envío de una cola o grupo de cola pueda aumentar de forma repentina. Recomendamos un máximo de 500 operaciones por segundo en una cola o un grupo de colas frías y, a continuación, aumentar el tráfico en un 50% cada 5 minutos. En teoría, puedes llegar a 740.000 operaciones por segundo después de 90 minutos con esta programación de aumento. Hay una serie de circunstancias en las que esto puede ocurrir.
Por ejemplo:
- Al lanzar nuevas funciones que hacen un uso intensivo de Cloud Tasks
- Al mover el tráfico entre colas
- Al intentar equilibrar el tráfico entre más o menos colas
- Al ejecutar tareas por lotes que incluyan un gran número de tareas
En estos casos, sigue el patrón 500/50/5.
Usar la división del tráfico de App Engine
Si las tareas las crea una aplicación de App Engine, puedes aprovechar la división del tráfico de App Engine (Standard/Flex) para suavizar los aumentos de tráfico. Al dividir el tráfico entre versiones (Estándar/Flex), las solicitudes que necesiten gestión de tarifas se pueden poner en marcha con el tiempo para proteger el estado de la cola. Por ejemplo, supongamos que se aumenta el tráfico a un grupo de colas recién ampliado: sea [queue0000, queue0199] una secuencia de colas de alto TPS que reciben un total de 100.000 creaciones de TPS en el momento de mayor actividad.
Deja que [queue0200, queue0399] sea una secuencia de colas nuevas. Una vez que se ha cambiado todo el tráfico, el número de colas en la secuencia se habrá duplicado y el nuevo intervalo de colas recibirá el 50 % del tráfico total de la secuencia.
Al desplegar la versión que aumenta el número de colas, se aumenta gradualmente el tráfico a la nueva versión y, por lo tanto, las nuevas colas, mediante la división del tráfico:
- Comienza por cambiar el 1 % del tráfico a la nueva versión. Por ejemplo, el 50 % del 1 % de 100.000 TPS constituye 500 TPS para el conjunto de colas nuevas.
- Cada 5 minutos, aumenta en un 50 % el tráfico que se envía a la nueva versión como se especifica en la siguiente tabla:
| Minutos desde el inicio del despliegue | % del tráfico total enviado a la versión nueva | % del tráfico total enviado a las colas nuevas | % del tráfico total que permanece a las colas antiguas |
|---|---|---|---|
| 0 | 1 | 0,5 | 99,5 |
| 5 | 1,5 | 0,75 | 99,25 |
| 10 | 2,3 | 1,15 | 98,85 |
| 15 | 3,4 | 1,7 | 98,3 |
| 20 | 5,1 | 2,55 | 97,45 |
| 25 | 7,6 | 3,8 | 96,2 |
| 30 | 11,4 | 5,7 | 94,3 |
| 35 | 17,1 | 8,55 | 91,45 |
| 40 | 25,6 | 12,8 | 87,2 |
| 45 | 38,4 | 19,2 | 80,8 |
| 50 | 57,7 | 28,85 | 71,15 |
| 55 | 86,5 | 43,25 | 56,75 |
| 60 | 100 | 50 | 50 |
Picos de tráfico impulsados por el lanzamiento de versiones
Al lanzar una versión que aumenta significativamente el tráfico de una cola o grupo de colas, el despliegue gradual es, de nuevo, un mecanismo importante para suavizar estos aumentos. Poco a poco, despliega las instancias de modo que el lanzamiento inicial no exceda las 500 operaciones totales en las colas nuevas, y auméntalo en un máximo de 50 % cada 5 minutos.
Colas o grupos de colas nuevos con un alto nivel de TPS
Las colas recién creadas son especialmente vulnerables. Los grupos de colas, por ejemplo, [queue0000, queue0001, ..., queue0199], son tan vulnerables como las colas únicas durante las etapas de despliegue inicial. En el caso de estas colas, el despliegue gradual constituye una estrategia importante. El lanzamiento de servicios nuevos o actualizados que crean colas o grupos de colas con un alto nivel de TPS en etapas en las que la carga inicial es inferior a 500 TPS y que aumentan en un máximo de un 50 % se programa cada 5 minutos o más.
Grupos de cola ampliados recientemente
Al aumentar la capacidad total de un grupo de colas, por ejemplo, al ampliar [queue0000-queue0199 a queue0000-queue0399], sigue el patrón 500/50/5. Es importante tener en cuenta que, en los procedimientos de despliegue, los nuevos grupos de colas no se comportan de forma diferente a las colas individuales. Aplica el patrón 500/50/5 al grupo nuevo como una unidad, no solo a las colas individuales del grupo. En el caso de estas expansiones de grupos de colas, el despliegue gradual vuelve a ser una estrategia importante. Si la fuente de tu tráfico es App Engine, puedes usar la división del tráfico (consulta Picos de tráfico provocados por lanzamientos). Al migrar el servicio para añadir tareas al mayor número de colas, despliega gradualmente las instancias de modo que en la fase inicial no se exceda la cantidad de 500 operaciones totales en las colas nuevas, y auméntalas en un máximo de un 50 % cada 5 minutos.
Ampliación del grupo de cola de emergencia
En ocasiones, es posible que quieras expandir un grupo de colas, por ejemplo, porque se espera que las tareas se añadan al grupo de colas más rápido de lo que el grupo puede enviarlas. Si los nombres de las nuevas colas se distribuyen de forma uniforme entre los nombres de las colas que ya tienes al ordenarlos lexicográficamente, el tráfico se puede enviar inmediatamente a esas colas siempre que no haya más de un 50% de colas intercaladas nuevas y el tráfico de cada cola sea inferior a 500 TPS. Este método es una alternativa a la división del tráfico y al lanzamiento gradual, tal como se describe en las secciones anteriores.
Este tipo de nomenclatura intercalada se puede conseguir al añadir un sufijo a las colas que terminan en números pares. Por ejemplo, si tienes 200 colas [queue0000-queue0199] y deseas crear 100 colas más, elige [queue0000a, queue0002a, queue0004a, ..., queue0198a] como los nuevos nombres de la cola, en lugar de [queue0200-queue0299].
Si necesitas un aumento adicional, puedes intercalar hasta un 50 % más de colas cada 5 minutos.
Colas de tareas a gran escala y por lotes
Cuando se necesita añadir una gran cantidad de tareas, por ejemplo, millones o miles de millones, un patrón de doble inyección puede resultar útil. En lugar de crear tareas desde un solo trabajo, usa una cola de inyector. Cada tarea que se añade a la cola del inyector se expande y aporta otras 100 tareas a la cola o al grupo de cola que desees. La velocidad de la cola del inyector se puede aumentar con el tiempo, por ejemplo, puede comenzar a 5 TPS y, a continuación, se puede aumentar en un 50 % cada 5 minutos.
Tareas con nombre
Cuando creas una tarea nueva, Cloud Tasks le asigna a la tarea un nombre único de forma predeterminada. Puedes asignarle el nombre que quieras a una tarea mediante el parámetro de nombre. Sin embargo, esto provoca una sobrecarga de rendimiento significativa, lo que causa un aumento de las latencias y un incremento potencial de los intervalos de error asociados con las tareas con nombre. Estos costes pueden aumentar significativamente si se les da nombre a las tareas de forma secuencial, como con las marcas de tiempo. Por lo tanto, si asignas los nombres que quieras, te recomendamos utilizar un prefijo bien distribuido para los nombres de las tareas, como un resumen de los contenidos. Consulta la documentación para obtener más información sobre cómo asignar un nombre a una tarea.
Sobrecarga del objetivo
Cloud Tasks puede sobrecargar otros servicios que estés usando, como App Engine, Datastore y tu uso de la red, si los envíos de una cola aumentan drásticamente en un breve periodo. Si se ha acumulado un retraso en las tareas, la eliminación de esas colas podría sobrecargar estos servicios. Esto se puede intentar evitar si se usa el patrón 500/50/5, que se sugirió para la sobrecarga de cola: si una cola envía más de 500 TPS, aumenta el tráfico impulsado por una cola en un máximo del 50 % cada 5 minutos. Para monitorizar los aumentos de tráfico de forma proactiva, utiliza las métricas de Cloud Monitoring. Puedes usar las alertas de Cloud Monitoring para detectar situaciones potencialmente peligrosas.
Pausar o reanudar las colas con un alto nivel de TPS
Cuando una cola o una serie de colas no se pausan ni se vuelven a habilitar, se reanudan los envíos. Si la cola tiene muchas tareas, la velocidad de envío de la cola recién habilitada podría aumentar drásticamente de 0 TPS a la capacidad total de la cola. Para aumentar la carga, escalona la reanudación de las colas o controla las tasas de envío de las colas mediante maxDispatchesPerSecond de Cloud Tasks.
Tareas programadas en lote
Programar un gran número de tareas para que se envíen al mismo tiempo puede constituir también un riesgo de sobrecarga del objetivo. Si necesitas iniciar una gran cantidad de tareas a la vez, usa controles de velocidad de cola para aumentar la velocidad de envío de forma gradual o aumentando la capacidad objetivo previamente de forma explícita.
Aumento de la distribución ramificada
Mientras se actualizan los servicios que se ejecutan mediante Cloud Tasks, un aumento del número de llamadas remotas podría acarrear riesgos de producción. Por ejemplo, supongamos que las tareas de una cola de TPS alto llaman al controlador /task-foo. Una nueva versión podría aumentar significativamente el coste de llamar a /task-foo
si, por ejemplo, esa nueva versión añade varias llamadas costosas a Datastore al controlador. El resultado neto de este lanzamiento de versión sería un aumento masivo del tráfico de Datastore, que está relacionado de forma directa con los cambios en el tráfico del usuario. Usa el despliegue gradual o la división del tráfico para administrar la aceleración gradual.
Reintentos
Tu código puede volver a intentar la operación si falla al hacer llamadas a la API Cloud Tasks. Sin embargo, cuando una proporción significativa de las solicitudes falla con errores del lado del servidor, una tasa alta de reintentos puede sobrecargar aún más las colas y hacer que se recuperen más lentamente. Por lo tanto, te recomendamos que limites la cantidad de tráfico saliente si tu cliente detecta que una proporción significativa de las solicitudes falla con errores del lado del servidor. Por ejemplo, puedes usar el algoritmo de limitación adaptativa que se describe en el capítulo Handling Overload (Gestión de la sobrecarga) del libro Site Reliability Engineering (Ingeniería de fiabilidad de sitios). Las bibliotecas de clientes gRPC de Google implementan una variación de este algoritmo.