Estratégias de nova tentativa de emprego no serviço em AWS Batch - AWS Batch

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Estratégias de nova tentativa de emprego no serviço em AWS Batch

As estratégias de repetição de tarefas de serviço AWS Batch permitem repetir automaticamente tarefas de serviço com falha sob condições específicas.

Os trabalhos de serviço podem exigir várias tentativas por vários motivos:

  • Problemas temporários de serviço: erros internos de serviço, limitação ou interrupções temporárias podem fazer com que os trabalhos falhem durante o envio ou a execução.

  • Falhas na inicialização do treinamento: problemas durante a inicialização do trabalho, como problemas de extração de imagens ou erros de inicialização, podem ser resolvidos na nova tentativa.

Ao configurar estratégias de repetição apropriadas, você pode melhorar as taxas de sucesso no trabalho e reduzir a necessidade de intervenção manual, especialmente para cargas de trabalho de treinamento de longa duração.

nota

Os trabalhos de serviço repetem automaticamente certos tipos de falhas, como erros de capacidade insuficiente, sem consumir suas tentativas de repetição configuradas. Sua estratégia de repetição lida principalmente com outros tipos de falhas, como erros de algoritmo ou problemas de serviço.

Configurando estratégias de repetição

As estratégias de repetição de tarefas de serviço são configuradas usando ServiceJobRetryStrategy, que suporta contagens simples de repetições e lógica de repetição condicional.

Configuração de repetição

A estratégia de repetição mais simples especifica o número de tentativas que devem ser feitas se uma tarefa de serviço falhar:

{ "retryStrategy": { "attempts": 3 } }

Essa configuração permite que a tarefa de serviço seja repetida até 3 vezes se falhar.

Importante

O attempts valor representa o número total de vezes que o trabalho pode ser colocado no RUNNABLE estado, incluindo a tentativa inicial. Um valor de 3 significa que o trabalho será tentado uma vez inicialmente e, em seguida, repetido até 2 vezes adicionais se falhar.

Repita a configuração com evaluateOnExit

Você pode usar o evaluateOnExit parâmetro para especificar as condições sob as quais os trabalhos devem ser repetidos ou podem falhar. Isso é útil quando diferentes tipos de falhas exigem tratamento diferente.

A evaluateOnExit matriz pode conter até 5 estratégias de repetição, cada uma especificando uma ação (RETRYouEXIT) e condições com base nos motivos do status:

{ "retryStrategy": { "attempts": 5, "evaluateOnExit": [ { "action": "RETRY", "onStatusReason": "Received status from SageMaker: InternalServerError*" }, { "action": "EXIT", "onStatusReason": "Received status from SageMaker: ValidationException*" }, { "action": "EXIT", "onStatusReason": "*" } ] } }

Essa configuração:

  • Tenta novamente trabalhos que falham devido a erros internos do servidor de SageMaker IA

  • Falha imediatamente em trabalhos que encontram exceções de validação (erros do cliente que não serão resolvidos por meio de uma nova tentativa)

  • Inclui uma regra abrangente para sair de qualquer outro tipo de falha

Correspondência de padrões de motivo de

O onStatusReason parâmetro suporta correspondência de padrões com até 512 caracteres. Os padrões podem usar curingas (*) e corresponder aos motivos de status retornados pela SageMaker IA.

Para trabalhos de serviço, as mensagens de status da SageMaker IA são prefixadas com “Status recebido de SageMaker:” para diferenciá-las das mensagens AWS Batch geradas. Os padrões comuns incluem:

  • Received status from SageMaker: InternalServerError*- Combine erros internos de serviço

  • Received status from SageMaker: ValidationException*- Combine erros de validação do cliente

  • Received status from SageMaker: ResourceLimitExceeded*- Combine erros de limite de recursos

  • *CapacityError*- Combine falhas relacionadas à capacidade

dica

Use a correspondência de padrões específicos para lidar com diferentes tipos de erro de forma adequada. Por exemplo, repita os erros internos do servidor, mas falhe imediatamente nos erros de validação que indicam problemas com os parâmetros do trabalho.