Cloud Tasks ti consente di creare sistemi asincroni resilienti quando progetti comportamenti di esecuzione di code e limiti di servizio specifici. Puoi evitare colli di bottiglia di elaborazione e ritardi imprevisti tenendo conto della consegna "at least once", della limitazione del sistema e della capacità delle risorse di destinazione.
Ordine di esecuzione
Ad eccezione delle attività pianificate per l'esecuzione in futuro, le code di attività sono completamente indipendenti dalla piattaforma per quanto riguarda l'ordine di esecuzione. Non esistono garanzie o tentativi di eseguire le attività in un ordine particolare. In particolare, non è garantito che le attività precedenti vengano eseguite a meno che una coda non sia completamente vuota. Esistono diversi casi comuni in cui le attività più recenti vengono eseguite prima di quelle precedenti e i pattern che le riguardano possono cambiare senza preavviso.
Ritardo di esecuzione
Le esecuzioni di Cloud Tasks potrebbero occasionalmente subire ritardi minori, in genere di pochi minuti, a causa dei riavvii interni del sistema. Le attività vengono ritardate, ma non vengono perse. Si tratta di eventi a livello di sistema senza soluzioni alternative. Questi eventi non vengono registrati e la loro occorrenza non ha una sequenza temporale impostata.
Esecuzione duplicata
Cloud Tasks mira a una semantica "execute exactly once" rigorosa. Tuttavia, nelle situazioni in cui è necessario trovare un compromesso tra l'esecuzione garantita e l'esecuzione duplicata, il servizio preferisce l'esecuzione garantita. Di conseguenza, si verifica un numero diverso da zero di esecuzioni duplicate. Devi assicurarti che le esecuzioni duplicate vengano gestite correttamente e non causino errori imprevisti. In produzione, più del 99,999% delle attività viene eseguito una sola volta.
Limitazioni delle risorse
La fonte più comune di backlog nelle code di elaborazione immediata è l'esaurimento delle risorse nelle istanze di destinazione. Se tenti di eseguire 100 attività al secondo su istanze frontend che possono elaborare solo 10 richieste al secondo, si creerà un backlog. In genere, questo si manifesta in uno dei due modi seguenti, entrambi risolvibili aumentando il numero di istanze che elaborano le richieste.
Errori di backoff e tariffe applicate
I server sovraccarichi possono iniziare a restituire errori di backoff: HTTP 503 (per le destinazioni App Engine) o HTTP 429 o 5xx (per le destinazioni esterne).
Cloud Tasks reagisce a questi errori rallentando l'esecuzione fino a quando gli errori non si interrompono. Questa limitazione del sistema impedisce al worker di sovraccaricarsi. Tieni presente che le impostazioni non vengono modificate.
La limitazione del sistema si verifica nelle seguenti circostanze:
Cloud Tasks esegue il backoff su tutti gli errori. Normalmente viene utilizzato il backoff specificato in
rate_limits. Tuttavia, se il worker restituisce HTTP429 Too Many Requests,503 Service Unavailableo la frequenza degli errori è elevata, Cloud Tasks utilizza una frequenza di backoff più elevata. Viene considerato il tentativo specificato nell'intestazione della risposta HTTPRetry-After.Per evitare picchi di traffico e attenuare gli aumenti improvvisi del traffico, gli invii aumentano lentamente quando la coda viene creata di recente o è inattiva e se un numero elevato di attività diventa improvvisamente disponibile per l'invio (a causa di picchi nelle frequenze di creazione delle attività, della ripresa della coda o di molte attività pianificate contemporaneamente).
Picchi di latenza e numero massimo di invii simultanei
I server sovraccarichi possono anche rispondere con un aumento significativo della latenza.
In questa situazione, le richieste rimangono aperte più a lungo. Poiché le code vengono eseguite con un numero massimo di attività simultanee, le code potrebbero non essere in grado di eseguire le attività alla frequenza prevista. L'aumento di
max_concurrent_dispatches
per le code interessate può essere utile nelle situazioni in cui il valore è stato impostato su un valore troppo
basso, introducendo un limite di frequenza artificiale. Tuttavia, è improbabile che l'aumento di max_concurrent_dispatches riduca la pressione sulle risorse sottostanti.
Problemi di aumento graduale con le attività a lunga esecuzione
Le code di Cloud Tasks aumentano gradualmente l'output in parte in base al numero di attività inviate in precedenza con esito positivo. Se il gestore di attività impiega un periodo di tempo considerevole, nell'ordine di minuti, per completare un'attività e restituire una risposta di successo, potrebbe verificarsi un ritardo nella frequenza di aumento graduale della coda.
Visualizzare più di 5000 attività
Se hai più di 5000 attività, alcune non sono visibili nella Google Cloud console. Utilizza gcloud CLI per visualizzare tutte le attività.
Metrica della profondità massima della coda segnalata
La metrica della profondità massima della coda segnalata da Cloud Tasks è limitata a 1.000.000 di attività. Lo scopo è migliorare il rendimento dei worker delle attività sottostanti e non influisce sul numero di attività che possono essere inviate o elaborate dalla coda. Le attività inviate alla coda oltre il limite di profondità della coda continueranno a essere eseguite come previsto.
Per recuperare la profondità attuale della coda oltre 1.000.000 di attività, puoi utilizzare il
queues.tasks.list metodo.
Questo metodo restituisce tutte le attività con paginazione, consentendoti di aggregare i dati ed eseguire un'operazione di conteggio. Tuttavia, a seconda delle dimensioni della profondità della coda, il
metodo potrebbe riscontrare limitazioni di quota.
Ricreare una coda con lo stesso nome
Se elimini una coda dalla Google Cloud console, devi attendere 3 giorni prima di ricrearla con lo stesso nome. Questo periodo di attesa impedisce comportamenti imprevisti nelle attività in esecuzione al momento dell'eliminazione o in attesa di essere eseguite. Inoltre, evita errori di processo interni nel ciclo di eliminazione o ricreazione.
Destinazione non supportata quando si utilizza un perimetro sicuro
Se hai configurato un perimetro sicuro utilizzando i Controlli di servizio VPC, le richieste HTTP provenienti da un'esecuzione di Cloud Tasks vengono bloccate per le destinazioni non supportate e non andranno a buon fine con un codice di errore TARGET_TYPE_NOT_PERMITTED_FOR_VPC. Per saperne di più, consulta
Configurare un perimetro di servizio utilizzando i Controlli di servizio VPC.
Vincoli sulle località delle risorse
Cloud Tasks supporta la limitazione delle località delle risorse; tuttavia, si applicano limitazioni alle seguenti regioni:
us-central1us-central2(regione privata Google Cloud )
Se specifichi una delle due regioni nella policy dell'organizzazione, devi includere sia us-central1 sia us-central2, anche se non crei risorse Cloud Tasks in entrambe le regioni. Puoi includere la regione us-central2 nella policy dell'organizzazione anche se la tua organizzazione non utilizza regioni private.