View a markdown version of this page

가상 클러스터 관리 - Amazon EMR

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

가상 클러스터 관리

가상 클러스터는 Amazon EMR이 등록된 Kubernetes 네임스페이스입니다. 가상 클러스터를 생성, 설명, 나열 및 삭제할 수 있습니다. 가상 클러스터는 시스템의 추가 리소스를 소비하지 않습니다. 단일 가상 클러스터는 단일 Kubernetes 네임스페이스에 매핑됩니다. 이 관계를 감안하면 Kubernetes 네임스페이스를 모형화하는 것과 동일한 방식으로 가상 클러스터를 모형화하여 요구 사항을 충족할 수 있습니다. Kubernetes Concepts Overview 설명서에서 가능한 사용 사례를 참조하세요.

Amazon EMR을 Amazon EKS 클러스터의 Kubernetes 네임스페이스에 등록하려면 EKS 클러스터의 이름과 워크로드를 실행하기 위해 설정된 네임스페이스가 필요합니다. Amazon EMR에 등록된 이러한 클러스터는 물리적 컴퓨팅 또는 스토리지를 관리하지 않고 워크로드가 예약된 Kubernetes 네임스페이스를 가리키므로 가상 클러스터라고 합니다.

참고

가상 클러스터를 생성하기 전에 먼저 Amazon EMR on EKS 설정에서 1~8단계를 완료해야 합니다.

가상 클러스터 생성

다음 명령을 실행하여 Amazon EMR을 EKS 클러스터의 네임스페이스에 등록하여 가상 클러스터를 생성합니다. virtual_cluster_name을 사용자가 제공한 가상 클러스터 이름으로 바꿉니다. eks_cluster-name을 EKS 클러스터 이름으로 바꿉니다. namespace_name을 네임스페이스(Amazon EMR을 등록하려는 네임스페이스)로 바꿉니다.

aws emr-containers create-virtual-cluster \ --name virtual_cluster_name \ --container-provider '{ "id": "eks_cluster_name", "type": "EKS", "info": { "eksInfo": { "namespace": "namespace_name" } } }'

또는 다음 예제에서 볼 수 있듯이 가상 클러스터에 필요한 파라미터가 포함된 JSON 파일을 생성할 수 있습니다.

{ "name": "virtual_cluster_name", "containerProvider": { "type": "EKS", "id": "eks_cluster_name", "info": { "eksInfo": { "namespace": "namespace_name" } } } }

그런 다음, JSON 파일 경로와 함께 다음 create-virtual-cluster 명령을 실행합니다.

aws emr-containers create-virtual-cluster \ --cli-input-json file://./create-virtual-cluster-request.json
참고

가상 클러스터가 생성되었는지 확인하려면 list-virtual-clusters 명령을 실행하거나 Amazon EMR 콘솔의 가상 클러스터 페이지로 이동하여 가상 클러스터의 상태를 확인합니다.

가상 클러스터 나열

가상 클러스터 상태를 보려면 다음 명령을 실행합니다.

aws emr-containers list-virtual-clusters

가상 클러스터 설명

다음 명령을 실행하여 네임스페이스, 상태, 등록 날짜 등 가상 클러스터에 대한 자세한 내용을 확인합니다. 123456을 가상 클러스터 ID로 바꿉니다.

aws emr-containers describe-virtual-cluster --id 123456

가상 클러스터 삭제

다음 명령을 실행하여 가상 클러스터를 삭제합니다. 123456을 가상 클러스터 ID로 바꿉니다.

aws emr-containers delete-virtual-cluster --id 123456

가상 클러스터 상태

다음 테이블에서는 가상 클러스터의 네 가지 가능한 상태를 설명합니다.

State 설명

RUNNING

가상 클러스터가 RUNNING 상태입니다.

TERMINATING

요청한 가상 클러스터 종료가 진행 중입니다.

TERMINATED

요청한 종료가 완료되었습니다.

ARRESTED

권한이 부족하여 요청한 종료에 실패했습니다.

가상 클러스터에 대한 동시 작업 제한

Amazon EMR on EKS 가상 클러스터에서 동시 작업 제한을 구성하여 동시에 실행되는 작업 실행 수와 대기열에서 대기할 수 있는 작업 수를 제어할 수 있습니다. 동시성 제한(maxConcurrentJobRuns)과 대기열 깊이(maxInQueueJobRuns)를 독립적으로 설정하므로 실행 중인 작업 실행, 대기 중인 작업 실행 또는 둘 다에 제한을 둘 수 있습니다. 이러한 제한을 설정하면 StartJobRun API는 가상 클러스터 수준에서 역압을 제공합니다. 작업은 즉시 시작하는 대신 SUBMITTED 또는 PENDING 상태의 대기열에서 실행 한도 대기를 초과하여 실행되며 대기열이 가득 차면가 추가 제출을 StartJobRun 거부합니다. 예를 들어 동시 작업 실행 500개와 대기 중인 작업 실행 100개를 허용하도록 가상 클러스터를 설정하면 101번째 대기 중인 제출이 거부되고 동일한 EKS 클러스터의 다른 가상 클러스터에서 해당 워크로드를 재조정하거나 용량을 추가할 수 있습니다. 동시성 제한을 설정하지 않았고 대기열 깊이가 계속 증가하여 작업 실행이 시작되기 전에 더 오래 SUBMITTED 또는 PENDING 상태로 유지되면 기본 EKS 클러스터가 컴퓨팅 리소스에서 부족하고 새 포드를 충분히 빠르게 예약할 수 없다는 신호를 보낼 수 있습니다. 이 경우 워크로드를 다른 클러스터로 라우팅하거나 용량을 추가합니다.

동시 작업 제한은 Kubernetes 스케줄러와 Kubernetes 웹 사이트의 ResourceQuota 기능 앞에 제어 계층을 추가합니다. 포드가 생성되기 StartJobRun전에에서 적용되므로 초과 로드는 API에서 대기열에 추가되거나 거부되어 작업에 도달하기 전에 기본 클러스터를 보호합니다. Kubernetes는 여전히 실제 CPU 및 메모리 상한을 적용합니다.

동시 작업 제한의 주요 이점

  • 노이즈-이웃 오버로드 방지 - 가상 클러스터당 실행 중인 작업과 대기 중인 작업 실행 수를 제한하므로 단일 가상 클러스터가 공유 EKS 클러스터를 독점할 수 없고 다른 가상 클러스터에 대해 노이즈-이웃 예약 실패를 일으킬 수 있습니다.

  • 트래픽 셰이핑 활성화 - 가상 클러스터의 대기열이 가득 차면 즉시 거부를 반환하므로 단일 가상 클러스터를 압도하는 대신 다른 가상 클러스터로 제출을 리디렉션할 수 있습니다.

  • 가시성 제공 - 네AWS/EMRContainers임스페이스에서 활성 JobsRunning 및 대기열 내 작업 실행 수에 대한 per-virtual-cluster 및 JobsInQueue CloudWatch 지표를 5분마다 내보내므로 예약에 대한 상태 신호를 제공합니다.

동시 작업 제한 시작하기

가상 클러스터의 schedulerConfiguration 필드를 사용하여 동시 작업 제한을 구성합니다. 이 필드에는 다음 두 가지 파라미터가 허용됩니다.

maxConcurrentJobRuns

언제든지 RUNNING 상태일 수 있는 최대 작업 실행 수입니다.

maxInQueueJobRuns

언제든지 PENDING 또는 SUBMITTED 상태(대기열 깊이)에 있을 수 있는 최대 작업 실행 수입니다.

AWS CLI

가상 클러스터를 생성할 때 제한을 설정하려면 요청에 schedulerConfiguration를 지정합니다.

aws emr-containers create-virtual-cluster \ --name my-virtual-cluster \ --container-provider '{ ... }' \ --scheduler-configuration '{ "maxConcurrentJobRuns": 500, "maxInQueueJobRuns": 100 }'

기존 가상 클러스터에 대한 제한을 변경하려면 update-virtual-cluster 명령을 사용합니다.

aws emr-containers update-virtual-cluster \ --id virtual-cluster-id \ --scheduler-configuration '{ "maxConcurrentJobRuns": 500, "maxInQueueJobRuns": 100 }'

가상 클러스터에서 제한을 제거하려면 빈를 전달합니다schedulerConfiguration. 이렇게 하면 구성이 지워지므로 제한이 적용되지 않고 가상 클러스터가 기본(무제한) 동작으로 돌아갑니다. 대신 요청schedulerConfiguration에서를 생략하면 기존 제한은 변경되지 않습니다. 이를 지우려면 빈 객체를 전달해야 합니다.

aws emr-containers update-virtual-cluster \ --id virtual-cluster-id \ --scheduler-configuration '{}'

현재 제한 및 라이브 작업 수를 보려면 describe-virtual-cluster 명령을 사용합니다. 응답에는와 현재 schedulerConfigurationactiveJobRunCount가 있는 SchedulerStatus 객체가 모두 포함됩니다inQueueJobRunCount.

참고

대기열이 가득 찬 가상 클러스터에 작업 실행을 제출하면가를 StartJobRun 반환합니다ValidationException.

maxConcurrentJobRuns 및 maxInQueueJobRuns에 대한 값 선택

올바른 제한은 Amazon EKS 클러스터가 한 번에 실행할 수 있는 작업량, 제출이 급증하는 정도, 가상 클러스터가 가득 차면 가상 클러스터가 어떻게 작동하는지 등 세 가지 사항에 따라 달라집니다. 다음 지침에 따라 시작점을 선택한 다음 라이브 카운터에서 구체화합니다.

maxConcurrentJobRuns 설정(실행 슬롯)

maxConcurrentJobRuns는 작업 세분화, 개수 기반 가드레일입니다. 여기서 대략적인 추정치는 기본 Amazon EKS 클러스터가 로드로 인해 저하되는 것을 방지하고 가용성을 개선할 수 있습니다.

  • 작업당 공간으로 나눈 용량부터 시작합니다. 각 작업 요청(드라이버, 실행기 및 메모리 오버헤드)을 기반으로 하며 네임스페이스 용량의 약 70~80%를 대상으로 드라이버 오버헤드, 노드 스케일 업 및 버스트를 위한 여유 공간을 확보합니다.

  • 각 작업의 크기를 제한합니다(티스 크기 조정). 모든 작업을 로 바인딩spark.dynamicAllocation.maxExecutors하고 스몰(실행기 20개), 미디엄(100개) 및 라지(약 500개)와 같은 몇 가지 크기로 표준화하면 가변 평균에 대해 과다 프로비저닝 또는 과소 프로비저닝 대신 캡 맵을 예상대로 용량에 maxConcurrentJobRuns곱할 수 있습니다. 가장 깨끗한 수학을 위해 각 크기 클래스를 자체 가상 클러스터로 라우팅합니다.

  • 라이브 카운터에서 튜닝합니다. 보수적으로 시작하고 AWS/EMRContainers 네임스페이스에서 activeJobRunCountJobsRunning 지표를 보는 동안 값을 점진적으로 높입니다.

maxInQueueJobRuns 설정(대기열 깊이)

maxInQueueJobRuns는 가상 클러스터가 제출 거부를 시작하기 전에 수락하는 백로그의 크기를 제어합니다. 버스트 흡수 버퍼입니다. 다음 요소를 고려하세요.

  • 버스트 프로파일 - 실행 속도 이상으로 예상되는 제출 버스트를 흡수하도록 대기열의 크기를 조정합니다. 예약된 파이프라인이 한 번에 많은 작업을 실행하면 대기열이 깊어지면 허위 거부가 방지됩니다. 의 고정된 배수가 아닌 예상 버스트 크기를 기준으로 깊이를 maxConcurrentJobRuns설정하고 다음 드레이닝 시간 제한과 비교하여 검증합니다.

  • 허용 가능한 대기 시간 - 대기 중인 작업은 실행 중인 슬롯이 확보될 때까지 기다립니다. 전체 대기열의 후면에 있는 작업은 대기열 깊이를 대략 완료 처리량으로 나눈 값으로 대기합니다. 예를 들어 작업이 분당 N으로 완료되고 대기열에 Q가 있는 경우 테일은 Q를 N분으로 나눈 값을 기다립니다. 이를 SLA 내에 유지합니다. 슬롯이 비워지지 않으면 버퍼링된 작업이 30분 후에 실패하므로 전체 대기열이 안정적인 완료율로 30분 이내에 충분히 maxInQueueJobRuns작게 유지하십시오. 그렇지 않으면 대기 중인 작업이 시간 초과됩니다.

  • 버퍼링과 비교한 역압 - 대기열이 깊을수록 버스트가 부드러워지지만 트래픽 셰이핑에 사용하는 대기열 전체 거부가 지연되고 테일 지연 시간이 증가합니다. 얕은 대기열은 빠르게 실패하므로 클라이언트가 다른 곳으로 재시도하거나 라우팅할 수 있는 실행 가능한 신호를 조기에 얻을 수 있습니다. 로드를 버퍼링할지 아니면 셰이프 및 리디렉션할지를 기준으로 선택합니다.

  • 클라이언트 재시도 동작 - 대기열이 가득 차면가를 StartJobRun 반환합니다ValidationException. 제출자가이 예외를 처리해야 합니다. 백오프를 사용하여 재시도하거나 워크로드를 다른 가상 클러스터로 라우팅합니다. 거부가 일상적인 작업이 아닌 실제 오버로드 중에만 발생하도록 깊이를 설정합니다.

동시 작업 제한 고려 사항

  • 기본적으로 제한이 적용되지 않습니다. 를 명시적으로 설정하지 않는 한 기존 가상 클러스터 및 워크로드는 영향을 받지 않습니다schedulerConfiguration.

  • 카운터는 분산 시스템에서 유지 관리되므로 경우에 따라 실제 값에서 약간의 일시적 델타를 예상할 수 있습니다. 내부 조정은 모든 드리프트를 수정합니다.