기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EMR 클러스터 문제 해결
EMR 클러스터는 오픈 소스 소프트웨어, 사용자 지정 애플리케이션 코드 및 로 구성된 복잡한 에코시스템에서 실행됩니다 AWS 서비스. 이러한 부분에서 문제가 발생하면 클러스터에 장애가 발생하거나 완료 시간이 예상보다 길어질 수 있습니다. 다음 주제는 클러스터 문제를 식별하고 해결 방법을 찾는 데 도움이 될 수 있습니다.
**Topics**
+ [Amazon EMR 클러스터 문제를 해결하는 데 사용할 수 있는 도구는 무엇인가요?](emr-troubleshoot-tools.md)
+ [Amazon EMR 및 애플리케이션 프로세스(대몬(daemon)) 보기 및 다시 시작](emr-process-restart-stop-view.md)
+ [Amazon EMR의 일반적인 오류 컬렉션](emr-troubleshoot-errors.md)
+ [오류 코드와 함께 실패한 Amazon EMR 클러스터 문제 해결](emr-troubleshoot-failed.md)
+ [느린 Amazon EMR 클러스터 문제 해결](emr-troubleshoot-slow.md)
+ [AWS Lake Formation과 함께 Amazon EMR을 사용할 때 발생하는 일반적인 문제 해결](emr-troubleshoot-lf.md)
[EMR의 Spark 애플리케이션](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Applications/Spark/troubleshooting/) 문제 해결 지침.
새 Hadoop 애플리케이션을 개발하는 경우, 디버깅을 활성화하고, 대표적인 소규모 데이터 하위 집합을 처리하여 애플리케이션을 테스트하는 것이 좋습니다. 애플리케이션을 단계적으로 실행하여 각 단계를 별도로 테스트해도 좋습니다. 자세한 내용은 [Amazon EMR 클러스터 로깅 및 디버깅 구성](emr-plan-debugging.md) 및 [5단계: Amazon EMR 클러스터 단계별 테스트](emr-troubleshoot-failed-5-test-steps.md) 섹션을 참조하세요.
# Amazon EMR 클러스터 문제를 해결하는 데 사용할 수 있는 도구는 무엇인가요?
클러스터 오류를 식별하고 수정하려면 이 페이지에서 설명하는 도구를 사용할 수 있습니다. 클러스터를 시작할 때 일부 도구를 초기화해야 할 수도 있습니다. 이외 도구는 기본적으로 모든 클러스터에서 사용 가능합니다.
**Topics**
+ [EMR 클러스터 세부 정보 보기](#emr-troubleshoot-tools-details)
+ [EMR 클러스터 오류 세부 정보 보기](#emr-troubleshoot-errordetail)
+ [스크립트 실행 및 Amazon EMR 프로세스 구성](#emr-troubleshoot-tools-commands)
+ [로그 파일 보기](#emr-troubleshoot-tools-logs)
+ [EMR 클러스터 성능 모니터링](#emr-troubleshoot-tools-performance)
## EMR 클러스터 세부 정보 보기
AWS Management Console AWS CLI또는 EMR API를 사용하여 EMR 클러스터 및 작업 실행에 대한 세부 정보를 검색할 수 있습니다. AWS Management Console 및 사용에 대한 자세한 내용은 단원을 AWS CLI참조하십시오[Amazon EMR 클러스터 상태 및 세부 정보 보기](emr-manage-view-clusters.md).
### Amazon EMR 콘솔 세부 정보 창
Amazon EMR 콘솔의 **클러스터** 목록에서 계정 및 AWS 리전에 있는 각 클러스터 상태에 대한 개요 수준의 정보를 볼 수 있습니다. 목록에는 지난 2개월 동안 시작한 모든 활성 클러스터 및 종료된 클러스터가 표시됩니다. **클러스터** 목록에서 클러스터 **이름**을 선택해서 클러스터 세부 정보를 볼 수 있습니다. 이 정보는 여러 카테고리로 구성되어 있어 쉽게 탐색할 수 있습니다.
클러스터 세부 정보 페이지에서 사용할 수 있는 **애플리케이션 사용자 인터페이스**는 클러스터 문제를 해결하는 데 유용할 수 있습니다. YARN 애플리케이션의 상태를 제공하며, Spark 애플리케이션과 같은 일부 애플리케이션의 경우 작업, 단계 및 실행기와 같은 다양한 지표 및 패싯으로 드릴다운할 수 있습니다. 자세한 내용은 [Amazon EMR 애플리케이션 기록 보기](emr-cluster-application-history.md) 단원을 참조하십시오. 이 기능은 Amazon EMR 릴리스 5.8.0 이상에서만 사용할 수 있습니다.
### Amazon EMR 명령줄 인터페이스
`--describe` 인수를 AWS CLI 사용하여에서 클러스터에 대한 세부 정보를 찾을 수 있습니다.
### Amazon EMR API
`DescribeJobFlows` 작업을 사용하여 API에서 클러스터에 대한 세부 정보를 찾을 수 있습니다.
## EMR 클러스터 오류 세부 정보 보기
EMR 클러스터가 오류와 함께 종료되면 `DescribeCluster` 및 `ListClusters` API는 오류 코드와 오류 메시지를 반환합니다. 일부 클러스터 오류의 경우 `ErrorDetail` 데이터 배열이 장애 문제를 해결하는 데 도움이 될 수 있습니다.
`ErrorDetail` 데이터가 포함된 오류 코드 목록은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 섹션을 참조하세요.
**참고**
가장 최근 관련 정보를 받을 수 있도록 오류 메시지를 지속적으로 구체화하고 있습니다. 이 텍스트는 변경될 수 있으므로 `ErrorMessage`에서 텍스트를 구문 분석하지 않는 것이 좋습니다.
## 스크립트 실행 및 Amazon EMR 프로세스 구성
문제 해결 프로세스의 일환으로 클러스터에서 사용자 지정 스크립트를 실행하거나 클러스터 프로세스를 보고 구성하는 것이 유용할 수 있습니다.
### 애플리케이션 프로세스 보기 및 다시 시작
잠재적 문제를 진단하기 위해 클러스터에서 실행 중인 프로세스를 보는 것이 유용할 수 있습니다. 클러스터의 프라이머리 노드에 연결하여 클러스터 프로세스를 중지하고 다시 시작할 수 있습니다. 자세한 내용은 [Amazon EMR 및 애플리케이션 프로세스(대몬(daemon)) 보기 및 다시 시작](emr-process-restart-stop-view.md) 단원을 참조하십시오.
### SSH 연결 없이 명령 및 스크립트 실행
클러스터에서 명령 또는 스크립트를 단계로 실행하려면 프라이머리 노드에 대한 SSH 연결을 설정하지 않고 `command-runner.jar` 또는 `script-runner.jar` 도구를 사용할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터에서 명령 및 스크립트 실행](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-commandrunner.html)을 참조하세요.
## 로그 파일 보기
Amazon EMR 및 Hadoop은 모두 클러스터가 실행될 때 로그 파일을 생성합니다. 클러스터를 시작할 때 지정한 구성에 따라 여러 다른 도구에서 이러한 로그 파일에 액세스할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터 로깅 및 디버깅 구성](emr-plan-debugging.md) 단원을 참조하십시오.
### 프라이머리 노드의 로그 파일
모든 클러스터는 로그 파일을 마스터 노드의 /mnt/var/log/ 디렉터리에 게시합니다. 이러한 로그 파일은 클러스터가 실행되는 동안에만 사용할 수 있습니다.
### Amazon S3에 아카이브된 로그 파일
클러스터를 실행하고 Amazon S3 로그 경로를 지정한 경우 클러스터는 프라이머리 노드의 /mnt/var/log/에 저장된 로그 파일을 Amazon S3에 5분 간격으로 복사합니다. 이렇게 하면 클러스터가 종료된 후에도 로그 파일에 액세스할 수 있습니다. 파일이 5분 간격으로 보관되므로 갑자기 종료된 클러스터의 마지막 몇 분은 사용하지 못할 수 있습니다.
## EMR 클러스터 성능 모니터링
Amazon EMR은 클러스터 성능을 모니터링하는 여러 도구를 제공합니다.
### Hadoop 웹 인터페이스
모든 클러스터는 클러스터에 대한 정보를 포함하는 일련의 웹 인터페이스를 마스터 노드에 게시합니다. SSH 터널을 사용하여 마스터 노드에 연결하면 이러한 웹 페이지에 액세스할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터에 호스팅된 웹 인터페이스 보기](emr-web-interfaces.md) 단원을 참조하십시오.
### CloudWatch 지표
모든 클러스터는 지표를 CloudWatch에 보고합니다. CloudWatch는 지표를 추적하고 이 지표에 대한 경보를 설정하는 데 사용할 수 있는 웹 서비스입니다. 자세한 내용은 [CloudWatch에서 Amazon EMR 지표 모니터링](UsingEMR_ViewingMetrics.md) 단원을 참조하십시오.
# Amazon EMR 및 애플리케이션 프로세스(대몬(daemon)) 보기 및 다시 시작
클러스터 문제를 해결할 때 필요하다면 실행 중인 프로세스를 나열할 수 있습니다. 프로세스를 중지하거나 다시 시작할 수도 있습니다. 예를 들어, 구성을 변경한 후 프로세스를 다시 시작하거나 로그 파일과 오류 메시지를 분석한 후 특정 프로세스의 문제를 확인할 수 있습니다.
클러스터에서 실행되는 프로세스는 두 가지 유형이 있는데, 하나는 Amazon EMR 프로세스(예: instance-controller 및 로그 푸셔)이며 다른 하나는 클러스터에 설치된 애플리케이션과 연결된 프로세스(예: hadoop-hdfs-namenode 및 hadoop-yarn-resourcemanager)입니다.
클러스터에서 프로세스 작업을 직접 수행하려면 프라이머리 노드에 연결합니다. 자세한 내용은 [Amazon EMR 클러스터에 연결하기](emr-connect-master-node.md) 단원을 참조하십시오.
## 실행 중인 프로세스 보기
클러스터에서 실행 중인 프로세스를 보는 데 사용하는 방법은 사용하는 Amazon EMR 버전에 따라 다릅니다.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : 실행 중인 모든 프로세스 나열**
다음 예제에서는 `systemctl`을 사용하고 `--type`을 지정하여 모든 프로세스를 봅니다.
```
systemctl --type=service
```
**Example : 특정 프로세스 나열**
다음 예제에서는 이름에 `hadoop`을 포함하는 모든 프로세스를 나열합니다.
```
systemctl --type=service | grep -i hadoop
```
출력 예시:
```
hadoop-hdfs-namenode.service loaded active running Hadoop namenode
hadoop-httpfs.service loaded active running Hadoop httpfs
hadoop-kms.service loaded active running Hadoop kms
hadoop-mapreduce-historyserver.service loaded active running Hadoop historyserver
hadoop-state-pusher.service loaded active running Daemon process that processes and serves EMR metrics data.
hadoop-yarn-proxyserver.service loaded active running Hadoop proxyserver
hadoop-yarn-resourcemanager.service loaded active running Hadoop resourcemanager
hadoop-yarn-timelineserver.service loaded active running Hadoop timelineserver
```
**Example : 특정 프로세스에 대한 자세한 상태 보고서 확인**
다음 예제에서는 `hadoop-hdfs-namenode` 서비스에 대한 자세한 상태 보고서를 표시합니다.
```
sudo systemctl status hadoop-hdfs-namenode
```
출력 예시:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:01:46 UTC; 26min ago
Main PID: 9733 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 9733 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p ...
Aug 18 21:01:37 ip-172-31-20-123 systemd[1]: Starting Hadoop namenode...
Aug 18 21:01:37 ip-172-31-20-123 su[9715]: (to hdfs) root on none
Aug 18 21:01:37 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: starting namenode, logging to /var/log/hadoop-hdfs/ha...out
Aug 18 21:01:46 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: Started Hadoop namenode:[ OK ]
Aug 18 21:01:46 ip-172-31-20-123 systemd[1]: Started Hadoop namenode.
Hint: Some lines were ellipsized, use -l to show in full.
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : 실행 중인 모든 프로세스 나열**
다음 예제에서는 실행 중인 모든 프로세스를 나열합니다.
```
initctl list
```
------
#### [ EMR 2.x - 3.x ]
**Example : 실행 중인 모든 프로세스 나열**
다음 예제에서는 실행 중인 모든 프로세스를 나열합니다.
```
ls /etc/init.d/
```
------
## 프로세스 중지 및 다시 시작
어떤 프로세스가 실행 중인지를 확인한 후 필요하다면 해당 프로세스를 중지했다가 다시 시작할 수 있습니다.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : 프로세스 중지**
다음 예제에서는 `hadoop-hdfs-namenode` 프로세스를 중지합니다.
```
sudo systemctl stop hadoop-hdfs-namenode
```
`status`를 쿼리하여 프로세스가 중지되었는지 확인할 수 있습니다.
```
sudo systemctl status hadoop-hdfs-namenode
```
출력 예시:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2021-08-18 21:37:50 UTC; 8s ago
Main PID: 9733 (code=exited, status=143)
```
**Example : 프로세스 시작**
다음 예제에서는 `hadoop-hdfs-namenode` 프로세스를 시작합니다.
```
sudo systemctl start hadoop-hdfs-namenode
```
상태를 쿼리하여 프로세스가 실행 중인지 확인할 수 있습니다.
```
sudo systemctl status hadoop-hdfs-namenode
```
출력 예시:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:38:24 UTC; 2s ago
Process: 13748 ExecStart=/etc/init.d/hadoop-hdfs-namenode start (code=exited, status=0/SUCCESS)
Main PID: 13800 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 13800 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p...
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : 실행 중인 프로세스 중지**
다음 예제에서는 `hadoop-hdfs-namenode` 서비스를 중지합니다.
```
sudo stop hadoop-hdfs-namenode
```
**Example : 중지된 프로세스 다시 시작**
다음 예제에서는 `hadoop-hdfs-namenode` 서비스를 다시 시작합니다. `restart`가 아닌 `start` 명령을 사용해야 합니다.
```
sudo start hadoop-hdfs-namenode
```
**Example : 프로세스 상태 확인**
다음에서는 `hadoop-hdfs-namenode`에 대한 상태를 가져옵니다. `status` 명령을 사용하여 프로세스가 중지 또는 시작되었는지 확인할 수 있습니다.
```
sudo status hadoop-hdfs-namenode
```
------
#### [ EMR 2.x - 3.x ]
**Example : 애플리케이션 프로세스 중지**
다음 예제에서는 클러스터에 설치된 Amazon EMR 버전과 연결된 `hadoop-hdfs-namenode` 서비스를 중지합니다.
```
sudo /etc/init.d/hadoop-hdfs-namenode stop
```
**Example : 애플리케이션 프로세스 다시 시작**
다음 예제 명령은 `hadoop-hdfs-namenode` 프로세스를 다시 시작합니다.
```
sudo /etc/init.d/hadoop-hdfs-namenode start
```
**Example : Amazon EMR 프로세스 중지**
다음 예제에서는 클러스터의 Amazon EMR 버전과 연결되지 않은 프로세스(예: instance-controller)를 중지합니다.
```
sudo /sbin/stop instance-controller
```
**Example : Amazon EMR 프로세스 다시 시작**
다음 예제에서는 클러스터의 Amazon EMR 버전과 연결되지 않은 프로세스(예: instance-controller)를 다시 시작합니다.
```
sudo /sbin/start instance-controller
```
**참고**
`/sbin/start, stop` 및 `restart` 명령은 `/sbin/intictl`에 대한 symlinks입니다. `initctl`에 대한 자세한 내용은 명령 프롬프트에서 `man initctl`을 입력해 initctl man 페이지를 참조하세요.
------
# Amazon EMR의 일반적인 오류 컬렉션
클러스터가 실패하거나 데이터 처리 속도가 느린 때가 있습니다. 다음 섹션에서는 일반적인 클러스터 문제를 나열합니다. 오류에는 부트스트랩 실패 및 검증 오류와 이를 해결하는 방법에 대한 제안이 포함됩니다.
**Topics**
+ [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md)
+ [Amazon EMR 클러스터 작업 중 리소스 오류](emr-troubleshoot-error-resource.md)
+ [Amazon EMR 작업 중 클러스터 입력 및 출력 오류](emr-troubleshoot-errors-io.md)
+ [Amazon EMR 클러스터 작업 중 권한 오류](emr-troubleshoot-error-permissions.md)
+ [Hive 클러스터 오류](emr-troubleshoot-error-hive.md)
+ [Amazon EMR 클러스터 작업 중 VPC 오류](emr-troubleshoot-error-vpc.md)
+ [Amazon EMR 클러스터 스트리밍 오류](emr-troubleshoot-error-streaming.md)
+ [Amazon EMR: 사용자 지정 JAR 클러스터 오류](emr-troubleshoot-error-custom-jar.md)
+ [Amazon EMR AWS GovCloud(미국 서부) 오류](emr-troubleshoot-error-govcloud.md)
+ [누락된 클러스터 찾기](#w2aac36c21c47)
# Amazon EMR에서 오류 코드 및 ErrorDetail 정보
EMR 클러스터가 오류와 함께 종료되면 `DescribeCluster` 및 `ListClusters` API는 오류 코드와 오류 메시지를 반환합니다. 일부 클러스터 오류의 경우 `ErrorDetail` 데이터 배열이 장애 문제를 해결하는 데 도움이 될 수 있습니다.
`ErrorDetail` 배열이 포함된 오류는 다음과 같은 세부 정보를 제공합니다.
**`ErrorCode`**
프로그래밍 방식의 액세스에 사용할 수 있는 고유한 오류 코드.
**`ErrorData`**
프로그래밍 방식의 검색 또는 수동 검색에 사용할 수 있는 키-값 페어의 식별자 목록. 오류 코드에 포함된 `ErrorData` 값에 대한 설명은 오류 코드의 문제 해결 페이지를 참조하세요.
**`ErrorMessage`**
오류에 대한 설명과 Amazon EMR 설명서의 추가 정보 링크.
이 텍스트는 변경될 수 있으므로 `ErrorMessage`에서 텍스트를 구문 분석하지 않는 것이 좋습니다.
**Topics**
+ [부트스트랩 실패](emr-troubleshoot-error-errordetail-bootstrap.md)
+ [내부 오류.](emr-troubleshoot-error-errordetail-internal.md)
+ [검증 실패](emr-troubleshoot-error-errordetail-validation.md)
# Amazon EMR에서의 부트스트랩 실패 오류 코드
다음 섹션에서는 부트스트랩 실패 오류 코드에 대한 문제 해결 정보를 제공합니다.
**Topics**
+ [BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE](BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE.md)
+ [BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY](BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY](BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER.md)
# BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE
## 개요
클러스터가 `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE` 오류로 종료되면 기본 인스턴스에서 부트스트랩 작업이 실패한 것입니다. 부트스트랩 작업에 대한 자세한 내용은 [부트스트랩 작업을 생성하여 Amazon EMR 클러스터에서 추가 소프트웨어 설치](emr-plan-bootstrap.md) 섹션을 참조하세요.
## 해결 방법
이 오류를 해결하려면 API 오류에 반환된 세부 정보를 검토하고, 부트스트랩 작업 스크립트를 수정하며, 업데이트된 부트스트랩 작업으로 새 클러스터를 생성합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
부트스트랩 작업이 실패한 기본 인스턴스의 ID.
**`bootstrap-action`**
실패한 부트스트랩 작업의 서수. `bootstrap-action` 값이 `1`인 스크립트가 인스턴스에서 실행하는 첫 번째 부트스트랩 작업입니다.
**`return-code`**
실패한 부트스트랩 작업의 반환 코드.
**`amazon-s3-path`**
실패한 부트스트랩 작업의 Amazon S3 위치.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
다음 단계를 수행하여 부트스트랩 작업 오류의 근본 원인을 식별하고 수정합니다. 그런 다음, 새 클러스터를 시작합니다.
1. Amazon S3의 부트스트랩 작업 로그 파일을 검토하여 실패의 근본 원인을 식별합니다. Amazon EMR 로그를 보는 방법에 대한 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 섹션을 참조하세요.
1. 인스턴스를 생성할 때 클러스터 로그를 활성화한 경우 자세한 내용은 `stdout` 로그를 참조하세요. 부트스트랩 작업에 대한 `stdout` 로그는 다음 Amazon S3 위치에서 찾을 수 있습니다.
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
클러스터 로그에 대한 자세한 내용은 [Amazon EMR 클러스터 로깅 및 디버깅 구성](emr-plan-debugging.md) 섹션을 참조하세요.
1. 부트스트랩 작업 실패를 확인하려면 `stdout` 로그의 예외와 `ErrorData`의 `return-code` 값을 검토합니다.
1. 이전 단계에서 찾은 조사 결과를 사용하여 예외를 방지하거나 예외 발생 시 적절하게 처리할 수 있도록 부트스트랩 작업을 수정합니다.
1. 업데이트된 부트스트랩 작업으로 새 클러스터를 시작합니다.
# BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY
## 개요
기본 인스턴스가 지정한 Amazon S3 위치에서 부트스트랩 작업 스크립트를 다운로드할 수 없는 경우 클러스터는 `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY` 오류로 종료됩니다. 잠재적 원인은 다음과 같습니다.
+ 부트스트랩 작업 스크립트 파일이 지정된 Amazon S3 위치에 없습니다.
+ 클러스터의 Amazon EC2 인스턴스에 대한 서비스 역할(*Amazon EMR의 EC2 인스턴스 프로파일*이라고도 함)에 부트스트랩 작업 스크립트가 있는 Amazon S3 버킷에 액세스할 권한이 없습니다. 서비스 역할에 대한 자세한 내용은 [클러스터 EC2 인스턴스에 대한 서비스 역할(EC2 인스턴스 프로파일)](emr-iam-role-for-ec2.md)을 참조하세요.
부트스트랩 작업에 대한 자세한 내용은 [부트스트랩 작업을 생성하여 Amazon EMR 클러스터에서 추가 소프트웨어 설치](emr-plan-bootstrap.md) 섹션을 참조하세요.
## 해결 방법
이 오류를 해결하려면 기본 인스턴스에 부트스트랩 작업 스크립트에 대한 적절한 액세스 권한이 있어야 합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
부트스트랩 작업이 실패한 기본 인스턴스의 ID.
**`bootstrap-action`**
실패한 부트스트랩 작업의 서수. `bootstrap-action` 값이 `1`인 스크립트가 인스턴스에서 실행하는 첫 번째 부트스트랩 작업입니다.
**`amazon-s3-path`**
실패한 부트스트랩 작업의 Amazon S3 위치.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
다음 단계를 수행하여 부트스트랩 작업 오류의 근본 원인을 식별하고 수정합니다. 그런 다음, 새 클러스터를 시작합니다.
**문제 해결 단계**
1. `ErrorData` 배열의 `amazon-s3-path` 값을 사용하여 Amazon S3에서 관련 부트스트랩 작업 스크립트를 찾습니다.
1. 인스턴스를 생성할 때 클러스터 로그를 활성화한 경우 자세한 내용은 `stdout` 로그를 참조하세요. 부트스트랩 작업에 대한 `stdout` 로그는 다음 Amazon S3 위치에서 찾을 수 있습니다.
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
클러스터 로그에 대한 자세한 내용은 [Amazon EMR 클러스터 로깅 및 디버깅 구성](emr-plan-debugging.md) 섹션을 참조하세요.
1. 부트스트랩 작업 실패를 확인하려면 `stdout` 로그의 예외와 `ErrorData`의 `return-code` 값을 검토합니다.
1. 이전 단계에서 찾은 조사 결과를 사용하여 예외를 방지하거나 예외 발생 시 적절하게 처리할 수 있도록 부트스트랩 작업을 수정합니다.
1. 업데이트된 부트스트랩 작업으로 새 클러스터를 시작합니다.
# BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY
## 개요
이 `BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY` 오류는 인스턴스가 지정된 Amazon S3 버킷에서 방금 다운로드한 부트스트랩 작업 스크립트를 기본 인스턴스에서 찾을 수 없음을 나타냅니다.
## 해결 방법
이 오류를 해결하려면 기본 인스턴스에 부트스트랩 작업 스크립트에 대한 적절한 액세스 권한이 있는지 확인합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
부트스트랩 작업이 실패한 기본 인스턴스의 ID.
**`bootstrap-action`**
실패한 부트스트랩 작업의 서수. `bootstrap-action` 값이 `1`인 스크립트가 인스턴스에서 실행하는 첫 번째 부트스트랩 작업입니다.
**`amazon-s3-path`**
실패한 부트스트랩 작업의 Amazon S3 위치.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
다음 단계를 수행하여 부트스트랩 작업 오류의 근본 원인을 식별하고 수정합니다. 그런 다음, 새 클러스터를 시작합니다.
1. Amazon S3에서 관련 부트스트랩 작업 스크립트를 찾으려면 `ErrorData` 배열의 `amazon-s3-path` 값을 사용합니다.
1. Amazon S3의 부트스트랩 작업 로그 파일을 검토하여 실패의 근본 원인을 식별합니다. Amazon EMR 로그를 보는 방법에 대한 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 섹션을 참조하세요.
**참고**
클러스터의 로그를 켜지 않은 경우 동일한 구성과 부트스트랩 작업을 사용하여 새 클러스터를 생성해야 합니다. 클러스터 로그가 켜져 있는지 확인하려면 [Amazon EMR 클러스터 로깅 및 디버깅 구성](emr-plan-debugging.md) 섹션을 참조하세요.
1. `stdout` 로그에서 부트스트랩 작업을 검토하고 기본 인스턴스의 `/emr/instance-controller/lib/bootstrap-actions` 폴더에 있는 파일을 삭제하는 사용자 지정 프로세스가 없는지 확인합니다. 부트스트랩 작업에 대한 `stdout` 로그는 다음 Amazon S3 위치에서 찾을 수 있습니다.
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
1. 업데이트된 부트스트랩 작업으로 새 클러스터를 시작합니다.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY
## 개요
`BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY` 오류는 필요한 소프트웨어를 설치할 때 기본 인스턴스에 충분한 디스크 공간이 없음을 나타냅니다.
## 해결 방법
이 오류를 해결하려면 기본 인스턴스에 루트 볼륨에 충분한 디스크 공간이 있어야 합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
디스크 공간이 부족한 기본 인스턴스의 ID입니다.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
1. 클러스터의 EBS 루트 디바이스 볼륨에 대한 모범 사례를 검토합니다. *Amazon EMR 관리 안내서*에서 [Amazon EBS 루트 디바이스 볼륨 사용자 지정](emr-custom-ami-root-volume-size.md) 섹션을 참조하세요.
1. EBS 루트 디바이스 볼륨 크기가 더 큰 새 클러스터를 시작합니다.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER
## 개요
`BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER` 오류는 필요한 소프트웨어를 설치할 때 하나 이상의 워커 인스턴스에 충분한 디스크 공간이 없음을 나타냅니다.
## 해결 방법
이 오류를 해결하려면 루트 볼륨에 워커 인스턴스의 디스크 공간이 충분한지 확인합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`worker-instance-ids`**
디스크 공간이 부족한 워커 인스턴스의 ID입니다.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
1. 클러스터의 EBS 루트 디바이스 볼륨에 대한 모범 사례를 검토합니다. *Amazon EMR 관리 안내서*에서 [Amazon EBS 루트 디바이스 볼륨 사용자 지정](emr-custom-ami-root-volume-size.md) 섹션을 참조하세요.
1. EBS 루트 디바이스 볼륨 크기가 더 큰 새 클러스터를 시작합니다.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY
## 개요
`BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY` 오류는 기본 인스턴스가 구성된 외부 Hive 메타스토어에 대한 연결을 설정할 수 없음을 나타냅니다.
## 해결 방법
이 오류를 해결하려면 외부 Hive 메타스토어가 올바르게 구성되어 있고 기본 인스턴스가 이 메타스토어에 연결할 수 있는지 확인합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
구성된 외부 Hive 메타스토어에 대한 연결을 설정할 수 없는 기본 인스턴스의 ID입니다.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
1. Hive용 외부 메타스토어를 구성하기 위한 모범 사례를 검토합니다. [Hive용 외부 메타스토어 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html)을 참조하세요.
1. 업데이트된 클러스터 구성으로 새 클러스터를 시작합니다.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER
## 개요
`BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER` 오류는 하나 이상의 워커 인스턴스가 구성된 외부 Hive 메타스토어에 대한 연결을 설정할 수 없음을 나타냅니다.
## 해결 방법
이 오류를 해결하려면 외부 Hive 메타스토어가 올바르게 구성되어 있고 워커 인스턴스가 이 메타스토어에 연결할 수 있는지 확인합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`worker-instance-ids`**
구성된 외부 Hive 메타스토어에 대한 연결을 설정할 수 없는 워커 인스턴스의 IDs.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
1. Hive용 외부 메타스토어를 구성하기 위한 모범 사례를 검토합니다. [Hive용 외부 메타스토어 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html)을 참조하세요.
1. 업데이트된 클러스터 구성으로 새 클러스터를 시작합니다.
# Amazon EMR의 내부 오류 코드
다음 섹션에서는 용량 없음 또는 용량 부족에 대한 코드를 포함하여 내부 오류 코드에 대한 문제 해결 정보를 제공합니다.
**Topics**
+ [INTERNAL\$1ERROR\$1EC2\$1INSUFFICIENT\$1CAPACITY\$1AZ](INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY](INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY](INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY.md)
# INTERNAL\$1ERROR\$1EC2\$1INSUFFICIENT\$1CAPACITY\$1AZ
## 개요
선택한 가용 영역에 Amazon EC2 인스턴스 유형 요청을 처리할 충분한 용량이 없을 경우 클러스터가 `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ` 오류로 종료됩니다. 클러스터에 대해 선택한 서브넷에 따라 가용 영역이 결정됩니다. Amazon EMR의 서브넷에 대한 자세한 내용은 [Amazon EMR에 대해 VPC에서 네트워킹 구성](emr-plan-vpc-subnet.md) 섹션을 참조하세요.
## 해결 방법
이 오류를 해결하려면 인스턴스 유형 구성을 수정하고 업데이트된 요청으로 새 클러스터를 생성합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`instance-type`**
용량이 부족한 인스턴스 유형.
**`availability-zone`**
서브넷이 확인하는 가용 영역.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
다음 단계를 수행하여 클러스터 구성 오류의 근본 원인을 식별하고 수정합니다.
+ 클러스터 구성에 대한 모범 사례를 검토합니다. *Amazon EMR 관리 안내서*에서 [스팟 인스턴스에 대한 Amazon EMR 클러스터 인스턴스 유형 및 모범 사례 구성](emr-plan-instances-guidelines.md) 섹션을 참조하세요.
+ 시작 문제를 해결하고 구성을 검토합니다. **Amazon EC2 사용 설명서에서 [인스턴스 시작 문제 해결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html)을 참조하세요.
+ 업데이트된 클러스터 구성으로 새 클러스터를 시작합니다.
# INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY
## 개요
인스턴스를 최고 스팟 가격 이하로 사용할 수 없으므로 Amazon EMR이 프라이머리 노드에 대한 스팟 인스턴스 요청을 이행할 수 없는 경우 클러스터가 종료되고 `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY` 오류가 발생합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 참조하세요.
## 해결 방법
이 오류를 해결하려면 가격 목표 범위 내에 있는 클러스터의 인스턴스 유형을 지정하거나 동일한 인스턴스 유형에 대한 가격 한도를 높입니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
실패한 클러스터의 기본 인스턴스 ID.
**`instance-type`**
용량이 부족한 인스턴스 유형.
**`availability-zone`**
서브넷이 있는 가용 영역.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
다음 단계를 수행하여 클러스터 구성 전략의 문제를 해결한 후 새 클러스터를 시작합니다.
1. Amazon EC2 스팟 인스턴스의 모범 사례를 검토하고 클러스터 구성 전략을 검토합니다. 자세한 내용은 [스팟 인스턴스에 대한 Amazon EMR 클러스터 인스턴스 유형 및 모범 사례 구성](emr-plan-instances-guidelines.md) 섹션 및 *Amazon EC2 사용 설명서*에서 [EC2 스팟 모범 사례](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)를 참조하세요.
1. 인스턴스 유형 구성 또는 가용 영역을 수정하고 업데이트된 요청으로 새 클러스터를 생성합니다.
1. 문제가 지속되면 기본 인스턴스의 온디맨드 용량을 사용합니다.
# INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY
## 개요
프라이머리 노드에 대한 스팟 인스턴스 요청을 처리할 용량이 충분하지 않으면 클러스터가 `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY` 오류와 함께 종료됩니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 참조하세요.
## 해결 방법
이 오류를 해결하려면 가격 목표 범위 내에 있는 클러스터의 인스턴스 유형을 지정하거나 동일한 인스턴스 유형에 대한 가격 한도를 높입니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`primary-instance-id`**
실패한 클러스터의 기본 인스턴스 ID.
**`instance-type`**
용량이 부족한 인스턴스 유형.
**`availability-zone`**
서브넷이 확인하는 가용 영역.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
다음 단계를 수행하여 클러스터 구성 전략의 문제를 해결한 후 새 클러스터를 시작합니다.
1. Amazon EC2 스팟 인스턴스의 모범 사례를 검토하고 클러스터 구성 전략을 검토합니다. 자세한 내용은 [스팟 인스턴스에 대한 Amazon EMR 클러스터 인스턴스 유형 및 모범 사례 구성](emr-plan-instances-guidelines.md) 섹션 및 *Amazon EC2 사용 설명서*에서 [EC2 스팟 모범 사례](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html)를 참조하세요.
1. 인스턴스 유형 구성을 수정하고 업데이트된 요청으로 새 클러스터를 생성합니다.
1. 문제가 지속되면 기본 인스턴스의 온디맨드 용량을 사용합니다.
# Amazon EMR에서의 검증 실패 오류 코드
다음 섹션에서는 검증 실패 오류 코드에 대한 문제 해결 정보를 제공합니다.
**Topics**
+ [VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME](VALIDATION_ERROR_INVALID_SSH_KEY_NAME.md)
+ [VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED](VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED.md)
# VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC
## 개요
클러스터 및 클러스터에서 참조하는 서브넷이 서로 다른 Virtual Private Cloud(VPC)에 속하는 경우 클러스터는 `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` 오류로 종료됩니다. VPC의 서브넷에서 인스턴스 플릿 구성을 포함하는 Amazon EMR에서 클러스터를 시작할 수 있습니다. 인스턴스 플릿에 대한 자세한 내용은 *Amazon EMR 관리 안내서*에서 [Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성](emr-instance-fleet.md) 섹션을 참조하세요.
## 해결 방법
이 오류를 해결하려면 클러스터와 동일한 VPC에 속한 서브넷을 사용합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`vpc`**
각 subnet:VPC 페어에서 서브넷이 속한 VPC의 ID.
**`subnet`**
각 subnet:VPC 페어에서 서브넷의 ID.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
오류를 식별하고 수정하려면 다음 단계를 수행합니다.
1. `ErrorData` 배열에 나열된 서브넷 ID를 검토하고 EMR 클러스터를 시작하려는 VPC에 속해 있는지 확인합니다.
1. 서브넷 구성을 수정합니다. 다음 방법 중 하나를 사용하여 VPC에서 사용 가능한 모든 퍼블릭 및 프라이빗 서브넷을 찾을 수 있습니다.
+ Amazon VPC 콘솔로 이동합니다. **서브넷을** 선택하고 클러스터의 내에 있는 모든 서브넷 AWS 리전 을 나열합니다. 퍼블릭 또는 프라이빗 서브넷만 찾으려면 **퍼블릭 IPv4 주소 자동 할당** 필터를 적용합니다. 클러스터가 사용하는 VPC에서 서브넷을 찾아 선택하려면 **VPC별 필터링** 옵션을 사용합니다. 서브넷을 생성하는 방법에 대한 자세한 내용은 *Amazon Virtual Private Cloud 사용 설명서*에서 [서브넷 생성](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html)을 참조하세요.
+ AWS CLI 를 사용하여 클러스터에서 사용하는 VPC에서 사용 가능한 모든 퍼블릭 및 프라이빗 서브넷을 찾습니다. 자세한 내용은 [describe-subnets](https://amazonaws.com/ec2/describe-subnets.html) API를 참조하세요. VPC에서 새 서브넷을 생성하려면 [create-subnet](https://amazonaws.com/ec2/create-subnet.html) API를 참조하세요.
1. 클러스터와 동일한 VPC의 서브넷을 사용하여 새 클러스터를 시작합니다.
# VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC
## 개요
클러스터 및 클러스터에 할당하는 보안 그룹이 서로 다른 Virtual Private Cloud(VPC)에 속하는 경우 클러스터는 `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` 오류로 종료됩니다. 보안 그룹에 대한 자세한 내용은 [Amazon EMR 관리형 및 추가 보안 그룹 지정](emr-sg-specify.md) 및 [Amazon EMR 클러스터의 보안 그룹으로 네트워크 트래픽 제어](emr-security-groups.md) 섹션을 참조하세요.
## 해결 방법
이 오류를 해결하려면 클러스터와 동일한 VPC에 속한 보안 그룹을 사용합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`vpc`**
각 security-group:VPC 페어에서 보안 그룹이 속한 VPC의 ID.
**`security-group`**
각 security-group:VPC 페어에서 보안 그룹 ID.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
오류를 식별하고 수정하려면 다음 단계를 수행합니다.
1. `ErrorData` 배열에 나열된 보안 그룹 ID를 검토하고 EMR 클러스터를 시작하려는 VPC에 속해 있는지 확인합니다.
1. Amazon VPC 콘솔로 이동합니다. **보안 그룹**을 선택하면 선택한 리전 내 모든 보안 그룹이 나열됩니다. 클러스터와 동일한 VPC에서 보안 그룹을 찾고 보안 그룹 구성을 수정합니다.
1. 클러스터와 동일한 VPC의 보안 그룹을 사용하여 새 클러스터를 시작합니다.
# VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME
## 개요
기본 인스턴스로의 SSH 연결에 유효하지 않은 Amazon EC2 키 페어를 사용하면 클러스터가 `VALIDATION_ERROR_INVALID_SSH_KEY_NAME` 오류로 종료됩니다. 키 페어 이름이 잘못되었거나 키 페어가 요청된에 존재하지 않을 수 있습니다 AWS 리전. 자세한 내용은 **Amazon EC2 사용 설명서에서 [Amazon EC2 키 페어 및 Linux 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)를 참조하세요.
## 해결 방법
이 오류를 해결하려면 유효한 SSH 키 페어 이름을 사용하여 새 클러스터를 생성합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`ssh-key`**
클러스터를 생성할 때 제공한 SSH 키 페어 이름.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
오류를 식별하고 수정하려면 다음 단계를 수행합니다.
1. *keypair*.pem 파일을 확인하고 Amazon EMR 콘솔에 표시되는 SSH 키의 이름과 일치하는지 확인합니다.
1. Amazon EC2 콘솔로 이동합니다. 클러스터에서 사용하는에서 사용한 SSH 키 이름을 사용할 수 AWS 리전 있는지 확인합니다. 의 상단에서 계정 ID AWS 리전 옆에 있는를 찾을 수 있습니다 AWS Management Console.
1. 유효한 SSH 키 이름으로 새 클러스터를 시작합니다.
# VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED
## 개요
클러스터의 AWS 리전 및 가용 영역이 하나 이상의 인스턴스 그룹에 지정된 인스턴스 유형을 지원하지 않으면 클러스터가 `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED` 오류로 종료됩니다. Amazon EMR은 리전 내 한 가용 영역에서 인스턴스 유형을 지원하지만 다른 가용 영역에서는 지원하지 않을 수 있습니다. 클러스터에 대해 선택한 서브넷에 따라 리전 내 가용 영역이 결정됩니다. Amazon EMR에서 지원하는 인스턴스 유형 및 리전 목록은 [Amazon EMR에서 지원되는 인스턴스 유형](emr-supported-instance-types.md) 섹션을 참조하세요.
## 해결 방법
이 오류를 해결하려면 클러스터를 요청한 리전 및 가용 영역에서 Amazon EMR이 지원하는 클러스터의 인스턴스 유형을 지정합니다.
실패한 EMR 클러스터의 문제를 해결하려면 `DescribeCluster` 및 `ListClusters` API에서 반환된 `ErrorDetail` 정보를 참조하세요. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오. `ErrorDetail` 내 `ErrorData` 배열은 이 오류 코드에 대한 다음 정보를 반환합니다.
**`instance-types`**
지원되지 않는 인스턴스 유형의 목록.
**`availability-zones`**
서브넷이 확인하는 가용 영역 목록.
**`public-doc`**
오류 코드에 대한 설명서의 퍼블릭 URL.
## 완료할 단계
오류를 식별하고 수정하려면 다음 단계를 수행합니다.
1. AWS CLI 를 사용하여 가용 영역에서 사용 가능한 인스턴스 유형을 검색합니다. 이렇게 하려면 `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` 명령을 사용하여 위치(AWS 리전 또는 가용 영역)별로 사용 가능한 인스턴스 유형을 필터링할 수 있습니다. 예를 들어, 다음 명령은 지정된 AZ, `us-east-2a`에서 제공되는 인스턴스 유형을 반환합니다.
```
aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=us-east-2a --region us-east-2 --query "InstanceTypeOfferings[*].[InstanceType]" --output text | sort
```
사용 가능한 인스턴스 유형을 찾는 방법에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형 찾기](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)를 참조하세요.
1. 클러스터와 동일한 리전 및 가용 영역에서 사용할 수 있는 인스턴스 유형을 결정한 후 다음 해결 방법 중 하나를 선택하여 계속합니다.
1. 새 클러스터를 생성하고, 선택한 인스턴스 유형이 Amazon EMR에서 지원하고 사용 가능한 가용 영역에서 클러스터의 서브넷을 선택합니다.
1. 실패한 클러스터와 동일한 리전 및 Amazon EC2 서브넷에서 Amazon EMR이 해당 위치에서 지원하는 인스턴스 유형으로 새 클러스터를 생성합니다.
Amazon EMR에서 지원하는 인스턴스 유형 및 리전 목록은 [Amazon EMR에서 지원되는 인스턴스 유형](emr-supported-instance-types.md) 섹션을 참조하세요. 인스턴스 유형의 기능을 비교하려면 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types)을 참조하세요.
# 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 경보를 설정하는 것이 좋습니다.
# Amazon EMR 작업 중 클러스터 입력 및 출력 오류
다음 오류는 클러스터 입력 및 출력 작업에서 일반적으로 발생합니다. 이 주제의 지침을 사용하여 구성 문제를 해결하고 구성을 확인합니다.
**Topics**
+ [Amazon Simple Storage Service(Amazon S3)에 대한 경로에 3개 이상의 슬래시가 있나요?](#threeslashes)
+ [입력 디렉터리를 재귀적으로 통과하려고 합니까?](#recurseinput)
+ [출력 디렉터리가 이미 있습니까?](#directoryexist)
+ [HTTP URL을 사용하여 리소스를 지정하려고 합니까?](#httpurl)
+ [잘못된 이름 형식을 사용하여 Amazon S3 버킷을 참조하고 있나요?](#validdnsname)
+ [Amazon S3에서 또는 Amazon S3로 데이터를 로드하는 데 문제가 있나요?](#emr-troubleshoot-errors-io-1)
## Amazon Simple Storage Service(Amazon S3)에 대한 경로에 3개 이상의 슬래시가 있나요?
Amazon S3 버킷을 지정할 때 URL 끝에 후행 슬래시를 포함해야 합니다. 예를 들어, 버킷을 "s3n://amzn-s3-demo-bucket"로 참조하는 대신에, "s3n://amzn-s3-demo-bucket/"을 사용해야 합니다. 그렇지 않으면 대부분의 경우 Hadoop에서 클러스터가 실패합니다.
## 입력 디렉터리를 재귀적으로 통과하려고 합니까?
Hadoop에서는 입력 디렉터리를 재귀적으로 검색하여 파일을 찾을 수 없습니다. /corpus/01/01.txt, /corpus/01/02.txt, /corpus/02/01.txt 등의 디렉터리 구조가 있으며 /corpus/를 클러스터의 입력 파라미터로 지정하는 경우, /corpus/ 디렉터리가 비어 있고 Hadoop에서는 하위 디렉터리의 콘텐츠가 확인되지 않으므로 어떠한 입력 파일도 찾을 수 없습니다. 마찬가지로, Hadoop에서는 Amazon S3 버킷의 하위 디렉터리를 재귀적으로 확인하지 않습니다.
입력 파일을 하위 디렉터리가 아니라 입력 디렉터리 또는 지정하는 Amazon S3 버킷 자체에 들어 있어야 합니다.
## 출력 디렉터리가 이미 있습니까?
이미 존재하는 출력 경로를 지정하는 경우 대부분의 경우 Hadoop에서 클러스터가 실패합니다. 즉, 클러스터를 일회성으로 실행하고 나서 동일한 파라미터를 사용하여 해당 클러스터를 다시 실행하는 경우 처음에는 작동하지만 그 이후에는 작동하지 않을 것입니다. 첫 번째 실행 후 출력 경로가 존재하므로 모든 이후 실행이 실패합니다.
## HTTP URL을 사용하여 리소스를 지정하려고 합니까?
Hadoop에서는 http:// 접두사를 사용하여 지정한 리소스 위치를 허용하지 않습니다. HTTP URL을 사용하여 리소스를 참조할 수 없습니다. 예를 들어, http://mysite/myjar.jar를 JAR 파라미터로 전달하면 클러스터가 실패합니다.
## 잘못된 이름 형식을 사용하여 Amazon S3 버킷을 참조하고 있나요?
"amzn-s3-demo-bucket1.1"과 같은 버킷 이름을 Amazon EMR에서 사용하려는 경우 Amazon EMR에서는 버킷 이름이 유효한 RFC 2396 호스트 이름이어야 하므로 클러스터에 실패합니다. 이름은 숫자로 끝날 수 없습니다. 또한, Hadoop 요구 사항으로 인해 Amazon EMR에 사용되는 Amazon S3 버킷 이름에는 소문자, 숫자, 마침표(.) 및 하이픈(-)만 포함되어야 합니다. Amazon S3 버킷 이름 형식 지정 방법에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [버킷 규제 및 제한](https://docs.aws.amazon.com/AmazonS3/latest/userguide/index.html?BucketRestrictions.html)을 참조하세요.
## Amazon S3에서 또는 Amazon S3로 데이터를 로드하는 데 문제가 있나요?
Amazon S3는 가장 널리 사용되는 Amazon EMR의 입출력 소스입니다. 흔하게 하는 실수 중 하나는 Amazon S3를 일반적인 파일 시스템처럼 다루는 것입니다. 클러스터 실행 시 파일 시스템과 Amazon S3 간의 차이를 고려해야 합니다.
+ Amazon S3에서 내부 오류가 발생하는 경우 애플리케이션은 이를 적절하게 처리하고 해당 작업을 다시 시도해야 합니다.
+ Amazon S3의 직접호출에 따른 결과가 반환되는 데 너무 오래 걸리는 경우 애플리케이션에서 Amazon S3를 직접 호출하는 빈도를 줄여야 할 수도 있습니다.
+ Amazon S3 버킷 내 모든 객체를 나열하는 작업은 상당한 비용이 드는 직접 호출입니다. 애플리케이션에서 이 작업을 수행하는 횟수를 최소화해야 합니다.
클러스터와 Amazon S3 간의 상호 작용 방식을 개선할 수 있는 몇 가지 방법이 있습니다.
+ Amazon EMR의 최신 릴리스 버전을 사용하여 클러스터를 시작합니다.
+ S3DistCp를 사용하여 Amazon S3 내부 및 외부로 객체를 이동합니다. S3DistCp는 오류 처리를 구현하고 Amazon S3의 요구 사항에 맞게 재시도 및 백오프합니다. 자세한 내용은 [S3DistCp를 사용한 분산 복사](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/UsingEMR_s3distcp.html)를 참조하세요.
+ 최종 일관성을 염두에 두고 애플리케이션을 설계합니다. 클러스터를 실행 중인 동안 중간 데이터 스토리지용으로 HDFS를 사용하고 Amazon S3는 초기 데이터를 입력하고 최종 결과를 출력하는 용도로만 사용합니다.
+ 클러스터에서 초당 200개 이상의 트랜잭션을 Amazon S3로 커밋하는 경우 [지원 센터](https://aws.amazon.com/contact-us/)에 문의하여 초당 대량 트랜잭션을 처리할 수 있도록 버킷을 준비하고 [Amazon S3 성능 팁 및 요령](https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/)에 설명된 주요 파티션 전략을 사용하는 방안을 고려합니다.
+ Hadoop 구성 설정 io.file.buffer.size를 65536로 설정합니다. 이렇게 하면 Hadoop에서 Amazon S3 객체를 탐색하는 데 드는 시간이 단축됩니다.
+ 클러스터에서 Amazon S3 동시성 문제가 발생하는 경우 Hadoop의 추론적 실행 기능을 비활성화하는 것을 고려합니다. 이 기능은 느린 클러스터 문제를 해결할 때도 유용합니다. `mapreduce.map.speculative` 및 `mapreduce.reduce.speculative` 속성을 `false`로 설정하여 이 작업을 수행할 수 있습니다. 클러스터를 시작할 때 `mapred-env` 구성 분류를 사용하여 이러한 값을 설정할 수 있습니다. 자세한 내용은 *Amazon EMR 릴리스 안내서*의 [애플리케이션 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html)을 참조하세요.
+ Hive 클러스터를 실행 중인 경우 [Amazon S3와 Hive 간에 데이터를 로드하는 데 문제가 있나요?](emr-troubleshoot-error-hive.md#emr-troubleshoot-error-hive-3) 섹션을 참조하세요.
자세한 내용은 *Amazon Simple Storage Service 사용 설명서*에서 [Amazon S3 오류 모범 사례](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html)를 참조하세요.
# Amazon EMR 클러스터 작업 중 권한 오류
권한 또는 자격 증명을 사용할 때 발생하는 일반적인 오류는 다음과 같습니다.
**Topics**
+ [SSH에 올바른 자격 증명을 전달하고 있습니까?](#correctcred)
+ [IAM를 사용하는 경우 올바로 설정된 Amazon EC2 정책이 있습니까?](#check-iam-permissions)
## SSH에 올바른 자격 증명을 전달하고 있습니까?
SSH를 사용하여 마스터 노드에 연결할 수 없는 경우 보안 자격 증명의 문제일 가능성이 가장 높습니다.
먼저 SSH 키를 포함하는 .pem 파일에 올바른 권한이 있는지 확인하세요. 다음 예제와 같이 chmod를 사용하여 .pem 파일의 사용 권한을 변경할 수 있습니다. 이 예제에서 mykey.pem을 자신의 .pem 파일 이름으로 바꿉니다.
```
1. chmod og-rwx mykey.pem
```
두 번째 가능성은 클러스터를 만들 때 지정한 키 페어를 사용하고 있지 않을 수 있다는 것입니다. 여러 키 페어를 작성한 경우 이렇게 하는 것이 쉽습니다. Amazon EMR 콘솔의 클러스터 세부 정보를 사용하거나 CLI의 `--describe` 옵션을 사용하여 클러스터를 만들 때 지정된 키 페어 이름을 확인합니다.
올바른 키 페어를 사용하고 있고 .pem 파일에 권한을 올바로 설정했음을 확인한 후에는 SSH를 사용하는 다음 명령을 통해 프라이머리 노드에 연결할 수 있습니다. 여기서 mykey.pem을 .pem 파일 이름으로 바꾸고 `hadoop@ec2-01-001-001-1.compute-1.amazonaws.com`을 프라이머리 노드의 퍼블릭 DNS 이름으로 바꿉니다(CLI의 `--describe` 옵션 또는 Amazon EMR 콘솔을 통해 사용 가능).
**중요**
Amazon EMR 클러스터 노드에 연결할 때 `hadoop` 로그인 이름을 사용해야 합니다. 그렇지 않으면 `Server refused our key`와 유사한 오류가 발생할 수 있습니다.
```
1. ssh -i mykey.pem hadoop@ec2-01-001-001-1.compute-1.amazonaws.com
```
자세한 내용은 [SSH를 사용하여 Amazon EMR 클러스터 프라이머리 노드에 연결](emr-connect-master-node-ssh.md) 단원을 참조하십시오.
## IAM를 사용하는 경우 올바로 설정된 Amazon EC2 정책이 있습니까?
Amazon EMR에서는 EC2 인스턴스를 노드로 사용하기 때문에 Amazon EMR의 사용자에게는 Amazon EMR이 사용자를 대신하여 그러한 인스턴스를 관리할 수 있도록 설정된 특정 Amazon EC2 정책도 필요합니다. 필요한 권한 세트가 없으면 Amazon EMR은 **'User account is not authorized to call EC2.'** 오류를 반환합니다.
Amazon EMR을 실행하기 위해 IAM 계정에서 설정해야 하는 Amazon EC2 정책에 대한 자세한 내용은 [Amazon EMR과 IAM의 작동 방식](security_iam_service-with-iam.md) 섹션을 참조하세요.
# Hive 클러스터 오류
일반적으로 **단계** 창에서 링크한 `syslog` 파일에서 Hive 오류의 원인을 찾을 수 있습니다. 문제를 확인할 수 없다면 Hadoop 작업 시도 오류 메시지를 확인하세요. **작업 시도** 창에서 링크하세요.
다음은 Hive 클러스터의 공통 오류입니다.
**Topics**
+ [Hive의 최신 버전을 사용하고 있습니까?](#emr-troubleshoot-error-hive-0)
+ [Hive 스크립트에서 구문 오류가 발생했습니까?](#emr-troubleshoot-error-hive-1)
+ [대화식으로 실행할 때 작업이 실패했습니까?](#emr-troubleshoot-error-hive-2)
+ [Amazon S3와 Hive 간에 데이터를 로드하는 데 문제가 있나요?](#emr-troubleshoot-error-hive-3)
## Hive의 최신 버전을 사용하고 있습니까?
Hive의 최신 버전은 모든 최신 패치와 버그 수정을 제공하며 문제를 해결할 수 있습니다.
## Hive 스크립트에서 구문 오류가 발생했습니까?
단계가 실패한 경우 Hive 스크립트를 실행한 단계는 로그의 `stdout` 파일을 확인하세요. 오류가 없으면 실패한 작업 시도에 대한 작업 시도 로그의 `syslog` 파일을 확인하세요. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
## 대화식으로 실행할 때 작업이 실패했습니까?
마스터 노드에서 Hive를 대화식으로 실행 중이며 클러스터가 실패한 경우 실패한 작업 시도에 대한 작업 시도 로그의 `syslog` 항목을 확인하세요. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
## Amazon S3와 Hive 간에 데이터를 로드하는 데 문제가 있나요?
Amazon S3에서 데이터에 액세스하는 데 문제가 있는 경우 먼저 [Amazon S3에서 또는 Amazon S3로 데이터를 로드하는 데 문제가 있나요?](emr-troubleshoot-errors-io.md#emr-troubleshoot-errors-io-1)에 나열된 가능한 원인을 확인합니다. 이러한 문제가 원인이 아니면 Hive와 관련된 다음 옵션을 고려하세요.
+ 사용 중인 Hive가 문제를 해결할 수 있는 최신 패치와 버그 수정이 모두 적용된 최신 버전인지 확인합니다. 자세한 내용은 [Apache Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html) 섹션을 참조하세요.
+ `INSERT OVERWRITE`를 사용하려면 Amazon S3 버킷 또는 폴더의 콘텐츠를 나열해야 합니다. 이 작업은 리소스를 많이 사용하는 작업입니다. 가능한 경우 Hive 목록을 보유하는 대신 경로를 수동으로 제거하고 기존 객체를 삭제하세요.
+ 5.0보다 이전 버전의 Amazon EMR 릴리스를 사용하는 경우 HiveQL에서 다음 명령을 사용하여 클러스터에서 로컬로 Amazon S3 나열 작업의 결과를 사전 캐시할 수 있습니다.
```
set hive.optimize.s3.query=true;
```
+ 가능한 경우 정적 파티션을 사용하세요.
+ Hive 및 Amazon EMR의 일부 버전에서는 테이블이 Hive가 예상한 것과 다른 위치에 저장되어 있기 때문에 ALTER TABLES 사용이 실패할 수 있습니다. 이때는 `/home/hadoop/conf/core-site.xml`에서 다음과 같이 추가하거나 업데이트하여 문제를 해결할 수 있습니다.
```
fs.s3n.endpoint
s3.amazonaws.com
```
# Amazon EMR 클러스터 작업 중 VPC 오류
다음은 Amazon EMR에서 VPC 구성과 관련하여 일반적으로 발생하는 오류입니다.
**Topics**
+ [잘못된 서브넷 구성](#emr-troubleshoot-error-gateway)
+ [DHCP 옵션 세트 누락](#emr-troubleshoot-error-dhcp)
+ [권한 오류](#emr-troubleshoot-error-denied)
+ [`START_FAILED`를 발생시키는 오류](#emr-troubleshoot-error-vpc-dns)
+ [클러스터 `Terminated with errors` 및 NameNode 시작 실패](#emr-troubleshoot-namenode-dns)
## 잘못된 서브넷 구성
**클러스터 세부 정보** 페이지의 **상태** 필드에는 다음과 비슷한 오류가 표시됩니다.
`The subnet configuration was invalid: Cannot find route to InternetGateway in main RouteTable rtb-id for vpc vpc-id.`
이 문제를 해결하려면 인터넷 게이트웨이를 생성하여 VPC에 연결해야 합니다. 자세한 내용은 [VPC에 인터넷 게이트웨이 추가](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html) 섹션을 참조하세요.
또는 **Enable DNS resolution**(DNS 확인 활성화) 및 **Enable DNS hostname support**(DNS 호스트 이름 지원 활성화)가 활성화된 상태로 VPC를 구성했는지 확인합니다. 자세한 내용은 [VPC에서 DNS 사용하기](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html) 섹션을 참조하세요.
## DHCP 옵션 세트 누락
클러스터 시스템 로그(syslog)에 다음과 유사한 오류와 함께 단계 실패가 표시됩니다.
` ERROR org.apache.hadoop.security.UserGroupInformation (main): PriviledgedActionException as:hadoop (auth:SIMPLE) cause:java.io.IOException: org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM. `
또는
`ERROR org.apache.hadoop.streaming.StreamJob (main): Error Launching job : org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM.`
이 문제를 해결하려면 파라미터가 다음 값으로 설정된 DHCP 옵션 세트를 포함하는 VPC를 구성해야 합니다.
**참고**
AWS GovCloud(미국 서부) 리전을 사용하는 경우 다음 예제에 사용된 값 **us-gov-west-1.compute.internal** 대신 domain-name을 로 설정합니다.
+ **domain-name** = **ec2.internal**
리전이 미국 동부(버지니아 북부)인 경우 **ec2.internal**을 사용합니다. 다른 리전의 경우 *region-name***.compute.internal**을 사용합니다. 예를 들어, us-west-2에서 **domain-name**=**us-west-2.compute.internal**을 사용합니다.
+ **domain-name-servers** = **AmazonProvidedDNS**
자세한 내용은 [DHCP 옵션 세트](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html) 섹션을 참조하세요.
## 권한 오류
`stderr` 로그에 표시되는 단계 오류는 Amazon S3 리소스에 적절한 권한이 없음을 의미합니다. 이 오류는 403 오류로, 다음과 비슷합니다.
```
Exception in thread "main" com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: REQUEST_ID
```
ActionOnFailure가 `TERMINATE_JOB_FLOW`로 설정된 경우 클러스터가 `SHUTDOWN_COMPLETED_WITH_ERRORS` 상태로 종료됩니다.
이 문제를 해결하는 몇 가지 방법은 다음과 같습니다.
+ VPC 내에서 Amazon S3 버킷 정책을 사용하려는 경우 VPC 엔드포인트를 생성하고 엔드포인트 생성 시 정책 옵션에서 **모두 허용**을 선택하여 모든 버킷에 액세스 권한을 부여해야 합니다.
+ S3 리소스와 연결된 모든 정책에 클러스터를 시작할 VPC를 포함해야 합니다.
+ 클러스터에서 다음 명령을 실행하여 버킷에 액세스할 수 있는 확인합니다.
```
hadoop fs -copyToLocal s3://path-to-bucket /tmp/
```
+ 클러스터의 `log4j.logger.org.apache.http.wire` 파일에서 `DEBUG` 파라미터를 `/home/hadoop/conf/log4j.properties`로 설정하여 자세한 디버깅 정보를 가져올 수 있습니다. 클러스터에서 버킷에 대한 액세스를 시도한 후 `stderr` 로그 파일을 확인할 수 있습니다. 로그 파일은 자세한 정보를 제공합니다.
```
Access denied for getting the prefix for bucket - us-west-2.elasticmapreduce with path samples/wordcount/input/
15/03/25 23:46:20 DEBUG http.wire: >> "GET /?prefix=samples%2Fwordcount%2Finput%2F&delimiter=%2F&max-keys=1 HTTP/1.1[\r][\n]"
15/03/25 23:46:20 DEBUG http.wire: >> "Host: us-west-2.elasticmapreduce.s3.amazonaws.com[\r][\n]"
```
## `START_FAILED`를 발생시키는 오류
AMI 3.7.0 이전에는 호스트 이름에 지정되어 있는 VPC의 경우, Amazon EMR이 서브넷의 내부 호스트 이름을 사용자 지정 도메인 주소와 매핑합니다(예: `ip-X.X.X.X.customdomain.com.tld`). 예를 들어, 호스트 이름이 `ip-10.0.0.10`이고 VPC에 customdomain.com으로 설정된 도메인 이름 옵션이 있는 경우 Amazon EMR에 의해 매핑되는 결과 호스트 이름은 `ip-10.0.1.0.customdomain.com`입니다. 호스트 이름을 10.0.0.10으로 확인하는 항목이 `/etc/hosts`에 추가됩니다. 이 동작은 AMI 3.7.0에서 변경되었으며 이제는 Amazon EMR이 VPC의 DHCP 구성 전체를 인식합니다. 이전에는 고객이 부트스트랩 작업을 사용하여 호스트 이름 매핑을 지정할 수도 있었습니다.
이 동작을 유지하려면 DNS를 제공하고 사용자 지정 도메인에 필요한 확인 설정을 전달해야 합니다.
## 클러스터 `Terminated with errors` 및 NameNode 시작 실패
사용자 지정 DNS 도메인 이름을 사용하는 EMR 클러스터를 VPC에서 시작하려는 경우 해당 클러스터가 실패하고 콘솔에 다음과 같은 오류 메시지가 표시될 수 있습니다.
```
Terminated with errors On the master instance(instance-id), bootstrap action 1 returned a non-zero return code
```
이 실패는 NameNode를 시작할 수 없어서 발생한 것입니다. 따라서 NameNode 로그에 다음과 같은 오류가 표시되며, 이때 Amazon S3 URI 양식은 `s3://amzn-s3-demo-bucket/logs/cluster-id/daemons/master instance-id/hadoop-hadoop-namenode-master node hostname.log.gz`입니다.
```
2015-07-23 20:17:06,266 WARN
org.apache.hadoop.hdfs.server.namenode.FSNamesystem (main): Encountered exception
loading fsimage java.io.IOException: NameNode is not formatted.
at
org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:212)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1020)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:739)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:537)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:596)
at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:765)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:749)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1441)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1507)
```
이 오류는 VPC에서 EMR 클러스터 시작 시 EC2 인스턴스 하나에 정규화된 도메인 이름의 여러 세트가 사용되는 경우에 발생할 수 있는 잠재적인 문제로, 이 경우 AWS제공 DNS 서버와 사용자 지정 사용자 제공 DNS 서버가 둘 다 사용됩니다. EMR 클러스터에서 노드를 지정하는 데 사용되는 A 레코드에 대한 포인터(PTR) 레코드를 사용자 제공 DNS 서버에서 제공하지 않는 경우, 이 방식으로 구성하면 클러스터가 시작되지 않습니다. 해결 방법은 EC2 인스턴스가 VPC의 서브넷에서 시작될 때 생성되는 모든 A 레코드에 대해 PTR 레코드 1개를 추가해야 합니다.
# Amazon EMR 클러스터 스트리밍 오류
일반적으로 `syslog` 파일에서 스트리밍 오류의 원인을 찾을 수 있습니다. **단계** 창에서 이 파일에 연결합니다.
다음은 스트리밍 클러스터에 일반적인 오류입니다.
**Topics**
+ [데이터가 잘못된 형식으로 매퍼에 전송되고 있습니까?](#emr-troubleshoot-error-streaming-1)
+ [스크립트가 시간 초과되고 있습니까?](#emr-troubleshoot-error-streaming-2)
+ [잘못된 스트리밍 인수를 전달하고 있습니까?](#invalidarg)
+ [스크립트가 오류로 종료되었습니까?](#emr-troubleshoot-error-streaming-3)
## 데이터가 잘못된 형식으로 매퍼에 전송되고 있습니까?
이 경우에 해당하는지 확인하려면 작업 시도 로그에 있는 실패한 작업 시도의 `syslog` 파일에서 오류 메시지를 찾습니다. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
## 스크립트가 시간 초과되고 있습니까?
매퍼 또는 reducer 스크립트의 기본 제한 시간은 600초입니다. 스크립트가 이 시간보다 오래 걸리면 작업 시도가 실패합니다. 작업 시도 로그에 있는 실패한 작업 시도의 `syslog` 파일을 확인하여 이 경우에 해당하는지 확인할 수 있습니다. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
`mapred.task.timeout` 구성 설정에 대해 새 값을 설정하여 시간 제한을 변경할 수 있습니다. 이 설정은 해당 시간이 경과한 후 Amazon EMR에서 입력을 읽거나 출력을 쓰거나 상태 문자열을 업데이트하지 않은 작업을 종료하는 밀리초 수를 지정합니다. 추가 스트리밍 인수 `-jobconf mapred.task.timeout=800000`를 전달하여 이 값을 업데이트할 수 있습니다.
## 잘못된 스트리밍 인수를 전달하고 있습니까?
Hadoop 스트리밍은 다음 인수만 지원합니다. 아래 나열된 인수 이외의 다른 인수를 전달하면 클러스터가 실패합니다.
```
1. -blockAutoGenerateCacheFiles
2. -cacheArchive
3. -cacheFile
4. -cmdenv
5. -combiner
6. -debug
7. -input
8. -inputformat
9. -inputreader
10. -jobconf
11. -mapper
12. -numReduceTasks
13. -output
14. -outputformat
15. -partitioner
16. -reducer
17. -verbose
```
또한 Hadoop 스트리밍은 Java 구문을 사용하여 전달된 인수, 즉 앞에 단일 하이픈이 있는 인수만 인식합니다. 앞에 이중 하이픈이 있는 인수를 전달하면 클러스터가 실패합니다.
## 스크립트가 오류로 종료되었습니까?
매퍼 또는 reducer 스크립트가 오류로 종료될 경우 실패한 작업 시도에 대한 작업 시도 로그의 `stderr` 파일에서 오류를 찾을 수 있습니다. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
# Amazon EMR: 사용자 지정 JAR 클러스터 오류
다음은 사용자 지정 JAR 클러스터에 일반적인 오류입니다.
**Topics**
+ [작업을 생성하기 전에 JAR에서 예외가 발생합니까?](#emr-troubleshoot-error-custom-jar-1)
+ [JAR이 맵 작업 내에서 오류를 발생합니까?](#emr-troubleshoot-error-custom-jar-2)
## 작업을 생성하기 전에 JAR에서 예외가 발생합니까?
Hadoop 작업을 생성하는 동안 사용자 지정 JAR의 기본 프로그램에서 예외가 발생할 경우, 이 예외를 볼 수 있는 가장 좋은 위치는 단계 로그의 `syslog` 파일입니다. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
## JAR이 맵 작업 내에서 오류를 발생합니까?
입력 데이터를 처리하는 중에 사용자 지정 JAR 및 매퍼가 예외를 발생할 경우, 이를 볼 수 있는 가장 좋은 위치는 작업 시도 로그의 `syslog` 파일입니다. 자세한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 단원을 참조하십시오.
# Amazon EMR AWS GovCloud(미국 서부) 오류
AWS GovCloud(미국 서부) 리전은 보안, 구성 및 기본 설정에서 다른 리전과 다릅니다. 따라서 보다 일반적인 문제 해결 권장 사항을 사용하기 전에 다음 체크리스트를 사용하여 AWS GovCloud(미국 서부) 리전과 관련된 Amazon EMR 오류를 해결합니다.
+ IAM 역할이 올바르게 구성되었는지 확인합니다. 자세한 내용은 [서비스 및 리소스에 대한 Amazon EMR 권한에 대한 IAM AWS 서비스 역할 구성](emr-iam-roles.md) 단원을 참조하십시오.
+ VPC 구성에 올바르게 구성된 DNS 확인/호스트 이름 지원, 인터넷 게이트웨이 및 DHCP 옵션 설정 파라미터가 있는지 확인합니다. 자세한 내용은 [Amazon EMR 클러스터 작업 중 VPC 오류](emr-troubleshoot-error-vpc.md) 단원을 참조하십시오.
이러한 단계를 통해 문제가 해결되지 않으면 일반적인 Amazon EMR 오류를 해결하기 위한 단계로 계속합니다. 자세한 내용은 [Amazon EMR의 일반적인 오류 컬렉션](emr-troubleshoot-errors.md) 단원을 참조하십시오.
## 누락된 클러스터 찾기
콘솔 목록 또는 `ListClusters` API에서 클러스터가 누락된 경우 다음을 확인합니다.
+ 완료 시점으로부터 클러스터 수명이 2개월 미만인지 확인합니다. Amazon EMR은 2개월 동안 무료로 완료된 클러스터에 대한 메타데이터 정보를 보존합니다. 완료된 클러스터는 콘솔에서 삭제할 수 없습니다. 대신 Amazon EMR은 2개월 후에 완료된 클러스터를 자동으로 삭제합니다.
+ 클러스터를 볼 수 있는 역할 권한이 있는지 확인합니다.
+ 클러스터가 있는 AWS 리전 동일한를 보고 있는지 확인합니다.
# 오류 코드와 함께 실패한 Amazon EMR 클러스터 문제 해결
이 섹션에서는 클러스터 실패 문제를 해결하는 과정을 안내합니다. 여기서 클러스터 실패란 클러스터가 오류 코드로 종료되는 경우를 의미합니다.
**참고**
EMR 클러스터가 오류와 함께 종료되면 `DescribeCluster` 및 `ListClusters` API는 오류 코드와 오류 메시지를 반환합니다. 일부 클러스터 오류의 경우 `ErrorDetail` 데이터 배열도 장애 문제를 해결하는 데 도움이 될 수 있습니다. 자세한 내용은 [Amazon EMR에서 오류 코드 및 ErrorDetail 정보](emr-troubleshoot-error-errordetail.md) 단원을 참조하십시오.
클러스터가 실행되지만 결과를 반환하는 데 시간이 오래 걸리는 경우 [느린 Amazon EMR 클러스터 문제 해결](emr-troubleshoot-slow.md) 섹션을 참조하세요.
**Topics**
+ [1단계: Amazon EMR 클러스터 관련 문제에 대한 데이터 수집](emr-troubleshoot-failed-1.md)
+ [2단계: 환경 점검](emr-troubleshoot-failed-2.md)
+ [3단계: 최근 상태 변경 살펴보기](emr-troubleshoot-failed-3.md)
+ [4단계: Amazon EMR 로그 파일 검사](emr-troubleshoot-failed-4.md)
+ [5단계: Amazon EMR 클러스터 단계별 테스트](emr-troubleshoot-failed-5-test-steps.md)
# 1단계: Amazon EMR 클러스터 관련 문제에 대한 데이터 수집
클러스터 문제를 해결하는 첫 번째 단계는 잘못된 부분에 대한 정보를 수집하고 클러스터의 현재 상태 및 구성을 가져오는 것입니다. 이 정보는 다음 단계에서 문제의 가능한 원인을 확인하거나 배제하는 데 사용됩니다.
## 문제 정의
문제를 명확하게 정의하는 것부터 시작해야 합니다. 다음과 같이 자문하세요.
+ 무엇을 기대했는가? 실제로는 어떤 일이 발생했는가?
+ 이 문제는 언제 처음 발생했는가? 이후 얼마나 자주 발생했는가?
+ 이로 인해 클러스터를 구성하거나 실행하는 방식이 바뀌었는가?
## 클러스터 세부 정보
다음 클러스터 세부 정보는 문제를 조사하는 데 유용합니다. 이 정보를 수집하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터 상태 및 세부 정보 보기](emr-manage-view-clusters.md) 섹션을 참조하세요.
+ 클러스터 식별자. (작업 흐름 식별자라고도 함)
+ AWS 리전 및 클러스터가 시작된 가용 영역.
+ 마지막 상태 변경의 세부 정보를 포함한 클러스터의 상태입니다.
+ 마스터, 코어, 작업 노드에 지정된 EC2 인스턴스 유형 및 수입니다.
# 2단계: 환경 점검
Amazon EMR은 웹 서비스 및 오픈 소스 소프트웨어로 이루어진 에코시스템에서 일부로 포함되어 작동합니다. 이러한 종속성에 영향을 미치는 요인이 Amazon EMR의 성능에도 영향을 줄 수 있습니다.
**Topics**
+ [서비스 중단 확인](#emr-troubleshoot-failed-2-outages)
+ [사용 한도 확인](#emr-troubleshoot-failed-2-limits)
+ [릴리스 버전 확인](#emr-troubleshoot-failed-2-ami)
+ [Amazon VPC 서브넷 구성 확인](#emr-troubleshoot-failed-2-vpc)
## 서비스 중단 확인
Amazon EMR은 내부적으로 여러 Amazon Web Services를 사용합니다. Amazon EC2에서 가상 서버를 실행하고, Amazon S3에 데이터와 스크립트를 저장하며, 지표를 CloudWatch에 보고합니다. 이러한 서비스를 중단시키는 이벤트는 드물지만, 발생할 경우 Amazon EMR에서 문제가 발생할 수 있습니다.
더 진행하기 전에 [서비스 상태 대시보드](https://status.aws.amazon.com/)를 확인하세요. 클러스터를 시작한 리전을 점검하여 이러한 서비스에 중단 이벤트가 발생했는지 확인합니다.
## 사용 한도 확인
대규모 클러스터를 시작하거나 여러 클러스터를 동시에 시작했거나 다른 사용자 AWS 계정 와를 공유하는 사용자인 경우 AWS 서비스 제한을 초과하여 클러스터가 실패했을 수 있습니다.
Amazon EC2는 단일 AWS 리전에서 실행되는 가상 서버 인스턴스 수를 온디맨드 또는 예약 인스턴스 20개로 제한합니다. 노드가 20개 이상인 클러스터를 시작하거나에서 활성화된 총 EC2 인스턴스 수가 20개를 초과하는 클러스터 AWS 계정 를 시작하는 경우 클러스터는 필요한 모든 EC2 인스턴스를 시작할 수 없으며 실패할 수 있습니다. 이 경우 Amazon EMR에서 `EC2 QUOTA EXCEEDED` 오류를 반환합니다. Amazon EC2 인스턴스 제한 AWS 증가 요청 애플리케이션을 제출하여 계정에서 실행할 수 있는 EC2 인스턴스 수를 늘리도록에 요청할 수 있습니다. [ Amazon EC2 ](https://aws.amazon.com/contact-us/ec2-request/)
또 한 가지 사용량 한도를 초과하게 되는 상황으로는, 클러스터가 종료된 후 모든 리소스를 해제하기까지 시간이 지연되는 경우를 들 수 있습니다. 구성에 따라 클러스터를 완전히 종료하고 할당된 리소스를 해제하는 데 5-20분이 걸릴 수도 있습니다. 클러스터를 시작하려 할 때 `EC2 QUOTA EXCEEDED` 오류가 발생하는 경우 최근에 종료된 클러스터의 리소스가 아직 해제되지 않았기 때문일 수 있습니다. 이 경우 [Amazon EC2 할당량 증가를 요청](https://aws.amazon.com/contact-us/ec2-request/)하거나 20분을 기다린 후 클러스터를 다시 시작할 수 있습니다.
Amazon S3에서는 한 계정에서 생성하는 버킷 수를 100개로 제한합니다. 클러스터가 이 한도를 초과하는 새 버킷을 생성하면 버킷 생성에 실패하며, 클러스터에 장애가 발생할 수 있습니다.
## 릴리스 버전 확인
클러스터를 시작하는 데 사용된 릴리스 레이블과 최신 Amazon EMR 릴리스를 비교합니다. 각 Amazon EMR 릴리스에는 새 애플리케이션, 기능, 패치 및 버그 수정 사항 등 향상 기능이 포함되어 있습니다. 최신 릴리스 버전에서는 클러스터에 영향을 미치는 문제가 이미 수정되었을 수도 있습니다. 가능하면 최신 버전을 사용하여 클러스터를 다시 실행합니다.
## Amazon VPC 서브넷 구성 확인
클러스터를 Amazon VPC 서브넷에서 시작한 경우 [Amazon EMR에 대해 VPC에서 네트워킹 구성](emr-plan-vpc-subnet.md)에서 설명한 대로 서브넷을 구성해야 합니다. 또한 클러스터를 시작하는 서브넷에 탄력적 가용 IP 주소가 충분하여 클러스터의 각 노드에 하나씩 할당할 수 있는지 확인합니다.
# 3단계: 최근 상태 변경 살펴보기
최근 상태 변경은 마지막으로 발생한 클러스터 상태 변경에 대한 정보를 제공합니다. 클러스터의 상태가 `FAILED`로 변경되므로 이 정보를 통해 잘못된 부분이 무엇인지 파악할 수 있습니다. 예를 들어, 스트리밍 클러스터를 시작하고 Amazon S3에 이미 존재하는 출력 위치를 지정할 경우 클러스터의 마지막 상태는 'Streaming output directory already exists'로 설정되며 클러스터가 실패합니다.
클러스터 세부 정보 창을 통해 콘솔에서, `list-steps` 또는 `describe-cluster` 인수를 사용하여 CLI에서, 또는 `DescribeCluster` 및 `ListSteps` 작업을 사용하여 API에서 마지막 상태 변경 값을 찾아볼 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터 상태 및 세부 정보 보기](emr-manage-view-clusters.md) 단원을 참조하십시오.
# 4단계: Amazon EMR 로그 파일 검사
다음 단계는 로그 파일을 살펴보면서 오류 코드 또는 그 외 클러스터에 문제가 발생했을 가능성을 찾아내는 것입니다. 제공되는 로그 파일, 찾을 수 있는 위치, 확인하는 방법에 대한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 섹션을 참조하세요.
발생한 문제를 파악하려면 약간의 조사 작업이 필요할 수 있습니다. Hadoop은 클러스터에 있는 다양한 노드에서 작업을 시도하며 작업을 실행합니다. Amazon EMR은 추론적 작업 시도를 시작하여 먼저 완료되지 않은 다른 작업 시도를 종료할 수 있습니다. 그러면 컨트롤러, stderr 및 syslog 로그 파일에 실시간으로 로깅되는 중요한 활동이 생성됩니다. 또한 여러 차례의 작업 시도가 동시에 실행되지만 로그 파일은 결과를 선형으로만 표시할 수 있습니다.
부트스트랩 작업 로그에 오류가 있거나 클러스터 시작 중 예기치 못한 구성 변경이 발생하지 않았는지 검사하는 것으로 시작합니다. 이를 시작으로 단계 로그를 살펴보며 오류가 있는 단계의 일부로 시작된 Hadoop 작업을 찾아냅니다. Hadoop 작업 로그를 살펴보며 장애가 발생한 작업 시도를 찾아냅니다. 작업 시도 로그에는 작업 시도를 실패로 만든 요인에 대한 세부 정보가 포함됩니다.
다음 섹션에서는 다양한 로그 파일을 이용해 클러스터에 발생한 오류를 찾아내는 방법을 설명합니다.
## 부트스트랩 작업 로그 확인
부트스트랩 작업은 클러스터가 시작될 때 스크립트를 실행합니다. 이 작업은 흔히 클러스터에 추가 소프트웨어를 설치하거나 구성 설정의 기본값을 변경하는 용도로 사용됩니다. 이 로그를 보면 클러스터 설정 중에 발생한 오류뿐 아니라 성능에 영향을 미칠 수 있는 구성 설정 변경에 대한 통찰을 얻을 수 있습니다.
## 단계 로그 확인
네 가지 유형의 단계 로그가 있습니다.
+ **controller** - 단계 실행을 시도하는 동안 발생한 오류로 인해 생성된 Amazon EMR에서 생성된 파일을 포함합니다. 단계를 로드하는 동안 장애가 발생하면 이 로그에서 스택 트레이스를 볼 수 있습니다. 애플리케이션 로드 또는 액세스 중에 발생한 오류는 매퍼 파일 누락 오류와 마찬가지로 주로 여기에 수록됩니다.
+ **stderr** - 단계 처리 중에 발생한 오류 메시지를 포함합니다. 애플리케이션 로딩 오류는 주로 여기에 수록됩니다. 이 로그에 스택 트레이스가 포함되기도 합니다.
+ **stdout** - 매퍼 및 reducer 실행 파일이 생성한 상태를 포함합니다. 애플리케이션 로딩 오류는 주로 여기에 수록됩니다. 이 로그에 애플리케이션 오류 메시지가 포함되기도 합니다.
+ **syslog** - Apache 및 Hadoop과 같은 Amazon 이외 소프트웨어의 로그를 포함합니다. 스트리밍 오류는 주로 여기에 수록됩니다.
stderr에서 명시적 오류 여부를 검사합니다. stderr에 짧은 오류 목록이 표시된 경우, 오류가 표시되며 단계가 갑자기 중지한 것입니다. 이 현상은 클러스터에서 매퍼와 reducer 애플리케이션 실행 중에 발생한 오류로 인해 가장 자주 발생합니다.
syslog와 컨트롤러의 마지막 줄에 오류나 장애 발생 알림이 있는지 살펴봅니다. 실패한 작업에 대한 메시지, 특히 "Job Failed"가 있는지 살펴봅니다.
## 작업 시도 로그 확인
이전의 단계 로그 분석에 실패한 작업이 하나 이상 포함된 경우, 해당하는 작업 시도의 로그에 더 자세한 오류 정보가 있는지 조사합니다.
# 5단계: Amazon EMR 클러스터 단계별 테스트
오류 원인을 추적하려 할 때 유용한 기술은 클러스터를 다시 시작하고 단계를 하나씩 제출하는 것입니다. 이렇게 하면 다음 단계를 처리하기 전에 각 단계의 결과를 확인할 수 있으므로 실패한 단계를 수정하여 다시 실행할 수 있습니다. 또한 입력 데이터를 한 번만 로드하면 되다는 이점도 있습니다.
**단계별로 클러스터를 테스트하려면**
1. 연결 유지 및 종료 방지 기능이 모두 활성화된 상태로 새 클러스터를 시작합니다. 연결 유지 기능은 모든 보류 단계를 처리한 후에도 클러스터를 실행 중 상태로 유지합니다. 종료 방지는 오류 발생 시 클러스터가 종료되지 않도록 합니다. 자세한 내용은 [단계 실행 후 계속 진행하거나 종료하도록 Amazon EMR 클러스터 구성](emr-plan-longrunning-transient.md) 및 [종료 방지를 사용하여 Amazon EMR 클러스터가 실수로 종료되지 않도록 보호](UsingEMR_TerminationProtection.md) 섹션을 참조하세요.
1. 단계를 클러스터로 제출합니다. 자세한 내용은 [Amazon EMR 클러스터에 작업 제출](emr-work-with-steps.md) 단원을 참조하십시오.
1. 단계에서 처리가 완료되면 단계 로그 파일에서 오류가 있는지 확인합니다. 자세한 내용은 [4단계: Amazon EMR 로그 파일 검사](emr-troubleshoot-failed-4.md) 단원을 참조하십시오. 이러한 로그 파일을 찾아보는 가장 빠른 방법은 마스터 노드에 연결하여 그곳에서 로그 파일을 보는 것입니다. 단계가 일정 시간 동안 실행되거나, 완료되거나, 실패할 때까지 단계 로그 파일이 나타나지 않습니다.
1. 단계가 오류가 없이 성공한 경우 다음 단계를 실행합니다. 오류가 있는 경우에는 로그 파일에서 오류를 찾아봅니다. 코드에 오류가 있는 경우 코드를 수정하여 단계를 다시 실행합니다. 모든 단계가 오류 없이 실행될 때까지 계속합니다.
1. 클러스터 디버깅이 완료되어 클러스터를 종료하려는 경우 수동으로 종료해야 합니다. 종료 방지 기능이 활성화된 상태로 클러스터를 시작했기 때문입니다. 자세한 내용은 [종료 방지를 사용하여 Amazon EMR 클러스터가 실수로 종료되지 않도록 보호](UsingEMR_TerminationProtection.md) 단원을 참조하십시오.
# 느린 Amazon EMR 클러스터 문제 해결
이 섹션에서는 여전히 실행 중이지만 결과를 반환하는 데 오랜 시간이 걸리는 클러스터의 문제 해결 프로세스를 연습합니다. 클러스터가 오류 코드로 종료된 경우 수행할 작업에 대한 자세한 내용은 [오류 코드와 함께 실패한 Amazon EMR 클러스터 문제 해결](emr-troubleshoot-failed.md) 섹션을 참조하세요.
Amazon EMR을 사용하면 클러스터에서 인스턴스의 수와 종류를 지정할 수 있습니다. 이러한 지정은 데이터 처리가 완료되는 속도에 영향을 주는 기본 수단입니다. 고려할 수 있는 한 가지 방법은 이번에는 더 큰 리소스가 있는 EC2 인스턴스를 지정하거나 클러스터에 더 많은 수의 인스턴스를 지정하여 클러스터를 다시 실행하는 것입니다. 자세한 내용은 [Amazon EMR 클러스터 하드웨어 및 네트워킹 구성](emr-plan-instances.md) 단원을 참조하십시오.
다음 주제에서는 느린 클러스터의 다른 원인을 식별하는 프로세스를 연습합니다.
**Topics**
+ [1단계: Amazon EMR 클러스터 관련 문제에 대한 데이터 수집](emr-troubleshoot-slow-1.md)
+ [2단계: EMR 클러스터 환경 확인](emr-troubleshoot-slow-2.md)
+ [3단계: Amazon EMR 클러스터에 대한 로그 파일 검사](emr-troubleshoot-slow-3.md)
+ [4단계: Amazon EMR 클러스터 및 인스턴스 상태 확인](emr-troubleshoot-slow-4.md)
+ [5단계: 일시 중단된 그룹 확인](emr-troubleshoot-slow-5.md)
+ [6단계: Amazon EMR 클러스터의 구성 설정 검토](emr-troubleshoot-slow-6.md)
+ [7단계: Amazon EMR 클러스터의 입력 데이터 검사](emr-troubleshoot-slow-7.md)
# 1단계: Amazon EMR 클러스터 관련 문제에 대한 데이터 수집
클러스터 문제를 해결하는 첫 번째 단계는 잘못된 부분에 대한 정보를 수집하고 클러스터의 현재 상태 및 구성을 가져오는 것입니다. 이 정보는 다음 단계에서 문제의 가능한 원인을 확인하거나 배제하는 데 사용됩니다.
## 문제 정의
문제를 명확하게 정의하는 것부터 시작해야 합니다. 다음과 같이 자문하세요.
+ 무엇을 기대했는가? 실제로는 어떤 일이 발생했는가?
+ 이 문제는 언제 처음 발생했는가? 이후 얼마나 자주 발생했는가?
+ 이로 인해 클러스터를 구성하거나 실행하는 방식이 바뀌었는가?
## 클러스터 세부 정보
다음 클러스터 세부 정보는 문제를 조사하는 데 유용합니다. 이 정보를 수집하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터 상태 및 세부 정보 보기](emr-manage-view-clusters.md) 섹션을 참조하세요.
+ 클러스터 식별자. (작업 흐름 식별자라고도 함)
+ AWS 리전 및 클러스터가 시작된 가용 영역.
+ 마지막 상태 변경의 세부 정보를 포함한 클러스터의 상태입니다.
+ 마스터, 코어, 작업 노드에 지정된 EC2 인스턴스 유형 및 수입니다.
# 2단계: EMR 클러스터 환경 확인
환경을 확인하여 서비스 중단이 있는지 또는 AWS 서비스 제한을 초과했는지 확인합니다.
**Topics**
+ [서비스 중단 확인](#emr-troubleshoot-slow-2-outages)
+ [사용 한도 확인](#emr-troubleshoot-slow-2-limits)
+ [Amazon VPC 서브넷 구성 확인](#emr-troubleshoot-slow-2-vpc)
+ [클러스터 다시 시작](#emr-troubleshoot-slow-2-restart)
## 서비스 중단 확인
Amazon EMR은 내부적으로 여러 Amazon Web Services를 사용합니다. Amazon EC2에서 가상 서버를 실행하고, Amazon S3에 데이터와 스크립트를 저장하며, 지표를 CloudWatch에 보고합니다. 이러한 서비스를 중단시키는 이벤트는 드물지만, 발생할 경우 Amazon EMR에서 문제가 발생할 수 있습니다.
더 진행하기 전에 [서비스 상태 대시보드](https://status.aws.amazon.com/)를 확인하세요. 클러스터를 시작한 리전을 점검하여 이러한 서비스에 중단 이벤트가 발생했는지 확인합니다.
## 사용 한도 확인
대규모 클러스터를 시작하거나 여러 클러스터를 동시에 시작했거나 다른 사용자 AWS 계정 와를 공유하는 사용자인 경우 AWS 서비스 제한을 초과하여 클러스터가 실패했을 수 있습니다.
Amazon EC2는 단일 AWS 리전에서 실행되는 가상 서버 인스턴스 수를 온디맨드 또는 예약 인스턴스 20개로 제한합니다. 노드가 20개 이상인 클러스터를 시작하거나에서 활성화된 총 EC2 인스턴스 수가 20개를 초과하는 클러스터 AWS 계정 를 시작하는 경우 클러스터는 필요한 모든 EC2 인스턴스를 시작할 수 없으며 실패할 수 있습니다. 이 경우 Amazon EMR에서 `EC2 QUOTA EXCEEDED` 오류를 반환합니다. Amazon EC2 인스턴스 제한 AWS 증가 요청 애플리케이션을 제출하여 계정에서 실행할 수 있는 EC2 인스턴스 수를 늘리도록에 요청할 수 있습니다. [ Amazon EC2 ](https://aws.amazon.com/contact-us/ec2-request/)
또 한 가지 사용량 한도를 초과하게 되는 상황으로는, 클러스터가 종료된 후 모든 리소스를 해제하기까지 시간이 지연되는 경우를 들 수 있습니다. 구성에 따라 클러스터를 완전히 종료하고 할당된 리소스를 해제하는 데 5-20분이 걸릴 수도 있습니다. 클러스터를 시작하려 할 때 `EC2 QUOTA EXCEEDED` 오류가 발생하는 경우 최근에 종료된 클러스터의 리소스가 아직 해제되지 않았기 때문일 수 있습니다. 이 경우 [Amazon EC2 할당량 증가를 요청](https://aws.amazon.com/contact-us/ec2-request/)하거나 20분을 기다린 후 클러스터를 다시 시작할 수 있습니다.
Amazon S3에서는 한 계정에서 생성하는 버킷 수를 100개로 제한합니다. 클러스터가 이 한도를 초과하는 새 버킷을 생성하면 버킷 생성에 실패하며, 클러스터에 장애가 발생할 수 있습니다.
## Amazon VPC 서브넷 구성 확인
클러스터를 Amazon VPC 서브넷에서 시작한 경우 [Amazon EMR에 대해 VPC에서 네트워킹 구성](emr-plan-vpc-subnet.md)에서 설명한 대로 서브넷을 구성해야 합니다. 또한 클러스터를 시작하는 서브넷에 탄력적 가용 IP 주소가 충분하여 클러스터의 각 노드에 하나씩 할당할 수 있는지 확인합니다.
## 클러스터 다시 시작
처리 속도 저하는 일시적인 조건으로 인해 발생할 수 있습니다. 클러스터를 종료한 다음 다시 시작하여 성능이 향상되는지 확인해 봅니다.
# 3단계: Amazon EMR 클러스터에 대한 로그 파일 검사
다음 단계는 로그 파일을 살펴보면서 오류 코드 또는 그 외 클러스터에 문제가 발생했을 가능성을 찾아내는 것입니다. 제공되는 로그 파일, 찾을 수 있는 위치, 확인하는 방법에 대한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 섹션을 참조하세요.
발생한 문제를 파악하려면 약간의 조사 작업이 필요할 수 있습니다. Hadoop은 클러스터에 있는 다양한 노드에서 작업을 시도하며 작업을 실행합니다. Amazon EMR은 추론적 작업 시도를 시작하여 먼저 완료되지 않은 다른 작업 시도를 종료할 수 있습니다. 그러면 컨트롤러, stderr 및 syslog 로그 파일에 실시간으로 로깅되는 중요한 활동이 생성됩니다. 또한 여러 차례의 작업 시도가 동시에 실행되지만 로그 파일은 결과를 선형으로만 표시할 수 있습니다.
부트스트랩 작업 로그에 오류가 있거나 클러스터 시작 중 예기치 못한 구성 변경이 발생하지 않았는지 검사하는 것으로 시작합니다. 이를 시작으로 단계 로그를 살펴보며 오류가 있는 단계의 일부로 시작된 Hadoop 작업을 찾아냅니다. Hadoop 작업 로그를 살펴보며 장애가 발생한 작업 시도를 찾아냅니다. 작업 시도 로그에는 작업 시도를 실패로 만든 요인에 대한 세부 정보가 포함됩니다.
다음 섹션에서는 다양한 로그 파일을 이용해 클러스터에 발생한 오류를 찾아내는 방법을 설명합니다.
## 부트스트랩 작업 로그 확인
부트스트랩 작업은 클러스터가 시작될 때 스크립트를 실행합니다. 이 작업은 흔히 클러스터에 추가 소프트웨어를 설치하거나 구성 설정의 기본값을 변경하는 용도로 사용됩니다. 이 로그를 보면 클러스터 설정 중에 발생한 오류뿐 아니라 성능에 영향을 미칠 수 있는 구성 설정 변경에 대한 통찰을 얻을 수 있습니다.
## 단계 로그 확인
네 가지 유형의 단계 로그가 있습니다.
+ **controller** - 단계 실행을 시도하는 동안 발생한 오류로 인해 생성된 Amazon EMR에서 생성된 파일을 포함합니다. 단계를 로드하는 동안 장애가 발생하면 이 로그에서 스택 트레이스를 볼 수 있습니다. 애플리케이션 로드 또는 액세스 중에 발생한 오류는 매퍼 파일 누락 오류와 마찬가지로 주로 여기에 수록됩니다.
+ **stderr** - 단계 처리 중에 발생한 오류 메시지를 포함합니다. 애플리케이션 로딩 오류는 주로 여기에 수록됩니다. 이 로그에 스택 트레이스가 포함되기도 합니다.
+ **stdout** - 매퍼 및 reducer 실행 파일이 생성한 상태를 포함합니다. 애플리케이션 로딩 오류는 주로 여기에 수록됩니다. 이 로그에 애플리케이션 오류 메시지가 포함되기도 합니다.
+ **syslog** - Apache 및 Hadoop과 같은 Amazon 이외 소프트웨어의 로그를 포함합니다. 스트리밍 오류는 주로 여기에 수록됩니다.
stderr에서 명시적 오류 여부를 검사합니다. stderr에 짧은 오류 목록이 표시된 경우, 오류가 표시되며 단계가 갑자기 중지한 것입니다. 이 현상은 클러스터에서 매퍼와 reducer 애플리케이션 실행 중에 발생한 오류로 인해 가장 자주 발생합니다.
syslog와 컨트롤러의 마지막 줄에 오류나 장애 발생 알림이 있는지 살펴봅니다. 실패한 작업에 대한 메시지, 특히 "Job Failed"가 있는지 살펴봅니다.
## 작업 시도 로그 확인
이전의 단계 로그 분석에 실패한 작업이 하나 이상 포함된 경우, 해당하는 작업 시도의 로그에 더 자세한 오류 정보가 있는지 조사합니다.
## Hadoop 대몬(daemon) 로그 확인
드물지만 Hadoop 자체에 장애가 발생하기도 합니다. 장애 발생 유무를 알아보려면 Hadoop 로그를 확인해야 합니다. 각 노드의 `/var/log/hadoop/`에 있습니다.
JobTracker 로그를 이용해 장애가 발생한 작업 시도를 실행 기반이 된 노드에 매핑할 수 있습니다. 작업 시도에 연결된 노드를 파악하면 이 노드를 호스팅하는 EC2 인스턴스의 상태를 점검해 CPU나 메모리를 초과하여 실행되는 등의 문제가 있는지 알아낼 수 있습니다.
# 4단계: Amazon EMR 클러스터 및 인스턴스 상태 확인
Amazon EMR 클러스터는 Amazon EC2 인스턴스에서 실행 중인 노드로 구성됩니다. 이러한 인스턴스가 리소스 바인딩되거나(예: CPU 또는 메모리 부족) 인스턴스에 네트워크 연결 문제가 발생하거나 인스턴스가 종료되면 클러스터 처리 속도가 느려집니다.
클러스터에는 최대 세 가지 유형의 노드가 있습니다.
+ **프라이머리 노드** - 클러스터를 관리합니다. 이 노드에 성능 문제가 발생하면 전체 클러스터가 영향을 받습니다.
+ **코어 노드** - 작업을 처리하고 Hadoop 분산 파일 시스템(HDFS)을 유지 관리합니다. 이러한 노드 중 하나에 성능 문제가 발생하면 HDFS 작업 및 map-reduce 처리 속도가 느려질 수 있습니다. 클러스터에 코어 노드를 추가하여 성능을 향상할 수 있지만 코어 노드를 제거할 수 없습니다. 자세한 내용은 [실행 중인 Amazon EMR 클러스터 크기 수동 조정](emr-manage-resize.md) 단원을 참조하십시오.
+ **태스크 노드** - map-reduce 작업을 처리합니다. 이 노드는 전적으로 컴퓨팅 리소스이며 데이터를 저장하지 않습니다. 클러스터에 작업 노드를 추가하여 작업 수행 속도를 향상하거나 필요 없는 작업 노드를 제거할 수 있습니다. 자세한 내용은 [실행 중인 Amazon EMR 클러스터 크기 수동 조정](emr-manage-resize.md) 단원을 참조하십시오.
클러스터의 상태를 볼 때 전체 클러스터의 성능과 개별 인스턴스의 성능을 모두 살펴보아야 합니다. 다음과 같은 여러 가지 도구를 사용할 수 있습니다.
## CloudWatch를 사용하여 클러스터 상태 확인
모든 Amazon EMR 클러스터는 CloudWatch에 지표를 보고합니다. 이러한 지표는 총 로드, HDFS 사용률, 실행 중인 작업, 남은 작업, 손상된 블록 등과 같은 클러스터에 대한 요약 성능 정보를 제공합니다. CloudWatch 지표를 확인하면 클러스터에 어떤 일이 발생하고 있는지를 전체적으로 파악할 수 있으며 처리 속도가 느려지는 원인이 무엇인지를 이해할 수 있습니다. CloudWatch를 사용하여 기존 성능 문제를 분석할 수 있을 뿐 아니라, 향후 성능 문제가 발생할 경우 CloudWatch에서 알림이 생성되도록 경보를 설정할 수 있습니다. 자세한 내용은 [CloudWatch에서 Amazon EMR 지표 모니터링](UsingEMR_ViewingMetrics.md) 단원을 참조하십시오.
## 작업 상태 및 HDFS 상태 확인
클러스터 세부 정보 페이지에서 **Application user history(애플리케이션 사용자 이력)**를 사용하여 YARN 애플리케이션 세부 정보를 봅니다. 특정 애플리케이션의 경우 세부 정보를 자세히 확인하고 로그에 직접 액세스할 수 있습니다. 이는 Spark 애플리케이션에 특히 유용합니다. 자세한 내용은 [Amazon EMR 애플리케이션 기록 보기](emr-cluster-application-history.md) 단원을 참조하십시오.
Hadoop은 정보를 보는 데 사용할 수 있는 일련의 웹 인터페이스를 제공합니다. 이러한 웹 인터페이스에 액세스하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터에 호스팅된 웹 인터페이스 보기](emr-web-interfaces.md) 섹션을 참조하세요.
+ JobTracker - 클러스터에서 처리되고 있는 작업의 진행에 대한 정보를 제공합니다. 이 인터페이스를 사용하여 언제 작업이 정체되었는지를 확인할 수 있습니다.
+ HDFS NameNode - HDFS 사용률과 각 노드에서 사용 가능한 공간의 비율에 대한 정보를 제공합니다. 이 인터페이스를 사용하여 언제 HDFS가 리소스 바인딩되며 추가 용량이 필요한지를 확인할 수 있습니다.
+ TaskTracker - 클러스터에서 처리되고 있는 작업에 대한 정보를 제공합니다. 이 인터페이스를 사용하여 언제 작업이 정체되었는지를 확인할 수 있습니다.
## Amazon EC2에서 인스턴스 상태 확인
클러스터에 있는 인스턴스의 상태에 대한 정보를 살펴보는 다른 방법은 Amazon EC2 콘솔을 사용하는 것입니다. 클러스터에 있는 각 노드는 EC2 인스턴스에서 실행되기 때문에 Amazon EC2에서 제공되는 도구를 사용하여 상태를 확인할 수 있습니다. 자세한 내용은 [Amazon EC2에서 클러스터 인스턴스 보기](UsingEMR_Tagging.md) 단원을 참조하십시오.
# 5단계: 일시 중단된 그룹 확인
노드를 시작하려고 시도하는 동안 인스턴스 그룹에 너무 많은 오류가 발생할 경우 인스턴스 그룹은 일시 중단됩니다. 예를 들어, 부트스트랩 작업을 수행하는 동안 새 노드에서 반복적으로 장애가 발생하면 새 노드 프로비저닝을 계속 시도하는 대신 일정 시간 이후 인스턴스 그룹이 `SUSPENDED` 상태가 됩니다.
다음과 같은 경우에 노드가 실행에 실패할 수 있습니다.
+ Hadoop 또는 클러스터가 어떤 식으로든 손상되었거나 클러스터에 새 노드를 허용하지 않음
+ 새 노드에서 부트스트랩 작업이 실패함
+ 노드가 올바르게 작동하지 않고 Hadoop에 체크인되지 않음
인스턴스 그룹이 `SUSPENDED` 상태이고 클러스터가 `WAITING` 상태인 경우 클러스터 단계를 추가하여 원하는 수의 코어 및 작업 노드를 재설정할 수 있습니다. 단계를 추가하면 클러스터 처리가 재개되고 인스턴스 그룹이 `RUNNING` 상태로 돌아갑니다.
일시 중단된 상태의 클러스터를 재설정하는 방법에 대한 자세한 내용은 [일시 중단됨 상태](emr-manage-resize.md#emr-manage-resizeSuspended) 섹션을 참조하세요.
# 6단계: Amazon EMR 클러스터의 구성 설정 검토
구성 설정은 작업을 재시도할 횟수 및 정렬에 사용 가능한 메모리 양과 같은 클러스터 실행 방식에 대한 세부 정보를 지정합니다. Amazon EMR을 사용하여 클러스터를 시작하는 경우 표준 Hadoop 구성 설정 외에도 Amazon EMR 특정 설정이 있습니다. 구성 설정은 클러스터의 마스터 노드에 저장됩니다. 구성 설정을 점검하여 클러스터를 효율적으로 실행하는 데 필요한 리소스가 있는지 확인할 수 있습니다.
Amazon EMR은 클러스터를 시작하는 데 사용하는 기본 Hadoop 구성 설정을 정의합니다. 값은 AMI 및 클러스터에 지정하는 인스턴스 유형을 기반으로 결정됩니다. 부트스트랩 작업을 사용하거나 작업 실행 파라미터에 새 값을 지정하여 구성 설정을 기본값에서 수정할 수 있습니다. 자세한 내용은 [부트스트랩 작업을 생성하여 Amazon EMR 클러스터에서 추가 소프트웨어 설치](emr-plan-bootstrap.md) 단원을 참조하십시오. 부트스트랩 작업에 따라 구성 설정이 변경되었는지 여부를 확인하려면 부트스트랩 작업 로그를 확인합니다.
Amazon EMR은 각 작업을 실행하는 데 사용된 Hadoop 설정을 기록합니다. 로그 데이터는 마스터 노드의 `/mnt/var/log/hadoop/history/` 디렉터리에 `job_job-id_conf.xml`이라는 파일로 저장됩니다. 여기서 *job-id*는 작업 식별자로 대체됩니다. 로그 아카이브를 활성화하면 이 데이터가 Amazon S3의 `logs/date/jobflow-id/jobs` 폴더에 복사됩니다. 여기서 *date*는 작업이 실행된 날짜이고 *jobflow-id*는 클러스터 식별자입니다.
다음 Hadoop 작업 구성 설정은 성능 문제를 조사하는 데 특히 유용합니다. Hadoop 구성 설정 및 이 설정이 Hadoop 동작에 미치는 영향에 대한 자세한 내용은 [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/)를 참조하세요.
**주의**
노드 수가 4개 미만인 클러스터에서 `dfs.replication`을 1로 설정하면 단일 노드가 중단된 경우 HDFS 데이터가 손실될 수 있습니다. 프로덕션 워크로드에는 코어 노드가 4개 이상 있는 클러스터를 사용하는 것이 좋습니다.
Amazon EMR은 클러스터에서 코어 노드를 `dfs.replication` 미만으로 조정하는 허용하지 않습니다. 예를 들어, `dfs.replication = 2`인 경우 최소 코어 노드 수가 2개입니다.
Managed Scaling, Auto Scaling을 사용하거나 클러스터 크기를 수동으로 조정하는 경우 `dfs.replication`을 2 이상으로 설정하는 것이 좋습니다.
| 구성 설정 | 설명 |
| --- | --- |
| dfs.replication | RAID 유형의 환경을 생성하기 위해 단일 블록(예: 하드 드라이브 블록)이 복사되는 HDFS 노드 수입니다. 블록 사본이 포함된 HDFS 노드 수를 결정합니다. |
| io.sort.mb | 정렬에 사용 가능한 총 메모리입니다. 이 값은 10x io.sort.factor여야 합니다. 이 설정은 io.sort.mb에 mapred.tasktracker.ap.tasks.maximum을 곱하여 작업 노드에 사용되는 총 메모리를 계산하는 데도 사용할 수 있습니다. |
| io.sort.spill.percent | 정렬 중에 할당된 정렬 메모리가 가득 차서 디스크를 사용하기 시작하는 지점입니다. |
| mapred.child.java.opts | 사용되지 않음. mapred.map.child.java.opts 및 mapred.reduce.child.java.opts를 대신 사용합니다. 내부에서 작업을 실행하기 위해 JVM을 시작할 때 TaskTracker에서 사용하는 Java 옵션입니다. 일반적인 파라미터는 최대 메모리 크기를 설정하는 '-Xmx'입니다. |
| mapred.map.child.java.opts | 내부에서 맵 작업을 실행하기 위해 JVM을 시작할 때 TaskTracker에서 사용하는 Java 옵션입니다. 일반적인 파라미터는 최대 메모리 힙 크기를 설정하는 '-Xmx'입니다. |
| mapred.map.tasks.speculative.execution | 동일한 작업의 맵 작업 시도를 병렬로 시작할 수 있는지 여부를 결정합니다. |
| mapred.reduce.tasks.speculative.execution | 동일한 작업의 reduce 작업 시도를 병렬로 시작할 수 있는지 여부를 결정합니다. |
| mapred.map.max.attempts | 맵 작업을 시도할 수 있는 최대 횟수입니다. 모두 실패할 경우 맵 작업이 실패로 표시됩니다. |
| mapred.reduce.child.java.opts | 내부에서 reduce 작업을 실행하기 위해 JVM을 시작할 때 TaskTracker에서 사용하는 Java 옵션입니다. 일반적인 파라미터는 최대 메모리 힙 크기를 설정하는 '-Xmx'입니다. |
| mapred.reduce.max.attempts | reduce 작업을 시도할 수 있는 최대 횟수입니다. 모두 실패할 경우 맵 작업이 실패로 표시됩니다. |
| mapred.reduce.slowstart.completed.maps | reduce 작업을 시도하기 전에 완료해야 하는 맵 작업의 양입니다. 충분히 오래 기다리지 않으면 시도 중에 'Too many fetch-failure' 오류가 발생할 수 있습니다. |
| mapred.reuse.jvm.num.tasks | 한 작업은 단일 JVM 내에서 실행됩니다. 동일한 JVM를 재사용할 수 있는 작업 수를 지정합니다. |
| mapred.tasktracker.map.tasks.maximum | 매핑 중 작업 노드 당 병렬로 실행할 수 있는 최대 작업량입니다. |
| mapred.tasktracker.reduce.tasks.maximum | reduce 중 작업 노드 당 병렬로 실행할 수 있는 최대 작업량입니다. |
클러스터 작업이 메모리 집약적인 경우 코어 노드당 사용하는 작업량을 줄이고 작업 트래커 힙 크기를 축소하여 성능을 향상할 수 있습니다.
# 7단계: Amazon EMR 클러스터의 입력 데이터 검사
입력 데이터를 살펴봅니다. 데이터가 키 값 간에 고르게 배포되어 있습니까? 데이터가 하나 또는 소수의 키 값에 심하게 편중되면 처리 로드가 소수의 노드에 매핑되고 다른 노드는 유휴 상태일 수 있습니다. 작업 배포가 불균형하면 처리 속도가 느려질 수 있습니다.
불균형한 데이터 세트의 예는 단어를 알파벳순으로 정렬하기 위해 클러스터를 실행하지만 문자 "a"로 시작하는 단어만 포함된 데이터 세트가 있는 경우일 수 있습니다. 작업이 매핑될 때 "a"로 시작되는 값을 처리하는 노드는 작업으로 압도되지만 다른 문자로 시작되는 단어를 처리하는 노드는 유휴 상태가 됩니다.
# AWS Lake Formation과 함께 Amazon EMR을 사용할 때 발생하는 일반적인 문제 해결
이 섹션에서는 AWS Lake Formation과 함께 Amazon EMR을 사용할 때 일반적으로 발생하는 문제를 해결하는 과정을 안내합니다.
## 데이터 레이크 액세스는 허용되지 않음
데이터 레이크의 데이터를 분석하고 처리하려면 먼저 Amazon EMR 클러스터에서 데이터 필터링을 명시적으로 옵트인해야 합니다. 데이터 액세스에 실패하면 노트북 항목 출력에 일반적인 `Access is not allowed` 메시지가 표시됩니다.
Amazon EMR에서 데이터 필터링을 옵트인하는 방법에 대한 지침은 *AWS Lake Formation 개발자 안내서*에서 [Allow data filtering on Amazon EMR](https://docs.aws.amazon.com/lake-formation/latest/dg/getting-started-setup.html#emr-switch)을 참조하세요.
## 세션 만료
EMR Notebooks 및 Zeppelin에 대한 세션 시간 제한은 IAM 역할의 Lake Formation `Maximum CLI/API session duration` 설정으로 제어됩니다. 이 설정의 기본값은 1시간입니다. 세션 시간 제한이 발생했을 때 Spark SQL 명령을 실행하려고 하면 노트북 항목의 출력에 다음 메시지가 표시됩니다.
```
Error 401 HTTP ERROR: 401 Problem accessing /sessions/2/statements.
Reason: JWT token included in request failed validation.
Powered by Jetty:// 9.3.24.v20180605 org.springframework.web.client.HttpClientErrorException: 401 JWT token included in request failed validation…
```
세션을 검사하려면 페이지를 새로 고칩니다. IdP를 사용하여 다시 인증하라는 메시지가 표시되고 노트북으로 다시 리디렉션됩니다. 다시 인증한 후 쿼리를 계속 실행할 수 있습니다.
## 요청된 테이블에서 사용자의 권한 없음
액세스 권한이 없는 테이블에 액세스하려고 시도할 때 Spark SQL 명령을 실행하려고 하면 노트북 항목의 출력에 다음 예외가 표시됩니다.
```
org.apache.spark.sql.AnalysisException: org.apache.hadoop.hive.ql.metadata.HiveException: Unable to fetch table table.
Resource does not exist or requester is not authorized to access requested permissions.
(Service: AWSGlue; Status Code: 400; Error Code: AccessDeniedException; Request ID: …
```
테이블에 액세스하려면 Lake Formation에서 이 테이블과 관련된 권한을 업데이트하여 사용자에 대한 액세스 권한을 부여해야 합니다.
## Lake Formation과 공유한 교차 계정 데이터 쿼리
Amazon EMR을 사용하여 다른 계정에서 공유된 데이터에 액세스하는 경우 일부 Spark 라이브러리는 `Glue:GetUserDefinedFunctions` API 작업을 직접 호출하려고 시도합니다. AWS RAM 관리형 권한 버전 1 및 2는이 작업을 지원하지 않으므로 다음과 같은 오류 메시지가 표시됩니다.
`"ERROR: User: arn:aws:sts::012345678901:assumed-role/my-spark-role/i-06ab8c2b59299508a is not authorized to perform: glue:GetUserDefinedFunctions on resource: arn:exampleCatalogResource because no resource-based policy allows the glue:GetUserDefinedFunctions action"`
이 오류를 해결하려면 리소스 공유를 생성한 데이터 레이크 관리자가 리소스 공유에 연결된 AWS RAM 관리형 권한을 업데이트해야 합니다. AWS RAM 관리형 권한의 버전 3에서는 보안 주체의 `glue:GetUserDefinedFunctions` 작업 수행을 허용합니다.
새 리소스 공유를 생성하는 경우 Lake Formation은 기본적으로 AWS RAM 관리형 권한의 최신 버전을 적용하므로 별도의 조치가 필요하지 않습니다. 기존 리소스 공유에 대한 교차 계정 데이터 액세스를 활성화하려면 AWS RAM 관리형 권한을 버전 3으로 업데이트해야 합니다.
에서 공유된 리소스에 할당된 AWS RAM 권한을 볼 수 있습니다 AWS RAM. 버전 3에는 다음과 같은 권한이 포함됩니다.
```
Databases
AWSRAMPermissionGlueDatabaseReadWriteForCatalog
AWSRAMPermissionGlueDatabaseReadWrite
Tables
AWSRAMPermissionGlueTableReadWriteForCatalog
AWSRAMPermissionGlueTableReadWriteForDatabase
AllTables
AWSRAMPermissionGlueAllTablesReadWriteForCatalog
AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```
**기존 리소스 공유의 AWS RAM 관리형 권한 버전을 업데이트하려면**
사용자(데이터 레이크 관리자)는 *AWS RAM 사용 설명서*의 지침에 따라 [AWS RAM 관리형 권한을 최신 버전으로 업데이트](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-update-permissions.html)하거나 리소스 유형에 대한 모든 기존 권한을 취소하고 다시 부여할 수 있습니다. 권한을 취소하면가 AWS RAM 리소스 유형과 연결된 리소스 공유를 AWS RAM 삭제합니다. 권한을 AWS RAM 다시 부여하면는 AWS RAM 관리형 권한의 최신 버전을 연결하는 새 리소스 공유를 생성합니다.
## 테이블에 삽입, 테이블 생성 및 테이블 변경
Lake Formation 정책으로 보호되는 데이터베이스의 테이블에 삽입, 테이블 생성 또는 테이블 변경은 지원되지 않습니다. 이러한 작업을 수행할 때 Spark SQL 명령을 실행하려고 하면 노트북 항목의 출력에 다음 예외가 표시됩니다.
```
java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception:
Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: …
```
자세한 내용은 [Amazon EMR과의 통합 제한 사항을 AWS Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-scope.html#emr-lf-limitations) 참조하세요.