클러스터 구성 지침 및 모범 사례 - Amazon EMR

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

클러스터 구성 지침 및 모범 사례

이 단원의 지침은 EMR 클러스터의 각 노드 유형에 대해 프로비저닝하기 위한 인스턴스 유형, 구매 옵션 및 스토리지 양을 결정하는 데 도움이 됩니다.

사용해야 할 인스턴스 유형은 무엇입니까?

클러스터에 인스턴스 그룹 구성 또는 인스턴스 집합 구성을 사용하는지 여부에 따라 Amazon EC2 인스턴스를 클러스터에 추가하는 여러 방법이 있습니다.

  • 인스턴스 그룹

    • 동일한 유형의 인스턴스는 수동으로 코어 및 작업 인스턴스 그룹에 추가합니다.

    • 다른 인스턴스 유형을 사용할 수 있는 작업 인스턴스 그룹을 수동으로 추가합니다.

    • Amazon EMR에서 인스턴스 그룹에 대한 자동 조정을 설정하여 Amazon의 값을 기반으로 인스턴스를 자동으로 추가 및 제거합니다. CloudWatch 지정한 메트릭입니다. 자세한 정보는 클러스터 리소스 조정을 참조하십시오.

  • 인스턴스 플릿

    • 단일 작업 인스턴스 집합을 추가합니다.

    • 기존 코어 및 작업 인스턴스 플릿에 대한 온디맨드 및 스팟 인스턴스의 대상 용량을 변경합니다. 자세한 정보는 인스턴스 집합 구성을 참조하십시오.

클러스터의 인스턴스를 계획하는 한 가지 방법은 대표 샘플 데이터 세트를 사용하여 테스트 클러스터를 실행하고 클러스터 내 노드의 사용률을 모니터링하는 것입니다. 자세한 정보는 클러스터 보기 및 모니터링을 참조하십시오. 또 한 가지 방법은 고려 중인 인스턴스의 용량을 계산하여 이 값을 데이터의 크기와 비교하는 것입니다.

일반적으로 작업을 할당하는 마스터 노드 유형에는 높은 처리 기능을 갖춘 EC2 인스턴스가 필요하지 않습니다. 작업을 처리하고 데이터를 HDFS에 저장하는 코어 노드 유형의 Amazon EC2 인스턴스에는 처리 기능과 스토리지 용량이 모두 필요합니다.데이터를 저장하고 처리 능력 만 있으면됩니다. 사용 가능한 Amazon EC2 인스턴스 및 관련 구성에 대한 지침은 단원을 참조하십시오.Amazon EC2 인스턴스 구성.

다음 지침은 대부분의 Amazon EMR 클러스터에 적용됩니다.

  • 에서 실행하는 온디맨드 Amazon EC2 인스턴스의 총 수에 대해 vCPU 제한이 있습니다.AWS계정당AWS 리전. vCPU 제한과 계정에 대한 한도 증가를 요청하는 방법에 대한 자세한 내용은 단원을 참조하십시오.온디맨드 인스턴스Amazon EC2 Linux 인스턴스용 사용 설명서.

  • 일반적으로 마스터 노드에는 큰 컴퓨팅 요구 사항이 수반되지 않습니다. 노드 수가 많은 클러스터나 마스터 노드 (JupyterHub, Hue 등) 에 특별히 배포된 응용 프로그램이 있는 클러스터의 경우 더 큰 마스터 노드가 필요할 수 있으며 클러스터 성능을 향상시키는 데 도움이 될 수 있습니다. 예를 들어, 소규모 클러스터 (50개 이하 노드) 에 m5.xlarge 인스턴스를 사용하고 더 큰 클러스터의 경우 더 큰 인스턴스 유형으로 늘리는 것이 좋습니다.

  • 코어 및 작업 노드의 컴퓨팅 요구는 애플리케이션에서 수행하는 처리 유형에 따라 달라집니다. 대부분의 작업은 범용 인스턴스 유형에서 실행할 수 있습니다. 이 인스턴스는 CPU, 디스크 공간 및 입/출력 면에서 균형된 성능을 제공합니다. 컴퓨팅 집약적인 클러스터는 RAM보다 비례적으로 더 많은 CPU를 사용할 수 있는 고성능 CPU 인스턴스의 실행에서 이점을 얻을 수 있습니다. 데이터베이스 및 메모리 캐싱 애플리케이션은 고용량 메모리 인스턴스의 실행에서 이점을 얻을 수 있습니다. 네트워크 집약적인 애플리케이션과 CPU 집약적인 애플리케이션 (예: 구문 분석, NLP 및 머신 러닝) 은 비례적으로 높은 CPU 리소스와 향상된 네트워크 성능을 제공하는 클러스터 컴퓨팅 인스턴스에서 실행되는 이점을 얻을 수 있습니다.

  • 클러스터의 각 단계마다 필요한 용량이 다른 경우 적은 코어 노드 수로 시작하여 작업 흐름의 가변 용량 요구 사항에 맞춰 작업 노드 수를 늘리거나 줄일 수 있습니다.

  • 처리할 수 있는 데이터 양은 입력 및 출력되거나 처리 중인 데이터의 크기와 코어 노드의 용량에 따라 달라집니다. 입력, 중간 및 출력 데이터 세트는 모두 처리 중에 클러스터에 상주합니다.

스팟 인스턴스는 언제 사용해야 합니까?

Amazon EMR에서 클러스터를 시작할 때 스팟 인스턴스에서 마스터, 코어 또는 작업 인스턴스를 시작하도록 선택할 수 있습니다. 각 인스턴스 그룹 유형이 클러스터에서 서로 다른 역할을 수행하므로 스팟 인스턴스에서 각 노드 유형이 시작됩니다. 클러스터 실행 도중에는 인스턴스 구매 옵션을 변경할 수 없습니다. 마스터 및 코어 노드의 경우 온디맨드에서 스팟 인스턴스로 변경하거나 그 반대로 변경하려면 클러스터를 종료하고 새 클러스터를 시작해야 합니다. 작업 노드의 경우 새 작업 인스턴스 그룹 또는 인스턴스 플릿을 시작하고 이전 그룹이나 플릿을 제거할 수 있습니다.

작업 노드 스팟 인스턴스 종료로 인해 작업 실패를 방지하기 위한 Amazon EMR 설정

작업 노드를 실행하는 데 종종 스팟 인스턴스가 사용되기 때문에 Amazon EMR은 YARN 작업을 위한 예약 기능을 제공하며 이를 통해 스팟 인스턴스에서 실행 중인 작업 노드가 종료될 경우 실행 중이던 작업이 실패하지 않습니다. Amazon EMR은 애플리케이션 마스터 프로세스가 코어 노드에서만 실행되게 함으로써 이를 지원합니다. 애플리케이션 마스터 프로세스는 실행 중인 작업을 제어하며, 작업 수명 동안 유지되어야 합니다.

Amazon EMR 릴리스 버전 5.19.0 이상에서는 기본 제공되는 YARN 노드 레이블 기능을 사용하여 이를 지원합니다. (이전 버전에서는 코드 패치를 사용했습니다.) 의 속성yarn-sitecapacity-scheduler구성 분류는 기본적으로 구성되므로 YARN capacity-scheduler 및 fair-scheduler는 노드 레이블을 활용합니다. Amazon EMR은 코어 노드에 자동으로 레이블을 지정합니다.CORE레이블을 지정하고 응용 프로그램 마스터가 CORE 레이블이 있는 노드에서만 예약되도록 속성을 설정합니다. yarn-site 및 capacity-scheduler 구성 분류에서 해당 속성을 수동으로 수정하거나, 연결된 XML 파일에서 직접 수정하면 이 기능이 작동하지 않거나 변경됩니다.

Amazon EMR은 기본적으로 다음 속성과 값을 구성합니다. 이러한 속성을 구성할 때 각별히 주의하십시오.

  • 모든 노드에 대한 yarn-site(yarn-site.xml)

    • yarn.node-labels.enabled: true

    • yarn.node-labels.am.default-node-label-expression: 'CORE'

    • yarn.node-labels.fs-store.root-dir: '/apps/yarn/nodelabels'

    • yarn.node-labels.configuration-type: 'distributed'

  • 마스터 및 코어 노드에 대한 yarn-site(yarn-site.xml)

    • yarn.nodemanager.node-labels.provider: 'config'

    • yarn.nodemanager.node-labels.provider.configured-node-partition: 'CORE'

  • 모든 노드에 대한 capacity-scheduler(capacity-scheduler.xml)

    • yarn.scheduler.capacity.root.accessible-node-labels: '*'

    • yarn.scheduler.capacity.root.accessible-node-labels.CORE.capacity: 100

    • yarn.scheduler.capacity.root.default.accessible-node-labels: '*'

    • yarn.scheduler.capacity.root.default.accessible-node-labels.CORE.capacity: 100

참고

Amazon EMR 6.x 릴리스 시리즈부터 YARN 노드 레이블 기능은 기본적으로 비활성화되어 있습니다. 애플리케이션 마스터 프로세스는 기본적으로 코어 및 작업 노드 모두에서 실행할 수 있습니다. 다음과 같은 속성을 구성하여 YARN 노드 레이블 기능을 활성화할 수 있습니다.

  • yarn.node-labels.enabled: true

  • yarn.node-labels.am.default-node-label-expression: 'CORE'

스팟 인스턴스의 마스터 노드

마스터 노드는 클러스터를 제어하고 지시합니다. 마스터 노드가 종료되면 클러스터가 종료되므로 갑작스런 종료를 허용할 수 있는 클러스터를 실행 중인 경우에만 마스터 노드를 스팟 인스턴스로 시작해야 합니다. 이는 새 애플리케이션을 테스트하거나 Amazon S3 S3와 같은 외부 스토어에 정기적으로 데이터를 유지하는 클러스터가 있거나, 클러스터 완료보다 비용이 더 중요시되는 클러스터를 실행 중인 경우일 수 있습니다.

마스터 인스턴스 그룹을 스팟 인스턴스로 시작할 경우 스팟 인스턴스 요청이 충족될 때까지 클러스터가 시작되지 않습니다. 최대 스팟 가격을 선택할 때 이 점을 고려해야 합니다.

클러스터를 시작할 때 스팟 인스턴스 마스터 노드만 추가할 수 있습니다. 실행 중인 클러스터에서 마스터 노드를 추가하거나 제거할 수는 없습니다.

일반적으로 전체 클러스터(모든 인스턴스 그룹)를 스팟 인스턴스로 실행 중이면 마스터 노드가 스팟 인스턴스로만 실행됩니다.

스팟 인스턴스의 코어 노드

코어 노드는 HDFS를 사용하여 데이터를 처리하고 정보를 저장합니다. 코어 인스턴스를 종료하면 데이터 손실의 위험이 있습니다. 따라서 일부 HDFS 데이터 손실이 허용되는 경우에만 스팟 인스턴스에서 코어 노드를 실행하십시오.

코어 인스턴스 그룹을 스팟 인스턴스로 시작하면 Amazon EMR은 인스턴스 그룹을 시작하기 전에 요청한 코어 인스턴스를 모두 프로비저닝할 수 있을 때까지 기다립니다. 즉, Amazon EC2 인스턴스 여섯 개를 요청했으며 최고 스팟 가격 이하에서 스팟 인스턴스 다섯 개만 사용할 수 있는 경우 인스턴스 그룹이 시작되지 않습니다. Amazon EMR은 6개의 Amazon EC2 인스턴스를 모두 사용할 수 있을 때까지 또는 사용자가 클러스터를 종료할 때까지 계속 대기합니다. 실행 중인 클러스터에 용량을 추가하기 위해 코어 인스턴스 그룹의 스팟 인스턴스 수를 변경할 수 있습니다. 인스턴스 그룹 작업 및 인스턴스 플릿에서의 스팟 인스턴스를 통한 작업 방법에 대한 자세한 내용은 인스턴스 플릿 또는 균일한 인스턴스 그룹을 사용하여 클러스터 생성 단원을 참조하십시오.

스팟 인스턴스의 작업 노드

작업 노드는 데이터를 처리하지만 HDFS에 영구 데이터를 보관하지 않습니다. 스팟 가격이 최대 스팟 가격보다 높아져서 작업 노드가 종료되는 경우 데이터가 손실되지 않으며 클러스터에 미치는 영향이 최소 수준입니다.

하나 이상의 작업 인스턴스 그룹을 스팟 인스턴스로 시작할 때 Amazon EMR은 최고 스팟 가격을 사용하여 최대한 많은 작업 노드를 프로비저닝합니다. 즉, 여섯 개 노드로 된 작업 인스턴스 그룹을 요청하고 최고 스팟 가격 이하에서 스팟 인스턴스 다섯 개만 사용할 수 있는 경우 Amazon EMR은 다섯 개 노드로 인스턴스 그룹을 시작하고 가능할 경우 나중에 여섯 번째 노드를 추가합니다.

작업 인스턴스 그룹을 스팟 인스턴스로 시작하는 방법은 비용을 최소화하면서 클러스터의 용량을 확장하는 전략적인 방법입니다. 온디맨드 인스턴스로 마스터 및 코어 인스턴스 그룹을 시작하는 경우에는 클러스터 실행 시 용량이 보장됩니다. 작업 인스턴스 그룹에 필요한 만큼 작업 인스턴스를 추가하여 피크 트래픽을 처리하거나 데이터 처리를 가속화할 수 있습니다.

콘솔, AWS CLI 또는 API를 사용하여 작업 노드를 추가 또는 제거할 수 있습니다. 또한 다른 작업 그룹을 추가할 수도 있지만, 작업 그룹은 일단 생성되고 나면 제거가 불가능합니다.

애플리케이션 시나리오를 위한 인스턴스 구성

다음 표에는 일반적으로 다양한 애플리케이션 시나리오에 적합한 노드 유형 구매 옵션 및 구성에 대한 빠른 참조가 나와 있습니다. 각 시나리오 유형에 대한 추가 정보를 보려면 링크를 선택하십시오.

애플리케이션 시나리오 마스터 노드 구매 옵션 코어 노드 구매 옵션 작업 노드 구매 옵션
장기 실행 클러스터 및 데이터 웨어하우스 온디맨드 온디맨드 또는 인스턴스 집합 조합 스팟 도는 인스턴스 집합 조합
비용 기반 워크로드 스팟 스팟 스팟
데이터 중심의 워크로드 온디맨드 온디맨드 스팟 도는 인스턴스 집합 조합
애플리케이션 테스트 스팟 스팟 스팟

Amazon EMR 클러스터를 실행할 때 스팟 인스턴스가 유용한 몇 가지 시나리오가 있습니다.

장기 실행 클러스터 및 데이터 웨어하우스

데이터 웨어하우스와 같이 컴퓨팅 용량이 예측 가능하게 변동되는 지속적 Amazon EMR 클러스터를 실행 중인 경우 스팟 인스턴스를 사용하여 최저 비용으로 피크 수요를 처리할 수 있습니다. 마스터 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 시작하여 일반 용량을 처리하고 작업 인스턴스 그룹을 스팟 인스턴스로 시작하여 피크 로드 요구 사항을 처리할 수 있습니다.

비용 기반 워크로드

완료 시간보다 비용을 낮추는 것이 더 중요한 일시적 클러스터를 실행 중이며 부분 작업 손실을 허용할 수 있는 경우, 전체 클러스터(마스터, 코어 및 작업 인스턴스 그룹)을 스팟 인스턴스로 실행하면 최대 비용 절감의 혜택을 얻을 수 있습니다.

데이터 중심의 워크로드

완료 시간보다 비용이 더 중요시되는 클러스터를 실행 중이지만 부분 작업을 잃는 것이 허용되지 않는 경우 마스터 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 시작하고 스팟 인스턴스의 하나 이상의 작업 인스턴스 그룹으로 보완합니다. 마스터 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 실행하면 데이터가 HDFS에 유지되며 스팟 시장 변동으로 인한 종료로부터 클러스터가 보호되는 한편, 작업 인스턴스 그룹을 스팟 인스턴스로 실행함으로써 누적되는 비용 절감의 혜택을 얻을 수 있습니다.

애플리케이션 테스트

프로덕션 환경 내 시작을 준비하기 위해 새 애플리케이션을 테스트하려는 경우 전체 클러스터(마스터, 코어 및 작업 인스턴스 그룹)를 스팟 인스턴스로 실행하면 테스트 비용을 낮출 수 있습니다.

클러스터에 필요한 HDFS 용량 계산

클러스터에 사용할 수 있는 HDFS 스토리지 양은 다음 인수에 따라 달라집니다.

  • 코어 노드에 사용할 Amazon EC2 인스턴스의 수입니다.

  • 사용되는 인스턴스 유형에 대한 Amazon EC2 인스턴스 스토어의 용량입니다. 인스턴스 스토어 볼륨에 대한 자세한 내용은 단원을 참조하십시오.Amazon Amazon EC2 인스턴스 스토어Linux 인스턴스용 Amazon EC2 사용 설명서.

  • 코어 노드에 연결된 Amazon EBS 볼륨의 개수와 크기

  • RAID형 중복성을 제공하기 위해 각 데이터 블록이 HDFS에 저장되는 방식을 의미하는 복제 인수. 기본적으로 복제 인수는 10개 이상의 코어 노드로 이루어진 클러스터의 경우 3이고, 4-9개 코어 노드로 구성된 클러스터의 경우 2이며, 3개 이하 노드로 구성된 클러스터의 경우 1입니다.

클러스터의 HDFS 용량을 계산하려면 코어 노드마다 인스턴스 스토어 볼륨 용량을 Amazon EBS 스토리지 용량 (사용되는 경우) 에 더합니다. 이 결과에 코어 노드 수를 곱한 합계를 코어 노드 수에 따른 복제 인수로 나눕니다. 예를 들어 연결된 Amazon EBS 볼륨이 없는 인스턴스 스토리지가 800GB인 i2.xlarge 유형의 코어 노드가 10개인 클러스터는 HDFS에 약 2,666GB를 사용할 수 있습니다 (10 노드 x 800GB ÷ 3 복제 요소).

계산된 HDFS 용량 값이 데이터보다 작으면 다음 방법으로 HDFS 스토리지의 양을 늘릴 수 있습니다.

  • 추가 Amazon EBS 볼륨으로 클러스터를 생성하거나 Amazon EBS 볼륨이 연결된 인스턴스 그룹을 기존 클러스터에 추가

  • 다른 코어 노드 추가

  • 스토리지 용량이 더 큰 Amazon EC2 인스턴스 유형 선택

  • 데이터 압축 사용

  • 하둡 구성 설정을 변경하여 복제 인수 낮추기

복제 인수를 낮추면 HDFS 데이터의 중복성과 손실/손상된 HDFS 블록으로부터의 클러스터 복구 기능이 감소되므로 이 기능은 각별히 주의해서 사용해야 합니다.