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.

Lo scale up o lo scale down del job non viene eseguito

Questa sezione fornisce informazioni sugli scenari che potrebbero impedire ai worker di aumentare o diminuire le risorse.

Lo scale up del job di streaming non funziona

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

Questo problema si verifica quando il backlog dura meno di qualche minuto o quando il parallelismo è limitato.

A volte, il backlog è elevato, ma il parallelismo è basso. In questo caso, Dataflow non esegue lo scale up perché il lavoro non può essere distribuito tra più worker, quindi l'aggiunta di altri worker non aiuta l'elaborazione. Per saperne di più, consulta Scalabilità automatica dello streaming.

I job batch e di streaming non vengono scalati

Il job batch o di 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 temporanei o di gestione temporanea 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 nel bucket. 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 le cartelle o i file temporanei o di gestione temporanea 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 firewall impediscono ai worker di inviare e ricevere traffico sulle porte TCP necessarie. Le regole 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 saperne di più, 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 del 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 diverso da NULL.
• Un aggiornamento attivato dalla scalabilità automatica verticale disattiva temporaneamente la scalabilità automatica orizzontale. Per saperne di più, 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 saperne di più, consulta Reshuffle nella documentazione di Apache Beam.

Fare lo scale down del job di streaming non funziona

Quando il job di streaming ha un backlog basso e un utilizzo di CPU ridotto, i worker non vengono fare lo scale down basso. Questo 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 lo stesso numero di dischi permanenti. Ad esempio, se ci sono 100 dischi e 100 worker, ogni worker ha un disco. Quando il job viene ridimensionato, può avere 50 worker con due dischi permanenti per worker. Il job non viene fare lo scale down di nuovo 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 saperne di più, consulta Intervallo di scalabilità per le pipeline di scalabilità automatica di streaming.

• Quando i job utilizzano Streaming Engine, il target di riduzione della scalabilità è basato su un utilizzo della CPU target del 75%. Quando questo utilizzo della CPU non può essere raggiunto, lo scale down viene disattivato.

• La stima del tempo di backlog deve rimanere inferiore a 10 secondi per almeno due minuti prima che i worker vengano fare lo scale down. Le fluttuazioni del tempo di backlog potrebbero disattivare lo scale down. Inoltre, una velocità effettiva bassa può distorcere 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 2.59.0 e precedenti dell'SDK Apache Beam, gli worker Dataflow non fare lo scale down come previsto.

Aumentare le fermate

Il job batch o di streaming inizia a scalare, ma i worker smettono di scalare 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 aver raggiunto il limite della quota di 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 aver raggiunto il 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 scalare.

Inoltre, se la risorsa desiderata è esaurita nell'area geografica che hai scelto, non potrai creare nuove risorse di quel tipo, anche se hai ancora a disposizione parte della quota nell'area geografica o nel progetto. Ad esempio, potresti disporre di una quota sufficiente per creare indirizzi IP esterni in us-central1, ma questa regione potrebbe non avere indirizzi IP disponibili. Per saperne di più, 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 sull'utilizzo dei lavoratori non ha alcun effetto

Hai impostato il suggerimento per l'utilizzo dei worker, ma il comportamento di scalabilità automatica non cambia.

Per comprendere questo problema, vai al grafico Utilizzo CPU worker e controlla se il suggerimento sull'utilizzo dei worker viene 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 seguente tabella 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 esterni. L'aggiustamento per la riduzione delle risorse è troppo piccolo o Dataflow sta attenuando la riduzione delle risorse. Per saperne di più, consulta Euristiche di scalabilità automatica dello streaming.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys Errori RPC segnalati nei log errori del worker Arresti anomali segnalati nei log dei worker
Scale up	L'obiettivo di backlog elevato o latenza elevata sta ignorando il suggerimento. Il numero minimo di worker è stato aggiornato a un valore superiore al numero attuale di worker.	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 attuale di worker.	job/aggregated_worker_utilization job/max_worker_instances_limit

Per saperne di più, consulta Euristiche di scalabilità automatica dello streaming.

Lacune nelle metriche di scalabilità automatica

Esistono brevi interruzioni 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 l'integrità del job di streaming.

La CPU è distribuita in modo non uniforme

Quando il job esegue la scalabilità automatica, l'utilizzo della CPU è distribuito in modo non uniforme tra i worker. Alcuni worker hanno un utilizzo della CPU, una latenza di sistema o una freschezza dei dati superiori rispetto ad altri.

Questo problema può verificarsi se i dati contengono un tasto di scelta rapida. Una chiave utilizzata di frequente è una chiave con elementi sufficienti a influire negativamente sulle prestazioni della pipeline. Ogni chiave deve essere elaborata da un singolo worker, quindi il lavoro non può essere suddiviso tra i worker.

Per saperne di più, consulta la guida agli errori dei tasti di scelta rapida.

L'elemento di lavoro che richiede la lettura dello stato 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 la scalabilità automatica, le istanze VM worker comunicano con più attività Streaming Engine e ogni attività gestisce più istanze VM worker. Le chiavi degli elementi vengono utilizzate per distribuire il lavoro. Ogni attività e istanza VM 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 del job può causare la modifica della distribuzione dell'intervallo di chiavi. Questo errore può verificarsi quando un intervallo di chiavi cambia. L'errore è previsto e, a meno che non noti una correlazione tra questi messaggi e una pipeline con un rendimento inferiore, 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. Vedi Impostare l'intervallo di scalabilità automatica.

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

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

Java

Per i job di scalabilità automatica in modalità flusso 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 di streaming è N/15, dove N è il valore di --maxNumWorkers.

Per i job di scalabilità automatica di 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 tua pipeline ha bisogno di tre o quattro worker in stato stabile, puoi impostare --maxNumWorkers=15. La pipeline scala automaticamente tra 1 e 15 worker, utilizzando 1, 3, 5 o 15 worker, che corrispondono rispettivamente a 15, 5, 3 o 1 Persistent Disk per worker.

--maxNumWorkers può essere al massimo 1000.

Python

Per i job di scalabilità automatica in modalità flusso 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 di streaming è N/15, dove N è il valore di --max_num_workers.

Per i job di scalabilità automatica di 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 ha bisogno di tre o quattro worker in stato stabile, 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 Persistent Disk per worker.

--max_num_workers può essere al massimo 1000.

Vai

Per i job di scalabilità automatica in modalità flusso 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 di streaming è N/15, dove N è il valore di --max_num_workers.

Per i job di scalabilità automatica di 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 ha bisogno di tre o quattro worker in stato stabile, 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 Persistent Disk per worker.

--max_num_workers può essere al massimo 1000.

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

Java

Dataflow opera entro i limiti della quota di conteggio delle istanze Compute Engine del tuo progetto o maxNumWorkers, a seconda di quale sia inferiore.

Python

Dataflow opera entro i limiti della quota di conteggio delle istanze Compute Engine del tuo progetto o max_num_workers, a seconda di quale sia inferiore.

Vai

Dataflow opera entro i limiti della quota di conteggio delle istanze Compute Engine del tuo progetto o max_num_workers, a seconda di quale sia inferiore.

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

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

Java

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

Python

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

Vai

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

Modificare l'intervallo di scalabilità

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

Disattiva la scalabilità automatica nelle pipeline di streaming

Per disattivare lo scalabilità automatica nella pipeline di streaming, segui questi passaggi.

Java

Imposta --autoscalingAlgorithm=NONE. Per saperne di più, consulta Disattivare la scalabilità automatica orizzontale.

Python

Imposta --autoscaling_algorithm=NONE. Per saperne di più, consulta Disattivare la scalabilità automatica orizzontale.

Vai

Imposta --autoscaling_algorithm=NONE. Per saperne di più, consulta Disattivare la scalabilità automatica orizzontale.

Utilizzare un numero fisso di worker

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