Práticas recomendadas e novas tentativas de jobs

Tarefas individuais ou até mesmo execuções de jobs podem falhar por vários motivos. Nesta página, você verá as práticas recomendadas para lidar com essas falhas, com base nas reinicializações da tarefa e na verificação de jobs.

Usar novas tentativas de tarefas

Tarefas individuais podem falhar por vários motivos, incluindo problemas com dependências de aplicativos, cotas ou até mesmo eventos internos do sistema. Muitas vezes, esses problemas são temporários, e a tarefa será concluída após uma nova tentativa.

Por padrão, cada tarefa é repetida automaticamente até três vezes. Isso ajuda a garantir que um job seja concluído mesmo que encontre falhas temporárias na tarefa. Também é possível personalizar o número máximo de novas tentativas. No entanto, se você mudar o padrão, especifique pelo menos uma nova tentativa.

Planejar as reinicializações das tarefas do job

Torne os jobs idempotentes para que a reinicialização de uma tarefa não resulte em resultados corrompidos ou duplicados. Ou seja, grave a lógica reproduzível que tem o mesmo comportamento para um determinado conjunto de entradas, não importa quantas vezes ela é repetida ou quando é executada.

Grave a saída em um local diferente dos dados de entrada, deixando os dados de entrada intactos. Dessa forma, se o job for executado novamente, ele poderá repetir o processo desde o início e conseguir o mesmo resultado.

Evite duplicar dados de saída reutilizando o mesmo identificador exclusivo ou verificando se a saída já existe. Os dados duplicados representam a corrupção de dados no nível da coleção.

Usar checkpoints

Sempre que possível, verifique seus jobs para que, se uma tarefa for reiniciada após uma falha, ela possa continuar de onde parou, em vez de reiniciar o trabalho no início. Isso acelera os jobs e minimiza os custos desnecessários.

Grave periodicamente resultados parciais e uma indicação de progresso feito em um local de armazenamento permanente, como o Cloud Storage ou um banco de dados. Quando a tarefa for iniciada, procure resultados parciais na inicialização. Se forem encontrados resultados parciais, comece a processar o ponto de onde parou.

Se o job não se aplicar a checkpoint, divida-o em pedaços menores e execute um número maior de tarefas.

Exemplo de ponto de controle 1: como calcular o Pi

Se você tiver um job que executa um algoritmo recursivo, como o cálculo de Pi para muitas casas decimais, e usa o paralelismo definido como um valor de 1:

  • Grave seu progresso a cada 10 minutos ou o que quer que a tolerância de trabalho perdida permita em um objeto pi-progress.txt do Cloud Storage.
  • Quando uma tarefa for iniciada, consulte o objeto pi-progress.txt e carregue o valor como um ponto de partida. Use esse valor como a entrada inicial para a função.
  • Grave o resultado final no Cloud Storage como um objeto chamado pi-complete.txt para evitar a duplicação por meio da execução paralela ou repetida ou pi-complete-DATE.txt para diferenciar por data de conclusão.

Exemplo de checkpoint 2: processamento de 10.000 registros do Cloud SQL

Se você tiver um job processando 10.000 registros em um banco de dados relacional,como o Cloud SQL:

  • Recuperar registros a serem processados com uma consulta SQL, como SELECT * FROM example_table LIMIT 10000.
  • Grave os registros atualizados em lotes de 100 para que não haja interrupção significativa do trabalho de processamento.
  • Quando os registros forem gravados, observe quais foram processados. Só é possível adicionar uma coluna booleana processada à tabela que é definida como 1 se o processamento for confirmado.
  • Quando uma tarefa é iniciada, a consulta usada para recuperar itens para processamento precisa adicionar a condição processada = 0.
  • Além de novas tentativas limpas, essa técnica também permite dividir o trabalho em tarefas menores, como modificar a consulta para selecionar 100 registros por vez: LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100 e executar 100 tarefas para processar os 10 mil. registros CLOUD_RUN_TASK_INDEX é uma variável de ambiente integrada presente no contêiner que executa jobs do Cloud Run.

Usando todas essas partes juntas, a consulta final pode ter esta aparência: SELECT * FROM example_table WHERE processed = 0 LIMIT 100 OFFSET $CLOUD_RUN_TASK_INDEX*100

A seguir