Amazon EMR에서 Spark의 ExecutorLostFailure "Slave lost" 오류를 해결하려면 어떻게 해야 합니까?

4분 분량
0

Apache Spark 애플리케이션을 Amazon EMR 클러스터에 제출했습니다. 다음 오류로 인해 애플리케이션이 실패합니다. "Most recent failure: Lost task 1209.0 in stage 4.0 (TID 31219, ip-xxx-xxx-xx-xxx.compute.internal, executor 115): ExecutorLostFailure (executor 115 exited caused by one of the running tasks) Reason: Slave lost"

간략한 설명

이 오류는 노드가 종료되거나 사용할 수 없게 되어 Spark 작업이 실패했음을 나타냅니다. 이 오류의 원인은 다양합니다. 다음 해결 방법은 일반적인 근본 원인을 설명합니다.

  • 높은 디스크 사용률
  • 클러스터 노드에 스팟 인스턴스 사용
  • 지나치게 엄격한 Amazon EC2(Amazon Elastic Compute Cloud) Auto Scaling 정책

해결 방법

높은 디스크 사용률

Hadoop에서 NodeManager는 클러스터의 노드에 연결된 Amazon Elastic Block Store(Amazon EBS) 볼륨을 주기적으로 확인합니다. 한 개의 볼륨이 연결된 노드의 디스크 사용률이 YARN 속성 yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage(기본값은 90%)를 초과하는 경우, 노드는 비정상으로 간주됩니다. 노드가 비정상이면 ResourceManager는 해당 노드에서 실행 중인 모든 컨테이너가 종료됩니다. ResourceManager는 비정상 노드에서 새 컨테이너를 예약하지 않습니다. 자세한 내용은 하둡 설명서의 NodeManager를 참조하세요.

ResourceManager가 비정상 노드로 인해 여러 실행 프로그램을 종료하면 애플리케이션이 "slave lost" 오류와 함께 실패합니다. 노드가 비정상인지 확인하려면 NodeManager 로그 또는 인스턴스 컨트롤러 로그를 검토하세요.

  • NodeManager 로그의 위치는 yarn-env.shYARN_LOG_DIR 변수에 정의되어 있습니다.
  • 인스턴스 컨트롤러 로그는 마스터 노드의 /emr/instance-controller/log/instance-controller.log에 저장됩니다. 인스턴스 컨트롤러 로그는 클러스터의 모든 노드에 대한 집계 보기를 제공합니다.

노드가 비정상인 경우 로그에 다음과 같은 항목이 표시됩니다.

2019-10-04 11:09:37,163 INFO Poller: InstanceJointStatusMap contains 40 entries (R:40):
  i-006baxxxxxx  1829s R   1817s ig-3B ip-xxx-xx-xx-xxx I:    7s Y:U    11s c: 0 am:    0 H:R  0.0%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers
  i-00979xxxxxx  1828s R   1817s ig-3B ip-xxx-xx-xx-xxx I:    7s Y:R     9s c: 3 am: 2048 H:R  0.0%
  i-016c4xxxxxx  1834s R   1817s ig-3B ip-xxx-xx-xx-xxx I:   13s Y:R    14s c: 3 am: 2048 H:R  0.0%
  i-01be3xxxxxx  1832s R   1817s ig-3B ip-xxx-xx-xx-xxx I:   10s Y:U    12s c: 0 am:    0 H:R  0.0%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers

이 문제를 해결하려면 코어 및 작업 노드에 연결된 EBS 볼륨의 크기를 늘립니다. 또는 HDFS에서 미사용 데이터를 삭제합니다.

스팟 인스턴스

EMR 클러스터 노드에 Amazon EC2 스팟 인스턴스를 사용 중이며 이러한 인스턴스 중 하나가 종료되면 "slave lost" 오류가 발생할 수 있습니다. 스팟 인스턴스는 다음과 같은 이유로 종료될 수 있습니다.

  • 스팟 인스턴트 가격이 최고 가격보다 큽니다.
  • 미사용 EC2 인스턴스가 스팟 인스턴스에 대한 수요를 충족하기에 충분하지 않습니다.

자세한 내용은 서비스 중단의 이유를 참조하세요.

이 문제를 해결하려면 다음을 수행합니다.

Amazon EC2 Auto Scaling 정책

조정 정책이 수많은 축소 및 확장 이벤트를 연달아 수행할 때, 새 노드는 이전 노드에서 사용한 것과 동일한 IP 주소를 가질 수 있습니다. 축소 이벤트 중에 Spark 애플리케이션이 실행 중인 경우, Spark는 해당 노드를 Spark 거부 목록에 추가하여 실행기가 폐기된 노드에서 시작되지 않도록 합니다. 또 다른 확장 이벤트가 발생하고 새 노드가 이전에 폐기된 노드와 동일한 IP 주소를 받는 경우, YARN은 새 노드가 유효한 것으로 간주하고 실행기 일정을 예약하려고 시도합니다. 그러나 노드가 여전히 Spark 거부 목록에 있으므로 해당 노드에서 실행기 시작 시도가 실패합니다. 최대 실패 횟수에 도달하면 Spark 애플리케이션이 "slave lost" 오류와 함께 실패합니다.

이 문제를 해결하려면 다음을 수행합니다.

Spark 거부 목록에서 노드를 제거하려면 다음 예제와 같이 Spark 및 YARN 제한 시간 속성을 줄입니다.

/etc/spark/conf/spark-defaults.conf에 다음 속성을 추가합니다. 이렇게 하면 폐기 상태의 노드가 거부 목록에 추가되어 있는 시간이 줄어듭니다. 기본값은 1시간입니다. 자세한 내용은 노드 폐기 동작 구성을 참조하세요.

spark.blacklist.decommissioning.timeout 600s

/etc/hadoop/conf/yarn-site.xml에서 다음 YARN 속성을 수정합니다. 이 속성은 폐기 중 노드가 폐기 상태로 전환하기 전에 실행 중인 컨테이너 및 애플리케이션이 완료될 때까지 대기하는 시간을 지정합니다. 기본값은 3600초입니다.

yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs 600

자세한 내용은 Spark enhancements for elasticity and resiliency on Amazon EMR을 참조하세요.


관련 정보

클러스터 구성 지침 및 모범 사례

Amazon EMR에서 Spark 작업의 단계 실패 문제를 해결하려면 어떻게 해야 합니까?

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