Configura le code di Cloud Tasks

Puoi configurare la coda Cloud Tasks quando la crei o in un secondo momento. La configurazione viene applicata a tutte le attività nella coda.

Esistono tre aspetti di base per configurare le code:

Configurare il routing a livello di coda

La configurazione del routing a livello di coda sostituisce il routing impostato a livello di attività. Questa opzione è utile se vuoi utilizzare Cloud Tasks come buffer davanti al servizio di destinazione o se devi modificare il routing per tutte le attività di una coda.

Il routing a livello di coda si applica a:

  • Attività in coda
  • Attività aggiunte alla coda dopo l'impostazione del routing a livello di coda

Limitazioni

Il routing a livello di coda non è compatibile con le chiavi di crittografia gestite dal cliente (CMEK) di Cloud Key Management Service (Cloud KMS). Se CMEK è attivo, non puoi svolgere le seguenti operazioni:

  • Creare attività in una coda con routing a livello di coda
  • Applicare il routing a livello di coda

Configura il routing a livello di coda per le attività HTTP

Puoi configurare una coda per eseguire l'override del routing a livello di attività durante la creazione o l'aggiornamento della coda. Per configurare il routing a livello di coda, imposta il parametro uriOverride della coda sul percorso che preferisci.

Se stai applicando il routing a livello di coda come aggiornamento a una coda esistente, metti in pausa la coda prima di applicare le modifiche e attendi un minuto dopo averle applicate per riprendere la coda.

  1. Metti in pausa la coda eseguendo il seguente comando:

      gcloud tasks queues pause QUEUE_ID

    Sostituisci QUEUE_ID con l'ID della coda.

  2. Aggiorna o rimuovi il routing a livello di coda.

    • Per aggiornare il routing a livello di coda, imposta il parametro uriOverride sul percorso aggiornato.

    • Per rimuovere il routing a livello di coda utilizzando l'API REST o RPC:

      • API REST: invia una richiesta patch per la coda con un payload vuoto e il parametro updateMask impostato su httpTarget.

      • API RPC: invia un messaggio updateQueueRequest per la coda con un payload vuoto e il parametro update_mask impostato su http_target.

    L'esempio seguente utilizza l'API REST per aggiornare l'host a cui vengono indirizzate le attività:

    curl -X PATCH -d @- -i \
  -H "Authorization: Bearer ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  "https://cloudtasks.googleapis.com/v2/projects/PROJECT_ID/locations/LOCATION/queues/QUEUE_ID?updateMask=httpTarget.uriOverride" << EOF
{
  "httpTarget": {"uriOverride":{"host":"NEW_HOST"}}
}
EOF

    Sostituisci quanto segue:

    • ACCESS_TOKEN: il tuo token di accesso. Puoi ottenere questo valore eseguendo il seguente comando nel terminale:

      gcloud auth application-default login
gcloud auth application-default print-access-token

    • PROJECT_ID: l'ID del tuo Google Cloud progetto. Puoi ottenere questo valore eseguendo il seguente comando nel terminale: 

      gcloud config get-value project

    • LOCATION: la posizione della coda.

    • NEW_HOST: il nuovo host a cui vuoi inoltrare la coda.

  3. Attendi un minuto.

    L'applicazione della nuova configurazione può richiedere fino a un minuto. L'attesa per riprendere la coda consente di evitare l'invio delle attività con la vecchia configurazione.

  4. Riprendi la coda eseguendo il seguente comando:

    gcloud tasks queues resume QUEUE_ID

Configurare il routing a livello di coda per le attività App Engine

Per configurare il routing a livello di coda per le attività di App Engine, imposta il parametro appEngineRoutingOverride della coda sul servizio e sulla versione di App Engine che preferisci.

  1. Configura il routing a livello di coda e sostituisci qualsiasi routing a livello di attività:

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

    Sostituisci quanto segue:

    • QUEUE_ID: l'ID coda (il nome breve).
    • SERVICE: il servizio di worker App Engine responsabile della gestione delle attività.
    • VERSION: la versione dell'app.

    Ad esempio, se configuri un servizio di lavoro per gestire tutte le attività in una coda, puoi instradare le richieste a quel servizio e alla versione predefinita:

    gcloud tasks queues update QUEUE_ID \
    --routing-override=service:SERVICE

  2. Verifica che la coda sia stata configurata correttamente eseguendo il seguente comando:

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    Sostituisci LOCATION con la posizione della coda.

    L'output dovrebbe essere simile al seguente:

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

  3. Per rimuovere il routing a livello di coda, esegui il seguente comando:

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

    Quando il routing a livello di coda viene rimosso, il routing a livello di attività viene applicato alle attività nella coda e alle attività aggiunte alla coda in futuro.

Definire i limiti di frequenza

Il limite di frequenza determina la frequenza massima con cui le attività possono essere inviate da una coda, indipendentemente dal fatto che l'invio sia un primo tentativo o un nuovo tentativo.

  1. Imposta la frequenza massima e il numero di attività in parallelo che possono essere inviate da una coda eseguendo il seguente comando:

    gcloud tasks queues update QUEUE_ID \
    --max-dispatches-per-second=DISPATCH_RATE \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

    Sostituisci quanto segue:

    • QUEUE_ID: l'ID coda (il nome breve).
    • DISPATCH_RATE: la frequenza di invio. Si tratta della frequenza con cui i token nel bucket vengono aggiornati. In condizioni in cui è presente un flusso relativamente costante di attività, questo valore è equivalente alla frequenza con cui le attività vengono inviate.
    • MAX_CONCURRENT_DISPATCHES: il numero massimo di attività nella coda che possono essere eseguite contemporaneamente.

    Ad esempio, se hai creato una coda senza impostare parametri, puoi aggiornare il numero massimo di attività simultanee eseguendo il seguente comando:

    gcloud tasks queues update QUEUE_ID \
    --max-concurrent-dispatches=MAX_CONCURRENT_DISPATCHES

  2. Verifica che la coda sia stata configurata correttamente eseguendo il seguente comando:

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    Sostituisci LOCATION con la posizione della coda.

    L'output dovrebbe essere simile al seguente:

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

Metodi per definire le frequenze di elaborazione delle code

Puoi definire le frequenze di elaborazione della coda utilizzando l'API Cloud Tasks o caricando un file queue.yaml. Entrambi i metodi generano code che utilizzano lo stesso meccanismo di base.

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

Ogni volta che l'applicazione esegue un'attività, un token viene rimosso dal bucket. La coda continua a elaborare le attività finché il bucket non esaurisce i token. Il sistema rifornisce continuamente il bucket con nuovi token in base alla frequenza max_dispatches_per_second specificata per la coda. Se la coda contiene attività da elaborare e il relativo bucket contiene token, il sistema elabora contemporaneamente tutte le attività presenti, fino al valore max_concurrent_dispatches impostato.

Un carico non uniforme può consentire un aumento significativo del numero di token nel bucket, il che può portare a picchi di elaborazione quando si verifica un picco di richieste. In questo caso, la coda potrebbe avere una frequenza di invio effettiva che supera la frequenza max_dispatches_per_second, consumando risorse di sistema e competendo con le richieste di pubblicazione per gli utenti. Se utilizzi le code per gestire le frequenze di invio in base a SLA relativamente lenti per i servizi a valle, questo può comportare errori come HTTP 429 (troppe richieste) o HTTP 503 (servizio non disponibile).

  • Quando utilizzi qualsiasi metodo dell'API Cloud Tasks, hai due campi per definire la frequenza di invio della coda:

    • max_dispatches_per_second
    • max_concurrent_dispatches

    Un terzo campo, max_burst_size, viene calcolato dal sistema in base al valore impostato per max_dispatches_per_second.

  • Quando 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 dell'API Cloud Tasks e il lasciare che sia il sistema a impostare max_burst_size producono una frequenza molto efficiente per la gestione delle ondate di richieste. In alcuni casi, tuttavia, in particolare quando la frequenza richiesta è relativamente lenta, puoi avere un maggiore controllo utilizzando il metodo queue.yaml per impostare manualmente bucket_size su un valore ridotto o impostando max_concurrent_dispatches su un valore ridotto utilizzando l'API Cloud Tasks.

Imposta i parametri di ripetizione

Se un'attività non viene completata correttamente, Cloud Tasks la riproverà con un backoff esponenziale in base ai parametri impostati.

  1. Specifica il numero massimo di volte per riprovare le attività non riuscite nella coda, imposta un limite di tempo per i tentativi di nuovo tentativo e controlla l'intervallo tra i tentativi eseguendo il seguente comando:

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

    Sostituisci quanto segue:

    • QUEUE_ID: l'ID coda (il nome breve).
    • MAX_ATTEMPTS: il numero massimo di tentativi per un compito, incluso il primo. Puoi consentire un numero illimitato di tentativi impostando questo flag su -1. Tieni presente che se MAX_ATTEMPTS è impostato su -1, MAX_RETRY_DURATION viene comunque applicato.
    • MAX_RETRY_DURATION: il tempo massimo per eseguire nuovamente un'attività non riuscita, misurato dal primo tentativo eseguito per l'attività. Il valore deve essere una stringa che termina con "s", ad esempio 5s. Se impostato su 0, l'età delle attività è illimitata. Tieni presente che se MAX_RETRY_DURATION è impostato su 0, viene comunque applicato MAX_ATTEMPTS.
    • MIN_INTERVAL: il tempo minimo da attendere tra un tentativo di nuovo tentativo e l'altro. Il valore deve essere una stringa che termina con "s", ad esempio 5s.
    • MAX_INTERVAL: il tempo massimo da attendere tra un nuovo tentativo e l'altro. Il valore deve essere una stringa che termina con "s", ad esempio 5s.

    • MAX_DOUBLINGS: il numero massimo di volte in cui l'intervallo tra i tentativi di attività non riusciti verrà raddoppiato prima che l'aumento diventi costante. L'intervallo tra i tentativi di un'attività inizia a MIN_INTERVAL, poi raddoppia MAX_DOUBLINGS volte, poi aumenta in modo lineare e infine i tentativi vengono eseguiti a intervalli di MAX_INTERVAL fino a MAX_ATTEMPTS volte.

      Ad esempio, se MIN_INTERVAL è 10s, MAX_INTERVAL è 300s e MAX_DOUBLINGS è 3, l'intervallo di ripetizione verrà raddoppiato 3 volte, aumenterà in modo lineare di 2^3 * 10 secondi e poi verrà eseguito nuovamente a intervalli di MAX_INTERVAL finché l'attività non è stata tentata MAX_ATTEMPTS volte: 10 secondi, 20 secondi, 40 secondi, 80 secondi, 160 secondi, 240 secondi, 300 secondi, 300 secondi e così via.

    Per ulteriori dettagli sul parametro, consulta le impostazioni RetryConfig per la risorsa Queue.

  2. Verifica che la coda sia stata configurata correttamente eseguendo il seguente comando:

    gcloud tasks queues describe QUEUE_ID --location=LOCATION

    Sostituisci LOCATION con la posizione della coda.

    L'output dovrebbe contenere i parametri di ripetizione impostati.

Passaggi successivi