노드 할당 전략 및 시나리오 이해

이 섹션에서는 Amazon EMR Managed Scaling과 함께 사용할 수 있는 노드 할당 전략 및 일반적인 조정 시나리오에 대한 개요를 제공합니다.

노드 할당 전략

Amazon EMR Managed Scaling은 다음과 같은 스케일 업 및 스케일 다운 전략을 기반으로 코어 및 태스크 노드를 할당합니다.

스케일 업 전략

• Amazon EMR Managed Scaling은 먼저 코어 노드에 용량을 추가한 다음, 최대 허용 용량에 도달하거나 원하는 스케일 업 목표 용량에 도달할 때까지 태스크 노드에 용량을 추가합니다.

• Amazon EMR에서 현재 인스턴스 그룹의 스케일 업이 지연되는 경우 Managed Scaling을 사용하는 클러스터는 다른 태스크 인스턴스 그룹으로 전환합니다.

• MaximumCoreCapacityUnits 파라미터가 설정된 경우 Amazon EMR은 코어 유닛이 최대 허용 한도에 도달할 때까지 코어 노드를 확장합니다. 남은 용량이 모두 태스크 노드에 추가됩니다.

• MaximumOnDemandCapacityUnits 파라미터가 설정된 경우 Amazon EMR은 온디맨드 단위가 최대 허용 한도에 도달할 때까지 온디맨드 인스턴스를 사용하여 클러스터를 조정합니다. 나머지 용량은 모두 스팟 인스턴스를 사용하여 추가됩니다.

• MaximumCoreCapacityUnits 및 MaximumOnDemandCapacityUnits 파라미터가 모두 설정된 경우 Amazon EMR은 조정 중에 두 한도를 모두 고려합니다.

  예를 들어 MaximumCoreCapacityUnits이 MaximumOnDemandCapacityUnits 미만인 경우 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 Managed Scaling은 먼저 태스크 노드를 제거한 다음 원하는 스케일 다운 목표 용량에 도달할 때까지 코어 노드를 제거합니다. 클러스터는 Managed Scaling 정책의 최소 제약 조건 이하로 조정되지 않습니다.

• 각 노드 유형(코어 노드 또는 태스크 노드) 내에서 Amazon EMR 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 파라미터가 다음 요구 사항을 충족해야 합니다.

• 온디맨드 제한은 최대 경계와 같습니다.

• 최대 코어 노드는 최대 경계와 같습니다.

온디맨드 제한과 최대 코어 노드 파라미터를 지정하지 않은 경우 두 파라미터 모두 기본적으로 최대 경계로 설정됩니다.

다음 예제에서는 코어 노드만 조정하는 시나리오를 보여줍니다.

클러스터 초기 상태	조정 파라미터	조정 동작
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개	UnitType: Instances MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 20 MaximumCoreCapacityUnits: 20	온디맨드 유형을 사용하는 코어 노드의 인스턴스 또는 인스턴스 플릿 유닛을 1~20개 사이로 조정합니다. 태스크 노드는 조정하지 않습니다.
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개	UnitType: InstanceFleetUnits MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 20 MaximumCoreCapacityUnits: 20

시나리오 2: 태스크 노드만 조정

태스크 노드만 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.

• 최대 코어 노드는 최소 경계와 같아야 합니다.

다음 예제에서는 태스크 노드만 조정하는 시나리오를 보여줍니다.

클러스터 초기 상태	조정 파라미터	조정 동작
인스턴스 그룹 코어: 온디맨드 2개 태스크: 스팟 1개	UnitType: Instances MinimumCapacityUnits: 2 MaximumCapacityUnits: 20 MaximumCoreCapacityUnits: 2	코어 노드를 2개로 유지하고 태스크 노드를 0~18개의 인스턴스 또는 인스턴스 플릿 유닛 사이로만 조정합니다. 최소 경계와 최대 경계 사이의 용량은 태스크 노드에만 추가됩니다.
인스턴스 플릿 코어: 온디맨드 2개 태스크: 스팟 1개	UnitType: InstanceFleetUnits MinimumCapacityUnits: 2 MaximumCapacityUnits: 20 MaximumCoreCapacityUnits: 2

시나리오 3: 클러스터의 온디맨드 인스턴스만

온디맨드 인스턴스만 보유하려면 클러스터 및 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.

• 온디맨드 제한은 최대 경계와 같습니다.

  온디맨드 제한이 지정되지 않은 경우 파라미터 값의 기본값은 최대 경계입니다. 기본값은 Amazon EMR이 온디맨드 인스턴스만 확장함을 나타냅니다.

최대 코어 노드가 최대 한도보다 작으면 최대 코어 노드 파라미터를 사용하여 코어 노드와 태스크 노드 사이에서 용량 할당을 분할할 수 있습니다.

인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 클러스터의 모든 노드 그룹이 초기 구성 시 온디맨드 시장 유형을 사용해야 합니다.

다음 예제에서는 전체 클러스터에 온디맨드 인스턴스가 있는 시나리오를 보여줍니다.

클러스터 초기 상태	조정 파라미터	조정 동작
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개	UnitType: Instances MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 20 MaximumCoreCapacityUnits: 12	온디맨드 유형을 사용하여 코어 노드의 인스턴스 또는 인스턴스 플릿 유닛을 1~12개 사이로 조정합니다. 태스크 노드에서 온디맨드를 사용하여 남은 용량을 조정합니다. 스팟 인스턴스를 사용하여 조정하지 않습니다.
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개	UnitType: InstanceFleetUnits MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 20 MaximumCoreCapacityUnits: 12

시나리오 4: 클러스터의 스팟 인스턴스만

스팟 인스턴스만 보유하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.

• 온디맨드 제한은 0으로 설정됩니다.

최대 코어 노드가 최대 한도보다 작으면 최대 코어 노드 파라미터를 사용하여 코어 노드와 태스크 노드 사이에서 용량 할당을 분할할 수 있습니다.

인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 코어 인스턴스 그룹이 초기 구성 중에 스팟 구매 옵션을 사용해야 합니다. 태스크 인스턴스 그룹에 스팟 인스턴스가 없는 경우 Amazon EMR Managed Scaling은 필요할 때 스팟 인스턴스를 사용하여 태스크 그룹을 생성합니다.

다음 예제에서는 전체 클러스터에 스팟 인스턴스가 있는 시나리오를 보여줍니다.

클러스터 초기 상태	조정 파라미터	조정 동작
인스턴스 그룹 코어: 스팟 1개 태스크: 스팟 1개	UnitType: Instances MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 0	스팟을 사용하여 코어 노드의 인스턴스 또는 인스턴스 플릿 유닛을 1~20개 사이로 조정합니다. 온디맨드 유형을 사용하여 조정하지 않습니다.
인스턴스 플릿 코어: 스팟 1개 태스크: 스팟 1개	UnitType: InstanceFleetUnits MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 0

시나리오 5: 코어 노드의 온디맨드 인스턴스 및 태스크 노드의 스팟 인스턴스 조정

코어 노드의 온디맨드 인스턴스와 태스크 노드의 스팟 인스턴스를 조정하려면 Managed Scaling 파라미터가 다음 요구 사항을 충족해야 합니다.

• 온디맨드 제한은 최대 코어 노드와 같아야 합니다.

• 온디맨드 제한과 최대 코어 노드 모두 최대 경계보다 작아야 합니다.

인스턴스 그룹으로 구성된 클러스터에서 이 시나리오를 활성화하려면 코어 노드 그룹에서 온디맨드 구매 옵션을 사용해야 합니다.

다음 예제에서는 코어 노드에서 온디맨드 인스턴스를 조정하고 태스크 노드에서 스팟 인스턴스를 조정하는 시나리오를 보여줍니다.

클러스터 초기 상태	조정 파라미터	조정 동작
인스턴스 그룹 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개	UnitType: Instances MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 7 MaximumCoreCapacityUnits: 7	태스크 노드에 온디맨드 유닛이 이미 1개이고 온디맨드의 최대 제한이 7개이므로 코어 노드에서 최대 6개까지 온디맨드 유닛을 조정할 수 있습니다. 그런 다음 태스크 노드에서 스팟 유닛을 최대 13개로 스케일 업합니다.
인스턴스 플릿 코어: 온디맨드 1개 태스크: 온디맨드 1개 및 스팟 1개	UnitType: InstanceFleetUnits MinimumCapacityUnits: 1 MaximumCapacityUnits: 20 MaximumOnDemandCapacityUnits: 7 MaximumCoreCapacityUnits: 7