기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon EMR 클러스터 작업 중 리소스 오류 다음 오류는 일반적으로 클러스터의 리소스 제약으로 인해 발생합니다. 이 지침에서는 각 오류를 설명하고 문제 해결 관련 도움말을 제공합니다. **Topics** + [NO\$1SLAVE\$1LEFT로 Amazon EMR 클러스터 종료 및 코어 노드 FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md) + [Amazon EMR 클러스터 오류: 블록을 복제할 수 없습니다. 0개 노드로만 복제할 수 있습니다.](enough-hdfs-space.md) + [Amazon EMR 클러스터 오류: EC2 할당량 초과됨](emr-EC2.md) + [Amazon EMR 클러스터 오류: 가져오기 실패가 너무 많음](emr-troubleshoot-error-resource-1.md) + [Amazon EMR 클러스터 오류: 파일을 1개 노드가 아니라 0개 노드로만 복제할 수 있습니다.](emr-troubleshoot-error-resource-2.md) + [Amazon EMR 클러스터 오류: 거부 목록 노드](emr-troubleshoot-error-resource-3.md) + [Amazon EMR 클러스터에서 오류 스로틀링](emr-throttling-error.md) + [Amazon EMR 클러스터 오류: 인스턴스 유형이 지원되지 않음](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md) + [Amazon EMR 클러스터 오류: EC2 용량이 부족함](emr-EC2_INSUFFICIENT_CAPACITY-error.md) + [Amazon EMR 클러스터 오류: HDFS 복제 인수 오류](emr-hdfs-insufficient-replication.md) + [Amazon EMR 클러스터 오류: HDFS 공간 부족 오류](emr-hdfs-insufficient-space.md) # NO\$1SLAVE\$1LEFT로 Amazon EMR 클러스터 종료 및 코어 노드 FAILED\$1BY\$1MASTER 일반적으로 이는 종료 방지 기능이 비활성화되고 모든 코어 노드가 `yarn-site.xml` 파일에 해당하는 `yarn-site` 구성 분류의 최대 사용률 임계값에 지정된 디스크 저장 용량을 초과하기 때문에 발생합니다. 기본값은 90%입니다. 코어 노드의 디스크 사용률이 사용률 임계값을 초과하면 YARN NodeManager 상태 서비스가 노드를 `UNHEALTHY`로 보고합니다. 이 상태에 있는 동안 은Amazon EMR 노드를 거부 목록에 등록하고 YARN 컨테이너를 할당하지 않습니다. 노드가 45분 동안 비정상 상태로 유지되면 Amazon EMR은 종료를 위해 연관된 Amazon EC2 인스턴스를 `FAILED_BY_MASTER`로 표시합니다. 코어 노드와 관련된 모든 Amazon EC2 인스턴스가 종료로 표시되면 작업을 실행할 리소스가 없기 때문에 클러스터는 `NO_SLAVE_LEFT` 상태로 종료됩니다. 하나의 코어 노드에서 디스크 사용률을 초과하면 연쇄 반응이 발생할 수 있습니다. HDFS로 인해 단일 노드가 디스크 사용률 임계값을 초과하는 경우 다른 노드도 임계값 근처에 있을 수 있습니다. 첫 번째 노드는 디스크 사용률 임계값을 초과하므로 Amazon EMR은 이를 거부 목록에 등록합니다. 이렇게 하면 거부 목록 노드에서 손실된 HDFS 데이터를 복제하기 시작하기 때문에 나머지 노드의 디스크 사용량이 증가합니다. 각 노드는 이후 같은 방식으로 `UNHEALTHY`로 이동하고 결국 클러스터가 종료됩니다. ## 모범 사례 및 권장 사항 ### 적절한 스토리지가 있는 클러스터 하드웨어 구성 클러스터를 생성할 때 코어 노드가 충분하고 각각에 적절한 인스턴스 스토어 및 HDFS용 EBS 스토리지 볼륨이 있는지 확인하세요. 자세한 내용은 [클러스터의 필요한 HDFS 용량 계산](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs) 단원을 참조하십시오. 기존 인스턴스 그룹에 수동으로 또는 자동 크기 조정을 통해 코어 인스턴스를 추가할 수도 있습니다. 새 인스턴스는 인스턴스 그룹의 다른 인스턴스와 동일한 스토리지 구성을 갖습니다. 자세한 내용은 [Amazon EMR 클러스터 조정을 사용하여 워크로드 변경에 맞게 조정](emr-scale-on-demand.md) 단원을 참조하십시오. ### 종료 방지 기능 활성화 종료 방지 기능을 활성화합니다. 이렇게 하면 코어 노드가 거부 목록에 등록된 경우 SSH를 사용하여 관련된 Amazon EC2 인스턴스에 연결하여 데이터 문제를 해결하고 복구할 수 있습니다. 종료 방지 기능을 활성화하면 Amazon EMR이 Amazon EC2 인스턴스를 새 인스턴스로 대체하지 않는다는 점에 유의하세요. 자세한 내용은 [종료 방지를 사용하여 Amazon EMR 클러스터가 실수로 종료되지 않도록 보호](UsingEMR_TerminationProtection.md) 단원을 참조하십시오. ### MRUnhealthyNodes CloudWatch 지표에 대한 경보 생성 이 측정치는 `UNHEALTHY` 상태를 보고하는 노드의 수를 보고합니다. 이는 YARN 측정치 `mapred.resourcemanager.NoOfUnhealthyNodes`와 동등합니다. 45분 제한 시간에 도달하기 전에 비정상 노드를 경고하기 위해 이 경고에 대한 알림을 설정할 수 있습니다. 자세한 내용은 [CloudWatch에서 Amazon EMR 지표 모니터링](UsingEMR_ViewingMetrics.md) 단원을 참조하십시오. ### yarn-site를 사용하여 설정 수정 아래의 설정은 애플리케이션 요구 사항에 따라 조정할 수 있습니다. 예를 들어, `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` 값을 증가시켜 노드가 `UNHEALTHY`를 보고하는 디스크 사용률 임계값을 늘릴 수 있습니다. `yarn-site` 구성 분류를 사용하여 클러스터를 생성할 때 이러한 값을 설정할 수 있습니다. 자세한 내용은 *Amazon EMR 릴리스 안내서*에서 [애플리케이션 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)을 참조하세요. SSH를 사용하여 코어 노드와 연관된 Amazon EC2 인스턴스에 연결한 다음, 텍스트 편집기를 사용하여 `/etc/hadoop/conf.empty/yarn-site.xml`에 값을 추가할 수도 있습니다. 변경한 후에는 아래와 같이 hadoop-yarn-nodemanager를 다시 시작해야 합니다. **중요** NodeManager 서비스를 다시 시작하면 클러스터를 생성할 때 `yarn-site` 구성 분류를 사용하여 `yarn.nodemanager.recovery.enabled`를 `true`로 설정하지 않으면 활성 YARN 컨테이너가 종료됩니다. `yarn.nodemanager.recovery.dir` 속성을 사용하여 컨테이너 상태를 저장할 디렉터리를 지정해야 합니다. ``` sudo /sbin/stop hadoop-yarn-nodemanager sudo /sbin/start hadoop-yarn-nodemanager ``` 현재 `yarn-site` 속성 및 기본값에 대한 자세한 내용은 Apache Hadoop 설명서의 [YARN 기본 설정](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml)을 참조하세요. | 속성 | 기본값 | 설명 | | --- | --- | --- | | yarn.nodemanager.disk-health-checker.interval-ms | 120000 | 디스크 상태 확인 프로그램이 실행되는 빈도(초)입니다. | | yarn.nodemanager.disk-health-checker.min-healthy-disks | 0.25 | NodeManager가 새 컨테이너를 시작하는 데 필요한 정상 디스크 수의 최소 비율입니다. 이는 yarn.nodemanager.local-dirs(기본값은 Amazon EMR의 `/mnt/yarn`)와 yarn.nodemanager.log-dirs(기본값은 `/var/log/hadoop-yarn/containers`이며 Amazon EMR의 `mnt/var/log/hadoop-yarn/containers`에 대한 기호 링크로 생성됨)에 모두 해당합니다. | | `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | 디스크가 불량으로 표시된 이후에 허용되는 디스크 공간 사용률의 최대 백분율입니다. 값의 범위는 0.0 \$1 100.0입니다. 값이 100보다 크거나 같으면 NodeManager가 전체 디스크를 확인합니다. 이는 `yarn-nodemanager.local-dirs` 및 `yarn.nodemanager.log-dirs`에 적용됩니다. | | `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | 디스크에서 사용할 수 있어야 하는 최소 공간입니다. 이는 `yarn-nodemanager.local-dirs` 및 `yarn.nodemanager.log-dirs`에 적용됩니다. | # Amazon EMR 클러스터 오류: 블록을 복제할 수 없습니다. 0개 노드로만 복제할 수 있습니다. 'Cannot replicate block, only managed to replicate to zero nodes.' 오류는 일반적으로 클러스터에 HDFS 스토리지가 부족할 때 발생합니다. 이 오류는 HDFS에 저장할 수 있는 것보다 더 많은 데이터를 클러스터에서 생성할 때 발생합니다. 작업이 종료될 때 사용 중이었던 HDFS 공간이 해제되므로 이 오류는 클러스터가 실행 중인 동안에만 표시됩니다. 클러스터에 사용할 수 있는 HDFS 공간의 양은 코어 노드로 사용되는 Amazon EC2 인스턴스의 개수 및 유형에 따라 달라집니다. 작업 노드는 HDFS 스토리지에 사용되지 않습니다. 연결된 EBS 스토리지 볼륨을 포함하여 각 Amazon EC2 인스턴스의 모든 디스크 공간을 HDFS에서 사용할 수 있습니다. 각 EC2 인스턴스 유형에 대한 로컬 스토리지 양에 대한 자세한 내용은 **Amazon EC2 사용 설명서에서 [인스턴스 유형 및 패밀리](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html)를 참조하세요. 사용할 수 있는 HDFS 공간의 양에 영향을 미칠 수 있는 기타 요인으로는 복제 인수가 있습니다. 복제 인수는 중복성을 위해 HDFS에 저장되는 각 데이터 블록의 복사본 수입니다. 복제 인수는 클러스터의 노드 수에 따라 증가합니다. 즉, 10개 이상의 노드로 구성된 클러스터에는 각 데이터 블록의 3개 복사본이 있으며, 4-9개 노드로 구성된 클러스터의 경우에는 각 블록의 2개 복사본이 있고, 3개 이하의 노드로 구성된 클러스터의 경우에는 1개 복사본(중복성 지원 안 함)이 있습니다. 사용 가능한 총 HDFS는 복제 인수로 나눠집니다. 경우에 따라, 노드 수를 9에서 10으로 늘리는 등 복제 인수를 높이는 경우 사실상 사용 가능한 HDFS 공간의 양이 감소될 수 있습니다. 예를 들어, m1.large 유형의 10개 코어 노드로 구성된 클러스터는 HDFS에 사용할 수 있는 2833GB((10개 노드 x 노드당 850GB) / 복제 인수 3)입니다. 클러스터가 HDFS에 사용할 수 있는 공간의 양을 초과할 경우 클러스터에 코어 노드를 더 추가하거나 데이터 압축을 사용하여 더 많은 HDFS 공간을 확보할 수 있습니다. 클러스터가 정지했다가 다시 시작할 수 있는 클러스터인 경우 더 큰 Amazon EC2 인스턴스 유형의 코어 노드를 사용하는 것을 고려해 볼 수 있습니다. 또한 복제 인수를 조정하는 것도 고려해 볼 수 있습니다. 하지만, 복제 인수를 낮추면 HDFS 데이터의 중복성과 클러스터에서 손실되었거나 손상된 HDFS 블록에서 복구할 수 있는 기능이 축소된다는 점을 기억해야 합니다. # Amazon EMR 클러스터 오류: EC2 할당량 초과됨 `EC2 QUOTA EXCEEDED`(할당량 초과) 메시지가 표시되는 이유는 몇 가지가 있습니다. 구성 차이에 따라 이전 클러스터를 종료하고 할당된 리소스를 해제하는 데 5-20분이 걸릴 수도 있습니다. 클러스터를 시작하려 할 때 `EC2 QUOTA EXCEEDED` 오류가 발생하는 경우 최근에 종료된 클러스터의 리소스가 아직 해제되지 않았기 때문일 수 있습니다. 또한 이 메시지는 인스턴스 그룹 또는 인스턴스 집합의 크기가 계정에 대한 현재 인스턴스 할당량보다 큰 목표 크기로 조정될 경우 발생할 수 있습니다. 이는 수동 또는 Auto Scaling을 통해 자동으로 발생할 수 있습니다. 문제를 해결하려면 다음 옵션을 고려하세요. + *Amazon Web Services 일반 참조*에서 [AWS 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)의 지침에 따라 서비스 한도 증가를 요청합니다. 일부 API의 경우 한도를 늘리는 것보다 CloudWatch 이벤트를 설정하는 것이 더 나을 수 있습니다. 자세한 내용은 [CloudWatch에서 EMR 이벤트를 설정하는 시점](emr-service-limits-cloudwatch-events.md) 섹션을 참조하세요. + 하나 이상의 실행 중인 클러스터가 완전 가동되지 않을 경우 인스턴스 그룹 크기를 변경하거나, 실행 중인 클러스터에 대한 인스턴스 집합의 목표 용량을 줄이세요. + EC2 인스턴스 수를 줄이거나 목표 용량을 줄여 클러스터를 생성합니다. # Amazon EMR 클러스터 오류: 가져오기 실패가 너무 많음 "**Too many fetch-failures**(가져오기 실패 횟수가 너무 많습니다.)" 또는 "**Error reading task output**(작업 출력을 읽는 중 오류가 발생했습니다.)" 오류 메시지가 단계 또는 작업 시도 로그에 있는 경우 이는 실행 중인 작업이 다른 작업의 출력에 따라 좌우됨을 의미합니다. 대체로 이 상황은 감소 작업이 실행 대기 중이며 하나 이상의 map 작업 출력이 필요하지만 출력을 아직 사용할 수 없는 경우에 발생합니다. 출력을 사용할 수 없는 이유는 몇 가지가 있을 수 있습니다. + 필수 선행 작업이 여전히 처리 중입니다. 이 작업은 대체로 map 작업입니다. + 데이터가 다른 인스턴스에 있는 경우 네트워크 연결 상태가 좋지 않아서 데이터를 사용하지 못할 수도 있습니다. + HDFS가 출력을 불러오는 데 사용되는 경우 HDFS 관련 문제가 있을 수 있습니다. 이 오류의 가장 일반적인 원인은 이전 작업이 여전히 처리 중이라는 점입니다. 특히 reduce 작업을 먼저 실행하려 할 때 오류가 발생하는 경우는 아마도 이 상황에 해당될 것입니다. 오류를 반환하는 클러스터 단계에 대해 syslog 로그를 검토하여 이 경우에 해당하는지 여부를 확인할 수 있습니다. syslog에 map 작업과 reduce 작업이 둘 다 진행 중인 것으로 표시되면 이는 아직 완료되지 않은 map 작업이 있는 상태에서 reduce 단계가 시작되었음을 나타냅니다. 로그에서 찾아볼 사항 중 하나는 100%에 도달하고 나서 그보다 낮은 값으로 내려가는 map 진행률입니다. map 백분율이 100%에 도달하는 경우 이것이 모든 map 작업이 완료되었음을 의미하지는 않습니다. 단순히 Hadoop이 모든 map 작업을 실행 중임을 의미할 뿐입니다. 이 값이 100% 미만으로 내려가면 map 작업이 실패했음을 의미하며 구성에 따라 Hadoop에서 해당 작업을 다시 예약하려 할 수도 있습니다. 로그에서 map 백분율이 100%로 유지되면 CloudWatch 지표(특히 `RunningMapTasks`)를 살펴봄으로써 해당 map 작업이 여전히 처리 중인지 확인합니다. 마스터 노드의 Hadoop 웹 인터페이스를 사용하여 이 정보를 찾아볼 수도 있습니다. 이 문제를 발생한 경우 몇 가지를 시도해 볼 수 있습니다. + reduce 단계의 시작 전 대기 시간을 늘립니다. 이렇게 하려면 Hadoop 구성 설정인 mapred.reduce.slowstart.completed.maps를 더 긴 시간으로 변경하면 됩니다. 자세한 내용은 [부트스트랩 작업을 생성하여 Amazon EMR 클러스터에서 추가 소프트웨어 설치](emr-plan-bootstrap.md) 단원을 참조하십시오. + reducer 수를 클러스터의 총 reducer 용량에 맞춥니다. 이렇게 하려면 해당 작업에 대한 Hadoop 구성 설정인 mapred.reduce.tasks를 조정하면 됩니다. + combiner 클래스 코드를 사용하여 가져와야 하는 출력 수를 최소화합니다. + 클러스터의 네트워크 성능에 영향을 미치는 Amazon EC2 서비스 관련 문제가 없는지 확인합니다. 이렇게 하려면 [서비스 상태 대시보드](https://status.aws.amazon.com/)를 사용합니다. + 클러스터 내 인스턴스의 CPU 및 메모리 리소스를 검토하여 노드의 리소스 중 너무 많은 부분이 데이터 처리에 사용되고 있지는 않은지 확인합니다. 자세한 내용은 [Amazon EMR 클러스터 하드웨어 및 네트워킹 구성](emr-plan-instances.md) 단원을 참조하십시오. + Amazon EMR 클러스터에 사용된 Amazon Machine Image(AMI)의 버전을 확인합니다. 버전이 2.3.0 \$1 2.4.4이면 더 최신 버전으로 업데이트합니다. 위에 지정된 범위에 속하는 AMI 버전에는 map 단계에서 출력을 제공하지 못할 수도 있는 Jetty 버전이 사용됩니다. reducer가 map 단계에서 출력을 가져올 수 없는 경우 가져오기 오류가 발생합니다. Jetty는 Hadoop 클러스터 내에서 시스템 간 통신에 사용되는 오픈 소스 HTTP 서버입니다. # Amazon EMR 클러스터 오류: 파일을 1개 노드가 아니라 0개 노드로만 복제할 수 있습니다. 파일을 HDFS에 쓰면 파일이 여러 코어 노드로 복제됩니다. 이 오류가 표시되는 경우 이는 HDFS에 데이터를 쓸 수 있는 DataNode 인스턴스가 NameNode 대몬이 없음을 의미합니다. 다시 말해서, 블록 복제가 발생하지 않는 것입니다. 이 오류는 여러 문제로 인해 발생할 수 있습니다. + HDFS 파일 시스템에 공간이 부족할 수 있습니다. 이 문제는 가장 큰 원인입니다. + 작업이 실행되었을 때 DataNode 인스턴스를 사용할 수 없었을 수도 있습니다. + DataNode 인스턴스와 마스터 노드 간의 통신이 차단되었을 수도 있습니다. + 코어 인스턴스 그룹 내 인스턴스의 사용이 불가능할 수도 있습니다. + 권한이 없을 수도 있습니다. 예를 들면 JobTracker대몬에 작업 트래커 정보를 생성할 권한이 없을 수도 있습니다. + DataNode 인스턴스에 대해 예약된 공간 설정이 부족할 수도 있습니다. dfs.datanode.du.reserved 구성 설정을 확인하여 이 경우에 해당하는지 확인합니다. 이 문제가 HDFS의 공간 부족으로 인해 발생하는지 여부를 확인하려면 CloudWatch에서 `HDFSUtilization` 지표를 살펴봅니다. 이 값이 너무 높은 경우 코어 노드를 클러스터에 더 추가할 수 있습니다. 클러스터에 HDFS 디스크 공간이 부족할 수도 있다고 생각되는 경우에는 CloudWatch에서 경보를 설정하여 `HDFSUtilization` 값이 특정 수준을 초과할 때 알리도록 할 수 있습니다. 자세한 내용은 [실행 중인 Amazon EMR 클러스터 크기 수동 조정](emr-manage-resize.md) 및 [CloudWatch에서 Amazon EMR 지표 모니터링](UsingEMR_ViewingMetrics.md) 섹션을 참조하세요. HDFS 공간 부족이 문제가 되지 않는 경우 DataNode 로그, NameNode 로그 및 네트워크 연결성을 확인하여 HDFS의 데이터 복제를 방해할 수 있는 그 밖의 문제가 있는지 알아봅니다. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오. # Amazon EMR 클러스터 오류: 거부 목록 노드 NodeManager 대몬은 코어 및 작업 노드에 있는 컨테이너의 실행 및 관리를 담당합니다. 이 컨테이너는 마스터 노드에서 실행되는 ResourceManager 대몬에 의해 NodeManager 대몬에 할당됩니다. ResourceManager는 하트비트를 통해 NodeManager 노드를 모니터링합니다. ResourceManager 대몬(daemon)에서 NodeManager 노드를 거부 목록에 등록하여 해당 노드가 작업을 처리할 수 있는 노드 풀에서 제거되는 몇 가지 상황이 있습니다. + NodeManager 노드에서 지난 10분(60만 밀리초) 동안 ResourceManager 대몬(daemon)으로 하트비트를 전송하지 않은 경우. 이 시간은 `yarn.nm.liveness-monitor.expiry-interval-ms` 구성 설정을 사용하여 구성할 수 있습니다. Yarn 구성 설정 변경에 대한 자세한 내용은 *Amazon EMR 릴리스 안내서*에서 [애플리케이션 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)을 참조하세요. + NodeManager는 `yarn.nodemanager.local-dirs` 및 `yarn.nodemanager.log-dirs`에 의해 결정되는 디스크 상태를 검사합니다. 이때 권한 및 사용 가능한 디스크 공간(90% 미만)에 대한 검사도 이루어집니다. 하나의 디스크가 검사에 실패하면 NodeManager가 해당 특정 디스크의 사용을 중지하지만 노드 상태는 양호한 것으로 보고합니다. 많은 수의 디스크가 검사에 실패하면 ResourceManager에 노드가 불량한 것으로 보고되고 새로운 컨테이너가 노드에 할당되지 않습니다. 실패한 작업이 3개를 넘으면 애플리케이션 마스터가 NodeManager 노드를 거부 목록으로도 처리할 수 있습니다. `mapreduce.job.maxtaskfailures.per.tracker` 구성 파라미터를 사용하여 이 값을 더 높은 값으로 변경할 수 있습니다. 변경할 수 있는 그 밖의 구성 설정으로는 실패로 표시되기 전 작업 시도 횟수(map 작업의 경우 `mapreduce.map.max.attempts`와 reduce 작업의 경우 `mapreduce.reduce.maxattempts`)가 있습니다. 구성 설정 변경에 대한 자세한 내용은 *Amazon EMR 릴리스 안내서*에서 [애플리케이션 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)을 참조하세요. # Amazon EMR 클러스터에서 오류 스로틀링 다른 서비스가 활동을 제한하기 때문에 Amazon EMR에서 요청을 완료할 수 없는 경우 'Throttled from *Amazon EC2* while launching cluster' 및 'Failed to provision instances due to throttling from *Amazon EC2*' 오류가 발생합니다. Amazon EC2가 제한 오류의 가장 일반적인 원인이지만 다른 서비스가 제한 오류의 원인일 수도 있습니다. [AWS 서비스 한도](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)는 성능 개선을 위해 리전별로 적용되며, 제한 오류는 해당 리전에서 계정의 서비스 한도를 초과했음을 나타냅니다. ## 가능한 원인 Amazon EC2 제한 오류의 가장 일반적인 원인은 너무 많은 클러스터 인스턴스가 시작되어 EC2 인스턴스의 서비스 한도가 초과되었기 때문입니다. 클러스터 인스턴스는 다음과 같은 이유로 시작될 수 있습니다. + 새 클러스터가 생성됩니다. + 클러스터 크기를 수동으로 변경합니다. 자세한 내용은 [실행 중인 Amazon EMR 클러스터 크기 수동 조정](emr-manage-resize.md) 단원을 참조하십시오. + 클러스터의 인스턴스 그룹은 자동 Automatic Scaling 규칙의 결과로 인스턴스를 추가합니다(확장). 자세한 내용은 [자동 조정 규칙 이해](emr-automatic-scaling.md#emr-scaling-rules) 단원을 참조하십시오. + 클러스터의 인스턴스 집합은 증가된 목표 용량을 충족하기 위해 인스턴스를 추가합니다. 자세한 내용은 [Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성](emr-instance-fleet.md) 단원을 참조하십시오. 또한 Amazon EC2에 대한 API 요청의 빈도나 유형에서 제한 오류가 발생할 수도 있습니다. Amazon EC2에서 API 요청을 제한하는 방법에 대한 자세한 내용은 *Amazon EC2 API 참조*에서 [Query API request rate](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate)를 참조하세요. ## Solutions 다음과 같이 해결해 보세요. + *Amazon Web Services 일반 참조*에서 [AWS 서비스 할당량](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)의 지침에 따라 서비스 한도 증가를 요청합니다. 일부 API의 경우 한도를 늘리는 것보다 CloudWatch 이벤트를 설정하는 것이 더 나을 수 있습니다. 자세한 내용은 [CloudWatch에서 EMR 이벤트를 설정하는 시점](emr-service-limits-cloudwatch-events.md) 섹션을 참조하세요. + 클러스터가 동일한 일정(예: 시간 상한에 시작)으로 시작되는 경우 시작 시간에 시차를 두는 것이 좋습니다. + 최고 수요에 맞게 크기가 조정된 클러스터가 있고 인스턴스 용량이 주기적으로 제공되는 경우, 온디맨드 방식으로 인스턴스를 추가하고 제거하기 위한 자동 확장을 지정해 보세요. 이러한 방법으로, 인스턴스를 보다 효율적으로 사용하고 수요 프로파일에 따라 계정 전체에서 지정된 시간에 요청되는 인스턴스가 더 적을 수 있습니다. 자세한 내용은 [Amazon EMR의 인스턴스 그룹에서 사용자 지정 정책과 함께 자동 조정 사용](emr-automatic-scaling.md) 단원을 참조하십시오. # Amazon EMR 클러스터 오류: 인스턴스 유형이 지원되지 않음 클러스터를 생성할 때 'The requested instance type *InstanceType* is not supported in the requested Availability Zone' 오류로 실패하면 클러스터를 생성했지만 클러스터가 생성된 리전 및 가용 영역에서 Amazon EMR이 지원하지 않는 하나 이상의 인스턴스 그룹의 인스턴스 유형을 지정했음을 의미합니다. Amazon EMR은 리전 내 한 가용 영역에서 인스턴스 유형을 지원하지만 다른 가용 영역에서는 지원하지 않을 수 있습니다. 클러스터에 대해 선택한 서브넷에 따라 리전 내 가용 영역이 결정됩니다. ## Solution **를 사용하여 가용 영역에서 사용 가능한 인스턴스 유형 확인 AWS CLI** + `--dry-run` 옵션과 함께 `ec2 run-instances` 명령을 사용합니다. 아래 예제에서 *m5.xlarge*를 사용하려는 인스턴스 유형으로, *ami-035be7bafff33b6b6*을 해당 인스턴스 유형에 연결된 AMI로, *subnet-12ab3c45*를 쿼리하려는 가용 영역으로 바꿉니다. ``` aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45 ``` AMI ID를 찾는 방법에 대한 지침은 [Linux AMI 찾기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html)를 참조하세요. 서브넷 ID를 찾기 위해 [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html) 명령을 사용할 수 있습니다. 사용 가능한 인스턴스 유형을 찾는 방법에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형 찾기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)를 참조하세요. 사용 가능한 인스턴스 유형을 확인한 후 다음 작업을 수행할 수 있습니다. + 동일한 리전 및 EC2 서브넷에 클러스터를 생성하고 처음 선택과 유사한 기능을 가진 다른 인스턴스 유형을 선택하세요. 지원되는 인스턴스 유형의 목록은 [Amazon EMR에서 지원되는 인스턴스 유형](emr-supported-instance-types.md) 섹션을 참조하세요. EC2 인스턴스 유형의 기능을 비교하려면 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요. + Amazon EMR이 지원하고 사용 가능한 인스턴스 유형이 있는 가용 영역에서 클러스터의 서브넷을 선택합니다. **Amazon EMR에서 지원되지 않는 프라이머리 인스턴스 유형으로 인한 인스턴스 플릿 클러스터 시작 실패 완화** 프라이머리 노드는 Amazon EMR 클러스터에서 필수적입니다. Amazon EMR이 프라이머리 인스턴스 유형이 지원되지 않는 가용 영역에서 클러스터를 시작하려고 시도하면 `instance type not supported` 오류와 함께 EMR 클러스터 시작이 실패할 수 있습니다. Amazon EMR의 인스턴스 플릿 클러스터에 대한 향상된 가용 영역 선택에서는 클러스터 구성에서 사용자가 지정한 프라이머리 인스턴스 유형에 대해 지원되지 않는 AZ를 자동으로 필터링합니다. 즉, Amazon EMR에서는 구성된 프라이머리 인스턴스 유형이 지원되지 않는 가용 영역을 선택하지 않으므로 지원되지 않는 인스턴스 유형으로 인한 클러스터 시작 실패를 방지합니다. 이 개선 사항을 활성화하려면 클러스터의 정책 또는 서비스 역할에 필요한 권한을 추가합니다. `AmazonEMRServicePolicy_v2`의 최신 버전에는 이 권한이 포함되어 있으므로 해당 정책을 사용하는 경우 개선 사항을 이미 사용할 수 있습니다. 사용자 지정 서비스 역할 또는 정책을 사용하는 경우 클러스터를 시작할 때 `ec2:DescribeInstanceTypeOfferings` 권한을 추가합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Action": [ "ec2:DescribeInstanceTypeOfferings" ], "Effect": "Allow", "Resource": [ "*" ], "Sid": "AllowEC2Describeinstancetypeofferings" } ] } ``` ------ # Amazon EMR 클러스터 오류: EC2 용량이 부족함 **InstanceType*에 대해 EC2의 용량이 부족함* 오류는 지정된 EC2 인스턴스 유형이 더 이상 없는 가용 영역에서 클러스터를 생성하거나 클러스터에 인스턴스를 추가하려고 하면 EC2 is out of capacity for InstanceType 오류가 발생합니다. 클러스터에 대해 선택한 서브넷에 따라 가용 영역이 결정됩니다. 클러스터를 생성하려면 다음 중 하나를 수행합니다. + 기능이 비슷한 다른 인스턴스 유형 지정 + 다른 리전에서 클러스터 생성 + 원하는 인스턴스 유형을 사용할 수 있는 가용 영역에서 서브넷을 선택합니다. 실행 중인 클러스터에 인스턴스를 추가하려면 다음 중 하나를 수행합니다. + 인스턴스 그룹 구성 또는 인스턴스 플릿 구성을 수정하여 유사한 기능을 가진 사용 가능한 인스턴스 유형을 추가합니다. 지원되는 인스턴스 유형의 목록은 [Amazon EMR에서 지원되는 인스턴스 유형](emr-supported-instance-types.md) 섹션을 참조하세요. EC2 인스턴스 유형의 기능을 비교하려면 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요. + 인스턴스 유형을 사용할 수 있는 리전 및 가용 영역에서 클러스터를 종료하고 다시 생성합니다. # Amazon EMR 클러스터 오류: HDFS 복제 인수 오류 코어 [인스턴스 그룹](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) 또는 [인스턴스 플릿](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html)에서 코어 노드를 제거하면 Amazon EMR에서 HDFS 복제 오류가 발생할 수 있습니다. 이 오류는 코어 노드를 제거하고 코어 노드 수가 Hadoop 분산 파일 시스템(HDFS)에 대해 구성된 [dfs.replication 인수](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) 아래로 떨어질 때 발생합니다. 이와 같이 Amazon EMR은 작업을 안전하게 수행할 수 없습니다. `dfs.replication` 구성의 기본값을 확인하려면 [HDFS 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html)을 선택합니다. ## 가능한 원인 HDFS 복제 인수 오류의 가능한 원인은 다음을 참조하세요. + 코어 인스턴스 그룹 또는 인스턴스 플릿의 크기를 구성된 `dfs.replication` 인수 미만으로 [수동으로 조정](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html)하는 경우. + [관리형 조정](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) 또는 [자동 조정](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html)에 대한 정책을 사용하면 조정 작업에서 코어 노드 수를 임계치(`dfs.replication`) 미만으로 줄일 수 있습니다. + 이 오류는 []()에서 정의한 최소 수의 코어 노드가 클러스터에 있는 경우 Amazon EMR이 비정상 코어 노드를 [교체](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html)하려고 할 때도 발생할 수 있습니다. ## 해결 방법 및 모범 사례 솔루션 및 모범 사례는 다음을 참조하세요. + Amazon EMR 클러스터의 크기를 수동으로 조정하는 경우 Amazon EMR이 크기 조정을 안전하게 완료할 수 없으므로 `dfs.replication` 아래로 스케일 다운하지 않습니다. + 관리형 조정 또는 자동 조정을 사용하는 경우 클러스터의 최소 용량이 `dfs.replication` 인수보다 낮지 않은지 확인합니다. + 코어 인스턴스 수는 `dfs.replication` \$1 1개 이상이어야 합니다. 이렇게 하면 비정상 코어 교체를 활성화한 경우 Amazon EMR이 비정상 코어 노드를 성공적으로 교체할 수 있습니다. **중요** `dfs.replication`을 1로 설정하는 경우 단일 코어 노드가 실패하면 HDFS 데이터가 손실될 수 있습니다. 클러스터에 HDFS 스토리지가 있는 경우 데이터 손실을 방지하려면 프로덕션 워크로드에 사용할 코어 노드를 4개 이상 포함하는 클러스터를 구성하는 것이 좋습니다. `dfs.replication` 인수도 2 이상으로 설정합니다. # Amazon EMR 클러스터 오류: HDFS 공간 부족 오류 코어 노드를 제거하려고 하면 Hadoop 분산 파일 시스템(HDFS) 공간 부족 오류가 발생할 수 있지만, HDFS에 공간이 부족하여 Amazon EMR이 작업을 안전하게 완료할 수 없습니다. Amazon EMR이 코어 노드를 제거하기 전에 먼저 데이터 중복성을 보장하기 위해 노드의 모든 HDFS 데이터를 다른 코어 노드로 전송해야 합니다. 그러나 다른 코어 노드에 복제할 공간이 충분하지 않으면 Amazon EMR은 노드를 정상적으로 해제할 수 없습니다. ## 가능한 원인 HDFS 공간 부족 오류의 가능한 원인 목록은 다음을 참조하세요. + 스케일 다운 전에 나머지 노드에 데이터 복제를 위한 HDFS 공간이 부족할 때 코어 인스턴스 그룹 또는 인스턴스 플릿을 수동으로 스케일 다운하는 경우. + 관리형 조정 또는 자동 조정은 데이터 복제를 위한 HDFS 공간이 부족할 때 코어 인스턴스 그룹 또는 인스턴스 플릿을 스케일 다운합니다. + Amazon EMR은 비정상 코어 노드 교체를 시도하지만 HDFS 공간이 부족하여 노드를 안전하게 교체할 수 없습니다. ## 해결 방법 및 모범 사례 솔루션 및 모범 사례는 다음을 참조하세요. + Amazon EMR 클러스터의 코어 노드 수를 스케일 업합니다. 관리형 조정 또는 자동 크기 조정을 사용하는 경우 코어 노드의 최소 용량을 늘립니다. + EMR 클러스터를 생성하는 경우 코어 노드에 더 큰 EBS 볼륨을 사용합니다. + EMR 클러스터에서 불필요한 HDFS 데이터를 삭제합니다. EMR 클러스터의 공간이 부족한지 확인하려면 클러스터의 `HDFSUtilization` 지표를 모니터링하도록 CloudWatch 경보를 설정하는 것이 좋습니다.