Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

EMRResilienza di Job serverless

EMRLe versioni Serverless 7.1.0 e successive includono il supporto per la resilienza dei job, in modo da riprovare automaticamente tutti i job non riusciti senza alcun intervento manuale da parte dell'utente. Un altro vantaggio della resilienza dei processi è che EMR Serverless sposta i job run in diverse zone di disponibilità (AZ) in caso di problemi in un'AZ.

Per abilitare la resilienza dei job, imposta la policy di riprova per il tuo job. Una politica di riprova assicura che EMR Serverless riavvii automaticamente un processo in caso di errore in qualsiasi momento. Le politiche di riprova sono supportate sia per i processi in batch che per quelli in streaming, quindi puoi personalizzare la resilienza dei processi in base al tuo caso d'uso. La tabella seguente confronta i comportamenti e le differenze di resilienza dei processi tra processi in batch e in streaming.

Quando EMR Serverless tenta di rieseguire un processo, lo indicizza anche con un numero di tentativo, in modo da poter tenere traccia del ciclo di vita di un processo in tutti i suoi tentativi.

È possibile utilizzare le operazioni Serverless o EMR API AWS CLI per modificare la resilienza del lavoro o visualizzare le informazioni relative alla resilienza del lavoro. Per ulteriori informazioni, consulta la guida EMRServerless API.

Per impostazione predefinita, EMR Serverless non esegue nuovamente i processi batch. Per abilitare i nuovi tentativi per i processi batch, configura il maxAttempts parametro quando si avvia l'esecuzione di un processo batch. Il maxAttempts parametro è applicabile solo ai processi batch. L'impostazione predefinita è 1, il che significa che non viene eseguito nuovamente il processo. I valori accettati sono compresi tra 1 e 10.

L'esempio seguente mostra come specificare un numero massimo di 10 tentativi all'avvio di un job run.

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 riprova a tempo indeterminato i processi di streaming se falliscono. Per evitare che si verifichino problemi dovuti a errori ripetuti e irrecuperabili, utilizzate il controllo di prevenzione delle interruzioni maxFailedAttemptsPerHour per lo streaming di nuovi tentativi di lavoro. Questo parametro consente di specificare il numero massimo di tentativi falliti consentiti entro un'ora prima che Serverless interrompa i nuovi tentativi. EMR L'impostazione predefinita è cinque. I valori accettati sono compresi tra 1 e 10.

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

È inoltre possibile utilizzare le altre API operazioni di esecuzione dei lavori per ottenere informazioni sui lavori. Ad esempio, è possibile utilizzare il attempt parametro con l'GetJobRunoperazione per ottenere dettagli su uno specifico tentativo di lavoro. Se non si include il attempt parametro, l'operazione restituisce informazioni sull'ultimo tentativo.

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

L'ListJobRunAttemptsoperazione restituisce informazioni su tutti i tentativi relativi all'esecuzione di un processo.

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

L'GetDashboardForJobRunoperazione crea e restituisce un URL file che è possibile utilizzare per accedere all'applicazione UIs per l'esecuzione di un processo. Il attempt parametro consente di ottenere un valore URL per un tentativo specifico. Se non si include il attempt parametro, l'operazione restituisce informazioni sull'ultimo tentativo.

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

Monitoraggio di un processo con una policy di ripetizione

Il supporto per la resilienza dei lavori aggiunge anche il nuovo evento EMRServerless job run retry. EMRServerless pubblica questo evento a ogni nuovo tentativo del processo. È possibile utilizzare questa notifica per tenere traccia dei nuovi tentativi di lavoro. Per ulteriori informazioni sugli eventi, consulta Amazon EventBridge events.

Registrazione con politica di riprova

Ogni volta che EMR Serverless riprova un processo, il tentativo genera il proprio set di log. Per garantire che EMR Serverless possa inviare correttamente questi log ad Amazon S3 e CloudWatch Amazon senza EMR sovrascriverli, Serverless aggiunge un prefisso al formato del CloudWatch percorso e del nome del flusso di log di S3 per includere il numero del tentativo del processo.

Di seguito è riportato un esempio di come si presenta il formato.

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

Questo formato garantisce che EMR Serverless pubblichi tutti i log per ogni tentativo di lavoro nella propria posizione designata in Amazon S3 e. CloudWatch Per maggiori dettagli, consulta Archiviazione dei log.