Informazioni su Cloud Tasks

Questa pagina descrive che cosa sono le attività e le code di Cloud Tasks, nonché quando e come utilizzarle. Cloud Tasks ti consente di separare di lavoro che può essere eseguito in modo indipendente, al di fuori del flusso principale dell'applicazione, e li invii per essere elaborati in modo asincrono utilizzando i gestori da te creati. Questi elementi di lavoro indipendenti sono chiamati task. Ad esempio, devi aggiornare un database nell'ambito dell'elaborazione di una richiesta dell'utente, ma gli aggiornamenti possono essere laboriosi. Il trasferimento di questo dettaglio come attività ti consente di tornare dalla richiesta più rapidamente.

Punto chiave: il servizio Cloud Tasks è progettato per il lavoro asincrono. Non fornisce garanzie solide in merito ai tempi di esecuzione delle attività ed è quindi inadatto per le applicazioni interattive in cui un utente è in attesa del risultato.

L'attività scaricata viene aggiunta a una coda, che mantiene l'attività fino a quando non viene eseguiti correttamente. In base alla configurazione iniziale, la coda può anche fungere da controllo del flusso di invio. Creerai e configurerai la coda, che verrà poi gestita dal servizio Cloud Tasks. Una volta aggiunte le attività, li invia e si assicura che vengano elaborati in modo affidabile dai worker. Le complessità associate a questo processo, come i costi di latenza per gli utenti, i crash del server, le limitazioni del consumo di risorse e la gestione dei tentativi di nuovo invio, vengono gestite dal servizio.

Cloud Tasks è progettato per fornire la consegna "almeno una volta", ovvero se un'attività viene aggiunta correttamente, la coda la invierà almeno una volta. In alcune rare circostanze è possibile eseguire più attività, quindi deve garantire che non ci siano effetti collaterali dannosi di un'esecuzione ripetuta. I gestori devono essere idempotenti.

Le attività stesse sono costituite da un nome univoco e da informazioni di configurazione e, facoltativamente, da eventuali dati della richiesta iniziale, chiamati payload, necessari per elaborare la richiesta. Poiché il payload viene inviato nel corpo della richiesta, le attività che includono i payload devono utilizzare POST o PUT come metodo HTTP.

Per accedere al servizio Cloud Tasks utilizzando l'API Cloud Tasks , è necessario Avere un progetto Google Cloud.

Casi d'uso

I casi d'uso tipici includono:

• Ridurre i tempi di risposta degli utenti delegando uno sfondo potenzialmente lento operazioni come gli aggiornamenti del database su un worker
• Preservare le richieste nel contesto di incidenti di produzione imprevisti
• Contribuire ad attenuare i picchi di traffico rimuovendo le attività non rivolte agli utenti dal flusso principale degli utenti
• Gestione delle frequenze di chiamata delle API di terze parti

Code di Cloud Tasks con target HTTP

Nel caso di target HTTP generici, il servizio Cloud Tasks inoltra la richiesta dell'attività al worker, che si trova in qualsiasi endpoint HTTP generico, in base alla configurazione dell'attività. Questo endpoint potrebbe trovarsi Funzioni di Cloud Run, Cloud Run, GKE Compute Engine o anche un server web on-prem, basato su configurazione dell'attività. Queste code inviano le richieste a una frequenza affidabile e configurabile. Garantiscono un'esecuzione affidabile delle attività: al termine, tutti i worker devono inviare un codice di risposta HTTP (200-299) al servizio Cloud Tasks prima della scadenza del timeout predefinito di 10 minuti, con un massimo di 30 minuti. Se viene inviata una risposta diversa o se non viene inviata alcuna risposta, l'attività viene ritentata.

Il target deve gestire la scalabilità dei lavoratori e la pulizia delle attività una volta completate.

Se la destinazione richiede l'autenticazione, devi configurare due account di servizio, una per l'applicazione, il client e una per la coda stessa. A entrambi gli account deve essere stato concesso le autorizzazioni richieste e nella richiesta dell'attività deve essere incluso un identificatore per l'account di servizio client. Consulta Crea attività target HTTP per ulteriori informazioni informazioni.

Code di Cloud Tasks con target App Engine

Cloud Tasks è compatibile con i seguenti ambienti App Engine:

• Runtime di seconda generazione dell'ambiente standard di App Engine
• Ambiente flessibile di App Engine

Gli utenti dei runtime di prima generazione di App Engine che attualmente utilizzano l'API Task Queue possono eseguire la migrazione a Cloud Tasks. Per scoprire come, consulta Eseguire la migrazione dai servizi in bundle legacy. Gli utenti dei runtime di prima generazione di App Engine che non utilizzano il servizio di task in bundle possono eseguire l'upgrade ai runtime di seconda generazione per utilizzare Cloud Tasks.

Nel caso delle destinazioni App Engine, il servizio Cloud Tasks inoltra anche la richiesta di attività al gestore, ma questo worker si trova all'interno in App Engine. Pertanto, tutte le code che hanno come target gli elaboratori di App Engine devono avere un'app App Engine. Gli elaboratori devono essere eseguiti nella regione in cui viene eseguita l'app App Engine. Questa regione funge anche da Parametro LOCATION_ID per le richieste di Cloud Tasks.

Le attività vengono indirizzate in base al modo in cui sono state eseguite (o, meno frequentemente, alla coda stessa) è configurata. Le code inviano le richieste a una velocità configurabile affidabile. Garantiscono un'esecuzione affidabile delle attività: al termine dell'operazione, tutti i worker devono inviare un codice di risposta HTTP (200-299) al servizio Cloud Tasks, in questo caso prima di una scadenza in base al tipo di scalabilità delle istanze del servizio: 10 minuti per la scalabilità automatica o fino a 24 ore per la scalabilità manuale. Se viene inviata una risposta diversa o nessuna risposta, l'attività viene ripetuta.

Poiché i gestori fanno parte di App Engine, l'API Cloud Tasks il servizio stesso può svolgere gran parte della gestione dei processi per l'attività, di lavoro in relazione al traffico e all'eliminazione delle attività quando completata.

Nota: due posizioni App Engine, chiamate europe-west e us-central nei comandi App Engine, si chiamano rispettivamente europe-west1 e us-central1 nei comandi Cloud Tasks.

Regioni supportate per target

Se il tuo target è un endpoint HTTP/S, Cloud Tasks è disponibile in tutte le regioni Google Cloud supportate per Cloud Tasks.

Se il target è un'applicazione App Engine all'interno del progetto corrente:

• Un'attività che ha come target App Engine può essere creata solo nella regione App Engine del progetto.

• Un progetto Google Cloud può contenere una sola app App Engine e la regione in cui si trova l'app App Engine non può essere modificata una volta creata l'app.

• App Engine è regionale, il che significa che l'infrastruttura che esegue la tua app si trova in una regione specifica. Se vuoi distribuire le risorse di computing in più regioni, devi scegliere come target un endpoint HTTP/S.

• Se non utilizzi App Engine come target, non devi eseguire il deployment di un'app App Engine e puoi disattivare qualsiasi app App Engine esistente.

Workflows

Il flusso di lavoro generale è il seguente:

1. Crei un worker per elaborare le attività.
2. Crei una coda.
3. Le attività vengono create tramite programmazione e aggiunte alla coda.
4. Il servizio Cloud Tasks restituisce un OK all'oggetto un'applicazione. Ciò indica che l'attività è stata scritta correttamente allo spazio di archiviazione di Cloud Tasks, in modo che la richiesta di creazione dell'attività ad alta disponibilità e durabilità.
5. Le attività vengono passate al worker.
6. Il worker elabora l'attività.
7. Per completare la sequenza, il worker restituisce un codice di stato di operazione riuscita 2xx al servizio Cloud Tasks.

Una volta che l'attività è stata trasferita alla coda, nessun dato viene reso disponibile per la richiesta iniziale.

Nota: l'API Cloud Tasks fornisce un'interfaccia indipendente da App Engine per il servizio Task Queue di App Engine. Le code accessibili utilizzando l'SDK App Engine sono accessibili anche dall'API Cloud Tasks e viceversa.

Funzionalità

Con Cloud Tasks puoi inviare elementi di lavoro asincroni con i seguenti controlli:

• Pianificare orari di consegna specifici
• Gestire le percentuali di pubblicazione
• Configura il comportamento per i nuovi tentativi
• Accedere alle singole attività e gestirle in una coda
• Attiva deduplicazione attività

Termini

La tabella seguente mostra i termini chiave che descrivono aspetti del comportamento di Cloud Tasks.

Termine	Definizione
coda	Un insieme di attività con lo stesso tipo di destinazione gestite da una singola configurazione.
tipo di target	Dove e come viene elaborata un'attività.
worker	Un servizio che elabora le attività.
tentativo	Un tentativo di eseguire un'attività.
tenta di inviare	Il momento in cui Cloud Tasks ha inviato l'attività al suo target.
risposta al tentativo	La risposta di un worker che indica che il lavoro associato al attività completata correttamente o non riuscita.
riprova	Più tentativi di esecuzione di un'attività. Il numero di nuovi tentativi viene impostato tramite RetryConfig.
limiti di frequenza	I limiti di frequenza per una coda.

Metriche

Le seguenti metriche predefinite di Google Tasks sono disponibili utilizzando Cloud Monitoring.

Tipo di metrica Nome visualizzato Tipo, Tipo, Unità	Etichette di descrizione
api/request_count richieste API DELTA, INT64, 1	Numero di chiamate all'API Cloud Tasks. api_method: Il metodo API chiamato (ad es. CreateTask). response_code: Codice di risposta canonico come stringa (ad es. "ok").
queue/depth e Profondità coda BETA GAUGE, INT64, 1	Il numero di attività in coda. Campionamento eseguito ogni 60 secondi. Dopo il campionamento, i dati non sono visibili per un massimo di 120 secondi.
queue/task_attempt_count e Numero di tentativi attività: DELTA, INT64, 1	Il conteggio del numero di attività che la coda ha tentato di inviare. suddivisi per codice di risposta dell'attività. response_code: Codice di risposta canonico come stringa (ad es. "ok").
queue/task_attempt_delays Ritardi dei tentativi di esecuzione dell'attività DELTA, DISTRIBUTION, ms	Ritardo tra ogni ora di tentativo pianificata e l'ora di tentativo effettiva.