기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 여러 프라이머리 노드가 있는 Amazon EMR 클러스터를 생성하는 경우 고려 사항 및 모범 사례 복수의 프라이머리 노드를 사용하여 Amazon EMR 클러스터를 생성할 경우 다음을 고려하세요. **중요** 복수의 프라이머리 노드가 있는 고가용성 EMR 클러스터를 시작하기 위해서는 최신 Amazon EMR 릴리스를 사용하는 것이 가장 좋습니다. 이렇게 하면 고가용성 클러스터에 대해 최고 수준의 복원력과 안정성을 확보할 수 있습니다. + 인스턴스 플릿을 위한 고가용성은 Amazon EMR 릴리스 5.36.1, 5.36.2, 6.8.1, 6.9.1, 6.10.1, 6.11.1, 6.12.0 이상에서 지원됩니다.** *인스턴스 그룹*의 경우에는 고가용성이 Amazon EMR 릴리스 5.23.0 이상에서 지원됩니다. 자세히 알아보려면 [Amazon EMR 릴리스 정보](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-release-components.html)를 참조하세요. + 고가용성 클러스터에서 Amazon EMR은 온디맨드 인스턴스가 포함된 프라이머리 노드의 시작만을 지원합니다. 따라서 클러스터의 최대 가용성이 보장됩니다. + 여전히 프라이머리 플릿에 복수의 인스턴스 유형을 지정할 수 있지만, 비정상 프라이머리 노드의 교체를 포함하여 고가용성 클러스터의 모든 프라이머리 노드가 동일한 인스턴스 유형으로 시작됩니다. + 작업을 계속하기 위해서는 프라이머리 노드의 수가 여러 개인 고가용성 클러스터에서 프라이머리 노드 3개 중 2개가 정상이어야 합니다. 따라서 프라이머리 노드 두 개에 장애가 동시에 발생할 경우 EMR 클러스터에 장애가 발생합니다. + 고가용성 클러스터를 포함한 모든 EMR 클러스터는 단일 가용 영역에서 시작됩니다. 따라서 가용 영역 장애를 용납할 수 없습니다. 가용 영역 중단의 경우 클러스터에 대한 액세스 권한이 손실됩니다. + 인스턴스 플릿 내에서 클러스터를 시작할 때 사용자 지정 서비스 역할 또는 정책을 사용하는 경우 Amazon EMR이 지원되지 않는 가용 영역(AZ)을 필터링할 수 있도록 `ec2:DescribeInstanceTypeOfferings` 권한을 추가할 수 있습니다. Amazon EMR이 프라이머리 노드의 인스턴스 유형을 지원하지 않는 AZ를 필터링하면 Amazon EMR은 지원되지 않는 프라이머리 인스턴스 유형으로 인해 클러스터 시작이 실패하는 것을 방지합니다. 자세한 내용은 [지원되지 않는 인스턴스 유형](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-INSTANCE_TYPE_NOT_SUPPORTED-error.html)을 참조하세요. + Amazon EMR은 [여러 프라이머리 노드를 포함하는 Amazon EMR 클러스터에서 지원되는 애플리케이션](emr-plan-ha-applications.md#emr-plan-ha-applications-list)에 명시된 것 이외의 오픈 소스 애플리케이션 고가용성을 보장하지 않습니다. + Amazon EMR 릴리스 5.23.0\$15.36.2까지 인스턴스 그룹 클러스터의 프라이머리 노드 3개 중 2개에서만 HDFS NameNode를 실행합니다. + Amazon EMR 릴리스 6.x 이상에서는 인스턴스 그룹의 세 프라이머리 노드 모두 HDFS NameNode를 실행합니다. 서브넷 구성 시 고려 사항: + 여러 프라이머리 노드가 있는 Amazon EMR 클러스터는 하나의 가용 영역 또는 서브넷에만 위치할 수 있습니다. 장애 조치 이벤트가 발생할 때 서브넷이 모두 사용되고 있거나 과다 구독된 경우 Amazon EMR은 장애가 발생한 프라이머리 노드를 대체할 수 없습니다. 이러한 시나리오를 피하려면 전체 서브넷을 Amazon EMR 클러스터 전용으로 사용하는 것이 좋습니다. 또한 서브넷에서 사용할 수 있는 프라이빗 IP 주소가 충분한지 확인하세요. 코어 노드 구성 시 고려 사항: + 코어 노드의 가용성도 높게 보장하려면 4개 이상의 코어 노드를 시작하는 것이 좋습니다. 코어 노드가 3개 이하인 더 작은 클러스터를 시작하려면 HDFS에서 DFS를 충분하게 복제할 수 있도록 `dfs.replication parameter`를 `2` 이상으로 설정합니다. 자세한 내용은 [HDFS 구성](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html)을 참조하세요. **주의** 노드 수가 4개 미만인 클러스터에서 `dfs.replication`을 1로 설정하면 단일 노드가 중단된 경우 HDFS 데이터가 손실될 수 있습니다. 프로덕션 워크로드에는 코어 노드가 4개 이상 있는 클러스터를 사용하는 것이 좋습니다. Amazon EMR은 클러스터에서 코어 노드를 `dfs.replication` 미만으로 조정하는 허용하지 않습니다. 예를 들어, `dfs.replication = 2`인 경우 최소 코어 노드 수가 2개입니다. Managed Scaling, Auto Scaling을 사용하거나 클러스터 크기를 수동으로 조정하는 경우 `dfs.replication`을 2 이상으로 설정하는 것이 좋습니다. 지표에 대한 경보 설정 시 고려 사항: + Amazon EMR은 현재 HDFS 또는 YARN에 대한 애플리케이션 특정 지표를 제공하지 않습니다. 프라이머리 노드 인스턴스 수를 모니터링하도록 경보를 설정하는 것이 좋습니다. Amazon CloudWatch 지표 `MultiMasterInstanceGroupNodesRunning`, `MultiMasterInstanceGroupNodesRunningPercentage` 또는 `MultiMasterInstanceGroupNodesRequested`를 사용하여 경보를 구성합니다. 프라이머리 노드에서 장애 또는 교체가 발생할 경우 CloudWatch에서 알림을 전송합니다. + `MultiMasterInstanceGroupNodesRunningPercentage`가 100%보다 작고 50%보다 크면 클러스터에 프라이머리 노드가 없는 것일 수 있습니다. 이 경우 Amazon EMR은 프라이머리 노드를 교체하려고 시도합니다. + `MultiMasterInstanceGroupNodesRunningPercentage`가 50% 미만으로 떨어지면 두 개의 프라이머리 노드에서 장애가 발생한 것일 수 있습니다. 이 경우 쿼럼이 손실되고 클러스터를 복구할 수 없습니다. 이 클러스터에서 데이터를 수동으로 마이그레이션해야 합니다. 자세한 내용은 [지표에 대한 경보 설정](https://docs.aws.amazon.com/emr/latest/ManagementGuide/UsingEMR_ViewingMetrics.html#UsingEMR_ViewingMetrics_Alarm)을 참조하세요.