Configura colas de Cloud Tasks

En esta página, se describe cómo configurar listas de tareas en cola de Cloud Tasks con el comando gcloud del SDK de Google Cloud.

Configura la cola de Cloud Tasks

Puedes configurar tu cola de Cloud Tasks cuando crees la cola o en cualquier momento posterior, y la configuración se aplicará a todas las tareas en esa cola.

La configuración de las colas tiene tres aspectos básicos:

Configura el enrutamiento (solo colas de App Engine)

La cola necesita conocer el nombre y la versión del servicio que contiene el trabajador adecuado. Esto es lo que se denomina el objetivo. Hay tres maneras de configurarlo:

  • No configurar el objetivo explícitamente. En este caso, se usa el servicio predeterminado.
  • Para declarar explícitamente el destino en la tarea, configura AppEngineRouting en AppEngineHttpRequest. Este es el método preferido si deseas usar un objetivo distinto del predeterminado.
  • Enrutar todas las tareas de una cola explícitamente a un objetivo no predeterminado con appEngineRoutingOverride. Este método anula los datos de configuración que estén configurados en la tarea en sí.

Si quieres usar gcloud para configurar este enrutamiento no predeterminado a nivel de la cola y, por lo tanto, anular cualquier enrutamiento a nivel de tarea, sigue estos pasos:

gcloud tasks queues update [QUEUE_ID] \
    --routing-override=service:[SERVICE],version:[VERSION]

Donde:

  • SERVICE es el servicio trabajador de App Engine responsable de manejar las tareas.
  • VERSION es la versión de la app.

Por ejemplo, si configuras un servicio trabajador llamado worker para que maneje todas las tareas de una cola llamada barbequeue, puedes enrutar a ese servicio y a la versión predeterminada con la siguiente llamada:

gcloud tasks queues update barbequeue \
    --routing-override=service:worker

Describe la cola:

gcloud tasks queues describe barbequeue

El resultado debería ser algo como lo siguiente:

appEngineRoutingOverride:
  host: worker.[PROJECT_ID].appspot.com
  service: worker
name: projects/[PROJECT_ID]/locations/[LOCATION_ID]/queues/barbequeue
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 1000
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

Define límites de frecuencia

Puedes configurar valores máximos para la frecuencia y la cantidad de tareas simultáneas que puede enviar una cola.

gcloud tasks queues update [QUEUE_ID] \
    --max-dispatches-per-second=[DISPATCH_RATE] \
    --max-concurrent-dispatches=[MAX_RUNNING]

Donde:

  • DISPATCH_RATE es en realidad la velocidad a la que se actualizan los tokens del depósito. En condiciones en las que hay un flujo de tareas relativamente estable, este es el equivalente a la velocidad a la que se envían las tareas.
  • MAX_RUNNING es la cantidad máxima de tareas de la cola que pueden ejecutarse a la vez.

Por ejemplo, si creaste una cola llamada barbequeue sin configurar ningún parámetro, puedes actualizar la cantidad máxima de tareas simultáneas con la siguiente llamada:

gcloud tasks queues update barbequeue \
        --max-concurrent-dispatches=20

Describe la cola:

gcloud tasks queues describe barbequeue

El resultado debería ser el siguiente:

name: projects/[PROJECT_ID]/locations/[LOCATION_ID]/queues/barbequeue
rateLimits:
  maxBurstSize: 100
  maxConcurrentDispatches: 20
  maxDispatchesPerSecond: 500.0
retryConfig:
  maxAttempts: 100
  maxBackoff: 3600s
  maxDoublings: 16
  minBackoff: 0.100s
state: RUNNING

Define definiciones de procesamiento con comandos gcloud frente a queue.yaml

El enfoque de la API de Cloud Tasks para definir las tasas de procesamiento de colas difiere levemente del enfoque tomado con la carga de archivos queue.yaml, a pesar de que ambos métodos generan colas con el mismo mecanismo subyacente.

En ambos casos, la cola usa el algoritmo del depósito de token para controlar la frecuencia de ejecución de las tareas. Cada cola nombrada tiene un depósito que contiene sus tokens.

Cada vez que tu aplicación ejecuta una tarea, se quita un token del depósito. La cola continúa procesando tareas hasta que el depósito se queda sin tokens. El sistema rellena el depósito con tokens nuevos de forma continua según la tasa de max_dispatches_per_second que especifiques para la cola. Si tu cola contiene tareas que se deben procesar, y el depósito correspondiente contiene tokens, el sistema procesa de forma simultánea tantas tareas como pueda con los tokens disponibles hasta el valor max_concurrent_dispatches que establezcas.

La carga desigual puede permitir que la cantidad de tokens en el depósito crezca de manera significativa, lo que puede generar picos de actividad de procesamiento cuando llega un pico de solicitudes. En este caso, tu cola puede experimentar una tasa de envío real que supere tu tasa de max_dispatches_per_second, lo que consume recursos del sistema y compite con las solicitudes de servicio del usuario. En los casos en que usas colas para administrar las tasas de envío basadas en ANS relativamente lentas para servicios descendentes, esto puede generar errores como HTTP 429 (Demasiadas solicitudes) o 503 (Servicio no disponible).

Cuando usas cualquier método de la API de Cloud Tasks, tienes dos campos para definir la frecuencia de envío de las colas:

  • max_dispatches_per_second
  • max_concurrent_dispatches

como se muestra en el ejemplo anterior. El sistema calcula un tercer campo, max_burst_size, en función del valor que estableces para max_dispatches_per_second.

Cuando usas el método queue.yaml, puedes configurar los tres elementos:

  • max_concurrent_requests, que equivale a max_concurrent_dispatches
  • rate, que es equivalente a max_dispatches_per_second
  • bucket_size, que es equivalente a max_burst_size

En la mayoría de los casos, usar el método de la API de Cloud Tasks y dejar que el sistema configurado max_burst_size produce una tasa muy eficiente para administrar los picos de solicitudes. Sin embargo, en algunos casos, en especial cuando la tasa deseada es relativamente lenta, ya sea mediante el método queue.yaml para configurar de forma manual bucket_size a un valor pequeño o configura tu max_concurrent_dispatches a un valor pequeño mediante la API de Cloud Tasks te puede brindar más control.

Configura los parámetros de reintento

Si una tarea no se completa correctamente, Cloud Tasks la reintenta con una retirada exponencial que depende de los parámetros que hayas configurado. Puedes especificar el máximo de veces que se debe reintentar una tarea con errores en la cola, y también puedes configurar un límite de tiempo para los reintentos y un intervalo de espera entre uno y otro.

gcloud tasks queues update [QUEUE_ID] \
    --max-attempts=[MAX_ATTEMPTS] \
    --min-backoff=[MIN_INTERVAL] \
    --max-backoff=[MAX_INTERVAL] \
    --max-doublings=[MAX_DOUBLINGS] \
    --max-retry-duration=[MAX_RETRY_DURATION]

Donde:

  • MAX_ATTEMPTS es la cantidad máxima de intentos de una tarea (incluido el primero). Para permitir una cantidad ilimitada de reintentos, configura la marca en unlimited.
  • MIN_INTERVAL es la cantidad mínima de tiempo que debes esperar entre dos intentos. El valor debe ser una string que termine en "s", como 5s.
  • MAX_INTERVAL es la cantidad máxima de tiempo que debe esperarse entre dos intentos. El valor debe ser una string que termine en "s", como 5s.
  • MAX_DOUBLINGS es la cantidad máxima de veces que se duplicará el intervalo entre los reintentos de las tareas con errores antes de que el aumento se vuelva constante.
  • MAX_RETRY_DURATION es la cantidad máxima de tiempo que debe esperarse antes de reintentar una tarea con errores. El valor debe ser una string que termine en "s", como 5s.

Verifica que tu cola se haya configurado correctamente:

gcloud tasks queues describe [QUEUE_ID]

Qué sigue