Configura le code di Cloud Tasks

Puoi configurare la coda Cloud Tasks quando la crei o in qualsiasi momento successivo. La configurazione viene applicata a tutte le attività in quella coda.

Esistono tre aspetti di base per la configurazione delle code:

Configurare il routing a livello di coda

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

Il routing a livello di coda si applica a:

  • Attività presenti nella coda
  • Attività aggiunte alla coda dopo aver impostato il 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 è abilitata, non puoi:

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

Configurare 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 calcolo itinerario a livello di coda, imposta il parametro uriOverride della coda sul tuo itinerario preferito.

Se applichi il routing a livello di coda come aggiornamento a una coda esistente, mettila in pausa 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 uriOverride parametro sulla route aggiornata.

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

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

      • API RPC: invia una 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 ottenerlo 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 ottenerlo eseguendo il seguente comando nel terminale: 

      gcloud config get-value project

    • LOCATION: la località della coda.

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

  3. Attendi un minuto.

    L'applicazione della nuova configurazione può richiedere fino a un minuto. L'attesa prima di riprendere la coda aiuta a impedire che le attività vengano inviate 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à App Engine, imposta il parametro della coda appEngineRoutingOverride sul servizio e sulla versione di App Engine che preferisci.

  1. Configura il routing a livello di coda ed esegui l'override di 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 della coda (il nome breve).
    • SERVICE: il servizio worker di App Engine responsabile della gestione delle attività.
    • VERSION: la versione dell'app.

    Ad esempio, se configuri un servizio worker per gestire tutte le attività in una coda, puoi indirizzare 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 località 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 di attività o un nuovo tentativo.

  1. Imposta la frequenza massima e il numero di attività simultanee 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 della coda (il nome breve).
    • DISPATCH_RATE: la frequenza di invio. Questa è la frequenza con cui i token nel bucket vengono aggiornati. In condizioni in cui il flusso di attività è relativamente costante, questa è l'equivalente della 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 alcun parametro, 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 località 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 delle code utilizzando l'API Cloud Tasks o caricando un file queue.yaml. Entrambi i metodi generano code che utilizzano lo stesso meccanismo sottostante.

In entrambi i casi, la coda utilizza l'algoritmo token bucket per controllare la frequenza di esecuzione delle attività. Ogni coda denominata ha un bucket che contiene i suoi 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 riempie 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 bucket della coda contiene token, il sistema elabora contemporaneamente il numero di attività corrispondente al numero di token, fino al valore max_concurrent_dispatches impostato.

Un carico irregolare può consentire al numero di token nel bucket di aumentare in modo significativo, il che può portare a picchi di elaborazione quando arriva un picco di richieste. In questo caso, la coda potrebbe riscontrare una frequenza di invio effettiva superiore alla frequenza 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 frequenze di invio in base a SLA relativamente lenti per i servizi downstream, ciò può causare errori come HTTP 429 (Troppe richieste) o HTTP 503 (Servizio non disponibile).

  • Quando utilizzi un 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. Per ulteriori informazioni, consulta i messaggi RateLimits.

  • Quando utilizzi il queue.yaml metodo, 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 l'impostazione di max_burst_size da parte del sistema producono una frequenza molto efficiente per la gestione dei picchi di richieste. In alcuni casi, tuttavia, in particolare quando la frequenza necessaria è relativamente lenta, l'utilizzo del metodo queue.yaml per impostare manualmente bucket_size su un valore piccolo o l'impostazione di max_concurrent_dispatches su un valore piccolo utilizzando l'API Cloud Tasks può darti un maggiore controllo.

Impostare i parametri per nuovi tentativi

Se un'attività non viene completata correttamente, Cloud Tasks riprova a eseguirla con un backoff esponenziale in base ai parametri impostati. Una volta eseguita correttamente, l'attività viene rimossa dalla coda. In tutti i casi, si applica anche il limite massimo di conservazione delle attività.

  1. Specifica il numero massimo di nuovi tentativi per le attività non riuscite nella coda, imposta un limite di tempo per i tentativi 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 della coda (il nome breve).
    • MAX_ATTEMPTS: il numero massimo di tentativi per un'attività, incluso il primo tentativo. Puoi consentire un numero illimitato di nuovi tentativi impostando questo flag su -1. Se MAX_ATTEMPTS è soddisfatto o impostato su -1, viene comunque applicato MAX_RETRY_DURATION.
    • MAX_RETRY_DURATION: la quantità massima di tempo per riprovare un'attività non riuscita misurata dal primo tentativo eseguito per l'attività. Il valore deve essere una stringa che termina con "s", ad esempio 5s. Puoi specificare una durata illimitata impostando questo flag su 0. Se MAX_RETRY_DURATION è soddisfatto o impostato su 0, viene comunque applicato MAX_ATTEMPTS.
    • MIN_INTERVAL: la quantità minima di tempo di attesa tra i tentativi. Il valore deve essere una stringa che termina con "s", ad esempio 5s.
    • MAX_INTERVAL: la quantità massima di tempo di attesa tra i tentativi. 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 nuovi 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, quindi raddoppia MAX_DOUBLINGS volte, per poi aumentare in modo lineare; infine, i tentativi vengono eseguiti a intervalli corrispondenti al valore di MAX_INTERVAL e fino al numero di tentativi massimo specificato in MAX_ATTEMPTS.

      Ad esempio, se MIN_INTERVAL è 10s, MAX_INTERVAL è 300s, e MAX_DOUBLINGS è 3, l'intervallo tra i tentativi verrà raddoppiato 3 volte, aumenterà linearmente di 2^3 * 10s e poi verrà riprovato a intervalli di MAX_INTERVAL fino a quando l'attività non sarà stata tentata MAX_ATTEMPTS volte: 10s, 20s, 40s, 80s, 160s, 240s, 300s, 300s e così via.

    Per ulteriori dettagli sui parametri, consulta le RetryConfig impostazioni per la Queue risorsa.

  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 località della coda.

    L'output dovrebbe contenere i parametri per nuovi tentativi che hai impostato.

Passaggi successivi