기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

EMR Serverless 작업 복원력

EMR Serverless 릴리스 7.1.0 이상에는 작업 복원력에 대한 지원이 포함되어 있으므로 수동으로 입력하지 않고도 실패한 작업을 자동으로 재시도합니다. 작업 복원력의 또 다른 이점은 AZ에 문제가 발생할 경우 EMR Serverless가 작업 실행을 다른 가용 영역(AZ)으로 이동한다는 점입니다.

작업에 대한 작업 복원력을 활성화하려면 작업에 대한 재시도 정책을 설정합니다. 재시도 정책은 언제라도 실패하면 EMR Serverless에서 작업을 자동으로 재시작하도록 보장합니다. 배치 작업 및 스트리밍 작업 모두에 대해 재시도 정책이 지원되므로 사용 사례에 따라 작업 복원력을 사용자 지정할 수 있습니다. 다음 표에서는 배치 및 스트리밍 작업 간 작업 복원력의 동작과 차이를 비교합니다.

EMR Serverless에서 작업을 재실행하려고 하면 시도 번호로 작업을 인덱싱하므로 시도 전반에 걸쳐 작업의 수명 주기를 추적할 수 있습니다.

EMR Serverless API 작업 또는 AWS CLI 를 사용하여 작업 복원력을 변경하거나 작업 복원력과 관련된 정보를 볼 수 있습니다. 자세한 내용은 EMR Serverless API 안내서를 참조하세요.

기본적으로 EMR Serverless는 배치 작업을 재실행하지 않습니다. 배치 작업에 대한 재시도를 활성화하려면 배치 작업 실행을 시작할 때 maxAttempts 파라미터를 구성합니다. maxAttempts 파라미터는 배치 작업에만 적용됩니다. 기본값은 1입니다. 작업을 다시 실행하지 않음을 의미합니다. 허용되는 값은 1~10(경계 포함)입니다.

다음 예제에서는 작업 실행을 시작할 때 최대 10회의 시도 횟수를 지정하는 방법을 보여줍니다.

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

EMR Serverless는 스트리밍 작업이 실패할 경우 스트리밍 작업을 제한 없이 재시도합니다. 복구할 수 없는 반복 장애로 인한 스래싱을 방지하려면 maxFailedAttemptsPerHour를 사용하여 스트리밍 작업 재시도에 대한 스래시 방지 제어를 구성합니다. 이 파라미터를 사용하면 EMR Serverless에서 재시도를 중지하기 1시간 전에 허용되는 최대 실패 시도 횟수를 지정할 수 있습니다. 기본값은 5입니다. 허용되는 값은 1~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"
     }
}'

또한 다른 작업 실행 API 작업을 사용하여 작업에 대한 정보를 얻을 수도 있습니다. 예를 들어 GetJobRun 작업과 함께 attempt 파라미터를 사용하여 특정 작업 시도에 대한 세부 정보를 가져올 수 있습니다. attempt 파라미터를 포함하지 않는 경우 작업은 최신 시도에 대한 정보를 반환합니다.

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

ListJobRunAttempts 작업은 작업 실행과 관련된 모든 시도에 대한 정보를 반환합니다.

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

GetDashboardForJobRun 작업은 작업 실행을 위해 애플리케이션 UI에 액세스하는 데 사용할 수 있는 URL을 생성하고 반환합니다. attempt 파라미터를 사용하면 특정 시도에 대한 URL을 가져올 수 있습니다. attempt 파라미터를 포함하지 않는 경우 작업은 최신 시도에 대한 정보를 반환합니다.

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

재시도 정책으로 작업 모니터링

또한 작업 복원력 지원에는 새 이벤트 EMR Serverless 작업 실행 재시도가 추가되었습니다. EMR Serverless는 작업을 재시도할 때마다 이 이벤트를 게시합니다. 이 알림을 사용하여 작업 재시도를 추적할 수 있습니다. 이벤트에 자세한 내용은 Amazon EventBridge events를 참조하세요.

재시도 정책을 사용한 로깅

EMR Serverless가 작업을 재시도할 때마다 자체 로그 세트가 생성됩니다. EMR Serverless가 덮어쓰지 않고 이러한 로그를 Amazon S3 및 Amazon CloudWatch에 전달할 수 있도록 하기 위해 EMR Serverless는 S3 로그 경로 및 CloudWatch 로그 스트림 이름의 형식에 작업의 시도 번호를 포함하도록 접두사를 추가합니다.

다음은 해당 형식에 대한 예제입니다.

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

이 형식을 사용하면 EMR Serverless가 각 작업 시도에 대한 모든 로그를 Amazon S3 및 CloudWatch의 지정된 위치에 게시할 수 있습니다. 자세한 내용은 로그 저장을 참조하세요.