Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

EMRRésilience des Job sans serveur

EMRLes versions 7.1.0 et supérieures sans serveur incluent la prise en charge de la résilience des tâches, de sorte que toutes les tâches échouées sont automatiquement relancées sans aucune intervention manuelle de votre part. Un autre avantage de la résilience des tâches est que EMR Serverless déplace les cycles de travail vers une autre zone de disponibilité (AZ) en cas de problème avec une AZ.

Pour activer la résilience d'une tâche, définissez la politique de nouvelle tentative pour cette tâche. Une politique de nouvelle tentative garantit que EMR Serverless redémarre automatiquement une tâche en cas d'échec. Les politiques de nouvelle tentative sont prises en charge pour les tâches par lots et en streaming. Vous pouvez donc personnaliser la résilience des tâches en fonction de votre cas d'utilisation. Le tableau suivant compare les comportements et les différences de résilience des tâches entre les tâches par lots et les tâches de streaming.

Lorsque EMR Serverless tente de réexécuter une tâche, il indexe également la tâche avec un numéro de tentative, afin que vous puissiez suivre le cycle de vie d'une tâche au fil de ses tentatives.

Vous pouvez utiliser les API opérations EMR sans serveur ou AWS CLI pour modifier la résilience au travail ou consulter les informations relatives à la résilience au travail. Pour plus d'informations, consultez le APIguide EMR Serverless.

Par défaut, EMR Serverless ne réexécute pas les tâches par lots. Pour activer les nouvelles tentatives pour les tâches par lots, configurez le maxAttempts paramètre lorsque vous démarrez l'exécution d'une tâche par lots. Le maxAttempts paramètre s'applique uniquement aux tâches par lots. La valeur par défaut est 1, ce qui signifie qu'il ne faut pas réexécuter la tâche. Les valeurs acceptées sont comprises entre 1 et 10 inclus.

L'exemple suivant montre comment spécifier un nombre maximum de 10 tentatives lors du démarrage d'une tâche.

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 réessaie indéfiniment les tâches de streaming en cas d'échec. Pour éviter le thrash dû à des échecs irrécupérables répétés, utilisez le maxFailedAttemptsPerHour pour configurer le contrôle de prévention du thrash pour les nouvelles tentatives de travail en streaming. Ce paramètre vous permet de spécifier le nombre maximum de tentatives infructueuses autorisées une heure avant que EMR Serverless arrête de réessayer. La valeur par défaut est cinq. Les valeurs acceptées sont comprises entre 1 et 10 inclus.

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

Vous pouvez également utiliser les autres API opérations d'exécution de tâches pour obtenir des informations sur les tâches. Par exemple, vous pouvez utiliser le attempt paramètre avec l'GetJobRunopération pour obtenir des détails sur une tentative de travail spécifique. Si vous n'incluez pas le attempt paramètre, l'opération renvoie des informations sur la dernière tentative.

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

L'ListJobRunAttemptsopération renvoie des informations sur toutes les tentatives liées à l'exécution d'une tâche.

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

L'GetDashboardForJobRunopération crée et renvoie un fichier URL que vous pouvez utiliser pour accéder à l'application UIs pour exécuter une tâche. Le attempt paramètre vous permet d'obtenir un URL pour une tentative spécifique. Si vous n'incluez pas le attempt paramètre, l'opération renvoie des informations sur la dernière tentative.

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

Surveillance d'une tâche à l'aide d'une politique de relance

Le support de résilience des tâches ajoute également le nouvel événement EMRServerless job run retry. EMRServerless publie cet événement à chaque nouvelle tentative de la tâche. Vous pouvez utiliser cette notification pour suivre les nouvelles tentatives de la tâche. Pour plus d'informations sur les événements, consultez Amazon EventBridge events.

Connexion avec politique de nouvelle tentative

Chaque fois que EMR Serverless réessaie une tâche, la tentative génère son propre ensemble de journaux. Pour garantir que EMR Serverless puisse transmettre ces journaux à Amazon S3 et Amazon CloudWatch sans en remplacer aucun, EMR Serverless ajoute un préfixe au format du chemin du journal S3 et au nom du flux de CloudWatch journal pour inclure le numéro de tentative de la tâche.

Voici un exemple de ce à quoi ressemble le format.

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

Ce format garantit que EMR Serverless publie tous les journaux de chaque tentative de tâche vers son propre emplacement désigné dans Amazon S3 et CloudWatch. Pour plus de détails, consultez la section Stockage des journaux.