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 o paralelismo é limitado.

Às vezes, o backlog é elevado, mas o paralelismo é baixo. Nesse caso, o Dataflow não é escalonar verticalmente, porque o trabalho não pode ser distribuído entre mais workers. Portanto, adicionar mais workers não ajuda no processamento. Para mais informações, consulte Escalonamento automático de streaming.

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 reduzir escala vertical verticalmente

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á reduzir escala vertical 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 reduzir escala vertical. 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.

• O PeriodicImpulse é compatível com as versões 2.60.0 e mais recentes do SDK do Apache Beam. Quando o pipeline usa PeriodicImpulse com as versões 2.59.0 e anteriores do SDK do Apache Beam, os workers do Dataflow não reduzir escala vertical vertical conforme o esperado.

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
Reduzir escala verticalmente	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.

Resolver problemas de programações de escalonamento automático

Se você tiver problemas ao criar, atualizar ou executar programações de escalonamento automático, confira os cenários comuns e as etapas de solução de problemas a seguir.

Não é possível definir ou atualizar uma programação de escalonamento automático

Se uma tentativa de criar ou atualizar uma programação de escalonamento automático falhar, verifique se a configuração da programação obedece às seguintes restrições:

• Limite de programação: um único job pode ter no máximo 10 programações de escalonamento automático. Para adicionar uma nova programação quando o job já tiver 10 programações, primeiro remova uma programação atual.
• Duração mínima: a duração da programação precisa ser de pelo menos 5 minutos (300 segundos).
• Restrições de parâmetro:
  • A meta de utilização da CPU precisa estar entre [0,1, 0,9].
  • A contagem máxima de workers precisa ser maior ou igual à contagem mínima de workers (max_workers ≥ min_workers).
• Restrições de formato do Crontab no início do job: as expressões do Crontab especificadas no início do job usando a opção de pipeline --experiments=autoscaling_schedule=... não podem conter vírgulas (como 1,15 * * * * ou * * * * MON,WED,FRI). As vírgulas são reservadas para delimitar as opções de pipeline. Se a programação exigir vírgulas, inicie o job sem a programação e configure-o após o lançamento usando uma atualização em andamento ou especifique várias programações separadas.

A programação não entra em vigor ou uma programação diferente é aplicada

Se uma programação de escalonamento automático não entrar em vigor durante a janela esperada ou se as configurações de uma programação diferente forem aplicadas, revise o seguinte:

• Apenas uma programação fica ativa por vez: se duas ou mais programações tiverem janelas de tempo sobrepostas, o Dataflow vai determinar qual programação aplicar com base na prioridade:
  • A programação com o valor de prioridade mais alto (priority) é aplicada.
  • Se várias programações ativas tiverem o mesmo valor de prioridade, a programação atualizada ou modificada mais recentemente será aplicada.
  • Quando a duração da programação ativa termina, o Dataflow aplica qualquer outra programação que ainda esteja ativa ou reverte o comportamento de escalonamento automático para as configurações padrão do job.
• Discrepâncias de fuso horário: verifique se o fuso horário especificado para sua programação corresponde à região pretendida e às regras de horário de verão. Por padrão, os horários de início da programação são interpretados em UTC.
• Verifique as programações ativas no console: no console do Google Cloud , acesse a guia Escalonamento automático na página de detalhes do job do Dataflow para ver qual programação está ativa. Também é possível inspecionar as programações configuradas e os parâmetros delas executando o comando gcloud dataflow jobs describe ou consultando a API REST.

O pipeline não é escalonar verticalmente para a contagem de workers programada

Se uma programação for ativada com limites de workers mais altos ou dicas de utilização mais baixas, mas o pipeline não for escalonar verticalmente para o número esperado de workers, verifique os seguintes fatores:

• Limites de recursos e cotas: o escalonamento vertical requer uma cota de recursos suficiente no projeto e na região do Google Cloud . A alocação de workers pode ser impedida por:
  • Cotas de instâncias do Compute Engine: seu projeto pode atingir o limite de instâncias para a região.
  • Cotas de CPU: se os workers usarem várias CPUs (por exemplo, n1-standard-4), verifique se o projeto tem cota de CPU suficiente.
  • Cotas de endereço IP: cada VM de worker requer um endereço IP. Se a cota de endereços IP na sua rede VPC ou região estiver esgotada, não será possível provisionar novos workers.
  • Disponibilidade de recursos: se a região ou zona tiver um esgotamento temporário de recursos, o Dataflow talvez não consiga criar novas instâncias de worker, mesmo que haja cota disponível. Para mais informações, consulte Como escalonar paradas.

• Sensibilidade do nível de latência: se a programação ativa configurar um nível de latência de medium_latency ou high_latency, o Dataflow vai esperar intencionalmente que mais backlog se acumule antes de acionar eventos de escalonamento vertical:

  • low_latency (padrão): escalonamento vertical quando o backlog excede 15 segundos.
  • medium_latency: aumenta quando o backlog excede 180 segundos (3 minutos).
  • high_latency: aumenta quando o backlog excede 600 segundos (10 minutos).

  Se o job parecer atrasar ou demorar para escalonar verticalmente durante um período de agendamento de horários, verifique se a programação ativa configurou um nível de latência mais alto.

• Limites de paralelismo baseados em chave: o Dataflow não pode escalonar além do número de chaves de processamento distintas disponíveis nesse estágio. Se o fluxo de dados tiver poucas chaves exclusivas, adicionar workers não vai melhorar a capacidade de processamento, e o Dataflow vai limitar a contagem de workers para evitar recursos de inatividade.

• Estabilidade do pool de workers: se as instâncias de worker encontrarem falhas ou erros de falta de memória (OOM, na sigla em inglês), o Dataflow pausará temporariamente as solicitações de redimensionamento do escalonamento automático até que o pool de workers se estabilize.

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 quente. Uma chave quente é 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, 3, 5 ou 15 workers, que correspondem a 15, 5, 3 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 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 --max_num_workers.

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 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 --max_num_workers.

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.

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.