기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# Amazon EMR에서 사용할 Amazon EC2 인스턴스 유형을 구성합니다.
EC2 인스턴스는 *인스턴스 유형*이라고 하는 다양한 구성으로 제공됩니다. 인스턴스 유형마다 CPU, 입출력 및 스토리지 용량이 다릅니다. 인스턴스 유형 외에도, Amazon EC2 인스턴스에 대해 서로 다른 구매 옵션을 선택할 수 있습니다. 균일한 인스턴스 그룹이나 인스턴스 플릿 내에서 다양한 인스턴스 유형 및 구매 옵션을 지정할 수 있습니다. 자세한 내용은 [인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성](emr-instance-group-configuration.md) 단원을 참조하십시오. 애플리케이션의 인스턴스 유형 및 구매 옵션 선택에 대한 지침은 [스팟 인스턴스에 대한 Amazon EMR 클러스터 인스턴스 유형 및 모범 사례 구성](emr-plan-instances-guidelines.md) 섹션을 참조하세요.
**중요**
를 사용하여 인스턴스 유형을 선택하면 각 **인스턴스 유형에** 대해 표시되는 **vCPU** AWS Management Console수는 해당 인스턴스 유형에 대한 EC2 vCPUs 수입니다. 인스턴스 유형별 vCPU 수에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
**Topics**
+ [
# Amazon EMR에서 지원되는 인스턴스 유형
](emr-supported-instance-types.md)
+ [
# Amazon EMR에 대해 VPC에서 네트워킹 구성
](emr-plan-vpc-subnet.md)
+ [
# 인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성
](emr-instance-group-configuration.md)
# Amazon EMR에서 지원되는 인스턴스 유형
이 섹션에서는 Amazon EMR에서 지원되는 AWS 리전별 인스턴스 유형을 설명합니다. 인스턴스 유형에 대한 자세한 내용은 [Amazon EC2 인스턴스](https://aws.amazon.com/ec2/instance-types/) 및 [Amazon Linux AMI 인스턴스 유형 매트릭스](https://aws.amazon.com/amazon-linux-ami/instance-type-matrix/)를 참조하세요.
모든 리전에서 일부 인스턴스 유형은 사용할 수 없으며, 인스턴스 가용성은 지정된 리전 및 가용 영역의 가용성 및 수요에 따라 달라집니다. 인스턴스의 가용 영역은 클러스터를 시작하는 데 사용하는 서브넷에 따라 결정됩니다.
## 고려 사항
Amazon EMR 클러스터에 대한 인스턴스 유형을 선택할 때 다음 사항을 고려합니다.
**중요**
를 사용하여 인스턴스 유형을 선택하면 각 **인스턴스 유형에** 대해 표시되는 **vCPU** AWS Management Console수는 해당 인스턴스 유형에 대한 EC2 vCPUs 수입니다. 인스턴스 유형별 vCPU 수에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
+ 지정된 리전 및 가용 영역에서 사용할 수 없는 인스턴스 유형을 사용하여 클러스터를 생성하는 경우, 클러스터가 프로비저닝에 실패하거나 프로비저닝 중에 멈출 수 있습니다. 인스턴스 가용성에 대한 자세한 내용은 [Amazon EMR 요금 페이지](https://aws.amazon.com/emr/pricing) 또는 이 페이지의 [에서 지원되는 인스턴스 유형 AWS 리전](#emr-instance-types-by-region) 테이블을 참조하세요.
+ Amazon EMR 릴리스 버전 5.13.0부터 모든 인스턴스에서는 루트 볼륨에 대해 HVM 가상화 및 EBS 지원 스토리지가 사용됩니다. 5.13.0 이전의 Amazon EMR 릴리스 버전을 사용하는 경우 일부 이전 세대 인스턴스에서는 PVM 가상화가 사용됩니다. 자세한 내용은 [Linux AMI 가상화 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html)을 참조하세요.
+ 5.36.1 및 6.10.0 미만의 Amazon EMR 릴리스를 실행하는 경우 메모리 및 코어의 사용률을 낮출 수 있는 하드웨어 지원 및 기본 설정이 부족하므로 인스턴스 유형 `c7a`, `c7i`, `m7i`, `m7i-flex`, `r7a`, `r7i`, `r7iz`, `i4i.12xlarge`, `i4i.24xlarge`를 사용하는 것이 좋습니다. 이러한 릴리스에서 이러한 인스턴스 유형을 실행하면 성능이 저하될 수 있으며, `c7i` 및 `c6i`와 같은 최신 인스턴스 유형의 예상 이점이 나타나지 않습니다. 이러한 성능 유형에서 리소스 사용률과 성능을 최적화하려면 5.36.1 이상 또는 6.10.0 이상을 실행하여 기능을 극대화해야 합니다.
+ 일부 인스턴스 유형은 향상된 네트워킹을 지원합니다. 자세한 내용은 [Linux에서 향상된 네트워킹](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html)을 참조하세요.
+ 기본적으로 GPU 인스턴스 유형에는 NVIDIA 및 CUDA 드라이버가 설치됩니다.
## 에서 지원되는 인스턴스 유형 AWS 리전
다음 표에는 Amazon EMR이 지원하는 Amazon EC2 인스턴스 유형이 정리되어 있습니다 AWS 리전. 또한 테이블에는 각 인스턴스 유형을 지원하는 5.x, 6.x 또는 7.x 시리즈 중 가장 초기의 Amazon EMR 릴리스가 나열되어 있습니다.
### 미국 동부(버지니아 북부) - us-east-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 미국 동부(오하이오) - us-east-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 미국 서부(캘리포니아 북부) - us-west-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 미국 서부(오리건) - us-west-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### AWS GovCloud(미국 서부) - us-gov-west-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### AWS GovCloud(미국 동부) - us-gov-east-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아프리카(케이프타운) – af-south-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(홍콩) - ap-east-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(자카르타) – ap-southeast-3
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(멜버른) – ap-southeast-4
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(말레이시아) - ap-southeast-5
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(뭄바이) - ap-south-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(하이데라바드) - ap-south-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(오사카) – ap-northeast-3
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(서울) - ap-northeast-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(싱가포르) - ap-southeast-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(시드니) - ap-southeast-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(도쿄) - ap-northeast-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 캐나다(중부) - ca-central-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 캐나다 서부(캘거리) - ca-west-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 중국(닝샤) - cn-northwest-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 중국(베이징) - cn-north-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(프랑크푸르트) eu-central-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(취리히) - eu-central-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(아일랜드) - eu-west-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(런던) eu-west-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(밀라노) – eu-south-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(스페인) - eu-south-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(파리) - eu-west-3
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 유럽(스톡홀름) - eu-north-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 이스라엘 (텔아비브) - il-central-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 중동(바레인) – me-south-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 중동(UAE) - me-central-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 남아메리카(상파울루) - sa-east-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(태국) - ap-southeast-7
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 멕시코(중부) - mx-central-1
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(타이베이) - ap-east-2
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
### 아시아 태평양(뉴질랜드) - ap-southeast-6
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-supported-instance-types.html)
## 이전 세대 인스턴스
Amazon EMR은 이전 세대 인스턴스를 지원하여 이러한 인스턴스에 대해 최적화되어 있지만 아직 업그레이드되지 않은 애플리케이션을 지원합니다. 이러한 인스턴스 유형 및 업그레이드 경로에 대한 자세한 내용은 [이전 세대 인스턴스](https://aws.amazon.com/ec2/previous-generation)를 참조하세요.
| 인스턴스 클래스 | 인스턴스 유형 |
| --- | --- |
| General Purpose | m1.small¹ \$1 m1.medium¹ \$1 m1.large¹ \$1 m1.xlarge¹ \$1 m3.xlarge¹ \$1 m3.2xlarge¹ \$1 m4.large \$1 m4.xlarge \$1 m4.2xlarge \$1 m4.4xlarge \$1 m4.10xlarge \$1 m4.16xlarge |
| Compute Optimized | c1.medium¹ ² \$1 c1.xlarge¹ \$1 c3.xlarge¹ \$1 c3.2xlarge¹ \$1 c3.4xlarge¹ \$1 c3.8xlarge¹ \$1 c4.large \$1 c4.xlarge \$1 c4.2xlarge \$1 c4.4xlarge \$1 c4.8xlarge |
| Memory Optimized | m2.xlarge¹ \$1 m2.2xlarge¹ \$1 m2.4xlarge¹ \$1 r3.xlarge \$1 r3.2xlarge \$1 r3.4xlarge \$1 r3.8xlarge \$1 r4.xlarge \$1 r4.2xlarge \$1 r4.4xlarge \$1 r4.8xlarge \$1 r4.16xlarge |
| Storage Optimized | d2.xlarge \$1 d2.2xlarge \$1 d2.4xlarge \$1 d2.8xlarge \$1 i2.xlarge \$1 i2.2xlarge \$1 i2.4xlarge \$1 i2.8xlarge |
¹ 5.13.0 이전의 Amazon EMR 릴리스 버전과 함께 PVM 가상화 AMI를 사용합니다. 자세한 내용은 [Linux AMI 가상화 유형](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html)을 참조하세요.
² 릴리스 버전 5.15.0에서는 지원되지 않습니다.
# Amazon EMR에서 인스턴스 구매 옵션
클러스터를 설정할 때 Amazon EC2 인스턴스의 구매 옵션을 선택합니다. 온디맨드 인스턴스, 스팟 인스턴스 또는 둘 다 선택할 수 있습니다. 가격은 인스턴스 유형과 리전에 따라 달라집니다. Amazon EMR 가격은 Amazon EC2 가격(기본 서버 가격) 및 Amazon EBS 가격(Amazon EBS 볼륨을 연결하는 경우)에 추가로 부과됩니다. 현재 요금은 [Amazon EMR 요금](https://aws.amazon.com/emr/pricing)을 참조하세요.
클러스터에서 인스턴스 그룹이나 인스턴스 플릿을 사용하도록 선택하면 클러스터 실행 도중에 인스턴스 구매 옵션을 변경하는 방법이 결정됩니다. 균일한 인스턴스 그룹을 선택하는 경우, 인스턴스를 생성할 때에만 인스턴스 그룹의 구매 옵션을 지정할 수 있고, 각 인스턴스 그룹의 모든 Amazon EC2 인스턴스에 해당 인스턴스 유형 및 구매 옵션이 적용됩니다. 인스턴스 플릿을 선택하는 경우, 인스턴스 플릿을 생성한 후 구매 옵션을 변경할 수 있으며 지정하는 대상 용량을 충족하기 위해 구매 옵션을 혼합할 수도 있습니다. 이러한 구성에 대한 자세한 내용은 [인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성](emr-instance-group-configuration.md) 섹션을 참조하세요.
## 온디맨드 인스턴스
온디맨드 인스턴스를 사용하면 초 단위로 컴퓨팅 용량 비용을 지급합니다. 또는 이러한 온디맨드 인스턴스에서 예약 인스턴스나 전용 인스턴스 구매 옵션을 사용하도록 설정할 수도 있습니다. 예약 인스턴스를 사용하면 인스턴스에 대한 일회성 지불을 통해 용량을 예약할 수 있습니다. 전용 인스턴스는 호스트 하드웨어 수준에서 다른 AWS 계정에 속한 인스턴스와 물리적으로 격리됩니다. 구매 옵션에 대한 자세한 내용은 **Amazon EC2 사용 설명서에서 [인스턴스 구매 옵션](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html)을 참조하세요.
### 예약 인스턴스 사용
Amazon EMR에서 예약 인스턴스를 사용하려면 Amazon EC2를 사용하여 예약 인스턴스를 구매하고 리전이나 가용 영역에 적용할 때 예약 범위를 비롯하여 예약 파라미터를 지정할 수 있습니다. 자세한 내용은 **Amazon EC2 사용 설명서에서 [Amazon EC2 예약 인스턴스](https://aws.amazon.com/ec2/reserved-instances/) 및 [예약 인스턴스 구입](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-concepts-buying.html)을 참조하세요. 예약 인스턴스를 구매한 후 다음 조건이 모두 true이면 클러스터가 시작될 때 Amazon EMR에서 예약 인스턴스가 사용됩니다.
+ 온디맨드 인스턴스는 예약 인스턴스 사양과 일치하는 클러스터 구성에 지정됩니다.
+ 클러스터가 인스턴스 예약 범위(가용 영역이나 리전) 내에서 시작됩니다.
+ 예약 인스턴스 용량을 여전히 사용할 수 있습니다.
예를 들면 인스턴스 예약 범위가 미국 동부 리전으로 지정된 `m5.xlarge` 예약 인스턴스 하나를 구매한다고 가정합니다. 다음에는 두 `m5.xlarge` 인스턴스를 사용하는 미국 동부에서 Amazon EMR 클러스터를 시작할 수 있습니다. 첫 번째 인스턴스에는 예약 인스턴스 요금이 청구되고 다른 하나에는 온디맨드 요금이 청구됩니다. 예약 인스턴스 용량은 온디맨드 인스턴스를 생성하기 전에 사용됩니다.
### 전용 인스턴스 사용
전용 인스턴스를 사용하려면 Amazon EC2를 사용하여 전용 인스턴스를 구매한 다음, **전용** 테넌시 속성을 사용하여 VPC를 생성합니다. 그런 다음 Amazon EMR 내에서 클러스터가 이 VPC에서 시작되도록 지정합니다. 클러스터에서 전용 인스턴스 사양과 일치하는 온디맨드 인스턴스에서는 클러스터 시작 시 사용 가능한 전용 인스턴스가 사용됩니다.
**참고**
Amazon EMR에서는 개별 인스턴스에 대한 `dedicated` 속성 설정을 지원하지 않습니다.
## 스팟 인스턴스
Amazon EMR의 스팟 인스턴스는 온디맨드 구매에 비해 절감된 비용으로 Amazon EC2 인스턴스 용량을 구매할 수 있는 옵션을 제공합니다. 스팟 인스턴스 사용의 단점은 실행 중인 인스턴스 유형에서 스팟 용량을 사용할 수 없으면 인스턴스가 종료될 수 있다는 점입니다. 애플리케이션에 대해 스팟 인스턴스를 사용하는 것이 적합한 경우에 대한 자세한 내용은 [스팟 인스턴스는 언제 사용해야 하나요?](emr-plan-instances-guidelines.md#emr-plan-spot-instances) 섹션을 참조하세요.
Amazon EC2에 미사용 용량이 있는 경우 *스팟 요금*이라고 하는 절감된 가격으로 EC2 인스턴스를 제공합니다. 이 가격은 가용성 및 수요에 따라 변동되며 리전 및 가용 영역별로 설정됩니다. 스팟 인스턴스를 선택할 때 각 EC2 인스턴스 유형에 지불하고자 하는 최고 스팟 가격을 지정합니다. 클러스터의 가용 영역 내 스팟 가격이 해당 인스턴스 유형에 대해 지정된 최고 스팟 가격보다 낮으면 인스턴스가 시작됩니다. 인스턴스가 실행되는 동안 *최고 스팟 가격이 아닌* 현재 스팟 가격으로 요금으로 부과됩니다.
**참고**
지속 시간이 정의된 스팟 인스턴스(스팟 블록이라고도 함)는 2021년 7월 1일부터 더 이상 신규 고객에게 제공되지 않습니다. 이전에 이 기능을 사용한 고객의 경우 2022년 12월 31일까지 지속 시간이 정의된 스팟 인스턴스를 계속 지원합니다.
현재 요금은 [Amazon EC2 스팟 인스턴스 요금](https://aws.amazon.com/ec2/spot/pricing/)을 참조하세요. 자세한 내용은 *Amazon EC2 사용 설명서*의 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 참조하세요. 클러스터를 생성 및 구성하는 경우 궁극적으로 클러스터가 시작될 가용 영역을 결정하는 네트워크 옵션을 지정할 수 있습니다. 자세한 내용은 [Amazon EMR에 대해 VPC에서 네트워킹 구성](emr-plan-vpc-subnet.md) 단원을 참조하십시오.
**작은 정보**
**고급 옵션**을 사용하여 클러스터를 생성할 때 **스팟** 구매 옵션 옆에 있는 정보 도구 설명을 마우스로 가리키면 콘솔에서 실시간 스팟 가격을 확인할 수 있습니다. 선택한 리전의 각 가용 영역에 대한 요금이 표시됩니다. 최저 가격은 녹색 행에 있습니다. 가용 영역 간의 스팟 가격 변동 때문에 최저 초기 가격으로 가용 영역을 선택했을 때 클러스터 수명 동안 해당 가격이 최저 가격이 아닐 수도 있습니다. 최상의 결과를 얻으려면 선택하기 전에 가용 영역 요금 기록을 살펴보세요. 자세한 내용은 **Amazon EC2 사용 설명서에서 [스팟 인스턴스 요금 기록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html)을 참조하세요.
스팟 인스턴스 옵션은 클러스터 구성에서 균일한 인스턴스 그룹을 사용하는지 인스턴스 집합을 사용하는지에 따라 달라집니다.
****균일한 인스턴스 그룹의 스팟 인스턴스****
균일한 인스턴스 그룹에서 스팟 인스턴스를 사용하는 경우 인스턴스 그룹 내 모든 인스턴스가 스팟 인스턴스여야 합니다. 클러스터에 대해 가용 영역의 단일 서브넷을 지정할 수 있습니다. 인스턴스 그룹마다 단일 스팟 인스턴스 및 최고 스팟 가격을 지정합니다. 클러스터의 리전과 가용 영역 내 스팟 가격이 최고 스팟 가격보다 낮으면 해당 유형의 스팟 인스턴스가 시작됩니다. 스팟 가격이 최대 스팟 가격보다 높으면 인스턴스가 종료됩니다. 인스턴스 그룹을 구성할 때만 최대 스팟 가격을 설정할 수 있습니다. 나중에 변경할 수 없습니다. 자세한 내용은 [인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성](emr-instance-group-configuration.md) 단원을 참조하십시오.
****인스턴스 플릿의 스팟 인스턴스****
인스턴스 집합 구성을 사용하는 경우 추가 옵션을 통해 스팟 인스턴스 시작 및 종료 방식을 보다 세부적으로 제어할 수 있습니다. 기본적으로 인스턴스 집합에서는 균일한 인스턴스 그룹과는 다른 방법을 사용하여 인스턴스를 시작합니다. 작동 방식은 스팟 인스턴스(및 온디맨드 인스턴스) 및 최대 다섯 개의 인스턴스 유형에 대해 *대상 용량*을 설정하는 것입니다. 또한 각 인스턴스 유형마다 *가중치 용량*을 지정하거나 인스턴스 유형의 vCPU(YARN vcores)를 가중치 용량으로 사용할 수도 있습니다. 이 가중치 기반 용량은 해당 유형의 인스턴스가 프로비저닝될 때 목표 용량에 포함됩니다. Amazon EMR은 각 대상의 목표 용량이 충족될 때까지 두 구매 옵션으로 인스턴스를 프로비저닝합니다. 또한, 인스턴스 시작 시 선택할 Amazon EMR에 대한 가용 영역 범위도 정의할 수 있습니다. 프로비저닝 제한 시간을 비롯하여 각 집합마다 추가 스팟 옵션도 제공할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성](emr-instance-fleet.md) 단원을 참조하십시오.
# Amazon EMR에서 인스턴스 스토리지 옵션 및 동작
## 개요
인스턴스 스토어 및 Amazon EBS 볼륨 스토리지는 HDFS 데이터, 그리고 일부 애플리케이션에서 로컬 파일 시스템으로 '유출'할 수 있는 버퍼, 캐시, 스크래치 데이터 및 기타 임시 콘텐츠에 사용됩니다.
Amazon EBS는 Amazon EMR 내에서 일반 Amazon EC2 인스턴스와는 다르게 작동합니다. Amazon EMR 클러스터에 연결된 Amazon EBS 볼륨은 휘발성입니다. 따라서 클러스터 및 인스턴스 종료 시 볼륨이 삭제되므로(예: 인스턴스 그룹 축소 시), 데이터 지속성을 기대할 수 없습니다. 데이터가 휘발성이더라도, 클러스터 내 노드의 개수와 특수화에 따라 HDFS의 데이터를 복제할 수도 있습니다. Amazon EBS 스토리지 볼륨 추가 시 이들 볼륨이 추가 볼륨으로 마운트됩니다. 이는 부팅 볼륨에 속하지 않습니다. YARN은 모든 추가 볼륨을 사용하도록 구성되어 있지만, 사용자가 추가 볼륨을 로컬 스토리지(예를 들면 로컬 로그 파일용)로 직접 할당해야 합니다.
## 고려 사항
Amazon EBS를 EMR 클러스터와 함께 사용하는 경우에는 다음의 추가 고려 사항에 유의하세요.
+ Amazon EBS 볼륨의 스냅샷을 생성한 후에 Amazon EMR에서 해당 볼륨을 복원할 수 없습니다. 재사용 가능한 사용자 지정 구성을 생성하려면 사용자 지정 AMI(Amazon EMR 버전 5.7.0 이상에서 사용 가능)를 사용합니다. 자세한 내용은 [사용자 지정 AMI를 사용하여 Amazon EMR 클러스터 구성에 더 많은 유연성 제공](emr-custom-ami.md) 단원을 참조하십시오.
+ 암호화된 Amazon EBS 루트 디바이스 볼륨은 사용자 지정 AMI를 사용하는 경우에만 지원됩니다. 자세한 내용은 [암호화된 Amazon EBS 루트 디바이스 볼륨이 있는 사용자 지정 AMI 생성](emr-custom-ami.md#emr-custom-ami-encrypted) 단원을 참조하십시오.
+ Amazon EMR API를 사용하여 태그를 적용할 경우 해당 작업이 EBS 볼륨에 적용됩니다.
+ 인스턴스당 25개 볼륨으로 제한됩니다.
+ 코어 노드의 Amazon EBS 볼륨은 5GB 미만일 수 없습니다.
+ Amazon EBS에는 인스턴스 시작 요청당 2,500개의 EBS 볼륨과 같은 고정된 제한이 있습니다. 이 제한은 EC2 클러스터의 Amazon EMR에도 적용됩니다. 총 EBS 볼륨 수가 이 제한 내에 있는 클러스터를 시작한 다음, 필요에 따라 클러스터를 수동으로 스케일 업하거나 Amazon EMR Managed Scaling을 사용하는 것이 좋습니다. EBS 볼륨 제한에 대해 자세히 알아보려면 [Service quotas](https://docs.aws.amazon.com/general/latest/gr/ebs-service.html#limits_ebs:~:text=Amazon%20EBS%20has,exceeding%20the%20limit.)를 참조하세요.
## 인스턴스의 기본 Amazon EBS 스토리지
EBS 전용 스토리지가 있는 EC2 인스턴스에서는 Amazon EMR이 Amazon EBS gp2 또는 gp3 스토리지 볼륨을 인스턴스에 할당합니다. Amazon EMR 릴리스 5.22.0 이상을 사용하여 클러스터를 생성할 때 Amazon EBS 스토리지의 기본 크기가 인스턴스 크기에 따라 증가합니다.
증가된 스토리지는 복수의 볼륨에서 분할됩니다. 이로 인해 IOPS 성능이 향상되고, 결과적으로 일부 표준화된 워크로드의 성능이 높아집니다. 다른 Amazon EBS 인스턴스 스토리지 구성을 사용하려는 경우 EMR 클러스터를 생성하거나 기존 클러스터에 노드를 추가할 때 이 구성을 지정할 수 있습니다. Amazon EBS gp2 또는 gp3 볼륨을 루트 볼륨으로 사용하고 gp2 또는 gp3 볼륨을 추가 볼륨으로 추가할 수 있습니다. 자세한 내용은 [추가 EBS 스토리지 볼륨 지정](#emr-plan-storage-additional-ebs-volumes) 단원을 참조하십시오.
다음 테이블에는 Amazon EBS gp2 스토리지 볼륨의 기본 수, 크기 및 인스턴스 유형별 총 크기가 나와 있습니다. gp2 볼륨과 gp3의 볼륨 비교에 대한 자세한 내용을 확인하려면 [Amazon EBS 볼륨 유형 gp2 및 gp3 비교](emr-plan-storage-compare-volume-types.md) 섹션을 참조하세요.
**Amazon EMR 5.22.0 이상에서 인스턴스 유형별 기본 Amazon EBS gp2 스토리지 볼륨 및 크기**
| 인스턴스 크기 | 볼륨 수 | 볼륨 크기(GiB) | 총 크기(GiB) |
| --- | --- | --- | --- |
| \$1.large | 1 | 32 | 32 |
| \$1.xlarge | 2 | 32 | 64 |
| \$1.2xlarge | 4 | 32 | 128 |
| \$1.4xlarge | 4 | 64 | 256 |
| \$1.8xlarge | 4 | 128 | 512 |
| \$1.9xlarge | 4 | 144 | 576 |
| \$1.10xlarge | 4 | 160 | 640 |
| \$1.12xlarge | 4 | 192 | 768 |
| \$1.16xlarge | 4 | 256 | 1024 |
| \$1.18xlarge | 4 | 288 | 1152 |
| \$1.24xlarge | 4 | 384 | 1536 |
## 인스턴스에 대한 기본 Amazon EBS 루트 볼륨
Amazon EMR 릴리스 6.15 이상에서 Amazon EMR은 성능 향상을 위해 AMI용 루트 디바이스로 Amazon EBS 범용 SSD(gp3)를 자동으로 연결합니다. 이전 릴리스를 사용하는 경우에는 Amazon EMR에서 EBS 범용 SSD(gp2)를 루트 디바이스로 연결합니다.
| | 6.15 이상 | 6.14.x 이하 |
| --- | --- | --- |
| 기본 루트 볼륨 유형 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-plan-storage.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-plan-storage.html) |
| 기본 크기 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-plan-storage.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-plan-storage.html) |
| 기본 IOPS | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-plan-storage.html) | |
| 기본 처리량 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/emr-plan-storage.html) | |
Amazon EBS 루트 디바이스 볼륨을 사용자 지정하는 방법에 대한 자세한 내용을 확인하려면 [추가 EBS 스토리지 볼륨 지정](#emr-plan-storage-additional-ebs-volumes) 섹션을 참조하세요.
## 추가 EBS 스토리지 볼륨 지정
Amazon EMR에서 인스턴스 유형을 구성할 때 추가 EBS 볼륨을 지정하여 인스턴스 스토어(있는 경우) 및 기본 EBS 볼륨 외에 용량을 추가할 수 있습니다. Amazon EBS는 범용(SSD), 프로비저닝된 IOPS(SSD), 처리량 최적화(HDD), 콜드(HDD) 및 마그네틱 등의 볼륨 유형을 제공합니다. 이들 유형은 성능 특성과 가격이 다르므로 애플리케이션의 분석 및 비즈니스 필요에 맞게 스토리지를 조정할 수 있습니다. 예를 들어, 일부 애플리케이션의 경우 디스크로 유출되어야 하는 반면, 다른 애플리케이션은 메모리 내에서 또는 Amazon S3를 사용하여 안전하게 작업할 수 있습니다.
클러스터를 시작할 때, 그리고 추가 태스크 노드 인스턴스 그룹을 추가할 때에만 클러스터의 인스턴스에 Amazon EBS 볼륨을 추가할 수 있습니다. Amazon EMR 클러스터의 인스턴스가 작동하지 않는 경우 해당 인스턴스와 연결된 Amazon EBS 볼륨이 모두 새 볼륨으로 대체됩니다. 따라서 Amazon EBS 볼륨을 수동으로 분리하는 경우 Amazon EMR에서는 해당 동작을 오류로 간주하여 두 인스턴스 스토리지(해당하는 경우)와 볼륨 스토어를 모두 바꿉니다.
Amazon EMR에서는 기존 EMR 클러스터의 볼륨 유형을 gp2에서 gp3로 수정할 수 없습니다. 워크로드에 gp3를 사용하려면 새 EMR 클러스터를 시작해야 합니다. 또한 Amazon EMR은 클러스터 스케일 업 중에 추가하는 모든 새 인스턴스에 대해 클러스터 시작 시 지정한 처리량과 IOPS 값을 사용하므로 사용 중이거나 프로비저닝 중인 클러스터의 처리량 및 IOPS는 업데이트하지 않는 것이 좋습니다. 자세한 내용은 [Amazon EBS 볼륨 유형 gp2 및 gp3 비교](emr-plan-storage-compare-volume-types.md) 및 [gp3 Amazon EBS 볼륨 유형으로 마이그레이션할 때 IOPS 및 처리량 선택](emr-plan-storage-gp3-migration-selection.md) 섹션을 참조하세요.
**중요**
EMR 클러스터에서 gp3 볼륨을 사용하려면 새 클러스터를 시작해야 합니다.
# Amazon EBS 볼륨 유형 gp2 및 gp3 비교
다음에서는 미국 동부(버지니아 북부) 리전의 gp2 및 gp3 볼륨 간 비용을 비교합니다. 최신 정보를 확인하려면 [Amazon EBS 범용 볼륨](https://aws.amazon.com/ebs/general-purpose/) 제품 페이지와 [Amazon EBS 요금 페이지](https://aws.amazon.com/ebs/pricing/)를 참조하세요.
| 볼륨 유형 | gp3 | gp2 |
| --- | --- | --- |
| 볼륨 크기 | 1GiB\$116TiB | 1GiB\$116TiB |
| 기본 및 기준 IOPS | 3000 | 3 IOPS/GiB(최소 100 IOPS)에서 최대 16,000 IOPS. 1TiB보다 작은 볼륨도 최대 3,000IOPS까지 버스트 가능합니다. |
| 볼륨당 최대 IOPS | 16,000 | 16,000 |
| 기본 및 기준 처리량 | 125MiB/s | 처리량 한도는 볼륨 크기에 따라 128MiB/s\$1250 MiB/s입니다. |
| 볼륨당 최대 처리량 | 1,000MiB/s | 250MiB/s |
| 가격 | 매월 GiB당 0.08 USD의 요금에서 3,000 IOPS 무료 제공, 3,000 초과 시 매월 프로비저닝된 IOPS당 0.005 USD, 125MiB/s 무료 및 125MiB/s 초과 시 매월 프로비저닝된 MiB/s당 0.04 USD | 매월 GiB당 0.10 USD |
# gp3 Amazon EBS 볼륨 유형으로 마이그레이션할 때 IOPS 및 처리량 선택
gp2 볼륨을 프로비저닝할 때 비례적인 IOPS와 처리량을 지원하기 위해 볼륨 크기를 파악해야 합니다. gp3에서 더 높은 성능을 얻기 위해 더 큰 볼륨을 프로비저닝할 필요가 없습니다. 애플리케이션 요구 사항에 따라 원하는 크기와 성능을 선택할 수 있습니다. 올바른 크기와 올바른 성능 파라미터(IOPS, 처리량)를 선택하면 성능에 영향을 주지 않으면서 비용을 최대한 절감할 수 있습니다.
다음은 gp3 구성 옵션을 선택하는 데 도움이 되는 테이블입니다.
| 볼륨 크기 | IOPS | 처리량 |
| --- | --- | --- |
| 1GiB\$1170GiB | 3000 | 125MiB/s |
| 170GiB\$1334GiB | 3000 | 125MiB/s(선택한 EC2 인스턴스 유형이 125MiB/s 이하를 지원하는 경우). 사용량에 따라 더 높은 용량을 사용합니다(최대 250MiB/s\$1). |
| 334GiB\$11,000GiB | 3000 | 125MiB/s(선택한 EC2 인스턴스 유형이 125MiB/s 이하를 지원하는 경우). 사용량에 따라 더 높은 용량을 사용합니다(최대 250MiB/s\$1). |
| 1,000GiB 이상 | 현재 gp2 볼륨으로 구동되는 gp2 IOPS(GiB 크기 x 3) 또는 최대 IOPS와 일치 | 125MiB/s(선택한 EC2 인스턴스 유형이 125MiB/s 이하를 지원하는 경우). 사용량에 따라 더 높은 용량을 사용합니다(최대 250MiB/s\$1). |
\$1Gp3는 최대 2,000MiB/s의 처리량을 제공할 수 있습니다. gp2는 최대 250MiB/s의 처리량을 지원하므로 gp3를 사용할 때는 이 한도를 초과하지 않아도 됩니다. Gp3 볼륨은 스토리지 가격에 포함된 125MiB/s의 일관된 기본 처리 성능을 제공합니다. 프로비저닝된 IOPS당 0.25MiB/s 비율의 추가 비용으로 추가 처리량(최대 2,000MiB/s)을 프로비저닝할 수 있습니다. 최대 처리량은 8,000IOPS 이상 및 16GiB 이상(8,000IOPS × IOPS당 0.25MiB/s = 2,000MiB/s)으로 프로비저닝할 수 있습니다.
# Amazon EMR에 대해 VPC에서 네트워킹 구성
대부분의 클러스터는 Amazon Virtual Private Cloud(VPC)를 사용해 가상 네트워크로 시작됩니다. VPC는 계정 AWS 내에서 논리적으로 격리 AWS 된 내의 격리된 가상 네트워크입니다. 프라이빗 IP 주소 범위, 서브넷, 라우팅 테이블, 네트워크 게이트웨이 등의 요소를 구성할 수 있습니다. 자세한 내용은 [Amazon VPC 사용 설명서](https://docs.aws.amazon.com/vpc/latest/userguide/)를 참조하세요.
VPC는 다음과 같은 기능을 제공합니다.
+ **중요 데이터 처리**
클러스터를 VPC에서 시작하는 것은 네트워크에 대한 액세스 권한이 있는 사람을 정의하기 위해 라우팅 테이블 및 네트워크 ACL 같은 추가 도구를 사용하여 클러스터를 프라이빗 네트워크에서 시작하는 것과 비슷합니다. 클러스터에서 중요 데이터를 처리하려는 경우 VPC에서 클러스터 시작 시 얻게 되는 추가 액세스 제어 기능이 필요할 수도 있습니다. 뿐만 아니라, 모든 리소스가 직접 인터넷에 연결할 수 없는 프라이빗 서브넷에서 리소스를 시작하도록 선택할 수도 있습니다.
+ **내부 네트워크의 리소스에 액세스**
데이터 소스가 프라이빗 네트워크에 있는 경우 전송할 데이터의 양이나 데이터의 민감한 특성으로 인해 Amazon EMR로 AWS 가져오기 위해 해당 데이터를에 업로드하는 것이 실용적이지 않거나 바람직하지 않을 수 있습니다. 대신에, 클러스터를 VPC에서 시작하고 VPN 연결을 통해 데이터 센터를 VPC에 연결하면 클러스터에서 내부 네트워크의 리소스에 액세스할 수 있습니다. 예를 들어, 데이터 센터에 Oracle 데이터베이스가 있는 경우 VPN에 의해 해당 네트워크에 연결된 VPC에서 클러스터를 시작하면 클러스터에서 Oracle 데이터베이스에 액세스할 수 있습니다.
****퍼블릭 및 프라이빗 서브넷****
퍼블릭 및 프라이빗 VPC 서브넷 모두에서 Amazon EMR 클러스터를 시작할 수 있습니다. 즉, Amazon EMR 클러스터를 실행하는 데 인터넷 연결이 필요하지 않지만 회사 인트라넷 또는와 같은 퍼블릭 AWS 서비스 엔드포인트와 같이 VPC 외부에 있는 서비스 또는 리소스에 액세스하도록 네트워크 주소 변환(NAT) 및 VPN 게이트웨이를 구성해야 할 수 있습니다 AWS Key Management Service.
**중요**
Amazon EMR은 릴리스 4.2 이상에서만 프라이빗 서브넷에서 클러스터 시작 기능을 지원합니다.
Amazon VPC에 대한 자세한 내용은 [Amazon VPC 사용 설명서](https://docs.aws.amazon.com/vpc/latest/userguide/)를 참조하세요.
**Topics**
+ [
# 클러스터를 시작하는 경우 Amazon VPC 옵션
](emr-clusters-in-a-vpc.md)
+ [
# 클러스터를 호스팅하도록 VPC 설정
](emr-vpc-host-job-flows.md)
+ [
# Amazon EMR에서 VPC로 클러스터 시작
](emr-vpc-launching-job-flows.md)
+ [
# Amazon S3에 액세스하는 프라이빗 서브넷에 대한 샘플 정책
](private-subnet-iampolicy.md)
+ [
## VPC에 대해 자세히 알 수 있는 추가 리소스
](#emr-resources-about-vpcs)
# 클러스터를 시작하는 경우 Amazon VPC 옵션
VPC 내에서 Amazon EMR 클러스터를 시작하는 경우 퍼블릭, 프라이빗 또는 공유 서브넷 내에서 시작할 수 있습니다. 클러스터에 대해 선택하는 서브넷 유형에 따라 구성이 약간 달라집니다.
## 퍼블릭 서브넷
퍼블릭 서브넷의 EMR 클러스터의 경우 인터넷 게이트웨이가 연결되어 있어야 합니다. 이는 Amazon EMR 클러스터가 AWS 서비스 및 Amazon EMR에 액세스해야 하기 때문입니다. Amazon S3와 같은 서비스에서 VPC 엔드포인트를 생성할 수 있는 기능을 제공하는 경우, 인터넷 게이트웨이를 통해 퍼블릭 엔드포인트를 액세스하는 대신에 엔드포인트를 사용하여 이러한 서비스에 액세스할 수 있습니다. 또한, Amazon EMR은 Network Address Translation(NAT) 디바이스를 통해 퍼블릭 서브넷에 있는 클러스터와 통신할 수 없습니다. 이 목적으로 인터넷 게이트웨이가 필요하지만 복잡한 시나리오에서 기타 트래픽에 대해 NAT 인스턴스나 게이트웨이를 여전히 사용할 수 있습니다.
VPC 엔드포인트 또는 인터넷 게이트웨이를 통해 클러스터의 모든 인스턴스가 Amazon S3에 연결됩니다. 현재 VPC 엔드포인트를 지원하지 않는 다른 AWS 서비스는 인터넷 게이트웨이만 사용합니다.
인터넷 게이트웨이에 연결하지 않으려는 추가 AWS 리소스가 있는 경우 VPC 내에서 생성한 프라이빗 서브넷에서 해당 구성 요소를 시작할 수 있습니다.
퍼블릭 서브넷에서 실행 중인 클러스터에는 프라이머리 노드에 대한 보안 그룹과 코어 및 태스크 노드에 대한 보안 그룹의 두 가지 보안 그룹이 있습니다. 자세한 내용은 [Amazon EMR 클러스터의 보안 그룹으로 네트워크 트래픽 제어](emr-security-groups.md) 단원을 참조하십시오.
다음 다이어그램은 Amazon EMR 클러스터가 퍼블릭 서브넷을 사용하여 VPC에서 실행되는 방식을 보여줍니다. 클러스터는 인터넷 게이트웨이를 통해 Amazon S3 버킷과 같은 다른 AWS 리소스에 연결할 수 있습니다.
![\[VPC의 클러스터\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/vpc_default_v3a.png)
다음 다이어그램에는 Oracle 데이터베이스 등 자신의 고유 네트워크에서 VPC 내 클러스터가 리소스에 액세스할 수 있도록 VPC를 설정하는 방법을 보여 줍니다.
![\[로컬 VPN 리소스에 액세스하도록 VPC 및 클러스터 설정\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/vpc_withVPN_v3a.png)
## 프라이빗 서브넷
프라이빗 서브넷을 사용하면 서브넷에 인터넷 게이트웨이가 연결되지 않아도 AWS 리소스를 시작할 수 있습니다. Amazon EMR은 릴리스 버전 4.2.0 이상에서 프라이빗 서브넷에서의 클러스터 시작 기능을 지원합니다.
**참고**
프라이빗 서브넷에서 Amazon EMR 클러스터를 설정할 때는 [Amazon S3에 대한 VPC 엔드포인트](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)도 설정하는 것이 좋습니다. EMR 클러스터가 Amazon S3의 VPC 엔드포인트 없이 프라이빗 서브넷에 있는 경우, EMR 클러스터와 S3 간 트래픽이 VPC 내에 머물지 않기 때문에 S3 트래픽과 관련된 추가 NAT 게이트웨이 요금이 발생합니다.
프라이빗 서브넷은 다음과 같은 점에서 퍼블릿 서브넷과 다릅니다.
+ VPC 엔드포인트를 제공하지 않는 AWS 서비스에 액세스하려면 NAT 인스턴스 또는 인터넷 게이트웨이를 사용해야 합니다.
+ 최소한, Amazon S3에 Amazon Linux 리포지토리 및 Amazon EMR 서비스 로그 버킷에 대한 경로를 제공해야 합니다. 자세한 내용은 [Amazon S3에 액세스하는 프라이빗 서브넷에 대한 샘플 정책](private-subnet-iampolicy.md) 섹션을 참조하세요.
+ EMRFS 기능을 사용할 경우 프라이빗 서브넷에서 DynamoDB로 연결되는 경로와 Amazon S3 VPC 엔드포인트가 있어야 합니다.
+ 프라이빗 서브넷에서 퍼블릭 Amazon SQS 엔드포인트로 연결되는 경로를 제공하는 경우에만 디버깅이 작동합니다.
+ 퍼블릭 서브넷에서 NAT 인스턴스 또는 게이트웨이로 프라이빗 서브넷 구성을 생성하는 작업은 AWS Management Console을 사용할 때만 지원됩니다. Amazon EMR 클러스터에 대한 NAT 인스턴스 및 Amazon S3 VPC 엔드포인트를 추가하고 구성하는 가장 쉬운 방법은 Amazon EMR 콘솔에서 **VPC 서브넷 목록** 페이지를 사용하는 것입니다. NAT 게이트웨이를 생성하려면 *Amazon VPC 사용 설명서*에서 [NAT 게이트웨이](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)를 참조하세요.
+ 기존 Amazon EMR 클러스터를 포함하는 서브넷을 퍼블릭에서 프라이빗으로 또는 그 반대로 변경할 수 있습니다. 프라이빗 서브넷 내에서 Amazon EMR 클러스터를 찾으려면 클러스터를 프라이빗 서브넷에서 시작해야 합니다.
Amazon EMR은 프라이빗 서브넷에서 클러스터에 대한 다양한 기본 보안 그룹(ElasticMapReduce-Master-Private, ElasticMapReduce-Slave-Private 및 ElasticMapReduce-ServiceAccess)을 생성하고 사용합니다. 자세한 내용은 [Amazon EMR 클러스터의 보안 그룹으로 네트워크 트래픽 제어](emr-security-groups.md) 단원을 참조하십시오.
클러스터의 전체 NACL 목록을 보려면 Amazon EMR 콘솔 **클러스터 세부 정보** 페이지에서 **프라이머리에 대한 보안 그룹** 및 **코어 및 작업에 대한 보안 그룹**을 선택합니다.
다음 이미지는 Amazon EMR 클러스터가 프라이빗 서브넷 내에서 구성되는 방식을 보여줍니다. 서브넷 외부 통신만 Amazon EMR과 이루어집니다.
![\[프라이빗 서브넷에서 Amazon EMR 클러스터 시작\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/vpc_with_private_subnet_v3a.png)
다음 이미지는 퍼블릭 서브넷에서 상주하는 NAT 인스턴스에 연결된 프라이빗 서브넷 내 Amazon EMR 클러스터에 대한 샘플 구성을 보여줍니다.
![\[NAT를 사용하는 프라이빗 서브넷\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/vpc_private_subnet_nat_v3a.png)
## 공유 서브넷
VPC 공유를 통해 고객은 동일한 AWS 조직 내의 다른 AWS 계정과 서브넷을 공유할 수 있습니다. 다음 주의 사항을 참고해 퍼블릭 공유 및 프라이빗 공유 서브넷으로 Amazon EMR 클러스터를 시작할 수 있습니다.
서브넷 소유자는 사용자가 해당 서브넷으로 Amazon EMR 클러스터를 시작하기 전에 사용자와 서브넷을 공유해야 합니다. 그러나 공유된 서브넷은 나중에 공유 해제할 수 있습니다. 자세한 내용은 [공유 VPC 작업](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html)을 참조하세요. 클러스터가 공유된 서브넷으로 시작되고 나서 이 공유된 서브넷이 공유 해제되는 경우 서브넷이 공유 해제되는 시점의 Amazon EMR 클러스터의 상태에 따른 특정 동작을 관찰할 수 있습니다.
+ 서브넷은 클러스터가 성공적으로 시작되기 *전에* 공유 해제됩니다. 참가자가 클러스터를 시작하는 중에 소유주가 Amazon VPC 또는 서브넷의 공유를 중단하면 요청된 모든 인스턴스를 프로비저닝하지 않고는 클러스터를 시작할 수 없거나 부분적으로 초기화하지 못할 수 있습니다.
+ 서브넷은 클러스터가 성공적으로 시작된 *후에* 공유 해제됩니다. 소유자가 서브넷 또는 Amazon VPC를 참가자와 공유하는 것을 중단하면 참가자의 클러스터는 새 인스턴스를 추가하거나 비정상 인스턴스를 교체할 수 있도록 크기 조정이 되지 않습니다.
Amazon EMR 클러스터를 시작하면 여러 개의 보안 그룹이 생성됩니다. 공유된 서브넷에서 서브넷 참가자는 이 보안 그룹을 제어합니다. 서브넷 소유자는 이 보안 그룹을 볼 수 있지만 이 보안 그룹에 대해 작업을 수행할 수는 없습니다. 서브넷 소유자가 보안 그룹을 제거하거나 수정하고자 하는 경우 보안 그룹을 생성한 참가자가 조치를 취해야 합니다.
## IAM을 통해 VPC 권한 제어
기본적으로 모든 사용자는 해당 계정에 대한 모든 서브넷을 볼 수 있으며, 모든 사용자가 어떤 서브넷에서든지 클러스터를 시작할 수 있습니다.
VPC에서 클러스터를 시작할 때 Amazon EC2 Classic에서 클러스터를 시작할 때와 마찬가지로 AWS Identity and Access Management (IAM)을 사용하여 클러스터에 대한 액세스를 제어하고 정책을 사용하여 작업을 제한할 수 있습니다. IAM에 대한 자세한 내용은 [IAM 사용 설명서](https://docs.aws.amazon.com/IAM/latest/UserGuide/)를 참조하세요.
IAM을 사용하여 서브넷을 생성하고 관리할 수 있는 사람을 제어할 수도 있습니다. 예를 들어, 서브넷을 관리하는 IAM 역할과 클러스터를 시작할 수 있지만 Amazon VPC 설정을 수정할 수 없는 두 번째 역할을 생성할 수 있습니다. Amazon EC2 및 Amazon VPC에서 정책 및 작업 관리에 대한 자세한 내용은 **Amazon EC2 사용 설명서에서 [Amazon EC2에 대한 IAM 정책](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html)을 참조하세요.
# 클러스터를 호스팅하도록 VPC 설정
VPC에서 클러스터를 시작하려면 먼저 VPC 및 서브넷을 생성해야 합니다. 퍼블릭 서브넷의 경우 인터넷 게이트웨이를 생성하여 서브넷에 연결해야 합니다. 다음 지침에서는 Amazon EMR 클러스터를 호스팅할 수 있는 VPC를 생성하는 방법을 설명합니다.
**Amazon EMR 클러스터에 대한 서브넷이 포함된 VPC를 생성하는 방법**
1. [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)에서 Amazon VPC 콘솔을 엽니다.
1. 페이지 오른쪽 상단에서 VPC의 [AWS 리전](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)을 선택합니다.
1. **VPC 생성**을 선택합니다.
1. **VPC 설정** 페이지에서 **VPC 등**을 선택합니다.
1. **이름 태그 자동 생성**에서 **자동 생성**을 활성화하고 VPC의 이름을 입력합니다. 이렇게 하면 VPC와 서브넷을 만든 후 Amazon VPC 콘솔에서 쉽게 식별할 수 있습니다.
1. **IPv4 CIDR 블록** 필드에 VPC의 프라이빗 IP 주소 공간을 입력합니다. 이를 통해 올바른 DNS 호스트 이름 확인을 보장합니다. 그렇지 않으면 Amazon EMR 클러스터 오류가 발생할 수 있습니다. 여기에는 다음 IP 주소 범위가 포함됩니다.
+ 10.0.0.0 - 10.255.255.255
+ 172.16.0.0 - 172.31.255.255
+ 192.168.0.0 - 192.168.255.255
1. **가용 영역(AZ) 수(Number of Availability Zones(AZs))**에서 서브넷을 시작할 가용 영역 수를 선택합니다.
1. **퍼블릭 서브넷 수**에서 VPC에 추가할 퍼블릭 서브넷 수를 선택합니다. 클러스터에서 사용하는 데이터를 인터넷에서 사용할 수 있는 경우(예: Amazon S3 또는 Amazon RDS), 퍼블릭 서브넷만 사용하면 됩니다. 프라이빗 서브넷을 추가할 필요는 없습니다.
1. **프라이빗 서브넷 수(Number of private subnets)**에서 VPC 추가할 프라이빗 서브넷 수를 선택합니다. 애플리케이션 데이터가 자체 네트워크(예: Oracle 데이터베이스)에 저장된 경우 하나 이상을 선택합니다. 프라이빗 서브넷에 있는 VPC의 경우, 모든 Amazon EC2 인스턴스에 최소한 탄력적 네트워크 인터페이스를 통해 Amazon EMR로 연결되는 경로가 있어야 합니다. 콘솔에서는 이 설정이 자동으로 구성됩니다.
1. 선택적으로 **NAT 게이트웨이**에서 NAT 게이트웨이를 추가하도록 선택합니다. 인터넷과 통신해야 하는 프라이빗 서브넷이 있는 경우에만 프라이빗 서브넷이 필요합니다.
1. **VPC 엔드포인트** 아래에서 선택적으로 Amazon S3의 엔드포인트를 서브넷에 추가하도록 선택합니다.
1. **DNS 호스트 이름 활성화** 및 **DNS 확인 활성화**가 선택되어 있는지 확인합니다. 자세한 내용은 [VPC에서 DNS 사용하기](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) 섹션을 참조하세요.
1. **VPC 생성**을 선택합니다.
1. 상태 창에 진행 중인 작업이 표시됩니다. 작업이 완료되면 **VPC 보기**를 선택하여 **VPC** 페이지로 이동합니다. 이 페이지에 방금 생성한 VPC 및 기본 VPC가 표시됩니다. 생성했던 VPC는 기본이 아닌 VPC이므로 **기본 VPC(Default VPC)** 열에 **아니요(No)**라고 표시됩니다.
1. VPC를 도메인 이름이 포함되지 않은 DNS 항목에 연결하려면 **DHCP 옵션 세트**로 이동하고 **DHCP 옵션 세트 선택**을 선택한 후 도메인 이름을 생략합니다. 옵션 세트를 생성한 후 새 VPC로 이동하여 **작업** 메뉴에서 **DHCP 옵션 세트 편집**을 선택하고 새 옵션 세트를 선택합니다. DNS 옵션 세트를 생성한 후에는 콘솔을 사용하여 도메인 이름을 편집할 수 없습니다.
Hadoop과 관련 애플리케이션을 사용하여 노드의 FQDN(정규화된 도메인 이름)이 확인되도록 하는 것이 좋습니다. DNS가 올바르게 확인되도록 하려면 파라미터가 다음 값으로 설정된 DHCP 옵션 세트를 포함하는 VPC를 구성합니다.
+ **domain-name** = **ec2.internal**
리전이 미국 동부(버지니아 북부)인 경우 **ec2.internal**을 사용합니다. 다른 리전의 경우 *region-name***.compute.internal**을 사용합니다. 예를 들어, `us-west-2`에서는 **us-west-2.compute.internal**을 사용합니다. AWS GovCloud(미국 서부) 리전의 경우 **us-gov-west-1.compute.internal**을 사용합니다.
+ **domain-name-servers** = **AmazonProvidedDNS**
자세한 내용은 *Amazon VPC 사용 설명서*에서 [DHCP 옵션 세트](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)를 참조하세요.
1. VPC를 생성한 후에는 **서브넷** 페이지로 이동하고 VPC 서브넷 중 하나의 **서브넷 ID**를 기록합니다. Amazon EMR 클러스터를 VPC에서 시작할 때 이 정보를 사용할 수 있습니다.
# Amazon EMR에서 VPC로 클러스터 시작
Amazon EMR 클러스터를 호스팅하도록 구성된 서브넷이 있으면 클러스터 생성 시 관련 서브넷 식별자를 지정하여 해당 서브넷에서 클러스터를 시작합니다.
**참고**
Amazon EMR 릴리스 버전 4.2 이상에서 프라이빗 서브넷이 지원됩니다.
클러스터 시작 시 Amazon EMR은 클러스터가 VPC 프라이빗에서 시작되는지, 아니면 퍼블릭 서브넷에서 시작되는지 여부에 따라 보안 그룹을 추가합니다. 모든 보안 그룹은 포트 8443에서 수신하여 Amazon EMR 서비스와 통신할 수 있도록 허용하지만 IP 주소 범위는 퍼블릭 서브넷과 프라이빗 서브넷에 따라 다릅니다. Amazon EMR은 이러한 모든 보안 그룹을 관리하며 시간 경과에 따라 AWS 범위에 IP 주소를 추가해야 할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터의 보안 그룹으로 네트워크 트래픽 제어](emr-security-groups.md) 단원을 참조하십시오.
VPC에서 클러스터를 관리하기 위해 Amazon EMR은 프라이머리 노드에 네트워크 디바이스를 연결하고 이 디바이스를 통해 클러스터를 관리합니다. Amazon EC2 API 작업 [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeInstances.html)를 사용하여 이 디바이스를 볼 수 있습니다. 어떤 방법으로든 이 디바이스를 수정할 경우 클러스터가 작동하지 않을 수도 있습니다.
------
#### [ Console ]
**콘솔을 사용하여 VPC에서 클러스터를 시작하는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 **클러스터 생성**을 선택합니다.
1. **네트워킹**에서 **Virtual Private Cloud(VPC)** 필드로 이동합니다. VPC의 이름을 입력하거나 **찾아보기**를 선택하여 VPC를 선택합니다. 또는 **VPC 생성**을 선택하여 클러스터에서 사용할 수 있는 VPC를 생성합니다.
1. 클러스터에 적용할 다른 옵션을 선택합니다.
1. 클러스터를 시작하려면 **클러스터 생성**을 선택합니다.
------
#### [ AWS CLI ]
**를 사용하여 VPC로 클러스터를 시작하려면 AWS CLI**
**참고**
는 NAT 인스턴스를 자동으로 생성하고 프라이빗 서브넷에 연결하는 방법을 제공하지 AWS CLI 않습니다. 하지만 서브넷에서 S3 엔드포인트를 생성하려면 Amazon VPC CLI 명령을 사용할 수 있습니다. 콘솔을 사용하여 NAT 인스턴스를 생성하고 프라이빗 서브넷에서 클러스터를 시작합니다.
VPC를 구성한 후에는 `create-cluster` 하위 명령을 `--ec2-attributes` 파라미터와 함께 사용하여 VPC에서 Amazon EMR 클러스터를 시작할 수 있습니다. `--ec2-attributes` 파라미터를 사용하여 클러스터에 대해 VPC 서브넷을 지정합니다.
+ 특정 서브넷에서 클러스터를 생성하려면 다음 명령을 입력하고 *myKey*를 Amazon EC2 키 페어의 이름으로 바꾸고 *77XXXX03*을 서브넷 ID로 바꿉니다.
```
aws emr create-cluster --name "Test cluster" --release-label emr-4.2.0 --applications Name=Hadoop Name=Hive Name=Pig --use-default-roles --ec2-attributes KeyName=myKey,SubnetId=subnet-77XXXX03 --instance-type m5.xlarge --instance-count 3
```
`--instance-groups` 파라미터를 사용하지 않고 인스턴스 수를 지정하면 단일 프라이머리 노드가 시작되고 나머지 인스턴스는 코어 노드로 시작됩니다. 모든 노드에는 이 명령에 지정된 인스턴스 유형이 사용됩니다.
**참고**
Amazon EMR 서비스 역할과 EC2 인스턴스 프로파일을 아직 생성하지 않았다면 `aws emr create-default-roles` 하위 명령을 입력하기 전에 `create-cluster`를 입력하여 생성합니다.
------
## EC2에서 EMR 클러스터에 사용 가능한 IP 주소 확인
시작할 때 사용 가능한 IP 주소가 충분히 있는 서브넷을 사용할 수 있도록 EC2 서브넷 선택 시 IP 가용성을 확인합니다. 생성 프로세스는 필요한 수의 IP 주소가 포함된 서브넷을 사용하여 코어, 프라이머리 및 태스크 노드를 필요에 따라 시작합니다. 단, 최초 생성 시 클러스터의 코어 노드만 생성됩니다. EMR은 생성 중에 프라이머리 및 태스크 노드를 시작하는 데 필요한 IP 주소 수를 확인하고 코어 노드를 시작하는 데 필요한 IP 주소 수를 별도로 계산합니다. 필요한 프라이머리 및 태스크 인스턴스 또는 노드의 최소 수는 Amazon EMR에 의해 자동으로 결정됩니다.
**중요**
VPC의 서브넷에 필수 노드를 수용할 만큼 사용 가능한 IP가 충분하지 않으면 오류가 반환되고 클러스터가 생성되지 않습니다.
대부분의 배포 사례에서는 코어, 프라이머리 및 태스크 노드의 각 시작 사이에 시간 차이가 있습니다. 또한 여러 클러스터가 서브넷을 공유할 수 있습니다. 이 경우 IP 주소 가용성이 변동될 수 있으며 사용 가능한 IP 주소에 따라 예를 들어, 후속 태스크 노드 시작이 제한될 수 있습니다.
# Amazon S3에 액세스하는 프라이빗 서브넷에 대한 샘플 정책
프라이빗 서브넷의 경우 최소한 Amazon EMR에서 Amazon Linux 리포지토리에 액세스할 수 있는 기능을 제공해야 합니다. 이 프라이빗 서브넷 정책은 Amazon S3에 액세스하기 위한 VPC 엔드포인트 정책의 일부입니다.
Amazon EMR 5.25.0 이상에서 영구 Spark 기록 서버에 대한 원클릭 액세스를 활성화하려면 Amazon EMR에서 Spark 이벤트 로그를 수집하는 시스템 버킷에 액세스할 수 있도록 허용해야 합니다. 로깅을 활성화하는 경우 다음 버킷에 PUT 권한을 제공합니다.
```
aws157-logs-${AWS::Region}/*
```
자세한 내용은 [영구 Spark 기록 서버에 대한 원클릭 액세스](https://docs.aws.amazon.com/emr/latest/ManagementGuide/app-history-spark-UI.html)를 참조하세요.
비즈니스 요구를 충족하는 정책 제한은 사용자가 결정합니다. 다음 예제 정책은 Spark 이벤트 로그를 수집하기 위해 Amazon Linux 리포지토리 및 Amazon EMR 시스템 버킷에 액세스할 수 있는 권한을 제공합니다. 버킷에 대한 몇 가지 샘플 리소스 이름을 보여줍니다.
Amazon VPC 엔드포인트에서 IAM 정책 사용에 대한 자세한 내용은 [Amazon S3에 대한 엔드포인트 정책](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html#vpc-endpoints-policies-s3)을 참조하세요.
다음 정책 예제에는 us-east-1 리전의 샘플 리소스가 포함되어 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AmazonLinuxAMIRepositoryAccess",
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::packages.us-east-1.amazonaws.com/*",
"arn:aws:s3:::repo.us-east-1.amazonaws.com/*"
]
},
{
"Sid": "EnableApplicationHistory",
"Effect": "Allow",
"Action": [
"s3:Put*",
"s3:Get*",
"s3:Create*",
"s3:Abort*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::prod.us-east-1.appinfo.src/*"
]
}
]
}
```
------
다음 예제 정책은 us-east-1 리전 내 Amazon Linux 2 리포지토리에 액세스하는 데 필요한 권한을 제공합니다.
```
{
"Statement": [
{
"Sid": "AmazonLinux2AMIRepositoryAccess",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::amazonlinux.us-east-1.amazonaws.com/*",
"arn:aws:s3:::amazonlinux-2-repos-us-east-1/*"
]
}
]
}
```
다음 예제 정책은 us-east-1 리전 내 Amazon Linux 2023 리포지토리에 액세스하는 데 필요한 권한을 제공합니다.
```
{
"Statement": [
{
"Sid": "AmazonLinux2023AMIRepositoryAccess",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::al2023-repos-us-east-1-de612dc2/*"
]
}
]
}
```
## 사용 가능한 리전
다음 표에는 리전별 버킷 목록이 포함되어 있으며, 리포지토리의 Amazon 리소스 이름(ARN)과 `appinfo.src`의 ARN을 나타내는 문자열이 모두 포함되어 있습니다. ARN 또는 Amazon 리소스 이름은 AWS 리소스를 고유하게 식별하는 문자열입니다.
| 리전 | 리포지토리 버킷 | AppInfo 버킷 |
| --- | --- | --- |
| 미국 동부(오하이오) | "arn:aws:s3:::packages.us-east-2.amazonaws.com/","arn:aws:s3:::repo.us-east-2.amazonaws.com/","arn:aws:s3:::repo.us-east-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.us-east-2.appinfo.src/\$1" |
| 미국 동부(버지니아 북부) | "arn:aws:s3:::packages.us-east-1.amazonaws.com/","arn:aws:s3:::repo.us-east-1.amazonaws.com/","arn:aws:s3:::repo.us-east-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.us-east-1.appinfo.src/\$1" |
| 미국 서부(캘리포니아 북부) | "arn:aws:s3:::packages.us-west-1.amazonaws.com/","arn:aws:s3:::repo.us-west-1.amazonaws.com/","arn:aws:s3:::repo.us-west-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.us-west-1.appinfo.src/\$1" |
| 미국 서부(오리건) | "arn:aws:s3:::packages.us-west-2.amazonaws.com/","arn:aws:s3:::repo.us-west-2.amazonaws.com/","arn:aws:s3:::repo.us-west-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.us-west-2.appinfo.src/\$1" |
| 아프리카(케이프타운) | "arn:aws:s3:::packages.af-south-1.amazonaws.com/","arn:aws:s3:::repo.af-south-1.amazonaws.com/","arn:aws:s3:::repo.af-south-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.af-south-1.appinfo.src/\$1" |
| 아프리카(케이프타운) | "arn:aws:s3:::packages.ap-east-1.amazonaws.com/","arn:aws:s3:::repo.ap-east-1.amazonaws.com/","arn:aws:s3:::repo.ap-east-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-east-1.appinfo.src/\$1" |
| 아시아 태평양(하이데라바드) | "arn:aws:s3:::packages.ap-south-2.amazonaws.com/","arn:aws:s3:::repo.ap-south-2.amazonaws.com/","arn:aws:s3:::repo.ap-south-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-south-2.appinfo.src/\$1" |
| 아시아 태평양(자카르타) | "arn:aws:s3:::packages.ap-southeast-3.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-3.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-3.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-southeast-3.appinfo.src/\$1" |
| 아시아 태평양(말레이시아) | "arn:aws:s3:::packages.ap-southeast-5.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-5.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-5.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-southeast-5.appinfo.src/\$1" |
| 아시아 태평양(멜버른) | "arn:aws:s3:::packages.ap-southeast-4.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-4.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-4.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-south-4.appinfo.src/\$1" |
| 아시아 태평양(뭄바이) | "arn:aws:s3:::packages.ap-south-1.amazonaws.com/","arn:aws:s3:::repo.ap-south-1.amazonaws.com/","arn:aws:s3:::repo.ap-south-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-south-1.appinfo.src/\$1" |
| 아시아 태평양(오사카) | "arn:aws:s3::packages.ap-northeast-3.amazonaws.com/","arn:aws:s3:::repo.ap-northeast-3.amazonaws.com/","arn:aws:s3:::repo.ap-northeast-3.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-northeast-3.appinfo.src/\$1" |
| 아시아 태평양(서울) | "arn:aws:s3:::packages.ap-northeast-2.amazonaws.com/","arn:aws:s3:::repo.ap-northeast-2.amazonaws.com/","arn:aws:s3:::repo.ap-northeast-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-northeast-2.appinfo.src/\$1" |
| 아시아 태평양(싱가포르) | "arn:aws:s3:::packages.ap-southeast-1.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-1.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-southeast-1.appinfo.src/\$1" |
| 아시아 태평양(시드니) | "arn:aws:s3:::packages.ap-southeast-2.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-2.amazonaws.com/","arn:aws:s3:::repo.ap-southeast-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-southeast-2.appinfo.src/\$1" |
| 아시아 태평양(도쿄) | "arn:aws:s3:::packages.ap-northeast-1.amazonaws.com/","arn:aws:s3:::repo.ap-northeast-1.amazonaws.com/","arn:aws:s3:::repo.ap-northeast-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ap-northeast-1.appinfo.src/\$1" |
| 캐나다(중부) | "arn:aws:s3:::packages.ca-central-1.amazonaws.com/","arn:aws:s3:::repo.ca-central-1.amazonaws.com/","arn:aws:s3:::repo.ca-central-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ca-central-1.appinfo.src/\$1" |
| 캐나다 서부(캘거리) | "arn:aws:s3:::packages.ca-west-1.amazonaws.com/","arn:aws:s3:::repo.ca-west-1.amazonaws.com/","arn:aws:s3:::repo.ca-west-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.ca-west-1.appinfo.src/\$1" |
| 유럽(프랑크푸르트) | "arn:aws:s3:::packages.eu-central-1.amazonaws.com/","arn:aws:s3:::repo.eu-central-1.amazonaws.com/","arn:aws:s3:::repo.eu-central-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-central-1.appinfo.src/\$1" |
| 유럽(아일랜드) | "arn:aws:s3:::packages.eu-west-1.amazonaws.com/","arn:aws:s3:::repo.eu-west-1.amazonaws.com/","arn:aws:s3:::repo.eu-west-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-west-1.appinfo.src/\$1" |
| 유럽(런던) | "arn:aws:s3:::packages.eu-west-2.amazonaws.com/","arn:aws:s3:::repo.eu-west-2.amazonaws.com/","arn:aws:s3:::repo.eu-west-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-west-2.appinfo.src/\$1" |
| 유럽(밀라노) | "arn:aws:s3:::packages.eu-south-1.amazonaws.com/","arn:aws:s3:::repo.eu-south-1.amazonaws.com/","arn:aws:s3:::repo.eu-south-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-south-1.appinfo.src/\$1" |
| 유럽(파리) | "arn:aws:s3:::packages.eu-west-3.amazonaws.com/","arn:aws:s3:::repo.eu-west-3.amazonaws.com/","arn:aws:s3:::repo.eu-west-3.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-west-3.appinfo.src/\$1" |
| 유럽(스페인) | "arn:aws:s3:::packages.eu-south-2.amazonaws.com/","arn:aws:s3:::repo.eu-south-2.amazonaws.com/","arn:aws:s3:::repo.eu-south-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-south-2.appinfo.src/\$1" |
| 유럽(스톡홀름) | "arn:aws:s3:::packages.eu-north-1.amazonaws.com/","arn:aws:s3:::repo.eu-north-1.amazonaws.com/","arn:aws:s3:::repo.eu-north-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-north-1.appinfo.src/\$1" |
| 유럽(취리히) | "arn:aws:s3:::packages.eu-central-2.amazonaws.com/","arn:aws:s3:::repo.eu-central-2.amazonaws.com/","arn:aws:s3:::repo.eu-central-2.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.eu-central-2.appinfo.src/\$1" |
| 이스라엘(텔아비브) | "arn:aws:s3:::packages.il-central-1.amazonaws.com/","arn:aws:s3:::repo.il-central-1.amazonaws.com/","arn:aws:s3:::repo.il-central-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.il-central-1.appinfo.src/\$1" |
| 중동(바레인) | "arn:aws:s3:::packages.me-south-1.amazonaws.com/","arn:aws:s3:::repo.me-south-1.amazonaws.com/","arn:aws:s3:::repo.me-south-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.me-south-1.appinfo.src/\$1" |
| 중동(UAE) | "arn:aws:s3:::packages.me-central-1.amazonaws.com/","arn:aws:s3:::repo.me-central-1.amazonaws.com/","arn:aws:s3:::repo.me-central-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.me-central-1.appinfo.src/\$1" |
| 남아메리카(상파울루) | "arn:aws:s3:::packages.sa-east-1.amazonaws.com/","arn:aws:s3:::repo.sa-east-1.amazonaws.com/","arn:aws:s3:::repo.sa-east-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.sa-east-1.appinfo.src/\$1" |
| AWS GovCloud(미국 동부) | "arn:aws:s3:::packages.us-gov-east-1.amazonaws.com/","arn:aws:s3:::repo.us-gov-east-1.amazonaws.com/","arn:aws:s3:::repo.us-gov-east-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.us-gov-east-1.appinfo.src/\$1" |
| AWS GovCloud(미국 서부) | "arn:aws:s3:::packages.us-gov-west-1.amazonaws.com/","arn:aws:s3:::repo.us-gov-west-1.amazonaws.com/","arn:aws:s3:::repo.us-gov-west-1.emr.amazonaws.com/\$1" | "arn:aws:s3:::prod.me-south-1.appinfo.src/\$1" |
## VPC에 대해 자세히 알 수 있는 추가 리소스
다음 주제를 확인하면 VPC 및 서브넷에 대해 자세히 알아볼 수 있습니다.
+ VPC의 프라이빗 서브넷
+ [시나리오 2: 퍼블릭 서브넷과 프라이빗 서브넷이 있는 VPC(NAT)](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario2.html)
+ [NAT 인스턴스](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_NAT_Instance.html)
+ [Amazon VPC NAT 인스턴스의 고가용성: 예](https://aws.amazon.com/articles/2781451301784570)
+ VPC의 퍼블릭 서브넷
+ [시나리오 1: 단일 퍼블릭 서브넷을 가진 VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Scenario1.html)
+ 일반 VPC 정보
+ [Amazon VPC User Guide](https://docs.aws.amazon.com/vpc/latest/userguide/)
+ [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)
+ [VPC에서 엘라스틱 네트워크 인터페이스 사용](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_ElasticNetworkInterfaces.html)
+ [프라이빗 VPC에서 실행 중인 Linux 인스턴스에 안전하게 연결](https://blogs.aws.amazon.com/security/post/Tx3N8GFK85UN1G6/Securely-connect-to-Linux-instances-running-in-a-private-Amazon-VPC)
# 인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성
클러스터를 생성하고 프라이머리 노드, 코어 노드 및 태스크 노드의 구성을 지정하는 경우 두 가지 구성 옵션이 있습니다. *인스턴스 플릿* 또는 *균일한 인스턴스 그룹*을 사용할 수 있습니다. 선택하는 구성 옵션은 모든 노드에 대해 클러스터의 수명 동안 적용되며, 인스턴스 집합과 인스턴스 그룹이 클러스터 하나에서 공존할 수는 없습니다. 인스턴스 플릿 구성은 5.0.x 버전을 제외한 Amazon EMR 버전 4.8.0 이상에서 제공됩니다.
Amazon EMR 콘솔, AWS CLI또는 Amazon EMR API를 사용하여 두 구성 중 하나로 클러스터를 생성할 수 있습니다. AWS CLI의 `create-cluster` 명령을 사용하는 경우 `--instance-fleets` 파라미터를 사용하여 인스턴스 플릿을 사용하는 클러스터를 생성하거나, `--instance-groups` 파라미터를 사용하여 균일한 인스턴스 그룹을 사용하는 클러스터를 생성할 수 있습니다.
Amazon EMR API를 사용할 때도 마찬가지입니다. `InstanceGroups` 구성을 사용하여 `InstanceGroupConfig` 개체 배열을 지정하거나, `InstanceFleets` 구성을 사용하여 `InstanceFleetConfig` 개체 배열을 지정할 수 있습니다.
새 Amazon EMR 콘솔에서는 클러스터를 생성할 때 인스턴스 그룹 또는 인스턴스 플릿을 사용하도록 선택할 수 있으며, 각각에서 스팟 인스턴스를 사용하는 옵션을 제공합니다. Amazon EMR 콘솔에서 클러스터 생성 시 기본 **빠른 옵션** 설정을 사용하는 경우 Amazon EMR에서 균일한 인스턴스 그룹 구성을 클러스터에 적용하고 온디맨드 인스턴스를 사용합니다. 균일한 인스턴스 그룹과 함께 스팟 인스턴스를 사용하거나 인스턴스 플릿 및 기타 사용자 지정을 구성하려면 **Advanced Options(고급 옵션)**를 선택합니다.
## 인스턴스 플릿
인스턴스 플릿 구성은 Amazon EC2 인스턴스에 대한 다양한 프로비저닝 옵션을 제공합니다. 노드 유형마다 인스턴스 플릿 하나가 있으며, 태스크 인스턴스 플릿은 선택 사항입니다. AWS CLI 또는 Amazon EMR API와 온디맨드 및 스팟 인스턴스에 대한 [할당 전략을](emr-instance-fleet.md#emr-instance-fleet-allocation-strategy) 사용하여 클러스터를 생성할 때 플릿당 최대 5개의 EC22 인스턴스 유형 또는 플릿당 30개의 EC2 인스턴스 유형을 지정할 수 있습니다. 코어 및 태스크 인스턴스 플릿의 경우 온디맨드 인스턴스에 *목표 용량*을 할당하고 스팟 인스턴스에 다른 목표 용량을 할당합니다. Amazon EMR은 목표 용량을 충족하기 위해 지정된 인스턴스 유형을 조합하여 온디맨드 인스턴스와 스팟 인스턴스를 모두 프로비저닝합니다.
프라이머리 노드 유형의 경우 Amazon EMR이 인스턴스 목록에서 단일 인스턴스 유형을 선택하고 사용자가 해당 인스턴스 유형을 온디맨드 또는 스팟 인스턴스로 프로비저닝할지 여부를 지정합니다. 인스턴스 플릿은 스팟 인스턴스 및 온디맨드 구매를 위한 추가 옵션도 제공합니다. 스팟 인스턴스 옵션에는 스팟 용량을 프로비저닝할 수 없는 경우 수행할 작업을 지정하는 제한 시간 및 스팟 인스턴스 플릿을 시작할 때 기본 할당 전략(용량 최적화)이 포함됩니다. 할당 전략(최저 가격) 옵션을 사용하여 온디맨드 인스턴스 플릿을 시작할 수도 있습니다. EMR 기본 서비스 역할이 아닌 서비스 역할을 사용하거나 서비스 역할에서 EMR 관리형 정책을 사용하는 경우 사용자 지정 클러스터 서비스 역할에 추가 권한을 추가하여 할당 전략 옵션을 활성화해야 합니다. 자세한 내용은 [Amazon EMR의 서비스 역할(EMR 역할)](emr-iam-role.md) 단원을 참조하십시오.
인스턴스 플릿 구성에 대한 자세한 내용은 [Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성](emr-instance-fleet.md) 섹션을 참조하세요.
## 균일한 인스턴스 그룹
균일한 인스턴스 그룹은 인스턴스 플릿보다 간단한 설정을 제공합니다. 각 Amazon EMR 클러스터에 최대 50개 인스턴스 그룹을 포함할 수 있으며, 이 인스턴스 그룹은 Amazon EC2 인스턴스 하나를 포함하는 프라이머리 인스턴스 그룹 하나, 하나 이상의 EC2 인스턴스를 포함하는 코어 인스턴스 그룹 하나, 그리고 최대 48개의 태스크 인스턴스 그룹(선택 사항)으로 이루어집니다. 각 코어 및 태스크 인스턴스 그룹에는 임의 개수의 Amazon EC2 인스턴스가 포함될 수 있습니다. Amazon EC2 인스턴스를 수동으로 추가 및 제거하여 각 인스턴스 그룹을 조정하거나 자동 조정을 설정할 수 있습니다. 인스턴스 추가 및 제거에 대한 자세한 내용은 [Amazon EMR 클러스터 조정을 사용하여 워크로드 변경에 맞게 조정](emr-scale-on-demand.md) 섹션을 참조하세요.
균일한 인스턴스 그룹 구성에 대한 자세한 내용은 [Amazon EMR 클러스터에 대한 균일한 인스턴스 그룹 구성](emr-uniform-instance-group.md) 섹션을 참조하세요.
## 인스턴스 플릿 및 인스턴스 그룹 작업
**Topics**
+ [
## 인스턴스 플릿
](#emr-plan-instance-fleets)
+ [
## 균일한 인스턴스 그룹
](#emr-plan-instance-groups)
+ [
## 인스턴스 플릿 및 인스턴스 그룹 작업
](#emr-plan-instance-topics)
+ [
# Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성
](emr-instance-fleet.md)
+ [
# Amazon EMR 클러스터의 인스턴스 플릿 재구성
](instance-fleet-reconfiguration.md)
+ [
# Amazon EMR의 인스턴스 플릿에서 용량 예약 사용
](on-demand-capacity-reservations.md)
+ [
# Amazon EMR 클러스터에 대한 균일한 인스턴스 그룹 구성
](emr-uniform-instance-group.md)
+ [
# Amazon EMR 클러스터에 대한 가용 영역 유연성
](emr-flexibility.md)
+ [
# 스팟 인스턴스에 대한 Amazon EMR 클러스터 인스턴스 유형 및 모범 사례 구성
](emr-plan-instances-guidelines.md)
# Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성
**참고**
인스턴스 플릿 구성은 5.0.0 및 5.0.3을 제외한 Amazon EMR 릴리스 4.8.0 이상에서만 제공됩니다.
Amazon EMR 클러스터의 인스턴스 플릿 구성을 사용하면 Amazon EC2 인스턴스에 대한 다양한 프로비저닝 옵션을 선택할 수 있으며, 클러스터의 각 노드 유형에 대해 유연하고 탄력적인 리소스 전략을 개발하는 데 도움이 됩니다.
각 인스턴스 플릿 구성에서 각 플릿 내 [온디맨드 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html) 및 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)의 *목표 용량*을 지정합니다. 클러스터를 시작할 때 대상 용량이 채워질 때까지 Amazon EMR이 인스턴스를 프로비저닝합니다. 가격 증가나 인스턴스 장애로 인해 Amazon EC2에서 실행 중인 클러스터에서 스팟 인스턴스를 회수하는 경우 Amazon EMR은 해당 인스턴스를 사용자가 지정한 인스턴스 유형으로 바꾸려고 합니다. 따라서 스팟 가격이 급증하는 동안 용량을 더 쉽게 다시 획득할 수 있습니다.
Amazon EMR이 대상을 충족할 때 사용할 Amazon EC2 인스턴스 유형을 플릿당 최대 5개까지 지정하거나, AWS CLI 또는 Amazon EMR API와 온디맨드 및 스팟 인스턴스에 대한 [할당 전략을](#emr-instance-fleet-allocation-strategy) 사용하여 클러스터를 생성할 때 플릿당 최대 30개의 Amazon EC2 인스턴스 유형을 지정할 수 있습니다.
다른 가용 영역에 다중 서브넷을 선택할 수도 있습니다. Amazon EMR이 클러스터를 시작할 때 서브넷을 둘러보며 사용자가 지정한 인스턴스 및 구매 옵션을 찾습니다. Amazon EMR이 하나 이상의 가용 영역에서 AWS 대규모 이벤트를 감지하면 Amazon EMR은 영향을 받는 가용 영역에서 트래픽을 자동으로 라우팅하고 선택 사항에 따라 대체 가용 영역에서 생성한 새 클러스터를 시작하려고 시도합니다. 클러스터 가용 영역 선택은 클러스터 생성 시에만 수행할 수 있습니다. 가용 영역이 중단되는 경우 기존 클러스터 노드는 새 가용 영역에서 자동으로 다시 시작되지 않습니다.
## **인스턴스 플릿 작업에 대한 고려 사항**
Amazon EMR에서 인스턴스 플릿을 사용할 때 다음 항목을 고려합니다.
+ 노드 유형(프라이머리, 코어, 태스크)당 하나의 인스턴스 플릿만 보유할 수 있습니다. 의 각 플릿에 대해 최대 5개의 Amazon EC2 인스턴스 유형을 지정할 수 있습니다 AWS Management Console (또는 AWS CLI 또는 Amazon EMR API 및를 사용하여 클러스터를 생성할 때 인스턴스 플릿당 최대 30개의 유형[인스턴스 플릿에 대한 할당 전략](#emr-instance-fleet-allocation-strategy)).
+ Amazon EMR은 스팟 및 온디맨드 구매 옵션을 둘 다 사용하여 프로비저닝하기 위해 지정된 Amazon EC2 인스턴스 유형 중 하나 또는 모두를 선택합니다.
+ 코어 플릿 및 태스크 플릿에 대해 스팟 및 온디맨드 인스턴스의 대상 용량을 설정할 수 있습니다. 대상 수에 포함되는 각 Amazon EC2 인스턴스에 할당된 vCPU 또는 일반 유닛을 사용합니다. Amazon EMR은 목표 용량이 완전히 충족될 때까지 인스턴스를 프로비저닝합니다. 프라이머리 플릿의 대상은 항상 하나입니다.
+ 1개의 서브넷(가용 영역) 또는 범위를 선택할 수 있습니다. 범위를 선택하면 Amazon EMR이 가장 적합한 가용 영역에서 용량을 프로비저닝합니다.
+ 스팟 인스턴스에 대한 대상 용량을 지정하는 경우:
+ 각 인스턴스 유형에 대해 최고 스팟 가격을 지정합니다. Amazon EMR은 스팟 가격이 최고 스팟 가격보다 낮은 경우 스팟 인스턴스를 프로비저닝합니다. 사용자는 스팟 가격을 지불합니다. 꼭 최고 스팟 가격인 것은 아닙니다.
+ 각 플릿마다 스팟 인스턴스를 프로비저닝할 제한 시간을 정의합니다. Amazon EMR이 스팟 용량을 프로비저닝할 수 없는 경우 클러스터를 종료하거나 프로비저닝 온디맨드 용량으로 대신 전환할 수 있습니다. 이는 클러스터 프로비저닝에만 적용되며 크기 조정에는 적용되지 않습니다. 클러스터 크기 조정 프로세스 중에 제한 시간이 종료되면 프로비저닝되지 않은 스팟 요청은 온디맨드 용량으로 전송되지 않고 무효화됩니다.
+ 각 플릿에서 스팟 인스턴스에 대해 가격-용량 최적화, 용량 최적화, 용량 최적화 우선, 최저 가격과 같은 할당 전략 중 하나를 지정하거나 모든 풀에서 다양한 옵션을 지정할 수 있습니다.
+ 각 플릿에 대해 온디맨드 인스턴스에 최저 가격 전략 또는 우선 전략과 같은 할당 전략을 적용할 수 있습니다.
+ 온디맨드 인스턴스를 사용하는 각 플릿의 경우 용량 예약 옵션을 적용하도록 선택할 수 있습니다.
+ 인스턴스 플릿에 대한 할당 전략을 사용하는 경우 EMR 클러스터의 서브넷을 선택할 때 다음 고려 사항이 적용됩니다.
+ Amazon EMR이 작업 플릿으로 클러스터를 프로비저닝하면 요청된 EMR 클러스터의 모든 인스턴스를 프로비저닝하기 위해 사용 가능한 IP 주소가 부족한 서브넷을 필터링합니다. 여기에는 클러스터 시작 중에 프라이머리, 코어 및 태스크 인스턴스 플릿에 필요한 IP 주소가 포함됩니다. 그런 다음, Amazon EMR은 할당 전략을 활용하여 IP 주소가 충분한 나머지 서브넷 및 인스턴스 유형을 기반으로 인스턴스 풀을 결정하여 클러스터를 시작합니다.
+ 사용 가능한 IP 주소가 부족하여 Amazon EMR이 전체 클러스터를 시작할 수 없는 경우 필수(코어 및 프라이머리) 인스턴스 플릿을 시작하기에 충분한 사용 가능한 IP 주소가 있는 서브넷을 식별하려고 시도합니다. 이러한 시나리오에서는 태스크 인스턴스 플릿이 오류로 클러스터를 종료하는 대신 일시 중지 상태로 전환됩니다.
+ 지정된 서브넷 중에 필수 코어 및 프라이머리 인스턴스 플릿을 프로비저닝하기에 충분한 IP 주소가 보유한 서브넷이 없는 경우 **VALIDATION\$1ERROR**로 클러스터 시작이 실패합니다. 이렇게 하면 **중요** 심각도 클러스터 종료 이벤트가 트리거되어 클러스터를 시작할 수 없음을 알립니다. 이 문제를 방지하려면 서브넷의 IP 주소 수를 늘리는 것이 좋습니다.
+ Amazon EMR 릴리스 **emr-7.7.0** 이상을 실행하고 인스턴스 플릿에 할당 전략을 사용하는 경우 인스턴스 플릿당 최대 4,000개의 EC2 인스턴스와 14,000개의 EBS 볼륨까지 클러스터를 확장할 수 있습니다. **emr-7.7.0** 미만 릴리스 버전의 경우 클러스터를 인스턴스 플릿당 EC2 인스턴스 2,000개 및 EBS 볼륨 7,000개로만 확장할 수 있습니다.
+ 온디맨드 인스턴스를 시작하는 경우 계정에서 프라이머리, 코어 및 태스크 노드에 대해 열린 용량 예약 또는 목표 용량 예약을 사용할 수 있습니다. 인스턴스 플릿의 할당 전략을 사용하는 온디맨드 인스턴스를 사용하면 용량이 충분하지 않을 수 있습니다. 많은 인스턴스 유형을 지정하여 다각화하고 용량 부족이 발생할 가능성을 줄이는 것이 좋습니다. 자세한 내용은 [Amazon EMR의 인스턴스 플릿에서 용량 예약 사용](on-demand-capacity-reservations.md) 단원을 참조하십시오.
## 인스턴스 플릿 옵션
아래 지침에 따라 인스턴스 플릿 옵션을 이해합니다.
**Topics**
+ [
### **대상 용량 설정**
](#emr-fleet-capacity)
+ [
### **시작 옵션**
](#emr-fleet-spot-options)
+ [
### **여러 서브넷(가용 영역) 옵션**
](#emr-multiple-subnet-options)
+ [
### **프라이머리 노드 구성**
](#emr-master-node-configuration)
### **대상 용량 설정**
코어 플릿 및 작업 플릿에 원하는 대상 용량을 지정합니다. 지정한 내용에 따라 Amazon EMR에서 프로비저닝할 온디맨드 인스턴스와 스팟 인스턴스의 수가 결정됩니다. 인스턴스를 지정할 때 각 인스턴스가 대상에 합산되는 수를 결정합니다. 온디맨드 인스턴스가 프로비저닝될 때는 온디맨드 대상으로 합산됩니다. 스팟 인스턴스도 마찬가지입니다. 코어 및 태스크 플릿과 달리, 프라이머리 플릿은 항상 하나의 인스턴스입니다. 그러므로 마스터 플릿의 대상 용량은 항상 하나입니다.
콘솔을 사용할 때는 기본적으로 대상 용량의 수로 Amazon EC2 인스턴스 유형의 vCPU를 사용합니다. 이것을 **범용 단위**로 변경한 후 각 EC2 인스턴스 유형의 수를 지정할 수 있습니다. 를 사용할 때 각 인스턴스 유형에 일반 단위를 수동으로 할당 AWS CLI합니다.
**중요**
를 사용하여 인스턴스 유형을 선택하면 각 **인스턴스 유형에** 대해 표시되는 **vCPU** AWS Management Console수는 해당 인스턴스 유형에 대한 EC2 vCPUs 수입니다. 인스턴스 유형별 vCPU 수에 대한 자세한 내용은 [Amazon EC2 인스턴스 유형](https://aws.amazon.com/ec2/instance-types/)을 참조하세요.
플릿마다 최대 5개의 Amazon EC2 인스턴스 유형을 지정합니다. 를 사용하고 AWS CLI 또는 Amazon EMR API를 사용하여 클러스터를 [인스턴스 플릿에 대한 할당 전략](#emr-instance-fleet-allocation-strategy) 생성하는 경우 인스턴스 플릿당 최대 30개의 EC2 인스턴스 유형을 지정할 수 있습니다. Amazon EMR은 목표 용량을 충족하기 위해 이러한 EC2 인스턴스 유형의 조합을 선택합니다. Amazon EMR은 목표 용량을 완전히 채우기를 원하므로 초과 요금이 발생할 수 있습니다. 예를 들어, 미충족 유닛이 2개이고 Amazon EMR에서 5개의 유닛 수로만 인스턴스를 프로비저닝할 수 있는 경우, 그래도 해당 인스턴스가 프로비저닝되어 목표 용량이 3개의 유닛을 초과합니다.
실행 클러스터의 크기를 조정하려고 목표 용량을 줄일 경우, Amazon EMR에서는 새 대상을 충족하기 위해 애플리케이션 작업을 종료하고 인스턴스를 종료하려고 시도합니다. 자세한 내용은 [작업 완료 시 종료](emr-scaledown-behavior.md#emr-scaledown-terminate-task) 단원을 참조하십시오.
### **시작 옵션**
인스턴스 그룹마다 플릿의 각 인스턴스 유형에 대해 **최고 스팟 가격**을 지정합니다. 이 가격을 온디맨드 가격의 백분율로 설정하거나 구체적 금액(USD)으로 설정할 수 있습니다. Amazon EMR은 가용 영역의 현재 스팟 가격이 최고 스팟 가격보다 낮은 경우 스팟 인스턴스를 프로비저닝합니다. 사용자는 스팟 가격을 지불합니다. 꼭 최고 스팟 가격인 것은 아닙니다.
**참고**
지속 시간이 정의된 스팟 인스턴스(스팟 블록이라고도 함)는 2021년 7월 1일부터 더 이상 신규 고객에게 제공되지 않습니다. 이전에 이 기능을 사용한 고객의 경우 2022년 12월 31일까지 지속 시간이 정의된 스팟 인스턴스를 계속 지원합니다.
Amazon EMR 5.12.1 이상에서 최적화된 용량 할당으로 스팟 및 온디맨드 인스턴스 플릿을 시작하는 옵션이 제공됩니다. 이 할당 전략 옵션은 이전에서 설정 AWS Management Console 하거나 API를 사용하여 설정할 수 있습니다`RunJobFlow`. 새 콘솔에서는 할당 전략을 사용자 지정할 수 없습니다. 할당 전략 옵션을 사용하려면 추가 서비스 역할 권한이 필요합니다. 클러스터의 기본 Amazon EMR 서비스 역할과 관리형 정책([`EMR_DefaultRole`](emr-iam-role.md) 및`AmazonEMRServicePolicy_v2`)을 사용하는 경우 할당 전략 옵션에 대한 권한이 이미 포함되어 있습니다. 기본 Amazon EMR 서비스 역할 및 관리형 정책을 사용하지 않는 경우 이 옵션을 사용하도록 추가해야 합니다. [Amazon EMR의 서비스 역할(EMR 역할)](emr-iam-role.md)을(를) 참조하세요.
스팟 인스턴스에 대한 자세한 내용은 Amazon EC2 사용 설명서에서 [스팟 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html)를 참조하세요. 온디맨드 인스턴스에 대한 자세한 내용은 Amazon EC2 사용 설명서에서 [온디맨드 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)를 참조하세요.
최저 가격 할당 전략으로 온디맨드 인스턴스 플릿을 시작하려는 경우 용량 예약을 사용할 수 있습니다. Amazon EMR API `RunJobFlow`를 사용하여 용량 예약 옵션을 설정할 수 있습니다. 용량 예약에는 추가 서비스 역할 권한이 필요하며, 이 옵션을 사용하려면 해당 권한을 추가해야 합니다. [할당 전략 권한할당 전략에 필요한 IAM 권한](#create-cluster-allocation-policy)을(를) 참조하세요. 새 콘솔에서는 용량 예약을 사용자 지정할 수 없습니다.
### **여러 서브넷(가용 영역) 옵션**
인스턴스 플릿을 사용할 때는 VPC 내에 각각 서로 다른 가용 영역에 해당하는 Amazon EC2 서브넷을 여러 개 지정할 수 있습니다 EC2-Classic을 사용하는 경우 가용 영역을 명시적으로 지정합니다. Amazon EMR은 플릿 사양에 따라 인스턴스를 시작하는 데 가장 적합한 가용 영역을 식별합니다. 인스턴스는 항상 단일 가용 영역에서만 프로비저닝됩니다. 프라이빗 서브넷 또는 퍼블릭 서브넷을 선택할 수 있지만 두 서브넷을 혼합할 수는 없으며, 지정된 서브넷이 동일한 VPC 안에 있어야 합니다.
### **프라이머리 노드 구성**
프라이머리 인스턴스 플릿은 단일 인스턴스이므로 이 인스턴스 플릿의 구성은 코어 및 태스크 인스턴스 플릿과는 조금 다릅니다. 인스턴스 하나로만 구성되므로 프라이머리 인스턴스 플릿에 대해 온디맨드 또는 스팟만 선택할 수 있습니다. 콘솔을 사용하여 인스턴스 집합을 생성하는 경우 선택하는 구매 옵션의 대상 용량이 1로 설정됩니다. 를 사용하는 경우 AWS CLI항상 `TargetSpotCapacity` 또는 `TargetOnDemandCapacity`를 1로 설정합니다. 프라이머리 인스턴스 플릿에 대해 여전히 최대 5개의 인스턴스 유형을 선택할 수 있습니다(또는 온디맨드 또는 스팟 인스턴스의 할당 전략 옵션을 사용할 경우 최대 30개). 하지만 Amazon EMR이 다양한 유형의 여러 인스턴스를 프로비저닝할 수 있는 코어 및 태스크 인스턴스 플릿과는 달리, 프라이머리 인스턴스 플릿에 대해서 Amazon EMR은 프로비저닝할 단일 인스턴스 유형을 선택합니다.
## 인스턴스 플릿에 대한 할당 전략
Amazon EMR 버전 5.12.1 이상에서 각 클러스터 노드의 온디맨드 및 스팟 인스턴스에서 할당 전략 옵션을 사용할 수 있습니다. AWS CLI, Amazon EMR API 또는 Amazon EMR 콘솔에서 할당 정략을 사용하여 클러스터를 생성할 때 플릿당 최대 30개의 Amazon EC2 인스턴스 유형을 지정할 수 있습니다. 기본 Amazon EMR 클러스터 인스턴스 플릿 구성을 사용하면 플릿당 최대 5개의 인스턴스 유형을 보유할 수 있습니다. 더 빠르게 클러스터를 프로비저닝하고, 더 정확하게 스팟 인스턴스를 할당하며 스팟 인스턴스 중단을 줄이려면 할당 전략 옵션을 사용하는 것이 좋습니다.
**Topics**
+ [
### 온디맨드 인스턴스에서 할당 전략
](#emr-instance-fleet-allocation-strategy-od)
+ [
### 스팟 인스턴스에서 할당 전략
](#emr-instance-fleet-allocation-strategy-spot)
+ [
### 할당 전략 권한
](#emr-instance-fleet-allocation-strategy-permissions)
+ [
### 할당 전략에 필요한 IAM 권한
](#create-cluster-allocation-policy)
### 온디맨드 인스턴스에서 할당 전략
온디맨드 인스턴스에 대해 사용할 수 있는 할당 전략은 다음과 같습니다.
`lowest-price`**(기본값)**
최저 가격 할당 전략은 가용 용량이 있는 최저 가격 풀에서 온디맨드 인스턴스를 시작합니다. 가장 낮은 가격의 풀에 사용 가능한 용량이 없는 경우 온디맨드 인스턴스는 사용 가능한 용량이 있는 다음으로 가장 낮은 가격의 풀에서 제공됩니다.
`prioritized`
우선 할당 전략을 사용하면 인스턴스 플릿의 각 인스턴스 유형에 대한 우선순위 값을 지정할 수 있습니다. Amazon EMR은 우선순위가 가장 높은 온디맨드 인스턴스를 시작합니다. 이 전략을 사용하는 경우 하나 이상의 인스턴스 유형에 대한 우선순위를 구성해야 합니다. 인스턴스 유형에 대한 우선순위 값을 구성하지 않으면 Amazon EMR에서 해당 인스턴스 유형에 가장 낮은 우선순위를 할당합니다. 클러스터의 각 인스턴스 플릿(프라이머리, 코어 또는 태스크)은 지정된 인스턴스 유형에 대해 우선순위 값이 서로 다를 수 있습니다.
**참고**
**용량 최적화 우선** 스팟 할당 전략을 사용하는 경우 우선순위를 설정할 때 Amazon EMR은 온디맨드 인스턴스와 스팟 인스턴스 모두에 동일한 우선순위를 적용합니다.
### 스팟 인스턴스에서 할당 전략
*스팟 인스턴스*에서는 다음 할당 전략 중 하나를 선택할 수 있습니다.
**`price-capacity-optimized`(권장) **
가격-용량 최적화 할당 전략은 스팟 인스턴스 풀에서 시작되는 인스턴스 수 대비 가용 용량이 가장 크고 가격이 가장 낮은 스팟 인스턴스를 시작합니다. 따라서 가격-용량 최적화 전략은 일반적으로 스팟 용량을 확보할 가능성이 더 크고 중단률도 낮습니다. Amazon EMR 릴리스 6.10.0 이상에서 기본 전략입니다.
**`capacity-optimized`**
용량 최적화 할당 전략은 가용성이 가장 높은 풀로 가까운 시일 내에 중단될 가능성이 가장 낮은 스팟 인스턴스를 시작합니다. 다시 시작하는 작업과 관련된 중단 비용이 더 높을 수 있는 워크로드에 적합합니다. 이는 Amazon EMR 릴리스 6.9.0 이하에서 기본 전략입니다.
**`capacity-optimized-prioritized`**
용량 최적화 우선 할당 전략을 사용하면 인스턴스 플릿의 각 인스턴스 유형에 대한 우선순위 값을 지정할 수 있습니다. Amazon EMR은 먼저 용량을 최적화하지만, 우선순위가 플릿의 최적 용량 프로비저닝 역량에 큰 영향을 미치지 않는 경우처럼 인스턴스 유형 우선순위를 최대한 존중합니다. 특정 인스턴스 유형에 대한 필요성이 여전히 존재하는 최소한의 중단이 요구되는 워크로드가 있는 경우 이 옵션을 사용하는 것이 좋습니다. 이 전략을 사용하는 경우 하나 이상의 인스턴스 유형에 대한 우선순위를 구성해야 합니다. 인스턴스 유형에 대한 우선순위를 구성하지 않으면 Amazon EMR에서 해당 인스턴스 유형에 가장 낮은 우선순위 값을 할당합니다. 클러스터의 각 인스턴스 플릿(프라이머리, 코어 또는 태스크)은 지정된 인스턴스 유형에 대해 우선순위 값이 서로 다를 수 있습니다.
**우선** 온디맨드 할당 전략을 사용하는 경우 우선순위를 설정할 때 Amazon EMR은 온디맨드 및 스팟 인스턴스 모두에 동일한 우선순위 값을 적용합니다.
**`diversified`**
Amazon EC2는 다양한 할당 전략을 사용하여 스팟 인스턴스를 모든 스팟 용량 풀에 분산합니다.
**`lowest-price`**
최저 가격 할당 전략은 가용 용량이 있는 최저 가격 풀에서 스팟 인스턴스를 시작합니다. 가장 낮은 가격의 풀에 사용 가능한 용량이 없는 경우 스팟 인스턴스는 사용 가능한 용량이 있는 다음으로 가장 낮은 가격의 풀에서 제공됩니다. 요청한 용량을 이행하기 전에 풀에 용량이 부족해지면 Amazon EC2 플릿은 다음으로 가격이 낮은 풀에서 끌어와 요청을 계속 이행합니다. 목표 용량이 충족되었는지 확인하기 위해 여러 풀에서 스팟 인스턴스를 받을 수도 있습니다. 이 전략은 인스턴스 가격만 고려하고 용량 가용성은 고려하지 않기 때문에 중단률이 높아질 수 있습니다.
### 할당 전략 권한
할당 전략 옵션에는 기본 Amazon EMR 서비스 역할 및 Amazon EMR 관리형 정책(`EMR_DefaultRole` 및 `AmazonEMRServicePolicy_v2`)에 자동으로 포함되는 여러 IAM 권한이 필요합니다. 클러스터에 사용자 지정 서비스 역할 또는 관리형 정책을 사용하는 경우 클러스터를 생성하기 전에 이러한 권한을 추가해야 합니다. 자세한 내용은 [할당 전략 권한할당 전략에 필요한 IAM 권한](#create-cluster-allocation-policy) 단원을 참조하십시오.
온디맨드 할당 전략 옵션을 사용하면 선택적 온디맨드 용량 예약(ODCR)을 사용할 수 있습니다. 용량 예약 옵션을 사용하면 Amazon EMR 클러스터에서 예약 용량을 먼저 사용하기 위한 기본 설정을 지정할 수 있습니다. 이를 통해 열린 ODCR 또는 목표 ODCR을 사용하여 이미 예약한 용량을 중요한 워크로드에 사용하도록 할 수 있습니다. 중요하지 않은 워크로드의 경우 용량 예약 기본 설정을 통해 예약 용량을 사용할지 여부를 지정할 수 있습니다.
용량 예약은 속성(인스턴스 유형, 플랫폼, 가용 영역)이 일치하는 인스턴스에서만 사용할 수 있습니다. 기본적으로 Amazon EMR은 인스턴스 속성과 일치하는 온디맨드 인스턴스를 프로비저닝할 때 자동으로 열린 용량 예약을 사용합니다. 용량 예약의 속성과 일치하는 인스턴스를 실행하고 있지 않으면 속성과 일치하는 인스턴스를 시작할 때까지 미사용 상태로 유지됩니다. 클러스터를 시작할 때 용량 예약을 사용하지 않으려면 시작 옵션에서 용량 예약 기본 설정을 **없음**으로 설정해야 합니다.
하지만 특정 워크로드에 용량 예약을 대상으로 지정할 수도 있습니다. 이렇게 하면 예약 용량으로 실행할 수 있는 인스턴스를 명시적으로 제어할 수 있습니다. 온디맨드 용량 예약에 대한 자세한 내용은 [Amazon EMR의 인스턴스 플릿에서 용량 예약 사용](on-demand-capacity-reservations.md) 섹션을 참조하세요.
### 할당 전략에 필요한 IAM 권한
온디맨드 또는 스팟 인스턴스 플릿에 대한 할당 전략 옵션을 사용하는 클러스터를 생성하려면 [Amazon EMR의 서비스 역할(EMR 역할)](emr-iam-role.md)에 추가 권한이 필요합니다.
이러한 권한을 기본 Amazon EMR 서비스 역할 [`EMR_DefaultRole`](emr-iam-role.md) 및 Amazon EMR 관리형 정책 [`AmazonEMRServicePolicy_v2`](emr-managed-iam-policies.md)에 자동으로 포함합니다.
클러스터에 사용자 지정 서비스 역할 또는 관리형 정책을 사용하는 경우 다음 권한을 추가해야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DeleteLaunchTemplate",
"ec2:CreateLaunchTemplate",
"ec2:DescribeLaunchTemplates",
"ec2:CreateLaunchTemplateVersion",
"ec2:CreateFleet"
],
"Resource": [
"*"
],
"Sid": "AllowEC2Deletelaunchtemplate"
}
]
}
```
------
열린 용량 예약 또는 목표 용량 예약을 사용하는 클러스터를 생성하려면 다음과 같은 서비스 역할 권한이 필요합니다. 할당 전략 옵션을 사용하는 데 필요한 권한과 함께 이러한 권한을 포함해야 합니다.
**Example 서비스 역할 용량 예약에 대한 정책 문서**
열린 용량 예약을 사용하려면 다음과 같은 추가 권한을 포함해야 합니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeCapacityReservations",
"ec2:DescribeLaunchTemplateVersions",
"ec2:DeleteLaunchTemplateVersions"
],
"Resource": [
"*"
],
"Sid": "AllowEC2Describecapacityreservations"
}
]
}
```
**Example**
목표 용량 예약을 사용하려면 다음과 같은 추가 권한을 포함해야 합니다.
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:DescribeCapacityReservations",
"ec2:DescribeLaunchTemplateVersions",
"ec2:DeleteLaunchTemplateVersions",
"resource-groups:ListGroupResources"
],
"Resource": [
"*"
],
"Sid": "AllowEC2Describecapacityreservations"
}
]
}
```
## 클러스터의 인스턴스 플릿 구성
------
#### [ Console ]
**콘솔을 사용하여 인스턴스 플릿을 포함하는 클러스터를 생성하는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 **클러스터 생성**을 선택합니다.
1. **클러스터 구성**에서 **인스턴스 플릿**을 선택합니다.
1. 각 **노드 그룹**에 대해 **인스턴스 유형 추가**를 선택하고 프라이머리 및 코어 인스턴스 플릿의 경우 최대 5개의 인스턴스 유형을 선택하고 태스크 인스턴스 플릿의 경우 최대 15개의 인스턴스 유형을 선택합니다. Amazon EMR은 클러스터를 시작할 때 이러한 인스턴스 유형을 원하는 대로 조합하여 프로비저닝할 수 있습니다.
1. 각 노드 그룹 유형에서 각 인스턴스 옆에 있는 **작업** 드롭다운 메뉴를 선택하여 다음 설정을 변경합니다.
**EBS 볼륨 추가**
Amazon EMR에서 프로비저닝한 후 인스턴스 유형에 연결할 EBS 볼륨을 지정합니다.
**가중치 기반 용량 편집**
코어 노드 그룹의 경우 이 값을 애플리케이션에 맞는 유닛 수로 변경합니다. 각 플릿 인스턴스 유형의 YARN vcore의 수는 기본 가중치 기반 용량 유닛으로 사용됩니다. 프라이미러 노드의 가중치 기반 용량은 편집할 수 없습니다.
**최고 스팟 가격 편집**
플릿에서 인스턴스 유형에 대해 최고 스팟 가격을 지정합니다. 이 가격을 온디맨드 가격의 백분율로 설정하거나 구체적 금액(USD)으로 설정할 수 있습니다. 가용 영역의 현재 스팟 가격이 최고 스팟 가격 미만인 경우 Amazon EMR은 스팟 인스턴스를 프로비저닝합니다. 사용자는 스팟 가격을 지불합니다. 꼭 최고 스팟 가격인 것은 아닙니다.
1. 선택적으로 노드에 보안 그룹을 추가하려면 **네트워킹** 섹션에서 **EC2 보안 그룹(방화벽)**을 확장하고 각 노드 유형에 맞는 보안 그룹을 선택합니다.
1. 선택적으로 할당 전략 옵션을 사용하려는 경우 **할당 전략 적용** 옆의 확인란을 선택하고 스팟 인스턴스에 지정하려는 할당 전략을 선택합니다. Amazon EMR 서비스 역할에 필요한 권한이 없는 경우에는 이 옵션을 선택하지 않아야 합니다. 자세한 내용은 [인스턴스 플릿에 대한 할당 전략](#emr-instance-fleet-allocation-strategy) 단원을 참조하십시오.
1. 클러스터에 적용할 다른 옵션을 선택합니다.
1. 클러스터를 시작하려면 **클러스터 생성**을 선택합니다.
------
#### [ AWS CLI ]
를 사용하여 인스턴스 플릿이 있는 클러스터를 생성하고 시작하려면 다음 지침을 AWS CLI따르세요.
+ 인스턴스 집합으로 클러스터를 구성하고 시작하려면 `create-cluster` 명령을 `--instance-fleet` 파라미터와 함께 사용합니다.
+ 클러스터에 내 인스턴스 플릿에 대한 구성 세부 정보를 가져오려면 `list-instance-fleets` 명령을 사용합니다.
+ 생성 중인 클러스터에 사용자 지정 Amazon Linux AMI를 여러 개 추가하려면 각 `InstanceType` 사양과 함께 `CustomAmiId` 옵션을 사용합니다. 요구 사항에 맞게 여러 인스턴스 유형과 다중 사용자 지정 AMI를 사용하여 인스턴스 플릿 노드를 구성할 수 있습니다. [예제: 인스턴스 플릿 구성을 포함하는 클러스터 생성](#create-cluster-instance-fleet-cli)을(를) 참조하세요.
+ 인스턴스 집합에 대한 대상 용량을 변경하려면 `modify-instance-fleet` 명령을 사용합니다.
+ 작업 인스턴스 집합이 아직 없는 클러스터에 작업 인스턴스 집합을 추가하려면(아직 없는 경우) `add-instance-fleet` 명령을 사용합니다.
+ add-instance-fleet 명령에서 CustomAmiId 인수를 사용하여 여러 사용자 지정 AMI를 태스크 인스턴스 플릿에 추가할 수 있습니다. [예제: 인스턴스 플릿 구성을 포함하는 클러스터 생성](#create-cluster-instance-fleet-cli)을(를) 참조하세요.
+ 인스턴스 플릿을 생성할 때 할당 전략 옵션을 사용하려면 다음 섹션의 예제 정책 문서를 포함하도록 서비스 역할을 업데이트합니다.
+ 온디맨드 할당 전략을 포함하는 인스턴스 플릿을 생성할 때 용량 예약 옵션을 사용하려면 다음 섹션의 예제 정책 문서를 포함하도록 서비스 역할을 업데이트합니다.
+ 인스턴스 플릿은 기본 EMR 서비스 역할 및 Amazon EMR 관리형 정책(`EMR_DefaultRole` 및 `AmazonEMRServicePolicy_v2`)에 자동으로 포함됩니다. 클러스터에 사용자 지정 서비스 역할 또는 사용자 지정 관리형 정책을 사용하는 경우 다음 섹션에서 할당 전략에 대한 새 권한을 추가해야 합니다.
------
## 예제: 인스턴스 플릿 구성을 포함하는 클러스터 생성
다음 예는 결합할 수 있는 다양한 옵션과 함께 사용되는 `create-cluster` 명령을 보여 줍니다.
**참고**
기본 Amazon EMR 서비스 역할 및 EC2 인스턴스 프로파일을 아직 생성하지 않은 경우 `aws emr create-default-roles` 명령을 사용하기 전에 `create-cluster` 명령을 사용하여 프로파일을 생성합니다.
**Example 예제: 온디맨드 프라이머리, 온디맨드 코어(단일 인스턴스 유형 사용), 기본 VPC**
```
aws emr create-cluster --release-label emr-5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge}']
```
**Example 예제: 스팟 프라이머리, 스팟 코어(단일 인스턴스 유형 사용), 기본 VPC**
```
aws emr create-cluster --release-label emr-5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets \
InstanceFleetType=MASTER,TargetSpotCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5}'] \
InstanceFleetType=CORE,TargetSpotCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5}']
```
**Example 예제: 온디맨드 프라이머리, 혼합 코어(단일 인스턴스 유형 사용), 단일 EC2 서브넷**
```
aws emr create-cluster --release-label emr-5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,SubnetIds=['subnet-ab12345c'] \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=2,TargetSpotCapacity=6,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5,WeightedCapacity=2}']
```
**Example 예제: 온디맨드 프라이머리, 스팟 코어(여러 가중치 인스턴스 유형 사용), 스팟의 제한 시간, EC2 서브넷의 범위**
```
aws emr create-cluster --release-label emr-5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,SubnetIds=['subnet-ab12345c','subnet-de67890f'] \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge}'] \
InstanceFleetType=CORE,TargetSpotCapacity=11,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5,WeightedCapacity=3}',\
'{InstanceType=m4.2xlarge,BidPrice=0.9,WeightedCapacity=5}'],\
LaunchSpecifications={SpotSpecification='{TimeoutDurationMinutes=120,TimeoutAction=SWITCH_TO_ON_DEMAND}'}
```
**Example 예제: 온디맨드 프라이머리, 혼합 코어 및 태스크(여러 가중치 인스턴스 유형 사용), 코어 스팟 인스턴스의 제한 시간, EC2 서브넷의 범위**
```
aws emr create-cluster --release-label emr-5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole,SubnetIds=['subnet-ab12345c','subnet-de67890f'] \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=m5.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=8,TargetSpotCapacity=6,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5,WeightedCapacity=3}',\
'{InstanceType=m4.2xlarge,BidPrice=0.9,WeightedCapacity=5}'],\
LaunchSpecifications={SpotSpecification='{TimeoutDurationMinutes=120,TimeoutAction=SWITCH_TO_ON_DEMAND}'} \
InstanceFleetType=TASK,TargetOnDemandCapacity=3,TargetSpotCapacity=3,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5,WeightedCapacity=3}']
```
**Example 예: 스팟 프라이머리, 코어 또는 태스크 없음, Amazon EBS 구성, 기본 VPC**
```
aws emr create-cluster --release-label Amazon EMR 5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets \
InstanceFleetType=MASTER,TargetSpotCapacity=1,\
LaunchSpecifications={SpotSpecification='{TimeoutDurationMinutes=60,TimeoutAction=TERMINATE_CLUSTER}'},\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5,\
EbsConfiguration={EbsOptimized=true,EbsBlockDeviceConfigs=[{VolumeSpecification={VolumeType=gp2,\
SizeIn GB=100}},{VolumeSpecification={VolumeType=io1,SizeInGB=100,Iop s=100},VolumesPerInstance=4}]}}']
```
**Example 예제: 여러 사용자 지정 AMI, 여러 인스턴스 유형, 온디맨드 프라이머리, 온디맨드 코어**
```
aws emr create-cluster --release-label Amazon EMR 5.3.1 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-123456},{InstanceType=m6g.xlarge, CustomAmiId=ami-234567}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-123456},{InstanceType=m6g.xlarge, CustomAmiId=ami-234567}']
```
**Example 예제: 여러 인스턴스 유형과 여러 사용자 지정 AMI가 있는 실행 중인 클러스터에 태스크 노드 추가**
```
aws emr add-instance-fleet --cluster-id j-123456 --release-label Amazon EMR 5.3.1 \
--service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleet \
InstanceFleetType=Task,TargetSpotCapacity=1,\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,CustomAmiId=ami-123456}',\
'{InstanceType=m6g.xlarge,CustomAmiId=ami-234567}']
```
**Example 예제: JSON 구성 파일 사용**
JSON 파일에서 인스턴스 집합 파라미터를 구성한 다음 JSON 파일을 인스턴스 집합의 유일한 파라미터로 참조할 수 있습니다. 예를 들어, 다음 명령은 JSON 구성 파일(`my-fleet-config.json`)을 참조합니다.
```
aws emr create-cluster --release-label emr-5.30.0 --service-role EMR_DefaultRole \
--ec2-attributes InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets file://my-fleet-config.json
```
*my-fleet-config.json*은 다음 예제에서처럼 프라이머리, 코어 및 태스크 인스턴스 플릿을 지정합니다. 코어 인스턴스 플릿은 온디맨드의 백분율로 최고 스팟 가격(`BidPrice`)을 사용하는 반면, 작업 및 프라이머리 인스턴스 플릿은 USD 단위의 문자열로 최대 스팟 가격(BidPriceAsPercentageofOnDemandPrice)을 사용합니다.
```
[
{
"Name": "Masterfleet",
"InstanceFleetType": "MASTER",
"TargetSpotCapacity": 1,
"LaunchSpecifications": {
"SpotSpecification": {
"TimeoutDurationMinutes": 120,
"TimeoutAction": "SWITCH_TO_ON_DEMAND"
}
},
"InstanceTypeConfigs": [
{
"InstanceType": "m5.xlarge",
"BidPrice": "0.89"
}
]
},
{
"Name": "Corefleet",
"InstanceFleetType": "CORE",
"TargetSpotCapacity": 1,
"TargetOnDemandCapacity": 1,
"LaunchSpecifications": {
"OnDemandSpecification": {
"AllocationStrategy": "lowest-price",
"CapacityReservationOptions":
{
"UsageStrategy": "use-capacity-reservations-first",
"CapacityReservationResourceGroupArn": "String"
}
},
"SpotSpecification": {
"AllocationStrategy": "capacity-optimized",
"TimeoutDurationMinutes": 120,
"TimeoutAction": "TERMINATE_CLUSTER"
}
},
"InstanceTypeConfigs": [
{
"InstanceType": "m5.xlarge",
"BidPriceAsPercentageOfOnDemandPrice": 100
}
]
},
{
"Name": "Taskfleet",
"InstanceFleetType": "TASK",
"TargetSpotCapacity": 1,
"LaunchSpecifications": {
"OnDemandSpecification": {
"AllocationStrategy": "lowest-price",
"CapacityReservationOptions":
{
"CapacityReservationPreference": "none"
}
},
"SpotSpecification": {
"TimeoutDurationMinutes": 120,
"TimeoutAction": "TERMINATE_CLUSTER"
}
},
"InstanceTypeConfigs": [
{
"InstanceType": "m5.xlarge",
"BidPrice": "0.89"
}
]
}
]
```
## 인스턴스 플릿의 대상 용량 수정
`modify-instance-fleet` 명령을 사용하여 인스턴스 집합에 대해 새 대상 용량을 지정합니다. 클러스터 ID와 인스턴스 집합 ID를 지정해야 합니다. `list-instance-fleets` 명령을 사용하여 인스턴스 집합 ID를 검색합니다.
```
aws emr modify-instance-fleet --cluster-id \
--instance-fleet \
InstanceFleetId='',TargetOnDemandCapacity=1,TargetSpotCapacity=1
```
## 클러스터에 태스크 인스턴스 플릿 추가
클러스터에 프라이머리 및 코어 인스턴스 플릿만 있는 경우 `add-instance-fleet` 명령을 사용하여 태스크 인스턴스 플릿을 추가할 수 있습니다. 이 방법으로만 작업 인스턴스 집합을 추가할 수 있습니다.
```
aws emr add-instance-fleet --cluster-id
--instance-fleet \
InstanceFleetType=TASK,TargetSpotCapacity=1,\
LaunchSpecifications={SpotSpecification='{TimeoutDurationMinutes=20,TimeoutAction=TERMINATE_CLUSTER}'},\
InstanceTypeConfigs=['{InstanceType=m5.xlarge,BidPrice=0.5}']
```
## 클러스터 내 인스턴스 플릿의 구성 세부 정보 가져오기
`list-instance-fleets` 명령을 사용하여 클러스터 내 인스턴스 집합의 구성 세부 정보를 가져옵니다. 이 명령은 클러스터 ID를 입력으로 사용합니다. 다음 예제에서는 프라이머리 태스크 인스턴스 그룹 및 코어 태스크 인스턴스 그룹을 포함하는 클러스터에 대한 이 명령과 관련 출력을 보여줍니다. 전체 응답 구문은 *Amazon EMR API 참조*에서 [ListInstanceFleets](https://docs.aws.amazon.com/ElasticMapReduce/latest/API/API_ListInstanceFleets.html)를 참조하세요.
```
list-instance-fleets --cluster-id
```
```
{
"InstanceFleets": [
{
"Status": {
"Timeline": {
"ReadyDateTime": 1488759094.637,
"CreationDateTime": 1488758719.817
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"ProvisionedSpotCapacity": 6,
"Name": "CORE",
"InstanceFleetType": "CORE",
"LaunchSpecifications": {
"SpotSpecification": {
"TimeoutDurationMinutes": 60,
"TimeoutAction": "TERMINATE_CLUSTER"
}
},
"ProvisionedOnDemandCapacity": 2,
"InstanceTypeSpecifications": [
{
"BidPrice": "0.5",
"InstanceType": "m5.xlarge",
"WeightedCapacity": 2
}
],
"Id": "if-1ABC2DEFGHIJ3"
},
{
"Status": {
"Timeline": {
"ReadyDateTime": 1488759058.598,
"CreationDateTime": 1488758719.811
},
"State": "RUNNING",
"StateChangeReason": {
"Message": ""
}
},
"ProvisionedSpotCapacity": 0,
"Name": "MASTER",
"InstanceFleetType": "MASTER",
"ProvisionedOnDemandCapacity": 1,
"InstanceTypeSpecifications": [
{
"BidPriceAsPercentageOfOnDemandPrice": 100.0,
"InstanceType": "m5.xlarge",
"WeightedCapacity": 1
}
],
"Id": "if-2ABC4DEFGHIJ4"
}
]
}
```
# Amazon EMR 클러스터의 인스턴스 플릿 재구성
Amazon EMR 버전 5.21.0 이상에서는 클러스터 애플리케이션을 재구성하고 실행 중인 클러스터의 각 인스턴스 플릿에 대해 추가 구성 분류를 지정할 수 있습니다. 이를 위해 AWS 명령줄 인터페이스(AWS CLI) 또는 AWS SDK를 사용할 수 있습니다.
CloudWatch 이벤트를 확인하여 인스턴스 플릿의 상태를 추적할 수 있습니다. 자세한 내용은 [인스턴스 플릿 재구성 이벤트](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html#emr-cloudwatch-instance-fleet-events-reconfig)를 참조하세요.
**참고**
클러스터 생성 시 지정된 클러스터 구성 객체만 재정의할 수 있습니다. 구성 객체에 대한 자세한 내용은 [RunJobFlow 요청 구문](https://docs.aws.amazon.com/emr/latest/APIReference/API_RunJobFlow.html#API_RunJobFlow_RequestSyntax)을 참조하세요. 기존 구성과 제공한 파일 간에 차이가 있는 경우 Amazon EMR은 수동으로 수정한 구성(예: SSH를 사용하여 클러스터에 연결하는 동안 수정한 구성)을 지정된 인스턴스 플릿의 클러스터 기본값으로 재설정합니다.
Amazon EMR 콘솔, AWS 명령줄 인터페이스(AWS CLI) 또는 AWS SDK를 사용하여 재구성 요청을 제출하면 Amazon EMR은 기존 클러스터 내 구성 파일을 확인합니다. 기존 구성과 제공한 파일 간에 차이가 있는 경우 Amazon EMR은 재구성 작업을 시작하고 일부 애플리케이션을 다시 시작하며 수동으로 수정한 구성(예: SSH를 사용하여 클러스터에 연결하는 동안 수정한 구성)을 지정된 인스턴스 플릿의 클러스터 기본값으로 재설정합니다.
## 재구성 동작
재구성은 새로 제출된 구성 세트로 클러스터 내 구성을 덮어쓰고 재구성 API 외부에서 수행된 구성 변경 사항을 덮어쓸 수 있습니다.
Amazon EMR은 롤링 프로세스에 따라 태스크 및 코어 인스턴스 플릿의 인스턴스를 재구성합니다. 인스턴스 그룹에 있는 인스턴스 중 1%만 동시에 수정 및 다시 시작됩니다. 인스턴스 플릿에 여러 인스턴스 유형 구성이 있는 경우 병렬로 재구성됩니다.
재구성은 [InstanceTypeConfig](https://docs.aws.amazon.com/emr/latest/APIReference/API_InstanceTypeConfig.html) 수준에서 선언됩니다. 시각적 예제는 섹션을 참조하세요[인스턴스 플릿 재구성](#instance-fleet-reconfiguration-cli-sdk). 단일 요청 내에서 하나 이상의 인스턴스 유형에 대한 업데이트된 구성 설정이 포함된 재구성 요청을 제출할 수 있습니다. 인스턴스 플릿의 일부인 모든 인스턴스 유형을 수정 요청에 포함해야 하지만 구성 필드가 채워진 인스턴스 유형은 재구성되는 반면 플릿의 다른 `InstanceTypeConfig` 인스턴스는 변경되지 않습니다. 재구성은 지정된 인스턴스 유형의 모든 인스턴스가 재구성을 완료한 경우에만 성공한 것으로 간주됩니다. 인스턴스를 다시 구성하지 못하면 전체 인스턴스 플릿이 마지막으로 알려진 안정적인 구성으로 자동 돌아갑니다.
## 제한 사항
실행 중인 클러스터에서 인스턴스 플릿을 재구성할 경우 다음 제한 사항을 고려합니다.
+ Yarn 기반이 아닌 애플리케이션에서 특히 애플리케이션이 제대로 구성되지 않은 경우 다시 시작 중에 실패하거나 클러스터 문제가 발생할 수 있습니다. 클러스터의 최대 메모리 및 CPU 사용량에 근접하면 다시 시작 프로세스 후에 문제가 발생할 수 있습니다. 프라이머리 인스턴스 플릿의 경우 특히 그렇습니다. [인스턴스 플릿 재구성 문제 해결](#instance-fleet-reconfiguration-troubleshooting) 섹션을 참조하세요.
+ 크기 조정 작업 및 재구성 작업은 병렬로 수행되지 않습니다. 재구성 요청은 지속적인 크기 조정을 대기하며 그 반대의 경우도 마찬가지입니다.
+ 크기 조정 작업 및 재구성 작업은 병렬로 수행되지 않습니다. 재구성 요청은 지속적인 크기 조정을 대기하며 그 반대의 경우도 마찬가지입니다.
+ 인스턴스 플릿을 재구성한 후 Amazon EMR에서 애플리케이션을 다시 시작하여 새 구성을 적용합니다. 재구성하는 동안 애플리케이션이 사용 중이면 작업이 실패하거나 예기치 않은 다른 애플리케이션 동작이 발생할 수 있습니다.
+ 인스턴스 플릿 아래의 인스턴스 유형 구성에 대한 재구성이 실패하면 Amazon EMR은 이벤트 내보내기 및 상태 세부 정보 업데이트와 함께 구성 파라미터를 전체 인스턴스 플릿의 이전 작업 버전으로 되돌립니다. 리버전 프로세스가 실패하면 새 `ModifyInstanceFleet` 요청을 제출하여 인스턴스 그룹을 `ARRESTED` 상태에서 복구합니다. 되돌리기가 실패하면 [인스턴스 플릿 재구성 이벤트](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-cloudwatch-events.html#emr-cloudwatch-instance-fleet-events-reconfig) 및 상태 변경이 발생합니다.
+ Phoenix 구성 분류에 대한 재구성 요청은 Amazon EMR 버전 5.23.0 이상에서만 지원되고 Amazon EMR 버전 5.21.0 또는 5.22.0에서는 지원되지 않습니다.
+ HBase 구성 분류에 대한 재구성 요청은 Amazon EMR 버전 5.30.0 이상에서만 지원되고 Amazon EMR 버전 5.23.0\$15.29.0에서는 지원되지 않습니다.
+ 모든 Hadoop KMS 구성 분류 또는 hdfs-encryption-zones 분류의 재구성은 여러 프라이머리 노드가 있는 Amazon EMR 클러스터에서 지원되지 않습니다.
+ Amazon EMR은 YARN ResourceManager를 다시 시작해야 하는 YARN 용량 스케줄러에 대한 특정 재구성 요청을 지원하지 않습니다. 예를 들어, 대기열을 완전히 제거할 수는 없습니다.
+ YARN을 다시 시작해야 하는 경우 일반적으로 실행 중인 모든 YARN 작업이 종료되고 손실됩니다. 이로 인해 데이터 처리가 지연될 수 있습니다. YARN을 다시 시작하는 중에 YARN 작업을 실행하려면, 여러 프라이머리 노드가 있는 Amazon EMR 클러스터를 생성하거나 yarn-site 구성 분류에서 yarn.resourcemanager.recovery.enabled를 `true`로 설정하세요. 여러 프라이머리 노드 사용에 대한 자세한 내용은 [고가용성 YARN ResourceManager](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-applications.html#emr-plan-ha-applications-YARN)를 참조하세요.
## 인스턴스 플릿 재구성
------
#### [ Using the AWS CLI ]
`modify-instance-fleet` 명령을 사용하여 실행 중인 클러스터의 인스턴스 플릿에 대해 새 구성을 지정합니다.
**참고**
다음 예제에서 **j-2AL4XXXXXX5T9**를 클러스터 ID로 바꾸고 **if-1xxxxxxx9**를 인스턴스 플릿 ID로 바꿉니다.
**예제 - 인스턴스 플릿에 대한 구성 교체**
**주의**
시작 시 사용한 모든 `InstanceTypeConfig` 필드를 지정합니다. 필드를 포함하지 않으면 시작 시 선언한 사양을 덮어쓸 수 있습니다. 목록은 [InstanceTypeConfig](https://docs.aws.amazon.com/emr/latest/APIReference/API_InstanceTypeConfig.html)를 참조하세요.
다음 예제에서는 구성 JSON 파일(instanceFleet.json)을 참조하여 인스턴스 플릿에 대해 YARN NodeManager 디스크 상태 검사기의 속성을 편집합니다.
**인스턴스 플릿 수정 JSON**
1. 구성 분류를 준비하고 명령을 실행할 디렉터리와 동일한 디렉터리에 instanceFleet.json으로 저장합니다.
```
{
"InstanceFleetId":"if-1xxxxxxx9",
"InstanceTypeConfigs": [
{
"InstanceType": "m5.xlarge",
other InstanceTypeConfig fields
"Configurations": [
{
"Classification": "yarn-site",
"Properties": {
"yarn.nodemanager.disk-health-checker.enable":"true",
"yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0"
}
}
]
},
{
"InstanceType": "r5.xlarge",
other InstanceTypeConfig fields
"Configurations": [
{
"Classification": "yarn-site",
"Properties": {
"yarn.nodemanager.disk-health-checker.enable":"false",
"yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"70.0"
}
}
]
}
]
```
1. 다음 명령을 실행합니다.
```
aws emr modify-instance-fleet \
--cluster-id j-2AL4XXXXXX5T9 \
--region us-west-2 \
--instance-fleet instanceFleet.json
```
**예제 - 인스턴스 플릿에 구성 추가**
인스턴스 그룹에 구성을 추가하려면 새 `ModifyInstanceFleet` 요청에 해당 인스턴스 그룹에 대해 이전에 지정한 구성도 포함합니다. 그렇지 않으면 이전에 지정한 구성이 제거됩니다.
다음 예제에서는 YARN NodeManager 가상 메모리 검사기의 속성을 추가합니다. 또한 구성에는 값을 덮어쓰지 않도록 YARN NodeManager 디스크 상태 검사기에 대해 이전에 지정한 값도 포함됩니다.
1. instanceFleet.json에서 다음 콘텐츠를 준비하고 명령을 실행할 동일한 디렉터리에 저장합니다.
```
{
"InstanceFleetId":"if-1xxxxxxx9",
"InstanceTypeConfigs": [
{
"InstanceType": "m5.xlarge",
other InstanceTypeConfig fields
"Configurations": [
{
"Classification": "yarn-site",
"Properties": {
"yarn.nodemanager.disk-health-checker.enable":"true",
"yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"100.0",
"yarn.nodemanager.vmem-check-enabled":"true",
"yarn.nodemanager.vmem-pmem-ratio":"3.0"
}
}
]
},
{
"InstanceType": "r5.xlarge",
other InstanceTypeConfig fields
"Configurations": [
{
"Classification": "yarn-site",
"Properties": {
"yarn.nodemanager.disk-health-checker.enable":"false",
"yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage":"70.0"
}
}
]
}
]
}
```
1. 다음 명령을 실행합니다.
```
aws emr modify-instance-fleet \
--cluster-id j-2AL4XXXXXX5T9 \
--region us-west-2 \
--instance-fleet instanceFleet.json
```
------
#### [ using the Java SDK ]
**참고**
다음 예제에서 **j-2AL4XXXXXX5T9**를 클러스터 ID로 바꾸고 **if-1xxxxxxx9**를 인스턴스 플릿 ID로 바꿉니다.
다음 코드 조각은 Java용 AWS SDK를 사용하여 인스턴스 플릿에 대한 새 구성을 제공합니다.
```
AWSCredentials credentials = new BasicAWSCredentials("access-key", "secret-key");
AmazonElasticMapReduce emr = new AmazonElasticMapReduceClient(credentials);
Map hiveProperties = new HashMap();
hiveProperties.put("hive.join.emit.interval","1000");
hiveProperties.put("hive.merge.mapfiles","true");
Configuration newConfiguration = new Configuration()
.withClassification("hive-site")
.withProperties(hiveProperties);
List instanceTypeConfigList = new ArrayList<>();
for (InstanceTypeConfig instanceTypeConfig : currentInstanceTypeConfigList) {
instanceTypeConfigList.add(new InstanceTypeConfig()
.withInstanceType(instanceTypeConfig.getInstanceType())
.withBidPrice(instanceTypeConfig.getBidPrice())
.withWeightedCapacity(instanceTypeConfig.getWeightedCapacity())
.withConfigurations(newConfiguration)
);
}
InstanceFleetModifyConfig instanceFleetModifyConfig = new InstanceFleetModifyConfig()
.withInstanceFleetId("if-1xxxxxxx9")
.withInstanceTypeConfigs(instanceTypeConfigList);
ModifyInstanceFleetRequest modifyInstanceFleetRequest = new ModifyInstanceFleetRequest()
.withInstanceFleet(instanceFleetModifyConfig)
.withClusterId("j-2AL4XXXXXX5T9");
emrClient.modifyInstanceFleet(modifyInstanceFleetRequest);
```
------
## 인스턴스 플릿 재구성 문제 해결
인스턴스 플릿 내 인스턴스 유형의 재구성 프로세스가 실패할 경우, Amazon EMR은 Amazon CloudWatch Events 이벤트를 사용하여 진행 중인 재구성을 되돌리고 실패 메시지를 로깅합니다. 이벤트는 재구성 실패에 대한 간략한 요약을 제공합니다. 재구성이 실패한 인스턴스와 해당 실패 메시지를 나열합니다. 다음은 실패 메시지의 예입니다.
`Amazon EMR couldn't revert the instance fleet if-1xxxxxxx9 in the Amazon EMR cluster j-2AL4XXXXXX5T9 (ExampleClusterName) to the previously successful configuration at 2021-01-01 00:00 UTC. The reconfiguration reversion failed because of Instance i-xxxxxxx1, i-xxxxxxx2, i-xxxxxxx3 failed with message "This is an example failure message"...`
### 노드 프로비저닝 로그에 액세스하는 방법
SSH를 사용하여 재구성이 실패한 노드에 연결합니다. 자세한 내용은 *Amazon Elastic Compute Cloud*의 [Linux 인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)을 참조하세요.
------
#### [ Accessing logs by connecting to a node ]
1. 노드 프로비저닝 로그 파일이 있는 다음 디렉터리로 이동합니다.
```
/mnt/var/log/provision-node/
```
1. 보고서 하위 디렉터리를 열고 재구성을 위한 노드 프로비저닝 보고서를 검색합니다. 보고서 디렉터리는 재구성 버전 번호, 범용 고유 식별자(UUID), Amazon EC2 인스턴스 IP 주소 및 타임스탬프별로 로그를 구성합니다. 각 보고서는 재구성 프로세스에 대한 자세한 정보를 포함하는 압축된 YAML 파일입니다. 다음은 보고서 파일 이름 및 경로에 대한 예제입니다.
```
/reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz
```
1. 다음 예제와 같이 zless 등의 파일 뷰어를 사용하여 보고서를 검토할 수 있습니다.
```
zless 202104061715.yaml.gz
```
------
#### [ Accessing logs using Amazon S3 ]
에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) Amazon S3 콘솔을 엽니다. 로그 파일을 아카이브하도록 클러스터를 구성할 때 지정한 Amazon S3 버킷을 엽니다.
1. 노드 프로비저닝 로그 파일이 있는 다음 폴더로 이동합니다.
```
amzn-s3-demo-bucket/elasticmapreduce/cluster id/node/instance id/provision-node/
```
1. 보고서 폴더를 열고 재구성을 위한 노드 프로비저닝 보고서를 검색합니다. 보고서 폴더는 재구성 버전 번호, 범용 고유 식별자(UUID), Amazon EC2 인스턴스 IP 주소 및 타임스탬프별로 로그를 구성합니다. 각 보고서는 재구성 프로세스에 대한 자세한 정보를 포함하는 압축된 YAML 파일입니다. 다음은 보고서 파일 이름 및 경로에 대한 예제입니다.
```
/reports/2/ca598xxx-cxxx-4xxx-bxxx-6dbxxxxxxxxx/ip-10-73-xxx-xxx.ec2.internal/202104061715.yaml.gz
```
로그 파일을 보려면 Amazon S3의에서 로컬 컴퓨터로 로그 파일을 텍스트 파일로 다운로드하면 됩니다. 관련 지침은 [객체 다운로드](https://docs.aws.amazon.com/AmazonS3/latest/userguide/download-objects.html)를 참조하세요.
------
각 로그 파일에는 관련 재구성에 대한 자세한 프로비저닝 보고서가 들어 있습니다. 오류 메시지 정보를 찾으려면 보고서의 `err` 로그 수준을 검색하면 됩니다. 보고서 형식은 클러스터의 Amazon EMR 버전에 따라 다릅니다. 다음 예제에서는 Amazon EMR 릴리스 버전 5.32.0 및 6.2.0 이후에 대한 오류 정보를 다음과 같은 형식으로 보여줍니다.
```
- level: err
message: 'Example detailed error message.'
source: Puppet
tags:
- err
time: '2021-01-01 00:00:00.000000 +00:00'
file:
line:
```
# Amazon EMR의 인스턴스 플릿에서 용량 예약 사용
용량 예약 옵션을 포함하는 온디맨드 인스턴스 플릿을 시작하려면 용량 예약 옵션을 사용하는 데 필요한 추가 서비스 역할 권한을 연결합니다. 용량 예약 옵션은 온디맨드 할당 전략과 함께 사용해야 하므로 할당 전략에 필요한 권한도 서비스 역할 및 관리형 정책에 포함해야 합니다. 자세한 내용은 [할당 전략 권한할당 전략에 필요한 IAM 권한](emr-instance-fleet.md#create-cluster-allocation-policy) 단원을 참조하십시오.
Amazon EMR은 열린 용량 예약과 목표 용량 예약을 모두 지원합니다. 다음 주제에서는 `RunJobFlow` 작업 또는 `create-cluster` 명령과 함께 온디맨드 용량 예약을 사용하여 인스턴스 플릿을 시작할 수 있는 인스턴스 플릿 구성을 보여줍니다.
## 최대한 열린 용량 예약 사용
클러스터의 온디맨드 인스턴스가 계정에서 사용할 수 있는 열린 용량 예약 속성(인스턴스 유형, 플랫폼, 테넌시 및 가용 영역)과 일치하면 용량 예약이 자동으로 적용됩니다. 하지만 용량 예약 사용은 보장되지 않습니다. 클러스터를 프로비저닝하기 위해 Amazon EMR은 시작 요청에 지정된 모든 인스턴스 풀을 평가하여 요청된 모든 코어 노드를 시작하기에 충분한 용량을 갖춘 최저 가격의 풀을 사용합니다. 인스턴스 풀과 일치하는 사용 가능한 열린 용량 예약이 자동으로 적용됩니다. 사용 가능한 열린 용량 예약이 인스턴스 풀과 일치하지 않는 경우 미사용 상태로 남습니다.
코어 노드가 프로비저닝되면 가용 영역이 선택되고 수정됩니다. Amazon EMR은 선택한 가용 영역에서 가장 저렴한 항목부터 시작해 모든 태스크 노드가 프로비저닝될 때까지 인스턴스 풀에 태스크 노드를 프로비저닝합니다. 인스턴스 풀과 일치하는 사용 가능한 열린 용량 예약이 자동으로 적용됩니다.
다음은 최대한 열린 용량 예약을 사용하기 위한 Amazon EMR 용량 할당 로직의 사용 사례입니다.
**예제 1: 시작 요청의 최저 가격 인스턴스 풀에 사용 가능한 열린 용량 예약이 있는 경우**
이 경우 Amazon EMR은 온디맨드 인스턴스를 사용하여 최저 가격의 인스턴스 풀에서 용량을 시작합니다. 해당 인스턴스 풀에서 사용 가능한 열린 용량 예약이 자동으로 사용됩니다.
| | |
| --- |--- |
| On-Demand Strategy | lowest-price |
| Requested Capacity | 100 |
| Instance Type | c5.xlarge | m5.xlarge | r5.xlarge |
| Available Open capacity reservations | 150 | 100 | 100 |
| On-Demand Price | \$1 | \$1\$1 | \$1\$1\$1 |
| 프로비저닝된 인스턴스 | 100 | - | - |
| --- |--- |--- |--- |
| 사용된 열린 용량 예약 | 100 | - | - |
| --- |--- |--- |--- |
| 사용 가능한 열린 용량 예약 | 50 | 100 | 100 |
| --- |--- |--- |--- |
인스턴스 플릿이 시작된 후, [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-capacity-reservations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-capacity-reservations.html)를 실행하여 미사용 용량 예약이 얼마나 남았는지 확인할 수 있습니다.
**예제 2: 시작 요청의 최저 가격 인스턴스 풀에 사용 가능한 열린 용량 예약이 없는 경우**
이 경우 Amazon EMR은 온디맨드 인스턴스를 사용하여 최저 가격의 인스턴스 풀에서 용량을 시작합니다. 하지만 열린 용량 예약은 미사용 상태로 남아 있습니다.
| | |
| --- |--- |
| On-Demand Strategy | lowest-price |
| Requested Capacity | 100 |
| Instance Type | c5.xlarge | m5.xlarge | r5.xlarge |
| 사용 가능한 열린 용량 예약 | - | - | 100 |
| On-Demand Price | \$1 | \$1\$1 | \$1\$1\$1 |
| 프로비저닝된 인스턴스 | 100 | - | - |
| --- |--- |--- |--- |
| 사용된 열린 용량 예약 | - | - | - |
| --- |--- |--- |--- |
| 사용 가능한 열린 용량 예약 | - | - | 100 |
| --- |--- |--- |--- |
**최대한 열린 용량 예약을 사용하도록 인스턴스 플릿 구성**
`RunJobFlow` 작업을 사용하여 인스턴스 플릿 기반 클러스터를 생성하는 경우 온디맨드 할당 전략을 `lowest-price`로 설정하고 용량 예약 옵션에서 `CapacityReservationPreference`를 `open`으로 설정합니다. 또는 이 필드를 비워 두면 Amazon EMR이 온디맨드 인스턴스의 용량 예약 기본 설정을 `open`으로 기본 설정합니다.
```
"LaunchSpecifications":
{"OnDemandSpecification": {
"AllocationStrategy": "lowest-price",
"CapacityReservationOptions":
{
"CapacityReservationPreference": "open"
}
}
}
```
Amazon EMR CLI를 사용하여 열린 용량 예약을 사용하여 인스턴스 플릿 기반 클러스터를 생성할 수도 있습니다.
```
aws emr create-cluster \
--name 'open-ODCR-cluster' \
--release-label emr-5.30.0 \
--service-role EMR_DefaultRole \
--ec2-attributes SubnetId=subnet-22XXXX01,InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=c4.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=100,InstanceTypeConfigs=['{InstanceType=c5.xlarge},{InstanceType=m5.xlarge},{InstanceType=r5.xlarge}'],\
LaunchSpecifications={OnDemandSpecification='{AllocationStrategy=lowest-price,CapacityReservationOptions={CapacityReservationPreference=open}}'}
```
여기서
+ `open-ODCR-cluster`는 열린 용량 예약을 사용하는 클러스터 이름으로 바뀝니다.
+ `subnet-22XXXX01`은 서브넷 ID로 바뀝니다.
## 먼저 열린 용량 예약을 사용합니다.
최저 가격 할당 전략을 재정의하고 Amazon EMR 클러스터를 프로비저닝하는 동안 먼저 사용 가능한 열린 용량 예약을 사용하도록 우선순위를 정할 수 있습니다. 이 경우 Amazon EMR은 시작 요청에 지정된 용량 예약을 포함하는 모든 인스턴스 풀을 재평가하여 요청된 모든 코어 노드를 시작하기에 충분한 용량을 갖춘 최저 가격의 풀을 사용합니다. 용량 예약을 사용하는 인스턴스 풀 중 요청된 코어 노드에 충분한 용량을 갖춘 인스턴스 풀이 하나도 없는 경우 Amazon EMR은 이전 주제에서 설명한 최대한의 원칙으로 돌아갑니다. 즉, Amazon EMR은 시작 요청에 지정된 모든 인스턴스 풀을 재평가하여 요청된 모든 코어 노드를 시작하기에 충분한 용량을 갖춘 최저 가격의 풀을 사용합니다. 인스턴스 풀과 일치하는 사용 가능한 열린 용량 예약이 자동으로 적용됩니다. 사용 가능한 열린 용량 예약이 인스턴스 풀과 일치하지 않는 경우 미사용 상태로 남습니다.
코어 노드가 프로비저닝되면 가용 영역이 선택되고 수정됩니다. Amazon EMR은 선택한 가용 영역에서 가장 저렴한 항목부터 시작해 모든 태스크 노드가 프로비저닝될 때까지 용량 예약이 있는 인스턴스 풀에 태스크 노드를 프로비저닝합니다. Amazon EMR은 선택한 가용 영역의 각 인스턴스 풀에서 사용 가능한 오픈 용량 예약을 먼저 사용하고, 필요한 경우에만 최저 가격 전략을 사용하여 나머지 태스크 노드를 프로비저닝합니다.
다음은 열린 용량 예약을 먼저 사용하기 위한 Amazon EMR 용량 할당 로직의 사용 사례입니다.
**예제 1: **시작 요청에서 사용 가능한 열린 용량 예약이 있는 인스턴스 풀에 코어 노드를 위한 충분한 용량이 있는 경우****
이 경우 Amazon EMR은 인스턴스 풀 가격에 관계없이 사용 가능한 열린 용량 예약을 통해 인스턴스 풀의 용량을 시작합니다. 따라서 모든 코어 노드가 프로비저닝될 때까지 최대한 열린 용량 예약이 사용됩니다.
| | |
| --- |--- |
| On-Demand Strategy | lowest-price |
| Requested Capacity | 100 |
| Usage Strategy | use-capacity-reservations-first |
| Instance Type | c5.xlarge | m5.xlarge | r5.xlarge |
| Available Open capacity reservations | - | - | 150 |
| On-Demand Price | \$1 | \$1\$1 | \$1\$1\$1 |
| 프로비저닝된 인스턴스 | - | - | 100 |
| --- |--- |--- |--- |
| 사용된 열린 용량 예약 | - | - | 100 |
| --- |--- |--- |--- |
| 사용 가능한 열린 용량 예약 | - | - | 50 |
| --- |--- |--- |--- |
**예제 2: **시작 요청에서 사용 가능한 열린 용량 예약이 있는 인스턴스 풀에 코어 노드를 위한 충분한 용량이 없는 경우****
이 경우 Amazon EMR은 용량 예약을 최대한 활용하면서 최저 가격 전략을 사용하여 코어 노드를 시작하는 방법으로 돌아갑니다.
| | |
| --- |--- |
| On-Demand Strategy | lowest-price |
| Requested Capacity | 100 |
| Usage Strategy | use-capacity-reservations-first |
| Instance Type | c5.xlarge | m5.xlarge | r5.xlarge |
| Available Open capacity reservations | 10 | 50 | 50 |
| On-Demand Price | \$1 | \$1\$1 | \$1\$1\$1 |
| 프로비저닝된 인스턴스 | 100 | - | - |
| --- |--- |--- |--- |
| 사용된 열린 용량 예약 | 10 | - | - |
| --- |--- |--- |--- |
| 사용 가능한 열린 용량 예약 | - | 50 | 50 |
| --- |--- |--- |--- |
인스턴스 플릿이 시작된 후, [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-capacity-reservations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-capacity-reservations.html)를 실행하여 미사용 용량 예약이 얼마나 남았는지 확인할 수 있습니다.
**먼저 열린 용량 예약을 사용하도록 인스턴스 플릿 구성**
`RunJobFlow` 작업을 사용하여 인스턴스 플릿 기반 클러스터를 생성하는 경우 온디맨드 할당 전략을 `lowest-price`로 설정하고 `CapacityReservationOptions`에서 `UsageStrategy`를 `use-capacity-reservations-first`로 설정합니다.
```
"LaunchSpecifications":
{"OnDemandSpecification": {
"AllocationStrategy": "lowest-price",
"CapacityReservationOptions":
{
"UsageStrategy": "use-capacity-reservations-first"
}
}
}
```
Amazon EMR CLI를 통해 먼저 용량 예약을 사용하여 인스턴스 플릿 기반 클러스터를 생성할 수도 있습니다.
```
aws emr create-cluster \
--name 'use-CR-first-cluster' \
--release-label emr-5.30.0 \
--service-role EMR_DefaultRole \
--ec2-attributes SubnetId=subnet-22XXXX01,InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=c4.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=100,InstanceTypeConfigs=['{InstanceType=c5.xlarge},{InstanceType=m5.xlarge},{InstanceType=r5.xlarge}'],\
LaunchSpecifications={OnDemandSpecification='{AllocationStrategy=lowest-price,CapacityReservationOptions={UsageStrategy=use-capacity-reservations-first}}'}
```
여기서
+ `use-CR-first-cluster`는 열린 용량 예약을 사용하는 클러스터 이름으로 바뀝니다.
+ `subnet-22XXXX01`은 서브넷 ID로 바뀝니다.
## 먼저 목표 용량 예약 사용
Amazon EMR 클러스터를 프로비저닝하는 경우 최저 가격 할당 전략을 재정의하고 먼저 사용 가능한 목표 용량 예약을 사용하도록 우선순위를 정할 수 있습니다. 이 경우 Amazon EMR은 시작 요청에 지정된 목표 용량 예약을 포함하는 모든 인스턴스 풀을 재평가하여 요청된 모든 코어 노드를 시작하기에 충분한 용량을 갖춘 최저 가격의 풀을 선택합니다. 목표 용량 예약을 사용하는 인스턴스 풀 중 코어 노드에 충분한 용량을 갖춘 인스턴스 풀이 하나도 없는 경우 Amazon EMR은 앞서 설명한 최대한의 원칙으로 돌아갑니다. 즉, Amazon EMR은 시작 요청에 지정된 모든 인스턴스 풀을 재평가하여 요청된 모든 코어 노드를 시작하기에 충분한 용량을 갖춘 최저 가격의 풀을 선택합니다. 인스턴스 풀과 일치하는 사용 가능한 열린 용량 예약이 자동으로 적용됩니다. 하지만 목표 용량 예약은 미사용 상태로 남아 있습니다.
코어 노드가 프로비저닝되면 가용 영역이 선택되고 수정됩니다. Amazon EMR은 선택한 가용 영역에서 가장 저렴한 항목부터 시작해 모든 태스크 노드가 프로비저닝될 때까지 목표가 정해진 용량 예약이 있는 인스턴스 풀에 태스크 노드를 프로비저닝합니다. Amazon EMR은 선택한 가용 영역의 각 인스턴스 풀에서 사용 가능한 목표가 정해진 용량 예약을 먼저 사용하려고 합니다. 그러면 Amazon EMR은 필요한 경우에만 최저 가격 전략을 사용하여 나머지 태스크 노드를 프로비저닝합니다.
다음은 목표 용량 예약을 먼저 사용하기 위한 Amazon EMR 용량 할당 로직의 사용 사례입니다.
**예제 1: 시작 요청에서 사용 가능한 목표 용량 예약이 있는 인스턴스 풀에 코어 노드를 위한 충분한 용량이 있는 경우**
이 경우 Amazon EMR은 인스턴스 풀 가격에 관계없이 사용 가능한 목표 용량 예약을 통해 인스턴스 풀의 용량을 시작합니다. 따라서 모든 코어 노드가 프로비저닝될 때까지 최대한 목표 용량 예약이 사용됩니다.
| | |
| --- |--- |
| On-Demand Strategy | lowest-price |
| Usage Strategy | use-capacity-reservations-first |
| Requested Capacity | 100 |
| Instance Type | c5.xlarge | m5.xlarge | r5.xlarge |
| Available targeted capacity reservations | - | - | 150 |
| On-Demand Price | \$1 | \$1\$1 | \$1\$1\$1 |
| 프로비저닝된 인스턴스 | - | - | 100 |
| --- |--- |--- |--- |
| 사용된 목표 용량 예약 | - | - | 100 |
| --- |--- |--- |--- |
| 사용 가능한 목표 용량 예약 | - | - | 50 |
| --- |--- |--- |--- |
**Example 예제 2: 시작 요청에서 사용 가능한 목표 용량 예약이 있는 인스턴스 풀에 코어 노드를 위한 충분한 용량이 없는 경우**
| | |
| --- |--- |
| On-Demand Strategy | lowest-price |
| Requested Capacity | 100 |
| Usage Strategy | use-capacity-reservations-first |
| Instance Type | c5.xlarge | m5.xlarge | r5.xlarge |
| Available targeted capacity reservations | 10 | 50 | 50 |
| On-Demand Price | \$1 | \$1\$1 | \$1\$1\$1 |
| 프로비저닝된 인스턴스 | 100 | - | - |
| --- |--- |--- |--- |
| 사용된 목표 용량 예약 | 10 | - | - |
| --- |--- |--- |--- |
| 사용 가능한 목표 용량 예약 | - | 50 | 50 |
| --- |--- |--- |--- |
인스턴스 플릿이 시작된 후, [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-capacity-reservations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-capacity-reservations.html)를 실행하여 미사용 용량 예약이 얼마나 남았는지 확인할 수 있습니다.
**먼저 목표 용량 예약을 사용하도록 인스턴스 플릿 구성**
`RunJobFlow` 작업을 사용하여 인스턴스 플릿 기반 클러스터를 생성하는 경우 온디맨드 할당 전략을 `lowest-price`로 설정하고 `CapacityReservationOptions`에서 `UsageStrategy`를 `use-capacity-reservations-first`로, `CapacityReservationOptions`에서 `CapacityReservationResourceGroupArn`을 ``으로 설정합니다. 자세한 내용을 알아보려면 **Amazon EC2 사용 설명서의 [용량 예약 작업](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservations-using.html)을 참조하세요.
```
"LaunchSpecifications":
{"OnDemandSpecification": {
"AllocationStrategy": "lowest-price",
"CapacityReservationOptions":
{
"UsageStrategy": "use-capacity-reservations-first",
"CapacityReservationResourceGroupArn": "arn:aws:resource-groups:sa-east-1:123456789012:group/MyCRGroup"
}
}
}
```
여기에서 `arn:aws:resource-groups:sa-east-1:123456789012:group/MyCRGroup`은 리소스 그룹 ARN으로 바뀝니다.
Amazon EMR CLI를 사용하여 목표 용량 예약을 사용하여 인스턴스 플릿 기반 클러스터를 생성할 수도 있습니다.
```
aws emr create-cluster \
--name 'targeted-CR-cluster' \
--release-label emr-5.30.0 \
--service-role EMR_DefaultRole \
--ec2-attributes SubnetId=subnet-22XXXX01,InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=c4.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=100,\
InstanceTypeConfigs=['{InstanceType=c5.xlarge},{InstanceType=m5.xlarge},{InstanceType=r5.xlarge}'],\
LaunchSpecifications={OnDemandSpecification='{AllocationStrategy=lowest-price,CapacityReservationOptions={UsageStrategy=use-capacity-reservations-first,CapacityReservationResourceGroupArn=arn:aws:resource-groups:sa-east-1:123456789012:group/MyCRGroup}}'}
```
여기서
+ `targeted-CR-cluster`는 목표 용량 예약을 사용하는 클러스터의 이름으로 바꿉니다.
+ `subnet-22XXXX01`은 서브넷 ID로 바뀝니다.
+ `arn:aws:resource-groups:sa-east-1:123456789012:group/MyCRGroup`은 리소스 그룹 ARN으로 바뀝니다.
## 사용 가능한 열린 용량 예약의 사용 방지
**Example**
Amazon EMR 클러스터를 시작할 때 열린 용량 예약이 예기치 않게 사용되는 것을 방지하려면 온디맨드 할당 전략을 `lowest-price`로, `CapacityReservationOptions`의 `CapacityReservationPreference`는 `none`으로 설정합니다. 그렇지 않으면 Amazon EMR은 온디맨드 인스턴스의 용량 예약 기본 설정을 `open`으로 기본 설정하고, 최대한 사용 가능한 오픈 용량 예약을 사용하려고 합니다.
```
"LaunchSpecifications":
{"OnDemandSpecification": {
"AllocationStrategy": "lowest-price",
"CapacityReservationOptions":
{
"CapacityReservationPreference": "none"
}
}
}
```
Amazon EMR CLI를 사용하여 열린 용량 예약을 사용하지 않고 인스턴스 플릿 기반 클러스터를 생성할 수도 있습니다.
```
aws emr create-cluster \
--name 'none-CR-cluster' \
--release-label emr-5.30.0 \
--service-role EMR_DefaultRole \
--ec2-attributes SubnetId=subnet-22XXXX01,InstanceProfile=EMR_EC2_DefaultRole \
--instance-fleets \
InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=['{InstanceType=c4.xlarge}'] \
InstanceFleetType=CORE,TargetOnDemandCapacity=100,InstanceTypeConfigs=['{InstanceType=c5.xlarge},{InstanceType=m5.xlarge},{InstanceType=r5.xlarge}'],\
LaunchSpecifications={OnDemandSpecification='{AllocationStrategy=lowest-price,CapacityReservationOptions={CapacityReservationPreference=none}}'}
```
여기서
+ `none-CR-cluster`는 열린 용량 예약을 사용하지 않는 클러스터 이름으로 바뀝니다.
+ `subnet-22XXXX01`은 서브넷 ID로 바뀝니다.
## 용량 예약 사용 시나리오
다음 시나리오에서 용량 예약을 사용하면 이점을 얻을 수 있습니다.
**시나리오 1: 용량 예약을 사용하여 장기 실행 클러스터 로테이션**
장기 실행 클러스터를 로테이션할 때 프로비저닝하는 새 인스턴스의 인스턴스 유형 및 가용 영역에 대한 엄격한 요구 사항이 있을 수 있습니다. 용량 예약을 사용하면 용량 보장을 통해 중단 없이 클러스터 로테이션을 완료할 수 있습니다.
![\[사용 가능한 용량 예약을 사용한 클러스터 로테이션\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/odcr-longrunning-cluster-diagram.png)
**시나리오 2: 용량 예약을 사용하여 연속된 단기 클러스터 프로비저닝**
용량 예약을 사용하여 개별 워크로드에 대해 연속 단기 클러스터 그룹을 프로비저닝함으로써 클러스터를 종료할 때 다음 클러스터가 용량 예약을 사용할 수 있습니다. 목표 용량 예약을 사용하여 의도한 클러스터만 용량 예약을 사용하도록 할 수 있습니다.
![\[사용 가능한 용량 예약을 사용하는 단기 클러스터 프로비저닝\]](http://docs.aws.amazon.com/ko_kr/emr/latest/ManagementGuide/images/odcr-short-cluster-diagram.png)
# Amazon EMR 클러스터에 대한 균일한 인스턴스 그룹 구성
인스턴스 그룹 구성을 사용하는 경우 각 노드 유형(마스터, 코어 또는 작업)은 인스턴스에 대해 동일한 인스턴스 유형 및 구매 옵션으로 구성됩니다(온디맨드 또는 스팟). 인스턴스 그룹 생성 시 이러한 설정을 지정합니다. 나중에 변경할 수 없습니다. 하지만 동일한 유형 및 구매 옵션의 인스턴스를 코어 및 작업 인스턴스 그룹에 추가할 수 있습니다. 또한 인스턴스를 제거할 수도 있습니다.
클러스터의 온디맨드 인스턴스가 계정에서 사용할 수 있는 열린 용량 예약 속성(인스턴스 유형, 플랫폼, 테넌시 및 가용 영역)과 일치하면 용량 예약이 자동으로 적용됩니다. 프라이머리, 코어 및 태스크 노드에 대해 열린 용량 예약을 사용할 수 있습니다. 하지만 인스턴스 그룹을 사용하여 클러스터를 프로비저닝할 때 목표 용량 예약을 사용할 수 없으며, 속성이 일치하는 열린 용량 예약으로 시작하지 않도록 인스턴스를 막을 수도 없습니다. 목표 용량 예약을 사용하거나 인스턴스가 열린 용량 예약으로 시작되지 않도록 하려면 대신 인스턴스 플릿을 사용합니다. 자세한 내용은 [Amazon EMR의 인스턴스 플릿에서 용량 예약 사용](on-demand-capacity-reservations.md) 단원을 참조하십시오.
클러스터를 생성한 후 다른 인스턴스 유형을 추가하려면 추가 작업 인스턴스 그룹을 추가하면 됩니다. 각 인스턴스 그룹에 대하여 다른 인스턴스 유형과 구매 옵션을 선택할 수 있습니다. 자세한 내용은 [Amazon EMR 클러스터 조정을 사용하여 워크로드 변경에 맞게 조정](emr-scale-on-demand.md) 단원을 참조하십시오.
인스턴스를 시작할 때 온디맨드 인스턴스의 용량 예약 기본 설정은 기본적으로 `open`으로 설정되며, 이를 통해 속성(인스턴스 유형, 플랫폼, 가용 영역)이 일치하는 모든 열린 용량 예약에서 실행됩니다. 온디맨드 용량 예약에 대한 자세한 내용은 [Amazon EMR의 인스턴스 플릿에서 용량 예약 사용](on-demand-capacity-reservations.md) 섹션을 참조하세요.
이 섹션에서는 균일한 인스턴스 그룹으로 클러스터를 만드는 방법에 대해 설명합니다. 인스턴스 수동 추가/제거 또는 자동 조정을 통한 기존 인스턴스 그룹 수정에 대한 자세한 내용은 [Amazon EMR 클러스터 관리](emr-manage.md) 섹션을 참조하세요.
## 콘솔을 사용하여 균일한 인스턴스 그룹 구성
------
#### [ Console ]
**새 콘솔을 사용하여 인스턴스 그룹을 포함하는 클러스터를 생성하는 방법**
1. 에 로그인 AWS Management Console하고 [https://console.aws.amazon.com/emr](https://console.aws.amazon.com/emr) Amazon EMR 콘솔을 엽니다.
1. 왼쪽 탐색 창의 **EMR on EC2**에서 **클러스터**를 선택하고 **클러스터 생성**을 선택합니다.
1. **클러스터 구성**에서 **인스턴스 그룹**을 선택합니다.
1. **노드 그룹** 아래에는 각 노드 그룹 유형에 대한 섹션이 있습니다. 프라이머리 노드 그룹의 경우 프라이머리 노드 3개를 사용하려는 경우 **여러 프라이머리 노드 사용** 확인란을 선택합니다. 스팟 구매를 사용하려면 **스팟 구매 옵션 사용** 확인란을 선택합니다.
1. 프라이머리 및 코어 노드 그룹의 경우 **인스턴스 유형 추가**를 선택하고 최대 5개의 인스턴스 유형을 선택합니다. 태스크 그룹의 경우 **인스턴스 유형 추가**를 선택하고 최대 15개의 인스턴스 유형을 선택합니다. Amazon EMR은 클러스터를 시작할 때 이러한 인스턴스 유형을 원하는 대로 조합하여 프로비저닝할 수 있습니다.
1. 각 노드 그룹 유형에서 각 인스턴스 옆에 있는 **작업** 드롭다운 메뉴를 선택하여 다음 설정을 변경합니다.
**EBS 볼륨 추가**
Amazon EMR에서 프로비저닝한 후 인스턴스 유형에 연결할 EBS 볼륨을 지정합니다.
**최고 스팟 가격 편집**
플릿에서 인스턴스 유형에 대해 최고 스팟 가격을 지정합니다. 이 가격을 온디맨드 가격의 백분율로 설정하거나 구체적 금액(USD)으로 설정할 수 있습니다. 가용 영역의 현재 스팟 가격이 최고 스팟 가격 미만인 경우 Amazon EMR은 스팟 인스턴스를 프로비저닝합니다. 사용자는 스팟 가격을 지불합니다. 꼭 최고 스팟 가격인 것은 아닙니다.
1. 선택적으로 **노드 구성**을 확장하여 JSON 구성을 입력하거나 Amazon S3에서 JSON을 로드합니다.
1. 클러스터에 적용할 다른 옵션을 선택합니다.
1. 클러스터를 시작하려면 **클러스터 생성**을 선택합니다.
------
## AWS CLI 를 사용하여 균일한 인스턴스 그룹으로 클러스터 생성
AWS CLI를 사용하여 클러스터의 인스턴스 그룹 구성을 지정하려면 `--instance-groups` 파라미터와 함께 `create-cluster` 명령을 사용합니다. 인스턴스 그룹에 `BidPrice` 인수를 지정하지 않은 경우 Amazon EMR은 온디맨드 인스턴스 옵션을 가정합니다. 온디맨드 인스턴스 및 다양한 클러스터 옵션을 사용하여 균일한 인스턴스 그룹을 시작하는 `create-cluster` 명령의 예제를 보려면 명령줄에 `aws emr create-cluster help `를 입력하거나 *AWS CLI 명령 참조*에서 [create-cluster](https://docs.aws.amazon.com/cli/latest/reference/emr/create-cluster.html)를 참조하세요.
를 사용하여 스팟 인스턴스 AWS CLI 를 사용하는 클러스터에서 균일한 인스턴스 그룹을 생성할 수 있습니다. 제공된 스팟 가격은 가용 영역에 따라 달라집니다. CLI 또는 API를 사용하는 경우 `--ec2-attributes ` 파라미터의 `SubnetID ` 인수 또는 `AvailabilityZone` 인수(EC2-classic 네트워크를 사용하는 경우)를 사용하여 가용 영역을 지정할 수 있습니다. 선택한 가용 영역이나 서브넷이 클러스터에 적용되므로 모든 인스턴스 그룹에 사용됩니다. 가용 영역이나 서브넷을 명시적으로 지정하지 않는 경우 Amazon EMR이 클러스터를 시작할 때 최저 스팟 가격으로 가용 영역을 선택합니다.
다음 예제에서는 모두 스팟 인스턴스를 사용하는 프라이머리, 코어 및 두 태스크 인스턴스 그룹을 생성하는 `create-cluster` 명령을 보여줍니다. *myKey*를 Amazon EC2 키 페어 이름으로 바꿉니다.
**참고**
가독성을 위해 Linux 줄 연속 문자(\$1)가 포함됩니다. Linux 명령에 사용하거나 제외할 수 있습니다. Windows에서는 제외시키거나 캐럿(^)으로 바꿉니다.
```
aws emr create-cluster --name "MySpotCluster" \
--release-label emr-7.12.0 \
--use-default-roles \
--ec2-attributes KeyName=myKey \
--instance-groups \
InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1,BidPrice=0.25 \
InstanceGroupType=CORE,InstanceType=m5.xlarge,InstanceCount=2,BidPrice=0.03 \
InstanceGroupType=TASK,InstanceType=m5.xlarge,InstanceCount=4,BidPrice=0.03 \
InstanceGroupType=TASK,InstanceType=m5.xlarge,InstanceCount=2,BidPrice=0.04
```
CLI를 사용하여 인스턴스 그룹의 각 인스턴스 유형에 대해 고유한 사용자 지정 AMI를 지정하는 균일한 인스턴스 그룹 클러스터를 생성할 수 있습니다. 이렇게 하면 동일한 인스턴스 그룹에서 서로 다른 인스턴스 아키텍처를 사용할 수 있습니다. 각 인스턴스 유형은 아키텍처가 일치하는 사용자 지정 AMI를 사용해야 합니다. 예를 들어, x86\$164 아키텍처 사용자 지정 AMI를 사용하여 m5.xlarge 인스턴스 유형을 구성하고, 대응하는 `AWS AARCH64`(ARM) 아키텍처 사용자 지정 AMI를 사용하여 m6g.xlarge 인스턴스 유형을 구성할 수 있습니다.
다음 예제에서는 각각 고유한 사용자 지정 AMI를 사용하여 두 개의 인스턴스 유형으로 생성된 균일한 인스턴스 그룹 클러스터를 보여줍니다. 사용자 지정 AMI는 클러스터 수준이 아닌 인스턴스 유형 수준에서만 지정됩니다. 인스턴스 유형 AMI와 클러스터 수준의 AMI 간 충돌(이 충돌로 인해 클러스터가 시작되지 않음)을 방지하기 위해서입니다.
```
aws emr create-cluster
--release-label emr-5.30.0 \
--service-role EMR_DefaultRole \
--ec2-attributes SubnetId=subnet-22XXXX01,InstanceProfile=EMR_EC2_DefaultRole \
--instance-groups \
InstanceGroupType=MASTER,InstanceType=m5.xlarge,InstanceCount=1,CustomAmiId=ami-123456 \
InstanceGroupType=CORE,InstanceType=m6g.xlarge,InstanceCount=1,CustomAmiId=ami-234567
```
실행 중인 클러스터에 추가하는 인스턴스 그룹에 다중 사용자 지정 AMI를 추가할 수 있습니다. 다음 예제와 같이 `add-instance-groups` 명령과 함께 `CustomAmiId` 인수를 사용할 수 있습니다.
```
aws emr add-instance-groups --cluster-id j-123456 \
--instance-groups \
InstanceGroupType=Task,InstanceType=m5.xlarge,InstanceCount=1,CustomAmiId=ami-123456
```
## Java SDK를 사용하여 인스턴스 그룹 생성
클러스터에 대해 인스턴스 그룹의 구성을 지정하는 `InstanceGroupConfig` 개체를 인스턴스화할 수 있습니다. 스팟 인스턴스를 사용하려면 `withBidPrice` 개체에 대해 `withMarket` 및 `InstanceGroupConfig` 속성을 설정합니다. 다음 코드는 스팟 인스턴스를 실행하는 프라이머리, 코어 및 태스크 인스턴스 그룹을 정의하는 방법을 보여줍니다.
```
InstanceGroupConfig instanceGroupConfigMaster = new InstanceGroupConfig()
.withInstanceCount(1)
.withInstanceRole("MASTER")
.withInstanceType("m4.large")
.withMarket("SPOT")
.withBidPrice("0.25");
InstanceGroupConfig instanceGroupConfigCore = new InstanceGroupConfig()
.withInstanceCount(4)
.withInstanceRole("CORE")
.withInstanceType("m4.large")
.withMarket("SPOT")
.withBidPrice("0.03");
InstanceGroupConfig instanceGroupConfigTask = new InstanceGroupConfig()
.withInstanceCount(2)
.withInstanceRole("TASK")
.withInstanceType("m4.large")
.withMarket("SPOT")
.withBidPrice("0.10");
```
# Amazon EMR 클러스터에 대한 가용 영역 유연성
각 AWS 리전 에는 가용 영역이라고 하는 격리된 위치가 여러 개 있습니다. 인스턴스를 시작할 때 선택적으로 사용하는 AWS 리전 에서 가용 영역(AZ)을 지정할 수 있습니다. [가용 영역 유연성](#emr-flexibility-az)이란 여러 AZ에 인스턴스를 배포하는 것을 말합니다. 하나의 인스턴스에 장애가 발생하면 다른 AZ에 있는 인스턴스에서 요청을 처리할 수 있도록 애플리케이션을 설계할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*에서 [리전 및 영역](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 설명서를 참조하세요.
[인스턴스 유연성](#emr-flexibility-types)이란 용량 요구 사항을 충족하기 위해 여러 인스턴스 유형을 사용하는 것을 말합니다. 인스턴스에 유연성을 적용하면 인스턴스 크기, 패밀리, 세대 전반에 걸쳐 총 용량을 사용할 수 있습니다. 유연성이 높으면 단일 인스턴스 유형을 사용하는 클러스터와 비교했을 때 필요한 컴퓨팅 크기를 찾아 할당할 가능성이 커집니다.
인스턴스 및 가용 영역의 유연성은 단일 인스턴스 유형 또는 AZ를 사용하는 클러스터와 비교했을 때 [용량 부족 오류(ICE)](emr-events-response-insuff-capacity.md) 및 스팟 중단을 줄여줍니다. 여기에 설명된 모범 사례를 사용하여 초기 인스턴스 패밀리와 크기를 파악한 후 다양화할 인스턴스를 결정합니다. 이 접근 방식은 성능과 비용 편차를 최소화하면서 Amazon EC2 용량 풀의 가용성을 극대화합니다.
## 가용 영역에 대한 유연성 지원
모든 가용 영역을 Virtual Private Cloud(VPC)에서 사용할 수 있도록 구성하고 EMR 클러스터용으로 선택하는 것이 좋습니다. 클러스터는 하나의 가용 영역에만 존재해야 하지만 Amazon EMR 인스턴스 플릿을 사용하면 여러 가용 영역에 대해 여러 서브넷을 선택할 수 있습니다. Amazon EMR이 클러스터를 시작할 때 서브넷을 둘러보며 사용자가 지정한 인스턴스 및 구매 옵션을 찾습니다. 여러 서브넷에서 EMR 클러스터를 프로비저닝하면 클러스터는 단일 서브넷의 클러스터에 비해 더 깊은 Amazon EC2 용량 풀에 액세스할 수 있습니다.
EMR 클러스터의 Virtual Private Cloud(VPC)에서 사용할 특정 수의 가용 영역에 우선순위를 지정해야 하는 경우 Amazon EC2에서 스팟 배치 점수 기능을 활용할 수 있습니다. 스팟 배치 점수를 사용하면 스팟 인스턴스의 컴퓨팅 요구 사항을 지정하면 EC2는 1\$110의 척도로 점수가 매겨진 상위 10개 AWS 리전 또는 가용 영역을 반환합니다. 10점은 스팟 요청이 성공할 가능성이 높음을 나타내고 1은 스팟 요청이 성공할 가능성이 낮음을 나타냅니다. 스팟 배치 점수 사용 방법에 대한 자세한 내용은 **Amazon EC2 사용 설명서에서 [스팟 배치 점수](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-placement-score.html)를 참조하세요.
## 인스턴스 유형에 대한 유연성 지원
인스턴스 유연성이란 용량 요구 사항을 충족하기 위해 여러 인스턴스 유형을 사용하는 것을 말합니다. 인스턴스 유연성은 Amazon EC2 스팟 및 온디맨드 인스턴스 사용에 모두 도움이 됩니다. 스팟 인스턴스의 경우 Amazon EC2는 인스턴스 유연성을 통해 실시간 용량 데이터를 사용하여 더 깊은 용량 풀에서 인스턴스를 시작할 수 있습니다. 또한 가장 가용성이 높은 인스턴스를 예측합니다. 이렇게 하면 중단이 줄어들고 전체 워크로드 비용을 줄일 수 있습니다. 온디맨드 인스턴스를 사용하면 인스턴스 유연성을 통해 더 많은 인스턴스 풀에서 전체 용량을 프로비저닝할 때 용량 부족 오류(ICE)를 줄일 수 있습니다.
**인스턴스 그룹** 클러스터의 경우 최대 50개의 EC2 인스턴스 유형을 지정할 수 있습니다. 할당 전략을 사용하는 **인스턴스 플릿**의 경우 각 프라이머리, 코어 및 태스크 노드 그룹에 대해 최대 30개의 EC2 인스턴스 유형을 지정할 수 있습니다. 인스턴스 범위가 넓어지면 인스턴스 유연성의 이점이 향상됩니다.
### 인스턴스 유연성 표현
애플리케이션의 인스턴스 유연성을 표현하려면 다음 모범 사례를 고려합니다.
**Topics**
+ [
#### 인스턴스 패밀리와 크기 결정
](#emr-flexibility-express-size)
+ [
#### 추가 인스턴스 포함
](#emr-flexibility-express-include)
#### 인스턴스 패밀리와 크기 결정
Amazon EMR은 여러 사용 사례를 위한 여러 인스턴스 유형을 지원합니다. 이러한 인스턴스 유형은 [Amazon EMR에서 지원되는 인스턴스 유형](emr-supported-instance-types.md) 설명서에 나열되어 있습니다. 각 인스턴스 유형은 인스턴스 패밀리에 속합니다. 이 패밀리에서는 어떤 유형이 어떤 애플리케이션에 최적화되는지를 설명합니다.
새 워크로드의 경우 범용 패밀리의 인스턴스 유형(예: `m5` 또는 `c5`)으로 벤치마킹해야 합니다. 그런 다음 Amazon CloudWatch 및 Ganglia에서 OS 및 YARN 지표를 모니터링하고 피크 로드에서 시스템 병목 현상을 파악합니다. 병목 현상에는 CPU, 메모리, 스토리지 및 I/O 작업이 포함됩니다. 병목 현상을 식별한 후에는 컴퓨팅 최적화, 메모리 최적화, 스토리지 최적화 또는 인스턴스 유형에 적합한 다른 인스턴스 패밀리를 선택합니다. 자세한 내용은 GitHub의 Amazon EMR 모범 사례 안내서에서 [Determine right infrastructure for your Spark workloads](https://github.com/aws/aws-emr-best-practices/blob/main/website/docs/bestpractices/Applications/Spark/best_practices.md#bp-512-----determine-right-infrastructure-for-your-spark-workloads) 페이지를 참조하세요.
다음으로, 애플리케이션에 필요한 가장 작은 YARN 컨테이너 또는 Spark 실행기를 식별합니다. 이는 컨테이너에 맞는 가장 작은 인스턴스 크기이자, 클러스터의 최소 인스턴스 크기입니다. 이 지표를 사용하여 더 다양화할 수 있는 인스턴스를 결정합니다. 인스턴스가 작을수록 인스턴스 유연성이 높아집니다.
인스턴스 유연성을 극대화하려면 가능한 한 많은 인스턴스를 활용해야 합니다. 하드웨어 사양이 비슷한 인스턴스로 다각화하는 것이 좋습니다. 이렇게 하면 비용 및 성능 편차를 최소화하면서 EC2 용량 풀에 대한 액세스를 극대화합니다. 규모를 다양화합니다. 그러려면 먼저 AWS Graviton과 이전 세대를 우선합니다. 일반적으로 각 워크로드에 대해 최소 15개의 인스턴스 유형을 유연하게 사용할 수 있도록 합니다. 범용, 컴퓨팅 최적화 또는 메모리 최적화 인스턴스로 시작하는 것이 좋습니다. 이러한 인스턴스 유형은 최고의 유연성을 제공합니다.
#### 추가 인스턴스 포함
다양성을 극대화하려면 추가 인스턴스 유형을 포함합니다. 먼저 인스턴스 크기, Graviton 및 생성 유연성을 우선합니다. 이를 통해 비용 및 성능 프로파일이 비슷한 추가 EC2 용량 풀에 액세스할 수 있습니다. ICE 또는 스팟 중단으로 인해 유연성이 더 필요한 경우 변형 및 패밀리 유연성을 고려합니다. 각 접근 방식에는 사용 사례와 요구 사항에 따라 단점이 있습니다.
+ **크기 유연성** - 먼저 동일한 패밀리 내에서 크기가 다른 인스턴스로 다양한 옵션을 지원합니다. 동일한 패밀리 내 인스턴스는 동일한 비용 및 성능을 제공하지만 각 호스트에서 다른 수의 컨테이너를 시작할 수 있습니다. 예를 들어, 필요한 최소 실행기 크기가 2 vCPU 및 8Gb 메모리인 경우 최소 인스턴스 크기는 `m5.xlarge`입니다. 크기를 유연하게 조정하기 위해 `m5.xlarge`, `m5.2xlarge`, `m5.4xlarge`, `m5.8xlarge`, `m5.12xlarge`, `m5.16xlarge`, `m5.24xlarge`를 포함합니다.
+ **Graviton 유연성** - 크기 외에도 Graviton 인스턴스를 사용하여 다각화할 수 있습니다. Graviton 인스턴스는 Amazon EC AWS 2의 클라우드 워크로드에 최상의 가격 대비 성능을 제공하는Graviton2 프로세서로 구동됩니다. Amazon EC2 예를 들어, 최소 인스턴스 크기가 `m5.xlarge`인 경우 Graviton의 유연성을 위해 `m6g.xlarge`, `m6g.2xlarge`, `m6g.4xlarge`, `m6g.8xlarge`, `m6g.16xlarge`를 포함할 수 있습니다.
+ **세대 유연성** - Graviton 및 크기 유연성과 마찬가지로 이전 세대 패밀리의 인스턴스도 동일한 하드웨어 사양을 공유합니다. 그 결과 액세스 가능한 전체 Amazon EC2 풀이 증가하면서 비용 및 성능 프로파일이 비슷해집니다. 생성 유연성을 위해 `m4.xlarge`, `m4.2xlarge`, `m4.10xlarge`, `m4.16xlarge`를 포함합니다.
+ **패밀리 및 변형 유연성**
+ **용량** - 용량을 최적화하려면 인스턴스 패밀리에서 인스턴스 유연성을 적용하는 것이 좋습니다. 다양한 인스턴스 패밀리의 일반 인스턴스에는 용량 요구 사항을 충족하는 데 도움이 되는 더 깊은 인스턴스 풀이 있습니다. 하지만 다른 패밀리의 인스턴스는 vCPU 대 메모리 비율도 다릅니다. 따라서 예상되는 애플리케이션 컨테이너의 크기가 인스턴스에 맞게 조정되면 사용률이 낮아집니다. 예를 들어, `m5.xlarge`를 사용하는 경우 인스턴스 패밀리 유연성을 위해 컴퓨팅 최적화 인스턴스(예: `c5`)를 포함하거나 메모리 최적화 인스턴스(예: `r5`)를 포함합니다.
+ **비용** - 비용을 최적화하려면 여러 변형에서 인스턴스를 유연하게 사용하는 것이 좋습니다. 이러한 인스턴스는 초기 인스턴스와 메모리 및 vCPU 비율이 동일합니다. 변형 유연성의 단점은 이러한 인스턴스의 용량 풀이 작아 추가 용량이 제한되거나 스팟 중단이 심해질 수 있다는 점입니다. 예를 들어, `m5.xlarge`를 사용하는 경우 인스턴스 변형에 대한 유연성을 지원하기 위해 AMD 기반 인스턴스(`m5a`), SSD 기반 인스턴스(`m5d`) 또는 네트워크 최적화 인스턴스(`m5n`)를 포함합니다.
# 스팟 인스턴스에 대한 Amazon EMR 클러스터 인스턴스 유형 및 모범 사례 구성
이 섹션의 지침은 EMR 클러스터의 각 노드 유형에 대해 프로비저닝하기 위한 인스턴스 유형, 구매 옵션 및 스토리지 양을 결정하는 데 도움이 됩니다.
## 어떤 인스턴스 유형을 사용해야 하나요?
클러스터에 Amazon EC2 인스턴스를 추가하는 여러 가지 방법이 있습니다. 선택해야 하는 방법은 클러스터의 인스턴스 그룹 구성을 사용하는지 아니면 인스턴스 플릿 구성을 사용하는지에 따라 달라집니다.
+ **인스턴스 그룹**
+ 동일한 유형의 인스턴스는 수동으로 코어 및 작업 인스턴스 그룹에 추가합니다.
+ 다른 인스턴스 유형을 사용할 수 있는 작업 인스턴스 그룹을 수동으로 추가합니다.
+ Amazon EMR에서 인스턴스 그룹에 대해 자동 조정을 설정하면, 사용자가 지정하는 Amazon CloudWatch 지표의 값을 기반으로 인스턴스가 자동으로 추가되고 제거됩니다. 자세한 내용은 [Amazon EMR 클러스터 조정을 사용하여 워크로드 변경에 맞게 조정](emr-scale-on-demand.md) 단원을 참조하십시오.
+ **인스턴스 플릿**
+ 단일 작업 인스턴스 집합을 추가합니다.
+ 기존 코어 및 작업 인스턴스 플릿에 대한 온디맨드 및 스팟 인스턴스의 대상 용량을 변경합니다. 자세한 내용은 [Amazon EMR 클러스터의 인스턴스 플릿 계획 및 구성](emr-instance-fleet.md) 단원을 참조하십시오.
클러스터의 인스턴스를 계획하는 한 가지 방법은 대표 샘플 데이터 세트를 사용하여 테스트 클러스터를 실행하고 클러스터 내 노드의 사용률을 모니터링하는 것입니다. 자세한 내용은 [작업을 수행하는 경우 Amazon EMR 클러스터 보기 및 모니터링](emr-manage-view.md) 단원을 참조하십시오. 또 한 가지 방법은 고려 중인 인스턴스의 용량을 계산하여 이 값을 데이터의 크기와 비교하는 것입니다.
일반적으로 작업을 할당하는 프라이머리 노드 유형에는 높은 처리 기능을 갖춘 Amazon EC2 인스턴스가 필요하지 않지만, 작업을 처리하고 데이터를 HDFS에 저장하는 코어 노드 유형의 Amazon EC2 인스턴스에는 높은 처리 기능 및 스토리지 용량이 모두 필요합니다. 한편, 데이터를 저장하지 않는 태스크 노드 유형의 Amazon EC2 인스턴스에는 처리 기능만 필요합니다. 사용 가능한 Amazon EC2 인스턴스 및 관련 구성에 대한 지침은 [Amazon EMR에서 사용할 Amazon EC2 인스턴스 유형을 구성합니다.](emr-plan-ec2-instances.md) 섹션을 참조하세요.
다음 지침은 대부분의 Amazon EMR 클러스터에 적용됩니다.
+ AWS 계정에서 실행하는 총 온디맨드 Amazon EC2 인스턴스 수에는 vCPU 제한이 있습니다 AWS 리전. vCPU 한도 및 계정에 대한 한도 증가를 요청하는 방법에 대한 자세한 내용은 *Amazon EC2* *Linux 인스턴스용 사용 설명서*에서 [온디맨드 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-on-demand-instances.html)를 참조하세요.
+ 프라이머리 노드에는 일반적으로 대규모 컴퓨팅 요구 사항이 수반되지 않습니다. 노드가 많은 클러스터 또는 특별히 애플리케이션(JupyterHub, Hue 등)이 프라이머리 노드에 배포된 클러스터의 경우 더 큰 프라이머리 노드가 필요할 수 있으며 이는 클러스터 성능을 향상시키는 데 도움이 될 수 있습니다. 예를 들어, 소규모 클러스터(50개 이하 노드)에는 m5.xlarge 인스턴스를 사용하고 더 큰 클러스터에는 더 큰 인스턴스 유형으로 늘리는 방법을 고려합니다.
+ 코어 및 작업 노드의 컴퓨팅 요구는 애플리케이션에서 수행하는 처리 유형에 따라 달라집니다. 대부분의 작업은 범용 인스턴스 유형에서 실행할 수 있습니다. 이 인스턴스 유형은 CPU, 디스크 공간 및 입출력 면에서 균형된 성능을 제공합니다. 컴퓨팅 집약적인 클러스터는 RAM보다 비례적으로 더 많은 CPU를 사용할 수 있는 고성능 CPU 인스턴스의 실행에서 이점을 얻을 수 있습니다. 데이터베이스 및 메모리 캐싱 애플리케이션은 고용량 메모리 인스턴스의 실행에서 이점을 얻을 수 있습니다. 네트워크 집약적인 애플리케이션과 CPU 집약적인 애플리케이션(예: 구문 분석, NLP 및 기계 학습)은 비례적으로 높은 CPU 리소스와 향상된 네트워크 성능을 제공하는 클러스터 컴퓨팅 인스턴스의 실행에서 이점을 얻을 수 있습니다.
+ 클러스터의 각 단계마다 필요한 용량이 다른 경우 적은 코어 노드 수로 시작하여 작업 흐름의 가변 용량 요구 사항에 맞춰 작업 노드 수를 늘리거나 줄일 수 있습니다.
+ 처리할 수 있는 데이터 양은 입력 및 출력되거나 처리 중인 데이터의 크기와 코어 노드의 용량에 따라 달라집니다. 입력, 중간 및 출력 데이터 세트는 모두 처리 중에 클러스터에 상주합니다.
## 스팟 인스턴스는 언제 사용해야 하나요?
Amazon EMR에서 클러스터를 시작하는 경우 스팟 인스턴스에서 프라이머리, 코어 또는 태스크 인스턴스를 시작하도록 선택할 수 있습니다. 각 인스턴스 그룹 유형이 클러스터에서 서로 다른 역할을 수행하므로 스팟 인스턴스에서 각 노드 유형이 시작됩니다. 클러스터 실행 도중에는 인스턴스 구매 옵션을 변경할 수 없습니다. 프라이머리 및 코어 노드의 경우 온디맨드에서 스팟 인스턴스로 변경하거나 그 반대로 변경하려면 클러스터를 종료하고 새 클러스터를 시작해야 합니다. 작업 노드의 경우 새 작업 인스턴스 그룹 또는 인스턴스 플릿을 시작하고 이전 그룹이나 플릿을 제거할 수 있습니다.
**Topics**
+ [
### 태스크 노드 스팟 인스턴스가 종료되어 작업이 실패하지 않도록 하기 위한 Amazon EMR 설정
](#emr-plan-spot-YARN)
+ [
### 스팟 인스턴스의 프라이머리 노드
](#emr-dev-master-instance-group-spot)
+ [
### 스팟 인스턴스의 코어 노드
](#emr-dev-core-instance-group-spot)
+ [
### 스팟 인스턴스의 태스크 노드
](#emr-dev-task-instance-group-spot)
+ [
### 애플리케이션 시나리오에 대한 인스턴스 구성
](#emr-plan-spot-scenarios)
### 태스크 노드 스팟 인스턴스가 종료되어 작업이 실패하지 않도록 하기 위한 Amazon EMR 설정
태스크 노드를 실행하는 데 종종 스팟 인스턴스가 사용되기 때문에, Amazon EMR은 YARN 작업을 예약하는 기본 기능을 제공하며 이를 통해 스팟 인스턴스에서 실행 중인 태스크 노드가 종료되어도 실행 중이던 작업이 실패하지 않습니다. Amazon EMR은 애플리케이션 마스터 프로세스가 코어 노드에서만 실행되게 함으로써 이를 지원합니다. 애플리케이션 마스터 프로세스는 실행 중인 작업을 제어하며, 작업 수명 동안 유지되어야 합니다.
Amazon EMR 릴리스 5.19.0 이상에서는 기본 제공되는 [YARN 노드 레이블](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/NodeLabel.html) 기능을 사용하여 이를 지원합니다. (이전 버전에서는 코드 패치를 사용했습니다.) `yarn-site` 및 `capacity-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개를 모두 사용할 수 있을 때까지 또는 사용자가 클러스터를 종료할 때까지 계속 기다립니다. 실행 중인 클러스터에 용량을 추가하기 위해 코어 인스턴스 그룹의 스팟 인스턴스 수를 변경할 수 있습니다. 인스턴스 그룹 작업 및 인스턴스 플릿에서의 스팟 인스턴스를 통한 작업 방법에 대한 자세한 내용은 [인스턴스 플릿이나 균일한 인스턴스 그룹을 사용하여 Amazon EMR 클러스터 생성](emr-instance-group-configuration.md) 섹션을 참조하세요.
### 스팟 인스턴스의 태스크 노드
작업 노드는 데이터를 처리하지만 HDFS에 영구 데이터를 보관하지 않습니다. 스팟 가격이 최대 스팟 가격보다 높아져서 작업 노드가 종료되는 경우 데이터가 손실되지 않으며 클러스터에 미치는 영향이 최소 수준입니다.
하나 이상의 태스크 인스턴스 그룹을 스팟 인스턴스로 시작할 경우 Amazon EMR에서는 최고 스팟 가격을 사용하여 최대한 많은 태스크 노드를 프로비저닝합니다. 즉, 여섯 개 노드로 된 태스크 인스턴스 그룹을 요청했으며 최고 스팟 가격 이하에서 스팟 인스턴스 다섯 개만 사용할 수 있는 경우, Amazon EMR에서는 다섯 개 노드로 인스턴스 그룹을 시작하고 가능할 경우 나중에 여섯 번째 노드를 추가합니다.
작업 인스턴스 그룹을 스팟 인스턴스로 시작하는 방법은 비용을 최소화하면서 클러스터의 용량을 확장하는 전략적인 방법입니다. 온디맨드 인스턴스로 프라이머리 및 코어 인스턴스 그룹을 시작하는 경우에는 클러스터 실행 시 용량이 보장됩니다. 작업 인스턴스 그룹에 필요한 만큼 작업 인스턴스를 추가하여 피크 트래픽을 처리하거나 데이터 처리를 가속화할 수 있습니다.
콘솔 AWS CLI또는 API를 사용하여 태스크 노드를 추가하거나 제거할 수 있습니다. 또한 다른 작업 그룹을 추가할 수도 있지만, 작업 그룹은 일단 생성되고 나면 제거가 불가능합니다.
### 애플리케이션 시나리오에 대한 인스턴스 구성
다음 표에는 일반적으로 다양한 애플리케이션 시나리오에 적합한 노드 유형 구매 옵션 및 구성에 대한 빠른 참조가 나와 있습니다. 각 시나리오 유형에 대한 추가 정보를 보려면 링크를 선택하세요.
| 애플리케이션 시나리오 | 프라이머리 노드 구매 옵션 | 코어 노드 구매 옵션 | 태스크 노드 구매 옵션 |
| --- | --- | --- | --- |
| [장기 실행 클러스터 및 데이터 웨어하우스](#emr-dev-when-use-spot-data-warehouses) | 온디맨드 | 온디맨드 또는 인스턴스 집합 조합 | 스팟 도는 인스턴스 집합 조합 |
| [비용 기반 워크로드](#emr-dev-when-use-spot-cost-driven) | 스팟 | 스팟 | 스팟 |
| [데이터 중심 워크로드](#emr-dev-when-use-spot-data-critical) | 온디맨드 | 온디맨드 | 스팟 도는 인스턴스 집합 조합 |
| [애플리케이션 테스트](#emr-dev-when-use-spot-application-testing) | 스팟 | 스팟 | 스팟 |
Amazon EMR 클러스터를 실행할 때 스팟 인스턴스가 유용한 몇 가지 시나리오가 있습니다.
#### 장기 실행 클러스터 및 데이터 웨어하우스
데이터 웨어하우스와 같이 컴퓨팅 용량이 예측 가능하게 변동되는 영구 Amazon EMR 클러스터를 실행 중인 경우 스팟 인스턴스를 사용하여 최저 비용으로 피크 수요를 처리할 수 있습니다. 프라이머리 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 시작하여 일반 용량을 처리하고 태스크 인스턴스 그룹을 스팟 인스턴스로 시작하여 피크 로드 요구 사항을 처리할 수 있습니다.
#### 비용 기반 워크로드
완료 시간보다 비용을 낮추는 것이 더 중요한 일시적 클러스터를 실행 중이며 부분 작업 손실을 허용할 수 있는 경우, 전체 클러스터(프라이머리, 코어 및 태스크 인스턴스 그룹)을 스팟 인스턴스로 실행하면 최대 비용 절감의 혜택을 얻을 수 있습니다.
#### 데이터 중심 워크로드
완료 시간보다 비용을 낮추는 것이 더 중요한 클러스터를 실행 중이지만 부분 작업 손실을 허용할 수 없는 경우, 프라이머리 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 시작하고 스팟 인스턴스로 된 하나 이상의 태스크 인스턴스 그룹으로 보충합니다. 프라이머리 및 코어 인스턴스 그룹을 온디맨드 인스턴스로 실행하면 데이터가 HDFS에서 유지되며 스팟 시장 변동으로 인한 종료로부터 클러스터가 보호되는 한편, 태스크 인스턴스 그룹을 스팟 인스턴스로 실행함으로써 누적되는 비용 절감의 혜택을 얻을 수 있습니다.
#### 애플리케이션 테스트
프로덕션 환경 내 시작을 준비하기 위해 새 애플리케이션을 테스트하려는 경우 전체 클러스터(프라이머리, 코어 및 태스크 인스턴스 그룹)를 스팟 인스턴스로 실행하면 테스트 비용을 낮출 수 있습니다.
## 클러스터의 필요한 HDFS 용량 계산
클러스터에 사용할 수 있는 HDFS 스토리지 양은 다음 인수에 따라 달라집니다.
+ 코어 노드에 사용할 Amazon EC2 인스턴스의 수입니다.
+ 사용되는 인스턴스 유형에 대한 Amazon EC2 인스턴스 스토어의 용량입니다. 인스턴스 스토어 볼륨에 대한 자세한 내용은 **Amazon EC2 사용 설명서에서 [Amazon EC2 인스턴스 저장소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html)를 참조하세요.
+ 코어 노드에 연결된 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 인스턴스 유형 선택
+ 데이터 압축 사용
+ Hadoop 구성 설정을 변경하여 복제 인수 낮추기
복제 인수를 낮추면 HDFS 데이터의 중복성과 손실/손상된 HDFS 블록으로부터의 클러스터 복구 기능이 감소되므로 이 기능은 각별히 주의해서 사용해야 합니다.