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.
Metti in pausa la coda eseguendo il seguente comando:
gcloud tasks queues pause QUEUE_ID
Sostituisci
QUEUE_ID
con l'ID della coda.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 parametroupdateMask
impostato suhttpTarget
.API RPC: invia un messaggio
updateQueueRequest
per la coda con un payload vuoto e il parametroupdate_mask
impostato suhttp_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.
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.
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.
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
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
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.
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
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 permax_dispatches_per_second
.Quando utilizzi il metodo
queue.yaml
, puoi impostare tutti e tre gli elementi:max_concurrent_requests
, che equivale amax_concurrent_dispatches
rate
, che equivale amax_dispatches_per_second
bucket_size
, che equivale amax_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.
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 seMAX_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 esempio5s
. Se impostato su0
, l'età delle attività è illimitata. Tieni presente che seMAX_RETRY_DURATION
è impostato su0
, viene comunque applicatoMAX_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 esempio5s
.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 esempio5s
.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 aMIN_INTERVAL
, poi raddoppiaMAX_DOUBLINGS
volte, poi aumenta in modo lineare e infine i tentativi vengono eseguiti a intervalli diMAX_INTERVAL
fino aMAX_ATTEMPTS
volte.Ad esempio, se
MIN_INTERVAL
è10s
,MAX_INTERVAL
è300s
eMAX_DOUBLINGS
è3
, l'intervallo di ripetizione verrà raddoppiato3
volte, aumenterà in modo lineare di 2^3 * 10 secondi e poi verrà eseguito nuovamente a intervalli diMAX_INTERVAL
finché l'attività non è stata tentataMAX_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 risorsaQueue
.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
- Scopri come creare attività target HTTP.
- Scopri come creare attività App Engine.
- Scopri di più sulla gestione delle code nel riferimento all'API RPC.
- Scopri di più sulla gestione delle code nel riferimento all'API REST.