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

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

클러스터 구성 모범 사례

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

어떤 인스턴스 유형을 사용해야 하나요?

클러스터에 Amazon EC2 인스턴스를 추가하는 여러 가지 방법이 있습니다. 선택해야 하는 방법은 클러스터의 인스턴스 그룹 구성을 사용하는지 아니면 인스턴스 플릿 구성을 사용하는지에 따라 달라집니다.

  • 인스턴스 그룹

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

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

    • Amazon EMR에서 인스턴스 그룹의 자동 크기 조정을 설정하여 지정한 Amazon CloudWatch 지표의 값에 따라 자동으로 인스턴스를 추가 및 제거합니다. 자세한 정보는 클러스터 조정 사용을 참조하세요.

  • 인스턴스 플릿

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

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

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

일반적으로 작업을 할당하는 프라이머리 노드 유형에는 높은 처리 기능을 갖춘 Amazon EC2 인스턴스가 필요하지 않지만, 작업을 처리하고 데이터를 HDFS에 저장하는 코어 노드 유형의 Amazon EC2 인스턴스에는 높은 처리 기능 및 스토리지 용량이 모두 필요합니다. 한편, 데이터를 저장하지 않는 태스크 노드 유형의 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에는 다음 속성과 값이 기본적으로 구성되어 있습니다. 이러한 속성을 구성할 때 각별히 주의하십시오.

참고

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

  • yarn.node-labels.enabled: true

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

  • 모든 노드에 대한 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 S3와 같은 외부 스토어에서 정기적으로 유지되는 클러스터가 있거나, 클러스터 완료보다 비용이 더 중요시되는 클러스터를 실행 중인 경우일 수 있습니다.

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

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

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

스팟 인스턴스의 코어 노드

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

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

스팟 인스턴스의 태스크 노드

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

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

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

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

애플리케이션 시나리오에 대한 인스턴스 구성

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

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

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

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

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

비용 기반 워크로드

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

데이터 중심 워크로드

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

애플리케이션 테스트

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

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

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

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

  • 사용되는 인스턴스 유형에 대한 Amazon EC2 인스턴스 스토어의 용량입니다. 인스턴스 스토리지 볼륨에 대한 자세한 내용은 Amazon EC2 사용 설명서의 Amazon 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 블록으로부터의 클러스터 복구 기능이 감소되므로 이 기능은 각별히 주의해서 사용해야 합니다.