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