Amazon EMR에서 Spark 작업이 실패한 이유는 무엇인가요?

6분 분량
0

Amazon EMR에서 Apache Spark 작업이 실패했습니다.

해결 방법

애플리케이션 장애

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)

이 문제는 Amazon EMR의 실행기 워커 노드가 비정상 상태일 때 발생할 수 있습니다. 워커 노드의 디스크 사용률이 90%의l 사용률 임계값을 초과하면 YARN NodeManager 상태 서비스에서 해당 노드를 비정상으로 보고합니다. 비정상 노드는 Amazon EMR 거부 목록에 포함됩니다. 또한 YARN 컨테이너는 해당 노드에 할당되지 않습니다.

이 오류를 해결하려면 다음을 수행합니다.

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 작업이 여러 개 활성화되어 있지 않은지 확인하세요. Java 가상 머신(JVM)에 따르면, 한 번에 하나의 SparkContext를 활성화할 수 있습니다. 또 다른 SparkContext를 초기화하려면 새 작업을 생성하기 전에 활성 작업을 중지해야 합니다.

Container killed on request. Exit code is 137

이 예외는 YARN 컨테이너의 작업이 해당 컨테이너에 할당된 실제 메모리를 초과할 때 발생합니다. 이는 일반적으로 셔플 파티션이 있거나, 파티션 크기가 일치하지 않거나, 실행기 코어가 많을 때 발생합니다.

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

다음은 드라이버 로그의 오류 예제입니다.

ERROR YarnScheduler: Lost executor 19 on ip-10-109-xx-xxx.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-xx-xxx.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"...

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

이를 해결하려면 다음 중 하나를 수행합니다.

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

자세한 내용은 Amazon EMR에서 Spark의 “Container killed on request. Exit code is 137” 문제를 해결하려면 어떻게 해야 하나요?를 참조하세요.

Spark 작업이 중단된 상태이며 완료되지 않고 있습니다.

Spark 작업은 여러 가지 이유로 중단될 수 있습니다. 예를 들어 Spark 드라이버(애플리케이션 마스터) 프로세스가 영향을 받거나 실행기 컨테이너가 손실되는 경우에 작업이 중단됩니다.

이는 일반적으로 디스크 공간 사용률이 높거나, 클러스터 노드에 스팟 인스턴스를 사용하고 스팟 인스턴스가 종료될 때 발생합니다. 자세한 내용은 Amazon EMR에서 Spark의 ExecutorLostFailure "Slave lost" 오류를 해결하려면 어떻게 해야 하나요?를 참조하세요.

이 오류를 해결하려면 다음을 수행합니다.

  • Spark 애플리케이션 마스터 또는 드라이버 로그에 예외가 있는지 검토합니다.
  • YARN 노드 목록에 비정상 노드가 있는지 확인합니다. 코어 노드의 디스크 사용률이 사용률 임계값을 초과하면 YARN Node Manager 상태 서비스에서 해당 노드를 비정상으로 보고합니다. 비정상 노드는 Amazon EMR 거부 목록에 포함됩니다. 또한 YARN 컨테이너는 해당 노드에 할당되지 않습니다.
  • 디스크 공간 사용률을 모니터링하고 Amazon Elastic Block Store(Amazon EBS) 볼륨을 구성하여 EMR 클러스터 워커 노드의 사용률을 90% 미만으로 유지합니다.

WARN Executor: Issue communicating with driver in heartbeater org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10000 milliseconds]. 이 타임아웃은 spark.executor.heartbeatInterval에서 제어합니다.

스파크 실행기는 spark.executor.heartbeatInterval 속성에 지정된 간격으로 Spark 드라이버에 하트비트 신호를 보냅니다. 가비지 수집이 오랫동안 중지되면 실행기가 하트비트 신호를 보내지 않을 수 있습니다. 드라이버는 지정된 값보다 큰 하트비트 신호를 보내지 못하는 실행기를 종료합니다.

TimeoutException

시간 초과 예외는 실행기에 메모리 제약이 있거나 데이터를 처리하는 동안 OOM 문제가 발생할 때 생깁니다. 이는 가비지 수집 프로세스에도 영향을 주어 추가 지연을 야기합니다.

다음 방법 중 하나를 사용하여 하트비트 시간 초과 오류를 해결합니다.

  • 실행기 메모리를 늘립니다. 또한 애플리케이션 프로세스에 따라 데이터를 다시 분할합니다.
  • 가비지 수집을 조정합니다.
  • spark.executor.heartbeatInterval의 간격을 늘립니다.
  • 더 긴 spark.network.timeout.period를 지정합니다.

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

이 오류는 디스크 공간 사용률이 높아 코어 또는 태스크 노드가 종료되는 경우 발행합니다. CPU 사용률이 높거나 가용 메모리가 부족하여 노드가 응답하지 않는 경우에도 이 오류가 발생합니다. 문제 해결 단계는 “Exit status: -100. Diagnostics: Amazon EMR에서 Diagnostics: Container released on a *lost* node" 오류를 해결하려면 어떻게 해야 하나요?를 참조하세요.

참고: 이 오류는 클러스터 노드에 스팟 인스턴스를 사용하고 스팟 인스턴스가 종료되는 경우에도 발생할 수 있습니다. 이 시나리오에서 EMR 클러스터는 종료된 스팟 인스턴스를 대체할 온디맨드 인스턴스를 프로비저닝합니다. 즉, 애플리케이션이 자체적으로 복구될 수도 있다는 의미입니다. 자세한 내용은 Spark enhancements for elasticity and resiliency on Amazon EMR(Amazon EMR의 탄력성과 복원력을 위한 Spark 개선 사항)을 참조하세요.

executor 38: java.sql.SQLException (Network error IOException: Connection timed out (Connection timed out)

이 문제는 데이터를 읽거나 쓸 때 소켓 연결을 설정하기 위한 SQL 데이터베이스와의 통신과 관련이 있습니다. DB 호스트가 포트 1433을 통해 EMR 클러스터 보안 그룹으로부터 들어오는 연결을 수신할 수 있는 상태인지 확인합니다.

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

아마존 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 EC2 인스턴스 프로파일 역할에 연결된 정책
  • Amazon S3에 대한 Amazon Virtual Private Cloud(Amazon VPC) 엔드포인트
  • S3 원본 및 대상 버킷 정책

403 오류를 해결하려면 관련 AWS Identity and Access Management(IAM) 역할 또는 정책이 Amazon S3에 대한 액세스를 허용하는지 확인합니다. 자세한 내용은 Amazon EMR 애플리케이션이 실패하고 HTTP 403 “Access Denied” AmazonS3Exception 오류가 발생하는 이유가 무엇인가요?를 참조하세요.

HTTP 404 "Not Found"

HTTP 404 오류는 애플리케이션이 S3에서 객체를 찾을 것으로 예상했지만, 요청 당시 객체를 찾을 수 없었음을 나타냅니다. 일반적인 원인은 다음과 같습니다.

  • 잘못된 S3 경로(예: 잘못 입력된 경로)
  • 파일이 애플리케이션 외부의 프로세스에 의해 이동 또는 삭제된 경우
  • 덮어쓰기와 같이 궁극적으로 일관성 문제를 일으킨 작업이 수행된 경우

자세한 내용은 HTTP 404 "Not Found" AmazonS3Exception으로 Amazon EMR 애플리케이션이 실패하는 이유가 무엇인가요?를 참조하세요.


AWS 공식
AWS 공식업데이트됨 일 년 전