기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 오류 코드와 함께 실패한 Amazon EMR 클러스터 문제 해결
<a name="emr-troubleshoot-failed"></a>

 이 섹션에서는 클러스터 실패 문제를 해결하는 과정을 안내합니다. 여기서 클러스터 실패란 클러스터가 오류 코드로 종료되는 경우를 의미합니다.

**참고**  
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 클러스터 관련 문제에 대한 데이터 수집
<a name="emr-troubleshoot-failed-1"></a>

 클러스터 문제를 해결하는 첫 번째 단계는 잘못된 부분에 대한 정보를 수집하고 클러스터의 현재 상태 및 구성을 가져오는 것입니다. 이 정보는 다음 단계에서 문제의 가능한 원인을 확인하거나 배제하는 데 사용됩니다.

## 문제 정의
<a name="emr-troubleshoot-failed-1-problem"></a>

 문제를 명확하게 정의하는 것부터 시작해야 합니다. 다음과 같이 자문하세요.
+  무엇을 기대했는가? 실제로는 어떤 일이 발생했는가?
+  이 문제는 언제 처음 발생했는가? 이후 얼마나 자주 발생했는가?
+  이로 인해 클러스터를 구성하거나 실행하는 방식이 바뀌었는가?

## 클러스터 세부 정보
<a name="emr-troubleshoot-failed-1-cluster"></a>

 다음 클러스터 세부 정보는 문제를 조사하는 데 유용합니다. 이 정보를 수집하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터 상태 및 세부 정보 보기](emr-manage-view-clusters.md) 섹션을 참조하세요.
+  클러스터 식별자. (작업 흐름 식별자라고도 함) 
+  AWS 리전 및 클러스터가 시작된 가용 영역.
+  마지막 상태 변경의 세부 정보를 포함한 클러스터의 상태입니다.
+  마스터, 코어, 작업 노드에 지정된 EC2 인스턴스 유형 및 수입니다.

# 2단계: 환경 점검
<a name="emr-troubleshoot-failed-2"></a>

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)

## 서비스 중단 확인
<a name="emr-troubleshoot-failed-2-outages"></a>

 Amazon EMR은 내부적으로 여러 Amazon Web Services를 사용합니다. Amazon EC2에서 가상 서버를 실행하고, Amazon S3에 데이터와 스크립트를 저장하며, 지표를 CloudWatch에 보고합니다. 이러한 서비스를 중단시키는 이벤트는 드물지만, 발생할 경우 Amazon EMR에서 문제가 발생할 수 있습니다.

 더 진행하기 전에 [서비스 상태 대시보드](https://status.aws.amazon.com/)를 확인하세요. 클러스터를 시작한 리전을 점검하여 이러한 서비스에 중단 이벤트가 발생했는지 확인합니다.

## 사용 한도 확인
<a name="emr-troubleshoot-failed-2-limits"></a>

 대규모 클러스터를 시작하거나 여러 클러스터를 동시에 시작했거나 다른 사용자 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개로 제한합니다. 클러스터가 이 한도를 초과하는 새 버킷을 생성하면 버킷 생성에 실패하며, 클러스터에 장애가 발생할 수 있습니다.

## 릴리스 버전 확인
<a name="emr-troubleshoot-failed-2-ami"></a>

클러스터를 시작하는 데 사용된 릴리스 레이블과 최신 Amazon EMR 릴리스를 비교합니다. 각 Amazon EMR 릴리스에는 새 애플리케이션, 기능, 패치 및 버그 수정 사항 등 향상 기능이 포함되어 있습니다. 최신 릴리스 버전에서는 클러스터에 영향을 미치는 문제가 이미 수정되었을 수도 있습니다. 가능하면 최신 버전을 사용하여 클러스터를 다시 실행합니다.

## Amazon VPC 서브넷 구성 확인
<a name="emr-troubleshoot-failed-2-vpc"></a>

클러스터를 Amazon VPC 서브넷에서 시작한 경우 [Amazon EMR에 대해 VPC에서 네트워킹 구성](emr-plan-vpc-subnet.md)에서 설명한 대로 서브넷을 구성해야 합니다. 또한 클러스터를 시작하는 서브넷에 탄력적 가용 IP 주소가 충분하여 클러스터의 각 노드에 하나씩 할당할 수 있는지 확인합니다.

# 3단계: 최근 상태 변경 살펴보기
<a name="emr-troubleshoot-failed-3"></a>

 최근 상태 변경은 마지막으로 발생한 클러스터 상태 변경에 대한 정보를 제공합니다. 클러스터의 상태가 `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 로그 파일 검사
<a name="emr-troubleshoot-failed-4"></a>

 다음 단계는 로그 파일을 살펴보면서 오류 코드 또는 그 외 클러스터에 문제가 발생했을 가능성을 찾아내는 것입니다. 제공되는 로그 파일, 찾을 수 있는 위치, 확인하는 방법에 대한 내용은 [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md) 섹션을 참조하세요.

 발생한 문제를 파악하려면 약간의 조사 작업이 필요할 수 있습니다. Hadoop은 클러스터에 있는 다양한 노드에서 작업을 시도하며 작업을 실행합니다. Amazon EMR은 추론적 작업 시도를 시작하여 먼저 완료되지 않은 다른 작업 시도를 종료할 수 있습니다. 그러면 컨트롤러, stderr 및 syslog 로그 파일에 실시간으로 로깅되는 중요한 활동이 생성됩니다. 또한 여러 차례의 작업 시도가 동시에 실행되지만 로그 파일은 결과를 선형으로만 표시할 수 있습니다.

 부트스트랩 작업 로그에 오류가 있거나 클러스터 시작 중 예기치 못한 구성 변경이 발생하지 않았는지 검사하는 것으로 시작합니다. 이를 시작으로 단계 로그를 살펴보며 오류가 있는 단계의 일부로 시작된 Hadoop 작업을 찾아냅니다. Hadoop 작업 로그를 살펴보며 장애가 발생한 작업 시도를 찾아냅니다. 작업 시도 로그에는 작업 시도를 실패로 만든 요인에 대한 세부 정보가 포함됩니다.

다음 섹션에서는 다양한 로그 파일을 이용해 클러스터에 발생한 오류를 찾아내는 방법을 설명합니다.

## 부트스트랩 작업 로그 확인
<a name="emr-troubleshoot-failed-4-bootstrap-logs"></a>

 부트스트랩 작업은 클러스터가 시작될 때 스크립트를 실행합니다. 이 작업은 흔히 클러스터에 추가 소프트웨어를 설치하거나 구성 설정의 기본값을 변경하는 용도로 사용됩니다. 이 로그를 보면 클러스터 설정 중에 발생한 오류뿐 아니라 성능에 영향을 미칠 수 있는 구성 설정 변경에 대한 통찰을 얻을 수 있습니다.

## 단계 로그 확인
<a name="emr-troubleshoot-failed-4-step-logs"></a>

 네 가지 유형의 단계 로그가 있습니다.
+ **controller** - 단계 실행을 시도하는 동안 발생한 오류로 인해 생성된 Amazon EMR에서 생성된 파일을 포함합니다. 단계를 로드하는 동안 장애가 발생하면 이 로그에서 스택 트레이스를 볼 수 있습니다. 애플리케이션 로드 또는 액세스 중에 발생한 오류는 매퍼 파일 누락 오류와 마찬가지로 주로 여기에 수록됩니다.
+  **stderr** - 단계 처리 중에 발생한 오류 메시지를 포함합니다. 애플리케이션 로딩 오류는 주로 여기에 수록됩니다. 이 로그에 스택 트레이스가 포함되기도 합니다.
+ **stdout** - 매퍼 및 reducer 실행 파일이 생성한 상태를 포함합니다. 애플리케이션 로딩 오류는 주로 여기에 수록됩니다. 이 로그에 애플리케이션 오류 메시지가 포함되기도 합니다.
+ **syslog** - Apache 및 Hadoop과 같은 Amazon 이외 소프트웨어의 로그를 포함합니다. 스트리밍 오류는 주로 여기에 수록됩니다.

 stderr에서 명시적 오류 여부를 검사합니다. stderr에 짧은 오류 목록이 표시된 경우, 오류가 표시되며 단계가 갑자기 중지한 것입니다. 이 현상은 클러스터에서 매퍼와 reducer 애플리케이션 실행 중에 발생한 오류로 인해 가장 자주 발생합니다.

 syslog와 컨트롤러의 마지막 줄에 오류나 장애 발생 알림이 있는지 살펴봅니다. 실패한 작업에 대한 메시지, 특히 "Job Failed"가 있는지 살펴봅니다.

## 작업 시도 로그 확인
<a name="emr-troubleshoot-failed-4-task-logs"></a>

 이전의 단계 로그 분석에 실패한 작업이 하나 이상 포함된 경우, 해당하는 작업 시도의 로그에 더 자세한 오류 정보가 있는지 조사합니다.

# 5단계: Amazon EMR 클러스터 단계별 테스트
<a name="emr-troubleshoot-failed-5-test-steps"></a>

 오류 원인을 추적하려 할 때 유용한 기술은 클러스터를 다시 시작하고 단계를 하나씩 제출하는 것입니다. 이렇게 하면 다음 단계를 처리하기 전에 각 단계의 결과를 확인할 수 있으므로 실패한 단계를 수정하여 다시 실행할 수 있습니다. 또한 입력 데이터를 한 번만 로드하면 되다는 이점도 있습니다.

**단계별로 클러스터를 테스트하려면**

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) 단원을 참조하십시오.