Amazon EMR에서 Managed Scaling 사용

다음 AWS 리전에서는 Amazon EMR 6.14.0 이상에서 Amazon EMR Managed Scaling을 사용할 수 있습니다.

다음 AWS 리전에서는 Amazon EMR 5.30.0 및 6.1.0 이상에서 Amazon EMR Managed Scaling을 사용할 수 있습니다.

Amazon EMR Managed Scaling은 Spark, Hadoop, Hive, Flink 등과 같은 YARN 애플리케이션에서만 작동합니다. 현재, Presto 및 HBase와 같은 YARN 기반이 아닌 애플리케이션에서는 지원되지 않습니다.

최소(MinimumCapacityUnits) - 클러스터에서 허용되는 EC2 용량의 하한. 인스턴스 그룹의 가상 중앙 처리 장치(vCPU) 코어 또는 인스턴스를 통해 측정됩니다. 인스턴스 플릿에 대한 장치를 통해 측정됩니다.

최대(MaximumCapacityUnits) - 클러스터에서 허용되는 EC2 용량의 상한. 인스턴스 그룹의 가상 중앙 처리 장치(vCPU) 코어 또는 인스턴스를 통해 측정됩니다. 인스턴스 플릿에 대한 장치를 통해 측정됩니다.

온디맨드 제한(MaximumOnDemandCapacityUnits)(선택 사항) - 클러스터의 온디맨드 시장 유형에 허용되는 EC2 용량의 상한. 이 파라미터를 지정하지 않으면 MaximumCapacityUnits 값이 기본값으로 사용됩니다.

최대 코어 노드(MaximumCoreCapacityUnits)(선택 사항) - 클러스터의 코어 노드 유형에 허용되는 EC2 용량의 상한. 이 파라미터를 지정하지 않으면 MaximumCapacityUnits 값이 기본값으로 사용됩니다.

Managed Scaling은 제한적 AWS 리전 및 Amazon EMR 릴리스에서 지원됩니다. 자세한 내용은 Managed Scaling 가용성 단원을 참조하십시오.

Amazon EMR Managed Scaling에 필요한 파라미터를 구성해야 합니다. 자세한 내용은 Managed Scaling 파라미터 단원을 참조하십시오.

Managed Scaling을 사용하려면 metrics-collector 프로세스를 API Gateway에서 Managed Scaling에 대한 퍼블릭 API 엔드포인트에 연결할 수 있어야 합니다. Amazon Virtual Private Cloud에서 프라이빗 DNS 이름을 사용하는 경우 Managed Scaling이 올바르게 작동하지 않습니다. Managed Scaling이 올바르게 작동하려면 다음 작업 중 하나를 수행하는 것이 좋습니다.

스케일 다운 중에 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 거부 목록과 통합되는 방법에 대한 세부 정보, Amazon EMR에서 노드를 거부 목록에 추가할 수 있는 경우, Spark 노드 서비스 해제 동작을 구성하는 방법을 참조하세요.

EBS 볼륨을 과도하게 사용하면 Managed Scaling 문제가 발생할 수 있습니다. EBS 볼륨 사용률을 90% 미만으로 유지하는 것이 좋습니다. 자세한 내용은 Amazon EMR에서 인스턴스 스토리지 옵션 및 동작 단원을 참조하십시오.

Amazon CloudWatch 지표는 Amazon EMR Managed Scaling을 작동하는 데 매우 중요한 역할을 합니다. Amazon CloudWatch 지표를 자세히 모니터링하여 데이터가 누락되지 않았는지 확인하는 것이 좋습니다. 누락된 지표를 감지하도록 CloudWatch 경보를 구성하는 방법에 대한 자세한 내용은 Amazon CloudWatch 경보 사용을 참조하세요.

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개 인스턴스 유형을 지정할 수 있으며, 각 인스턴스 유형을 온디맨드 및 스팟 인스턴스로 프로비저닝할 수 있습니다. 자세한 내용은 인스턴스 플릿 또는 균일한 인스턴스 그룹으로 클러스터 생성, 인스턴스 플릿 옵션 및 노드 할당 시나리오 섹션을 참조하세요.

Amazon EMR 5.30.0 이상에서 마스터 보안 그룹의 기본 모두 허용 아웃바운드 규칙(0.0.0.0/)을 제거하는 경우 포트 9443에서 서비스에 액세스할 수 있도록 보안 그룹에 아웃바운드 TCP 연결을 허용하는 규칙을 추가해야 합니다. 또한 서비스 액세스를 위한 보안 그룹은 마스터 보안 그룹의 포트 9443을 통한 인바운드 TCP 트래픽을 허용해야 합니다. 보안 그룹 구성에 대한 자세한 내용은 기본 인스턴스(프라이빗 서브넷)에 대한 Amazon EMR 관리형 보안 그룹을 참조하세요.

AWS CloudFormation을 사용하여 Amazon EMR Managed Scaling을 구성할 수 있습니다. 자세한 내용은 AWS CloudFormation 사용 설명서에서 AWS::EMR::Cluster를 참조하세요.

스팟 노드를 사용하는 경우 Amazon EMR이 스팟 노드를 제거할 때 Amazon EMR이 애플리케이션 프로세스를 제거하지 못하도록 노드 레이블을 사용하는 방법을 고려합니다. 노드 레이블에 대한 자세한 내용은 태스크 노드를 참조하세요.

Amazon EMR 릴리스 6.15 이하에서는 노드 레이블링이 기본적으로 지원되지 않습니다. 자세한 내용은 노드 유형 이해: 프라이머리, 코어 및 태스크 노드를 참조하세요.

Amazon EMR 릴리스 6.15 이하를 사용하는 경우 코어 및 태스크 노드와 같은 노드 유형별로만 노드 레이블을 할당할 수 있습니다. 그러나 Amazon EMR 릴리스 7.0 이상을 사용하는 경우 온디맨드 및 스팟과 같은 노드 유형 및 시장 유형별로 노드 레이블을 구성할 수 있습니다.

애플리케이션 프로세스를 코어 노드로 제한할 때 애플리케이션 프로세스 수요가 증가하고 실행기 수요가 감소하는 경우 동일한 크기 조정 작업에서 코어 노드를 다시 추가하고 태스크 노드를 제거할 수 있습니다. 자세한 내용은 노드 할당 전략 및 시나리오 이해를 참조하세요.

Amazon EMR은 태스크 노드에 레이블을 지정하지 않으므로 태스크 노드에 대해서만 애플리케이션 프로세스를 제한하도록 YARN 속성을 설정할 수 없습니다. 그러나 시장 유형을 노드 레이블로 사용하려는 경우 애플리케이션 프로세스 배치에 ON_DEMAND 또는 SPOT 레이블을 사용할 수 있습니다. 애플리케이션 프라이머리 프로세스에 대해서는 스팟 노드를 사용하지 않는 것이 좋습니다.

노드 레이블을 사용하는 경우 클러스터의 총 실행 단위는 관리형 조정 정책에 설정된 최대 컴퓨팅을 일시적으로 초과할 수 있는 반면, Amazon EMR은 일부 인스턴스를 해제합니다. 요청된 총 단위는 항상 정책의 최대 컴퓨팅 수치 이하로 유지됩니다.

관리형 조정은 노드 레이블 ON_DEMAND 및 SPOT 또는 CORE 및 TASK만 지원합니다. 사용자 지정 노드 레이블은 지원되지 않습니다.

Amazon EMR은 클러스터를 생성하고 리소스를 프로비저닝하는 경우 노드 레이블을 생성합니다. Amazon EMR은 클러스터를 재구성하는 경우 노드 레이블 추가를 지원하지 않습니다. 또한 클러스터를 시작한 후 관리형 조정을 구성하는 경우 노드 레이블을 수정할 수 없습니다.

관리형 조정은 애플리케이션 프로세스 및 실행기 수요에 따라 코어 및 태스크 노드를 독립적으로 조정합니다. 코어 스케일 다운 중에 HDFS 데이터 손실 문제를 방지하려면 코어 노드에 대한 표준 관행을 따릅니다. 코어 노드 및 HDFS 복제 관련 모범 사례에 대해 자세히 알아보려면 고려 사항 및 모범 사례를 참조하세요.

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 노드를 다시 커미셔닝하기 위해 애플리케이션을 다시 예약해야 할 가능성이 줄어듭니다.