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은 노드 레이블을 기반으로 노드를 제거합니다. 노드 레이블에 대한 자세한 내용은 노드 유형 이해: 프라이머리, 코어 및 태스크 노드를 참조하세요.
-
노드 레이블을 활성화하지 않은 경우 관리형 조정은 태스크 노드를 제거한 다음, 원하는 스케일 다운 목표 용량에 도달할 때까지 코어 노드를 제거합니다. 관리형 조정은 클러스터를 관리형 조정 정책에 지정된 최소 제약 조건 이하로 스케일 다운하지 않습니다.
-
Amazon EMR 버전 5.34.0 이상 및 Amazon EMR 버전 6.4.0 이상에서는 Spark 셔플 데이터(Spark가 특정 작업을 수행하기 위해 파티션 전체에 재분배하는 데이터)를 인식하는 Managed Scaling을 지원합니다. 셔플 작업에 대한 자세한 내용은 Spark Programming Guide
를 참조하세요. Managed Scaling은 사용률이 낮고 활발하게 사용되는 셔플 데이터를 포함하지 않는 인스턴스만 스케일 다운합니다. 이러한 지능형 조정을 통해 의도하지 않은 셔플 데이터 손실을 방지할 수 있으며 이를 통해 작업을 다시 시도하거나 중간 데이터를 재계산할 필요가 없습니다. -
관리형 조정은 먼저 태스크 노드를 제거한 다음, 원하는 스케일 다운 목표 용량에 도달할 때까지 코어 노드를 제거합니다. 클러스터는 관리형 조정 정책의 최소 제약 조건 이하로 조정되지 않습니다.
-
Amazon EMR 5.x 릴리스 5.34.0 이상 및 6.x 릴리스 6.4.0 이상으로 시작된 클러스터의 경우 Amazon EMR Managed Scaling은 Apache Spark가 실행 중인
ApplicationMaster를 포함하는 노드를 스케일 다운하지 않습니다. 이렇게 하면 작업 실패 및 재시도가 최소화되어 작업 성능을 개선하고 비용을 절감하는 데 도움이 됩니다. 클러스터에서ApplicationMaster를 실행하는 노드를 확인하려면 Spark 기록 서버로 이동하여 Spark 애플리케이션 ID의 실행기 탭에서 드라이버를 필터링합니다.
클러스터에 로드가 없는 경우 Amazon EMR은 이전 평가에서 새 인스턴스 추가를 취소하고 스케일 다운 작업을 수행합니다. 클러스터에 로드가 많은 경우 Amazon EMR은 인스턴스 제거를 취소하고 스케일 업 작업을 수행합니다.
노드 할당 고려 사항
스팟 재확보 시 HDFS 데이터 손실을 방지하려면 코어 노드에 대한 온디맨드 구매 옵션을 사용하는 것이 좋습니다. 태스크 노드에 대한 스팟 구매 옵션을 사용하면 태스크 노드에 스팟 인스턴스가 더 추가될 때 비용을 절감하고 작업 실행 속도를 높일 수 있습니다.
노드 할당 시나리오
최대, 최소, 온디맨드 제한 및 최대 코어 노드 파라미터를 다양한 조합으로 설정하여 필요에 따라 다양한 조정 시나리오를 만들 수 있습니다.
시나리오 1: 코어 노드만 조정
코어 노드만 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
-
온디맨드 제한은 최대 경계와 같습니다.
-
최대 코어 노드는 최대 경계와 같습니다.
온디맨드 제한과 최대 코어 노드 파라미터를 지정하지 않은 경우 두 파라미터 모두 기본적으로 최대 경계로 설정됩니다.
관리형 조정은 실행기 수요를 수용하기 위해 태스크 노드를 조정하므로 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 CORE 노드에서만 실행하도록 제한하는 경우 이 시나리오는 적용되지 않습니다.
다음 예제에서는 코어 노드만 조정하는 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개 |
|
온디맨드 유형을 사용하는 코어 노드의 인스턴스 또는 인스턴스 플릿 유닛을 1~20개 사이로 조정합니다. 태스크 노드는 조정하지 않습니다. 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 |
|
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개 |
UnitType: InstanceFleetUnits
|
시나리오 2: 태스크 노드만 조정
태스크 노드만 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
-
최대 코어 노드는 최소 경계와 같아야 합니다.
다음 예제에서는 태스크 노드만 조정하는 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 온디맨드 2개 태스크: 스팟 1개 |
|
코어 노드를 2개로 유지하고 태스크 노드를 0~18개의 인스턴스 또는 인스턴스 플릿 유닛 사이로만 조정합니다. 최소 경계와 최대 경계 사이의 용량은 태스크 노드에만 추가됩니다. 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 ON_DEMAND 노드로 제한하는 경우 클러스터는 코어 노드는 2개로 유지하고 수요 유형에 따라 태스크 노드에서만 |
|
인스턴스 플릿 코어: 온디맨드 2개 태스크: 스팟 1개 |
|
시나리오 3: 클러스터의 온디맨드 인스턴스만
온디맨드 인스턴스만 보유하려면 클러스터 및 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
-
온디맨드 제한은 최대 경계와 같습니다.
온디맨드 제한이 지정되지 않은 경우 파라미터 값의 기본값은 최대 경계입니다. 기본값은 Amazon EMR이 온디맨드 인스턴스만 확장함을 나타냅니다.
최대 코어 노드가 최대 한도보다 작으면 최대 코어 노드 파라미터를 사용하여 코어 노드와 태스크 노드 사이에서 용량 할당을 분할할 수 있습니다.
인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 클러스터의 모든 노드 그룹이 초기 구성 시 온디맨드 시장 유형을 사용해야 합니다.
관리형 조정은 실행기 수요를 수용하기 위해 Spot 노드를 조정하므로 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 ON_DEMAND 노드에서만 실행하도록 제한하는 경우 이 시나리오는 적용되지 않습니다.
다음 예제에서는 전체 클러스터에 온디맨드 인스턴스가 있는 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 |
|
온디맨드 유형을 사용하여 코어 노드의 인스턴스 또는 인스턴스 플릿 유닛을 1~12개 사이로 조정합니다. 태스크 노드에서 온디맨드를 사용하여 남은 용량을 조정합니다. 스팟 인스턴스를 사용하여 조정하지 않습니다. 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 |
|
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 |
|
시나리오 4: 클러스터의 스팟 인스턴스만
스팟 인스턴스만 보유하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
-
온디맨드 제한은 0으로 설정됩니다.
최대 코어 노드가 최대 한도보다 작으면 최대 코어 노드 파라미터를 사용하여 코어 노드와 태스크 노드 사이에서 용량 할당을 분할할 수 있습니다.
인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 코어 인스턴스 그룹이 초기 구성 중에 스팟 구매 옵션을 사용해야 합니다. 태스크 인스턴스 그룹에 스팟 인스턴스가 없는 경우 Amazon EMR Managed Scaling은 필요할 때 스팟 인스턴스를 사용하여 태스크 그룹을 생성합니다.
관리형 조정은 애플리케이션 프로세스 수요를 수용하기 위해 ON_DEMAND 노드를 조정하므로 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 ON_DEMAND 노드에서만 실행하도록 제한하는 경우 이 시나리오는 적용되지 않습니다.
다음 예제에서는 전체 클러스터에 스팟 인스턴스가 있는 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 스팟 1개 태스크: 스팟 1개 |
|
스팟을 사용하여 코어 노드의 인스턴스 또는 인스턴스 플릿 유닛을 1~20개 사이로 조정합니다. 온디맨드 유형을 사용하여 조정하지 않습니다. 노드 레이블과 함께 관리형 조정을 사용하고 애플리케이션 프로세스를 |
|
인스턴스 플릿 코어: 스팟 1개 태스크: 스팟 1개 |
|
시나리오 5: 코어 노드의 온디맨드 인스턴스 및 태스크 노드의 스팟 인스턴스 조정
코어 노드의 온디맨드 인스턴스와 태스크 노드의 스팟 인스턴스를 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.
-
온디맨드 제한은 최대 코어 노드와 같아야 합니다.
-
온디맨드 제한과 최대 코어 노드 모두 최대 경계보다 작아야 합니다.
인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 코어 노드 그룹에서 온디맨드 구매 옵션을 사용해야 합니다.
이 시나리오는 노드 레이블과 함께 관리형 조정을 사용하고 ON_DEMAND 노드 또는 CORE 노드에서만 실행하도록 애플리케이션 프로세스를 제한하는 경우 적용되지 않습니다.
다음 예제에서는 코어 노드에서 온디맨드 인스턴스를 조정하고 태스크 노드에서 스팟 인스턴스를 조정하는 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개 |
|
태스크 노드에 온디맨드 유닛이 이미 1개이고 온디맨드의 최대 제한이 7개이므로 코어 노드에서 최대 6개까지 온디맨드 유닛을 조정할 수 있습니다. 그런 다음 태스크 노드에서 스팟 유닛을 최대 13개로 스케일 업합니다. |
|
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개 |
|
시나리오 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 인스턴스 조정 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 |
|
온디맨드 또는 스팟 시장 유형을 사용하여 클러스터의 애플리케이션 프로세스 수요에 기반하여 요청된 |
|
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 |
|
시나리오 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 노드는 최대 코어 용량에서 정적으로 유지됩니다.
다음 예제에서는 실행기 수요에 기반한 스팟 인스턴스 조정 및 애플리케이션 프로세스 수요에 기반한 온디맨드 인스턴스 조정 시나리오를 보여줍니다.
| 클러스터 초기 상태 | 조정 파라미터 | 조정 동작 |
|---|---|---|
|
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 |
|
요청된 |
|
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 |
|
