Amazon EMR에서 Managed Scaling 사용 - Amazon EMR
개요가용성파라미터고려 사항기능 기록

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon EMR에서 Managed Scaling 사용

중요

스케일링 관리에는 최신 Amazon EMR 릴리스 (Amazon EMR 7.1.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 가용성 섹션을 참조하세요.

개요

Amazon EMR 버전 5.30.0 이상(Amazon EMR 6.0.0 제외)에서는 Amazon EMR Managed Scaling을 활성화할 수 있습니다. Managed Scaling을 활성화하면 워크로드에 따라 클러스터에서 인스턴스 또는 유닛 수를 자동으로 늘리거나 줄일 수 있습니다. Amazon EMR은 클러스터 지표를 지속적으로 평가하여 비용과 속도 측면에서 클러스터를 최적화하는 조정 결정을 내립니다. Managed Scaling은 인스턴스 그룹 또는 인스턴스 플릿으로 구성된 클러스터에 사용할 수 있습니다.

Managed Scaling 가용성

  • Amazon EMR 6.14.0 AWS 리전이상에서는 다음과 같이 Amazon EMR 관리형 규모 조정을 사용할 수 있습니다.

    • 아시아 태평양(하이데라바드)(ap-south-2)

    • 아시아 태평양(자카르타) (ap-southeast-3)

    • 유럽(스페인)(eu-south-2)

  • 다음은 Amazon EMR 5.30.0 AWS 리전및 6.1.0 이상에서 Amazon EMR 관리형 크기 조정을 사용할 수 있습니다.

    • 미국 동부(버지니아 북부)(us-east-1)

    • 미국 동부(오하이오)(us-east-2)

    • 미국 서부(오레곤)(us-west-2)

    • 미국 서부(캘리포니아 북부)(us-west-1)

    • 아프리카(케이프타운)(af-south-1)

    • 아시아 태평양(홍콩)(ap-east-1)

    • 아시아 태평양(뭄바이)(ap-south-1)

    • 아시아 태평양(서울)(ap-northeast-2)

    • 아시아 태평양(싱가포르)(ap-southeast-1)

    • 아시아 태평양(시드니)(ap-southeast-2)

    • 아시아 태평양(도쿄)(ap-northeast-1)

    • 캐나다(중부)(ca-central-1)

    • 남아메리카(상파울루)(sa-east-1)

    • 유럽(프랑크푸르트)(eu-central-1)

    • 유럽(아일랜드)(eu-west-1)

    • 유럽(런던) (eu-west-2)

    • 유럽(밀라노) (eu-south-1)

    • 유럽(파리) (eu-west-3)

    • 유럽(스톡홀름) (eu-north-1)

    • 중국(베이징) (cn-north-1)

    • 중국(닝샤) (cn-northwest-1)

    • AWS GovCloud (미국 동부) (-1) us-gov-east

    • 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개의 온디맨드 인스턴스로 스케일 업하고 나머지 용량을 스팟 인스턴스에 할당합니다. 자세한 정보는 노드 할당 시나리오을 참조하세요.

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

    • 이 파라미터는 코어 노드와 태스크 노드 간에 용량 할당을 분할하는 데 사용됩니다. 예를 들어 최소 파라미터를 인스턴스 2개, 최대 인스턴스 100개, 최대 코어 노드를 인스턴스 17개로 설정하는 경우 Amazon EMR Managed Scaling은 최대 17개의 코어 노드를 스케일 업하고 나머지 83개 인스턴스를 태스크 노드에 할당합니다. 자세한 정보는 노드 할당 시나리오을 참조하세요.

Managed Scaling 파라미터에 대한 자세한 내용은 ComputeLimits 섹션을 참조하세요.

Amazon EMR Managed Scaling에 대한 고려 사항

  • 관리형 확장은 제한적 AWS 리전 및 Amazon EMR 릴리스에서 지원됩니다. 자세한 정보는 Managed Scaling 가용성을 참조하세요.

  • Amazon EMR Managed Scaling에 필요한 파라미터를 구성해야 합니다. 자세한 정보는 Managed Scaling 파라미터을 참조하세요.

  • Managed Scaling을 사용하려면 metrics-collector 프로세스를 API Gateway에서 Managed Scaling에 대한 퍼블릭 API 엔드포인트에 연결할 수 있어야 합니다. 와 함께 프라이빗 DNS 이름을 사용하는 Amazon Virtual Private Cloud경우 관리형 스케일링이 제대로 작동하지 않습니다. 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 CloudWatch 지표는 Amazon EMR 관리형 규모 조정이 운영되는 데 매우 중요합니다. 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 관리형 보안 그룹을 참조하세요.

  • Managed Scaling은 YARN 노드 레이블 기능을 지원하지 않습니다. Managed Scaling을 사용하는 클러스터에서는 노드 레이블을 사용하지 마세요. 예를 들어 실행기가 태스트 노드에서만 실행되도록 허용하지 마세요. Amazon EMR 클러스터에서 노드 레이블을 사용하면 클러스터가 스케일 업되지 않아 애플리케이션 속도가 느려질 수 있습니다.

  • 를 AWS CloudFormation 사용하여 Amazon EMR 관리형 조정을 구성할 수 있습니다. 자세한 내용은 AWS CloudFormation 사용 설명서를 참조하십시오 AWS::EMR::Cluster.

기능 기록

이 테이블에는 Amazon EMR Managed Scaling 기능에 대한 업데이트가 나열되어 있습니다.

릴리스 날짜 기능 Amazon EMR 버전
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을 개선했습니다. 자세한 정보는 노드 할당 전략 및 시나리오 이해을 참조하세요. 5.34.0 이상, 6.4.0 이상
2022년 3월 21일 클러스터를 스케일 다운할 때 사용되는 Spark 셔플 데이터 인식을 추가했습니다. Apache Spark가 있고 Managed Scaling이 활성화된 Amazon EMR 클러스터의 경우 Amazon EMR은 Spark 실행기 및 중간 셔플 데이터 위치를 지속적으로 모니터링합니다. Amazon EMR은 이 정보를 사용하여 사용률이 낮은 인스턴스(활발하게 사용되는 셔플 데이터를 포함하지 않음)를 스케일 다운합니다. 이렇게 하면 손실된 셔플 데이터가 재계산되지 않으므로 비용을 절감하고 작업 성과를 개선하는 데 도움이 됩니다. 자세한 내용은 Spark Programming Guide를 참조하세요. 5.34.0 이상, 6.4.0 이상