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étodogetProgress()
da origem personalizada para começar a coletar dados. A implementação padrão degetProgress()
retorna um valor NULL. Para resolver esse problema, verifique se a origem personalizada substitui o métodogetProgress()
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çãoReshuffle
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 dePeriodicImpulse
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 |
|
|
Escalonar verticalmente |
|
|
Diminuir a escala |
|
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 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.