Configura le code di Cloud Tasks

In questa pagina viene descritto come configurare le coda Cloud Tasks utilizzando il comando gcloud di Google Cloud CLI.

Configurazione della coda di Cloud Tasks

Puoi configurare la coda Cloud Tasks quando crei la coda o in qualsiasi momento successivo e la configurazione verrà applicata a tutte le attività della coda.

Esistono tre aspetti di base per la configurazione delle code:

Configura il routing (solo code di App Engine)

La coda deve conoscere il nome e la versione del servizio che contiene il worker appropriato. Questo è noto come target. Esistono tre modi per impostare il target:

  • Non impostare esplicitamente la destinazione. In questo caso viene utilizzato il servizio predefinito.
  • Dichiara esplicitamente il target nell'attività stessa impostando AppEngineRouting in AppEngineHttpRequest. Si tratta del metodo preferito se vuoi utilizzare un target diverso da quello predefinito.
  • Instrada esplicitamente tutte le attività in una coda a un target non predefinito utilizzando appEngineRoutingOverride. Questo metodo esegue l'override di qualsiasi routing che potrebbe essere impostato nell'attività stessa.

Per utilizzare gcloud per impostare questo routing a livello di coda non predefinito e sostituire quindi qualsiasi routing a livello di attività:

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

dove:

  • SERVICE è il servizio worker di App Engine responsabile della gestione delle attività.
  • VERSION è la versione dell'app.

Ad esempio, se configuri un servizio worker denominato worker per gestire tutte le attività in una coda chiamata barbequeue, puoi indirizzare quel servizio e la versione predefinita chiamando:

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

Describe la coda:

gcloud tasks queues describe barbequeue

L'output dovrebbe avere il seguente aspetto:

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

Rimuovi il routing:

gcloud tasks queues update [QUEUE_ID] \
    --clear-routing-override

Definisci limiti di frequenza

Puoi impostare la frequenza massima e il numero di attività simultanee che possono essere inviate da una coda.

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

dove:

  • DISPATCH_RATE è in effetti la frequenza con cui i token nel bucket vengono aggiornati. In condizioni in cui il flusso di attività è relativamente costante, questo è l'equivalente della frequenza di invio delle attività.
  • MAX_RUNNING è il numero massimo di attività in coda che possono essere eseguite contemporaneamente.

Ad esempio, se hai creato una coda chiamata barbequeue senza impostare alcun parametro, puoi aggiornare il numero massimo di attività simultanee chiamando:

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

Describe la coda:

gcloud tasks queues describe barbequeue

L'output dovrebbe essere:

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

Definizione delle frequenze di elaborazione tramite comandi gcloud rispetto all'uso di queue.yaml

L'approccio dell'API Cloud Tasks per definire le frequenze di elaborazione delle code varia leggermente rispetto all'approccio adottato utilizzando il caricamento di queue.yaml file, anche se entrambi i metodi generano code che utilizzano lo stesso meccanismo sottostante.

In entrambi i casi, la coda utilizza l'algoritmo del bucket token per controllare la frequenza di esecuzione delle attività. Ogni coda denominata contiene un bucket che contiene i propri token.

Ogni volta che l'applicazione esegue un'attività, un token viene rimosso dal bucket. La coda continua l'elaborazione delle attività finché il bucket non esaurisce i token. Il sistema reintegra il bucket con nuovi token in modo continuo, in base alla tariffa max_dispatches_per_second specificata per la coda. Se la coda contiene attività da elaborare e il bucket della coda contiene token, il sistema elabora contemporaneamente tutte le attività necessarie per i token, fino al valore max_concurrent_dispatches impostato.

Un carico non uniforme può aumentare in modo significativo il numero di token nel bucket, il che può portare a burst di elaborazione quando arriva un burst di richieste. In questo caso, la coda potrebbe notare una frequenza di invio effettiva che supera la tariffa di max_dispatches_per_second, consumando risorse di sistema e competendo con le richieste di pubblicazione degli utenti. Nei casi in cui utilizzi le code per gestire le tariffe di spedizione in base a SLA (accordo sul livello del servizio) relativamente lenti per i servizi di downstream, questo può causare errori come HTTP 429 (Troppe richieste) o 503 (servizio non disponibile).

Quando utilizzi un metodo dell'API Cloud Tasks, hai due campi per definire la frequenza di invio delle code:

  • max_dispatches_per_second
  • max_concurrent_dispatches

come mostrato nell'esempio sopra. Un terzo campo, max_burst_size, viene calcolato dal sistema in base al valore impostato per max_dispatches_per_second.

Se utilizzi il metodo queue.yaml, puoi impostare tutti e tre gli elementi:

  • max_concurrent_requests, che equivale a max_concurrent_dispatches
  • rate, che equivale a max_dispatches_per_second
  • bucket_size, che equivale a max_burst_size

Nella maggior parte dei casi, l'utilizzo del metodo API Cloud Tasks e lasciare che il sistema imposti max_burst_size generi una tariffa molto efficiente per la gestione di burst di richieste. In alcuni casi, tuttavia, in particolare quando la frequenza desiderata è relativamente lenta, l'uso del metodo queue.yaml per impostare manualmente bucket_size su un valore piccolo o l'impostazione max_concurrent_dispatches su un valore piccolo tramite l'API Cloud Tasks può offrirti un maggiore controllo.

Imposta i parametri di ripetizione

Se un'attività non viene completata correttamente, Cloud Tasks la proverà nuovamente a eseguire il backoff esponenziale in base ai parametri impostati. Puoi specificare il numero massimo di tentativi per le attività non riuscite in coda, impostare un limite di tempo per i nuovi tentativi e controllare l'intervallo tra tentativi.

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]

dove:

  • MAX_ATTEMPTS corrisponde al numero massimo di tentativi per un'attività, incluso il primo tentativo. Puoi consentire un numero illimitato di nuovi tentativi impostando questo flag su unlimited.
  • MIN_INTERVAL è il tempo minimo di attesa tra un nuovo tentativo e l'altro. Il valore deve essere una stringa che termina con "&", come 5s.
  • MAX_INTERVAL è il tempo massimo di attesa tra un nuovo tentativo e l'altro. Il valore deve essere una stringa che termina con "&", come 5s.
  • MAX_DOUBLINGS è il numero massimo di volte in cui l'intervallo tra nuovi tentativi non riusciti viene raddoppiato prima che l'aumento diventi costante.
  • MAX_RETRY_DURATION è il tempo massimo per il nuovo tentativo di un'attività non riuscita, misurato dal primo tentativo dell'attività. Il valore deve essere una stringa che termina con "&", come 5s.

Verifica che la coda sia stata configurata correttamente:

gcloud tasks queues describe [QUEUE_ID]

Passaggi successivi