Resolver problemas de escalonamento automático do Dataflow

Nesta página, mostramos como resolver problemas com os recursos de escalonamento automático do Dataflow e fornecemos informações sobre como gerenciar o escalonamento automático.

O job não é escalonado automaticamente

Nesta seção, fornecemos informações sobre cenários que podem impedir que os workers aumentem ou diminuam o escalonamento.

O job de streaming não é escalonado

Quando o pipeline de streaming tem um backlog, os workers não escalonam verticalmente.

Esse problema ocorre quando o backlog dura menos de alguns minutos ou quando os workers estão usando menos de 20% das CPUs deles.

Às vezes, o backlog é elevado, mas o uso da CPU é baixo. Como algumas tarefas não exigem alta utilização da CPU, a adição de workers não melhora o desempenho. Nesses casos, o Dataflow não é escalonado verticalmente. Para mais informações, consulte Escalonamento automático de streaming. Esse cenário pode ocorrer pelos seguintes motivos:

O pipeline é intenso de E/S.
O pipeline está aguardando chamadas RPC externas.
As teclas de atalho causam um uso desigual de CPU do worker.
O pipeline não tem chaves suficientes.

Jobs de lote e streaming não escalonam verticalmente

O job em lote ou de streaming é executado conforme o esperado, mas, quando mais workers são necessários, o job não é escalonado verticalmente.

Esse problema pode ocorrer por um dos seguintes motivos:

Os arquivos de preparação ou temporários não podem ser acessados. Se o job usar um bucket do Cloud Storage, o bucket poderá ter uma configuração de ciclo de vida que exclui objetos no bucket. Os objetos excluídos incluem pastas e arquivos temporários e de preparação. Para verificar se os arquivos foram excluídos, confira a configuração do ciclo de vida do bucket. Se as pastas ou os arquivos temporários ou de preparo tiverem sido excluídos após o início do job, talvez os pacotes necessários para criar novos workers não existam. Para resolver esse problema, recrie as pastas e os arquivos no bucket.
As regras de firewall impedem que os workers enviem e recebam tráfego nas portas TCP necessárias. As regras de firewall podem impedir que os workers sejam iniciados. Os workers do Dataflow precisam enviar e receber tráfego nas portas TCP 12345 e 12346. Para mais informações, incluindo etapas para resolver esse problema, consulte Regras de firewall para o Dataflow.
Uma origem personalizada tem um método getProgress() que retorna um valor NULL. Quando você usa uma fonte personalizada, as métricas de backlog dependem do valor de retorno do método getProgress() da origem personalizada para começar a coletar dados. A implementação padrão de getProgress() retorna um valor NULL. Para resolver esse problema, verifique se a origem personalizada substitui o método getProgress() padrão para retornar um valor não NULL.
Uma atualização acionada pelo escalonamento automático vertical desativa temporariamente o escalonamento automático horizontal. Para mais informações, consulte Efeito no escalonamento automático horizontal.
Se você usar uma operação map em um canal do Python e o job não for escalonado, talvez seja necessário adicionar uma transformação Reshuffle ao código do pipeline. Para mais informações, consulte Reshuffle na documentação do Apache Beam.

O job de streaming não reduz a escala vertical

Quando o job de streaming tem um backlog baixo e uma baixa utilização da CPU, os workers não reduzem a escala vertical. Esse problema pode ocorrer por vários motivos.

Quando os jobs não usam o Streaming Engine, o Dataflow equilibra o número de discos permanentes entre os workers. Como resultado, cada worker precisa ter um número igual de discos permanentes. Por exemplo, se houver 100 discos e 100 workers, cada worker terá um disco. Quando o job reduz a escala vertical, ele pode ter 50 workers com dois discos permanentes por worker. O job não será escalonado novamente até ter 25 workers com quatro discos permanentes por worker. Além disso, o número mínimo de workers é o valor atribuído ao maxNumWorkers dividido por 15. Para mais informações, consulte Intervalo de escalonamento de pipelines de escalonamento automático de streaming.
Quando os jobs usam o Streaming Engine, a meta de redução de escalonamento é baseada em uma utilização de CPU de 75%. Quando não for possível usar essa CPU, o downgrade será desativado.
A estimativa de tempo do backlog precisa permanecer abaixo de 10 segundos por pelo menos dois minutos antes que os workers reduzam a escala. As variações no tempo de backlog podem desativar a redução da escala vertical. Além disso, a baixa capacidade de processamento pode distorcer a estimativa de tempo.
Quando o pipeline usa PeriodicImpulse, os workers do Dataflow não são reduzidos conforme o esperado. O uso de PeriodicImpulse não é compatível com o escalonamento automático de streaming.

Escalonamento de paradas

O job em lote ou de streaming começa a escalonar verticalmente, mas os workers deixam de ser escalonados verticalmente mesmo com um backlog restante.

Esse problema ocorre quando os limites de cota são atingidos.

Cotas do Compute Engine: os jobs do Dataflow estão sujeitos à cota do Compute Engine do projeto. Se vários jobs estiverem em execução, o projeto poderá estar no limite da cota do Compute Engine. Nesse caso, o Dataflow não pode aumentar o número de workers.
Cotas de CPU: os jobs do Dataflow também estão sujeitos à cota de CPU do projeto. Se o tipo de worker usa mais de uma CPU, o projeto pode estar no limite da cota de CPU.
Cotas de endereços IP externos: quando o job usa endereços IP externos para se comunicar com recursos, você precisa de tantos endereços IP externos quanto workers. Quando o número de workers aumenta, o número de endereços IP externos também aumenta. Quando você atinge o limite de endereços IP, os workers param de escalonar verticalmente.

Além disso, se a região escolhida não for de um recurso, não será possível criar novos recursos desse tipo, mesmo que você ainda tenha cota restante na região ou no projeto. Por exemplo, você ainda pode ter cota para criar endereços IP externos em us-central1, mas essa região pode não ter endereços IP disponíveis. Veja mais informações em Cotas e disponibilidade de recursos.

Para resolver esse problema, solicite um aumento de cota ou execute o job em uma região diferente.

A dica de utilização do worker não tem efeito

Você define a dica de utilização do worker, mas o comportamento de escalonamento automático não muda.

Para entender esse problema, acesse o gráfico de utilização da CPU do worker e verifique se a dica de utilização do worker é usada ativamente. Se a dica estiver sendo usada, o gráfico mostrará CPU utilization hint (actively used by autoscaler). Caso contrário, ele mostrará CPU utilization hint (not actively used by autoscaler).

A dica de utilização é apenas um fator que afeta o escalonamento automático. A tabela a seguir lista alguns motivos pelos quais o escalonador automático pode não usar ativamente a dica:

Comportamento de escalonamento observado	Causas	Métricas a serem verificadas
Sem alterações	Você atingiu o número mínimo ou máximo de workers. O número de workers é limitado pelo número de chaves processadas em paralelo. Os jobs são limitados por RPCs externas. O ajuste de redução é muito pequeno ou o Dataflow está abrandando a redução. Para mais informações, consulte Heurística de escalonamento automático de streaming.	`job/aggregated_worker_utilization` `job/max_worker_instances_limit` `job/min_worker_instances_limit` `job/processing_parallelism_keys` Erros de RPC relatados nos registros de erros do worker Falhas informadas nos registros do worker
Escalonar verticalmente	A meta de backlog alto ou de latência está substituindo a dica. O número mínimo de workers foi atualizado para um valor maior do que o número atual.	`job/aggregated_worker_utilization` `job/backlog_bytes` `job/backlog_elements` `job/estimated_timer_backlog_processing_time` `job/min_worker_instances_limit`
Diminuir a escala	O número máximo de workers foi atualizado para um valor menor do que o número atual.	`job/aggregated_worker_utilization` `job/max_worker_instances_limit`

Para mais informações, consulte Heurísticas de escalonamento automático de streaming.

Lacunas nas métricas de escalonamento automático

Há lacunas curtas e temporárias nas métricas de escalonamento automático.

Esse problema pode ocorrer se as tarefas de back-end forem reiniciadas. Essas lacunas nas métricas não indicam um problema com o escalonamento automático ou a integridade do job de streaming.

A CPU está distribuída desigualmente

Quando o job está com escalonamento automático, a utilização da CPU é distribuída de maneira desigual entre os workers. Alguns workers têm uma utilização de CPU, latência do sistema ou atualização de dados mais alta do que outros.

Esse problema pode ocorrer se os dados contêm uma chave de uso intenso. Uma chave com uso intenso é uma chave com elementos suficientes para afetar negativamente o desempenho do pipeline. Cada chave precisa ser processada por um único worker, portanto, o trabalho não pode ser dividido entre workers.

Para mais informações, consulte a orientação para erros de teclas de atalho.

"O item de trabalho que solicita a leitura do estado não é mais válido no back-end.

Durante a comunicação entre instâncias de VM de worker e tarefas do Streaming Engine em um pipeline de streaming, ocorre o seguinte erro:

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 o escalonamento automático, as instâncias de VM de worker se comunicam com várias tarefas do Streaming Engine, e cada tarefa exibe várias instâncias de VM de worker. As chaves de item são usadas para distribuir o trabalho. Cada tarefa e instância de VM de worker tem um conjunto de intervalos de chaves, e a distribuição desses intervalos pode mudar dinamicamente. Por exemplo, durante o escalonamento automático, o redimensionamento do job pode alterar a distribuição de intervalos de chaves. Quando um intervalo de chaves muda, este erro pode ocorrer. O erro é esperado. A menos que você veja uma correlação entre essas mensagens e um pipeline com baixo desempenho, ignore-o.

Recursos insuficientes do Streaming Engine

Se o Streaming Engine não puder alocar o número mínimo de workers solicitados, o seguinte erro será retornado:

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

Para resolver esse problema, tente definir um número mínimo menor de workers. Consulte Definir o intervalo de escalonamento automático.

Intervalo de escalonamento para pipelines de escalonamento automático de streaming

Nesta seção, fornecemos detalhes sobre o intervalo de escalonamento dos pipelines de escalonamento automático de streaming.

Java

Para jobs de escalonamento automático de streaming que não usam o Streaming Engine, o serviço do Dataflow aloca de 1 a 15 discos permanentes para cada worker. Isso significa que o número mínimo de workers usados para um pipeline de escalonamento automático de streaming é N/15, em que N é o valor de --maxNumWorkers.

Para jobs de escalonamento automático de streaming que usam o Streaming Engine, o número mínimo de workers é 1.

O Dataflow equilibra o número de discos permanentes entre os workers. Por exemplo, se o pipeline precisar de três ou quatro workers estáveis, defina --maxNumWorkers=15. O pipeline escalona automaticamente entre 1 e 15 workers, usando 1, 2, 3, 4, 5, 8 ou 15 workers, que correspondem a 15, 8, 5, 4, 3, 2 ou 1 discos permanentes por worker, respectivamente.

--maxNumWorkers pode ser de, no máximo, 1.000.

Python

Para jobs de escalonamento automático de streaming que usam o Streaming Engine, o número mínimo de workers é 1.

O Dataflow equilibra o número de discos permanentes entre os workers. Por exemplo, se o pipeline precisar de três ou quatro workers estáveis, defina --max_num_workers=15. O pipeline escalona automaticamente entre 1 e 15 workers, usando 1, 2, 3, 4, 5, 8 ou 15 workers, que correspondem a 15, 8, 5, 4, 3, 2 ou 1 discos permanentes por worker, respectivamente.

--max_num_workers pode ser de, no máximo, 1.000.

Go

Para jobs de escalonamento automático de streaming que usam o Streaming Engine, o número mínimo de workers é 1.

--max_num_workers pode ser de, no máximo, 1.000.

O número máximo de workers que fazem o escalonamento automático pode usar

Java

O Dataflow opera dentro dos limites da cota de contagem de instâncias do Compute Engine do seu projeto ou maxNumWorkers, o que for menor.

Python

O Dataflow opera dentro dos limites da cota de contagem de instâncias do Compute Engine do seu projeto ou max_num_workers, o que for menor.

Go

O Dataflow opera dentro dos limites da cota de contagem de instâncias do Compute Engine do seu projeto ou max_num_workers, o que for menor.

Limitar o escalonamento automático para reduzir o impacto no faturamento

Se você não quiser que o escalonamento automático aumente sua fatura, é possível limitar o número máximo de workers que seu job de streaming pode usar.

Java

Ao especificar --maxNumWorkers, você limita o intervalo de dimensionamento usado para processar o job.

Python

Ao especificar --max_num_workers, você limita o intervalo de dimensionamento usado para processar o job.

Go

Ao especificar --max_num_workers, você limita o intervalo de dimensionamento usado para processar o job.

Mudar o intervalo de escalonamento

Para informações sobre como alterar o intervalo de escalonamento em um pipeline de streaming, consulte Definir o intervalo de escalonamento automático.

Desativar o escalonamento automático em pipelines de streaming

Para desativar o escalonamento automático no pipeline de streaming, siga estas etapas.

Java

Defina --autoscalingAlgorithm=NONE. Para mais informações, consulte Desativar o escalonamento automático horizontal.

Python

Defina --autoscaling_algorithm=NONE. Para mais informações, consulte Desativar o escalonamento automático horizontal.

Go

Defina --autoscaling_algorithm=NONE. Para mais informações, consulte Desativar o escalonamento automático horizontal.

Usar um número fixo de workers

Para jobs de streaming que não usam o Streaming Engine, o comportamento padrão é usar um número fixo de workers. Para usar o escalonamento automático de streaming com esses pipelines, é preciso ativar explicitamente, já que ele não está ativado por padrão.