Risolvere i problemi di scalabilità automatica di Dataflow

Questa pagina mostra come risolvere i problemi relativi alle funzionalità di scalabilità automatica di Dataflow e fornisce informazioni su come gestire la scalabilità automatica.

Il job non esegue lo scale up o lo scale down

Questa sezione fornisce informazioni su scenari che potrebbero impedire ai lavoratori di eseguire il ridimensionamento.

Il job di streaming non esegue lo scale up

Quando la pipeline di streaming presenta un backlog, i worker non vengono scalati.

Questo problema si verifica quando la coda dura meno di qualche minuto o quando i worker utilizzano meno del 20% delle CPU.

A volte, la coda è elevata, ma l'utilizzo della CPU è basso. Poiché alcune attività non richiedono un elevato utilizzo della CPU, l'aggiunta di worker non migliora le prestazioni. In questi casi, Dataflow non esegue l'aumento di scala. Per ulteriori informazioni, consulta la sezione Scalabilità automatica di streaming. Questo scenario potrebbe verificarsi per i seguenti motivi:

• La pipeline è ad I/O elevato.
• La pipeline è in attesa di chiamate RPC esterne.
• I tasti di scelta rapida causano un utilizzo non uniforme della CPU dei worker.
• La pipeline non ha chiavi sufficienti.

I job batch e in streaming non vengono scalati

Il job batch o in streaming viene eseguito come previsto, ma quando sono necessari più worker, il job non viene scalato.

Questo problema potrebbe verificarsi per uno dei seguenti motivi:

• I file di staging o temporanei non sono accessibili. Se il job utilizza un bucket Cloud Storage, il bucket potrebbe avere una configurazione del ciclo di vita che elimina gli oggetti al suo interno. Gli oggetti eliminati includono file e cartelle temporanee e di staging. Per verificare se i file sono stati eliminati, controlla la configurazione del ciclo di vita del bucket. Se i file o le cartelle di staging o temporanee sono stati eliminati dopo l'avvio del job, i pacchetti necessari per creare nuovi worker potrebbero non esistere. Per risolvere il problema, ricrea le cartelle e i file nel bucket.
• Le regole del firewall impediscono ai lavoratori di inviare e ricevere traffico sulle porte TCP necessarie. Le regole del firewall potrebbero impedire l'avvio dei worker. I worker Dataflow devono essere in grado di inviare e ricevere traffico sulle porte TCP 12345 e 12346. Per ulteriori informazioni, inclusi i passaggi per risolvere il problema, consulta Regole firewall per Dataflow.
• Un'origine personalizzata ha un metodo getProgress() che restituisce un valore NULL. Quando utilizzi un'origine personalizzata, le metriche relative al backlog si basano sul valore restituito del metodo getProgress() dell'origine personalizzata per iniziare a raccogliere i dati. L'implementazione predefinita per getProgress() restituisce un valore NULL. Per risolvere il problema, assicurati che l'origine personalizzata sostituisca il metodo getProgress() predefinito per restituire un valore non NULL.
• Un aggiornamento attivato dalla scalabilità automatica verticale disattiva temporaneamente la scalabilità automatica orizzontale. Per ulteriori informazioni, consulta Effetto sulla scalabilità automatica orizzontale.
• Se utilizzi un'operazione map in una pipeline Python e il tuo job non viene scalato, potresti dover aggiungere una trasformazione Reshuffle al codice della pipeline. Per ulteriori informazioni, consulta Riordina nella documentazione di Apache Beam.

Il job di streaming non esegue fare lo scale down

Quando il job di streaming ha un backlog ridotto e un utilizzo ridotto della CPU, i worker non vengono fare lo scale down. Il problema può verificarsi per vari motivi.

• Quando i job non utilizzano Streaming Engine, Dataflow bilancia il numero di dischi permanenti tra i worker. Di conseguenza, ogni worker deve avere un numero uguale di dischi permanenti. Ad esempio, se ci sono 100 dischi e 100 worker, ogni worker ha un disco. Quando il job viene ridotto, può avere 50 worker con due dischi permanenti per worker. Il job non riduce nuovamente le fare lo scale down finché non può avere 25 worker con quattro dischi permanenti per worker. Inoltre, il numero minimo di worker è il valore assegnato a maxNumWorkers diviso per 15. Per ulteriori informazioni, consulta Intervallo di scalabilità per le pipeline di scalabilità automatica in streaming.

• Quando i job utilizzano Streaming Engine, il target di riduzione della scala si basa su un utilizzo della CPU target del 75%. Se non è possibile raggiungere questo utilizzo della CPU, il ridimensionamento verso il basso viene disattivato.

• La stima del tempo di coda deve rimanere inferiore a dieci secondi per almeno due minuti prima dello fare lo scale down dei worker. Le fluttuazioni nel tempo del backlog potrebbero disattivare lo scale down. Inoltre, un throughput ridotto può falsare la stima del tempo.

• PeriodicImpulse è supportato nelle versioni 2.60.0 e successive dell'SDK Apache Beam. Quando la pipeline utilizza PeriodicImpulse con le versioni dell'SDK Apache Beam 2.59.0 e precedenti, i worker Dataflow non fare lo scale down le dimensioni come previsto.

Aumentare il numero di fermate

Il job batch o flusso inizia a eseguire lo scale up, ma i worker interrompono lo scale up anche se rimane un backlog.

Questo problema si verifica quando vengono raggiunti i limiti di quota.

• Quote di Compute Engine: i job Dataflow sono soggetti alla quota di Compute Engine del progetto. Se sono in esecuzione più job, il progetto potrebbe essere al limite della quota Compute Engine. In questo caso, Dataflow non può aumentare il numero di worker.
• Quote CPU: i job Dataflow sono soggetti anche alla quota CPU del progetto. Se il tipo di worker utilizza più di una CPU, il progetto potrebbe essere al limite della quota CPU.
• Quote di indirizzi IP esterni: quando il job utilizza indirizzi IP esterni per comunicare con le risorse, hai bisogno di tanti indirizzi IP esterni quanti sono i worker. Quando il numero di worker aumenta, aumenta anche il numero di indirizzi IP esterni. Quando raggiungi il limite di indirizzi IP, i worker smettono di aumentare.

Inoltre, se la risorsa desiderata non è disponibile nella regione scelta, non puoi creare nuove risorse di quel tipo, anche se hai ancora a disposizione parte della quota nella regione o nel progetto. Ad esempio, potresti disporre di una quota sufficiente per creare indirizzi IP esterni in us-central1, ma in questa regione potrebbe non essere possibile trovare indirizzi IP disponibili. Per ulteriori informazioni, consulta Quote e disponibilità delle risorse.

Per risolvere il problema, richiedi un aumento della quota o esegui il job in un'altra regione.

Il suggerimento di utilizzo dei lavoratori non ha alcun effetto

Imposti il suggerimento per l'utilizzo dei worker ma il comportamento della scalabilità automatica non cambia.

Per comprendere questo problema, vai al grafico Utilizzo della CPU dei worker e controlla se il suggerimento per l'utilizzo dei worker è utilizzato attivamente. Se il suggerimento viene utilizzato, il grafico mostra CPU utilization hint (actively used by autoscaler). In caso contrario, viene visualizzato CPU utilization hint (not actively used by autoscaler).

Il suggerimento per l'utilizzo è solo uno dei fattori che influiscono sulla scalabilità automatica. La tabella seguente elenca alcuni motivi per cui il gestore della scalabilità automatica potrebbe non utilizzare attivamente il suggerimento:

Comportamento di scalabilità osservato	Cause	Metriche da controllare
Nessuna modifica	Hai raggiunto il numero minimo o massimo di worker. Il numero di worker è limitato dal numero di chiavi elaborate in parallelo. I job vengono limitati da RPC esterne. L'aggiustamento di riduzione è troppo piccolo o Dataflow sta attenuando la riduzione. Per ulteriori informazioni, consulta Heuristiche di scalabilità automatica di streaming.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys Errori RPC segnalati nei log degli errori del worker Arresti anomali segnalati nei log del worker
Scale up	L'obiettivo di backlog o latenza elevato ha sostituito il suggerimento. Il numero minimo di worker è stato aggiornato a un valore superiore al numero di worker corrente.	job/aggregated_worker_utilization job/backlog_bytes job/backlog_elements job/estimated_timer_backlog_processing_time job/min_worker_instances_limit
Scalabilità verso il basso	Il numero massimo di worker è stato aggiornato a un valore inferiore al numero di worker corrente.	job/aggregated_worker_utilization job/max_worker_instances_limit

Per ulteriori informazioni, consulta Euristiche di scalabilità automatica in streaming.

Lacune nelle metriche di scalabilità automatica

Esistono brevi lacune temporanee nelle metriche di scalabilità automatica.

Questo problema può verificarsi se le attività di backend vengono riavviate. Queste lacune nelle metriche non indicano un problema con la scalabilità automatica o con lo stato del job in streaming.

La CPU è distribuita in modo non uniforme

Quando il job è sottoposto a scalabilità automatica, l'utilizzo della CPU è distribuito in modo non uniforme tra i worker. Alcuni worker hanno un utilizzo della CPU, una latenza del sistema o una frequenza di aggiornamento dei dati più elevati rispetto ad altri.

Questo problema può verificarsi se i dati contengono una hot key. Una hot key è una chiave con elementi sufficienti per influire negativamente sul rendimento della pipeline. Ogni chiave deve essere elaborata da un singolo worker, pertanto il lavoro non può essere suddiviso tra i worker.

Per ulteriori informazioni, consulta le linee guida relative agli errori delle hot key.

Lo stato di lettura richiesto dell'elemento di lavoro non è più valido nel backend

Durante la comunicazione tra le istanze VM worker e le attività di Streaming Engine in una pipeline di streaming, si verifica il seguente errore:

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

Durante l'autoscaling, le istanze VM worker comunicano con più attività Streaming Engine e ogni attività serve più istanze VM worker. Le chiavi elemento vengono utilizzate per distribuire il lavoro. Ogni istanza VM di attività e worker ha una raccolta di intervalli di chiavi e la distribuzione di questi intervalli può cambiare dinamicamente. Ad esempio, durante la scalabilità automatica, il ridimensionamento dei job può causare la variazione della distribuzione dell'intervallo di chiavi. Questo errore può verificarsi quando un intervallo di chiavi cambia. L'errore è previsto e, a meno che non riscontri una correlazione tra questi messaggi e una pipeline con prestazioni inferiori al previsto, puoi ignorarlo.

Risorse Streaming Engine insufficienti

Se Streaming Engine non riesce ad allocare il numero minimo di worker richiesto, viene restituito il seguente errore:

Streaming Engine does not currently have enough resources available to fulfill
the request.

Per risolvere il problema, prova a impostare un numero minimo di worker inferiore. Consulta Impostare l'intervallo di scalabilità automatica.

Intervallo di scalabilità per le pipeline di scalabilità automatica in streaming

Questa sezione fornisce dettagli sull'intervallo di scalabilità per le pipeline di scalabilità automatica streaming.

Java

Per i job di scalabilità automatica in streaming che non utilizzano Streaming Engine, il servizio Dataflow alloca da 1 a 15 dischi permanenti a ogni worker. Questa allocazione significa che il numero minimo di worker utilizzati per una pipeline di scalabilità automatica in streaming è N/15, dove N è il valore di --maxNumWorkers.

Per i job di scalabilità automatica in streaming che utilizzano Streaming Engine, il numero minimo di worker è 1.

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la pipeline richiede tre o quattro worker in stato steady, puoi impostare --maxNumWorkers=15. La pipeline scala automaticamente tra 1 e 15 worker, utilizzando 1, 2, 3, 4, 5, 8 o 15 worker, che corrispondono rispettivamente a 15, 8, 5, 4, 3, 2 o 1 dischi rigidi permanenti per worker.

--maxNumWorkers può essere al massimo 1000.

Python

Per i job di scalabilità automatica in streaming che non utilizzano Streaming Engine, il servizio Dataflow alloca da 1 a 15 dischi permanenti a ogni worker. Questa allocazione significa che il numero minimo di worker utilizzati per una pipeline di scalabilità automatica in streaming è N/15, dove N è il valore di --max_num_workers.

Per i job di scalabilità automatica in streaming che utilizzano Streaming Engine, il numero minimo di worker è 1.

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la pipeline richiede tre o quattro worker in stato steady, puoi impostare --max_num_workers=15. La pipeline scala automaticamente tra 1 e 15 worker, utilizzando 1, 2, 3, 4, 5, 8 o 15 worker, che corrispondono rispettivamente a 15, 8, 5, 4, 3, 2 o 1 dischi rigidi permanenti per worker.

--max_num_workers può essere al massimo 1000.

Vai

Per i job di scalabilità automatica in streaming che non utilizzano Streaming Engine, il servizio Dataflow alloca da 1 a 15 dischi permanenti a ogni worker. Questa allocazione significa che il numero minimo di worker utilizzati per una pipeline di scalabilità automatica in streaming è N/15, dove N è il valore di --max_num_workers.

Per i job di scalabilità automatica in streaming che utilizzano Streaming Engine, il numero minimo di worker è 1.

Dataflow bilancia il numero di dischi permanenti tra i worker. Ad esempio, se la pipeline richiede tre o quattro worker in stato steady, puoi impostare --max_num_workers=15. La pipeline scala automaticamente tra 1 e 15 worker, utilizzando 1, 2, 3, 4, 5, 8 o 15 worker, che corrispondono rispettivamente a 15, 8, 5, 4, 3, 2 o 1 dischi rigidi permanenti per worker.

--max_num_workers può essere al massimo 1000.

Numero massimo di worker che la scalabilità automatica dello streaming potrebbe utilizzare

Java

Dataflow opera entro i limiti della quota di conteggi di istanze Compute Engine del progetto o di maxNumWorkers, a seconda del valore più basso.

Python

Dataflow opera entro i limiti della quota di conteggi di istanze Compute Engine del progetto o di max_num_workers, a seconda del valore più basso.

Vai

Dataflow opera entro i limiti della quota di conteggi di istanze Compute Engine del progetto o di max_num_workers, a seconda del valore più basso.

Limita la scalabilità automatica per ridurre l'impatto sulla fatturazione

Se non vuoi che la scalabilità automatica aumenti la tua fattura, puoi limitare il numero massimo di worker che il tuo job di streaming può utilizzare.

Java

Se specifichi --maxNumWorkers, limiti l'intervallo di scalabilità utilizzato per elaborare il tuo job.

Python

Se specifichi --max_num_workers, limiti l'intervallo di scalabilità utilizzato per elaborare il tuo job.

Vai

Se specifichi --max_num_workers, limiti l'intervallo di scalabilità utilizzato per elaborare il tuo job.

Modificare l'intervallo di scalabilità

Per informazioni su come modificare l'intervallo di scalabilità in una pipeline di streaming, consulta Impostare l'intervallo di scalabilità automatica.

Disattivare la scalabilità automatica nelle pipeline di streaming

Per disattivare l'autoscaling nella pipeline di streaming:

Java

Imposta --autoscalingAlgorithm=NONE. Per ulteriori informazioni, consulta Disattivare la scalabilità automatica orizzontale.

Python

Imposta --autoscaling_algorithm=NONE. Per ulteriori informazioni, consulta Disattivare la scalabilità automatica orizzontale.

Vai

Imposta --autoscaling_algorithm=NONE. Per ulteriori informazioni, consulta Disattivare la scalabilità automatica orizzontale.

Utilizza un numero fisso di worker

Per i job in streaming che non utilizzano Streaming Engine, il comportamento predefinito è utilizzare un numero fisso di worker. Per utilizzare la scalabilità automatica per lo streaming con queste pipeline, devi attivarla esplicitamente perché non è attiva per impostazione predefinita.