Ajustar o escalonamento automático horizontal para pipelines de streaming

Em pipelines de streaming com dados de entrada flutuantes ou de alto volume, geralmente é necessário equilibrar a latência de processamento com os custos operacionais. Embora o Dataflow forneça configurações padrão de escalonamento automático horizontal que atendem a muitas cargas de trabalho, o comportamento padrão pode não corresponder aos seus requisitos específicos. Por exemplo, talvez você queira reduzir custos aceitando uma latência média mais alta, escalonar verticalmente com mais rapidez para lidar com picos de tráfego ou aplicando limites estritos à alocação de workers.

O ajuste do escalonamento automático horizontal permite personalizar como o Dataflow ajusta a capacidade do worker em resposta às mudanças nas demandas de carga de trabalho. Ao ajustar os parâmetros de escalonamento automático, é possível otimizar a capacidade de processamento do pipeline, controlar os custos de computação e atingir seus objetivos específicos de latência.

Otimizar o escalonamento automático horizontal

Para otimizar o escalonamento automático horizontal, ajuste os seguintes parâmetros:

Definir o intervalo de escalonamento automático

Ao criar um novo job de streaming, é possível definir o número inicial e máximo de workers. Para fazer isso, especifique as seguintes opções de pipeline:

Java

  • --numWorkers: o número inicial de workers disponíveis quando o pipeline começa a ser executado.
  • --maxNumWorkers: o número máximo de workers disponíveis para o pipeline.

Python

  • --num_workers: o número inicial de workers disponíveis quando o pipeline começa a ser executado.
  • --max_num_workers: o número máximo de workers disponíveis para o pipeline.

Go

  • --num_workers: o número inicial de workers disponíveis quando o pipeline começa a ser executado.
  • --max_num_workers: o número máximo de workers disponíveis para o pipeline.

Para jobs de streaming que usam o Streaming Engine, a sinalização --maxNumWorkers é opcional. O padrão é 100. Para jobs de streaming que não usam o Streaming Engine, --maxNumWorkers é necessário quando o Escalonamento automático horizontal está ativado.

O valor inicial de --maxNumWorkers também determina quantos discos permanentes são alocados para o job. Os pipelines de streaming são implantados com um pool fixo de discos permanentes equivalente ao número de --maxNumWorkers. Durante o streaming, os discos permanentes são redistribuídos para que cada worker tenha um número igual de discos anexados.

Se você definir --maxNumWorkers, verifique se o valor corresponde ao número suficiente de discos para o pipeline. Considere o crescimento futuro ao definir o valor inicial. Para informações sobre o desempenho dos discos permanentes, consulte Configurar discos permanentes e VMs. O Dataflow cobra pelo uso do disco permanente e tem cotas do Compute Engine, incluindo as de disco permanente.

Por padrão, o número mínimo de workers é 1 para jobs de streaming que usam o Streaming Engine e (maxNumWorkers/15), arredondado para cima, para jobs que não usam o Streaming Engine.

Atualizar o intervalo de escalonamento automático

Para jobs que usam o Streaming Engine, você pode ajustar o número mínimo e máximo de workers sem parar ou substituir o job. Para ajustar esses valores, use uma atualização de job em andamento. Atualize as seguintes opções de job:

  • --min-num-workers: o número mínimo de workers.

  • --max-num-workers: o número máximo de workers.

gcloud

Use o comando gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --min-num-workers=MINIMUM_WORKERS \
  --max-num-workers=MAXIMUM_WORKERS \
  JOB_ID

Substitua:

  • REGION: o ID da região do endpoint regional do job
  • MINIMUM_WORKERS: o número mínimo de instâncias do Compute Engine
  • MAXIMUM_WORKERS: o número máximo de instâncias do Compute Engine
  • JOB_ID: o ID do job a ser atualizado

Também é possível atualizar --min-num-workers e --max-num-workers individualmente.

REST

Use o método projects.locations.jobs.update:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.max_num_workers,runtime_updatable_params.min_num_workers
{
  "runtime_updatable_params": {
    "min_num_workers": MINIMUM_WORKERS,
    "max_num_workers": MAXIMUM_WORKERS
  }
}

Substitua:

  • PROJECT_ID: o ID do projeto do Google Cloud job do Dataflow
  • REGION: o ID da região do endpoint regional do job
  • JOB_ID: o ID do job a ser atualizado
  • MINIMUM_WORKERS: o número mínimo de instâncias do Compute Engine
  • MAXIMUM_WORKERS: o número máximo de instâncias do Compute Engine

Também é possível atualizar min_num_workers e max_num_workers individualmente. Especifique quais parâmetros atualizar no parâmetro de consulta updateMask e inclua os valores atualizados no campo runtimeUpdatableParams do corpo da solicitação. O exemplo a seguir atualiza min_num_workers:

PUT https://dataflow.googleapis.com/v1b3/projects/my_project/locations/us-central1/jobs/job1?updateMask=runtime_updatable_params.min_num_workers
{
  "runtime_updatable_params": {
    "min_num_workers": 5
  }
}

Para jobs que não usam o Streaming Engine, é possível substituir o job atual por um valor atualizado de maxNumWorkers.

Se você atualizar um job de streaming que não use o Streaming Engine, o job atualizado terá o Escalonamento automático horizontal desativado por padrão. Para manter o escalonamento automático ativado, especifique --autoscalingAlgorithm e --maxNumWorkers para o job atualizado.

Definir a dica de utilização do worker

O Dataflow usa a utilização média da CPU como um sinal para aplicar o escalonamento automático horizontal. Por padrão, o Dataflow define uma meta de utilização da CPU de 0,8. Quando a utilização estiver fora desse intervalo, o Dataflow poderá adicionar ou remover workers.

Para ter mais controle sobre o comportamento do escalonamento automático, defina a meta de uso da CPU como um valor no intervalo [0,1, 0,9].

  • Defina um valor mais baixo de utilização da CPU se quiser alcançar latências de pico mais baixas. Um valor menor permite que o Dataflow seja escalonar horizontalmente horizontalmente de maneira mais agressiva em resposta à crescente utilização do worker e reduza a escala de maneira mais conservadora para melhorar a estabilidade. Um valor menor também oferece margem quando o pipeline está em execução em um estado estável, geralmente resultando em uma latência de cauda mais baixa. A latência de cauda mede os tempos de espera mais longos antes do processamento de um novo registro.

  • Defina um valor mais alto se você quiser economizar recursos e manter os custos mais baixos quando o tráfego aumentar. Um valor maior impede o aumento excessivo da escala, à custa de maior latência.

Para configurar a dica de utilização ao executar um job sem modelo, defina a opção de serviço worker_utilization_hint. Para um job de modelo, atualize a dica de utilização, já que as opções de serviço não têm suporte.

O exemplo a seguir mostra como usar worker_utilization_hint:

Java

--dataflowServiceOptions=worker_utilization_hint=TARGET_UTILIZATION

Substitua TARGET_UTILIZATION por um valor no intervalo [0,1, 0,9].

Python

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

Substitua TARGET_UTILIZATION por um valor no intervalo [0,1, 0,9].

Go

--dataflow_service_options=worker_utilization_hint=TARGET_UTILIZATION

Substitua TARGET_UTILIZATION por um valor no intervalo [0,1, 0,9].

Para novos pipelines, recomendamos que você teste sob cargas realistas usando a configuração padrão. Em seguida, avalie o comportamento do escalonamento automático conforme ele se aplica ao seu pipeline e faça os ajustes necessários.

A dica de utilização é apenas um fator usado pelo Dataflow ao decidir se precisa escalonar ou não workers. Outros fatores, como backlog e chaves disponíveis, podem modificar o valor da dica. Além disso, a dica não é um alvo rigoroso. O escalonador automático tenta manter a utilização da CPU no intervalo do valor da dica, mas a métrica de utilização agregada pode ser maior ou menor. Para mais informações, consulte Heurísticas de escalonamento automático de streaming.

Atualizar a dica de utilização

Para atualizar a dica de utilização enquanto um job está em execução, execute uma atualização em andamento da seguinte maneira:

gcloud

Use o comando gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --worker-utilization-hint=TARGET_UTILIZATION \
  JOB_ID

Substitua:

  • REGION: o ID da região do endpoint regional do job
  • JOB_ID: o ID do job a ser atualizado
  • TARGET_UTILIZATION: um valor no intervalo [0,1, 0,9].

Para redefinir a dica de utilização para o valor padrão, use o seguinte comando gcloud:

gcloud dataflow jobs update-options \
  --unset-worker-utilization-hint \
  --region=REGION \
  --project=PROJECT_ID \
  JOB_ID

REST

Use o método projects.locations.jobs.update:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtime_updatable_params.worker_utilization_hint
{
  "runtime_updatable_params": {
    "worker_utilization_hint": TARGET_UTILIZATION
  }
}

Substitua:

  • PROJECT_ID: o ID do projeto do Google Cloud do job do Dataflow.
  • REGION: o ID da região do endpoint regional do job.
  • JOB_ID: o ID do job a ser atualizado.
  • TARGET_UTILIZATION: um valor no intervalo [0,1, 0,9].

Definir dica de paralelismo de workers

Para lidar com o escalonamento automático em operações longas que dependem menos de CPUs, como cargas de trabalho com uso intensivo de ML, defina a dica de paralelismo de worker usando as dicas de recursos do Apache Beam. Essas dicas mudam o escalonamento automático para um modo diferente, otimizado para cargas de trabalho com uso intensivo de GPU ou transformações com longo tempo de processamento.

O exemplo a seguir mostra como anexar uma dica de paralelismo a uma transformação:

Java

pcoll.apply(MyCompositeTransform.of(...)
  .setResourceHints(
      ResourceHints.create()
          .withMaxActiveBundlesPerWorker(TARGET_PARALLELISM_PER_WORKER)))

Substitua TARGET_PARALLELISM_PER_WORKER por um valor adequado ao seu caso de uso. Para orientações gerais, consulte como escolher um bom valor inicial.

Python

pcoll | MyPTransform().with_resource_hints(
  max_active_bundles_per_worker="TARGET_PARALLELISM_PER_WORKER")

Substitua TARGET_PARALLELISM_PER_WORKER por um valor adequado ao seu caso de uso. Para orientações gerais, consulte como escolher um bom valor inicial.

Escolher o valor da dica de paralelismo de workers

Para casos de uso de ML, um bom valor inicial é equivalente ao número de modelos em execução em paralelo em cada worker. Esse valor é limitado pela capacidade dos aceleradores no worker e pelo tamanho do modelo.

Para outros casos de uso, o pipeline é vinculado à memória ou à CPU. Para pipelines vinculados à memória, use o limite de memória para calcular o processamento paralelo máximo. Para pipelines vinculados à CPU, é recomendável manter a política de escalonamento automático padrão, em vez de fornecer uma dica de paralelismo.

É possível ajustar o valor para acomodar as necessidades de processamento de outras etapas, como gravar em um coletor. Aumentar o valor em 1 ou 2 quando o paralelismo do modelo é 2 ajuda a reconhecer o tempo de processamento mais rápido da gravação no coletor, mais folga para considerar o processamento feito em outras etapas. Se o pipeline não envolver o embaralhamento e as transformações forem combinadas em uma única etapa, não será necessário ajustar o valor para outras transformações.

Esse valor também pode ser ajustado para simular os efeitos de atrasos aceitáveis no backlog. Por exemplo, se você aceita um atraso máximo de 10 minutos e o tempo médio de processamento do seu modelo é de 1 minuto, é possível aumentar o valor em 1, supondo que o número máximo de workers esteja definido como 10.

Heurística de escalonamento automático com uso intensivo de GPU

Na configuração de uso intensivo de GPU indicada pela dica de paralelismo de configuração, o Dataflow considera vários fatores ao fazer o escalonamento automático. Entre esses fatores estão:

  • Chaves disponíveis. As chaves são a unidade fundamental de paralelismo no Dataflow.
  • Máximo de pacotes ativos por worker. Isso sugere o número máximo ideal de paralelismo de processamento no worker.

A ideia geral por trás das decisões de escalonamento é calcular os workers necessários para processar a carga atual, conforme sinalizado pelas chaves disponíveis. Por exemplo, se houver 100 chaves disponíveis para processamento e o paralelismo máximo por worker for 10, o ideal é ter 10 workers no total.

Se o pipeline for complexo e tiver uma carga de trabalho pesada com uso intensivo de GPU e várias transformações com uso intensivo de CPU, recomendamos ativar o ajuste correto. Isso permite que o serviço faça uma boa distinção entre o trabalho que exige muita CPU e o que exige muita GPU e, em seguida, escalone cada pool de workers de acordo.

Definir o nível de latência

O escalonamento automático horizontal do Dataflow usa a duração do backlog para determinar quando escalonar os workers. Por padrão, o Dataflow visa uma duração de backlog de menos de 15 segundos, o que é adequado para cargas de trabalho em tempo real, mas pode resultar em custos de recursos mais altos.

Para jobs de streaming que usam o Streaming Engine, é possível configurar o limite de backlog escolhendo um nível de latência. Um nível de latência é mapeado para uma duração de backlog de destino, permitindo que você configure a sensibilidade do escalonador automático para a duração do backlog. Uma decisão de escalonamento automático só é acionada quando a duração do backlog excede o nível selecionado por vários minutos.

A tabela a seguir descreve os níveis de latência disponíveis:

Nível de latência Tempo de backlog estimado permitido Caso de uso pretendido
low_latency Menos de 15 segundos Prioriza o escalonamento vertical rápido para manter o backlog mínimo. Valor padrão selecionado se nenhum nível for especificado
medium_latency Menos de 2 minutos Meio-termo equilibrado entre latência e custos de recursos.
high_latency Menos de 10 minutos Prioriza a economia de custos ao permitir que o backlog se acumule. Projetado para cargas de trabalho tolerantes a atrasos.

Para configurar o nível de latência ao criar um job, defina a opção de pipeline enable_latency_tier_lightweight_update:

--experiments=enable_latency_tier_lightweight_update=TIER

Substitua TIER por um dos níveis de latência disponíveis (por exemplo, medium_latency).

Atualizar o nível de latência

Para atualizar o nível de latência enquanto um job está em execução, execute uma atualização em andamento usando o comando gcloud dataflow jobs update-options:

gcloud dataflow jobs update-options \
  --region=REGION \
  --latency-tier=TIER \
  JOB_ID

Substitua:

  • REGION: o ID da região do endpoint regional do job.
  • JOB_ID: o ID do job a ser atualizado
  • TIER: o nível de latência de destino. Uma das seguintes opções: low_latency, medium_latency ou high_latency

Para redefinir o nível de latência e reverter para o comportamento padrão de baixa latência, use o seguinte comando:

gcloud dataflow jobs update-options \
  --unset-latency-tier \
  --region=REGION \
  JOB_ID

Programar mudanças no escalonamento automático

Para jobs de streaming que usam o Streaming Engine, é possível configurar programações de escalonamento automático para aplicar automaticamente substituições de parâmetros durante janelas de tempo recorrentes. Isso é útil para antecipar variações previsíveis na carga de trabalho, como escalonar verticalmente durante o horário de funcionamento de pico ou reduzir escala vertical durante períodos de menor movimento, sem atualizar manualmente o job todas as vezes. Cada job pode ter até 10 programações especificadas.

Uma programação de escalonamento automático especifica:

  • Início da programação: uma expressão crontab que determina quando a programação é acionada.
  • Duração: o período em segundos em que as substituições permanecem ativas. Precisa ser de pelo menos 5 minutos.
  • Fuso horário: um fuso horário opcional do banco de dados tz (por exemplo, America/New_York). O padrão é UTC.
  • Prioridade: uma prioridade opcional para a programação, em que valores maiores indicam prioridade mais alta. As programações com prioridade mais alta são aplicadas primeiro. Se uma programação já estiver ativa quando uma de prioridade mais alta for aplicada, a de prioridade mais alta vai substituir a atual. Se duas programações tiverem a mesma prioridade, a programação modificada mais recentemente será aplicada.
  • Substituições de parâmetros: as configurações de escalonamento automático a serem usadas durante a janela ativa, incluindo o número mínimo e máximo de workers e a dica de utilização de workers.

Quando o período de agendamento de horários termina, o Dataflow reverte automaticamente o comportamento de escalonamento automático para as configurações padrão do job. É possível definir várias programações para um único job.

Definir uma programação de escalonamento automático no início do job

Para definir uma programação inicial de escalonamento automático ao iniciar um novo job de streaming, especifique a opção de pipeline experimental autoscaling_schedule ou inclua o campo runtimeUpdatableParams.schedules ao criar um job usando a API REST.

Especifique o experimento autoscaling_schedule como uma string separada por ponto e vírgula de pares key:value com os seguintes atributos:

Obrigatório:

  • name: um identificador exclusivo para a programação.
  • crontab: uma expressão crontab que especifica quando a programação é acionada.
  • duration: a duração em segundos em que a programação permanece ativa.

Opcional:

  • timezone: o fuso horário do banco de dados tz (por exemplo, America/New_York). O padrão é UTC.
  • min_workers: o número mínimo de workers a serem alocados durante a programação.
  • max_workers: o número máximo de workers a serem alocados durante a programação.
  • cpu_utilization_target: a meta de uso da CPU do worker durante a programação, no intervalo [0,1, 0,9]
  • latency_tier: o nível de latência desejado (low_latency, medium_latency ou high_latency)

  • priority: a prioridade da programação, em que valores maiores indicam prioridade mais alta.

Java

--experiments=autoscaling_schedule="name=SCHEDULE_NAME;crontab=CRONTAB_EXPRESSION;duration=DURATION_SECONDS;timezone=TIMEZONE;min_workers=MINIMUM_WORKERS;max_workers=MAXIMUM_WORKERS;cpu_utilization_target=TARGET_UTILIZATION;latency_tier=LATENCY_TIER;priority=PRIORITY"

Python

--experiments=autoscaling_schedule="name=SCHEDULE_NAME;crontab=CRONTAB_EXPRESSION;duration=DURATION_SECONDS;timezone=TIMEZONE;min_workers=MINIMUM_WORKERS;max_workers=MAXIMUM_WORKERS;cpu_utilization_target=TARGET_UTILIZATION;latency_tier=LATENCY_TIER;priority=PRIORITY"

Go

--experiments=autoscaling_schedule="name=SCHEDULE_NAME;crontab=CRONTAB_EXPRESSION;duration=DURATION_SECONDS;timezone=TIMEZONE;min_workers=MINIMUM_WORKERS;max_workers=MAXIMUM_WORKERS;cpu_utilization_target=TARGET_UTILIZATION;latency_tier=LATENCY_TIER;priority=PRIORITY"

REST

Use o método projects.locations.jobs.create e inclua o objeto runtimeUpdatableParams.schedules no corpo da solicitação:

POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs
{
"name": "JOB_NAME",
"environment": { ... },
"runtimeUpdatableParams": {
  "schedules": [
    {
      "name": "SCHEDULE_NAME",
      "crontab": "CRONTAB_EXPRESSION",
      "duration": "DURATION_SECONDSs",
      "timeZone": "TIMEZONE",
      "priority": PRIORITY,
      "parameters": {
        "minWorkerCount": MINIMUM_WORKERS,
        "maxWorkerCount": MAXIMUM_WORKERS,
        "cpuUtilizationTarget": TARGET_UTILIZATION,
        "latencyTarget": LATENCY_TIER
      }
    }
  ]
}
}

Criar ou atualizar uma programação de escalonamento automático para um job em execução

Para criar ou atualizar uma programação de escalonamento automático para um job em execução, faça uma atualização em andamento:

gcloud

Use o comando gcloud dataflow jobs update-options com a flag --set-schedule:

gcloud dataflow jobs update-options \
  --region=REGION \
  --set-schedule=SCHEDULE_NAME \
  --autoscaling-schedule="CRONTAB_EXPRESSION" \
  --autoscaling-schedule-duration-seconds=DURATION_SECONDS \
  --autoscaling-schedule-timezone=TIMEZONE \
  --autoscaling-min-workers=MINIMUM_WORKERS \
  --autoscaling-max-workers=MAXIMUM_WORKERS \
  --autoscaling-worker-utilization-hint=TARGET_UTILIZATION \
  --autoscaling-latency-tier=LATENCY_TIER \
  --autoscaling-schedule-priority=PRIORITY \
  JOB_ID

Substitua:

  • REGION: o ID da região do endpoint regional do job
  • SCHEDULE_NAME: um identificador exclusivo para a programação.
  • CRONTAB_EXPRESSION: uma expressão crontab que especifica quando a programação é acionada (por exemplo, "0 0 * * FRI")
  • DURATION_SECONDS: a duração em segundos em que a programação está ativa (por exemplo, 3600)
  • TIMEZONE: o fuso horário da programação do banco de dados tz (por exemplo, America/New_York). Se omitido, o padrão será UTC.
  • MINIMUM_WORKERS: o número mínimo de workers a serem alocados durante a programação.
  • MAXIMUM_WORKERS: o número máximo de workers a serem alocados durante a programação
  • LATENCY_TIER: o nível de latência de destino (low_latency, medium_latency ou high_latency)
  • JOB_ID: o ID do job a ser atualizado

Ao criar uma nova programação, --autoscaling-schedule e --autoscaling-schedule-duration-seconds são obrigatórios. Para modificar uma programação, especifique --set-schedule e apenas os parâmetros que você quer atualizar.

REST

Use o método projects.locations.jobs.update:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtimeUpdatableParams.schedules
{
  "runtimeUpdatableParams": {
    "schedules": [
      {
        "name": "SCHEDULE_NAME",
        "crontab": "CRONTAB_EXPRESSION",
        "duration": "DURATION_SECONDSs",
        "timeZone": "TIMEZONE",
        "priority": PRIORITY,
        "parameters": {
          "minWorkerCount": MINIMUM_WORKERS,
          "maxWorkerCount": MAXIMUM_WORKERS,
          "cpuUtilizationTarget": TARGET_UTILIZATION,
          "latencyTarget": LATENCY_TIER
        }
      }
    ]
  }
}

Substitua:

  • PROJECT_ID: o ID do projeto do Google Cloud job do Dataflow
  • REGION: o ID da região do endpoint regional do job
  • JOB_ID: o ID do job a ser atualizado
  • SCHEDULE_NAME: um identificador exclusivo para a programação.
  • CRONTAB_EXPRESSION: uma expressão crontab que especifica quando a programação é acionada
  • DURATION_SECONDS: a duração em segundos em que a programação está ativa (por exemplo, 3600)
  • TIMEZONE: o fuso horário da programação do banco de dados tz (por exemplo, America/New_York)
  • MINIMUM_WORKERS: o número mínimo de workers a serem alocados durante a programação.
  • MAXIMUM_WORKERS: o número máximo de workers a serem alocados durante a programação
  • TARGET_UTILIZATION: um valor no intervalo [0,1, 0,9].

Remover uma programação de escalonamento automático

Para remover uma programação de escalonamento automático específica ou todas as programações de um job, faça uma atualização em andamento:

gcloud

Para remover uma única programação, especifique a flag --unset-schedule:

gcloud dataflow jobs update-options \
  --region=REGION \
  --unset-schedule=SCHEDULE_NAME \
  JOB_ID

Para remover todas as programações de um job, especifique a flag --unset-schedules:

gcloud dataflow jobs update-options \
  --region=REGION \
  --unset-schedules \
  JOB_ID

REST

Use o método projects.locations.jobs.update com updateMask=runtimeUpdatableParams.schedules, omitindo a programação da matriz schedules ou fornecendo uma lista schedules vazia para remover todas as programações:

PUT https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/jobs/JOB_ID?updateMask=runtimeUpdatableParams.schedules
{
  "runtimeUpdatableParams": {
    "schedules": []
  }
}

Para resolver problemas com programações de escalonamento automático, consulte Resolver problemas de programações de escalonamento automático.

Heurística de escalonamento automático de streaming

Para pipelines de streaming, o objetivo do Escalonamento automático horizontal é minimizar o backlog e, ao mesmo tempo, maximizar a utilização e a capacidade de workers, além de permitir uma rápida reação a picos de carga.

O Dataflow considera vários fatores no escalonamento automático, incluindo:

  • Backlog. O tempo estimado do backlog é calculado com base na capacidade e nos bytes do backlog que ainda serão processados da origem de entrada. Um pipeline é considerado "com backlog" quando o tempo estimado do backlog permanece acima do limite configurado. Por padrão, esse limite é de 15 segundos. Para mais informações, consulte Definir o nível de latência.

  • Meta de uso da CPU. A meta padrão para o uso médio da CPU é 0,8. É possível substituir esse valor.

  • Chaves disponíveis. As chaves são a unidade fundamental de paralelismo no Dataflow.

Em alguns casos, o Dataflow usa os seguintes fatores nas decisões de escalonamento automático. Se esses fatores forem usados para seu job, será possível ver essas informações na guia de métricas Escalonamento automático.

  • A limitação baseada em chaves usa o número de chaves de processamento recebidas pelo job para calcular o limite de workers do usuário, já que cada chave só pode ser processada por um worker por vez.

  • Abrandamento de redução. Se o Dataflow detectar que houve decisões de escalonamento automático instáveis, ele diminuirá a taxa de redução para melhorar a estabilidade.

  • O aumento baseado em CPU usa a alta taxa de utilização da CPU como um critério de aumento.

  • Para jobs de streaming que não usam o Streaming Engine, o escalonamento pode ser restrito pelo número de discos permanentes. Para mais informações, consulte Definir o intervalo de escalonamento automático.

  • Escalonamento automático com uso intensivo de GPU, se ativado pela configuração da dica de paralelismo de worker. Para mais informações, consulte Heurísticas de escalonamento automático intensivo de GPU.

Upscaling. Se um pipeline de streaming permanecer atrasado com paralelismo suficiente nos workers por vários minutos, o Dataflow será escalonado verticalmente. O Dataflow tenta limpar o backlog em aproximadamente 150 segundos de escalonamento vertical, considerando a capacidade atual por worker. Se houver backlog, mas o worker não tiver paralelismo suficiente para workers adicionais, o pipeline não será escalonado verticalmente. Escalonar o número de workers além do número de chaves disponíveis para processamento paralelo não ajuda a processar o backlog mais rápido.

Redução de escalonamento Quando o escalonador automático toma uma decisão de redução, o backlog é o fator de prioridade mais alta. O escalonador automático visa um backlog com base no nível de latência. Se o backlog cair o suficiente abaixo da meta por vários minutos e a utilização média do worker estiver abaixo da meta de utilização da CPU, o Dataflow será reduzido. Enquanto o backlog for aceitável, o escalonador automático tentará manter a utilização da CPU próxima da utilização de destino da CPU. No entanto, se a utilização já estiver suficientemente próxima da meta, o escalonador automático poderá manter o número de workers inalterado, porque cada etapa de redução tem um custo.

O Streaming Engine também usa uma técnica de escalonamento automático preditivo com base no backlog do timer. Os dados ilimitados em um pipeline de streaming são divididos em janelas agrupadas por carimbos de data/hora. No final de uma janela, os timers são acionados para cada chave processada nessa janela. O acionamento de um timer indica que a janela expirou para uma determinada chave. O Streaming Engine pode medir o backlog do timer e prever quantos timers serão acionados ao final de uma janela. Usando o backlog do timer como um sinal, o Dataflow pode estimar a quantidade de processamento que precisa acontecer quando os próximos timers forem disparados. Com base na estimativa da carga futura, o Dataflow é escalonado automaticamente para atender à demanda esperada.

Métricas

Para encontrar os limites atuais de escalonamento automático de um job, consulte as seguintes métricas:

  • job/max_worker_instances_limit: número máximo de workers
  • job/min_worker_instances_limit: número mínimo de workers

Para ver informações sobre a utilização de workers, consulte as métricas a seguir:

  • job/aggregated_worker_utilization: o uso agregado do worker.
  • job/worker_utilization_hint: a dica atual de utilização do worker.

Para receber insights sobre o comportamento do escalonador automático, consulte a métrica a seguir:

  • job.worker_utilization_hint_is_actively_used: indica se o escalonador automático está usando ativamente a dica de utilização do worker. Se outros fatores substituirem a dica durante a amostragem, o valor será false.
  • job/horizontal_worker_scaling: descreve as decisões tomadas pelo escalonador automático. Essa métrica contém os seguintes rótulos:
    • direction: especifica se o escalonador automático realizou o escalonamento vertical ou horizontal ou se não realizou nenhuma ação.
    • rationale: especifica a lógica da decisão do escalonador automático.

Para mais informações, consulte métricas do Cloud Monitoring. Essas métricas também são exibidas nos gráficos de monitoramento de escalonamento automático.

A seguir