Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

EMRResiliencia laboral sin servidor

EMRLas versiones 7.1.0 y posteriores de Serverless incluyen compatibilidad con la resiliencia de los trabajos, por lo que reintenta automáticamente cualquier trabajo fallido sin necesidad de intervención manual por tu parte. Otra ventaja de la resiliencia laboral es que EMR Serverless traslada las ejecuciones de tareas a una zona de disponibilidad (AZ) diferente en caso de que una zona de disponibilidad experimente algún problema.

Para habilitar la resiliencia laboral de un trabajo, establezca la política de reintentos para su trabajo. Una política de reintentos garantiza que EMR Serverless reinicie automáticamente un trabajo en caso de que se produzca un error en algún momento. Las políticas de reintento se admiten tanto para los trabajos por lotes como para los de streaming, por lo que puede personalizar la resiliencia de los trabajos en función de su caso de uso. En la siguiente tabla se comparan los comportamientos y las diferencias en cuanto a la resiliencia de los trabajos en lotes y en streaming.

Cuando EMR Serverless intenta volver a ejecutar un trabajo, también indexa el trabajo con un número de intentos, para que pueda realizar un seguimiento del ciclo de vida de un trabajo en todos sus intentos.

Puede utilizar las operaciones EMR sin servidor API o las AWS CLI para cambiar la resiliencia laboral o ver información relacionada con la resiliencia laboral. Para obtener más información, consulte la guía EMRServerless API.

De forma predeterminada, EMR Serverless no vuelve a ejecutar los trabajos por lotes. Para habilitar los reintentos de los trabajos por lotes, configure el maxAttempts parámetro al iniciar la ejecución de un trabajo por lotes. El maxAttempts parámetro solo se aplica a los trabajos por lotes. El valor predeterminado es 1, lo que significa que no se debe volver a ejecutar el trabajo. Los valores aceptados son del 1 al 10, ambos inclusive.

El siguiente ejemplo muestra cómo especificar un número máximo de 10 intentos al iniciar la ejecución de un trabajo.

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"
     }
}'

EMRServerless vuelve a intentar transmitir los trabajos de streaming de forma indefinida si fallan. Para evitar que se produzcan errores repetidos e irrecuperables, utilice el control de prevención de atascos maxFailedAttemptsPerHour para los reintentos de tareas de streaming. Este parámetro le permite especificar el número máximo de intentos fallidos permitidos una hora antes de que Serverless deje de reintentarlo. EMR El valor predeterminado es cinco. Los valores aceptados son del 1 al 10, ambos 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"
     }
}'

También puede utilizar las demás API operaciones de ejecución de tareas para obtener información sobre las tareas. Por ejemplo, puede usar el attempt parámetro con la GetJobRun operación para obtener detalles sobre un intento de trabajo específico. Si no incluye el attempt parámetro, la operación devuelve información sobre el último intento.

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

La ListJobRunAttempts operación devuelve información sobre todos los intentos relacionados con la ejecución de un trabajo.

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

La GetDashboardForJobRun operación crea y devuelve un URL objeto que puede utilizar para acceder a la aplicación UIs y ejecutar un trabajo. El attempt parámetro le permite obtener un URL para un intento específico. Si no incluye el attempt parámetro, la operación devuelve información sobre el último intento.

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

Supervisión de un trabajo con una política de reintento

La compatibilidad con la resiliencia de los trabajos también añade el nuevo evento EMRServerless Job Run Retry. EMRServerless publica este evento en cada reintento del trabajo. Puede usar esta notificación para realizar un seguimiento de los reintentos del trabajo. Para obtener más información sobre los eventos, consulta Amazon EventBridge events.

Política de registro con reintentos

Cada vez que EMR Serverless vuelve a intentar un trabajo, el intento genera su propio conjunto de registros. Para garantizar que EMR Serverless pueda entregar correctamente estos registros a Amazon S3 y Amazon CloudWatch sin sobrescribir ninguno, EMR Serverless añade un prefijo al formato de la ruta de registro de S3 y al nombre del flujo de CloudWatch registro para incluir el número de intento del trabajo.

A continuación se muestra un ejemplo del aspecto del formato.

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

Este formato garantiza que EMR Serverless publique todos los registros de cada intento de trabajo en su propia ubicación designada en Amazon S3 y CloudWatch. Para obtener más información, consulte Almacenamiento de registros.