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

Resiliência de trabalhos no EMR Sem Servidor

As versões 7.1.0 e posteriores do EMR Sem Servidor 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 de trabalhos é que o EMR Sem Servidor transfere as execuções de trabalhos para uma zona de disponibilidade (AZ) diferente, caso uma AZ tenha algum problema.

Para habilitar a resiliência de um trabalho, defina a política de repetição para ele. Uma política de repetição garante que o EMR Sem Servidor 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 de trabalhos em lote e de streaming.

Quando o EMR Sem Servidor 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 operações da API do EMR Sem Servidor ou a AWS CLI para alterar a resiliência do trabalho ou consultar informações relacionadas a isso. Para obter mais informações, consulte o Guia da API do EMR Sem Servidor.

Por padrão, o EMR Sem Servidor não executa novamente trabalhos em lotes. Para habilitar novas tentativas de trabalhos em lotes, configure o parâmetro maxAttempts ao iniciar a execução de um trabalho em lote. O parâmetro maxAttempts é 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 uma execução de 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"
     }
}'

O EMR Sem Servidor repete indefinidamente os trabalhos de streaming se eles falharem. Para evitar thrashing devido a falhas irrecuperáveis repetidas, use maxFailedAttemptsPerHour para configurar o controle de prevenção contra thrash em novas tentativas de trabalhos de streaming. Esse parâmetro permite especificar o número máximo de tentativas malsucedidas permitidas até uma hora antes que o EMR Sem Servidor 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 operações da API de execução de trabalhos para obter informações sobre trabalhos. Por exemplo, você pode usar o parâmetro attempt com a operação GetJobRun para obter detalhes sobre uma tentativa de trabalho específica. Se você não incluir o parâmetro attempt, 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 operação ListJobRunAttempts 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 operação GetDashboardForJobRun cria e retorna um URL que você pode usar para acessar as interfaces de usuário da aplicação para uma execução de trabalho. O parâmetro attempt permite obter um URL para uma tentativa específica. Se você não incluir o parâmetro attempt, 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 trabalhos também adiciona o novo evento Nova tentativa de execução de trabalho do EMR Sem Servidor. O EMR Sem servidor 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 Amazon EventBridge events.

Logs com política de nova tentativa

Toda vez que o EMR Sem Servidor repete um trabalho, a tentativa gera seu próprio conjunto de logs. Para garantir que o EMR Sem Servidor possa entregar com êxito esses logs ao Amazon S3 e ao Amazon CloudWatch sem sobrescrever nenhum, o EMR Sem servidor adiciona um prefixo ao formato do caminho do log do S3 e ao nome do fluxo de logs do CloudWatch para incluir o número da tentativa do trabalho.

Confira a seguir um exemplo de como é o formato.

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

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