기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 작업을 수행하는 경우 Amazon EMR 클러스터 보기 및 모니터링
Amazon EMR은 클러스터에 대한 정보를 수집하는 데 사용할 수 있는 몇 가지 도구를 제공합니다. 콘솔, CLI 또는 프로그래밍 방식으로 클러스터에 대한 정보에 액세스할 수 있습니다. 표준 Hadoop 웹 인터페이스 및 로그 파일은 프라이머리 노드에서 사용할 수 있습니다. 또한 CloudWatch 및 Ganglia 같은 모니터링 서비스를 사용하여 클러스터의 성능을 추적할 수 있습니다.
Amazon EMR 5.25.0부터 Spark 기록 서버용 “영구” 애플리케이션 UI를 사용하는 콘솔에서 애플리케이션 이력을 사용할 수도 있습니다. Amazon EMR 6.x에서는 영구 YARN 타임라인 서버 및 Tez 사용자 인터페이스를 사용할 수도 있습니다. 이러한 서비스는 클러스터 외부에서 호스팅되므로 SSH 연결이나 웹 프록시 없이도 클러스터가 종료된 후 30일 동안 애플리케이션 이력에 액세스할 수 있습니다. [애플리케이션 기록 보기](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html)를 참조하세요.
**Topics**
+ [Amazon EMR 클러스터 상태 및 세부 정보 보기](emr-manage-view-clusters.md)
+ [Amazon EMR에서 향상된 단계 디버깅](emr-enhanced-step-debugging.md)
+ [Amazon EMR 애플리케이션 기록 보기](emr-cluster-application-history.md)
+ [Amazon EMR 로그 파일 보기](emr-manage-view-web-log-files.md)
+ [Amazon EC2에서 클러스터 인스턴스 보기](UsingEMR_Tagging.md)
+ [Amazon EMR에서 CloudWatch 이벤트 및 지표](emr-manage-cluster-cloudwatch.md)
+ [Amazon EMR에서 Ganglia를 사용하여 클러스터 애플리케이션 지표 보기](ViewingGangliaMetrics.md)
+ [를 사용하여 AWS EMR API 호출 로깅 AWS CloudTrail](logging-using-cloudtrail.md)
+ [EMR 관찰성 모범 사례](emr-metrics-observability.md)
# Amazon EMR 클러스터 상태 및 세부 정보 보기
클러스터를 생성한 후에는 상태를 모니터링하고 실행이 종료된 후에도 발생할 수 있는 실행 및 오류에 대한 자세한 정보를 얻을 수 있습니다. Amazon EMR은 종료된 클러스터에 대한 메타데이터를 참조용으로 2개월 동안 저장하며, 그 이후에는 메타데이터가 삭제됩니다. 클러스터 내역에서 클러스터를 삭제할 수는 없지만 AWS Management Console을 사용하면 **필터**를 사용할 수 있고, AWS CLI를 사용하면 `list-clusters` 명령으로 옵션을 사용하여 관리하는 클러스터에 중점을 둘 수 있습니다.
클러스터가 실행 중이거나 종료되었는지 여부에 관계없이 기록된 시간으로부터 1주일 동안 클러스터에 저장된 애플리케이션 이력에 액세스할 수 있습니다. 또한 영구 애플리케이션 사용자 인터페이스는 클러스터가 종료된 후 30일 동안 애플리케이션 이력을 클러스터 외부에 저장합니다. [애플리케이션 기록 보기](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-cluster-application-history.html)를 참조하세요.
대기 중 및 실행 중과 같은 클러스터 상태에 대한 자세한 내용은 [클러스터 수명 주기 이해](emr-overview.md#emr-overview-cluster-lifecycle) 섹션을 참조하세요.
## 를 사용하여 클러스터 세부 정보 보기 AWS Management Console
[https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) **클러스터** 목록에는 종료된 클러스터를 포함하여 계정 및 AWS 리전의 모든 클러스터가 나열됩니다. 다음 목록에는 각 클러스터에 대한 **이름** 및 **ID**, **상태** 및 **상태 세부 정보**, **생성 시간**, 클러스터가 실행 중인 **경과 시간**, 클러스터의 모든 EC2 인스턴스에서 누적된 **정규화된 인스턴스 시간**이 나와 있습니다. 이 목록은 클러스터 상태의 모니터링을 위한 출발점입니다. 이 목록은 분석 및 문제 해결을 위해 각 클러스터의 세부 정보로 드릴다운할 수 있도록 설계되었습니다.
------
#### [ Console ]
**콘솔을 사용하여 클러스터 정보를 보는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 보려는 클러스터를 선택합니다.
1. **요약** 패널을 사용하여 클러스터 상태, Amazon EMR이 클러스터에 설치한 오픈 소스 애플리케이션, 클러스터를 생성하는 데 사용한 Amazon EMR 버전 등 클러스터 구성의 기본 사항을 확인합니다. 다음 테이블에서 설명하는 바와 같이 요약 아래 각 탭을 사용하여 정보를 봅니다.
------
## 를 사용하여 클러스터 세부 정보 보기 AWS CLI
다음 예제에서는 AWS CLI를 사용하여 클러스터 세부 정보를 가져오는 방법을 보여줍니다. 사용 가능한 명령에 대한 자세한 내용은 [Amazon EMR에 대한AWS CLI 명령 참조](https://docs.aws.amazon.com/cli/latest/reference/emr)를 참조하세요. [describe-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/describe-cluster.html) 명령을 사용하여 상태, 하드웨어 및 소프트웨어 구성, VPC 설정, 부트스트랩 작업, 인스턴스 그룹 등을 비롯한 클러스터 수준의 세부 정보를 볼 수 있습니다. 클러스터 상태에 대한 자세한 내용은 [클러스터 수명 주기 이해](emr-overview.md#emr-overview-cluster-lifecycle) 섹션을 참조하세요. 다음 예제는 `describe-cluster` 명령의 사용과 [list-clusters](https://docs.aws.amazon.com/cli/latest/reference/emr/describe-cluster.html) 명령의 예를 보여줍니다.
**Example 클러스터 상태 보기**
`describe-cluster` 명령을 사용하려면 클러스터 ID가 필요합니다. 이 예제는 특정 날짜 범위 내에서 생성된 클러스터 목록을 가져온 다음, 반환된 클러스터 ID 중 하나를 사용하여 개별 클러스터의 상태에 대한 자세한 정보를 나열하는 데 사용하는 방법을 보여 줍니다.
다음 명령은 클러스터 ID로 바뀌는 클러스터 *j-1K48XXXXXXHCB*를 설명합니다.
```
aws emr describe-cluster --cluster-id j-1K48XXXXXXHCB
```
명령의 출력은 다음과 유사합니다.
```
{
"Cluster": {
"Status": {
"Timeline": {
"ReadyDateTime": 1438281058.061,
"CreationDateTime": 1438280702.498
},
"State": "WAITING",
"StateChangeReason": {
"Message": "Waiting for steps to run"
}
},
"Ec2InstanceAttributes": {
"EmrManagedMasterSecurityGroup": "sg-cXXXXX0",
"IamInstanceProfile": "EMR_EC2_DefaultRole",
"Ec2KeyName": "myKey",
"Ec2AvailabilityZone": "us-east-1c",
"EmrManagedSlaveSecurityGroup": "sg-example"
},
"Name": "Development Cluster",
"ServiceRole": "EMR_DefaultRole",
"Tags": [],
"TerminationProtected": false,
"ReleaseLabel": "emr-4.0.0",
"NormalizedInstanceHours": 16,
"InstanceGroups": [
{
"RequestedInstanceCount": 1,
"Status": {
"Timeline": {
"ReadyDateTime": 1438281058.101,
"CreationDateTime": 1438280702.499
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"Name": "CORE",
"InstanceGroupType": "CORE",
"Id": "ig-2EEXAMPLEXXP",
"Configurations": [],
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"RunningInstanceCount": 1
},
{
"RequestedInstanceCount": 1,
"Status": {
"Timeline": {
"ReadyDateTime": 1438281023.879,
"CreationDateTime": 1438280702.499
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"Name": "MASTER",
"InstanceGroupType": "MASTER",
"Id": "ig-2A1234567XP",
"Configurations": [],
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"RunningInstanceCount": 1
}
],
"Applications": [
{
"Version": "1.0.0",
"Name": "Hive"
},
{
"Version": "2.6.0",
"Name": "Hadoop"
},
{
"Version": "0.14.0",
"Name": "Pig"
},
{
"Version": "1.4.1",
"Name": "Spark"
}
],
"BootstrapActions": [],
"MasterPublicDnsName": "ec2-X-X-X-X.compute-1.amazonaws.com",
"AutoTerminate": false,
"Id": "j-jobFlowID",
"Configurations": [
{
"Properties": {
"hadoop.security.groups.cache.secs": "250"
},
"Classification": "core-site"
},
{
"Properties": {
"mapreduce.tasktracker.reduce.tasks.maximum": "5",
"mapred.tasktracker.map.tasks.maximum": "2",
"mapreduce.map.sort.spill.percent": "90"
},
"Classification": "mapred-site"
},
{
"Properties": {
"hive.join.emit.interval": "1000",
"hive.merge.mapfiles": "true"
},
"Classification": "hive-site"
}
]
}
}
```
**Example 생성 날짜별로 클러스터 나열**
특정 데이터 범위 내에서 생성된 클러스터를 검색하려면 `list-clusters` 명령을 `--created-after` 및 `--created-before` 파라미터와 함께 사용합니다.
다음 명령은 2019년 10월 9일에서 2019년 10월 12일 사이에 생성된 모든 클러스터를 나열합니다.
```
aws emr list-clusters --created-after 2019-10-09T00:12:00 --created-before 2019-10-12T00:12:00
```
**Example 상태별로 클러스터 나열**
상태별로 클러스터를 나열하려면 `list-clusters` 명령을 `--cluster-states` 파라미터와 함께 사용합니다. 유효한 클러스터 상태에는 STARTING, BOOTSTRAPPING, RUNNING, WAITING, TERMINATING, TERMINATED 및 TERMINATED\$1WITH\$1ERRORS가 있습니다.
```
aws emr list-clusters --cluster-states TERMINATED
```
다음 바로 가기 파라미터를 사용하여 지정된 상태의 모든 클러스터를 나열할 수도 있습니다.
+ `--active`는 STARTING, BOOTSTRAPPING, RUNNING, WAITING 또는 TERMINATING 상태의 클러스터를 필터링합니다.
+ `--terminated`는 TERMINATED 상태의 클러스터를 필터링합니다.
+ `--failed`는 TERMINATED\$1WITH\$1ERRORS 상태의 클러스터를 필터링합니다.
다음은 동일한 결과를 반환하는 명령입니다.
```
aws emr list-clusters --cluster-states TERMINATED
```
```
aws emr list-clusters --terminated
```
클러스터 상태에 대한 자세한 내용은 [클러스터 수명 주기 이해](emr-overview.md#emr-overview-cluster-lifecycle) 섹션을 참조하세요.
# Amazon EMR에서 향상된 단계 디버깅
Amazon EMR 단계가 실패하고 AMI 버전 5.x 이상의 단계 API 작업을 사용하여 작업을 제출한 경우 Amazon EMR은 경우에 따라 단계 실패의 근본 원인을 식별하고 관련 로그 파일의 이름 및 애플리케이션 스택 추적의 일부와 함께 해당 원인을 API를 통해 반환할 수 있습니다. 예를 들어, 다음 실패를 식별할 수 있습니다.
+ 출력 디렉터리와 같은 일반적인 Hadoop 오류가 있거나, 입력 디렉터리가 없거나, 애플리케이션의 메모리가 부족합니다.
+ 호환되지 않는 Java 버전으로 컴파일된 애플리케이션과 같은 Java 오류가 있거나 찾을 수 없는 기본 클래스로 실행됩니다.
+ Amazon S3에 저장된 객체에 액세스하는 중 문제가 발생했습니다.
[DescribeStep](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_DescribeStep.html) 및 [ListSteps](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_ListSteps.html) API 작업을 통해 이 정보를 사용할 수 있습니다. 해당 작업에서 반환된 [StepSummary](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_StepSummary.html)의 [FailureDetails](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_FailureDetails.html) 필드. FailureDetails 정보에 액세스하려면 AWS CLI, 콘솔 또는 AWS SDK를 사용합니다.
------
#### [ Console ]
새 Amazon EMR 콘솔은 단계 디버깅을 제공하지 않습니다. 하지만 다음 단계를 통해 클러스터 종료 세부 정보를 볼 수 있습니다.
**콘솔을 사용하여 실패 세부 정보를 보는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 보려는 클러스터를 선택합니다.
1. 클러스터 세부 정보 페이지의 **요약** 섹션에 있는 **상태** 값을 기록합니다. **오류로 종료** 상태인 경우 텍스트 위에 마우스를 올려 놓으면 클러스터 실패 세부 정보를 볼 수 있습니다.
------
#### [ CLI ]
**를 사용하여 실패 세부 정보를 보려면 AWS CLI**
+ 를 사용하여 단계의 실패 세부 정보를 가져오려면 `describe-step` 명령을 AWS CLI사용합니다.
```
aws emr describe-step --cluster-id j-1K48XXXXXHCB --step-id s-3QM0XXXXXM1W
```
다음과 비슷한 출력이 표시될 것입니다.
```
{
"Step": {
"Status": {
"FailureDetails": {
"LogFile": "s3://amzn-s3-demo-bucket/logs/j-1K48XXXXXHCB/steps/s-3QM0XXXXXM1W/stderr.gz",
"Message": "org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory s3://amzn-s3-demo-bucket/logs/beta already exists",
"Reason": "Output directory already exists."
},
"Timeline": {
"EndDateTime": 1469034209.143,
"CreationDateTime": 1469033847.105,
"StartDateTime": 1469034202.881
},
"State": "FAILED",
"StateChangeReason": {}
},
"Config": {
"Args": [
"wordcount",
"s3://amzn-s3-demo-bucket/input/input.txt",
"s3://amzn-s3-demo-bucket/logs/beta"
],
"Jar": "s3://amzn-s3-demo-bucket/jars/hadoop-mapreduce-examples-2.7.2-amzn-1.jar",
"Properties": {}
},
"Id": "s-3QM0XXXXXM1W",
"ActionOnFailure": "CONTINUE",
"Name": "ExampleJob"
}
}
```
------
# Amazon EMR 애플리케이션 기록 보기
콘솔의 클러스터 세부 정보 페이지에서 Spark 기록 서버 및 YARN 타임라인 서비스 애플리케이션 세부 정보를 볼 수 있습니다. Amazon EMR 애플리케이션 기록을 사용하면 활성 작업 및 작업 기록을 쉽게 문제 해결하고 분석할 수 있습니다.
**참고**
Amazon EMR에서 사용할 수 있는 콘솔 외부 애플리케이션에 대한 보안을 강화하기 위해 애플리케이션 호스팅 도메인이 PSL(Public Suffix List)에 등록됩니다. 이러한 호스팅 도메인의 예에는 `emrstudio-prod.us-east-1.amazonaws.com`, `emrnotebooks-prod.us-east-1.amazonaws.com`, `emrappui-prod.us-east-1.amazonaws.com`이 포함됩니다. 보안 강화를 위해 기본 도메인 이름에 민감한 쿠키를 설정해야 하는 경우 `__Host-` 접두사가 있는 쿠키를 사용하는 것이 좋습니다. 이렇게 하면 교차 사이트 요청 위조 시도(CSRF) 로부터 도메인을 보호하는 데 도움이 됩니다. 자세한 내용은 *Mozilla 개발자 네트워크*의 [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#cookie_prefixes) 페이지를 참조하세요.
**애플리케이션** 탭의 **애플리케이션 사용자 인터페이스** 섹션에서는 클러스터 상태 및 클러스터에 설치한 애플리케이션에 따라 여러 보기 옵션을 제공합니다.
+ [클러스터 외부에서 영구 애플리케이션 사용자 인터페이스에 액세스](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html) - Amazon EMR 버전 5.25.0부터 Spark UI 및 Spark History Service에서 영구 애플리케이션 사용자 인터페이스 링크를 사용할 수 있습니다. Amazon EMR 버전 5.30.1 이상에서는 Tez UI 및 YARN 타임라인 서버에도 영구 애플리케이션 사용자 인터페이스가 있습니다. YARN 타임라인 서버 및 Tez UI는 활성 및 종료된 클러스터에 대한 지표를 제공하는 오픈 소스 애플리케이션입니다. Spark 사용자 인터페이스는 스케줄러 단계 및 작업, RDD 크기 및 메모리 사용량, 환경 정보, 실행 중인 실행기에 대한 정보 등 다양한 세부 정보를 제공합니다. 영구 애플리케이션 UI는 클러스터 외부에서 실행되므로 애플리케이션이 종료된 후 30일 동안 클러스터 정보와 로그를 사용할 수 있습니다. 클러스터 내 애플리케이션 사용자 인터페이스와 달리 영구 애플리케이션 UI에서는 SSH 연결을 통해 웹 프록시를 설정할 필요가 없습니다.
+ [클러스터 내 애플리케이션 사용자 인터페이스](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-web-interfaces.html) - 클러스터에서 실행할 수 있는 다양한 애플리케이션 기록 사용자 인터페이스가 있습니다. 클러스터 내 사용자 인터페이스는 마스터 노드에서 호스팅되며 웹 서버에 대한 SSH 연결을 설정해야 합니다. 클러스터 내 애플리케이션 사용자 인터페이스는 애플리케이션이 종료된 후 1주일 동안 애플리케이션 기록을 보관합니다. SSH 터널 설정에 대한 지침과 자세한 내용은 [Amazon EMR 클러스터에 호스팅된 웹 인터페이스 보기](emr-web-interfaces.md) 섹션을 참조하세요.
Spark 기록 서버, YARN 타임라인 서버 및 Hive 애플리케이션을 제외하고 클러스터 내 애플리케이션 기록은 클러스터가 실행되는 동안에만 볼 수 있습니다.
# Amazon EMR에서 영구 애플리케이션 사용자 인터페이스 보기
Amazon EMR 버전 5.25.0부터 콘솔의 클러스터 **요약 페이지** 또는 **애플리케이션 사용자 인터페이스** 탭을 사용하여 클러스터 외부에 호스팅된 영구 Spark 기록 서버 애플리케이션 세부 정보에 연결할 수 있습니다. Tez UI 및 YARN 타임라인 서버 영구 애플리케이션 인터페이스는 Amazon EMR 버전 5.30.1부터 사용할 수 있습니다. 영구 애플리케이션 이력에 대한 원클릭 링크 액세스는 다음과 같은 이점을 제공합니다.
+ SSH 연결을 통해 웹 프록시를 설정하지 않고도 활성 작업 및 작업 기록을 신속하게 분석하고 문제를 해결할 수 있습니다.
+ 활성 클러스터와 종료된 클러스터에 대한 애플리케이션 이력 및 관련 로그 파일에 액세스할 수 있습니다. 로그는 애플리케이션이 종료된 후 30일 동안 사용할 수 있습니다.
콘솔의 클러스터 세부 정보로 이동한 다음 **애플리케이션** 탭을 선택합니다. 클러스터가 시작되고 나면 원하는 애플리케이션 UI를 선택합니다. 애플리케이션 UI가 새 브라우저 탭에서 열립니다. 자세한 내용은 [Monitoring and instrumentation](https://spark.apache.org/docs/latest/monitoring.html)을 참조하세요.
Spark 기록 서버, YARN 타임라인 서버 및 Tez UI의 링크를 통해 YARN 컨테이너 로그를 확인할 있습니다.
**참고**
Spark 기록 서버, YARN 타임라인 서버 및 Tez UI에서 YARN 컨테이너 로그에 액세스하려면 클러스터에서 Amazon S3에 대한 로깅을 활성화해야 합니다. 로깅을 활성화하지 않으면 YARN 컨테이너 로그에 대한 링크가 작동하지 않습니다.
## 로그 수집
영구 애플리케이션 사용자 인터페이스에 대한 원클릭 액세스를 활성화하기 위해 Amazon EMR은 다음 두 가지 유형의 로그를 수집합니다.
+ **애플리케이션 이벤트 로그**는 EMR 시스템 버킷으로 수집됩니다. 저장된 이벤트 로그는 Amazon S3 관리형 키를 사용한 서버 측 암호화(SSE-S3)를 사용해 암호화됩니다. 클러스터에 대해 프라이빗 서브넷을 사용하는 경우 프라이빗 서브넷에 대한 Amazon S3 정책의 리소스 목록에 올바른 시스템 버킷 ARN을 포함해야 합니다. 자세한 내용은 [프라이빗 서브넷에 대한 최소 Amazon S3 정책](https://docs.aws.amazon.com/emr/latest/ManagementGuide/private-subnet-iampolicy.html)을 참조하세요.
+ **YARN 컨테이너 로그**는 사용자가 소유한 Amazon S3 버킷으로 수집됩니다. YARN 컨테이너 로그에 액세스하려면 클러스터에 대한 로깅을 활성화해야 합니다. 자세한 내용은 [클러스터 로깅 및 디버깅 구성](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html)을 참조하세요.
개인적인 이유로 로그 수집 기능을 비활성화해야 한다면 클러스터를 생성할 때 다음 예제와 같이 부트스트랩 스크립트를 사용해 대몬을 중지할 수 있습니다.
```
aws emr create-cluster --name "Stop Application UI Support" --release-label emr-7.12.0 \
--applications Name=Hadoop Name=Spark --ec2-attributes KeyName= \
--instance-groups InstanceGroupType=MASTER,InstanceCount=1,InstanceType=m3.xlarge InstanceGroupType=CORE,InstanceCount=1,InstanceType=m3.xlarge InstanceGroupType=TASK,InstanceCount=1,InstanceType=m3.xlarge \
--use-default-roles --bootstrap-actions Path=s3://region.elasticmapreduce/bootstrap-actions/run-if,Args=["instance.isMaster=true","echo Stop Application UI | sudo tee /etc/apppusher/run-apppusher; sudo systemctl stop apppusher || exit 0"]
```
이 부트스트랩 스크립트를 실행하면 Amazon EMR이 Spark 기록 서버 또는 YARN 타임라인 서버 이벤트 로그를 EMR 시스템 버킷으로 수집하지 않습니다. 따라서 **Application user interfaces(애플리케이션 사용자 인터페이스)** 탭에서 애플리케이션 이력 정보를 확인할 수 없으며 콘솔에서 모든 애플리케이션 사용자 인터페이스에 액세스할 수 없습니다.
## 대형 Spark 이벤트 로그 파일
경우에 따라 Spark 스트리밍과 같이 장기 실행 Spark 작업 및 Spark SQL 쿼리와 같은 대형 작업은 큰 이벤트 로그를 생성할 수 있습니다. 이벤트 로그가 크면 컴퓨팅 인스턴스의 디스크 공간이 빠르게 소진되고 영구 UI를 로드할 때 `OutOfMemory` 오류가 발생할 수 있습니다. 이러한 문제를 방지하려면 Spark 이벤트 로그 롤링 및 압축 기능을 켜는 것이 좋습니다. 이 기능은 Amazon EMR 버전 emr-6.1.0 이상에서 사용할 수 있습니다. 롤링 및 압축에 대한 자세한 내용은 Spark 설명서에서 [Applying compaction on rolling event log files](https://spark.apache.org/docs/latest/monitoring.html#applying-compaction-on-rolling-event-log-files)를 참조하세요.
Spark 이벤트 로그 롤링 및 압축 기능을 활성화하려면 다음 Spark 구성 설정을 켭니다.
+ `spark.eventLog.rolling.enabled` - 크기에 따른 이벤트 로그 롤링을 켭니다. 이 설정은 기본적으로 비활성화되어 있습니다.
+ `spark.eventLog.rolling.maxFileSize` - 롤링이 활성화된 경우 롤오버하기 전 이벤트 로그 파일의 최대 크기를 지정합니다. 기본값은 128MB입니다.
+ `spark.history.fs.eventLog.rolling.maxFilesToRetain` - 유지할 압축되지 않은 이벤트 로그 파일의 최대 수를 지정합니다. 기본적으로 모든 이벤트 로그 파일이 유지됩니다. 이전 이벤트 로그를 압축하려면 더 낮은 숫자로 설정합니다. 가장 낮은 값은 1입니다.
압축 시 다음과 같이 오래된 이벤트 로그 파일이 있는 이벤트를 제외하려고 합니다. 이벤트를 버리면 Spark 기록 서버 UI에 해당 이벤트가 더 이상 표시되지 않습니다.
+ 완료된 작업에 대한 이벤트 및 관련 단계 또는 작업 이벤트.
+ 종료된 실행기에 대한 이벤트.
+ 완료된 SQL 쿼리에 대한 이벤트 및 관련 작업, 단계, 작업 이벤트.
**롤링 및 압축이 활성화된 상태로 클러스터를 시작하는 방법**
1. 다음 구성을 사용하여 `spark-configuration.json` 파일을 생성합니다.
```
[
{
"Classification": "spark-defaults",
"Properties": {
"spark.eventLog.rolling.enabled": true,
"spark.history.fs.eventLog.rolling.maxFilesToRetain": 1
}
}
]
```
1. 다음과 같이 Spark 롤링 압축 구성을 사용하여 클러스터를 생성합니다.
```
aws emr create-cluster \
--release-label emr-6.6.0 \
--instance-type m4.large \
--instance-count 2 \
--use-default-roles \
--configurations file://spark-configuration.json
```
## 영구 애플리케이션 사용자 인터페이스를 볼 수 있는 권한
다음 샘플은 영구 애플리케이션 사용자 인터페이스에 액세스하는 데 필요한 역할 권한을 보여줍니다. 런타임 역할이 활성화된 클러스터의 경우 사용자가 동일한 사용자 자격 증명 및 런타임 역할에서 제출한 애플리케이션에만 액세스할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:CreatePersistentAppUI",
"elasticmapreduce:DescribePersistentAppUI"
],
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/clusterId"
],
"Sid": "AllowELASTICMAPREDUCECreatepersistentappui"
},
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:GetPersistentAppUIPresignedURL"
],
"Resource": [
"arn:aws:elasticmapreduce:*:123456789012:cluster/clusterId",
"arn:aws:elasticmapreduce:*:123456789012:persistent-app-ui/*"
],
"Condition": {
"StringEqualsIfExists": {
"elasticmapreduce:ExecutionRoleArn": [
"arn:aws:iam::123456789012:role/executionRoleArn"
]
}
},
"Sid": "AllowELASTICMAPREDUCEGetpersistentappuipresignedurl"
}
]
}
```
------
다음 샘플은 런타임 역할 지원 클러스터의 영구 애플리케이션 사용자 인터페이스에서 애플리케이션 보기에 대한 제한을 제거하는 데 필요한 역할 권한을 보여줍니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:CreatePersistentAppUI",
"elasticmapreduce:DescribePersistentAppUI",
"elasticmapreduce:AccessAllEventLogs"
],
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-XXXXXXXXXXXXX"
],
"Sid": "AllowELASTICMAPREDUCECreatepersistentappui"
},
{
"Effect": "Allow",
"Action": [
"elasticmapreduce:GetPersistentAppUIPresignedURL"
],
"Resource": [
"arn:aws:elasticmapreduce:us-east-1:123456789012:cluster/j-XXXXXXXXXXXXX",
"arn:aws:elasticmapreduce:us-east-1:123456789012:persistent-app-ui/*"
],
"Condition": {
"StringEqualsIfExists": {
"elasticmapreduce:ExecutionRoleArn": [
"arn:aws:iam::123456789012:role/YourExecutionRoleName"
]
}
},
"Sid": "AllowELASTICMAPREDUCEGetpersistentappuipresignedurl"
}
]
}
```
------
## 고려 사항 및 제한 사항
영구 애플리케이션 사용자 인터페이스에 대한 원클릭 액세스는 현재 다음과 같은 제한 사항이 있습니다.
+ Spark 기록 서버 UI에 애플리케이션 세부 정보가 표시될 때까지 최소 2분 정도 지연될 수 있습니다.
+ 이 기능은 애플리케이션의 이벤트 로그 디렉터리가 HDFS에 있는 경우에만 작동합니다. 기본적으로 Amazon EMR은 HDFS의 디렉터리에 이벤트 로그를 저장합니다. 기본 디렉터리를 다른 파일 시스템(예: Amazon S3)으로 변경하면 이 기능이 작동하지 않습니다.
+ 여러 개의 마스터 노드가 있는 EMR 클러스터 또는 AWS Lake Formation과 통합된 EMR 클러스터에는 현재 이 기능을 사용할 수 없습니다.
+ 영구 애플리케이션 사용자 인터페이스에 대한 원클릭 액세스를 활성화하려면 Amazon EMR에 대한 `CreatePersistentAppUI`, `DescribePersistentAppUI` 및 `GetPersistentAppUIPresignedURL` 작업의 권한이 있어야 합니다. 이러한 작업에 대한 IAM 보안 주체의 권한을 거부하면 권한 변경을 전파하는 데 약 5분 정도 걸립니다.
+ 클러스터가 런타임 역할이 활성화된 클러스터인 경우 영구 앱 UI에서 Spark 기록 서버에 액세스할 때 사용자는 런타임 역할이 Spark 작업을 제출한 경우에만 Spark 작업에 액세스할 수 있습니다.
+ 클러스터가 런타임 역할이 활성화된 클러스터인 경우 각 사용자는 동일한 사용자 자격 증명 및 런타임 역할이 제출한 애플리케이션에만 액세스할 수 있습니다.
+ Amazon EMR의 `AccessAllEventLogs` 작업은 런타임 역할이 활성화된 클러스터에 대한 영구 애플리케이션 사용자 인터페이스의 모든 애플리케이션을 보는 데 필요합니다.
+ 실행 중인 클러스터에서 애플리케이션을 다시 구성하면 애플리케이션 UI를 통해서는 애플리케이션 이력을 사용할 수 없습니다.
+ 각 활성 애플리케이션 UI AWS 계정의 기본 제한은 200입니다. UIs
+ 다음에서 Amazon EMR 6.14.0 이상을 사용하여 콘솔에서 애플리케이션 UIs에 액세스할 AWS 리전수 있습니다.
+ 아시아 태평양(자카르타) (ap-southeast-3)
+ 유럽(스페인)(eu-south-2)
+ 아시아 태평양(멜버른)(ap-southeast-4)
+ 이스라엘(텔아비브)(il-central-1)
+ 중동(UAE)(me-central-1)
+ 다음에서 Amazon EMR 5.25.0 이상을 사용하여 콘솔에서 애플리케이션 UIs에 액세스할 AWS 리전수 있습니다.
+ 미국 동부(버지니아 북부)(us-east-1)
+ 미국 서부(오레곤)(us-west-2)
+ 아시아 태평양(뭄바이)(ap-south-1)
+ 아시아 태평양(서울)(ap-northeast-2)
+ 아시아 태평양(싱가포르)(ap-southeast-1)
+ 아시아 태평양(시드니)(ap-southeast-2)
+ 아시아 태평양(도쿄)(ap-northeast-1)
+ 캐나다(중부)(ca-central-1)
+ 남아메리카(상파울루)(sa-east-1)
+ 유럽(프랑크푸르트)(eu-central-1)
+ 유럽(아일랜드)(eu-west-1)
+ 유럽(런던) (eu-west-2)
+ 유럽(파리) (eu-west-3)
+ 유럽(스톡홀름)(eu-north-1)
+ 중국(베이징)(cn-north-1)
+ 중국(닝샤)(cn-northwest-1)
# Amazon EMR에서 개요 수준의 애플리케이션 기록 보기
**참고**
앱 기록을 최대 30일 동안 유지하는 향상된 사용자 경험을 위해 영구 애플리케이션 인터페이스를 사용하는 것이 좋습니다. 이 페이지에 설명된 개요 수준 애플리케이션 기록은 새 Amazon EMR 콘솔([https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr))에서 사용할 수 없습니다. 자세한 내용은 [Amazon EMR에서 영구 애플리케이션 사용자 인터페이스 보기](app-history-spark-UI.md) 단원을 참조하십시오.
Amazon EMR 릴리스 5.8.0\$15.36.0 및 6.x 릴리스(최대 6.8.0)에서는 이전 Amazon EMR 콘솔의 **애플리케이션 사용자 인터페이스** 탭에서 개요 수준 애플리케이션 기록을 볼 수 있습니다. Amazon EMR **애플리케이션 사용자 인터페이스**는 애플리케이션 완료 후 7일 동안 애플리케이션 기록 요약을 보관합니다.
## 고려 사항 및 제한 사항
이전 Amazon EMR 콘솔의 **애플리케이션 사용자 인터페이스** 탭을 사용할 경우 다음과 같은 제한 사항을 고려합니다.
+ Amazon EMR 릴리스 5.8.0\$15.36.0 및 6.x 릴리스(최대 6.8.0)를 사용할 때만 개요 수준 애플리케이션 기록기능에 액세스할 수 있습니다. 2023년 1월 23일부터 Amazon EMR은 모든 버전에서 상위 수준의 애플리케이션 기록을 중단합니다. Amazon EMR 버전 5.25.0 이상을 사용하는 경우 영구 애플리케이션 사용자 인터페이스를 대신 사용하는 것이 좋습니다.
+ 개요 수준의 애플리케이션 기록 기능은 Spark Streaming 애플리케이션을 지원하지 않습니다.
+ 여러 프라이머리 노드가 있는 Amazon EMR 클러스터 또는 AWS Lake Formation과 통합된 Amazon EMR 클러스터에서는 현재 영국 애플리케이션 사용자 인터페이스에 원클릭 액세스를 사용할 수 없습니다.
## 예제: 개요 수준의 애플리케이션 기록 보기
다음 과정에서는 이전 콘솔의 클러스터 세부 정보 페이지에서 **애플리케이션 사용자 인터페이스**를 사용해 Spark 또는 YARN 애플리케이션에서 작업 세부 정보 드릴다운을 보여줍니다.
클러스터 세부 정보를 보려면 **클러스터** 목록에서 클러스터 **이름**을 선택합니다. YARN 컨테이너 로그에 대한 정보를 보려면 클러스터에서 로깅을 활성화해야 합니다. 자세한 내용은 [클러스터 로깅 및 디버깅 구성](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-debugging.html)을 참조하세요. Spark 애플리케이션 기록의 경우, Spark 기록 서버 UI를 통해 확인할 수 있는 정보의 하위 집합만 요약 표에 표시됩니다.
**개요 수준 애플리케이션 기록** 아래의 **애플리케이션 사용자 인터페이스** 탭에서 행을 확장하여 Spark 애플리케이션에 대한 진단 요약을 표시하거나 **애플리케이션 ID** 링크를 선택하여 다른 애플리케이션에 대한 세부 정보를 볼 수 있습니다.
![\[Application user interfaces tab showing persistent and on-클러스터 UIs, with YARN application history.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/app-history-app.png)
**애플리케이션 ID** 링크를 선택하면 해당 애플리케이션에 대한 **YARN 애플리케이션** 세부 정보를 표시하도록 UI가 변경됩니다. **YARN 애플리케이션** 세부 정보의 **작업** 탭에서 작업에 **대한 설명** 링크를 선택하여 해당 작업의 세부 정보를 표시할 수 있습니다.
![\[YARN application details showing job history with completed Spark tasks and their statuses.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/app-history-job-1.png)
작업 세부 정보 페이지에서 개별 작업 스테이지에 대한 정보를 확장한 다음 **설명**을 선택하여 스테이지 세부 정보를 확인할 수 있습니다.
![\[EMR 클러스터 interface showing persistent and on-클러스터 application UIs, with job details and stages.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/app-history-job-2.png)
스테이지 세부 정보 페이지에서 스테이지 작업 및 실행기에 대한 주요 지표를 볼 수 있습니다. **로그 보기** 링크를 사용하여 작업 및 실행기 로그를 볼 수도 있습니다.
![\[Application history page showing task metrics, executor details, and log access links for a Spark job.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/app-history-job-3.png)
# Amazon EMR 로그 파일 보기
Amazon EMR 및 Hadoop은 모두 클러스터에서 상태를 보고하는 로그 파일을 생성합니다. 기본적으로 이러한 파일은 `/mnt/var/log/` 디렉터리의 프라이머리 노드에 기록됩니다. 클러스터를 시작할 때 구성한 방법에 따라 이러한 로그를 Amazon S3에도 아카이브할 수 있으며 그래픽 디버깅 도구를 통해 볼 수 있습니다.
프라이머리 노드에는 여러 유형의 로그가 기록됩니다. Amazon EMR은 단계, 부트스트랩 작업 및 인스턴스 상태 로그를 작성합니다. Apache Hadoop은 작업 및 작업 시도의 처리를 보고하기 위해 로그를 작성합니다. Hadoop도 대몬의 로그를 기록합니다. Hadoop에서 작성되는 로그에 대한 자세한 내용은 [http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/ClusterSetup.html](http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/ClusterSetup.html)을 참조하세요.
## 프라이머리 노드에서 로그 파일 보기
다음 테이블에는 프라이머리 노드에 있는 몇 가지 로그 파일이 나열되어 있습니다.
| Location | 설명 |
| --- | --- |
| /emr/instance-controller/log/bootstrap-actions | 부트스트랩 작업의 처리 중 작성된 로그입니다. |
| /mnt/var/log/hadoop-state-pusher | Hadoop 상태 pusher 프로세스에서 작성된 로그입니다. |
| /emr/instance-controller/log | 인스턴스 컨트롤러 로그입니다. |
| /emr/instance-state | 인스턴스 상태 로그입니다. 이 로그에는 노드의 CPU, 메모리 상태 및 가비지 수집기 스레드에 대한 정보가 포함됩니다. |
| /emr/service-nanny | 서비스 nanny 프로세스에서 작성된 로그입니다. |
| /mnt/var/log/*application* | Hadoop, Spark 또는 Hive와 같은 애플리케이션에 특정한 로그입니다. |
| /mnt/var/log/hadoop/steps/*N* | 단계 처리에 대한 정보가 포함된 단계 로그입니다. *N*의 값은 Amazon EMR에서 할당된 단계를 나타냅니다. 예를 들어, 클러스터에는 `s-1234ABCDEFGH` 및 `s-5678IJKLMNOP`라는 두 개의 단계가 있습니다. 첫 번째 단계는 `/mnt/var/log/hadoop/steps/s-1234ABCDEFGH/`에, 그리고 두 번째 단계는 `/mnt/var/log/hadoop/steps/s-5678IJKLMNOP/`에 있습니다. Amazon EMR에서 작성한 단계 로그는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-manage-view-web-log-files.html) |
**AWS CLI를 사용하여 프라이머리 노드의 로그 파일을 보는 방법.**
1. [SSH를 사용하여 Amazon EMR 클러스터 프라이머리 노드에 연결](emr-connect-master-node-ssh.md)에서 설명한 대로, SSH를 사용하여 프라이머리 노드에 연결합니다.
1. 보려는 로그 파일 정보가 포함된 디렉터리로 이동합니다. 이전의 표는 사용 가능한 로그 파일 유형 및 파일이 있는 위치의 목록을 제공합니다. 다음 예제에서는 `s-1234ABCDEFGH`라는 ID의 단계 로그로 이동하기 위한 명령을 보여 줍니다.
```
cd /mnt/var/log/hadoop/steps/s-1234ABCDEFGH/
```
1. 원하는 파일 뷰어를 사용하여 로그 파일을 볼 수 있습니다. 다음 예제에서는 Linux `less` 명령을 사용하여 `controller` 로그 파일을 봅니다.
```
less controller
```
## Amazon S3에 아카이브된 로그 파일 보기
기본적으로 콘솔을 사용하여 시작된 Amazon EMR 클러스터는 로그 파일을 Amazon S3에 자동으로 아카이브합니다. 고유의 로그 경로를 지정하거나 콘솔에서 로그 경로를 자동으로 생성할 수 있습니다. CLI 또는 API를 사용하여 시작된 클러스터의 경우 Amazon S3 로그 아카이브를 수동으로 구성해야 합니다.
Amazon EMR이 로그 파일을 Amazon S3에 아카이브하도록 구성된 경우 지정한 S3 위치(/*cluster-id*/ 폴더)에 파일을 저장합니다. 여기서 *cluster-id*는 클러스터 ID입니다.
다음 테이블에는 Amazon S3에 있는 몇 가지 로그 파일이 나열되어 있습니다.
| Location | 설명 |
| --- | --- |
| /*cluster-id*/node/ | 노드에 대한 부트스트랩 작업, 인스턴스 상태 및 애플리케이션 로그를 포함한 노드 로그입니다. 각 노드에 대한 로그는 해당 노드의 EC2 인스턴스 식별자가 레이블로 지정된 폴더에 저장됩니다. |
| /*cluster-id*/node/*instance-id*/*application* | 애플리케이션과 연결된 각 애플리케이션이나 대몬에서 생성된 로그입니다. 예를 들어, Hive 서버 로그는 `cluster-id/node/instance-id/hive/hive-server.log`에 있습니다. |
| /*cluster-id*/steps/*step-id*/ | 단계 처리에 대한 정보가 포함된 단계 로그입니다. *step-id*의 값은 Amazon EMR에서 할당한 단계 ID를 나타냅니다. 예를 들어, 클러스터에는 `s-1234ABCDEFGH` 및 `s-5678IJKLMNOP`라는 두 개의 단계가 있습니다. 첫 번째 단계는 `/mnt/var/log/hadoop/steps/s-1234ABCDEFGH/`에, 그리고 두 번째 단계는 `/mnt/var/log/hadoop/steps/s-5678IJKLMNOP/`에 있습니다. Amazon EMR에서 작성한 단계 로그는 다음과 같습니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-manage-view-web-log-files.html) |
| /*cluster-id*/containers | 애플리케이션 컨테이너 로그입니다. 각 YARN 애플리케이션에 대한 로그가 이 위치에 저장됩니다. |
| /*cluster-id*/hadoop-mapreduce/ | MapReduce 작업의 구성 세부 정보 및 작업 기록에 대한 정보가 포함된 로그입니다. |
**Amazon S3 콘솔을 사용하여 Amazon S3에 아카이브된 로그 파일을 보는 방법**
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다.
1. Amazon S3에 로그 파일을 아카이브하도록 클러스터를 구성할 때 지정한 S3 버킷을 엽니다.
1. 표시할 정보가 포함된 로그 파일로 이동합니다. 이전의 표는 사용 가능한 로그 파일 유형 및 파일이 있는 위치의 목록을 제공합니다.
1. 로그 파일 객체를 다운로드하여 확인합니다. 관련 지침은 [객체 다운로드](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html)를 참조하세요.
# Amazon EC2에서 클러스터 인스턴스 보기
Amazon EC2에서는 태그 형태로 리소스에 메타데이터를 배정하여 리소스를 쉽게 관리할 수 있습니다. 각 Amazon EC2 태그는 키와 값으로 구성됩니다. 태그를 사용하면 용도, 소유자 또는 환경 등을 기준으로 하여 Amazon EC2 리소스를 다양한 방식으로 분류할 수 있습니다.
태그에 따라 리소스를 검색하고 필터링할 수 있습니다. AWS 계정을 통해 리소스에 할당하는 태그는 사용자만 사용할 수 있습니다. 동일한 리소스를 공유하는 다른 계정에서는 태그를 볼 수 없습니다.
Amazon EMR은 키-값 페어로 시작하는 각 EC2 인스턴스에 자동으로 태그를 지정합니다. 키는 인스턴스가 속한 클러스터 및 인스턴스 그룹을 식별합니다. 따라서 표시할 EC2 인스턴스를 쉽게 필터링할 수 있습니다. 예를 들어, 특정 클러스터에 속하는 인스턴스만 표시하거나 작업의 인스턴스 그룹에서 현재 실행 중인 인스턴스를 모두 표시할 수 있습니다. 이 기능은 많은 EC2 인스턴스를 관리하거나 여러 클러스터를 동시에 실행 중인 경우에 특히 유용합니다.
다음은 Amazon EMR에서 할당하는 사전 정의된 키-값 페어입니다.
| Key(키) | 값 | 값 정의 |
| --- | --- | --- |
| aws:elasticmapreduce:job-flow-id | `job-flow-identifier` | 인스턴스가 프로비저닝되는 클러스터의 ID. `j-XXXXXXXXXXXXX` 형식으로 표시되며, 최대 256자일 수 있습니다. |
| aws:elasticmapreduce:instance-group-role | `group-role` | 인스턴스 그룹 유형(`master`, `core` 또는 `task` 값 중 하나로 입력됨). |
Amazon EMR에서 추가하는 태그를 보고 필터링할 수 있습니다. 자세한 내용은 **Amazon EC2 사용 설명서의 [태그 사용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)을 참조하세요. Amazon EMR에서 설정한 태그는 시스템 태그여서 편집하거나 삭제할 수 없으므로 가장 관련성이 높은 섹션은 태그 표시 및 필터링에 대한 섹션입니다.
**참고**
Amazon EMR은 상태가 **실행 중**으로 업데이트될 때 EC2 인스턴스에 태그를 추가합니다. EC2 인스턴스가 프로비저닝되는 시간과 상태가 **실행 중**으로 설정된 시간 사이에 지연이 발생하는 경우 인스턴스가 시작되면 Amazon EMR이 설정하는 태그가 나타납니다. 태그가 표시되지 않으면 몇 분 기다렸다가 보기를 새로 고칩니다.
# Amazon EMR에서 CloudWatch 이벤트 및 지표
이벤트와 지표를 사용하여 Amazon EMR 클러스터의 활동 및 상태를 추적합니다. 이벤트는 클러스터 내에서 특정 발생을 모니터링하는 데 유용합니다. 예를 들어, 클러스터가 시작 중에서 실행 중으로 상태가 변경되는 경우입니다. 지표는 특정 값(예: 클러스터 내에서 HDFS가 사용하는 사용 가능한 디스크 공간의 비율)을 모니터링하는 데 유용합니다.
CloudWatch Events에 대한 자세한 내용은 [Amazon CloudWatch Events 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/)를 참조하세요. CloudWatch 지표에 대한 자세한 내용은 *Amazon CloudWatch 사용 설명서*에서 [Amazon CloudWatch 지표 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 및 [Amazon CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.
**Topics**
+ [CloudWatch에서 Amazon EMR 지표 모니터링](UsingEMR_ViewingMetrics.md)
+ [CloudWatch에서 Amazon EMR 이벤트 모니터링](emr-manage-cloudwatch-events.md)
+ [Amazon EMR에서 CloudWatch 이벤트에 대한 대응](emr-events-response.md)
# CloudWatch에서 Amazon EMR 지표 모니터링
지표는 각 Amazon EMR 클러스터에서 5분마다 업데이트되고 자동으로 수집되며 CloudWatch로 푸시됩니다. 이 간격은 구성할 수 없습니다. CloudWatch에서 보고되는 Amazon EMR 지표에는 요금이 부과되지 않습니다. 이 5분의 데이터 포인트 지표는 63일 동안 아카이브되며, 그 이후에는 데이터가 삭제됩니다.
## Amazon EMR 지표를 사용하려면 어떻게 해야 하나요?
다음 테이블에는 Amazon EMR이 보고하는 지표의 일반적인 용도가 나와 있습니다. 모든 사용 사례를 망라한 것은 아니지만 시작하는 데 참고가 될 것입니다. Amazon EMR에서 보고하는 전체 지표 목록은 [CloudWatch에서 Amazon EMR이 보고하는 지표](#UsingEMR_ViewingMetrics_MetricsReported) 섹션을 참조하세요.
****
| 방법 | 관련 지표 |
| --- | --- |
| 내 클러스터의 진행 상황을 추적 | RunningMapTasks, RemainingMapTasks, RunningReduceTasks 및 RemainingReduceTasks 측정치를 살펴봅니다. |
| 유휴 클러스터를 감지 | IsIdle 지표는 클러스터가 활성화되었지만 현재 작업을 실행하고 있지 않은지 여부를 추적합니다. 클러스터가 일정 시간(예: 30분) 동안 유휴 상태일 때 경보가 울리도록 설정할 수 있습니다. |
| 노드에서 저장소가 부족한 경우 감지 | MRUnhealthyNodes 지표는 하나 이상의 코어 또는 태스크 노드에서 로컬 디스크 스토리지가 부족해지고 UNHEALTHY YARN 상태로 전환되는 시점을 추적합니다. 예를 들어, 코어 또는 태스크 노드의 디스크 공간이 부족하여 작업을 실행할 수 없는 경우가 이에 해당합니다. |
| 클러스터에서 스토리지 부족 감지 | HDFSUtilization 지표는 클러스터의 결합된 HDFS 용량을 모니터링하며, 코어 노드를 더 추가하기 위해 클러스터 크기를 조정해야 할 수 있습니다. 예를 들어, HDFS 사용률이 높아 작업 및 클러스터 상태에 영향을 미칠 수 있습니다. |
| 용량을 줄여 클러스터가 실행되는 경우를 감지합니다. | MRLostNodes 지표는 하나 이상의 코어 또는 태스크 노드가 프라이머리 노드와 통신할 수 없는 경우를 추적합니다. 예를 들어, 프라이머리 노드가 코어 또는 태스크 노드에 접속할 수 없습니다. |
자세한 내용은 [NO\$1SLAVE\$1LEFT로 Amazon EMR 클러스터 종료 및 코어 노드 FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md) 및 [AWSSupport-AnalyzeEMRLogs](https://docs.aws.amazon.com//systems-manager-automation-runbooks/latest/userguide/automation-awssupport-analyzeemrlogs.html)를 참조하세요.
## Amazon EMR의 CloudWatch 지표 액세스
Amazon EMR 콘솔 또는 CloudWatch 콘솔을 사용하여 Amazon EMR이 CloudWatch에 보고하는 지표를 볼 수 있습니다. CloudWatch CLI 명령 `[mon-get-stats](https://docs.aws.amazon.com/AmazonCloudWatch/latest/cli/cli-mon-get-stats.html)` 또는 CloudWatch `[GetMetricStatistics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricStatistics.html)` API를 사용하여 지표를 검색할 수도 있습니다. CloudWatch를 사용하여 Amazon EMR 지표를 보거나 검색하는 방법에 대한 자세한 내용은 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)를 참조하세요.
------
#### [ Console ]
**콘솔을 사용하여 지표를 보는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 지표를 볼 클러스터를 선택합니다. 그러면 클러스터 세부 정보 페이지가 열립니다.
1. 클러스터 세부 정보 페이지에서 **모니터링** 탭을 선택합니다. 클러스터의 진행 상황 및 상태에 대한 보고서를 로드하려면 **클러스터 상태**, **노드 상태** 또는 **입력 및 출력** 옵션 중 하나를 선택합니다.
1. 확인할 지표를 선택한 후 각 그래프를 확대할 수 있습니다. 그래프의 기간을 필터링하려면 미리 채워진 옵션을 선택하거나 **사용자 지정**을 선택합니다.
------
## CloudWatch에서 Amazon EMR이 보고하는 지표
다음 테이블에는 콘솔에서 Amazon EMR이 보고하고 CloudWatch에 푸시하는 모든 지표가 나열되어 있습니다.
### Amazon EMR 지표
Amazon EMR은 여러 지표에 대한 데이터를 CloudWatch로 보냅니다. 모든 Amazon EMR 클러스터가 5분 간격으로 지표를 자동으로 전송합니다. 측정치는 2주 간 보관되고 그 후에는 삭제됩니다.
`AWS/ElasticMapReduce` 네임스페이스에는 다음과 같은 지표가 포함됩니다.
**참고**
Amazon EMR은 클러스터에서 지표를 가져옵니다. 이때 클러스터에 도달할 수 없는 경우에는 클러스터를 다시 사용할 수 있을 때까지 아무런 지표도 보고되지 않습니다.
Hadoop 2.x 버전을 실행하는 클러스터에 대해 사용할 수 있는 지표는 다음과 같습니다.
| 지표 | 설명 |
| --- | --- |
| 클러스터 상태 |
| IsIdle | 클러스터가 더 이상 작업을 실행하지 않지만 여전히 활성 상태로 요금이 발생하고 있다는 것을 나타냅니다. 아무런 작업도 실행되고 있지 않으면 1로 설정되고, 그 외에는 0으로 설정됩니다. 이 값은 5분 주기로 검사하며, 값이 1일 때는 클러스터가 검사 시에만 유휴 상태일 뿐 전체 5분간 유휴 상태라는 것을 의미하지는 않습니다. 오탐지를 방지하기 위해서는 이 값이 5분 주기의 연속 검사 1회를 넘어 1을 유지할 때 경보를 알려야 합니다. 예를 들어, 30분 이상 1을 유지하는 경우 이 값에 대한 경보를 제기할 수 있습니다. 사용 사례: 클러스터 성능 모니터링 단위: *부울* |
| ContainerAllocated | ResourceManager에서 할당된 리소스 컨테이너 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ContainerReserved | 예약된 컨테이너 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ContainerPending | 대기열에서 아직 할당되지 않은 컨테이너 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ContainerPendingRatio | 대기 중인 컨테이너와 할당된 컨테이너의 비율(ContainerPendingRatio = ContainerPending / ContainerAllocated). ContainerAllocated가 0이면 ContainerPendingRatio는 ContainerPending과 같습니다. ContainerPendingRatio 값은 비율이 아닌 숫자를 나타냅니다. 이 값은 컨테이너 할당 동작에 따라 클러스터 리소스를 조정하는 데 유용합니다. Units: *Count* |
| AppsCompleted | 완료 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| AppsFailed | 미완료 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| AppsKilled | 종료 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| AppsPending | 대기 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| AppsRunning | 실행 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| AppsSubmitted | YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| 노드 상태 |
| CoreNodesRunning | 작업 중인 코어 노드 수. 이 지표의 데이터 포인트는 해당하는 인스턴스 그룹이 존재하는 경우에만 보고됩니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| CoreNodesPending | 할당 대기 중인 코어 노드 수. 코어 노드를 요청한다고 해서 즉시 모두 제공되는 것은 아닙니다. 이때 이 지표가 대기 중인 요청 수를 보고합니다. 이 지표의 데이터 포인트는 해당하는 인스턴스 그룹이 존재하는 경우에만 보고됩니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| LiveDataNodes | Hadoop에서 작업을 수신 중인 데이터 노드 비율 사용 사례: 클러스터 상태 모니터링 단위: *백분율* |
| MRTotalNodes | 현재 MapReduce 작업에 사용할 수 있는 노드 수 YARN 지표 `mapred.resourcemanager.TotalNodes`와 동등합니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* 참고: MRTotalNodes는 시스템의 현재 활성 노드만 계산합니다. YARN은 이 개수에서 종료된 노드를 자동으로 제거하고 추적을 중지하므로 MRTotalNodes 지표에서 고려되지 않습니다. |
| MRActiveNodes | 현재 MapReduce 작업 또는 작업을 실행 중인 노드 수 YARN 지표 `mapred.resourcemanager.NoOfActiveNodes`와 동등합니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| MRLostNodes | MapReduce에 LOST 상태로 할당된 노드 수 YARN 지표 `mapred.resourcemanager.NoOfLostNodes`와 동등합니다. 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| MRUnhealthyNodes | UNHEALTHY 상태이면서 MapReduce 작업에 사용할 수 있는 노드 수 YARN 지표 `mapred.resourcemanager.NoOfUnhealthyNodes`와 동등합니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| MRDecommissionedNodes | MapReduce 애플리케이션에 DECOMMISSIONED 상태로 할당된 노드 수 YARN 지표 `mapred.resourcemanager.NoOfDecommissionedNodes`와 동등합니다. 사용 사례: 클러스터 상태 모니터링, 클러스터 진행 상황 모니터링 Units: *Count* |
| MRRebootedNodes | 재부팅되어 REBOOTED 상태이면서 MapReduce에 사용할 수 있는 노드 수 YARN 지표 `mapred.resourcemanager.NoOfRebootedNodes`와 동등합니다. 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| MultiMasterInstanceGroupNodesRunning | 실행 중인 마스터 노드의 수입니다. 사용 사례: 마스터 노드 장애 및 교체 모니터링 Units: *Count* |
| MultiMasterInstanceGroupNodesRunningPercentage | 요청된 수의 마스터 노드 인스턴스에서 실행 중인 마스터 노드의 백분율입니다. 사용 사례: 마스터 노드 장애 및 교체 모니터링 단위: *백분율* |
| MultiMasterInstanceGroupNodesRequested | 요청된 마스터 노드의 수입니다. 사용 사례: 마스터 노드 장애 및 교체 모니터링 Units: *Count* |
| IO |
| S3BytesWritten | Amazon S3에 기록된 바이트 수입니다. 이 지표는 MapReduce 작업만 집계하며, Amazon EMR의 다른 워크로드에는 적용되지 않습니다. 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| S3BytesRead | Amazon S3에서 읽은 바이트 수입니다. 이 지표는 MapReduce 작업만 집계하며, Amazon EMR의 다른 워크로드에는 적용되지 않습니다. 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| HDFSUtilization | 현재 사용 중인 HDFS 스토리지 비율 사용 사례: 클러스터 성능 분석 단위: *백분율* |
| HDFSBytesRead | HDFS에서 읽어온 바이트 수 이 지표는 MapReduce 작업만 집계하며, Amazon EMR의 다른 워크로드에는 적용되지 않습니다. 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| HDFSBytesWritten | HDFS에 작성된 바이트 수 이 지표는 MapReduce 작업만 집계하며, Amazon EMR의 다른 워크로드에는 적용되지 않습니다. 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| MissingBlocks | HDFS에 복제본이 없는 블록 수. 이는 손상된 블록일 수 있습니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| CorruptBlocks | HDFS가 손상된 것으로 보고하는 블록 수 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| TotalLoad | 동시 데이터 전송 총 수 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| MemoryTotalMB | 클러스터의 총 메모리 크기 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| MemoryReservedMB | 예약된 메모리 크기 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| MemoryAvailableMB | 할당 가능한 메모리 크기 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| YARNMemoryAvailablePercentage | YARN에 사용할 수 있는 잔여 메모리 비율(YARNMemoryAvailablePercentage = MemoryAvailableMB / MemoryTotalMB). 이 값은 YARN 메모리 사용량을 기준으로 클러스터 리소스를 조정하는 데 유용합니다. 단위: *백분율* |
| MemoryAllocatedMB | 클러스터에 할당된 메모리 크기 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| PendingDeletionBlocks | 삭제 표시된 블록 수 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| UnderReplicatedBlocks | 1회 이상 복제해야 하는 블록 수 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| DfsPendingReplicationBlocks | 블록 복제 상태: 복제 중인 블록, 복제 요청의 경과 시간, 성공하지 못한 복제 요청 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
| CapacityRemainingGB | 남아있는 HDFS 디스크 용량 크기 사용 사례: 클러스터 진행 상황 모니터링, 클러스터 상태 모니터링 Units: *Count* |
다음은 Hadoop 1 지표입니다.
| 지표 | 설명 |
| --- | --- |
| 클러스터 상태 |
| IsIdle | 클러스터가 더 이상 작업을 실행하지 않지만 여전히 활성 상태로 요금이 발생하고 있다는 것을 나타냅니다. 아무런 작업도 실행되고 있지 않으면 1로 설정되고, 그 외에는 0으로 설정됩니다. 이 값은 5분 주기로 검사하며, 값이 1일 때는 클러스터가 검사 시에만 유휴 상태일 뿐 전체 5분간 유휴 상태라는 것을 의미하지는 않습니다. 오탐지를 방지하기 위해서는 이 값이 5분 주기의 연속 검사 1회를 넘어 1을 유지할 때 경보를 알려야 합니다. 예를 들어, 30분 이상 1을 유지하는 경우 이 값에 대한 경보를 제기할 수 있습니다. 사용 사례: 클러스터 성능 모니터링 단위: *부울* |
| JobsRunning | 클러스터에서 현재 실행 중인 작업 수 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| JobsFailed | 클러스터에서 실패한 작업 수 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| 맵/감소 |
| MapTasksRunning | 각 작업마다 실행 중인 맵 태스크 수. 스케줄러를 설치하여 여러 작업을 실행 중인 경우에는 다수의 그래프가 생성됩니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| MapTasksRemaining | 각 작업마다 남아있는 맵 태스크 수. 스케줄러를 설치하여 여러 작업을 실행 중인 경우에는 다수의 그래프가 생성됩니다. 남아있는 맵 태스크란 Running, Killed 또는 Completed 상태가 아닌 태스크를 말합니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| MapSlotsOpen | 사용하지 않은 맵 태스크 용량. 이 용량은 임의 클러스터에서 현재 실행 중인 전체 맵 태스크 수를 뺀 최대 맵 태스크 수로 계산됩니다. 사용 사례: 클러스터 성능 분석 Units: *Count* |
| RemainingMapTasksPerSlot | 클러스터에서 남아있는 전체 맵 작업과 사용할 수 있는 전체 맵 슬롯의 비율 사용 사례: 클러스터 성능 분석 단위: *비율* |
| ReduceTasksRunning | 각 작업마다 실행 중인 reduce 작업 수. 스케줄러를 설치하여 여러 작업을 실행 중인 경우에는 다수의 그래프가 생성됩니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ReduceTasksRemaining | 각 작업마다 남아있는 reduce 작업 수. 스케줄러를 설치하여 여러 작업을 실행 중인 경우에는 다수의 그래프가 생성됩니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ReduceSlotsOpen | 사용하지 않은 reduce 작업 용량. 이 용량은 임의 클러스터에서 현재 실행 중인 reduce 작업 수를 뺀 최대 reduce 작업 용량으로 계산됩니다. 사용 사례: 클러스터 성능 분석 Units: *Count* |
| 노드 상태 |
| CoreNodesRunning | 작업 중인 코어 노드 수. 이 지표의 데이터 포인트는 해당하는 인스턴스 그룹이 존재하는 경우에만 보고됩니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| CoreNodesPending | 할당 대기 중인 코어 노드 수. 코어 노드를 요청한다고 해서 즉시 모두 제공되는 것은 아닙니다. 이때 이 지표가 대기 중인 요청 수를 보고합니다. 이 지표의 데이터 포인트는 해당하는 인스턴스 그룹이 존재하는 경우에만 보고됩니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| LiveDataNodes | Hadoop에서 작업을 수신 중인 데이터 노드 비율 사용 사례: 클러스터 상태 모니터링 단위: *백분율* |
| TaskNodesRunning | 작업 중인 작업 노드 수. 이 지표의 데이터 포인트는 해당하는 인스턴스 그룹이 존재하는 경우에만 보고됩니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| TaskNodesPending | 할당 대기 중인 작업 노드 수. 작업 노드를 요청한다고 해서 즉시 모두 제공되는 것은 아닙니다. 이때 이 지표가 대기 중인 요청 수를 보고합니다. 이 지표의 데이터 포인트는 해당하는 인스턴스 그룹이 존재하는 경우에만 보고됩니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| LiveTaskTrackers | 실행 중인 태스크 트래커 비율 사용 사례: 클러스터 상태 모니터링 단위: *백분율* |
| IO |
| S3BytesWritten | Amazon S3에 기록된 바이트 수입니다. 이 지표는 MapReduce 작업만 집계하며, Amazon EMR의 다른 워크로드에는 적용되지 않습니다. 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| S3BytesRead | Amazon S3에서 읽은 바이트 수입니다. 이 지표는 MapReduce 작업만 집계하며, Amazon EMR의 다른 워크로드에는 적용되지 않습니다. 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| HDFSUtilization | 현재 사용 중인 HDFS 스토리지 비율 사용 사례: 클러스터 성능 분석 단위: *백분율* |
| HDFSBytesRead | HDFS에서 읽어온 바이트 수 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| HDFSBytesWritten | HDFS에 작성된 바이트 수 사용 사례: 클러스터 성능 분석, 클러스터 진행 상황 모니터링 Units: *Count* |
| MissingBlocks | HDFS에 복제본이 없는 블록 수. 이는 손상된 블록일 수 있습니다. 사용 사례: 클러스터 상태 모니터링 Units: *Count* |
| TotalLoad | 클러스터의 모든 DataNodes가 보고하는 현재 리더 및 라이터의 총 수. 사용 사례: 높은 I/O가 작업 실행 성능 저하에 기여하는 정도를 진단합니다. DataNode 대몬에서 실행되는 작업자 노드 역시 맵 및 reduce 작업을 수행해야 합니다. 시간이 지나도 지속적으로 높은 TotalLoad 값은 높은 I/O가 성능 저하의 원인일 가능성을 나타낼 수 있습니다. 이 값이 이따금 급증하는 것은 일반적인 것이며, 보통은 문제를 나타내지 않습니다. Units: *Count* |
#### 클러스터 용량 지표
다음 지표는 클러스터의 현재 또는 대상 용량을 나타냅니다. 이러한 지표는 Managed Scaling 또는 자동 종료가 활성화된 경우에만 사용할 수 있습니다.
인스턴스 플릿으로 구성된 클러스터의 경우, 클러스터 용량 지표는 `Units`에서 측정됩니다. 인스턴스 그룹으로 구성된 클러스터의 경우, 클러스터 용량 지표는 관리형 조정 정책에 사용된 단위 유형을 기반으로 하는 `VCPU`에서 또는 `Nodes`에서 측정됩니다. 자세한 내용은 *Amazon EMR 관리 안내서*의 [EMR Managed Scaling 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html)을 참조하세요.
| 지표 | 설명 |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | 관리형 조정에 의해 결정된 클러스터의 총 units/nodes/vCPU 대상 수입니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | 실행 중인 클러스터에서 사용 가능한 현재 총unit/node/vCPU 수입니다. 클러스터 크기 조정이 요청되면 새 인스턴스가 클러스터에 추가되거나 클러스터에서 제거된 후 이 지표가 업데이트됩니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | 관리형 조정에 의해 결정된 클러스터의 CORE unit/node/vCPU 대상 수입니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | 클러스터에서 실행 중인 현재 CORE unit/node/vCPU 수입니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | 관리형 조정에 의해 결정된 클러스터의 TASK unit/node/vCPU 대상 수입니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) | 클러스터에서 실행 중인 현재 TASK unit/node/vCPU 수입니다. Units: *Count* |
자동 종료 정책을 사용하여 자동 종료를 활성화하면 Amazon EMR은 1분 단위로 다음 지표를 생성합니다. 일부 지표는 Amazon EMR 버전 6.4.0 이상에만 사용할 수 있습니다. 자동 종료에 대한 자세한 내용은 [Amazon EMR 클러스터 정리에 대한 자동 종료 정책 사용](emr-auto-termination-policy.md) 섹션을 참조하세요.
****
| 지표 | 설명 |
| --- | --- |
| TotalNotebookKernels | 클러스터에서 실행 중 및 유휴 상태의 노트북 커널 총 수.이 지표는 Amazon EMR 버전 6.4.0 이상에만 사용할 수 있습니다. |
| AutoTerminationIsClusterIdle | 클러스터가 사용 중인지 여부를 나타냅니다.값이 **0**이면 다음 구성 요소 중 하나가 클러스터를 사용하고 있음을 나타냅니다.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html) 값이 **1**이면 클러스터가 유휴 상태임을 나타냅니다. Amazon EMR은 지속적인 클러스터 유휴 상태(`AutoTerminationIsClusterIdle`=1)를 확인합니다. 클러스터의 유휴 시간이 자동 종료 정책의 `IdleTimeout` 값과 같으면 Amazon EMR은 클러스터를 종료합니다. |
### Amazon EMR 지표 차원
다음 테이블의 차원을 사용하여 Amazon EMR 데이터를 필터링할 수 있습니다.
| 차원 | 설명 |
| --- | --- |
| JobFlowId | 클러스터 ID와 동일합니다. 이는 j-XXXXXXXXXXXXX 양식의 클러스터 고유 식별자입니다. Amazon EMR 콘솔에서 클러스터를 클릭하여 이 값을 찾습니다. |
# CloudWatch에서 Amazon EMR 이벤트 모니터링
Amazon EMR은 Amazon EMR 콘솔에서 이벤트를 추적하고 이벤트 관련 정보를 최대 7일 동안 보관합니다. Amazon EMR은 클러스터, 인스턴스 그룹, 인스턴스 플릿, 자동 조정 정책 또는 단계의 상태가 변경될 때 이벤트를 기록합니다. 이벤트는 이벤트가 발생한 날짜 및 시간, 영향을 받는 요소에 대한 세부 정보 및 기타 중요한 데이터 포인트를 캡처합니다.
다음 테이블에는 Amazon EMR 이벤트와 함께 이벤트가 나타내는 상태 또는 상태 변경, 이벤트의 심각도, 이벤트 유형, 이벤트 코드 및 이벤트 메시지가 나와 있습니다. Amazon EMR은 이벤트를 JSON 객체로 표현하고 자동으로 이벤트 스트림으로 전송합니다. CloudWatch Events를 사용한 이벤트 처리를 위한 규칙은 JSON 객체의 패턴과 일치하므로 JSON 객체는 이 규칙을 설정할 때 중요합니다. 자세한 내용은 *Amazon CloudWatch Events 사용 설명서*에서 [Events and event patterns](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/CloudWatchEventsandEventPatterns.html) 및 [Amazon EMR events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#emr_event_type)를 참조하세요.
**참고**
EMR은 이벤트 코드 **EC2 프로비저닝 - 인스턴스 용량 부족**으로 이벤트를 주기적으로 내보냅니다. 이러한 이벤트는 클러스터 생성 또는 크기 조정 작업 중에 Amazon EMR 클러스터에서 Amazon EMR의 인스턴스 플릿 또는 인스턴스 그룹에 대한 용량 부족 오류가 발생하는 경우 주기적으로 발생합니다. EMR에는 마지막 용량 부족 이벤트가 발생한 이후 용량을 프로비저닝하려고 시도한 인스턴스 유형 및 AZ만 포함되므로 이벤트에 AZs 사용자가 제공한 모든 인스턴스 유형 및 AZs가 포함되지 않을 수 있습니다. 이러한 이벤트에 응답하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터 인스턴스 용량 부족 이벤트에 대한 응답](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-events-response-insuff-capacity.html)을 참조하세요.
## 클러스터 시작 이벤트
| 상태 또는 상태 변경 | 심각도 | 이벤트 유형 | 이벤트 코드 | 메시지 |
| --- | --- | --- | --- | --- |
| CREATING | WARN | EMR 인스턴스 플릿 프로비저닝 | EC2 프로비저닝 - 인스턴스 용량 부족 | 인스턴스 플릿 InstanceFleetID에 대해 Amazon EMR ClusterId (ClusterName) 클러스터를 생성할 수 없습니다. [Instancetype3, Instancetype4] 가용 영역에서 인스턴스 유형 [Instancetype1, Instancetype2]에 사용할 Amazon EC2의 스팟 용량이 부족하고 인스턴스 유형 [AvailabilityZone1, AvaliabilityZone2]에 사용할 온디맨드 용량이 부족합니다. 이 이벤트에 대응하는 방법에 대한 자세한 내용은 이 [설명서](emr-EC2_INSUFFICIENT_CAPACITY-error.md)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 그룹 프로비저닝 | EC2 프로비저닝 - 인스턴스 용량 부족 | 인스턴스 그룹 InstanceGroupID에 대해 Amazon EMR ClusterId (ClusterName) 클러스터를 생성할 수 없습니다. [Instancetype3, Instancetype4] 가용 영역에서 인스턴스 유형 [Instancetype1, Instancetype2]에 사용할 Amazon EC2의 스팟 용량이 부족하고 인스턴스 유형 [AvailabilityZone1, AvaliabilityZone2]에 사용할 온디맨드 용량이 부족합니다. 이 이벤트에 대응하는 방법에 대한 자세한 내용은 이 [설명서](emr-EC2_INSUFFICIENT_CAPACITY-error.md)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 플릿 프로비저닝 | EC2 프로비저닝 - 서브넷의 사용 가능한 주소가 부족함 | 지정된 서브넷 [Subnet1, Subnet2]에 사용 가능한 프라이빗 IP 주소가 부족하여 요청을 이행할 수 없으므로 인스턴스 플릿 InstanceFleetID에 대해 요청한 Amazon EMR 클러스터 ClusterId (ClusterName)를 생성할 수 없습니다. DescribeSubnets 작업을 사용하여 서브넷에서 사용 가능한 IP 주소 수(사용되지 않은 주소)를 확인합니다. 이 이벤트에 응답하는 방법에 대한 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 그룹 프로비저닝 | EC2 프로비저닝 - 서브넷의 사용 가능한 주소가 부족함 | 지정된 서브넷 [Subnet1, Subnet2]에 사용 가능한 프라이빗 IP 주소가 부족하여 요청을 이행할 수 없으므로 인스턴스 그룹 InstanceGroupID에 대해 요청한 Amazon EMR 클러스터 ClusterId (ClusterName)를 생성할 수 없습니다. DescribeSubnets 작업을 사용하여 서브넷에서 사용 가능한 IP 주소 수(사용되지 않은 주소)를 확인합니다. 이 이벤트에 응답하는 방법에 대한 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 플릿 프로비저닝 | EC2 프로비저닝 - vCPU 제한을 초과함 | account (accountId)에서 실행 중인 인스턴스에 할당된 vCPU(가상 처리 단위) 수의 제한에 도달했으므로 Amazon EMR 클러스터 ClusterId (ClusterName)에서 InstanceFleetID의 프로비전이 지연됩니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 그룹 프로비저닝 | EC2 프로비저닝 - vCPU 제한을 초과함 | 계정 (accountId)에서 실행 중인 인스턴스에 할당된 vCPU(가상 처리 단위) 수의 제한에 도달했으므로 Amazon EMR 클러스터 ClusterId에서 인스턴스 그룹 InstanceGroupID의 프로비전이 지연됩니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 플릿 프로비저닝 | EC2 프로비저닝 - 스팟 인스턴스 수 제한을 초과함 | Amazon EMR 클러스터 ClusterID (ClusterName)에서 인스턴스 플릿 InstanceFleetID의 프로비전이 지연됩니다. account (accountId)에서 시작할 수 있는 스팟 인스턴스 수의 제한에 도달했기 때문입니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 그룹 프로비저닝 | EC2 프로비저닝 - 스팟 인스턴스 수 제한을 초과함 | Amazon EMR 클러스터 ClusterID (ClusterName)에서 인스턴스 그룹 InstanceGroupID의 프로비전이 지연됩니다. account (accountId)에서 시작할 수 있는 스팟 인스턴스 수의 제한에 도달했기 때문입니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 플릿 프로비저닝 | EC2 프로비저닝 - 인스턴스 제한을 초과함 | Amazon EMR 클러스터 ClusterId (ClusterName)에서 인스턴스 플릿 InstanceFleetID의 프로비전이 지연됩니다. account (accountID)에서 동시에 실행할 수 있는 인스턴스 수의 제한에 도달했기 때문입니다. Amazon EC2 서비스 제한에 대한 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 그룹 프로비저닝 | EC2 프로비저닝 - 인스턴스 제한을 초과함 | Amazon EMR 클러스터 ClusterId (ClusterName)에서 인스턴스 그룹 InstanceGroupID의 프로비전이 지연됩니다. account (accountID)에서 동시에 실행할 수 있는 인스턴스 수의 제한에 도달했기 때문입니다. Amazon EC2 서비스 제한에 대한 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| CREATING | WARN | EMR 인스턴스 그룹 프로비저닝 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `Time`에 생성되었으며 바로 사용할 수 있습니다. – 또는 - Amazon EMR 클러스터 `ClusterId (ClusterName)`에서는 `Time`에 보류 중 상태인 모든 단계를 완료했습니다. 그럼에도 불구하고 `WAITING` 상태의 클러스터가 작업을 처리 중일 수 있습니다. |
| STARTING | INFO | EMR 클러스터 상태 변경 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `Time`에 등록되었으며 생성 중입니다. |
| STARTING | INFO | EMR 클러스터 상태 변경 | *none* | Amazon EC2 내에서 선택된 인스턴스 플릿 구성 및 여러 가용 영역이 있는 클러스터에만 적용됩니다. Amazon EMR `ClusterId (ClusterName)` 클러스터는 지정된 가용 영역 옵션에서 선택한 영역(`AvailabilityZoneID`)에서 생성 중입니다. |
| STARTING | INFO | EMR 클러스터 상태 변경 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `Time`에 실행 중 단계를 시작했습니다. |
| WAITING | INFO | EMR 클러스터 상태 변경 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `Time`에 생성되었으며 바로 사용할 수 있습니다. – 또는 - Amazon EMR 클러스터 `ClusterId (ClusterName)`에서는 `Time`에 보류 중 상태인 모든 단계를 완료했습니다. 그럼에도 불구하고 `WAITING` 상태의 클러스터가 작업을 처리 중일 수 있습니다. |
**참고**
클러스터 생성 또는 크기 조정 작업 중에 EMR 클러스터에서 Amazon EC2의 인스턴스 플릿 또는 인스턴스 그룹에 대한 용량 부족 오류가 발생하면 `EC2 provisioning - Insufficient Instance Capacity` 이벤트 코드의 이벤트가 주기적으로 발생합니다. 이러한 이벤트에 대응하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터 인스턴스 용량 부족 이벤트에 대한 대응](emr-events-response-insuff-capacity.md) 섹션을 참조하세요.
## 클러스터 종료 이벤트
| 상태 또는 상태 변경 | 심각도 | 이벤트 유형 | 이벤트 코드 | 메시지 |
| --- | --- | --- | --- | --- |
| TERMINATED | 심각도는 다음과 같이 상태가 변경된 이유에 따라 다릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html) | EMR 클러스터 상태 변경 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `StateChangeReason:Code`의 이유로 `Time`에 종료되었습니다. |
| TERMINATED\$1WITH\$1ERRORS | CRITICAL | EMR 클러스터 상태 변경 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `StateChangeReason:Code`의 이유로 `Time`에 오류로 종료되었습니다. |
| TERMINATED\$1WITH\$1ERRORS | CRITICAL | EMR 클러스터 상태 변경 | *none* | Amazon EMR `ClusterId (ClusterName)` 클러스터가 `StateChangeReason:Code`의 이유로 `Time`에 오류로 종료되었습니다. |
## 인스턴스 플릿 상태 변경 이벤트
**참고**
인스턴스 플릿 구성은 5.0.0 및 5.0.3을 제외한 Amazon EMR 릴리스 4.8.0 이상에서만 제공됩니다.
****
| 상태 또는 상태 변경 | 심각도 | 이벤트 유형 | 이벤트 코드 | 메시지 |
| --- | --- | --- | --- | --- |
| `PROVISIONING`에서 `WAITING`으로 | INFO | | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `InstanceFleetID`에 대한 프로비저닝이 완료되었습니다. 프로비저닝이 `Time`에 시작되었고 `Num`분이 걸렸습니다. 이제 인스턴스 플릿의 온디맨드 용량은 `Num`이며, 스팟 용량은 `Num`입니다. 목표 온디맨드 용량은 `Num`, 목표 스팟 용량은 `Num`이었습니다. |
| `WAITING`에서 `RESIZING`으로 | INFO | | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `InstanceFleetID`에 대한 크기 조정이 `Time`에 시작되었습니다. 인스턴스 플릿 크기가 `Num`의 온디맨드 용량에서 `Num`의 목표 용량으로, `Num`의 스팟 용량이 `Num`의 목표 용량으로 조정됩니다. |
| `RESIZING`에서 `WAITING`으로 | INFO | | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `InstanceFleetID`에 대한 크기 조정 작업이 완료되었습니다. 크기 조정이 `Time`에 시작되었고 `Num`분이 걸렸습니다. 이제 인스턴스 플릿의 온디맨드 용량은 `Num`이며, 스팟 용량은 `Num`입니다. 목표 온디맨드 용량은 `Num`, 목표 스팟 용량은 `Num`이었습니다. |
| `RESIZING`에서 `WAITING`으로 | INFO | | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `InstanceFleetID`에 대한 크기 조정 작업이 제한 시간에 도달하여 중지되었습니다. 크기 조정이 `Time`에 시작되었고 `Num`분 후에 중지되었습니다. 이제 인스턴스 플릿의 온디맨드 용량은 `Num`이며, 스팟 용량은 `Num`입니다. 목표 온디맨드 용량은 `Num`, 목표 스팟 용량은 `Num`이었습니다. |
| SUSPENDED | ERROR | | none | Amazon EMR `InstanceFleetID` 클러스터의 인스턴스 플릿 `ClusterId (ClusterName)`가 `Time`에 일시 중단되었습니다. 이유: `ReasonDesc`. |
| RESIZING | WARNING | | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `InstanceFleetID`에 대한 크기 조정 작업이 중단되었습니다. 이유: `ReasonDesc`. |
| `WAITING` 또는 `Running` | INFO | | none | Amazon EMR이 `AvailabilityZone` 가용 영역에 스팟 용량을 추가하는 동안 Amazon EMR `InstanceFleetID` 클러스터의 인스턴스 플릿 `ClusterId (ClusterName)`에 대한 크기 조정 작업을 완료할 수 없었습니다. 추가 스팟 용량 프로비저닝 요청을 취소했습니다. 권장 조치로 [Amazon EMR 클러스터에 대한 가용 영역 유연성](emr-flexibility.md)를 확인하고 다시 시도합니다. |
| `WAITING` 또는 `Running` | INFO | | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `InstanceFleetID`에 대한 크기 조정 작업이 `Entity`에 의해 `Time`에 시작되었습니다. |
## 인스턴스 플릿 재구성 이벤트
****
| 상태 또는 상태 변경 | 심각도 | 메시지 |
| --- | --- | --- |
| 인스턴스 플릿 재구성 요청됨 | INFO | 사용자가 Amazon EMR 클러스터`ClusterId`(`ClusterName`)에서 인스턴스 플릿 `InstanceFleetID`을(를) 재구성하도록 요청했습니다. |
| 인스턴스 플릿 재구성 시작 | INFO | Amazon EMR이 `Time`에 있는 Amazon EMR 클러스터`ClusterId`(`ClusterName`)에서 인스턴스 플릿 `InstanceFleetID`의 재구성을 시작했습니다. |
| 인스턴스 플릿 재구성 완료 | INFO | Amazon EMR이 Amazon EMR 클러스터`ClusterId`(`ClusterName`)에서 인스턴스 플릿 `InstanceFleetID`의 재구성을 완료했습니다. |
| 인스턴스 플릿 재구성 실패 | WARNING | Amazon EMR이 `Time`의 Amazon EMR 클러스터`ClusterId`(`ClusterName`)에서 인스턴스 플릿 `InstanceFleetID`을(를) 재구성하지 못했습니다. `Reason`(으)로 인해 재구성에 실패했습니다. |
| 인스턴스 플릿 재구성 되돌리기 시작 | INFO | Amazon EMR은 Amazon EMR 클러스터`ClusterId`(`ClusterName`)의 인스턴스 플릿 `InstanceFleetID`을(를) 이전에 성공한 구성으로 되돌리고 있습니다. |
| 인스턴스 플릿 재구성 되돌리기 완료됨 | INFO | Amazon EMR이 Amazon EMR 클러스터`ClusterId`(`ClusterName`)의 인스턴스 플릿 `InstanceFleetID`을(를) 이전에 성공한 구성으로 되돌렸습니다. |
| 인스턴스 플릿 재구성 되돌리기 실패 | CRITICAL | Amazon EMR은 Amazon EMR 클러스터`ClusterId`(`ClusterName`)에서 인스턴스 플릿 `InstanceFleetID`를 `Time`에서 이전에 성공한 구성으로 되돌릴 수 없습니다. `Reason`(으)로 인해 재구성 되돌리기가 실패했습니다. |
| 인스턴스 플릿 재구성 되돌리기가 차단됨 | INFO | Amazon EMR은 인스턴스 플릿이 `State` 상태이기 때문에 `Time`에서 Amazon EMR 클러스터`ClusterId`(`ClusterName`)의 인스턴스 플릿 `InstanceFleetID`를 일시적으로 차단했습니다. |
## 인스턴스 플릿 크기 조정 이벤트
****
| 이벤트 유형 | 심각도 | 이벤트 코드 | 메시지 |
| --- | --- | --- | --- |
| EMR 인스턴스 플릿 크기 조정 | ERROR | 스팟 프로비저닝 제한 시간 | `InstanceFleetID` AZ에서 스팟 용량을 확보하는 동안 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `AvailabilityZone`에 대한 크기 조정 작업을 완료할 수 없었습니다. 이제 요청을 취소하고 추가 스팟 용량을 프로비저닝하려는 시도를 중단합니다. 인스턴스 플릿은 `num`의 스팟 용량을 프로비저닝했습니다. 목표 스팟 용량은 `num`이었습니다. [여기](emr-flexibility.md) 설명서 페이지에서 자세한 내용과 권장 조치를 확인하고 다시 시도합니다. |
| EMR 인스턴스 플릿 크기 조정 | ERROR | 온디맨드 프로비저닝 제한 시간 | `InstanceFleetID` AZ에서 온디맨드 용량을 확보하는 동안 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 `AvailabilityZone`에 대한 크기 조정 작업을 완료할 수 없었습니다. 이제 요청을 취소하고 추가 온디맨드 용량을 프로비저닝하려는 시도를 중단합니다. 인스턴스 플릿은 `num`의 온디맨드 용량을 프로비저닝했습니다. 목표 온디맨드 용량은 `num`이었습니다. [여기](emr-flexibility.md) 설명서 페이지에서 자세한 내용과 권장 조치를 확인하고 다시 시도합니다. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | EC2 프로비저닝 - 인스턴스 용량 부족 | EMR `ClusterId (ClusterName)` 클러스터에서 인스턴스 플릿 `InstanceFleetID`에 대한 크기 조정 작업을 완료할 수 없습니다. `[AvailabilityZone1]` 가용 영역에서 인스턴스 유형 `[Instancetype1, Instancetype2]`에 사용할 Amazon EC2의 스팟 용량이 부족하고 인스턴스 유형 `[Instancetype3, Instancetype4]`에 사용할 온디맨드 용량이 부족하기 때문입니다. 지금까지 인스턴스 플릿은 `num`의 온디맨드 용량을 프로비저닝했지만 목표 온디맨드 용량은 `num`이었습니다. 프로비저닝된 스팟 용량은 `num`이지만 목표 스팟 용량은 `num`이었습니다. 이 이벤트에 대응하는 방법에 대한 자세한 내용은 이 [설명서](emr-EC2_INSUFFICIENT_CAPACITY-error.md)를 참조하세요. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | 스팟 프로비저닝 제한 시간 - 크기 조정 계속 | `AvailabilityZone` AZ에서 `[Instancetype1, Instancetype2]`의 경우 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 ID `InstanceFleetID`에 대해 `time`에 시작된 인스턴스 플릿 크기 조정 작업을 위한 스팟 용량을 아직 프로비저닝하고 있습니다. `time`에 시작된 이전 크기 조정 작업의 경우 제한 시간이 만료되어 Amazon EMR은 요청된 `num`개 인스턴스 중 `num`개를 인스턴스 플릿에 추가한 후 스팟 용량 프로비저닝을 중단했습니다. 자세한 내용은 [여기](emr-flexibility.md) 설명서 페이지를 참조하세요. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | 온디맨드 프로비저닝 제한 시간 - 크기 조정 계속 | `AvailabilityZone` AZ에서 `[Instancetype1, Instancetype2]`의 경우 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 플릿 ID `InstanceFleetID`에 대해 `time`에 시작된 인스턴스 플릿 크기 조정 작업을 위한 온디맨드 용량을 아직 프로비저닝하고 있습니다. `time`에 시작된 이전 크기 조정 작업의 경우 제한 시간이 만료되어 Amazon EMR은 요청된 `num`개 인스턴스 중 `num`개를 인스턴스 플릿에 추가한 후 온디맨드 용량 프로비저닝을 중단했습니다. 자세한 내용은 [여기](emr-flexibility.md) 설명서 페이지를 참조하세요. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | EC2 프로비저닝 - 서브넷의 사용 가능한 주소가 부족함 | 지정된 서브넷 [Subnet1, Subnet2]에 사용 가능한 프라이빗 IP 주소가 부족하여 요청을 이행할 수 없으므로 Amazon EMR 클러스터 ClusterId (ClusterName)에서 인스턴스 플릿 InstanceFleetID에 대한 크기 조정 작업을 완료할 수 없습니다. DescribeSubnets 작업을 사용하여 서브넷에서 사용 가능한 IP 주소 수(사용되지 않은 주소)를 확인합니다. 이 이벤트에 응답하는 방법에 대한 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | EC2 프로비저닝 - vCPU 제한을 초과함 | account (accountId)에서 실행 중인 인스턴스에 할당된 vCPU(가상 처리 단위) 수의 제한에 도달했으므로 Amazon EMR 클러스터 ClusterName에서 인스턴스 플릿 InstanceFleetID의 크기 조정이 지연됩니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | EC2 프로비저닝 - 스팟 인스턴스 수 제한을 초과함 | Amazon EMR 클러스터 ClusterID (ClusterName)에서 인스턴스 플릿 InstanceFleetID의 프로비전이 지연됩니다. account (accountId)에서 시작할 수 있는 스팟 인스턴스 수의 제한에 도달했기 때문입니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| EMR 인스턴스 플릿 크기 조정 | WARNING | EC2 프로비저닝 - 인스턴스 제한을 초과함 | Amazon EMR 클러스터 ClusterID (ClusterName)에서 인스턴스 플릿 InstanceFleetID의 프로비전이 지연됩니다. account (accountId)에서 실행할 수 있는 온디맨드 인스턴스 수의 제한에 도달했기 때문입니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
**참고**
프로비저닝 제한 시간 이벤트는 제한 시간이 만료된 후 Amazon EMR이 플릿에 대한 스팟 또는 온디맨드 용량 프로비저닝을 중지할 때 발생합니다. 이러한 이벤트에 대응하는 방법에 대한 자세한 내용은 [Amazon EMR 클러스터 인스턴스 플릿 크기 조정 제한 시간 이벤트에 대한 대응](emr-events-response-timeout-events.md) 섹션을 참조하세요.
## 인스턴스 그룹 이벤트
****
| 이벤트 유형 | 심각도 | 이벤트 코드 | 메시지 |
| --- | --- | --- | --- |
| `RESIZING`에서 `Running`으로 | INFO | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 크기 조정 작업이 완료되었습니다. 이제 인스턴스 수는 `Num`개입니다. 크기 조정이 `Time`에 시작되었고 완료하는 데 `Num`분이 걸렸습니다. |
| `RUNNING`에서 `RESIZING`으로 | INFO | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 크기 조정이 `Time`에 시작되었습니다. 인스턴스 수가 `Num`개에서 `Num`개로 조정됩니다. |
| SUSPENDED | ERROR | none | Amazon EMR `InstanceGroupID` 클러스터의 인스턴스 그룹 `ClusterId (ClusterName)`가 `Time`에 일시 중단되었습니다. 이유: `ReasonDesc`. |
| RESIZING | WARNING | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 크기 조정 작업이 중단되었습니다. 이유: `ReasonDesc`. |
| EMR 인스턴스 그룹 크기 조정 | WARNING | EC2 프로비저닝 - 인스턴스 용량 부족 | EMR `ClusterId (ClusterName)` 클러스터의 `InstanceGroupID` 인스턴스 그룹에서 `time`에 시작된 크기 조정 작업을 완료할 수 없습니다. `[AvailabilityZone1]` 가용 영역의 `[Instancetype]` 인스턴스 유형에 대해 Amazon EC2의 용량(`Spot/On Demand`)이 부족하기 때문입니다. 지금까지 인스턴스 그룹에서 실행 중인 인스턴스 수는 `num`개이지만 요청된 인스턴스 수는 `num`개였습니다. 이 이벤트에 대응하는 방법에 대한 자세한 내용은 이 [설명서](emr-EC2_INSUFFICIENT_CAPACITY-error.md)를 참조하세요. |
| EMR 인스턴스 그룹 크기 조정 | WARNING | EC2 프로비저닝 - 서브넷의 사용 가능한 주소가 부족함 | 지정된 서브넷 [Subnet1, Subnet2]에 사용 가능한 프라이빗 IP 주소가 부족하여 요청을 이행할 수 없으므로 Amazon EMR 클러스터 ClusterId (ClusterName)에서 인스턴스 그룹 InstanceGroupID에 대한 크기 조정 작업을 완료할 수 없습니다. DescribeSubnets 작업을 사용하여 서브넷에서 사용 가능한 IP 주소 수(사용되지 않은 주소)를 확인합니다. 이 이벤트에 응답하는 방법에 대한 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| EMR 인스턴스 그룹 크기 조정 | WARNING | EC2 프로비저닝 - vCPU 제한을 초과함 | account (accountId)에서 실행 중인 인스턴스에 할당된 vCPU(가상 처리 단위) 수의 제한에 도달했으므로 Amazon EMR 클러스터 ClusterName에서 인스턴스 그룹 InstanceGroupID의 크기 조정이 지연됩니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| EMR 인스턴스 그룹 크기 조정 | WARNING | EC2 프로비저닝 - 스팟 인스턴스 수 제한을 초과함 | Amazon EMR 클러스터 ClusterID (ClusterName)에서 인스턴스 그룹 InstanceGroupID의 프로비전이 지연됩니다. account (accountId)에서 시작할 수 있는 스팟 인스턴스 수의 제한에 도달했기 때문입니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| EMR 인스턴스 그룹 크기 조정 | WARNING | EC2 프로비저닝 - 인스턴스 제한을 초과함 | Amazon EMR 클러스터 ClusterID (ClusterName)에서 인스턴스 그룹 InstanceGroupID의 프로비전이 지연됩니다. account (accountId)에서 실행할 수 있는 온디맨드 인스턴스 수의 제한에 도달했기 때문입니다. 자세한 내용은 [Error codes for the Amazon EC2 API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html)를 참조하세요. |
| `RUNNING`에서 `RESIZING`으로 | INFO | none | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 크기 조정이 `Entity`에 의해 `Time`에 시작되었습니다. |
**참고**
Amazon EMR 버전 5.21.0 이상에서는 클러스터 구성을 재정의할 수 있으며, 실행 중인 클러스터의 각 인스턴스 그룹에 대해 추가 구성 분류를 지정할 수 있습니다. Amazon EMR 콘솔, AWS Command Line Interface (AWS CLI) 또는 AWS SDK를 사용하여이 작업을 수행할 수 있습니다. 자세한 내용은 [실행 중 클러스터의 인스턴스 그룹에 대해 구성 제공](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps-running-cluster.html)을 참조하세요.
다음 테이블에는 재구성 작업의 Amazon EMR 이벤트, 이벤트가 나타내는 상태 또는 상태 변경, 이벤트의 심각도 및 이벤트 메시지가 나와 있습니다.
****
| 상태 또는 상태 변경 | 심각도 | 메시지 |
| --- | --- | --- |
| RUNNING | INFO | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 재구성이 사용자에 의해 `Time`에 시작되었습니다. 요청된 구성의 버전은 `Num`입니다. |
| `RECONFIGURING`에서 `Running`으로 | INFO | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 재구성 작업이 완료되었습니다. 재구성이 `Time`에 시작되었고 완료하는 데 `Num`분이 걸렸습니다. 현재 구성 버전은 `Num`입니다. |
| `RUNNING`에서 `RECONFIGURING`으로 in | INFO | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 재구성이 `Time`에 시작되었습니다. 버전 번호 `Num`에서 버전 번호 `Num`까지 구성 중입니다. |
| RESIZING | INFO | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 구성 버전 `Num`에서의 재구성 작업이 `Time`에 일시적으로 차단됩니다. 인스턴스 그룹이 `State` 상태이기 때문입니다. |
| RECONFIGURING | INFO | Amazon EMR ClusterId (ClusterName) 클러스터의 인스턴스 그룹 InstanceGroupID에 대한 인스턴스 개수(Num개)에서의 크기 조정 작업이 Time에 일시적으로 차단됩니다. 인스턴스 그룹이 State 상태이기 때문입니다. |
| RECONFIGURING | WARNING | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대한 재구성 작업이 `Time`에 실패했으며 실패하기까지 `Num`분이 걸렸습니다. 실패한 구성 버전은 `Num`입니다. |
| RECONFIGURING | INFO | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대해 `Time`에 이전의 성공한 버전 번호(`Num`)로 구성을 되돌립니다. 새 구성 버전은 `Num`입니다. |
| `RECONFIGURING`에서 `Running`으로 | INFO | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대해 `Time`에 이전의 성공한 버전(`Num`)으로 구성을 되돌렸습니다. 새 구성 버전은 `Num`입니다. |
| `RECONFIGURING`에서 `SUSPENDED`으로 | CRITICAL | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 대해 `Time`에 이전의 성공한 버전(`Num`)으로 구성을 되돌리지 못했습니다. |
## 자동 조정 정책 이벤트
****
| 상태 또는 상태 변경 | 심각도 | 메시지 |
| --- | --- | --- |
| PENDING | INFO | `Time`에 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에 Auto Scaling 정책을 추가했습니다. 정책이 연결 대기 중입니다. – 또는 - `Time`에 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에서 Auto Scaling 정책을 업데이트했습니다. 정책이 연결 대기 중입니다. |
| ATTACHED | INFO | `Time`에 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에서 Auto Scaling 정책을 연결했습니다. |
| `DETACHED` | INFO | `Time`에 Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에서 Auto Scaling 정책을 분리했습니다. |
| FAILED | ERROR | Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에서 Auto Scaling 정책을 연결할 수 없으며 `Time`에 실패했습니다. – 또는 - Amazon EMR `ClusterId (ClusterName)` 클러스터의 인스턴스 그룹 `InstanceGroupID`에서 Auto Scaling 정책을 분리할 수 없으며 `Time`에 실패했습니다. |
## 단계 이벤트
****
| 상태 또는 상태 변경 | 심각도 | 메시지 |
| --- | --- | --- |
| PENDING | INFO | `Time`에 `StepID (StepName)` 단계가 Amazon EMR `ClusterId (ClusterName)` 클러스터에 추가되었으며 실행 보류 중입니다. |
| CANCEL\$1PENDING | WARN | `Time`에 Amazon EMR `StepID (StepName)` 클러스터에서 `ClusterId (ClusterName)` 단계가 취소되었으며 취소 보류 중입니다. |
| RUNNING | INFO | Amazon EMR `StepID (StepName)` 클러스터에서 `ClusterId (ClusterName)` 단계 실행이 `Time`에 시작되었습니다. |
| COMPLETED | INFO | Amazon EMR `StepID (StepName)` 클러스터에서 `ClusterId (ClusterName)` 단계 실행이 `Time`에 완료되었습니다. 단계 실행이 `Time`에 시작되었고 완료하는 데 `Num`분이 걸렸습니다. |
| CANCELLED | WARN | `Time`에 Amazon EMR `ClusterId (ClusterName)` 클러스터의 클러스터 단계 `StepID (StepName)`에 대한 취소 요청이 성공했으며 이제 단계가 취소되었습니다. |
| FAILED | ERROR | `Time`에 Amazon EMR `ClusterId (ClusterName)` 클러스터의 `StepID (StepName)` 단계가 실패했습니다. |
## 비정상 노드 교체 이벤트
| 이벤트 유형 | 심각도 | 이벤트 코드 | 메시지 |
| --- | --- | --- | --- |
| Amazon EMR 비정상 노드 교체 | INFO | 비정상 코어 노드 감지됨 | Amazon EMR은 Amazon EMR 클러스터 `clusterID (ClusterName)`에 있는 `InstanceGroup/Fleet`의 코어 인스턴스 `[instanceID (InstanceName)]`가 `UNHEALTHY` 상태임을 식별했습니다. Amazon EMR은 `UNHEALTHY` 인스턴스를 복구하거나 정상적으로 교체하려고 시도합니다. |
| Amazon EMR 비정상 노드 교체 | INFO | 코어 노드 비정상 - 대체 비활성화됨 | Amazon EMR은 Amazon EMR 클러스터 `(clusterID) (ClusterName)`에 있는 `InstanceGroup/Fleet`의 코어 인스턴스 `[instanceID (InstanceName)]`가 `UNHEALTHY` 상태임을 식별했습니다. 클러스터에서 비정상 코어 노드의 정상적 교체 기능을 켜면 복구할 수 없는 경우 Amazon EMR이 `UNHEALTHY` 인스턴스를 정상적으로 교체할 수 있습니다. |
| Amazon EMR 비정상 노드 교체 | WARN | 비정상 코어 노드 교체되지 않음 | Amazon EMR은 **이유 때문에 Amazon EMR 클러스터 `clusterID (ClusterName)`의 `InstanceGroup/Fleet`에서 `UNHEALTHY` 코어 인스턴스 `[instanceID (InstanceName)]`를 교체할 수 없습니다. Amazon EMR이 코어 노드를 교체할 수 없는 이유는 시나리오에 따라 다릅니다. 예를 들어, Amazon EMR이 노드를 삭제할 수 없는 한 가지 이유는 클러스터에 나머지 코어 노드가 없기 때문입니다. |
| Amazon EMR 비정상 노드 교체 | INFO | 비정상 코어 노드 복구됨 | Amazon EMR이 Amazon EMR 클러스터 `clusterID (ClusterName)`의 `InstanceGroup/Fleet`에서 `UNHEALTHY` 상태의 코어 인스턴스 `[instanceID (InstanceName)]`를 복구했습니다. |
비정상 노드 교체에 대한 자세한 내용은 [비정상 노드 교체](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html)를 참조하세요.
## Amazon EMR 콘솔을 사용하여 이벤트 보기
각 클러스터마다 이벤트가 내림차순으로 나열되어 있는 세부 정보 창에서 간단한 이벤트 목록을 확인할 수 있습니다. 또한 리전에 속한 모든 클러스터의 이벤트까지 모두 내림차순으로 표시됩니다.
리전의 모든 클러스터 이벤트가 특정 사용자에게 노출되지 않도록 하려면 `"Effect": "Deny"` 작업 권한을 거부하는 문(`elasticmapreduce:ViewEventsFromAllClustersInConsole`)을 해당 사용자와 연결된 정책에 추가합니다.
**콘솔을 사용하여 리전의 모든 클러스터 이벤트를 보는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **이벤트**를 선택합니다.
**콘솔을 사용하여 특정 클러스터 이벤트를 보는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 클러스터를 선택합니다.
1. 모든 이벤트를 보려면 클러스터 세부 정보 페이지에서 **이벤트** 탭을 선택합니다.
# Amazon EMR에서 CloudWatch 이벤트에 대한 대응
이 섹션에서는 Amazon EMR이 [CloudWatch 이벤트 메시지](emr-manage-cloudwatch-events.md)로 생성하는 실행 가능한 이벤트에 대응할 수 있는 다양한 방법을 설명합니다. 이벤트에 대응할 수 있는 방법으로, 규칙 생성, 경보 설정 및 기타 응답이 있습니다. 다음 섹션에는 절차에 대한 링크와 일반적인 이벤트에 대한 권장 응답이 포함되어 있습니다.
**Topics**
+ [CloudWatch를 사용하여 Amazon EMR 이벤트에 대한 규칙 생성](emr-events-cloudwatch-console.md)
+ [Amazon EMR에서 CloudWatch 지표에 대한 경보 설정](UsingEMR_ViewingMetrics_Alarm.md)
+ [Amazon EMR 클러스터 인스턴스 용량 부족 이벤트에 대한 대응](emr-events-response-insuff-capacity.md)
+ [Amazon EMR 클러스터 인스턴스 플릿 크기 조정 제한 시간 이벤트에 대한 대응](emr-events-response-timeout-events.md)
# CloudWatch를 사용하여 Amazon EMR 이벤트에 대한 규칙 생성
Amazon EMR은 이벤트를 CloudWatch 이벤트 스트림에 자동으로 전송합니다. 지정된 패턴에 따라 이벤트를 일치시키는 규칙을 생성하고 이벤트를 대상으로 라우트하여 조치를 취할 수 있습니다(예: 이메일 알림 전송). 패턴은 이벤트 JSON 객체와 비교됩니다. Amazon EMR 이벤트 세부 정보에 대한 자세한 내용은 *Amazon CloudWatch Events 사용 설명서*에서 [Amazon EMR events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html#emr_event_type)를 참조하세요.
CloudWatch 이벤트 규칙 설정에 대한 자세한 내용은 [Creating a CloudWatch rule that triggers on an event](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)를 참조하세요.
# Amazon EMR에서 CloudWatch 지표에 대한 경보 설정
Amazon EMR은 지표를 Amazon CloudWatch로 전송합니다. 이에 대응하여 CloudWatch를 사용하여 Amazon EMR 지표에 대한 경보를 설정할 수 있습니다. 예를 들어, HDFS 사용률이 80%를 초과할 때마다 이메일을 전송하도록 CloudWatch에서 경보를 구성할 수 있습니다. 자세한 지침은 *Amazon CloudWatch 사용 설명서*에서 [Amazon CloudWatch 경보 생성 또는 편집](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)을 참조하세요.
# Amazon EMR 클러스터 인스턴스 용량 부족 이벤트에 대한 대응
## 개요
Amazon EMR 클러스터는 선택한 가용 영역에서 클러스터 시작 또는 크기 조정 요청을 처리할 용량이 부족한 경우 이벤트 코드 `EC2 provisioning - Insufficient Instance Capacity`를 반환합니다. Amazon EMR에서 용량 부족 예외가 반복적으로 발생하여 클러스터 시작 또는 클러스터 크기 조정 작업에 대한 프로비저닝 요청을 이행할 수 없는 경우, 이 이벤트는 인스턴스 그룹과 인스턴스 플릿 모두에서 주기적으로 발생합니다.
이 페이지에서는 EMR 클러스터에서 이 이벤트가 발생할 때 이 이벤트 유형에 가장 잘 대응하는 방법을 설명합니다.
## 용량 부족 이벤트에 대한 권장 대응
부족한 용량 이벤트에 다음 방법 중 하나를 사용하여 대응하는 것이 좋습니다.
+ 용량이 복구될 때까지 기다립니다. 용량이 자주 바뀌므로 용량 부족 예외는 저절로 복구될 수 있습니다. Amazon EC2 용량이 확보되는 즉시 클러스터의 크기 조정이 시작되거나 완료됩니다.
+ 또는 클러스터를 종료하고, 인스턴스 유형 구성을 수정하며, 업데이트된 클러스터 구성 요청으로 새 클러스터를 생성할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터에 대한 가용 영역 유연성](emr-flexibility.md) 단원을 참조하십시오.
다음 섹션에 설명된 대로 용량 부족 이벤트에 대한 규칙 또는 자동 대응을 설정할 수도 있습니다.
## 용량 부족 이벤트 발생 시 자동 복구
Amazon EMR 이벤트(예: `EC2 provisioning - Insufficient Instance Capacity` 이벤트 코드의 이벤트)에 대한 대응으로 자동화를 구축할 수 있습니다. 예를 들어 다음 AWS Lambda 함수는 온디맨드 인스턴스를 사용하는 인스턴스 그룹으로 EMR 클러스터를 종료한 다음 원래 요청과 다른 인스턴스 유형을 포함하는 인스턴스 그룹으로 새 EMR 클러스터를 생성합니다.
다음과 같은 조건에 따라 자동 프로세스가 트리거됩니다.
+ 프라이머리 또는 코어 노드에서 20분 넘게 용량 부족 이벤트가 생성되었습니다.
+ 클러스터가 **준비** 또는 **대기 중** 상태가 아닙니다. EMR 클러스터 상태에 대한 자세한 내용은 [클러스터 수명 주기 이해](emr-overview.md#emr-overview-cluster-lifecycle) 섹션을 참조하세요.
**참고**
용량 부족 예외에 대한 자동 프로세스를 구축할 때 용량 부족 이벤트는 복구 가능하다는 점을 고려해야 합니다. 용량은 자주 변경되며 Amazon EC2 용량이 확보되는 즉시 클러스터는 크기 조정 또는 시작 작업을 재개합니다.
**Example 용량 부족 이벤트에 대응하는 함수**
```
// Lambda code with Python 3.10 and handler is lambda_function.lambda_handler
// Note: related IAM role requires permission to use Amazon EMR
import json
import boto3
import datetime
from datetime import timezone
INSUFFICIENT_CAPACITY_EXCEPTION_DETAIL_TYPE = "EMR Instance Group Provisioning"
INSUFFICIENT_CAPACITY_EXCEPTION_EVENT_CODE = (
"EC2 provisioning - Insufficient Instance Capacity"
)
ALLOWED_INSTANCE_TYPES_TO_USE = [
"m5.xlarge",
"c5.xlarge",
"m5.4xlarge",
"m5.2xlarge",
"t3.xlarge",
]
CLUSTER_START_ACCEPTABLE_STATES = ["WAITING", "RUNNING"]
CLUSTER_START_SLA = 20
CLIENT = boto3.client("emr", region_name="us-east-1")
# checks if the incoming event is 'EMR Instance Fleet Provisioning' with eventCode 'EC2 provisioning - Insufficient Instance Capacity'
def is_insufficient_capacity_event(event):
if not event["detail"]:
return False
else:
return (
event["detail-type"] == INSUFFICIENT_CAPACITY_EXCEPTION_DETAIL_TYPE
and event["detail"]["eventCode"]
== INSUFFICIENT_CAPACITY_EXCEPTION_EVENT_CODE
)
# checks if the cluster is eligible for termination
def is_cluster_eligible_for_termination(event, describeClusterResponse):
# instanceGroupType could be CORE, MASTER OR TASK
instanceGroupType = event["detail"]["instanceGroupType"]
clusterCreationTime = describeClusterResponse["Cluster"]["Status"]["Timeline"][
"CreationDateTime"
]
clusterState = describeClusterResponse["Cluster"]["Status"]["State"]
now = datetime.datetime.now()
now = now.replace(tzinfo=timezone.utc)
isClusterStartSlaBreached = clusterCreationTime < now - datetime.timedelta(
minutes=CLUSTER_START_SLA
)
# Check if instance group receiving Insufficient capacity exception is CORE or PRIMARY (MASTER),
# and it's been more than 20 minutes since cluster was created but the cluster state and the cluster state is not updated to RUNNING or WAITING
if (
(instanceGroupType == "CORE" or instanceGroupType == "MASTER")
and isClusterStartSlaBreached
and clusterState not in CLUSTER_START_ACCEPTABLE_STATES
):
return True
else:
return False
# Choose item from the list except the exempt value
def choice_excluding(exempt):
for i in ALLOWED_INSTANCE_TYPES_TO_USE:
if i != exempt:
return i
# Create a new cluster by choosing different InstanceType.
def create_cluster(event):
# instanceGroupType cloud be CORE, MASTER OR TASK
instanceGroupType = event["detail"]["instanceGroupType"]
# Following two lines assumes that the customer that created the cluster already knows which instance types they use in original request
instanceTypesFromOriginalRequestMaster = "m5.xlarge"
instanceTypesFromOriginalRequestCore = "m5.xlarge"
# Select new instance types to include in the new createCluster request
instanceTypeForMaster = (
instanceTypesFromOriginalRequestMaster
if instanceGroupType != "MASTER"
else choice_excluding(instanceTypesFromOriginalRequestMaster)
)
instanceTypeForCore = (
instanceTypesFromOriginalRequestCore
if instanceGroupType != "CORE"
else choice_excluding(instanceTypesFromOriginalRequestCore)
)
print("Starting to create cluster...")
instances = {
"InstanceGroups": [
{
"InstanceRole": "MASTER",
"InstanceCount": 1,
"InstanceType": instanceTypeForMaster,
"Market": "ON_DEMAND",
"Name": "Master",
},
{
"InstanceRole": "CORE",
"InstanceCount": 1,
"InstanceType": instanceTypeForCore,
"Market": "ON_DEMAND",
"Name": "Core",
},
]
}
response = CLIENT.run_job_flow(
Name="Test Cluster",
Instances=instances,
VisibleToAllUsers=True,
JobFlowRole="EMR_EC2_DefaultRole",
ServiceRole="EMR_DefaultRole",
ReleaseLabel="emr-6.10.0",
)
return response["JobFlowId"]
# Terminated the cluster using clusterId received in an event
def terminate_cluster(event):
print("Trying to terminate cluster, clusterId: " + event["detail"]["clusterId"])
response = CLIENT.terminate_job_flows(JobFlowIds=[event["detail"]["clusterId"]])
print(f"Terminate cluster response: {response}")
def describe_cluster(event):
response = CLIENT.describe_cluster(ClusterId=event["detail"]["clusterId"])
return response
def lambda_handler(event, context):
if is_insufficient_capacity_event(event):
print(
"Received insufficient capacity event for instanceGroup, clusterId: "
+ event["detail"]["clusterId"]
)
describeClusterResponse = describe_cluster(event)
shouldTerminateCluster = is_cluster_eligible_for_termination(
event, describeClusterResponse
)
if shouldTerminateCluster:
terminate_cluster(event)
clusterId = create_cluster(event)
print("Created a new cluster, clusterId: " + clusterId)
else:
print(
"Cluster is not eligible for termination, clusterId: "
+ event["detail"]["clusterId"]
)
else:
print("Received event is not insufficient capacity event, skipping")
```
# Amazon EMR 클러스터 인스턴스 플릿 크기 조정 제한 시간 이벤트에 대한 대응
## 개요
Amazon EMR 클러스터는 인스턴스 플릿 클러스터의 크기 조정 작업을 실행하는 동안 [이벤트](emr-manage-cloudwatch-events.md#emr-cloudwatch-instance-fleet-resize-events)를 생성합니다. 프로비저닝 제한 시간 이벤트는 제한 시간이 만료된 후 Amazon EMR이 플릿에 대한 스팟 또는 온디맨드 용량 프로비저닝을 중지할 때 발생합니다. 제한 시간은 인스턴스 플릿의 [크기 조정 사양](https://docs.aws.amazon.com/emr/latest/APIReference/API_InstanceFleetResizingSpecifications.html)의 일부로 사용자가 구성할 수 있습니다. 동일한 인스턴스 플릿의 크기가 연속적으로 조정되는 시나리오에서 Amazon EMR은 현재 크기 조정 작업의 제한 시간이 만료되면 `Spot provisioning timeout - continuing resize` 또는 `On-Demand provisioning timeout - continuing resize` 이벤트를 생성합니다. 그런 다음 플릿의 다음 크기 조정 작업을 위한 용량 프로비저닝을 시작합니다.
## 인스턴스 플릿 크기 조정 제한 시간 이벤트에 대한 대응
프로비저닝 제한 시간 이벤트에 대한 다음 방법 중 하나를 사용하여 대응하는 것이 좋습니다.
+ [크기 조정 사양](https://docs.aws.amazon.com/emr/latest/APIReference/API_InstanceFleetResizingSpecifications.html)을 다시 확인하고 크기 조정 작업을 다시 시도합니다. 용량이 자주 변경되므로 Amazon EC2 용량이 확보되면 즉시 클러스터의 크기가 성공적으로 조정됩니다. 더 엄격한 SLA가 필요한 작업의 경우 제한 시간을 더 낮은 값으로 구성하는 것이 좋습니다.
+ 또는 다음 중 하나를 수행할 수 있습니다.
+ [인스턴스 및 가용 영역 유연성에 대한 모범 사례](emr-flexibility.md#emr-flexibility-types)를 기반으로 다양한 인스턴스 유형으로 새 클러스터 시작 또는
+ 온디맨드 용량으로 클러스터 시작
+ 프로비저닝 제한 시간 - 크기 조정 계속 이벤트의 경우 크기 조정 작업이 처리될 때까지 더 기다릴 수 있습니다. Amazon EMR은 구성된 크기 조정 사양에 따라 플릿에 대해 트리거된 크기 조정 작업을 계속 순차적으로 처리합니다.
다음 섹션의 설명에 따라 이 이벤트에 대한 규칙이나 자동 대응을 설정할 수도 있습니다.
## 프로비저닝 제한 시간 이벤트에서 자동 복구
`Spot Provisioning timeout` 이벤트 코드의 Amazon EMR 이벤트에 대한 대응으로 자동화를 구축할 수 있습니다. 예를 들어, 다음 AWS Lambda 함수는 태스크 노드에 대해 스팟 인스턴스를 사용하는 인스턴스 플릿이 있는 EMR 클러스터를 종료한 다음, 원래 요청과 다른 인스턴스 유형을 포함하는 인스턴스 플릿으로 새 EMR 클러스터를 생성합니다. 이 예제에서 태스크 노드에 대해 생성된 `Spot Provisioning timeout` 이벤트는 Lambda 함수의 실행을 트리거합니다.
**Example `Spot Provisioning timeout` 이벤트에 대응하는 예제 함수**
```
// Lambda code with Python 3.10 and handler is lambda_function.lambda_handler
// Note: related IAM role requires permission to use Amazon EMR
import json
import boto3
import datetime
from datetime import timezone
SPOT_PROVISIONING_TIMEOUT_EXCEPTION_DETAIL_TYPE = "EMR Instance Fleet Resize"
SPOT_PROVISIONING_TIMEOUT_EXCEPTION_EVENT_CODE = (
"Spot Provisioning timeout"
)
CLIENT = boto3.client("emr", region_name="us-east-1")
# checks if the incoming event is 'EMR Instance Fleet Resize' with eventCode 'Spot provisioning timeout'
def is_spot_provisioning_timeout_event(event):
if not event["detail"]:
return False
else:
return (
event["detail-type"] == SPOT_PROVISIONING_TIMEOUT_EXCEPTION_DETAIL_TYPE
and event["detail"]["eventCode"]
== SPOT_PROVISIONING_TIMEOUT_EXCEPTION_EVENT_CODE
)
# checks if the cluster is eligible for termination
def is_cluster_eligible_for_termination(event, describeClusterResponse):
# instanceFleetType could be CORE, MASTER OR TASK
instanceFleetType = event["detail"]["instanceFleetType"]
# Check if instance fleet receiving Spot provisioning timeout event is TASK
if (instanceFleetType == "TASK"):
return True
else:
return False
# create a new cluster by choosing different InstanceType.
def create_cluster(event):
# instanceFleetType cloud be CORE, MASTER OR TASK
instanceFleetType = event["detail"]["instanceFleetType"]
# the following two lines assumes that the customer that created the cluster already knows which instance types they use in original request
instanceTypesFromOriginalRequestMaster = "m5.xlarge"
instanceTypesFromOriginalRequestCore = "m5.xlarge"
# select new instance types to include in the new createCluster request
instanceTypesForTask = [
"m5.xlarge",
"m5.2xlarge",
"m5.4xlarge",
"m5.8xlarge",
"m5.12xlarge"
]
print("Starting to create cluster...")
instances = {
"InstanceFleets": [
{
"InstanceFleetType":"MASTER",
"TargetOnDemandCapacity":1,
"TargetSpotCapacity":0,
"InstanceTypeConfigs":[
{
'InstanceType': instanceTypesFromOriginalRequestMaster,
"WeightedCapacity":1,
}
]
},
{
"InstanceFleetType":"CORE",
"TargetOnDemandCapacity":1,
"TargetSpotCapacity":0,
"InstanceTypeConfigs":[
{
'InstanceType': instanceTypesFromOriginalRequestCore,
"WeightedCapacity":1,
}
]
},
{
"InstanceFleetType":"TASK",
"TargetOnDemandCapacity":0,
"TargetSpotCapacity":100,
"LaunchSpecifications":{},
"InstanceTypeConfigs":[
{
'InstanceType': instanceTypesForTask[0],
"WeightedCapacity":1,
},
{
'InstanceType': instanceTypesForTask[1],
"WeightedCapacity":2,
},
{
'InstanceType': instanceTypesForTask[2],
"WeightedCapacity":4,
},
{
'InstanceType': instanceTypesForTask[3],
"WeightedCapacity":8,
},
{
'InstanceType': instanceTypesForTask[4],
"WeightedCapacity":12,
}
],
"ResizeSpecifications": {
"SpotResizeSpecification": {
"TimeoutDurationMinutes": 30
}
}
}
]
}
response = CLIENT.run_job_flow(
Name="Test Cluster",
Instances=instances,
VisibleToAllUsers=True,
JobFlowRole="EMR_EC2_DefaultRole",
ServiceRole="EMR_DefaultRole",
ReleaseLabel="emr-6.10.0",
)
return response["JobFlowId"]
# terminated the cluster using clusterId received in an event
def terminate_cluster(event):
print("Trying to terminate cluster, clusterId: " + event["detail"]["clusterId"])
response = CLIENT.terminate_job_flows(JobFlowIds=[event["detail"]["clusterId"]])
print(f"Terminate cluster response: {response}")
def describe_cluster(event):
response = CLIENT.describe_cluster(ClusterId=event["detail"]["clusterId"])
return response
def lambda_handler(event, context):
if is_spot_provisioning_timeout_event(event):
print(
"Received spot provisioning timeout event for instanceFleet, clusterId: "
+ event["detail"]["clusterId"]
)
describeClusterResponse = describe_cluster(event)
shouldTerminateCluster = is_cluster_eligible_for_termination(
event, describeClusterResponse
)
if shouldTerminateCluster:
terminate_cluster(event)
clusterId = create_cluster(event)
print("Created a new cluster, clusterId: " + clusterId)
else:
print(
"Cluster is not eligible for termination, clusterId: "
+ event["detail"]["clusterId"]
)
else:
print("Received event is not spot provisioning timeout event, skipping")
```
# Amazon EMR에서 Ganglia를 사용하여 클러스터 애플리케이션 지표 보기
Ganglia는 Amazon EMR 릴리스 4.2\$16.15에서 사용할 수 있습니다. Ganglia는 성능에 미치는 영향을 최소화하면서 클러스터 및 그리드를 모니터링하도록 설계된 확장 가능한 분산 시스템인 오픈 소스 프로젝트입니다. 클러스터에서 Ganglia를 활성화하면 보고서를 생성하고 전체 클러스터의 성능을 볼 수 있으며 개별 노드 인스턴스의 성능을 검사할 수 있습니다. 또한 Ganglia는 Hadoop 및 Spark 지표를 수집하고 시각화하도록 구성되어 있습니다. 자세한 내용은 *Amazon EMR 릴리스 안내서*에서 [Ganglia](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-ganglia.html)를 참조하세요.
# 를 사용하여 AWS EMR API 호출 로깅 AWS CloudTrail
AWS EMR은 사용자[AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html), 역할 또는가 수행한 작업에 대한 레코드를 제공하는 서비스인와 통합됩니다 AWS 서비스. CloudTrail은 AWS EMR에 대한 모든 API 호출을 이벤트로 캡처합니다. 캡처되는 호출에는 AWS EMR 콘솔의 호출과 AWS EMR API 작업에 대한 코드 호출이 포함됩니다. CloudTrail에서 수집한 정보를 사용하여 AWS EMR에 수행된 요청, 요청이 수행된 IP 주소, 요청이 수행된 시간 및 추가 세부 정보를 확인할 수 있습니다.
모든 이벤트 또는 로그 항목에는 요청을 생성했던 사용자에 관한 정보가 포함됩니다. 자격 증명을 이용하면 다음을 쉽게 판단할 수 있습니다.
+ 요청을 루트 사용자로 했는지 사용자 보안 인증으로 했는지 여부.
+ IAM Identity Center 사용자를 대신하여 요청이 이루어졌는지 여부입니다.
+ 역할 또는 페더레이션 사용자의 임시 자격 증명을 사용하여 요청이 생성되었는지 여부.
+ 다른 AWS 서비스에서 요청했는지 여부
CloudTrail은 계정을 생성할 AWS 계정 때에서 활성화되며 CloudTrail **이벤트 기록에** 자동으로 액세스할 수 있습니다. CloudTrail **이벤트 기록**은 지난 90일 간 AWS 리전의 관리 이벤트에 대해 보기, 검색 및 다운로드가 가능하고, 수정이 불가능한 레코드를 제공합니다. 자세한 설명은 *AWS CloudTrail 사용 설명서*의 [CloudTrail 이벤트 기록 작업](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html)을 참조하세요. **이벤트 기록** 보기는 CloudTrail 요금이 부과되지 않습니다.
AWS 계정 지난 90일 동안 이벤트를 지속적으로 기록하려면 추적 또는 [CloudTrail Lake](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) 이벤트 데이터 스토어를 생성합니다.
**CloudTrail 추적**
CloudTrail은 *추적*을 사용하여 Amazon S3 버킷으로 로그 파일을 전송할 수 있습니다. 를 사용하여 생성된 모든 추적 AWS Management Console 은 다중 리전입니다. AWS CLI를 사용하여 단일 리전 또는 다중 리전 추적을 생성할 수 있습니다. 계정의 모든 AWS 리전 에서 활동을 캡처하므로 다중 리전 추적을 생성하는 것이 좋습니다. 단일 리전 추적을 생성하는 경우 추적의 AWS 리전에 로깅된 이벤트만 볼 수 있습니다. 추적에 대한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [AWS 계정에 대한 추적 생성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html) 및 [조직에 대한 추적 생성](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/creating-trail-organization.html)을 참조하세요.
CloudTrail에서 추적을 생성하여 진행 중인 관리 이벤트의 사본 하나를 Amazon S3 버킷으로 무료로 전송할 수는 있지만, Amazon S3 스토리지 요금이 부과됩니다. CloudTrail 요금에 관한 자세한 내용은 [AWS CloudTrail 요금](https://aws.amazon.com/cloudtrail/pricing/)을 참조하세요. Amazon S3 요금에 관한 자세한 내용은 [Amazon S3 요금](https://aws.amazon.com/s3/pricing/)을 참조하세요.
**CloudTrail Lake 이벤트 데이터 스토어**
*CloudTrail Lake*를 사용하면 이벤트에 대해 SQL 기반 쿼리를 실행할 수 있습니다. CloudTrail Lake는 행 기반 JSON 형식의 기존 이벤트를 [ Apache ORC](https://orc.apache.org/) 형식으로 변환합니다. ORC는 빠른 데이터 검색에 최적화된 열 기반 스토리지 형식입니다. 이벤트는 *이벤트 데이터 스토어*로 집계되며, 이벤트 데이터 스토어는 [고급 이벤트 선택기](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-concepts.html#adv-event-selectors)를 적용하여 선택한 기준을 기반으로 하는 변경 불가능한 이벤트 컬렉션입니다. 이벤트 데이터 스토어에 적용하는 선택기는 어떤 이벤트가 지속되고 쿼리에 사용 가능한지를 제어합니다. CloudTrail Lake에 대한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [AWS CloudTrail Lake 작업을](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake.html) 참조하세요.
CloudTrail Lake 이벤트 데이터 스토어 및 쿼리에는 비용이 발생합니다. 이벤트 데이터 스토어를 생성할 때 이벤트 데이터 스토어에 사용할 [요금 옵션](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-lake-manage-costs.html#cloudtrail-lake-manage-costs-pricing-option)을 선택합니다. 요금 옵션에 따라 이벤트 모으기 및 저장 비용과 이벤트 데이터 스토어의 기본 및 최대 보존 기간이 결정됩니다. CloudTrail 요금에 관한 자세한 내용은 [AWS CloudTrail 요금](https://aws.amazon.com/cloudtrail/pricing/)을 참조하세요.
## AWS CloudTrail의 EMR 데이터 이벤트
[데이터 이벤트](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events)는 리소스 기반 또는 리소스에서 수행된 리소스 작업에 대한 정보를 제공합니다(예: Amazon S3 객체 읽기 또는 쓰기). 이를 데이터 플레인 작업이라고도 합니다. 데이터 이벤트는 흔히 대량 활동입니다. 기본적으로 CloudTrail은 데이터 이벤트를 로깅하지 않습니다. CloudTrail **이벤트 기록**은 데이터 이벤트를 기록하지 않습니다.
데이터 이벤트에는 추가 요금이 적용됩니다. CloudTrail 요금에 관한 자세한 내용은 [AWS CloudTrail 요금](https://aws.amazon.com/cloudtrail/pricing/)을 참조하세요.
CloudTrail 콘솔 AWS CLI또는 CloudTrail API 작업을 사용하여 AWS EMR 리소스 유형에 대한 데이터 이벤트를 로깅할 수 있습니다. 데이터 이벤트를 로깅하는 방법에 관한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [AWS Management Console을 사용한 데이터 이벤트 로깅](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#logging-data-events-console) 및 [AWS Command Line Interface를 사용한 이벤트 데이터 로깅](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-data-events-with-cloudtrail.html#creating-data-event-selectors-with-the-AWS-CLI)을 참조하세요.
다음 표에는 데이터 이벤트를 로깅할 수 있는 AWS EMR 리소스 유형이 나열되어 있습니다. **데이터 이벤트 유형(콘솔)** 열에는 CloudTrail 콘솔의 **데이터 이벤트 유형** 목록에서 선택할 값이 표시됩니다. **resources.type 값** 열에는 AWS CLI 또는 CloudTrail APIs를 사용하여 고급 이벤트 선택기를 구성할 때 지정하는 `resources.type` 값이 표시됩니다. **CloudTrail에 로깅되는 데이터 API** 열에는 리소스 유형에 대해 CloudTrail에 로깅된 API 직접 호출이 표시됩니다.
이러한 API 작업에 대한 자세한 내용은 [Amazon EMR WAL(EMRWAL) CLI 참조](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emrwalcli-ref.html)를 참조하세요. Amazon EMR은 직접 호출하지 않는 HBase 시스템 작업인 일부 데이터 API 작업을 CloudTrail에 로깅합니다. 이러한 작업은 EMRWAL CLI 참조에 없습니다.
| 데이터 이벤트 유형(콘솔) | resources.type 값 | CloudTrail에 로깅되는 데이터 API |
| --- | --- | --- |
| Amazon EMR 미리 쓰기 로그 워크스페이스 | AWS::EMRWAL::Workspace | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/logging-using-cloudtrail.html) |
`eventName`, `readOnly` 및 `resources.ARN` 필드를 필터링하여 중요한 이벤트만 로깅하도록 고급 이벤트 선택기를 구성할 수 있습니다. 이러한 필드에 관한 자세한 내용은 *AWS CloudTrail API 참조*의 [https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html](https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_AdvancedFieldSelector.html) 섹션을 참조하세요.
## AWS CloudTrail의 EMR 관리 이벤트
[관리 이벤트](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/logging-management-events-with-cloudtrail.html#logging-management-events)는의 리소스에서 수행되는 관리 작업에 대한 정보를 제공합니다 AWS 계정. 이를 컨트롤 플레인 작업이라고도 합니다. 기본적으로 CloudTrail은 관리 이벤트를 로깅합니다.
AWS EMR은 모든 AWS EMR 컨트롤 플레인 작업을 관리 이벤트로 로깅합니다. AWS EMR이 CloudTrail에 로깅하는 AWS EMR 컨트롤 플레인 작업 목록은 [AWS EMR API 참조](https://docs.aws.amazon.com/emr/latest/APIReference/Welcome.html)를 참조하세요.
## AWS EMR 이벤트 예제
이벤트는 모든 소스로부터의 단일 요청을 나타내며 요청된 API 작업, 작업 날짜와 시간, 요청 파라미터 등에 관한 정보가 들어 있습니다. CloudTrail 로그 파일은 퍼블릭 API 직접 호출의 주문 스택 추적이 아니므로 이벤트가 특정 순서로 표시되지 않습니다.
다음 예제는 **RunJobFlow** 작업을 설명하는 CloudTrail 로그 항목을 보여줍니다.
```
{
"Records": [
{
"eventVersion":"1.01",
"userIdentity":{
"type":"IAMUser",
"principalId":"EX_PRINCIPAL_ID",
"arn":"arn:aws:iam::123456789012:user/temporary-user-xx-7M",
"accountId":"123456789012",
"userName":"temporary-user-xx-7M"
},
"eventTime":"2018-03-31T17:59:21Z",
"eventSource":"elasticmapreduce.amazonaws.com",
"eventName":"RunJobFlow",
"awsRegion":"us-west-2",
"sourceIPAddress":"192.0.2.1",
"userAgent":"aws-sdk-java/unknown-version Linux/xx Java_HotSpot(TM)_64-Bit_Server_VM/xx",
"requestParameters":{
"tags":[
{
"value":"prod",
"key":"domain"
},
{
"value":"us-west-2",
"key":"realm"
},
{
"value":"VERIFICATION",
"key":"executionType"
}
],
"instances":{
"slaveInstanceType":"m5.xlarge",
"ec2KeyName":"emr-integtest",
"instanceCount":1,
"masterInstanceType":"m5.xlarge",
"keepJobFlowAliveWhenNoSteps":true,
"terminationProtected":false
},
"visibleToAllUsers":false,
"name":"MyCluster",
"ReleaseLabel":"emr-5.16.0"
},
"responseElements":{
"jobFlowId":"j-2WDJCGEG4E6AJ"
},
"requestID":"2f482daf-b8fe-11e3-89e7-75a3d0e071c5",
"eventID":"b348a38d-f744-4097-8b2a-e68c9b424698"
},
...additional entries
]
}
```
CloudTrail 레코드 콘텐츠에 관한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [CloudTrail 레코드 콘텐츠](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-record-contents.html)를 참조하세요.
# EMR 관찰성 모범 사례
EMR 관찰성에는 AWS EMR 클러스터에 대한 포괄적인 모니터링 및 관리 접근 방식이 포함됩니다. 기반은 Amazon CloudWatch를 기본 모니터링 서비스로 사용하며, EMR Studio와 향상된 가시성을 위해 Prometheus 및 Grafana와 같은 타사 도구로 보완됩니다. 이 문서에서는 클러스터 관찰성의 특정 측면을 살펴봅니다.
1. *[Spark 관찰성](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Applications/Spark/observability.md)*(GitHub) - Spark 사용자 인터페이스와 관련하여 Amazon EMR에는 세 가지 옵션이 있습니다.
1. *[Spark 문제 해결](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Applications/Spark/troubleshooting.md)*(GitHub) - 오류를 해결합니다.
1. *[EMR 클러스터 모니터링](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Observability/best_practices/)*(GitHub) - 클러스터 성능을 모니터링합니다.
1. *[EMR 문제 해결](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Troubleshooting/Troubleshooting%20EMR.md)*(GitHub) - 일반적인 EMR 클러스터 문제를 식별, 진단 및 해결합니다.
1. *[비용 최적화](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Cost%20Optimizations/best_practices.md)*(GitHub) -이 섹션에서는 비용 효율적인 워크로드를 실행하는 모범 사례를 간략하게 설명합니다.
## Apache Spark 애플리케이션을 위한 성능 최적화 도구
1. [AWS EMR Advisor](https://github.com/aws-samples/aws-emr-advisor) 도구는 Spark 이벤트 로그를 분석하여 EMR 클러스터 구성을 최적화하고 성능을 향상하며 비용을 절감하기 위한 맞춤형 권장 사항을 제공합니다. 기록 데이터를 활용하면 이상적인 실행기 크기와 인프라 설정을 제안하여 리소스 사용률을 높이고 전체 클러스터 성능을 개선할 수 있습니다.
1. [Amazon CodeGuru Profiler](https://github.com/amzn/amazon-codeguru-profiler-for-spark) 도구를 사용하면 개발자가 런타임 데이터를 수집하고 분석하여 Spark 애플리케이션의 성능 병목 현상과 비효율성을 식별할 수 있습니다. 이 도구는 최소한의 설정이 필요한 기존 Spark 애플리케이션과 원활하게 통합되며 AWS 콘솔을 통해 CPU 사용량, 메모리 패턴 및 성능 핫스팟에 대한 자세한 인사이트를 제공합니다.