기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EMR 클러스터 조정을 사용하여 워크로드 변경에 맞게 조정
다양한 요구 사항이 있는 워크로드에 대한 대응으로 Amazon EMR 클러스터에서 사용 가능한 Amazon EC2 인스턴스 수를 자동 또는 수동으로 조정할 수 있습니다. 자동 조정을 수행할 경우 두 가지 옵션을 사용할 수 있습니다. Amazon EMR Managed Scaling을 활성화하거나 사용자 지정 조정 정책을 생성할 수 있습니다. 다음 표에 두 옵션의 차이점이 나와 있습니다.
| | Amazon EMR Managed Scaling | 사용자 지정 자동 조정 |
| --- | --- | --- |
| 조정 정책 및 규칙 | 정책이 필요하지 않습니다. Amazon EMR은 클러스터 지표를 지속적으로 평가하고 최적화된 조정 결정을 내림으로써 자동 조정 활동을 관리합니다. | 조정 활동, 평가 기간, 휴지 기간 등을 트리거하는 특정 조건과 같은 자동 조정 정책 및 규칙을 정의하고 관리해야 합니다. |
| 지원되는 Amazon EMR 릴리스 | Amazon EMR 버전 5.30.0 이상(Amazon EMR 버전 6.0.0 제외) | Amazon EMR 버전 4.0.0 이상 |
| 지원되는 클러스터 구성 | 인스턴스 그룹 또는 인스턴스 플릿 | 인스턴스 그룹 전용 |
| 조정 제한 구성 | 조정 제한은 전체 클러스터에 대해 구성됩니다. | 조정 제한은 각 인스턴스 그룹에 대해서만 구성할 수 있습니다. |
| 지표 평가 빈도 | 매 5\$110초 지표를 더 자주 평가하면 Amazon EMR에서 보다 정확한 조정 결정을 내릴 수 있습니다. | 평가 기간은 5분 증분으로만 정의할 수 있습니다. |
| 지원되는 애플리케이션 | Spark, Hadoop, Hive, Flink 등과 같은 YARN 애플리케이션만 지원됩니다. Amazon EMR Managed Scaling은 Presto나 HBase와 같이 YARN을 기반으로 하는 애플리케이션만 지원합니다. | 자동 조정 규칙을 정의할 때, 지원되는 애플리케이션을 선택할 수 있습니다. |
## 고려 사항
+ Amazon EMR 클러스터는 항상 하나 또는 세 개의 프라이머리 노드로 구성됩니다. 클러스터를 처음 구성한 후에는 코어 및 태스크 노드만 확장할 수 있습니다. 클러스터의 프라이머리 노드 수는 조정할 수 없습니다.
+ 인스턴스 그룹의 경우 재구성 작업과 크기 조정 작업이 동시에 발생하지 않고 연속적으로 발생합니다. 인스턴스 그룹 크기 조정 중에 재구성을 시작하면 인스턴스 그룹이 진행 중인 크기 조정을 완료한 후 재구성이 시작됩니다. 반대로 인스턴스 그룹이 재구성을 사용하는 동안 크기 조정 작업을 시작하면 재구성이 완료되면 크기 조정이 시작됩니다.
# Amazon EMR에서 Managed Scaling 사용
**중요**
관리형 조정에는 최신 Amazon EMR 릴리스(Amazon EMR 7.12.0)를 사용하는 것이 좋습니다. 일부 초기 릴리스에서는 애플리케이션 장애가 간헐적으로 발생하거나 규모 조정이 지연될 수 있습니다. Amazon EMR은 5.x 릴리스 5.30.2, 5.31.1, 5.32.1, 5.33.1 이상 버전과 6.x 릴리스 6.1.1, 6.2.1, 6.3.1 이상에서 이 문제를 해결했습니다. 리전 및 릴리스 가용성에 대한 자세한 내용은 [Managed Scaling 가용성](#emr-managed-scaling-availability) 섹션을 참조하세요.
## 개요
Amazon EMR 버전 5.30.0 이상(Amazon EMR 6.0.0 제외)에서는 Amazon EMR Managed Scaling을 활성화할 수 있습니다. Managed Scaling을 활성화하면 워크로드에 따라 클러스터에서 인스턴스 또는 유닛 수를 자동으로 늘리거나 줄일 수 있습니다. Amazon EMR은 클러스터 지표를 지속적으로 평가하여 비용과 속도 측면에서 클러스터를 최적화하는 조정 결정을 내립니다. Managed Scaling은 인스턴스 그룹 또는 인스턴스 플릿으로 구성된 클러스터에 사용할 수 있습니다.
## Managed Scaling 가용성
+ 다음에서 AWS 리전 Amazon EMR 관리형 조정은 Amazon EMR 6.14.0 이상에서 사용할 수 있습니다.
+ 아시아 태평양(타이베이)(ap-east-2)
+ 아시아 태평양(멜버른)(ap-southeast-4)
+ 아시아 태평양(말레이시아)(ap-southeast-5)
+ 아시아 태평양(뉴질랜드)(ap-southeast-6)
+ 아시아 태평양(태국)(ap-southeast-7)
+ 캐나다 서부(캘거리)(ca-west-1)
+ 유럽(스페인)(eu-south-2)
+ 멕시코(중부)(mx-central-1)
+ 다음에서 AWS 리전 Amazon EMR 관리형 조정은 Amazon EMR 5.30.0 및 6.1.0 이상에서 사용할 수 있습니다.
+ 미국 동부(버지니아 북부)(us-east-1)
+ 미국 동부(오하이오)(us-east-2)
+ 미국 서부(오리건)(us-west-2)
+ 미국 서부(캘리포니아 북부)(us-west-1)
+ 아프리카(케이프타운)(af-south-1)
+ 아시아 태평양(홍콩)(ap-east-1)
+ 아시아 태평양(뭄바이)(ap-south-1)
+ 아시아 태평양(하이데라바드)(ap-south-2)
+ 아시아 태평양(서울)(ap-northeast-2)
+ 아시아 태평양(싱가포르)(ap-southeast-1)
+ 아시아 태평양(시드니)(ap-southeast-2)
+ 아시아 태평양(자카르타) (ap-southeast-3)
+ 아시아 태평양(도쿄)(ap-northeast-1)
+ 아시아 태평양(오사카) (ap-northeast-3)
+ 캐나다(중부)(ca-central-1)
+ 남아메리카(상파울루)(sa-east-1)
+ 유럽(프랑크푸르트)(eu-central-1)
+ 유럽(취리히)(eu-central-2)
+ 유럽(아일랜드)(eu-west-1)
+ 유럽(런던) (eu-west-2)
+ 유럽(밀라노) (eu-south-1)
+ 유럽(파리) (eu-west-3)
+ 유럽(스톡홀름)(eu-north-1)
+ 이스라엘(텔아비브)(il-central-1)
+ 중동(UAE)(me-central-1)
+ 중국(베이징)(cn-north-1)
+ 중국(닝샤)(cn-northwest-1)
+ AWS GovCloud(미국 동부)(us-gov-east-1)
+ AWS GovCloud(미국 서부)(us-gov-west-1)
+ Amazon EMR Managed Scaling은 Spark, Hadoop, Hive, Flink 등과 같은 YARN 애플리케이션에서만 작동합니다. 현재, Presto 및 HBase와 같은 YARN 기반이 아닌 애플리케이션에서는 지원되지 않습니다.
## Managed Scaling 파라미터
Managed Scaling을 위해 다음 파라미터를 구성해야 합니다. 제한은 코어 및 작업 노드에만 적용됩니다. 초기 구성 후에는 프라이머리 노드를 조정할 수 없습니다.
+ **최소**(`MinimumCapacityUnits`) - 클러스터에서 허용되는 EC2 용량의 하한. 인스턴스 그룹의 가상 중앙 처리 장치(vCPU) 코어 또는 인스턴스를 통해 측정됩니다. 인스턴스 플릿에 대한 장치를 통해 측정됩니다.
+ **최대**(`MaximumCapacityUnits`) - 클러스터에서 허용되는 EC2 용량의 상한. 인스턴스 그룹의 가상 중앙 처리 장치(vCPU) 코어 또는 인스턴스를 통해 측정됩니다. 인스턴스 플릿에 대한 장치를 통해 측정됩니다.
+ **온디맨드 제한**(`MaximumOnDemandCapacityUnits`)(선택 사항) - 클러스터의 온디맨드 시장 유형에 허용되는 EC2 용량의 상한. 이 파라미터를 지정하지 않으면 `MaximumCapacityUnits` 값이 기본값으로 사용됩니다.
+ 이 파라미터는 온디맨드 인스턴스와 스팟 인스턴스 간에 용량 할당을 분할하는 데 사용됩니다. 예를 들어, 최소 파라미터를 인스턴스 2개로, 최대 파라미터를 100개 인스턴스로, 온디맨드 제한을 인스턴스 10개로 설정하는 경우 Amazon EMR Managed Scaling은 최대 10개의 온디맨드 인스턴스로 스케일 업하고 나머지 용량을 스팟 인스턴스에 할당합니다. 자세한 내용은 [노드 할당 시나리오](managed-scaling-allocation-strategy.md#node-allocation-scenarios) 단원을 참조하십시오.
+ **최대 코어 노드**(`MaximumCoreCapacityUnits`)(선택 사항) - 클러스터의 코어 노드 유형에 허용되는 EC2 용량의 상한. 이 파라미터를 지정하지 않으면 `MaximumCapacityUnits` 값이 기본값으로 사용됩니다.
+ 이 파라미터는 코어 노드와 태스크 노드 간에 용량 할당을 분할하는 데 사용됩니다. 예를 들어, 최소 파라미터를 인스턴스 2개, 최대 인스턴스 100개, 최대 코어 노드를 인스턴스 17개로 설정하는 경우 Amazon EMR Managed Scaling은 최대 17개의 코어 노드를 스케일 업하고 나머지 83개 인스턴스를 태스크 노드에 할당합니다. 자세한 내용은 [노드 할당 시나리오](managed-scaling-allocation-strategy.md#node-allocation-scenarios) 단원을 참조하십시오.
Managed Scaling 파라미터에 대한 자세한 내용은 [https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html](https://docs.aws.amazon.com/emr/latest/APIReference/API_ComputeLimits.html) 섹션을 참조하세요.
## Amazon EMR Managed Scaling에 대한 고려 사항
+ Managed Scaling은 제한된 릴리스 AWS 리전 와 Amazon EMR 릴리스에서 지원됩니다. 자세한 내용은 [Managed Scaling 가용성](#emr-managed-scaling-availability) 단원을 참조하십시오.
+ Amazon EMR Managed Scaling에 필요한 파라미터를 구성해야 합니다. 자세한 내용은 [Managed Scaling 파라미터](#emr-managed-scaling-parameters) 단원을 참조하십시오.
+ Managed Scaling을 사용하려면 metrics-collector 프로세스를 API Gateway에서 Managed Scaling에 대한 퍼블릭 API 엔드포인트에 연결할 수 있어야 합니다. 에서 프라이빗 DNS 이름을 사용하는 경우 Amazon Virtual Private Cloud관리형 조정이 제대로 작동하지 않습니다. Managed Scaling이 올바르게 작동하려면 다음 작업 중 하나를 수행하는 것이 좋습니다.
+ Amazon VPC에서 API Gateway 인터페이스 VPC 엔드포인트를 제거합니다.
+ [VPC에서 API Gateway API에 연결할 때 HTTP 403 Forbidden 오류가 발생하는 이유는 무엇입니까?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-vpc-connections/)의 지침에 따라 프라이빗 DNS 이름 설정을 비활성화합니다.
+ 대신 프라이빗 서브넷에서 인스턴스를 시작합니다. 자세한 내용은 [프라이빗 서브넷](emr-clusters-in-a-vpc.md#emr-vpc-private-subnet)의 주제를 참조하세요.
+ 스케일 다운 중에 YARN 작업이 간헐적으로 느려지고 YARN Resource Manager 로그에 해당 기간 대부분의 노드가 거부 목록에 추가된 것으로 표시되는 경우 서비스 해제 제한 시간 임계값을 조정할 수 있습니다.
작업 처리를 계속하기 위해 보류 중인 다른 컨테이너가 노드를 사용할 수 있도록 하려면 `spark.blacklist.decommissioning.timeout`을 1시간에서 1분으로 줄입니다.
또한 가장 긴 'Spark 작업'이 여전히 노드에서 실행 중인 동안 Amazon EMR이 노드를 강제로 종료하지 않도록 하려면 `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs`를 더 큰 값으로 설정해야 합니다. 현재 기본값은 60분입니다. 즉, 노드가 서비스 해제 상태가 되면 60분 후에 YARN에서 컨테이너를 강제 종료합니다.
다음 예제의 YARN Resource Manager 로그 줄에서는 서비스 해제 상태에 추가된 노드를 보여줍니다.
```
2021-10-20 15:55:26,994 INFO org.apache.hadoop.YARN.server.resourcemanager.DefaultAMSProcessor (IPC Server handler 37 on default port 8030): blacklist are updated in Scheduler.blacklistAdditions: [ip-10-10-27-207.us-west-2.compute.internal, ip-10-10-29-216.us-west-2.compute.internal, ip-10-10-31-13.us-west-2.compute.internal, ... , ip-10-10-30-77.us-west-2.compute.internal], blacklistRemovals: []
```
[노드를 서비스 해제하는 동안 Amazon EMR이 YARN 거부 목록과 통합되는 방법에 대한 세부 정보](https://aws.amazon.com/blogs/big-data/spark-enhancements-for-elasticity-and-resiliency-on-amazon-emr/), [Amazon EMR에서 노드를 거부 목록에 추가할 수 있는 경우](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-troubleshoot-error-resource-3.html), [Spark 노드 서비스 해제 동작을 구성하는 방법](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-configure.html#spark-decommissioning)을 참조하세요.
+ Spark 워크로드의 경우, Spark 속성 **spark.dynamicAllocation.enabled**를 `FALSE`로 변경하여 Spark DRA(동적 리소스 할당자)를 비활성화하면 클러스터가 워크로드에 필요한 것보다 더 많이(최대 컴퓨팅까지) 확장될 수 있는 관리형 확장 문제가 발생할 수 있습니다. 이러한 워크로드에 관리형 확장을 사용하는 경우 이 속성의 기본 상태인 Spark DRA를 활성화된 상태로 유지하는 것이 좋습니다.
+ EBS 볼륨을 과도하게 사용하면 Managed Scaling 문제가 발생할 수 있습니다. EBS 볼륨 사용률을 90% 미만으로 유지하는 것이 좋습니다. 자세한 내용은 [Amazon EMR에서 인스턴스 스토리지 옵션 및 동작](emr-plan-storage.md) 단원을 참조하십시오.
+ Amazon CloudWatch 지표는 Amazon EMR Managed Scaling을 작동하는 데 매우 중요한 역할을 합니다. Amazon CloudWatch 지표를 자세히 모니터링하여 데이터가 누락되지 않았는지 확인하는 것이 좋습니다. 누락된 지표를 감지하도록 CloudWatch 경보를 구성하는 방법에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.
+ Presto가 설치되지 않은 5.30.0 및 5.30.1 클러스터에서 Managed Scaling을 수행하면 애플리케이션 장애가 발생하거나 균일한 인스턴스 그룹 또는 인스턴스 플릿이 `ARRESTED` 상태로 유지될 수 있습니다. 특히 스케일 다운 작업 이후 바로 스케일 업 작업이 수행되는 경우가 이에 해당합니다.
해결 방법으로 작업에 Presto가 필요하지 않더라도 Amazon EMR 릴리스 5.30.0 및 5.30.1에서 클러스터를 생성할 때 설치할 애플리케이션으로 Presto를 선택합니다.
+ Amazon EMR Managed Scaling에 대해 최대 코어 노드 및 온디맨드 제한을 설정할 때 인스턴스 그룹과 인스턴스 플릿 간 차이를 고려합니다. 각 인스턴스 그룹은 온디맨드 및 스팟과 같이 동일한 인스턴스 유형 및 동일한 인스턴스 구매 옵션으로 구성됩니다. 인스턴스 플릿마다, 최대 5개 인스턴스 유형을 지정할 수 있으며, 각 인스턴스 유형을 온디맨드 및 스팟 인스턴스로 프로비저닝할 수 있습니다. 자세한 내용은 [인스턴스 플릿 또는 균일한 인스턴스 그룹으로 클러스터 생성](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-group-configuration.html), [인스턴스 플릿 옵션](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html#emr-instance-fleet-options) 및 [노드 할당 시나리오](managed-scaling-allocation-strategy.md#node-allocation-scenarios) 섹션을 참조하세요.
+ Amazon EMR 5.30.0 이상에서 마스터 보안 그룹의 기본 **모두 허용** 아웃바운드 규칙(0.0.0.0/)을 제거하는 경우 포트 9443에서 서비스에 액세스할 수 있도록 보안 그룹에 아웃바운드 TCP 연결을 허용하는 규칙을 추가해야 합니다. 또한 서비스 액세스를 위한 보안 그룹은 마스터 보안 그룹의 포트 9443을 통한 인바운드 TCP 트래픽을 허용해야 합니다. 보안 그룹 구성에 대한 자세한 내용은 [기본 인스턴스(프라이빗 서브넷)에 대한 Amazon EMR 관리형 보안 그룹](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-man-sec-groups.html#emr-sg-elasticmapreduce-master-private)을 참조하세요.
+ AWS CloudFormation 를 사용하여 Amazon EMR 관리형 조정을 구성할 수 있습니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*에서 [AWS::EMR::Cluster](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticmapreduce-cluster.html)를 참조하세요.
+ 스팟 노드를 사용하는 경우 Amazon EMR이 스팟 노드를 제거할 때 Amazon EMR이 애플리케이션 프로세스를 제거하지 못하도록 노드 레이블을 사용하는 방법을 고려합니다. 노드 레이블에 대한 자세한 내용은 [태스크 노드](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html#emr-plan-task)를 참조하세요.
+ Amazon EMR 릴리스 6.15 이하에서는 노드 레이블링이 기본적으로 지원되지 않습니다. 자세한 내용은 [노드 유형 이해: 프라이머리, 코어 및 태스크 노드](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)를 참조하세요.
+ Amazon EMR 릴리스 6.15 이하를 사용하는 경우 코어 및 태스크 노드와 같은 노드 유형별로만 노드 레이블을 할당할 수 있습니다. 그러나 Amazon EMR 릴리스 7.0 이상을 사용하는 경우 온디맨드 및 스팟과 같은 노드 유형 및 시장 유형별로 노드 레이블을 구성할 수 있습니다.
+ 애플리케이션 프로세스를 코어 노드로 제한할 때 애플리케이션 프로세스 수요가 증가하고 실행기 수요가 감소하는 경우 동일한 크기 조정 작업에서 코어 노드를 다시 추가하고 태스크 노드를 제거할 수 있습니다. 자세한 내용은 [노드 할당 전략 및 시나리오 이해](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)를 참조하세요.
+ Amazon EMR은 태스크 노드에 레이블을 지정하지 않으므로 태스크 노드에 대해서만 애플리케이션 프로세스를 제한하도록 YARN 속성을 설정할 수 없습니다. 그러나 시장 유형을 노드 레이블로 사용하려는 경우 애플리케이션 프로세스 배치에 `ON_DEMAND` 또는 `SPOT` 레이블을 사용할 수 있습니다. 애플리케이션 프라이머리 프로세스에 대해서는 스팟 노드를 사용하지 않는 것이 좋습니다.
+ 노드 레이블을 사용하는 경우 클러스터의 총 실행 단위는 관리형 조정 정책에 설정된 최대 컴퓨팅을 일시적으로 초과할 수 있는 반면, Amazon EMR은 일부 인스턴스를 해제합니다. 요청된 총 단위는 항상 정책의 최대 컴퓨팅 수치 이하로 유지됩니다.
+ 관리형 조정은 노드 레이블 `ON_DEMAND` 및 `SPOT` 또는 `CORE` 및 `TASK`만 지원합니다. 사용자 지정 노드 레이블은 지원되지 않습니다.
+ Amazon EMR은 클러스터를 생성하고 리소스를 프로비저닝하는 경우 노드 레이블을 생성합니다. Amazon EMR은 클러스터를 재구성하는 경우 노드 레이블 추가를 지원하지 않습니다. 또한 클러스터를 시작한 후 관리형 조정을 구성하는 경우 노드 레이블을 수정할 수 없습니다.
+ 관리형 조정은 애플리케이션 프로세스 및 실행기 수요에 따라 코어 및 태스크 노드를 독립적으로 조정합니다. 코어 스케일 다운 중에 HDFS 데이터 손실 문제를 방지하려면 코어 노드에 대한 표준 관행을 따릅니다. 코어 노드 및 HDFS 복제 관련 모범 사례에 대해 자세히 알아보려면 [고려 사항 및 모범 사례](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-considerations.html)를 참조하세요.
+ `core` 또는 `ON_DEMAND` 노드에만 애플리케이션 프로세스 및 실행기 둘 다를 배치할 수는 없습니다. 노드 중 하나에서 애플리케이션 프로세스 및 실행기를 모두 추가하려면 `yarn.node-labels.am.default-node-label-expression` 구성을 사용하지 않습니다.
예를 들어, 애플리케이션 프로세스와 실행기를 모두 `ON_DEMAND` 노드에 배치하려면 최대 컴퓨팅을 `ON_DEMAND` 노드의 최댓값과 동일하게 설정합니다. 또한 `yarn.node-labels.am.default-node-label-expression` 구성을 제거합니다.
`core` 노드에 애플리케이션 프로세스 및 실행기를 모두 추가하려면 `yarn.node-labels.am.default-node-label-expression` 구성을 제거합니다.
+ 노드 레이블과 함께 관리형 조정을 사용할 때 여러 애플리케이션을 병렬로 실행하려는 경우 `yarn.scheduler.capacity.maximum-am-resource-percent: 1` 속성을 설정합니다. 그러면 애플리케이션 프로세스가 사용 가능한 `CORE` 또는 `ON_DEMAND` 노드를 완전히 활용할 수 있습니다.
+ 노드 레이블과 함께 관리형 조정을 사용하는 경우 `yarn.resourcemanager.decommissioning.timeout` 속성을 클러스터에서 가장 오래 실행되는 애플리케이션보다 긴 값으로 설정합니다. 그러면 Amazon EMR Managed Scaling이 `CORE` 또는 `ON_DEMAND` 노드를 다시 커미셔닝하기 위해 애플리케이션을 다시 예약해야 할 가능성이 줄어듭니다.
+ 셔플 데이터 손실로 인한 애플리케이션 실패 위험을 줄이기 위해 Amazon EMR은 클러스터에서 지표를 수집하여 현재 및 이전 단계의 기존 임시 셔플 데이터가 있는 노드를 결정합니다. 드물지만 이미 완료되었거나 종료된 애플리케이션에 대해 지표가 계속해서 오래된 데이터를 보고할 수 있습니다. 이는 클러스터의 인스턴스를 적시에 스케일 다운하는 데 영향을 미칠 수 있습니다. 셔플 데이터가 많은 클러스터의 경우 EMR 버전 6.13 이상을 사용하는 것이 좋습니다.
## 기능 기록
이 테이블에는 Amazon EMR Managed Scaling 기능에 대한 업데이트가 나열되어 있습니다.
| 릴리스 날짜 | 기능 | Amazon EMR 버전 |
| --- | --- | --- |
| 2024년 11월 20일 | 관리형 규모 조정은 il-central-1 이스라엘(텔아비브), me-central-1 중동(UAE) 및 ap-northeast-3 아시아 태평양(오사카) 리전에서 사용할 수 있습니다. | 5.30.0 및 6.1.0 이상 |
| 2024년 11월 15일 | 관리형 조정은 eu-central-2 유럽(취리히) 리전에서 사용할 수 있습니다. | 5.30.0 및 6.1.0 이상 |
| 2024년 8월 20일 | 이제 노드 레이블을 관리형 조정에서 사용할 수 있으므로 시장 유형 또는 노드 유형에 따라 인스턴스에 레이블을 지정하여 자동 조정을 개선할 수 있습니다. | 7.2.0 이상 |
| 2024년 3월 31일 | 관리형 조정은 ap-south-2 아시아 태평양(하이데라바드) 리전에서 사용할 수 있습니다. | 6.14.0 이상 |
| 2024년 2월 13일 | 관리형 조정은 eu-south-2 유럽(스페인) 리전에서 사용할 수 있습니다. | 6.14.0 이상 |
| 2023년 10월 10일 | ap-southeast-3 아시아 태평양(자카르타) 리전에서 Managed Scaling을 사용할 수 있습니다. | 6.14.0 이상 |
| 2023년 7월 28일 | Amazon EMR에서 현재 인스턴스 그룹의 스케일 업이 지연되는 경우 스케일 업할 때 다른 태스크 인스턴스 그룹으로 전환할 수 있도록 Managed Scaling을 개선했습니다. | 5.34.0 이상, 6.4.0 이상 |
| 2023년 6월 16일 | 애플리케이션 마스터를 실행하는 노드를 인식하여 해당 노드가 스케일 다운되지 않도록 Managed Scaling을 개선했습니다. 자세한 내용은 [Amazon EMR 노드 할당 전략 및 시나리오 이해](managed-scaling-allocation-strategy.md) 단원을 참조하십시오. | 5.34.0 이상, 6.4.0 이상 |
| 2022년 3월 21일 | 클러스터를 스케일 다운할 때 사용되는 Spark 셔플 데이터 인식을 추가했습니다. Apache Spark가 있고 Managed Scaling이 활성화된 Amazon EMR 클러스터의 경우 Amazon EMR은 Spark 실행기 및 중간 셔플 데이터 위치를 지속적으로 모니터링합니다. Amazon EMR은 이 정보를 사용하여 사용률이 낮은 인스턴스(활발하게 사용되는 셔플 데이터를 포함하지 않음)를 스케일 다운합니다. 이렇게 하면 손실된 셔플 데이터가 재계산되지 않으므로 비용을 절감하고 작업 성과를 개선하는 데 도움이 됩니다. 자세한 내용은 [Spark Programming Guide](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations)를 참조하세요. | 5.34.0 이상, 6.4.0 이상 |
# Amazon EMR에 대한 관리형 조정 구성
다음 섹션에서는 AWS Management Console AWS SDK for Java, 또는를 사용하여 관리형 조정을 사용하는 EMR 클러스터를 시작하는 방법을 설명합니다 AWS Command Line Interface.
**Topics**
+ [AWS Management Console 를 사용하여 관리형 조정 구성](#managed-scaling-console)
+ [AWS CLI 를 사용하여 관리형 조정 구성](#managed-scaling-cli)
+ [AWS SDK for Java 를 사용하여 관리형 조정 구성](#managed-scaling-sdk)
## AWS Management Console 를 사용하여 관리형 조정 구성
Amazon EMR 콘솔을 사용하여 클러스터를 생성할 때 Managed Scaling을 구성하거나 실행 중인 클러스터의 Managed Scaling 정책을 변경할 수 있습니다.
------
#### [ 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 릴리스 **emr-5.30.0** 이상(**emr-6.0.0** 버전 제외)을 선택합니다.
1. **클러스터 크기 조정 및 프로비저닝 옵션**에서 **EMR 관리형 조정 사용**을 선택합니다. 인스턴스의 **최소** 및 **최대** 수, **최대 코어 노드** 인스턴스 및 **최대 온디맨드** 인스턴스를 지정합니다.
1. 클러스터에 적용할 다른 옵션을 선택합니다.
1. 클러스터를 시작하려면 **클러스터 생성**을 선택합니다.
**콘솔을 사용하여 기존 클러스터에서 관리형 조정을 구성하는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 업데이트할 클러스터를 선택합니다.
1. 클러스터 세부 정보 페이지의 **인스턴스** 탭에서 **인스턴스 그룹 설정** 섹션을 찾습니다. **클러스터 크기 조정 편집**을 선택하고 인스턴스의 **최소** 및 **최대** 수와 **온디맨드** 제한에 새 값을 지정합니다.
------
## AWS CLI 를 사용하여 관리형 조정 구성
클러스터를 생성할 때 Amazon EMR에 대한 AWS CLI 명령을 사용하여 관리형 조정을 구성할 수 있습니다. 관련 명령 내에서 JSON 구성 인라인을 지정하는 간편 구문을 사용하거나 구성 JSON을 포함하는 파일을 참조할 수 있습니다. 관리형 조정 정책을 기존 클러스터에 적용하고 이전에 적용된 관리형 조정 정책을 제거할 수도 있습니다. 또한 실행 중인 클러스터에서 확장 정책 구성의 세부 정보를 검색할 수 있습니다.
**클러스터 시작 중에 관리형 조정 활성화**
다음 예제에서 보여주듯이 클러스터 시작 중에 관리형 조정을 활성화할 수 있습니다.
```
aws emr create-cluster \
--service-role EMR_DefaultRole \
--release-label emr-7.12.0 \
--name EMR_Managed_Scaling_Enabled_Cluster \
--applications Name=Spark Name=Hbase \
--ec2-attributes KeyName=keyName,InstanceProfile=EMR_EC2_DefaultRole \
--instance-groups InstanceType=m4.xlarge,InstanceGroupType=MASTER,InstanceCount=1 InstanceType=m4.xlarge,InstanceGroupType=CORE,InstanceCount=2 \
--region us-east-1 \
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=2,MaximumCapacityUnits=4,UnitType=Instances}'
```
`create-cluster`를 사용할 때 관리형 조정 정책 옵션을 사용하여 관리형 정책 구성을 지정할 수도 있습니다.
**기존 클러스터에 관리형 조정 정책 적용**
다음 예제에서 보여주듯이 관리형 조정 정책을 기존 클러스터에 적용할 수 있습니다.
```
aws emr put-managed-scaling-policy
--cluster-id j-123456
--managed-scaling-policy ComputeLimits='{MinimumCapacityUnits=1,
MaximumCapacityUnits=10, MaximumOnDemandCapacityUnits=10, UnitType=Instances}'
```
`aws emr put-managed-scaling-policy` 명령을 사용하여 기존 클러스터에 관리형 조정 정책을 적용할 수도 있습니다. 다음 예제에서는 관리형 조정 정책 구성을 지정하는 JSON 파일 `managedscaleconfig.json`에 대한 참조를 사용합니다.
```
aws emr put-managed-scaling-policy --cluster-id j-123456 --managed-scaling-policy file://./managedscaleconfig.json
```
다음 예제는 관리형 조정 정책을 정의하는 `managedscaleconfig.json` 파일의 내용을 보여줍니다.
```
{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 10,
"MaximumOnDemandCapacityUnits": 10
}
}
```
**관리형 조정 정책 구성 검색**
`GetManagedScalingPolicy` 명령은 정책 구성을 검색합니다. 예를 들어, 다음 명령은 클러스터 ID `j-123456`의 클러스터에 대한 구성을 검색합니다.
```
aws emr get-managed-scaling-policy --cluster-id j-123456
```
다음과 같은 예제 출력이 생성됩니다.
```
1. {
2. "ManagedScalingPolicy": {
3. "ComputeLimits": {
4. "MinimumCapacityUnits": 1,
5. "MaximumOnDemandCapacityUnits": 10,
6. "MaximumCapacityUnits": 10,
7. "UnitType": "Instances"
8. }
9. }
10. }
```
에서 Amazon EMR 명령을 사용하는 방법에 대한 자세한 내용은 섹션을 AWS CLI참조하세요[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr).
**관리형 조정 정책 제거**
`RemoveManagedScalingPolicy` 명령은 정책 구성을 제거합니다. 예를 들어, 다음 명령은 클러스터 ID `j-123456`의 클러스터에 대한 구성을 제거합니다.
```
aws emr remove-managed-scaling-policy --cluster-id j-123456
```
## AWS SDK for Java 를 사용하여 관리형 조정 구성
다음 프로그램 발췌에서는 AWS SDK for Java를 사용하여 관리형 조정을 구성하는 방법을 보여줍니다.
```
package com.amazonaws.emr.sample;
import java.util.ArrayList;
import java.util.List;
import com.amazonaws.AmazonClientException;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.AWSStaticCredentialsProvider;
import com.amazonaws.auth.profile.ProfileCredentialsProvider;
import com.amazonaws.regions.Regions;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduce;
import com.amazonaws.services.elasticmapreduce.AmazonElasticMapReduceClientBuilder;
import com.amazonaws.services.elasticmapreduce.model.Application;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimits;
import com.amazonaws.services.elasticmapreduce.model.ComputeLimitsUnitType;
import com.amazonaws.services.elasticmapreduce.model.InstanceGroupConfig;
import com.amazonaws.services.elasticmapreduce.model.JobFlowInstancesConfig;
import com.amazonaws.services.elasticmapreduce.model.ManagedScalingPolicy;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowRequest;
import com.amazonaws.services.elasticmapreduce.model.RunJobFlowResult;
public class CreateClusterWithManagedScalingWithIG {
public static void main(String[] args) {
AWSCredentials credentialsFromProfile = getCreadentials("AWS-Profile-Name-Here");
/**
* Create an Amazon EMR client with the credentials and region specified in order to create the cluster
*/
AmazonElasticMapReduce emr = AmazonElasticMapReduceClientBuilder.standard()
.withCredentials(new AWSStaticCredentialsProvider(credentialsFromProfile))
.withRegion(Regions.US_EAST_1)
.build();
/**
* Create Instance Groups - Primary, Core, Task
*/
InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig()
.withInstanceCount(1)
.withInstanceRole("MASTER")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig()
.withInstanceCount(4)
.withInstanceRole("CORE")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig()
.withInstanceCount(5)
.withInstanceRole("TASK")
.withInstanceType("m4.large")
.withMarket("ON_DEMAND");
List igConfigs = new ArrayList<>();
igConfigs.add(instanceGroupConfigMaster);
igConfigs.add(instanceGroupConfigCore);
igConfigs.add(instanceGroupConfigTask);
/**
* specify applications to be installed and configured when Amazon EMR creates the cluster
*/
Application hive = new Application().withName("Hive");
Application spark = new Application().withName("Spark");
Application ganglia = new Application().withName("Ganglia");
Application zeppelin = new Application().withName("Zeppelin");
/**
* Managed Scaling Configuration -
* Using UnitType=Instances for clusters composed of instance groups
*
* Other options are:
* UnitType = VCPU ( for clusters composed of instance groups)
* UnitType = InstanceFleetUnits ( for clusters composed of instance fleets)
**/
ComputeLimits computeLimits = new ComputeLimits()
.withMinimumCapacityUnits(1)
.withMaximumCapacityUnits(20)
.withUnitType(ComputeLimitsUnitType.Instances);
ManagedScalingPolicy managedScalingPolicy = new ManagedScalingPolicy();
managedScalingPolicy.setComputeLimits(computeLimits);
// create the cluster with a managed scaling policy
RunJobFlowRequest request = new RunJobFlowRequest()
.withName("EMR_Managed_Scaling_TestCluster")
.withReleaseLabel("emr-7.12.0") // Specifies the version label for the Amazon EMR release; we recommend the latest release
.withApplications(hive,spark,ganglia,zeppelin)
.withLogUri("s3://path/to/my/emr/logs") // A URI in S3 for log files is required when debugging is enabled.
.withServiceRole("EMR_DefaultRole") // If you use a custom IAM service role, replace the default role with the custom role.
.withJobFlowRole("EMR_EC2_DefaultRole") // If you use a custom Amazon EMR role for EC2 instance profile, replace the default role with the custom Amazon EMR role.
.withInstances(new JobFlowInstancesConfig().withInstanceGroups(igConfigs)
.withEc2SubnetId("subnet-123456789012345")
.withEc2KeyName("my-ec2-key-name")
.withKeepJobFlowAliveWhenNoSteps(true))
.withManagedScalingPolicy(managedScalingPolicy);
RunJobFlowResult result = emr.runJobFlow(request);
System.out.println("The cluster ID is " + result.toString());
}
public static AWSCredentials getCredentials(String profileName) {
// specifies any named profile in .aws/credentials as the credentials provider
try {
return new ProfileCredentialsProvider("AWS-Profile-Name-Here")
.getCredentials();
} catch (Exception e) {
throw new AmazonClientException(
"Cannot load credentials from .aws/credentials file. " +
"Make sure that the credentials file exists and that the profile name is defined within it.",
e);
}
}
public CreateClusterWithManagedScalingWithIG() { }
}
```
# Amazon EMR의 고급 규모 조정
EC2 버전 7.0의 Amazon EMR부터 고급 규모 조정을 활용하여 클러스터의 리소스 사용률을 제어할 수 있습니다. Advanced Scaling은 비즈니스 요구 사항에 따라 리소스 사용률 및 성능 수준을 조정하기 위한 사용률-성능 규모를 도입합니다. 설정하는 값은 클러스터가 리소스 보존에 더 많은 가중치를 부여할지 아니면 빠른 완료가 중요한 서비스 수준 계약(SLA)에 민감한 워크로드를 처리하도록 스케일 업할지를 결정합니다. 규모 조정 값이 조정되면 관리형 규모 조정은 의도를 해석하고 지능적으로 규모를 조정하여 리소스를 최적화합니다. 관리형 규모 조정에 대한 자세한 내용은 [Amazon EMR에 대한 관리형 규모 조정 구성](https://docs.aws.amazon.com/emr/latest/ManagementGuide/managed-scaling-configure.html)을 참조하세요.
## 고급 조정 설정
고급 규모 조정에 대해 설정한 값은 요구 사항에 맞게 클러스터를 최적화합니다. 값 범위는 **1**\$1**100**입니다. 가능한 값은 **1**, **25**, **50**, **75** 및 **100**입니다. 인덱스를 이외의 값으로 설정하면 검증 오류가 발생합니다.
규모 조정 값은 리소스 사용 전략에 매핑됩니다. 다음 목록은 다음 중 몇 가지를 정의합니다.
+ **사용률 최적화 [1]** - 이 설정은 리소스 과다 프로비저닝을 방지합니다. 비용을 낮게 유지하고 효율적인 리소스 사용률을 우선시하려면 낮은 값을 사용합니다. 이 작업을 수행하면 클러스터가 덜 적극적으로 확장됩니다. 이는 워크로드 스파이크가 정기적으로 발생하고 리소스가 너무 빠르게 증가하는 것을 원치 않는 사용 사례에 적합합니다.
+ **균형 [50]** - 리소스 사용률과 작업 성능의 균형을 맞춥니다. 이 설정은 대부분의 단계에서 안정적인 런타임이 안정적인 워크로드에 적합합니다. 단기 및 장기 실행 단계가 혼합된 워크로드에도 적합합니다. 어떤 설정을 선택해야 할지 잘 모르는 경우 이 설정부터 시작하는 것이 좋습니다.
+ ** 성능 최적화 [100]** - 이 전략은 성능에 우선순위를 둡니다. 클러스터는 작업이 빠르게 완료되고 성능 목표를 충족하도록 적극적으로 확장됩니다. 성능 최적화는 빠른 실행 시간이 중요한 서비스 수준 계약(SLA)에 민감한 워크로드에 적합합니다.
**참고**
사용 가능한 중간 값은 클러스터의 고급 규모 조정 동작을 미세 조정하기 위한 전략 간의 중간 기반을 제공합니다.
## 고급 조정의 이점
데이터 볼륨 변경, 비용 목표 조정, SLA 구현과 같은 환경 및 요구 사항에 변동성이 있는 경우 클러스터 규모 조정을 통해 클러스터 구성을 조정하여 목표를 달성할 수 있습니다. 주요 이점은 다음과 같습니다.
+ **세분화된 제어 향상** - 사용률-성능 설정을 도입하면 요구 사항에 따라 클러스터의 조정 동작을 쉽게 조정할 수 있습니다. 사용 패턴에 따라 컴퓨팅 리소스에 대한 수요를 충족하도록 스케일 업하거나 리소스를 절약하도록 스케일 다운할 수 있습니다.
+ **비용 최적화 개선** - 요구 사항에 따라 낮은 사용률 값을 선택하여 비용 목표를 더욱 쉽게 충족할 수 있습니다.
## 최적화 시작하기
**설정 및 구성**
다음 단계에 따라 성능 인덱스를 설정하고 규모 조정 전략을 최적화합니다.
1. 다음 명령은 사용률 최적화 `[1]` 규모 조정 전략으로 기존 클러스터를 업데이트합니다.
```
aws emr put-managed-scaling-policy --cluster-id 'cluster-id' \
--managed-scaling-policy '{
"ComputeLimits": {
"UnitType": "Instances",
"MinimumCapacityUnits": 1,
"MaximumCapacityUnits": 2,
"MaximumOnDemandCapacityUnits": 2,
"MaximumCoreCapacityUnits": 2
},
"ScalingStrategy": "ADVANCED",
"UtilizationPerformanceIndex": "1"
}' \
--region "region-name"
```
`ScalingStrategy` 및 `UtilizationPerformanceIndex` 속성은 새 속성이며 규모 조정 최적화와 관련이 있습니다. 관리형 규모 조정 정책에서 `UtilizationPerformanceIndex` 속성에 해당하는 값(1, 25, 50, 75 및 100)을 설정하여 다양한 규모 조정 전략을 선택할 수 있습니다.
1. 기본 관리형 규모 조정 전략으로 되돌리려면 `ScalingStrategy` 및 `UtilizationPerformanceIndex` 속성을 포함하지 않고 `put-managed-scaling-policy` 명령을 실행합니다. (이는 선택 사항입니다.) 이 샘플은 다음 작업을 수행하는 방법을 보여줍니다.
```
aws emr put-managed-scaling-policy \
--cluster-id 'cluster-id' \
--managed-scaling-policy '{"ComputeLimits":{"UnitType":"Instances","MinimumCapacityUnits":1,"MaximumCapacityUnits":2,"MaximumOnDemandCapacityUnits":2,"MaximumCoreCapacityUnits":2}}' \
--region "region-name"
```
**모니터링 지표를 사용하여 클러스터 사용률 추적**
EMR 버전 7.3.0부터 Amazon EMR은 메모리 및 가상 CPU와 관련된 4가지 새로운 지표를 게시합니다. 이를 사용하여 조정 전략 전반에서 클러스터 사용률을 측정할 수 있습니다. 이러한 지표는 모든 사용 사례에 사용할 수 있지만, 여기에 제공된 세부 정보를 사용하여 고급 규모 조정을 모니터링할 수 있습니다.
유용한 지표는 다음과 같습니다.
+ **YarnContainersUsedMemoryGBSeconds** - YARN에서 관리하는 애플리케이션에서 사용하는 메모리의 양입니다.
+ **YarnContainersTotalMemoryGBSeconds** - 클러스터 내에서 YARN에 할당된 총 메모리 용량입니다.
+ **YarnNodesUsedVCPUSeconds** - YARN에서 관리하는 각 애플리케이션의 총 VCPU 초입니다.
+ **YarnNodesTotalVCPUSeconds** - 준비되지 않은 기간을 포함하여 사용된 메모리의 총 VCPU 초를 집계합니다.
Amazon CloudWatch Logs Insights를 사용하여 리소스 지표를 분석할 수 있습니다. 기능에는 리소스 사용 및 조정과 관련된 지표를 추출하는 데 도움이 되는 특별히 구축된 쿼리 언어가 포함됩니다.
Amazon CloudWatch 콘솔에서 실행할 수 있는 다음 쿼리는 지표 수학을 사용하여 사용된 메모리의 실행 합계(e2)를 총 메모리의 실행 합계(e3)로 나누어 평균 메모리 사용률(e1)을 계산합니다.
```
{
"metrics": [
[ { "expression": "e2/e3", "label": "Average Mem Utilization", "id": "e1", "yAxis": "right" } ],
[ { "expression": "RUNNING_SUM(m1)", "label": "RunningTotal-YarnContainersUsedMemoryGBSeconds", "id": "e2", "visible": false } ],
[ { "expression": "RUNNING_SUM(m2)", "label": "RunningTotal-YarnContainersTotalMemoryGBSeconds", "id": "e3", "visible": false } ],
[ "AWS_EMR_ManagedResize", "YarnContainersUsedMemoryGBSeconds", "ACCOUNT_ID", "793684541905", "COMPONENT", "ManagerService", "JOB_FLOW_ID", "cluster-id", { "id": "m1", "label": "YarnContainersUsedMemoryGBSeconds" } ],
[ ".", "YarnContainersTotalMemoryGBSeconds", ".", ".", ".", ".", ".", ".", { "id": "m2", "label": "YarnContainersTotalMemoryGBSeconds" } ]
],
"view": "timeSeries",
"stacked": false,
"region": "region",
"period": 60,
"stat": "Sum",
"title": "Memory Utilization"
}
```
로그를 쿼리하려면 AWS 콘솔에서 CloudWatch를 선택합니다. CloudWatch 쿼리 작성하기에 대한 자세한 내용은 Amazon CloudWatch Logs 사용 설명서의 [CloudWatch Logs Insights에서 로그 데이터 분석](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)을 참조하세요.
다음 이미지는 샘플 클러스터에 대한 이러한 지표를 보여줍니다.
![\[사용률 통계를 보여주는 그래프.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/scaling_graph_EMR.png)
## 고려 사항 및 제한 사항
+ 규모 조정 전략의 효과는 고유한 워크로드 특성 및 클러스터 구성에 따라 다를 수 있습니다. 규모 조정 설정을 실험하여 사용 사례에 맞는 최적의 인덱스 값을 결정하는 것이 좋습니다.
+ Amazon EMR 고급 규모 조정은 배치 워크로드에 특히 적합합니다. SQL/데이터 웨어하우징 및 스트리밍 워크로드의 경우 최적의 성능을 위해 기본 관리형 규모 조정 전략을 사용하는 것이 좋습니다.
+ Amazon EMR Advanced Scaling은 클러스터에서 노드 레이블 구성이 활성화된 경우 지원되지 않습니다. 클러스터에서 고급 조정 및 노드 레이블 구성이 모두 활성화된 경우 조정 동작은 기본 관리형 조정 설정이 활성화된 것처럼 됩니다.
+ 성능 최적화 조정 전략을 사용하면 기본 관리형 규모 조정 전략보다 긴 기간 동안 높은 컴퓨팅 리소스를 유지하여 더 빠른 작업 실행이 가능합니다. 이 모드는 리소스 수요에 맞게 빠르게 스케일 업하는 것을 우선시하므로 작업 완료가 빨라집니다. 이로 인해 기본 전략에 비해 비용이 증가할 수 있습니다.
+ 클러스터가 이미 최적화되어 완전히 활용되는 경우 고급 규모 조정을 활성화해도 추가 이점이 제공되지 않을 수 있습니다. 경우에 따라 고급 규모 조정을 활성화하면 워크로드가 더 오래 실행될 수 있으므로 비용이 증가할 수 있습니다. 이러한 경우 최적의 리소스 할당 및 비용 효율성을 보장하기 위해 기본 관리형 규모 조정 전략을 사용하는 것이 좋습니다.
+ 관리형 규모 조정의 맥락에서 설정이 성능 최적화 [**100**]에서 사용률 최적화 [**1**]로 조정됨에 따라 실행 시간 경과에 따른 리소스 사용률에 중점을 둡니다. 그러나 워크로드의 특성과 클러스터의 토폴로지에 따라 결과가 달라질 수 있다는 점에 유의합니다. 사용 사례에 최적의 결과를 얻으려면 워크로드로 규모 조정 전략을 테스트하여 가장 적합한 설정을 결정하는 것이 좋습니다.
+ **PerformanceUtilizationIndex**가 허용하는 값은 다음과 같습니다.
+ **1**
+ **25**
+ **50**
+ **75**
+ **100**
다른 값이 제출되면 검증 오류가 발생합니다.
# Amazon EMR 노드 할당 전략 및 시나리오 이해
이 섹션에서는 Amazon EMR Managed Scaling과 함께 사용할 수 있는 노드 할당 전략 및 일반적인 조정 시나리오에 대한 개요를 제공합니다.
## 노드 할당 전략
Amazon EMR Managed Scaling은 다음과 같은 스케일 업 및 스케일 다운 전략을 기반으로 코어 및 태스크 노드를 할당합니다.
**스케일 업 전략 **
+ Amazon EMR 릴리스 7.2 이상의 경우 관리형 조정은 먼저 노드 레이블 및 애플리케이션 프로세스 제한 YARN 속성을 기반으로 노드를 추가합니다.
+ Amazon EMR 릴리스 7.2 이상의 경우 노드 레이블을 활성화하고 애플리케이션 프로세스를 `CORE` 노드로 제한하면 애플리케이션 프로세스 수요가 증가하고 실행기 수요가 증가할 때 Amazon EMR Managed Scaling은 코어 노드 및 태스크 노드를 스케일 업합니다. 마찬가지로 노드 레이블을 활성화하고 애플리케이션 프로세스를 `ON_DEMAND` 노드로 제한하면 관리형 조정은 애플리케이션 프로세스 수요가 증가할 때 온디맨드 노드를 스케일 업하고 실행기 수요가 증가할 때 스팟 노드를 스케일 업합니다.
+ 노드 레이블을 활성화하지 않으면 애플리케이션 프로세스 배치가 노드 또는 시장 유형으로 제한되지 않습니다.
+ 노드 레이블을 사용하면 관리형 조정이 동일한 크기 조정 작업에서 서로 다른 인스턴스 그룹 및 인스턴스 플릿을 스케일 업 및 스케일 다운할 수 있습니다. 예를 들어, `instance_group1`에 `ON_DEMAND` 노드가 있고 `instance_group2`에 `SPOT` 노드가 있을 때 노드 레이블이 활성화되고 애플리케이션 프로세스가 `ON_DEMAND` 레이블의 노드로 제한되는 시나리오입니다. 애플리케이션 프로세스 수요가 감소하고 실행기 수요가 증가하면 관리형 조정은 `instance_group1`을 스케일 다운하고 `instance_group2`를 스케일 업합니다.
+ Amazon EMR에서 현재 인스턴스 그룹의 스케일 업이 지연되는 경우 Managed Scaling을 사용하는 클러스터는 다른 태스크 인스턴스 그룹으로 전환합니다.
+ `MaximumCoreCapacityUnits` 파라미터가 설정된 경우 Amazon EMR은 코어 유닛이 최대 허용 한도에 도달할 때까지 코어 노드를 확장합니다. 남은 용량이 모두 태스크 노드에 추가됩니다.
+ `MaximumOnDemandCapacityUnits` 파라미터가 설정된 경우 Amazon EMR은 온디맨드 단위가 최대 허용 한도에 도달할 때까지 온디맨드 인스턴스를 사용하여 클러스터를 조정합니다. 나머지 용량은 모두 스팟 인스턴스를 사용하여 추가됩니다.
+ `MaximumCoreCapacityUnits` 및 `MaximumOnDemandCapacityUnits` 파라미터가 모두 설정된 경우 Amazon EMR은 조정 중에 두 한도를 모두 고려합니다.
예를 들어, `MaximumCoreCapacityUnits`이 `MaximumOnDemandCapacityUnits` 미만인 경우 Amazon EMR은 먼저 코어 용량 한도에 도달할 때까지 코어 노드를 조정합니다. 남은 용량에 대해 Amazon EMR은 먼저 온디맨드 인스턴스를 사용하여 온디맨드 제한에 도달할 때까지 태스크 노드를 확장한 다음 스팟 인스턴스를 태스크 노드로 사용합니다.
**스케일 다운 전략**
+ 스케일 업 전략과 마찬가지로 Amazon EMR은 노드 레이블을 기반으로 노드를 제거합니다. 노드 레이블에 대한 자세한 내용은 [노드 유형 이해: 프라이머리, 코어 및 태스크 노드](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-master-core-task-nodes.html)를 참조하세요.
+ 노드 레이블을 활성화하지 않은 경우 관리형 조정은 태스크 노드를 제거한 다음, 원하는 스케일 다운 목표 용량에 도달할 때까지 코어 노드를 제거합니다. 관리형 조정은 클러스터를 관리형 조정 정책에 지정된 최소 제약 조건 이하로 스케일 다운하지 않습니다.
+ Amazon EMR 버전 5.34.0 이상 및 Amazon EMR 버전 6.4.0 이상은 Spark 셔플 데이터 인식을 지원하므로 관리형 규모 조정이 기존 셔플 데이터를 인식하는 동안 인스턴스가 스케일 다운되지 않습니다. 셔플 작업에 대한 자세한 내용은 [Spark Programming Guide](https://spark.apache.org/docs/latest/rdd-programming-guide.html#shuffle-operations)를 참조하세요. 관리형 규모 조정은 활성 Spark 애플리케이션의 현재 및 이전 단계에서 셔플 데이터를 사용하여 노드를 최대 30분까지 스케일 다운하지 않도록 최선의 노력을 합니다. 이 기능을 통해 의도하지 않은 셔플 데이터 손실을 최소화할 수 있으며 이를 통해 작업을 다시 시도하거나 중간 데이터를 재계산할 필요가 없습니다. 하지만 셔플 데이터 손실 방지는 보장되지 않습니다. Spark 셔플 보호를 개선하려면 릴리스 레이블이 7.4 이상인 클러스터에서 셔플 인식을 사용하는 것이 좋습니다. 클러스터 구성에 다음 플래그를 추가하여 향상된 Spark 셔플 보호를 활성화합니다.
+ `yarn.nodemanager.shuffledata-monitor.interval-ms` 플래그(기본값 30,000ms) 또는 `spark.dynamicAllocation.executorIdleTimeout` (기본값 60초)가 기본값에서 변경된 경우 필요한 플래그를 업데이트`true`하여 조건이 `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` 유지되는지 확인합니다.
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
}
},
{
"Classification": "spark-defaults",
"Properties": {
"spark.dynamicAllocation.enabled": "true",
"spark.shuffle.service.removeShuffle": "true"
}
}
]
```
+ 관리형 조정은 먼저 태스크 노드를 제거한 다음, 원하는 스케일 다운 목표 용량에 도달할 때까지 코어 노드를 제거합니다. 클러스터는 관리형 조정 정책의 최소 제약 조건 이하로 조정되지 않습니다.
+ Amazon EMR 5.x 릴리스 5.34.0 이상 및 6.x 릴리스 6.4.0 이상에서 시작된 클러스터의 경우 애플리케이션이 실행되는 활성 단계가 있는 경우 Amazon EMR Managed Scaling은 Apache Spark`ApplicationMaster`용가 있는 노드를 스케일 다운하지 않습니다. 이렇게 하면 작업 실패 및 재시도가 최소화되어 작업 성능을 개선하고 비용을 절감하는 데 도움이 됩니다. 클러스터에서 `ApplicationMaster`를 실행하는 노드를 확인하려면 Spark 기록 서버로 이동하여 Spark 애플리케이션 ID의 **실행기** 탭에서 드라이버를 필터링합니다.
+ EMR 관리형 규모 조정을 사용한 지능형 조정은 Spark의 셔플 데이터 손실을 최소화하지만 스케일 다운 중에 일시적인 셔플 데이터가 보호되지 않을 수 있는 인스턴스가 있을 수 있습니다. 스케일 다운 중에 셔플 데이터의 복원력을 향상하려면 YARN의 **셔플 데이터에 대해 Graceful Decommissioning**을 활성화하는 것이 좋습니다. YARN에서 **셔플 데이터의 정상 해제**가 활성화된 경우 셔플 데이터가 있는 축소를 위해 선택한 노드는 **해제** 상태가 되어 셔플 파일을 계속 제공합니다. YARN ResourceManager는 노드가 셔플 파일이 없음을 보고할 때까지 기다린 후 클러스터에서 노드를 제거합니다.
+ Amazon EMR 버전 6.11.0 이상 버전은 Tez 및 MapReduce 셔플 핸들러 모두에 대해 **Hive** 셔플 데이터에 대한 Yarn 기반 정상 해제를 지원합니다.
+ `yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data`를 `true`로 설정하여 셔플 데이터에 대한 정상적인 폐기를 활성화합니다.
+ Amazon EMR 버전 7.4.0 이상 버전은 외부 셔플 서비스가 활성화된 경우(EC2의 EMR에서 기본적으로 활성화됨) Spark 셔플 데이터에 대한 Yarn 기반 정상 해제를 지원합니다.
+ Spark 외부 셔플 서비스의 기본 동작은 Yarn에서 Spark를 실행할 때 Yarn NodeManager가 애플리케이션 종료 시 애플리케이션 셔플 파일을 제거하는 것입니다. 이는 노드 해제 속도 및 컴퓨팅 사용률에 영향을 미칠 수 있습니다. 장기 실행 애플리케이션의 경우 활성 셔플 데이터 없이 노드를 더 빠르게 폐기할 수 있도록, 더 이상 사용되지 않는 셔플 파일을 제거하려면 `spark.shuffle.service.removeShuffle`을 `true`로 설정하는 것이 좋습니다.
+ Amazon EMR 버전 7.4.0 이상에서 Spark 셔플 데이터 손실을 최소화하려면 다음 플래그를 설정하는 것이 좋습니다.
+ `yarn.nodemanager.shuffledata-monitor.interval-ms` 플래그(기본값 30,000ms) 또는 `spark.dynamicAllocation.executorIdleTimeout` (기본값 60초)가 기본값에서 변경된 경우 필요한 플래그를 업데이트`true`하여 조건이 `spark.dynamicAllocation.executorIdleTimeout > yarn.nodemanager.shuffledata-monitor.interval-ms` 유지되는지 확인합니다.
```
[
{
"Classification": "yarn-site",
"Properties": {
"yarn.resourcemanager.decommissioning-nodes-watcher.wait-for-shuffle-data": "true"
}
},
{
"Classification": "spark-defaults",
"Properties": {
"spark.dynamicAllocation.enabled": "true",
"spark.shuffle.service.removeShuffle": "true"
}
}
]
```
클러스터에 로드가 없는 경우 Amazon EMR은 이전 평가에서 새 인스턴스 추가를 취소하고 스케일 다운 작업을 수행합니다. 클러스터에 로드가 많은 경우 Amazon EMR은 인스턴스 제거를 취소하고 스케일 업 작업을 수행합니다.
## 노드 할당 고려 사항
스팟 재확보 시 HDFS 데이터 손실을 방지하려면 코어 노드에 대한 온디맨드 구매 옵션을 사용하는 것이 좋습니다. 태스크 노드에 대한 스팟 구매 옵션을 사용하면 태스크 노드에 스팟 인스턴스가 더 추가될 때 비용을 절감하고 작업 실행 속도를 높일 수 있습니다.
## 노드 할당 시나리오
최대, 최소, 온디맨드 제한 및 최대 코어 노드 파라미터를 다양한 조합으로 설정하여 필요에 따라 다양한 조정 시나리오를 만들 수 있습니다.
**시나리오 1: 코어 노드만 조정**
코어 노드만 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
+ 온디맨드 제한은 최대 경계와 같습니다.
+ 최대 코어 노드는 최대 경계와 같습니다.
온디맨드 제한과 최대 코어 노드 파라미터를 지정하지 않은 경우 두 파라미터 모두 기본적으로 최대 경계로 설정됩니다.
관리형 조정은 실행기 수요를 수용하기 위해 태스크 노드를 조정하므로 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 `CORE` 노드에서만 실행하도록 제한하는 경우 이 시나리오는 적용되지 않습니다.
다음 예제에서는 코어 노드만 조정하는 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**시나리오 2: 태스크 노드만 조정**
태스크 노드만 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
+ 최대 코어 노드는 최소 경계와 같아야 합니다.
다음 예제에서는 태스크 노드만 조정하는 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**시나리오 3: 클러스터의 온디맨드 인스턴스만**
온디맨드 인스턴스만 보유하려면 클러스터 및 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
+ 온디맨드 제한은 최대 경계와 같습니다.
온디맨드 제한이 지정되지 않은 경우 파라미터 값의 기본값은 최대 경계입니다. 기본값은 Amazon EMR이 온디맨드 인스턴스만 확장함을 나타냅니다.
최대 코어 노드가 최대 한도보다 작으면 최대 코어 노드 파라미터를 사용하여 코어 노드와 태스크 노드 사이에서 용량 할당을 분할할 수 있습니다.
인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 클러스터의 모든 노드 그룹이 초기 구성 시 온디맨드 시장 유형을 사용해야 합니다.
관리형 조정은 실행기 수요를 수용하기 위해 `Spot` 노드를 조정하므로 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 `ON_DEMAND` 노드에서만 실행하도록 제한하는 경우 이 시나리오는 적용되지 않습니다.
다음 예제에서는 전체 클러스터에 온디맨드 인스턴스가 있는 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**시나리오 4: 클러스터의 스팟 인스턴스만**
스팟 인스턴스만 보유하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
+ 온디맨드 제한은 0으로 설정됩니다.
최대 코어 노드가 최대 한도보다 작으면 최대 코어 노드 파라미터를 사용하여 코어 노드와 태스크 노드 사이에서 용량 할당을 분할할 수 있습니다.
인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 코어 인스턴스 그룹이 초기 구성 중에 스팟 구매 옵션을 사용해야 합니다. 태스크 인스턴스 그룹에 스팟 인스턴스가 없는 경우 Amazon EMR Managed Scaling은 필요할 때 스팟 인스턴스를 사용하여 태스크 그룹을 생성합니다.
관리형 조정은 애플리케이션 프로세스 수요를 수용하기 위해 `ON_DEMAND` 노드를 조정하므로 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 `ON_DEMAND` 노드에서만 실행하도록 제한하는 경우 이 시나리오는 적용되지 않습니다.
다음 예제에서는 전체 클러스터에 스팟 인스턴스가 있는 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**시나리오 5: 코어 노드의 온디맨드 인스턴스 및 태스크 노드의 스팟 인스턴스 조정**
코어 노드의 온디맨드 인스턴스와 태스크 노드의 스팟 인스턴스를 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
+ 온디맨드 제한은 최대 코어 노드와 같아야 합니다.
+ 온디맨드 제한과 최대 코어 노드 모두 최대 경계보다 작아야 합니다.
인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 코어 노드 그룹에서 온디맨드 구매 옵션을 사용해야 합니다.
이 시나리오는 노드 레이블과 함께 관리형 조정을 사용하고 `ON_DEMAND` 노드 또는 `CORE` 노드에서만 실행하도록 애플리케이션 프로세스를 제한하는 경우 적용되지 않습니다.
다음 예제에서는 코어 노드에서 온디맨드 인스턴스를 조정하고 태스크 노드에서 스팟 인스턴스를 조정하는 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**시나리오 6: 애플리케이션 프로세스 수요에 대해 `CORE` 인스턴스를 조정하고 실행기 수요에 대해 `TASK` 인스턴스를 조정합니다.**
이 시나리오는 노드 레이블과 함께 관리형 조정을 사용하고 `CORE` 노드에서만 실행하도록 애플리케이션 프로세스를 제한하는 경우에만 적용됩니다.
실행기 수요에 기반하여 `TASK` 노드를 조정하고 애플리케이션 프로세스 수요에 기반하여 `CORE` 노드를 조정하려면 클러스터 시작 시 다음 구성을 설정해야 합니다.
+ `yarn.node-labels.enabled:true`
+ `yarn.node-labels.am.default-node-label-expression: 'CORE'`
`ON_DEMAND` 제한과 최대 `CORE` 노드 파라미터를 지정하지 않은 경우 두 파라미터 모두 기본적으로 최대 경계로 설정됩니다.
최대 `ON_DEMAND` 노드가 최대 한도보다 작으면 관리형 조정은 최대 `ON_DEMAND` 노드 파라미터를 사용하여 `ON_DEMAND` 및 `SPOT` 노드 사이에서 용량 할당을 분할합니다. 최대 `CORE` 노드 파라미터를 최소 용량 파라미터 이하로 설정하면 `CORE` 노드는 최대 코어 용량에서 정적으로 유지됩니다.
다음 예제에서는 실행기 수요에 기반한 TASK 인스턴스 조정 및 애플리케이션 프로세스 수요에 기반한 CORE 인스턴스 조정 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
**시나리오 7: 애플리케이션 프로세스 수요에 대해 `ON_DEMAND` 인스턴스를 조정하고 실행기 수요에 대해 `SPOT` 인스턴스를 조정합니다.**
이 시나리오는 노드 레이블과 함께 관리형 조정을 사용하고 `ON_DEMAND` 노드에서만 실행하도록 애플리케이션 프로세스를 제한하는 경우에만 적용됩니다.
실행기 수요에 기반하여 `SPOT` 노드를 조정하고 애플리케이션 프로세스 수요에 기반하여 `ON_DEMAND` 노드를 조정하려면 클러스터 시작 시 다음 구성을 설정해야 합니다.
+ `yarn.node-labels.enabled:true`
+ `yarn.node-labels.am.default-node-label-expression: 'ON_DEMAND'`
`ON_DEMAND` 제한과 최대 `CORE` 노드 파라미터를 지정하지 않은 경우 두 파라미터 모두 기본적으로 최대 경계로 설정됩니다.
최대 `CORE` 노드가 최대 한도보다 작으면 관리형 조정은 최대 `CORE` 노드 파라미터를 사용하여 `CORE` 및 `TASK` 노드 사이에서 용량 할당을 분할합니다. 최대 `CORE` 노드 파라미터를 최소 용량 파라미터 이하로 설정하면 `CORE` 노드는 최대 코어 용량에서 정적으로 유지됩니다.
다음 예제에서는 실행기 수요에 기반한 스팟 인스턴스 조정 및 애플리케이션 프로세스 수요에 기반한 온디맨드 인스턴스 조정 시나리오를 보여줍니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-allocation-strategy.html)
# Amazon EMR에서 관리형 조정 지표 이해
클러스터에 Managed Scaling이 활성화된 경우 Amazon EMR은 1분 시간 단위로 데이터와 함께 고해상도 지표를 게시합니다. Amazon EMR 콘솔 또는 Amazon CloudWatch 콘솔을 사용하여 Managed Scaling에 의해 제어되는 모든 크기 조정 시작 및 완료에 대한 이벤트를 볼 수 있습니다. CloudWatch 지표는 Amazon EMR Managed Scaling을 작동하는 데 매우 중요한 역할을 합니다. CloudWatch 지표를 자세히 모니터링하여 데이터가 누락되지 않았는지 확인하는 것이 좋습니다. 누락된 지표를 감지하도록 CloudWatch 경보를 구성하는 방법에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요. Amazon EMR에서 CloudWatch 이벤트 사용에 대한 자세한 내용은 [CloudWatch 이벤트 모니터링](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html)을 참조하세요.
다음 지표는 클러스터의 현재 또는 대상 용량을 나타냅니다. 이러한 지표는 관리형 조정이 활성화된 경우에만 사용할 수 있습니다. 인스턴스 플릿으로 구성된 클러스터의 경우, 클러스터 용량 지표는 `Units`에서 측정됩니다. 인스턴스 그룹으로 구성된 클러스터의 경우, 클러스터 용량 지표는 관리형 조정 정책에 사용된 단위 유형을 기반으로 하는 `vCPU`에서 또는 `Nodes`에서 측정됩니다.
| 지표 | 설명 |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-metrics.html) | 관리형 조정에 의해 결정된 클러스터의 총 units/nodes/vCPU 대상 수입니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-metrics.html) | 실행 중인 클러스터에서 사용 가능한 현재 총unit/node/vCPU 수입니다. 클러스터 크기 조정이 요청되면 새 인스턴스가 클러스터에 추가되거나 클러스터에서 제거된 후 이 지표가 업데이트됩니다. Units: *Count* |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/managed-scaling-metrics.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/managed-scaling-metrics.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/managed-scaling-metrics.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/managed-scaling-metrics.html) | 클러스터에서 실행 중인 현재 TASK unit/node/vCPU 수입니다. Units: *Count* |
다음 지표는 클러스터 및 애플리케이션의 사용 상태를 나타냅니다. 이러한 지표는 모든 Amazon EMR 기능에 사용할 수 있으며 클러스터에 관리형 조정이 활성화된 경우 1분 시간 단위로 데이터와 함께 고해상도로 게시됩니다. 다음 지표를 이전 표의 클러스터 용량 지표와 상호 연관시켜 관리형 조정 결정을 파악할 수 있습니다.
| 지표 | 설명 |
| --- | --- |
| `AppsCompleted` | 완료 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| `AppsPending` | 대기 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| `AppsRunning` | 실행 상태로 YARN에게 제출된 애플리케이션 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ContainerAllocated | ResourceManager에서 할당된 리소스 컨테이너 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| `ContainerPending` | 대기열에서 아직 할당되지 않은 컨테이너 수 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| ContainerPendingRatio | 대기 중인 컨테이너와 할당된 컨테이너의 비율(ContainerPendingRatio = ContainerPending / ContainerAllocated). ContainerAllocated가 0이면 ContainerPendingRatio는 ContainerPending과 같습니다. ContainerPendingRatio 값은 비율이 아닌 숫자를 나타냅니다. 이 값은 컨테이너 할당 동작에 따라 클러스터 리소스를 조정하는 데 유용합니다. Units: *Count* |
| `HDFSUtilization` | 현재 사용 중인 HDFS 스토리지 비율 사용 사례: 클러스터 성능 분석 단위: *백분율* |
| `IsIdle` | 클러스터가 더 이상 작업을 실행하지 않지만 여전히 활성 상태로 요금이 발생하고 있다는 것을 나타냅니다. 아무런 작업도 실행되고 있지 않으면 1로 설정되고, 그 외에는 0으로 설정됩니다. 이 값은 5분 주기로 검사하며, 값이 1일 때는 클러스터가 검사 시에만 유휴 상태일 뿐 전체 5분간 유휴 상태라는 것을 의미하지는 않습니다. 오탐지를 방지하기 위해서는 이 값이 5분 주기의 연속 검사 1회를 넘어 1을 유지할 때 경보를 알려야 합니다. 예를 들어, 30분 이상 1을 유지하는 경우 이 값에 대한 경보를 제기할 수 있습니다. 사용 사례: 클러스터 성능 모니터링 단위: *부울* |
| `MemoryAvailableMB` | 할당 가능한 메모리 크기 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| `MRActiveNodes` | 현재 MapReduce 작업 또는 작업을 실행 중인 노드 수 YARN 지표 `mapred.resourcemanager.NoOfActiveNodes`와 동등합니다. 사용 사례: 클러스터 진행 상황 모니터링 Units: *Count* |
| `YARNMemoryAvailablePercentage` | YARN에 사용할 수 있는 잔여 메모리 비율(YARNMemoryAvailablePercentage = MemoryAvailableMB / MemoryTotalMB). 이 값은 YARN 메모리 사용량을 기준으로 클러스터 리소스를 조정하는 데 유용합니다. 단위: *백분율* |
다음 지표는 YARN 컨테이너 및 노드에서 사용하는 리소스에 대한 정보를 제공합니다. YARN 리소스 관리자의 이러한 지표는 클러스터에서 실행되는 컨테이너 및 노드에서 사용하는 리소스에 대한 인사이트를 제공합니다. 이러한 지표를 이전 테이블의 클러스터 용량 지표와 비교하면 관리형 규모 조정의 영향을 보다 명확하게 파악할 수 있습니다.
| 지표 | 연결된 릴리스 | 설명 |
| --- | --- | --- |
| `YarnContainersUsedMemoryGBSeconds` | 레이블 7.3.0 이상의 릴리스에 사용 가능 | 게시 기간 동안 사용된 컨테이너 메모리 \$1초입니다. **단위:**GB \$1 초 |
| `YarnContainersTotalMemoryGBSeconds` | 레이블 7.3.0 이상의 릴리스에 사용 가능 | 게시 기간의 총 yarn 컨테이너 \$1 초입니다. **단위:**GB \$1 초 |
| `YarnContainersUsedVCPUSeconds` | 레이블 7.5.0 이상의 릴리스에 사용 가능 | 게시 기간 동안 사용된 컨테이너 VCPU \$1 초입니다. **단위:** VCPU \$1 초 |
| `YarnContainersTotalVCPUSeconds` | 레이블 7.5.0 이상의 릴리스에 사용 가능 | 게시 기간의 총 컨테이너 VCPU \$1 초입니다. **단위:** VCPU \$1 초 |
| `YarnNodesUsedMemoryGBSeconds` | 레이블 7.5.0 이상의 릴리스에 사용 가능 | 게시 기간 중 사용된 노드 메모리 \$1초입니다. **단위:**GB \$1 초 |
| `YarnNodesTotalMemoryGBSeconds` | 레이블 7.5.0 이상의 릴리스에 사용 가능 | 게시 기간 중 총 노드 메모리 \$1 초입니다. **단위:**GB \$1 초 |
| `YarnNodesUsedVCPUSeconds` | 레이블 7.3.0 이상의 릴리스에 사용 가능 | 게시 기간 동안 사용된 노드 VCPU \$1 초입니다. **단위:** VCPU \$1 초 |
| `YarnNodesTotalVCPUSeconds` | 레이블 7.3.0 이상의 릴리스에 사용 가능 | 게시 기간의 총 노드 VCPU \$1 초입니다. **단위:** VCPU \$1 초 |
## Managed Scaling 지표 그래프 작성
다음 단계에서 보여주듯이, 지표를 그래프로 작성하여 클러스터의 워크로드 패턴과 Amazon EMR Managed Scaling에 의해 수행된 해당 조정 결정을 시각화할 수 있습니다.
**CloudWatch 콘솔에서 관리형 조정 지표 그래프를 작성하려면**
1. [CloudWatch 콘솔](https://console.aws.amazon.com/cloudwatch/)을 엽니다.
1. 탐색 창에서 **Amazon EMR**을 선택합니다. 모니터링할 클러스터의 클러스터 ID를 검색할 수 있습니다.
1. 그래프 처리할 지표로 스크롤합니다. 그래프를 표시할 측정치를 엽니다.
1. 하나 이상의 지표를 그래프 처리하려면 각 지표 옆에 있는 확인란을 선택합니다.
다음 예제는 클러스터의 Amazon EMR Managed Scaling 활동을 보여줍니다. 그래프는 3개의 자동 축소 기간을 보여줍니다. 여기서 활성 워크로드가 적은 경우 비용을 절감할 수 있습니다.
![\[관리형 조정 지표 그래프\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/Managed_Scaling_Decision.png)
모든 클러스터 용량 및 사용량 지표는 1분 간격으로 게시됩니다. 또한 추가 통계 정보는 각 1분 데이터와 연관되어 `Percentiles`, `Min`, `Max`, `Sum`, `Average`, `SampleCount` 등의 다양한 함수를 표시할 수 있습니다.
예를 들어, 다음 그래프는 `YARNMemoryAvailablePercentage`, `Sum`, `Average`, `Min`와 함께 서로 다른 백분위수 P10, P50, P90, P99에서 동일한 `SampleCount` 지표를 표시합니다.
![\[다른 백분위수를 사용하는 관리형 조정 지표 그래프 작성\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/Managed_Scaling_Metrics.png)
# Amazon EMR의 인스턴스 그룹에서 사용자 지정 정책과 함께 자동 조정 사용
Amazon EMR 릴리스 4.0 이상에서 사용자 지정 정책을 사용하는 자동 조정을 사용하면 *조정 정책*에서 지정한 CloudWatch 지표 및 기타 파라미터를 기반으로 코어 노드와 태스크 노드를 프로그래밍 방식으로 스케일 아웃 및 스케일 인할 수 있습니다. 사용자 지정 정책이 포함된 자동 조정은 인스턴스 그룹 구성에서 사용 가능하며, 인스턴스 플릿에는 사용할 수 없습니다. 인스턴스 그룹과 인스턴스 플릿에 대한 자세한 내용은 [인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성](emr-instance-group-configuration.md) 섹션을 참조하세요.
**참고**
Amazon EMR에서 사용자 지정 정책 기능과 함께 자동 조정을 사용하려면 클러스터를 생성할 때 `VisibleToAllUsers` 파라미터에 `true`를 설정해야 합니다. 자세한 내용은 [SetVisibleToAllUsers](https://docs.aws.amazon.com/emr/latest/APIReference/API_SetVisibleToAllUsers.html)를 참조하세요.
확장 정책은 인스턴스 그룹 구성의 일부입니다. 인스턴스 그룹의 초기 구성 중에 또는 해당 인스턴스 그룹이 활성화되어 있어도 기존 클러스터의 인스턴스 그룹을 수정하여 정책을 지정할 수 있습니다. 프라이머리 인스턴스 그룹을 제외하고 클러스터의 각 인스턴스 그룹에는 스케일 아웃 및 스케일 인 규칙으로 구성된 자체 조정 정책이 있을 수 있습니다. 확장 및 축소 규칙은 각 규칙마다 다른 파라미터를 사용하여 개별적으로 구성할 수 있습니다.
AWS Management Console AWS CLI, 또는 Amazon EMR API를 사용하여 조정 정책을 구성할 수 있습니다. AWS CLI 또는 Amazon EMR API를 사용하는 경우 조정 정책을 JSON 형식으로 지정합니다. 또한 AWS CLI 또는 Amazon EMR API를 사용하는 경우 사용자 지정 CloudWatch 지표를 지정할 수 있습니다. AWS Management Console을 사용하여 선택하는 경우에는 사용자 지정 지표를 사용할 수 없습니다. 처음 콘솔을 사용하여 확장 정책을 만들면 많은 애플리케이션에 적합한 기본 정책이 미리 구성되어 있어서 시작하는 데 도움이 됩니다. 기본 규칙을 삭제 또는 수정할 수 있습니다.
자동 조정을 사용하여 EMR 클러스터 용량을 즉각 조정할 수는 있지만 기본 워크로드 요구 사항을 고려하고 노드 및 인스턴스 그룹 구성을 계획해야 합니다. 자세한 내용은 [클러스터 구성 지침](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-instances-guidelines.html)을 참조하세요.
**참고**
대부분의 워크로드에서 리소스 활용을 최적화하려면 확장 및 축소 규칙을 모두 설정하는 것이 바람직합니다. 다른 규칙 없이 어느 한 규칙만 설정하면 조정 활동 후에 인스턴스 수를 수동으로 조정해야 합니다. 즉, 이 경우 수동 재설정을 사용하여 "단방향" 자동 확장 또는 축소 정책을 설정합니다.
## 자동 조정에 대한 IAM 역할 생성
Amazon EMR의 자동 조정에서는 조정 활동이 트리거될 때 인스턴스를 추가 및 종료할 수 있는 권한을 가진 IAM 역할이 필요합니다. 적절한 역할 정책 및 신뢰 정책으로 구성된 기본 역할인 `EMR_AutoScaling_DefaultRole`을 이 용도로 사용할 수 있습니다. 를 사용하여 조정 정책이 있는 클러스터를 처음 생성하면 AWS Management Console Amazon EMR은 기본 역할을 생성하고 권한에 대한 기본 관리형 정책인를 연결합니다`AmazonElasticMapReduceforAutoScalingRole`.
를 사용하여 자동 조정 정책을 사용하여 클러스터를 생성할 때는 먼저 기본 IAM 역할이 있는지 또는 적절한 권한을 제공하는 정책이 연결된 사용자 지정 IAM 역할이 있는지 확인해야 AWS CLI합니다. 기본 역할을 생성하기 위해 클러스터를 생성하기 전에 `create-default-roles` 명령을 실행할 수 있습니다. 그런 다음, 클러스터를 생성할 때 `--auto-scaling-role EMR_AutoScaling_DefaultRole` 옵션을 지정할 수 있습니다. 또는 사용자 지정 자동 조정 역할을 생성한 다음, 클러스터를 생성할 때 이를 지정할 수 있습니다(예를 들면 `--auto-scaling-role MyEMRAutoScalingRole`). Amazon EMR의 사용자 지정 자동 조정 역할을 생성하는 경우에는 관리형 정책을 토대로 사용자 지정 역할에 대한 권한 정책을 수립하는 것이 좋습니다. 자세한 내용은 [서비스 및 리소스에 대한 Amazon EMR 권한에 대한 IAM AWS 서비스 역할 구성](emr-iam-roles.md) 단원을 참조하십시오.
## 자동 조정 규칙 이해
확장 규칙에서 인스턴스 그룹에 대한 조정 활동을 트리거할 경우 규칙에 따라 Amazon EC2 인스턴스가 인스턴스 그룹에 추가됩니다. Amazon EC2 인스턴스가 `InService` 상태가 되자마자 Apache Spark, Apache Hive 및 Presto 같은 애플리케이션에서 새 노드를 사용할 수 있습니다. 인스턴스를 종료하고 노드를 제거하는 축소 규칙도 설정할 수 있습니다. 자동으로 조정되는 Amazon EC2 인스턴스의 수명 주기에 대한 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*에서 [Auto Scaling lifecycle](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroupLifecycle.html)을 참조하세요.
클러스터가 Amazon EC2 인스턴스를 종료하는 방법을 구성할 수 있습니다. 결제를 위해 또는 작업 완료 시 Amazon EC2 인스턴스 시간 경계에서 종료하도록 선택할 수 있습니다. 이 설정은 자동 조정 및 수동 크기 조정 조작에 모두 적용됩니다. 이 구성에 대한 자세한 정보는 [Amazon EMR 클러스터에 대한 클러스터 스케일 다운 옵션](emr-scaledown-behavior.md) 섹션을 참조하세요.
정책의 각 규칙에 대한 다음 파라미터가 Auto Scaling 동작을 결정합니다.
**참고**
여기에 나열된 파라미터는 Amazon EMR AWS Management Console 용를 기반으로 합니다. AWS CLI 또는 Amazon EMR API를 사용하는 경우 추가 고급 구성 옵션을 사용할 수 있습니다. 고급 옵션에 대한 자세한 내용은 *Amazon EMR API 참조*에서 [SimpleScalingPolicyConfiguration](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)을 참조하세요.
+ Maximum instances 및 Minimum instances. **최대 인스턴스** 제약은 인스턴스 그룹에 있을 수 있는 Amazon EC2 인스턴스의 최대 수를 지정하며 모든 스케일 아웃 규칙에 적용됩니다. 마찬가지로, **최소 인스턴스** 제약은 인스턴스 그룹에 있을 수 있는 Amazon EC2 인스턴스의 최소 수를 지정하며 모든 스케일 인 규칙에 적용됩니다.
+ **규칙 이름**은 정책 내에서 고유해야 합니다.
+ **scaling adjustment(조정 조절)**는 규칙에서 트리거한 조정 활동 중에 추가(확장 규칙의 경우) 또는 종료(축소 규칙의 경우)할 EC2 인스턴스 수를 결정합니다.
+ **CloudWatch 지표**는 경보 조건을 감시합니다.
+ **comparison operator(비교 연산자)**는 CloudWatch 지표를 **임계값**과 비교하고 트리거 조건을 결정하는 데 사용됩니다.
+ **evaluation period(평가 기간)**는 5분씩 증가하고, 조정 활동이 트리거되기 전에 이 기간의 CloudWatch 지표가 트리거 조건에 있어야 합니다.
+ [**Cooldown period**]는 조정 활동을 트리거하는 규칙에 상관없이 규칙에서 시작한 조정 활동과 다음 조정 활동 시작 사이에 경과해야 할 기간(초 단위)을 결정합니다. 인스턴스 그룹이 조정 활동을 끝내고 조정 후 상태에 도달하면 후속 조정 활동을 트리거할 수 있는 CloudWatch 지표가 안정화될 수 있는 기회를 휴지 기간에서 제공합니다. 자세한 내용은 *Amazon EC2 Auto Scaling 사용 설명서*에서 [Auto Scaling cooldowns](https://docs.aws.amazon.com/autoscaling/ec2/userguide/Cooldown.html)를 참조하세요.
![\[AWS Management Console Amazon EMR에 대한 자동 조정 규칙 파라미터입니다.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/auto-scaling-rule-params.png)
## 고려 사항 및 제한 사항
+ Amazon CloudWatch 지표는 Amazon EMR 자동 조정을 작동하는 데 매우 중요한 역할을 합니다. Amazon CloudWatch 지표를 자세히 모니터링하여 데이터가 누락되지 않았는지 확인하는 것이 좋습니다. 누락된 지표를 감지하도록 Amazon CloudWatch 경보를 구성하는 방법에 대한 자세한 내용은 [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)을 참조하세요.
+ EBS 볼륨을 과도하게 사용하면 Managed Scaling 문제가 발생할 수 있습니다. EBS 볼륨 사용량을 자세히 모니터링하여 EBS 볼륨 사용률이 90% 미만인지 확인하는 것이 좋습니다. 추가 EBS 볼륨 지정에 대한 자세한 내용은 [인스턴스 스토리지](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-storage.html)를 참조하세요.
+ Amazon EMR 릴리스 5.18\$15.28에서 사용자 지정 정책을 사용한 자동 조정을 사용하면 Amazon CloudWatch 지표에서 간헐적으로 누락된 데이터로 인해 조정에 실패할 수 있습니다. 자동 조정을 개선하려면 최신 Amazon EMR 버전을 사용하는 것이 좋습니다. 5.18\$15.28 사이의 Amazon EMR 릴리스를 사용해야 하는 경우에도 [AWS Support](https://aws.amazon.com/premiumsupport/)에 문의하여 패치를 요청할 수 있습니다.
## AWS Management Console 를 사용하여 자동 조정 구성
클러스터를 생성할 때 고급 클러스터 구성 옵션을 사용하여 인스턴스 그룹에 대한 조정 정책을 구성합니다. 또한 기존 클러스터의 **Hardware(하드웨어)** 설정에서 인스턴스 그룹을 수정하여 서비스 중인 인스턴스 그룹에 대한 조정 정책을 생성하거나 수정할 수 있습니다.
1. 새 Amazon EMR 콘솔로 이동하고 측면 탐색에서 **이전 콘솔로 전환**을 선택합니다. 이전 콘솔로 전환할 때 예상되는 사항에 대한 자세한 내용은 [이전 콘솔 사용](https://docs.aws.amazon.com/emr/latest/ManagementGuide/whats-new-in-console.html#console-opt-in)을 참조하세요.
1. Amazon EMR 콘솔에서 클러스터를 생성하는 경우 **클러스터 생성**을 선택하고 **고급 옵션으로 이동**을 선택한 후 **1단계: 소프트웨어 및 단계**에 대한 옵션을 선택하고 **2단계: 하드웨어 구성**으로 이동합니다.
** 또는 **
실행 중인 클러스터의 인스턴스 그룹을 수정할 경우 클러스터 목록에서 클러스터를 선택한 다음 **Hardware(하드웨어)** 섹션을 확장합니다.
1. **클러스터 크기 조정 및 프로비저닝 옵션** 섹션에서 **클러스터 크기 조정 활성화**를 선택합니다. 그런 다음 **Create a custom automatic scaling policy(사용자 지정 자동 조정 정책 생성)**를 선택합니다.
**Custom automatic scaling policies(사용자 지정 자동 조정 정책)** 표에서, 구성할 인스턴스 그룹의 행에 나타나는 연필 아이콘을 클릭합니다. Auto Scaling 규칙 화면이 열립니다.
1. 확장 후 인스턴스 그룹에 포함할 **최대 인스턴스**를 입력하고, 축소 후 인스턴스 그룹에 포함할 **최소 인스턴스**를 입력합니다.
1. 규칙 파라미터를 편집하려면 연필을 클릭하고, 정책에서 규칙을 제거하려면 **X**를 클릭하며, 규칙을 추가하려면 **Add rule(규칙 추가)**을 클릭합니다.
1. 이 주제의 앞부분에서 설명한 대로 규칙 파라미터를 선택합니다. Amazon EMR에서 사용할 수 있는 CloudWatch 지표에 대한 설명은 *Amazon CloudWatch 사용 설명서*에서 [Amazon EMR 지표 및 차원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/emr-metricscollected.html)을 참조하세요.
## AWS CLI 를 사용하여 자동 조정 구성
클러스터를 생성할 때와 인스턴스 그룹을 생성할 때 Amazon EMR용 AWS CLI 명령을 사용하여 자동 조정을 구성할 수 있습니다. 관련 명령 내에서 JSON 구성 인라인을 지정하는 간편 구문을 사용하거나 구성 JSON을 포함하는 파일을 참조할 수 있습니다. 기존 인스턴스 그룹에 자동 조정 정책을 적용하고 이전에 적용한 자동 조정 정책을 제거할 수도 있습니다. 또한 실행 중인 클러스터에서 확장 정책 구성의 세부 정보를 검색할 수 있습니다.
**중요**
자동 조정 정책을 가진 클러스터를 생성할 때는 `--auto-scaling-role MyAutoScalingRole` 명령을 사용하여 자동 조정을 위한 IAM 역할을 지정해야 합니다. 기본 역할은 `EMR_AutoScaling_DefaultRole`이고 `create-default-roles` 명령을 통해 생성이 가능합니다. 이 역할은 클러스터를 만들 때만 추가할 수 있으며 기존 클러스터에 추가할 수 없습니다.
자동 조정 정책을 구성할 때 사용할 수 있는 파라미터에 대한 자세한 설명은 *Amazon EMR API 참조*에서 [PutAutoScalingPolicy](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_PutAutoScalingPolicy.html)를 참조하세요.
### 인스턴스 그룹에 적용된 자동 조정 정책을 사용하여 클러스터 생성
`aws emr create-cluster` 명령의 `--instance-groups` 옵션 내에서 자동 조정 구성을 지정할 수 있습니다. 다음 예제에서는 코어 인스턴스 그룹에 대한 자동 조정 정책이 인라인으로 제공되는 create-cluster 명령을 보여줍니다. 명령은 Amazon EMR AWS Management Console 용를 사용하여 자동 조정 정책을 생성할 때 나타나는 기본 스케일 아웃 정책과 동등한 조정 구성을 생성합니다. 간략하게 하기 위해 축소 정책은 표시되지 않습니다. 축소 규칙 없이 확장 규칙을 생성하는 것은 권장되지 않습니다.
```
aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --auto-scaling-role EMR_AutoScaling_DefaultRole --instance-groups Name=MyMasterIG,InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1 'Name=MyCoreIG,InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=2,AutoScalingPolicy={Constraints={MinCapacity=2,MaxCapacity=10},Rules=[{Name=Default-scale-out,Description=Replicates the default scale-out rule in the console.,Action={SimpleScalingPolicyConfiguration={AdjustmentType=CHANGE_IN_CAPACITY,ScalingAdjustment=1,CoolDown=300}},Trigger={CloudWatchAlarmDefinition={ComparisonOperator=LESS_THAN,EvaluationPeriods=1,MetricName=YARNMemoryAvailablePercentage,Namespace=AWS/ElasticMapReduce,Period=300,Statistic=AVERAGE,Threshold=15,Unit=PERCENT,Dimensions=[{Key=JobFlowId,Value="${emr.clusterId}"}]}}}]}'
```
다음 명령은 명령줄을 사용하여 인스턴스 그룹 구성 파일(`instancegroupconfig.json`)의 일부로 자동 조정 정책 정의를 제공하는 방법을 보여줍니다.
```
aws emr create-cluster --release-label emr-5.2.0 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --instance-groups file://your/path/to/instancegroupconfig.json --auto-scaling-role EMR_AutoScaling_DefaultRole
```
구성 파일의 내용은 다음과 같습니다.
```
[
{
"InstanceCount": 1,
"Name": "MyMasterIG",
"InstanceGroupType": "MASTER",
"InstanceType": "m5.xlarge"
},
{
"InstanceCount": 2,
"Name": "MyCoreIG",
"InstanceGroupType": "CORE",
"InstanceType": "m5.xlarge",
"AutoScalingPolicy":
{
"Constraints":
{
"MinCapacity": 2,
"MaxCapacity": 10
},
"Rules":
[
{
"Name": "Default-scale-out",
"Description": "Replicates the default scale-out rule in the console for YARN memory.",
"Action":{
"SimpleScalingPolicyConfiguration":{
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": 1,
"CoolDown": 300
}
},
"Trigger":{
"CloudWatchAlarmDefinition":{
"ComparisonOperator": "LESS_THAN",
"EvaluationPeriods": 1,
"MetricName": "YARNMemoryAvailablePercentage",
"Namespace": "AWS/ElasticMapReduce",
"Period": 300,
"Threshold": 15,
"Statistic": "AVERAGE",
"Unit": "PERCENT",
"Dimensions":[
{
"Key" : "JobFlowId",
"Value" : "${emr.clusterId}"
}
]
}
}
}
]
}
}
]
```
### 자동 조정 정책이 있는 인스턴스 그룹을 클러스터에 추가
`--instance-groups`를 사용할 때와 같은 방법으로 `add-instance-groups` 명령과 함께 `create-cluster` 옵션을 사용하여 조정 정책 구성을 지정할 수 있습니다. 다음 예제에서는 JSON 파일 `instancegroupconfig.json`에 대한 참조를 인스턴스 그룹 구성과 함께 사용합니다.
```
aws emr add-instance-groups --cluster-id j-1EKZ3TYEVF1S2 --instance-groups file://your/path/to/instancegroupconfig.json
```
### 기존 인스턴스 그룹에 자동 조정 정책 적용 또는 적용된 정책 수정
`aws emr put-auto-scaling-policy` 명령을 사용하여 자동 조정 정책을 기존 인스턴스 그룹에 적용합니다. 인스턴스 그룹은 자동 조정 IAM 역할을 사용하는 클러스터의 일부여야 합니다. 다음 예제에서는 자동 조정 정책 구성을 지정하는 JSON 파일 `autoscaleconfig.json`에 대한 참조를 사용합니다.
```
aws emr put-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07 --auto-scaling-policy file://your/path/to/autoscaleconfig.json
```
이전 예제에 표시된 것과 동일한 확장 규칙을 정의하는 `autoscaleconfig.json` 파일의 내용이 아래에 표시됩니다.
```
{
"Constraints": {
"MaxCapacity": 10,
"MinCapacity": 2
},
"Rules": [{
"Action": {
"SimpleScalingPolicyConfiguration": {
"AdjustmentType": "CHANGE_IN_CAPACITY",
"CoolDown": 300,
"ScalingAdjustment": 1
}
},
"Description": "Replicates the default scale-out rule in the console for YARN memory",
"Name": "Default-scale-out",
"Trigger": {
"CloudWatchAlarmDefinition": {
"ComparisonOperator": "LESS_THAN",
"Dimensions": [{
"Key": "JobFlowId",
"Value": "${emr.clusterID}"
}],
"EvaluationPeriods": 1,
"MetricName": "YARNMemoryAvailablePercentage",
"Namespace": "AWS/ElasticMapReduce",
"Period": 300,
"Statistic": "AVERAGE",
"Threshold": 15,
"Unit": "PERCENT"
}
}
}]
}
```
### 인스턴스 그룹에서 자동 조정 정책 제거
```
aws emr remove-auto-scaling-policy --cluster-id j-1EKZ3TYEVF1S2 --instance-group-id ig-3PLUZBA6WLS07
```
### 자동 조정 정책 구성 검색
`describe-cluster` 명령은 InstanceGroup 블록의 정책 구성을 검색합니다. 예를 들어, 다음 명령은 클러스터 ID `j-1CWOHP4PI30VJ`의 클러스터에 대한 구성을 검색합니다.
```
aws emr describe-cluster --cluster-id j-1CWOHP4PI30VJ
```
다음과 같은 예제 출력이 생성됩니다.
```
{
"Cluster": {
"Configurations": [],
"Id": "j-1CWOHP4PI30VJ",
"NormalizedInstanceHours": 48,
"Name": "Auto Scaling Cluster",
"ReleaseLabel": "emr-5.2.0",
"ServiceRole": "EMR_DefaultRole",
"AutoTerminate": false,
"TerminationProtected": true,
"MasterPublicDnsName": "ec2-54-167-31-38.compute-1.amazonaws.com",
"LogUri": "s3n://aws-logs-232939870606-us-east-1/elasticmapreduce/",
"Ec2InstanceAttributes": {
"Ec2KeyName": "performance",
"AdditionalMasterSecurityGroups": [],
"AdditionalSlaveSecurityGroups": [],
"EmrManagedSlaveSecurityGroup": "sg-09fc9362",
"Ec2AvailabilityZone": "us-east-1d",
"EmrManagedMasterSecurityGroup": "sg-0bfc9360",
"IamInstanceProfile": "EMR_EC2_DefaultRole"
},
"Applications": [
{
"Name": "Hadoop",
"Version": "2.7.3"
}
],
"InstanceGroups": [
{
"AutoScalingPolicy": {
"Status": {
"State": "ATTACHED",
"StateChangeReason": {
"Message": ""
}
},
"Constraints": {
"MaxCapacity": 10,
"MinCapacity": 2
},
"Rules": [
{
"Name": "Default-scale-out",
"Trigger": {
"CloudWatchAlarmDefinition": {
"MetricName": "YARNMemoryAvailablePercentage",
"Unit": "PERCENT",
"Namespace": "AWS/ElasticMapReduce",
"Threshold": 15,
"Dimensions": [
{
"Key": "JobFlowId",
"Value": "j-1CWOHP4PI30VJ"
}
],
"EvaluationPeriods": 1,
"Period": 300,
"ComparisonOperator": "LESS_THAN",
"Statistic": "AVERAGE"
}
},
"Description": "",
"Action": {
"SimpleScalingPolicyConfiguration": {
"CoolDown": 300,
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": 1
}
}
},
{
"Name": "Default-scale-in",
"Trigger": {
"CloudWatchAlarmDefinition": {
"MetricName": "YARNMemoryAvailablePercentage",
"Unit": "PERCENT",
"Namespace": "AWS/ElasticMapReduce",
"Threshold": 75,
"Dimensions": [
{
"Key": "JobFlowId",
"Value": "j-1CWOHP4PI30VJ"
}
],
"EvaluationPeriods": 1,
"Period": 300,
"ComparisonOperator": "GREATER_THAN",
"Statistic": "AVERAGE"
}
},
"Description": "",
"Action": {
"SimpleScalingPolicyConfiguration": {
"CoolDown": 300,
"AdjustmentType": "CHANGE_IN_CAPACITY",
"ScalingAdjustment": -1
}
}
}
]
},
"Configurations": [],
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"Name": "Core - 2",
"ShrinkPolicy": {},
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.342,
"ReadyDateTime": 1479413864.615
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"RunningInstanceCount": 2,
"Id": "ig-3M16XBE8C3PH1",
"InstanceGroupType": "CORE",
"RequestedInstanceCount": 2,
"EbsBlockDevices": []
},
{
"Configurations": [],
"Id": "ig-OP62I28NSE8M",
"InstanceGroupType": "MASTER",
"InstanceType": "m5.xlarge",
"Market": "ON_DEMAND",
"Name": "Master - 1",
"ShrinkPolicy": {},
"EbsBlockDevices": [],
"RequestedInstanceCount": 1,
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.342,
"ReadyDateTime": 1479413752.088
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"RunningInstanceCount": 1
}
],
"AutoScalingRole": "EMR_AutoScaling_DefaultRole",
"Tags": [],
"BootstrapActions": [],
"Status": {
"Timeline": {
"CreationDateTime": 1479413437.339,
"ReadyDateTime": 1479413863.666
},
"State": "WAITING",
"StateChangeReason": {
"Message": "Cluster ready after last step completed."
}
}
}
}
```
# 실행 중인 Amazon EMR 클러스터 크기 수동 조정
AWS Management Console AWS CLI또는 Amazon EMR API를 사용하여 실행 중인 클러스터의 코어 및 태스크 인스턴스 그룹과 인스턴스 플릿에서 인스턴스를 추가하고 제거할 수 있습니다. 클러스터에서 인스턴스 그룹을 사용하는 경우, 인스턴스 개수를 명시적으로 변경해 줍니다. 인스턴스 플릿을 사용하는 클러스터라면 온디맨드 인스턴스 및 스팟 인스턴스의 대상 유닛을 변경할 수 있습니다. 그러면 인스턴스 플릿이 새 대상에 맞춰 인스턴스를 추가하거나 제거합니다. 자세한 내용은 [인스턴스 플릿 옵션](emr-instance-fleet.md#emr-instance-fleet-options) 단원을 참조하십시오. 애플리케이션은 새로 프로비저닝된 Amazon EC2 인스턴스가 사용 가능해지는 즉시 해당 인스턴스로 노드를 호스팅할 수 있습니다. 인스턴스가 제거되면 Amazon EMR은 작업이 중단되지 않고 데이터 손실이 방지되는 방식으로 작업을 종료합니다. 자세한 내용은 [작업 완료 시 종료](emr-scaledown-behavior.md#emr-scaledown-terminate-task) 단원을 참조하십시오.
## 콘솔을 사용하여 클러스터 크기 조정
Amazon EMR 콘솔을 사용하여 실행 중인 클러스터의 크기를 조정할 수 있습니다.
------
#### [ 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. 기존 인스턴스 그룹의 크기를 조정하려면 크기를 조정하려는 코어 또는 태스크 인스턴스 그룹 옆의 라디오 버튼을 선택한 다음, **인스턴스 그룹 크기 조정**을 선택합니다. 인스턴스 그룹의 새 인스턴스 수를 지정하고 **크기 조정**을 선택합니다.
**참고**
실행 중인 인스턴스 그룹의 크기를 줄이는 경우 Amazon EMR은 데이터 손실을 최소화하기 위해 그룹에서 제거할 인스턴스를 지능적으로 선택합니다. 크기 조정 작업을 보다 세밀하게 제어하기 위해 인스턴스 그룹의 **ID**를 선택하고 제거하려는 인스턴스를 선택한 다음, **종료** 옵션을 사용할 수 있습니다. 지능형 스케일 다운 동작에 대한 자세한 내용은 [Amazon EMR 클러스터에 대한 클러스터 스케일 다운 옵션](emr-scaledown-behavior.md) 섹션을 참조하세요.
1. 크기 조정 작업을 취소하려면 **크기 조정 중** 상태인 인스턴스 그룹의 라디오 버튼을 선택한 다음, 목록의 작업에서 **크기 조정 중지**를 선택하면 됩니다.
1. 워크로드 증가에 대응하여 클러스터에 하나 이상의 태스크 인스턴스 그룹을 추가하려면 목록의 작업에서 **태스크 인스턴스 그룹 추가**를 선택합니다. Amazon EC2 인스턴스 유형을 선택하고 태스크 그룹의 인스턴스 수를 입력한 다음, **태스크 인스턴스 그룹 추가**를 선택하여 클러스터의 **인스턴스 그룹** 패널로 돌아갑니다.
------
노드 수를 변경하면 인스턴스 그룹의 **상태**가 업데이트됩니다. 요청한 변경이 완료되면 **상태**가 **실행 중**이 됩니다.
## 를 사용하여 클러스터 크기 조정 AWS CLI
AWS CLI 를 사용하여 실행 중인 클러스터의 크기를 조정할 수 있습니다. 작업 노드 수를 늘리거나 줄일 수 있고, 실행 중인 클러스터의 코어 노드 수를 늘릴 수 있습니다. AWS CLI 또는 API를 사용하여 코어 인스턴스 그룹의 인스턴스를 종료할 수도 있습니다. 이 작업은 각별히 주의하여 수행해야 합니다. 코어 인스턴스 그룹에서 인스턴스를 종료하면 데이터가 손실될 위험이 있으며, 인스턴스가 자동으로 대체되지 않기 때문입니다.
코어 및 태스크 그룹의 크기를 조정하는 것 외에도 AWS CLI를 사용하여 하나 이상의 태스크 인스턴스 그룹을 실행 중인 클러스터에 추가할 수도 있습니다.
**를 사용하여 인스턴스 수를 변경하여 클러스터 크기를 조정하려면 AWS CLI**
코어 그룹 또는 작업 그룹에 인스턴스를 추가하고 `InstanceCount` 파라미터를 사용하여 하위 명령을 사용하여 작업 그룹에서 인스턴스를 AWS CLI `modify-instance-groups` 제거할 수 있습니다. 코어 또는 작업 그룹에 인스턴스를 추가하려면 `InstanceCount`를 늘리세요. 작업 그룹에서 인스턴스 수를 줄이려면 `InstanceCount`를 줄이세요. 작업 그룹의 인스턴스 수를 0으로 변경하면 모든 인스턴스를 제거하지만 인스턴스 그룹은 제거하지 않습니다.
+ 작업 인스턴스 그룹의 인스턴스 수를 3에서 4로 늘리려면 다음 명령을 입력하고 *ig-31JXXXXXXBTO*를 인스턴스 그룹 ID로 바꿉니다.
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-31JXXXXXXBTO,InstanceCount=4
```
`InstanceGroupId`를 검색하려면 `describe-cluster` 하위 명령을 사용하세요. 출력은 각 인스턴스 그룹의 ID를 포함하는 `Cluster`라는 JSON 객체입니다. 이 명령을 사용하려면 클러스터 ID(`aws emr list-clusters` 명령 또는 콘솔을 사용하여 검색할 수 있음)가 필요합니다. 인스턴스 그룹 ID를 검색하려면 다음 명령을 입력하고 *j-2AXXXXXXGAPLF*를 클러스터 ID로 바꿉니다.
```
aws emr describe-cluster --cluster-id j-2AXXXXXXGAPLF
```
를 사용하면 `--modify-instance-groups` 하위 명령을 사용하여 코어 인스턴스 그룹의 인스턴스를 종료 AWS CLI할 수도 있습니다.
**주의**
`EC2InstanceIdsToTerminate`는 주의해서 지정해야 합니다. 인스턴스는 실행 중인 애플리케이션의 상태에 관계없이 즉시 종료되며 인스턴스는 자동으로 대체되지 않습니다. 이는 클러스터의 **축소 동작** 구성에 관계없이 적용됩니다. 이 방법으로 인스턴스를 종료하면 데이터 손실과 예기치 않은 클러스터 동작이 발생할 위험이 있습니다.
특정 인스턴스를 종료하려면 인스턴스 그룹 ID(`aws emr describe-cluster --cluster-id` 하위 명령에 의해 반환됨) 및 인스턴스 ID(`aws emr list-instances --cluster-id` 하위 명령에 의해 반환됨)가 있어야 하며, 다음 명령을 입력해야 합니다. 그리고 *ig-6RXXXXXX07SA*를 인스턴스 그룹 ID로 바꾸고 *i-f9XXXXf2*를 인스턴스 ID로 바꾸어야 합니다.
```
1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-6RXXXXXX07SA,EC2InstanceIdsToTerminate=i-f9XXXXf2
```
에서 Amazon EMR 명령을 사용하는 방법에 대한 자세한 내용은 섹션을 AWS CLI참조하세요[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr).
**를 사용하여 태스크 인스턴스 그룹을 추가하여 클러스터의 크기를 조정하려면 AWS CLI**
를 사용하면 `--add-instance-groups` 하위 명령을 사용하여 1\$148개의 태스크 인스턴스 그룹을 클러스터에 AWS CLI추가할 수 있습니다. 태스크 인스턴스 그룹은 프라이머리 인스턴스 그룹 및 코어 인스턴스 그룹을 포함하는 클러스터에만 추가할 수 있습니다. 를 사용할 때 `--add-instance-groups` 하위 명령을 사용할 때마다 최대 5개의 태스크 인스턴스 그룹을 추가할 AWS CLI수 있습니다.
1. 단일 작업 인스턴스 그룹을 클러스터에 추가하려면 다음 명령을 입력하고 *j-JXBXXXXXX37R*을 클러스터 ID로 바꿉니다.
```
1. aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge
```
1. 여러 작업 인스턴스 그룹을 클러스터에 추가하려면 다음 명령을 입력하고 *j-JXBXXXXXX37R*을 클러스터 ID로 바꿉니다. 단일 명령으로 최대 5개의 작업 인스턴스 그룹을 추가할 수 있습니다.
```
aws emr add-instance-groups --cluster-id j-JXBXXXXXX37R --instance-groups InstanceCount=6,InstanceGroupType=task,InstanceType=m5.xlarge InstanceCount=10,InstanceGroupType=task,InstanceType=m5.xlarge
```
에서 Amazon EMR 명령을 사용하는 방법에 대한 자세한 내용은 섹션을 AWS CLI참조하세요[https://docs.aws.amazon.com/cli/latest/reference/emr](https://docs.aws.amazon.com/cli/latest/reference/emr).
## 크기 조정 중단
Amazon EMR 4.1.0 이상 버전을 사용하면 기존 크기 조정 작업 중에 크기 조정을 실행할 수 있습니다. 또한 이전에 제출한 크기 조정 요청을 중지하거나 이전 요청이 완료될 때까지 기다리지 않고 이전 요청을 재정의하는 새 요청을 제출할 수 있습니다. 콘솔의 기존 크기 조정을 중지하거나 `ModifyInstanceGroups` API 직접 호출을 사용하여 현재 개수를 클러스터의 대상 개수로 사용할 수도 있습니다.
다음 스크린샷은 크기 조정 중이지만 **Stop(중지)**을 선택하여 중지할 수 있는 작업 인스턴스 그룹을 보여줍니다.
![\[Task instance group showing resizing status with options to resize or stop.\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/resize-stop.png)
**를 사용하여 크기 조정을 중단하려면 AWS CLI**
를 사용하여 `modify-instance-groups` 하위 명령으로 크기 조정을 중지 AWS CLI 할 수 있습니다. 인스턴스 그룹에 6개의 인스턴스가 있고 이 수를 10개로 늘리려 한다고 가정해 보세요. 나중에 이 요청을 취소하기로 결정했습니다.
+ 최초 요청:
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=10
```
첫 번째 요청을 중지하는 두 번째 요청:
```
aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-myInstanceGroupId,InstanceCount=6
```
**참고**
이 프로세스는 비동기식이므로 이후 요청이 처리되기 전에 인스턴스 수가 이전 API 요청과 관련하여 변경되는 것을 볼 수 있습니다. 축소되는 경우 노드에서 실행 중인 작업이 있으면 노드가 해당 작업을 완료할 때까지 인스턴스 그룹이 축소되지 않을 수도 있습니다.
## 일시 중단됨 상태
인스턴스 그룹은 새 클러스터 노드를 시작하는 동안 너무 많은 오류가 발생하면 일시 중단됨 상태가 됩니다. 예를 들어, 부트스트랩 작업을 수행하는 동안 새 노드에 장애가 발생하면 인스턴스 그룹은 새 노드를 계속 프로비저닝하지 않고 *일시 중단됨* 상태가 됩니다. 기본 문제를 해결한 후 클러스터 인스턴스 그룹에서 원하는 노드 수를 다시 설정하면 인스턴스 그룹이 노드 할당을 다시 시작합니다. 인스턴스 그룹을 수정하면 노드를 다시 프로비저닝하도록 Amazon EMR에 지시합니다. 실행 중인 노드는 다시 시작되거나 종료되지 않습니다.
에서 `list-instances` 하위 명령 AWS CLI은 `describe-cluster` 하위 명령과 마찬가지로 모든 인스턴스와 해당 상태를 반환합니다. Amazon EMR이 인스턴스 그룹에 대한 오류를 감지하면 그룹의 상태를 `SUSPENDED`로 변경합니다.
**를 사용하여 일시 중지됨 상태의 클러스터를 재설정하려면 AWS CLI**
`describe-cluster` 파라미터와 함께 `--cluster-id` 하위 명령을 입력하여 클러스터의 인스턴스 상태를 봅니다.
+ 클러스터의 모든 인스턴스 및 인스턴스 그룹에 대한 정보를 보려면 다음 명령을 입력하고 *j-3KVXXXXXXY7UG*를 클러스터 ID로 바꿉니다.
```
1. aws emr describe-cluster --cluster-id j-3KVXXXXXXY7UG
```
출력에는 인스턴스 그룹 및 인스턴스 상태에 대한 정보가 표시됩니다.
```
1. {
2. "Cluster": {
3. "Status": {
4. "Timeline": {
5. "ReadyDateTime": 1413187781.245,
6. "CreationDateTime": 1413187405.356
7. },
8. "State": "WAITING",
9. "StateChangeReason": {
10. "Message": "Waiting after step completed"
11. }
12. },
13. "Ec2InstanceAttributes": {
14. "Ec2AvailabilityZone": "us-west-2b"
15. },
16. "Name": "Development Cluster",
17. "Tags": [],
18. "TerminationProtected": false,
19. "RunningAmiVersion": "3.2.1",
20. "NormalizedInstanceHours": 16,
21. "InstanceGroups": [
22. {
23. "RequestedInstanceCount": 1,
24. "Status": {
25. "Timeline": {
26. "ReadyDateTime": 1413187775.749,
27. "CreationDateTime": 1413187405.357
28. },
29. "State": "RUNNING",
30. "StateChangeReason": {
31. "Message": ""
32. }
33. },
34. "Name": "MASTER",
35. "InstanceGroupType": "MASTER",
36. "InstanceType": "m5.xlarge",
37. "Id": "ig-3ETXXXXXXFYV8",
38. "Market": "ON_DEMAND",
39. "RunningInstanceCount": 1
40. },
41. {
42. "RequestedInstanceCount": 1,
43. "Status": {
44. "Timeline": {
45. "ReadyDateTime": 1413187781.301,
46. "CreationDateTime": 1413187405.357
47. },
48. "State": "RUNNING",
49. "StateChangeReason": {
50. "Message": ""
51. }
52. },
53. "Name": "CORE",
54. "InstanceGroupType": "CORE",
55. "InstanceType": "m5.xlarge",
56. "Id": "ig-3SUXXXXXXQ9ZM",
57. "Market": "ON_DEMAND",
58. "RunningInstanceCount": 1
59. }
60. ...
61. }
```
특정 인스턴스 그룹에 대한 정보를 보려면 `list-instances` 및 `--cluster-id` 파라미터와 함께 `--instance-group-types` 하위 명령을 입력합니다. 프라이머리, 코어 또는 태스크 그룹에 대한 정보를 볼 수 있습니다.
```
1. aws emr list-instances --cluster-id j-3KVXXXXXXY7UG --instance-group-types "CORE"
```
클러스터를 `modify-instance-groups` 상태로 재설정하려면 `--instance-groups` 파라미터와 함께 `SUSPENDED` 하위 명령을 사용합니다. `describe-cluster` 하위 명령에서 인스턴스 그룹 ID를 반환합니다.
```
1. aws emr modify-instance-groups --instance-groups InstanceGroupId=ig-3SUXXXXXXQ9ZM,InstanceCount=3
```
## 클러스터 크기를 줄일 때 고려 사항
실행 중인 클러스터의 크기를 줄이려면 다음 Amazon EMR 동작 및 모범 사례를 고려합니다.
+ 진행 중인 작업에 미치는 영향을 줄이기 위해 Amazon EMR은 제거할 인스턴스를 지능적으로 선택합니다. 클러스터 스케일 다운 동작에 대한 자세한 내용은 Amazon EMR 관리 안내서에서 [작업 완료 시 종료](emr-scaledown-behavior.md#emr-scaledown-terminate-task) 섹션을 참조하세요.
+ 클러스터 크기를 스케일 다운하면 Amazon EMR은 제거하는 인스턴스의 데이터를 남아 있는 인스턴스로 복사합니다. 그룹에 남아 있는 인스턴스에 이 데이터를 저장할 충분한 스토리지 용량이 있는지 확인합니다.
+ Amazon EMR은 그룹 내 인스턴스에서 HDFS의 서비스를 해제하려고 시도합니다. 클러스터 크기를 줄이기 전에 HDFS 쓰기 I/O를 최소화하는 것이 좋습니다.
+ 클러스터의 크기를 줄일 때 가장 세밀하게 제어하기 위해 콘솔에서 클러스터를 보고 **인스턴스** 탭으로 이동할 수 있습니다. 크기를 조정하려는 인스턴스 그룹의 **ID**를 선택합니다. 그런 다음 제거하려는 특정 인스턴스에 대해 **종료** 옵션을 사용합니다.
# Amazon EMR에서 용량을 제어하도록 프로비저닝 제한 시간 구성
인스턴스 플릿을 사용하는 경우 *프로비저닝 제한 시간*을 구성할 수 있습니다. 프로비저닝 제한 시간은 클러스터 시작 또는 클러스터 조정 작업 중에 클러스터가 지정된 시간 임계값을 초과하는 경우 Amazon EMR에서 인스턴스 용량 프로비저닝을 중단하도록 지시합니다. 다음 주제에서는 클러스터 시작 및 클러스터 스케일 업 작업에 대한 프로비저닝 제한 시간을 구성하는 방법을 다룹니다.
**Topics**
+ [Amazon EMR에서 클러스터 시작에 대한 프로비저닝 제한 시간 구성](emr-provisioning-timeout-launch.md)
+ [Amazon EMR에서 클러스터 크기 조정에 대한 프로비저닝 제한 시간 사용자 지정](emr-provisioning-timeout-resize.md)
# Amazon EMR에서 클러스터 시작에 대한 프로비저닝 제한 시간 구성
클러스터의 각 플릿에 스팟 인스턴스를 프로비저닝하는 제한 시간을 정의할 수 있습니다. Amazon EMR이 스팟 용량을 프로비저닝할 수 없는 경우 클러스터를 종료하거나 대신 온디맨드 용량을 프로비저닝하도록 선택할 수 있습니다. 클러스터 크기 조정 프로세스 중에 제한 시간이 끝나면 Amazon EMR은 프로비저닝되지 않은 스팟 요청을 취소합니다. 프로비저닝되지 않은 스팟 인스턴스는 온디맨드 용량으로 전환되지 않습니다.
Amazon EMR 콘솔에서 다음 단계를 수행하여 클러스터 시작에 대한 프로비저닝 제한 시간을 사용자 지정합니다.
------
#### [ 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. **클러스터 조정 및 프로비저닝 옵션**에서 코어 및 태스크 플릿의 스팟 크기를 지정합니다.
1. **스팟 제한 시간 구성**에서 **스팟 제한 시간 후 클러스터 종료** 또는 **스팟 제한 시간 후 온디맨드로 전환**을 선택합니다. 그런 다음 스팟 인스턴스를 프로비저닝하기 위한 제한 시간을 지정합니다. 기본값은 1시간입니다.
1. 클러스터에 적용되는 다른 옵션을 선택합니다.
1. 구성된 제한 시간으로 클러스터를 시작하려면 **클러스터 생성**을 선택합니다.
------
#### [ AWS CLI ]
**`create-cluster` 명령으로 프로비저닝 제한 시간을 지정하는 방법**
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
------
# Amazon EMR에서 클러스터 크기 조정에 대한 프로비저닝 제한 시간 사용자 지정
클러스터의 각 플릿에 스팟 인스턴스를 프로비저닝하는 제한 시간을 정의할 수 있습니다. Amazon EMR이 스팟 용량을 프로비저닝할 수 없는 경우 크기 조정 요청을 취소하고 추가 스팟 용량을 프로비저닝하려는 시도를 중지합니다. 클러스터를 생성할 때 제한 시간을 구성할 수 있습니다. 실행 중인 클러스터의 경우 제한 시간을 추가하거나 업데이트할 수 있습니다.
제한 시간이 만료되면 Amazon EMR은 Amazon CloudWatch Events 스트림으로 이벤트를 자동으로 전송합니다. CloudWatch에서 지정된 패턴에 따라 이벤트를 일치시키는 규칙을 생성하고 이벤트를 대상으로 라우트하여 조치를 취할 수 있습니다. 예를 들어, 이메일 알림을 보내는 규칙을 구성할 수 있습니다. 규칙을 생성하는 방법에 대한 자세한 내용은 [CloudWatch를 사용하여 Amazon EMR 이벤트에 대한 규칙 생성](emr-events-cloudwatch-console.md) 섹션을 참조하세요. 여러 이벤트 세부 정보에 대한 자세한 내용은 [인스턴스 플릿 상태 변경 이벤트](emr-manage-cloudwatch-events.md#emr-cloudwatch-instance-fleet-events) 섹션을 참조하세요.
## 클러스터 크기 조정에 대한 프로비저닝 제한 시간 예제
** AWS CLI를 사용하여 크기 조정에 대한 프로비저닝 제한 시간 지정**
다음 예제에서는 `create-cluster` 명령을 사용하여 크기 조정에 대한 프로비저닝 제한 시간을 추가합니다.
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
다음 예제에서는 `modify-instance-fleet` 명령을 사용하여 크기 조정에 대한 프로비저닝 제한 시간을 추가합니다.
```
aws emr modify-instance-fleet \
--cluster-id j-XXXXXXXXXXXXX \
--instance-fleet '{"InstanceFleetId":"if-XXXXXXXXXXXX","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":60}}}' \
--region us-east-1
```
다음 예제에서는 `add-instance-fleet-command`를 사용하여 크기 조정에 대한 프로비저닝 제한 시간을 추가합니다.
```
aws emr add-instance-fleet \
--cluster-id j-XXXXXXXXXXXXX \
--instance-fleet '{"InstanceFleetType":"TASK","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"TaskFleet","ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":30},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":35}}}' \
--region us-east-1
```
**를 사용하여 크기 조정 및 시작을 위한 프로비저닝 제한 시간 지정 AWS CLI**
다음 예제에서는 `create-cluster` 명령을 사용하여 크기 조정 및 시작에 대한 프로비저닝 제한 시간을 추가합니다.
```
aws emr create-cluster \
--release-label emr-5.35.0 \
--service-role EMR_DefaultRole \
--ec2-attributes '{"InstanceProfile":"EMR_EC2_DefaultRole","SubnetIds":["subnet-XXXXX"]}' \
--instance-fleets '[{"InstanceFleetType":"MASTER","TargetOnDemandCapacity":1,"TargetSpotCapacity":0,"LaunchSpecifications":{"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":100,"InstanceType":"m5.xlarge"}],"Name":"Master - 1"},{"InstanceFleetType":"CORE","TargetOnDemandCapacity":1,"TargetSpotCapacity":1,"LaunchSpecifications":{"SpotSpecification":{"TimeoutDurationMinutes":120,"TimeoutAction":"SWITCH_TO_ON_DEMAND"},"OnDemandSpecification":{"AllocationStrategy":"lowest-price"}},"ResizeSpecifications":{"SpotResizeSpecification":{"TimeoutDurationMinutes":20},"OnDemandResizeSpecification":{"TimeoutDurationMinutes":25}},"InstanceTypeConfigs":[{"WeightedCapacity":1,"EbsConfiguration":{"EbsBlockDeviceConfigs":[{"VolumeSpecification":{"SizeInGB":32,"VolumeType":"gp2"},"VolumesPerInstance":2}]},"BidPriceAsPercentageOfOnDemandPrice":1,"InstanceType":"m5.xlarge"}],"Name":"Core - 2"}]'
```
## 크기 조정 프로비저닝 제한 시간에 대한 고려 사항
인스턴스 플릿의 클러스터 프로비저닝 제한 시간을 구성할 때 다음 동작을 고려합니다.
+ 스팟 인스턴스와 온디맨드 인스턴스 모두에 대해 프로비저닝 제한 시간을 구성할 수 있습니다. 최소 프로비저닝 제한 시간은 5분입니다. 최대 프로비저닝 제한 시간은 7일입니다.
+ 인스턴스 플릿을 사용하는 EMR 클러스터의 프로비저닝 제한 시간만 구성할 수 있습니다. 각 코어 및 태스크 플릿은 개별적으로 구성해야 합니다.
+ 클러스터를 생성할 때 프로비저닝 제한 시간을 구성할 수 있습니다. 실행 중인 클러스터의 제한 시간을 추가하거나 기존 제한 시간을 업데이트할 수 있습니다.
+ 크기 조정 작업을 여러 번 제출하는 경우 Amazon EMR은 모든 크기 조정 작업에 대한 프로비저닝 제한 시간을 추적합니다. 예를 들어, 클러스터의 프로비저닝 제한 시간을 *60*분으로 설정합니다. 그런 다음, 시간 *T1*에 크기 조정 작업 *R1*을 제출합니다. 시간 *T2*에 두 번째 크기 조정 작업 *R2*를 제출합니다. R1의 프로비저닝 제한 시간은 *T1 이후 60분*이 지나면 만료됩니다. R2의 프로비저닝 제한 시간은 *T2 이후 60분*이 지나면 만료됩니다.
+ 제한 시간이 만료되기 전에 새로운 스케일 업 크기 조정 작업을 제출하면 Amazon EMR은 EMR 클러스터에 용량을 프로비저닝하기 위한 시도를 계속합니다.
# Amazon EMR 클러스터에 대한 클러스터 스케일 다운 옵션
**참고**
Amazon EMR 릴리스 5.10.0 이후 스케일 다운 동작 옵션은 더 이상 지원되지 않습니다. Amazon EC2에 초당 요금이 도입됨에 따라 Amazon EMR 클러스터의 기본 스케일 다운 동작은 이제 작업 완료 시 종료됩니다.
Amazon EMR 릴리스 버전 5.1.0\$15.9.1에서는 스케일 다운 동작으로 두 가지 옵션, 즉 Amazon EC2 청구의 인스턴스 시간 경계에서 종료하거나 작업 완료 시 종료하는 옵션이 제공됩니다. Amazon EMR 릴리스 버전 5.10.0부터는 Amazon EC2에 초당 요금 부과가 도입되면서 인스턴스 시간 경계에서 종료하는 설정은 더 이상 사용되지 않습니다. 이 옵션이 제공되는 버전에서는 인스턴스 시간 경계에서 종료를 지정하지 않는 것이 좋습니다.
**주의**
AWS CLI 를 사용하여 `modify-instance-groups`에서를 발급하는 경우 `EC2InstanceIdsToTerminate`이러한 설정을 고려하지 않고 실행 중인 애플리케이션의 상태에 관계없이 이러한 인스턴스가 즉시 종료됩니다. 이 방법으로 인스턴스를 종료하면 데이터 손실과 예기치 않은 클러스터 동작이 발생할 위험이 있습니다.
작업 완료 시 종료가 지정되면 Amazon EMR은 Amazon EC2 인스턴스를 종료하기 전에 거부 목록을 생성하고 노드에서 작업을 빼냅니다. 어떤 동작이 지정되든 Amazon EMR은 HDFS 손상을 초래할 수 있는 경우 코어 인스턴스 그룹에서 Amazon EC2 인스턴스를 종료하지 않습니다.
## 작업 완료 시 종료
Amazon EMR에서는 워크로드에 영향을 주지 않고 클러스터를 스케일 다운할 수 있습니다. Amazon EMR은 크기 조정 작업 중에 데이터 손실이나 작업 중단 없이 코어 및 태스크 노드의 YARN, HDFS 및 기타 대몬(daemon)을 정상적으로 서비스 해제하려고 시도합니다. Amazon EMR은 그룹에 할당된 작업이 완료되고 유휴 상태인 경우에만 인스턴스 그룹 크기를 줄입니다. YARN NodeManager의 단계적 서비스 해제에서는 노드의 서비스 해제를 기다리는 시간을 수동으로 조정할 수 있습니다.
**참고**
정상 해제 시 데이터가 손실될 수 있습니다. 데이터를 백업합니다.
**중요**
비정상 코어 인스턴스를 정상적으로 교체하는 동안 HDFS 데이터가 영구적으로 손실될 수 있습니다. 항상 데이터를 백업하는 것이 좋습니다.
이 시간은 `YARN-site` 구성 분류의 속성으로 설정합니다. Amazon EMR 릴리스 5.12.0 이상에서는 `YARN.resourcemanager.nodemanager-graceful-decommission-timeout-secs` 속성을 지정합니다. 이전 Amazon EMR 릴리스를 사용할 경우 `YARN.resourcemanager.decommissioning.timeout` 속성을 지정합니다.
폐기 시간 제한이 지났을 때 컨테이너 또는 YARN 애플리케이션이 계속 실행 중이면 강제로 노드를 폐기하고 YARN이 다른 노드에서 해당 컨테이너를 다시 예약합니다. 기본값은 3,600초(1시간)입니다. 이 제한 시간을 임의로 높은 값으로 설정하면 단계적으로 축소될 때까지 더 오래 기다릴 수 있습니다. 자세한 내용은 Apache Hadoop 설명서에서 [Graceful Decommission of YARN nodes](http://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/GracefulDecommission.html)를 참조하세요.
### 태스크 노드 그룹
Amazon EMR은 모든 단계 또는 애플리케이션과 관련해 실행 중인 작업이 없는 인스턴스를 지능적으로 선택하여 클러스터에서 해당 인스턴스를 먼저 제거합니다. 클러스터의 모든 인스턴스가 사용 중이면 Amazon EMR은 인스턴스에서 작업이 완료될 때까지 기다린 후 클러스터에서 해당 인스턴스를 제거합니다. 기본 대기 시간은 1시간입니다. 이 값은 `YARN.resourcemanager.decommissioning.timeout` 설정을 사용하여 변경할 수 있습니다. Amazon EMR은 새 설정을 동적으로 사용합니다. 이 값을 임의로 큰 수로 설정하여 Amazon EMR이 클러스터 크기를 줄이는 동안 작업을 종료하지 않도록 할 수 있습니다.
### 코어 노드 그룹
코어 노드에서 인스턴스 그룹을 줄이려면 YARN NodeManager 및 HDFS DataNode 대몬(daemon)을 모두 해제해야 합니다. YARN의 경우 단계적 축소를 사용하면 보류 중이거나 미완료 상태의 컨테이너 또는 애플리케이션이 없는 경우 폐기용으로 표시된 노드만 `DECOMMISSIONED` 상태로 전환됩니다. 폐기가 시작될 때 노드에 실행 중인 컨테이너가 없으면 폐기가 즉시 완료됩니다.
HDFS의 경우 단계적 축소를 사용하면 HDFS의 대상 용량이 기존의 모든 블록에 맞도록 충분히 큰지 확인합니다. 대상 용량이 충분히 크지 않으면 나머지 노드가 HDFS에 있는 현재 데이터를 처리할 수 있도록 코어 인스턴스의 일부분만 폐기됩니다. 추가 폐기를 허용하려면 추가 HDFS 용량을 확보해야 합니다. 또한 인스턴스 그룹을 줄이기 전에 쓰기 I/O를 최소화해야 합니다. 쓰기 I/O가 너무 과도하면 크기 조정 작업 완료가 지연될 수 있습니다.
또 다른 한계로, `dfs.replication` 내부의 기본 복제 인수(`/etc/hadoop/conf/hdfs-site`)가 있습니다. 클러스터를 생성할 대 Amazon EMR은 클러스터의 인스턴스 수를 기반으로 값을 구성합니다. 인스턴스가 1\$13개 있는 클러스터의 경우 `1`, 4\$19개가 있는 클러스터의 경우 `2`, 10개 이상이 있는 클러스터의 경우 `3`입니다.
**주의**
노드 수가 4개 미만인 클러스터에서 `dfs.replication`을 1로 설정하면 단일 노드가 중단된 경우 HDFS 데이터가 손실될 수 있습니다. 프로덕션 워크로드에는 코어 노드가 4개 이상 있는 클러스터를 사용하는 것이 좋습니다.
Amazon EMR은 클러스터에서 코어 노드를 `dfs.replication` 미만으로 조정하는 허용하지 않습니다. 예를 들어, `dfs.replication = 2`인 경우 최소 코어 노드 수가 2개입니다.
Managed Scaling, Auto Scaling을 사용하거나 클러스터 크기를 수동으로 조정하는 경우 `dfs.replication`을 2 이상으로 설정하는 것이 좋습니다.
단계적 축소에서는 코어 노드를 HDFS 복제 인수 이하로 줄일 수 없습니다. 복제본이 충분하지 않으므로 HDFS에서 파일을 닫을 수 있도록 하기 위해서입니다. 이 제한을 피하려면 복제 인수를 낮추고 NameNode 대몬(daemon)을 다시 시작합니다.
# Amazon EMR 스케일 다운 동작 구성
**참고**
Amazon EMR 릴리스 5.10.0 이상에서는 인스턴스 시간에 종료 스케일 다운 동작 옵션이 더 이상 지원되지 않습니다. 다음 스케일 다운 동작 옵션은 릴리스 5.1.0에서 5.9.1의 Amazon EMR 콘솔에만 나타납니다.
클러스터를 생성할 때 AWS Management Console AWS CLI, 또는 Amazon EMR API를 사용하여 축소 동작을 구성할 수 있습니다.
------
#### [ 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이 단방향 조정만 수행하므로 다른 작업을 수동으로 수행해야 합니다.
1. 클러스터에 적용할 다른 옵션을 선택합니다.
1. 클러스터를 시작하려면 **클러스터 생성**을 선택합니다.
------
#### [ AWS CLI ]
**를 사용하여 축소 동작을 구성하려면 AWS CLI**
+ `--scale-down-behavior` 옵션을 사용하여 `TERMINATE_AT_INSTANCE_HOUR` 또는 `TERMINATE_AT_TASK_COMPLETION`을 지정합니다.
------