기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 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)