내용으로 건너뛰기

Amazon EMR에서 Spark 작업이 실패하는 이유는 무엇입니까?

6분 분량
0

Amazon EMR에서 실패한 Apache Spark 작업 문제를 해결하려고 합니다.

해결 방법

애플리케이션 장애

‘Spark shuffle block fetch’ 런타임 예외

Amazon EMR의 실행기 워커 노드가 비정상 상태인 경우 다음 오류를 받을 수 있습니다.

"ERROR ShuffleBlockFetcherIterator: Failed to get block(s) from ip-192-168-14-250.us-east-2.compute.internal:7337

org.apache.spark.network .client.ChunkFetchFailureException: Failure while fetching StreamChunkId[streamId=842490577174,chunkIndex=0]: java.lang.RuntimeException: Executor is not registered (appId=application_1622819239076_0367, execId=661)"

워커 노드의 디스크 사용률이 90% 사용률 임계값을 초과하면 YARN NodeManager 상태 서비스는 노드를 비정상으로 식별합니다. Amazon EMR은 거부 목록에 비정상 노드를 포함하고 YARN 컨테이너는 비정상 노드에 할당되지 않습니다.

이 오류를 해결하려면 다음 작업을 수행하십시오.

‘NoSuchElementException’ 런타임 예외

애플리케이션 코드 및 SparkContext 초기화에 문제가 있는 경우 다음과 같은 예외가 발생할 수 있습니다.

"ERROR [Executor task launch worker for task 631836] o.a.s.e.Executor:Exception in task 24.0 in stage 13028.0 (TID 631836) java.util.NoSuchElementException: None.get"

이 문제를 해결하려면 동일한 세션 내에 여러 SparkContext 작업이 활성화되어 있지 않은지 확인하십시오. 한 번에 하나의 SparkContext를 활성화할 수 있습니다. 다른 SparkContext를 초기화하려면 새 작업을 만들기 전에 활성 작업을 중지해야 합니다.

자세한 내용은 Spark 웹 사이트의 SparkContext를 참조하십시오.

‘Container exit code 137’ 오류

작업이 할당된 실제 메모리를 초과하면 YARN 컨테이너가 작업을 중지하고 다음 오류를 받습니다.

"Container killed on request. Exit code is 137"

셔플 파티션이 있거나 파티션 크기가 일치하지 않거나 실행기 코어 수가 많으면 이 오류를 받습니다.

Spark 드라이버 로그의 오류 세부 정보를 검토하여 오류의 원인을 확인하십시오. 자세한 내용은 Amazon EMR 클러스터에서 Spark 드라이버 로그에 액세스하려면 어떻게 해야 합니까?를 참조하십시오.

드라이버 로그의 예제 오류:

ERROR YarnScheduler: Lost executor 19 on ip-10-109-##-###.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-##-###.aws.com . Exit status: 137.Diagnostics:Container killed on request. Exit code is 137
Container exited with a non-zero exit code 137.
Killed by external signal
Executor container 'container_1658329343444_0018_01_000020' was killed with exit code 137. To understand the root cause, you can analyze executor container log.
# java.lang.OutOfMemoryError: Java heap space
# -XX:OnOutOfMemoryError="kill -9 %p"
# Executing /bin/sh -c "kill -9 23573"...

위의 오류 스택 추적은 실행기에 데이터를 계속 처리할 수 있는 사용 가능한 메모리가 충분하지 않음을 보여줍니다. 이 오류는 좁은 변환과 넓은 변환 모두의 다양한 작업 단계에서 발생할 수 있습니다.

이 문제를 해결하려면 다음 작업을 수행하십시오.

  • 실행기 메모리를 늘립니다.
    참고: 실행기 메모리에는 작업을 실행하는 데 필요한 메모리와 오버헤드 메모리가 포함됩니다. 이러한 메모리를 합한 값은 Java 가상 머신(JVM)의 크기와 YARN 최대 컨테이너 크기보다 크지 않아야 합니다.
  • Spark 파티션을 더 추가합니다.
  • 셔플 파티션 수를 늘립니다.
  • 실행기 코어 수를 줄입니다.

자세한 내용은 Amazon EMR에서 Spark의 ‘Container killed on request. Exit code is 137’ 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

Spark 작업이 멈춘 상태이며 완료되지 않음

Spark 작업은 여러 가지 이유로 멈출 수 있습니다. 예를 들어 Spark 드라이버 프로세스를 변경하거나 실행기 컨테이너가 손실되면 작업이 중단될 수 있습니다.

디스크 공간 사용률이 높거나 클러스터 노드에 스팟 인스턴스를 사용하고 AWS에서 스팟 인스턴스를 종료하는 경우, Spark 작업이 멈출 수 있습니다. 자세한 내용은 Amazon EMR에서 Spark의 ‘ExecutorLostFailure: Slave lost’ 오류를 해결하려면 어떻게 해야 합니까?)을 참조하십시오.

이 오류를 해결하려면 다음 작업을 수행하십시오.

  • Spark 드라이버 또는 드라이버 로그에서 예외를 검토합니다.
  • YARN 노드 목록에서 비정상 노드가 있는지 확인합니다. 디스크 사용률이 코어 노드의 임계값을 초과하면 YARN 노드 관리자 상태 서비스는 해당 노드를 비정상으로 표시합니다. Amazon EMR은 비정상 노드를 거부 목록에 추가하고 YARN이 해당 노드에 컨테이너를 할당하지 못하도록 합니다.
  • 디스크 공간 사용률을 모니터링하고 Amazon EMR 클러스터 워커 노드의 사용률을 90% 미만으로 유지하도록 Amazon Elastic Block Store(Amazon EBS) 볼륨을 구성합니다.

‘Heartbeat communication’ 오류

Spark 실행기는 spark.executor.heartbeatInterval 속성에 지정된 간격으로 Spark 드라이버에 하트비트 신호를 보냅니다. 폐영역 회수가 오랫동안 일시 중지되면 실행기가 하트비트 신호를 보내지 않을 수 있습니다. 드라이버는 지정된 값보다 많은 하트비트 신호를 보내지 못하는 실행기를 중지하고 다음과 같은 오류를 받습니다.

"WARN Executor: Issue communicating with driver in heartbeater org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10000 milliseconds]. This timeout is controlled by spark.executor.heartbeatInterval"

메모리 제약 또는 메모리 부족(OOM) 문제로 인해 실행기가 데이터를 처리할 때 시간 초과 예외가 발생합니다. 이러한 문제는 폐영역 회수 프로세스에도 영향을 미치며 추가 지연을 초래할 수 있습니다.

하트비트 통신 오류를 해결하려면 다음 옵션 중 하나를 사용하십시오.

  • 실행기 메모리를 늘립니다. 또한 애플리케이션 프로세스에 따라 데이터를 다시 분할합니다.
  • 폐영역 회수를 튜닝합니다. 자세한 내용은 Apache Spark 웹 사이트에서 폐영역 회수 튜닝을 참조하십시오.
  • spark.executor.heartbeatInterval의 간격을 늘립니다.
  • 더 긴 spark.network.timeout 기간을 지정합니다.

‘ExecutorLostFailure’ 오류

디스크 사용률이 높아 코어 또는 태스크 노드가 종료되면 다음 오류를 받을 수 있습니다.

"ExecutorLostFailure "Exit status: -100. Diagnostics: Container released on a *lost* node"

CPU 사용률이 오랫동안 높거나 사용 가능한 메모리가 부족하여 노드가 응답하지 않는 경우에도 위 오류를 받을 수 있습니다. 문제 해결 단계는 Amazon EMR에서 ‘Exit status: -100. Diagnostics: Container released on a lost node’ 오류를 해결하려면 어떻게 해야 합니까?를 참조하십시오.

참고: 이 오류는 클러스터 노드에 스팟 인스턴스를 사용하고 AWS에서 스팟 인스턴스를 종료하는 경우에도 발생할 수 있습니다. Amazon EMR 클러스터는 종료된 스팟 인스턴스를 대체할 온디맨드 인스턴스를 프로비저닝하며, 애플리케이션이 자체적으로 복구될 수 있습니다. 자세한 내용은 Amazon EMR의 탄력성 및 복원력을 위한 Spark 개선 사항을 참조하십시오.

‘SQL connection timeout’ 오류

네트워크 시간 초과로 인해 데이터베이스 연결 시도가 실패하면 다음 오류를 받습니다. 이 문제를 해결하려면 데이터베이스 호스트가 Amazon EMR 클러스터 보안 그룹에서 포트 1433을 통해 들어오는 연결을 수신할 수 있는지 확인하십시오.

또한 SQL 데이터베이스에 대해 구성된 최대 병렬 데이터베이스 연결 수와 데이터베이스 인스턴스 클래스의 메모리 할당을 검토하십시오. 데이터베이스 연결도 메모리를 사용합니다. 사용률이 높으면 데이터베이스 구성과 허용된 연결 수를 검토하십시오. 자세한 내용은 최대 데이터베이스 연결 수를 참조하십시오.

Amazon S3 예외

HTTP 503 ‘Slow Down’

HTTP 503 예외는 접두사에 대한 Amazon Simple Storage Service(Amazon S3) 요청 속도를 초과하면 발생합니다. 503 예외는 항상 장애가 발생할 수 있음을 의미하지는 않습니다. 그러나 예외를 해결하면 애플리케이션 성능이 향상될 수 있습니다.

자세한 내용은 Amazon EMR에서 Spark 또는 Hive 작업이 HTTP 503 ‘Slow Down’ AmazonS3Exception으로 실패하는 이유는 무엇입니까?를 참조하십시오.

HTTP 403 ‘Access Denied’

HTTP 403 오류는 다음 자격 증명을 비롯하여 올바르지 않거나 잘못된 자격 증명으로 인해 발생합니다.

  • 애플리케이션 코드에 지정하지 않은 자격 증명 또는 역할
  • Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 프로파일 역할에 연결된 정책
  • Amazon S3용 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트
  • Amazon S3 소스 및 대상 버킷 정책

403 오류를 해결하려면 관련 AWS Identity and Access Management(IAM) 역할 또는 정책이 Amazon S3에 대한 액세스를 허용하는지 확인하십시오. 자세한 내용은 Amazon EMR 애플리케이션이 HTTP 403 ‘Access Denied’ AmazonS3Exception으로 실패하는 이유는 무엇입니까?를 참조하십시오.

HTTP 404 ‘Not Found’

애플리케이션이 Amazon S3에서 객체를 찾을 것으로 예상하지만 요청 시점에 객체를 찾지 못한 경우 ‘HTTP 404 Not found’ 오류를 받습니다.

이 오류는 다음과 같은 이유로 인해 발생할 수 있습니다.

  • Amazon S3 경로가 잘못되었습니다.
  • 애플리케이션 외부 프로세스에서 파일을 이동 또는 삭제했습니다.
  • 작업으로 인해 덮어쓰기와 같은 궁극적인 일관성 문제가 발생했습니다.

자세한 내용은 Amazon EMR 애플리케이션이 HTTP 404 ‘Not Found’ AmazonS3Exception으로 실패하는 이유는 무엇입니까?를 참조하십시오.

AWS 공식업데이트됨 7달 전