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

EMRResiliência de trabalho sem servidor

EMRAs versões 7.1.0 e posteriores do Serverless incluem suporte à resiliência do trabalho, portanto, ele repete automaticamente qualquer trabalho com falha sem sua intervenção manual. Outro benefício da resiliência do trabalho é que o EMR Serverless transfere as execuções de tarefas para uma zona de disponibilidade (AZ) diferente, caso uma AZ tenha algum problema.

Para ativar a resiliência de um trabalho, defina a política de repetição para seu trabalho. Uma política de repetição garante que o EMR Serverless reinicie automaticamente um trabalho se ele falhar em algum momento. As políticas de repetição são compatíveis com trabalhos em lote e de streaming, para que você possa personalizar a resiliência do trabalho de acordo com seu caso de uso. A tabela a seguir compara os comportamentos e as diferenças da resiliência do trabalho em trabalhos em lote e de streaming.

Quando o EMR Serverless tenta executar novamente um trabalho, ele também indexa o trabalho com um número de tentativas, para que você possa acompanhar o ciclo de vida de um trabalho em todas as tentativas.

Você pode usar as API operações EMR sem servidor ou o AWS CLI para mudar a resiliência do trabalho ou ver informações relacionadas à resiliência do trabalho. Para obter mais informações, consulte o guia EMRServerless API.

Por padrão, o EMR Serverless não executa novamente trabalhos em lote. Para habilitar novas tentativas para trabalhos em lotes, configure o maxAttempts parâmetro ao iniciar a execução de um trabalho em lotes. O maxAttempts parâmetro é aplicável somente a trabalhos em lotes. O padrão é 1, o que significa não executar o trabalho novamente. Os valores aceitos são de 1 a 10, inclusive.

O exemplo a seguir demonstra como especificar um número máximo de 10 tentativas ao iniciar a execução de um trabalho.

aws emr-serverless start-job-run
 --application-id <APPLICATION_ID> \
 --execution-role-arn <JOB_EXECUTION_ROLE> \
 --mode 'BATCH' \
 --retry-policy '{
    "maxAttempts": 10
 }' \
 --job-driver '{
    "sparkSubmit": {
         "entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
         "entryPointArguments": ["1"],
         "sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
     }
}'

EMRO Serverless repete indefinidamente os trabalhos de streaming se eles falharem. Para evitar problemas devido a falhas irrecuperáveis repetidas, use o maxFailedAttemptsPerHour para configurar o controle de prevenção de problemas para novas tentativas de tarefas de streaming. Esse parâmetro permite especificar o número máximo de tentativas malsucedidas permitidas até uma hora antes que o EMR Serverless pare de tentar novamente. O padrão é cinco. Os valores aceitos são de 1 a 10, inclusive.

aws emr-serverless start-job-run
 --application-id <APPPLICATION_ID> \
 --execution-role-arn <JOB_EXECUTION_ROLE> \
 --mode 'STREAMING' \
 --retry-policy '{
    "maxFailedAttemptsPerHour": 7
 }' \
 --job-driver '{
    "sparkSubmit": {
         "entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
         "entryPointArguments": ["1"],
         "sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
     }
}'

Você também pode usar as outras API operações de execução de trabalhos para obter informações sobre trabalhos. Por exemplo, você pode usar o attempt parâmetro com a GetJobRun operação para obter detalhes sobre uma tentativa de trabalho específica. Se você não incluir o attempt parâmetro, a operação retornará informações sobre a última tentativa.

aws emr-serverless get-job-run \
    --job-run-id job-run-id \
    --application-id application-id \
    --attempt 1

A ListJobRunAttempts operação retorna informações sobre todas as tentativas relacionadas à execução de um trabalho.

aws emr-serverless list-job-run-attempts \
  --application-id application-id \
  --job-run-id job-run-id

A GetDashboardForJobRun operação cria e retorna um URL que você pode usar para acessar o aplicativo UIs para a execução de um trabalho. O attempt parâmetro permite que você obtenha um URL para uma tentativa específica. Se você não incluir o attempt parâmetro, a operação retornará informações sobre a última tentativa.

aws emr-serverless get-dashboard-for-job-run \
    --application-id application-id \
    --job-run-id job-run-id \
    --attempt 1

Monitoramento de um trabalho com uma política de repetição

O suporte à resiliência de tarefas também adiciona o novo evento EMRServerless job run retry. EMRO Serverless publica esse evento em cada nova tentativa do trabalho. Você pode usar essa notificação para rastrear novas tentativas do trabalho. Para obter mais informações sobre eventos, consulte EventBridge Eventos da Amazon.

Registro com política de repetição

Toda vez que o EMR Serverless tenta novamente um trabalho, a tentativa gera seu próprio conjunto de registros. Para garantir que o EMR Serverless possa entregar com sucesso esses registros para o Amazon S3 e a CloudWatch Amazon sem sobrescrever EMR nenhum, o Serverless adiciona um prefixo ao formato do CloudWatch caminho de log do S3 e do nome do stream de log para incluir o número da tentativa do trabalho.

Veja a seguir um exemplo da aparência do formato.

'/applications/<applicationId>/jobs/<jobId>/attempts/<attemptNumber>/'.

Esse formato garante que o EMR Serverless publique todos os registros de cada tentativa do trabalho em seu próprio local designado no Amazon S3 e. CloudWatch Para obter mais detalhes, consulte Armazenamento de registros.