Amazon EMR 릴리스 5.30.0

• Amazon EMR 7.x 릴리스의 애플리케이션 버전

• Amazon EMR 6.x 릴리스의 애플리케이션 버전

• Amazon EMR 5.x 릴리스의 애플리케이션 버전

• Amazon EMR 4.x 릴리스의 애플리케이션 버전

업그레이드

• 버전 1.11.759 AWS SDK for Java 로 업그레이드됨

• Amazon SageMaker Spark SDK가 버전 1.3.0으로 업그레이드됨

• EMR 레코드 서버가 버전 1.6.0으로 업그레이드됨

• Flink가 버전 1.10.0으로 업그레이드됨

• Ganglia가 버전 3.7.2로 업그레이드됨

• HBase가 버전 1.4.13으로 업그레이드됨

• Hudi가 버전 0.5.2-incubating으로 업그레이드됨

• Hue가 버전 4.6.0으로 업그레이드됨

• JupyterHub가 버전 1.1.0으로 업그레이드됨

• Livy가 버전 0.7.0-incubating으로 업그레이드됨

• Oozie가 버전 5.2.0으로 업그레이드됨

• Presto가 버전 0.232로 업그레이드됨

• Spark가 버전 2.4.5로 업그레이드됨

• 업그레이드된 커넥터 및 드라이버: Amazon Glue 커넥터 1.12.0, Amazon Kinesis 커넥터 3.5.0, EMR DynamoDB 커넥터 4.14.0

새로운 특성

• EMR Notebooks - 5.30.0을 사용하여 생성된 EMR 클러스터와 함께 사용하면 EMR 노트북 커널이 클러스터에서 실행됩니다. 이로써 노트북 성능이 향상되며, 커널을 설치하고 사용자 지정할 수 있습니다. 클러스터 프라이머리 노드에 Python 라이브러리를 설치할 수도 있습니다. 자세한 내용은 EMR 관리 안내서에서 커널 및 라이브러리 설치 및 사용을 참조하세요.

• Managed Scaling - Amazon EMR 버전 5.30.0 이상에서는 EMR Managed Scaling을 활성화하여 워크로드에 따라 클러스터에서 인스턴스 또는 유닛 수를 자동으로 늘리거나 줄일 수 있습니다. Amazon EMR은 클러스터 지표를 지속적으로 평가하여 비용과 속도 측면에서 클러스터를 최적화하는 조정 결정을 내립니다. 자세한 내용은 Amazon EMR 관리 안내서에서 클러스터 리소스 조정을 참조하세요.

• Amazon S3에 저장된 로그 파일 암호화 - Amazon EMR 버전 5.30.0 이상을 사용하면 AWS KMS 고객 관리형 키를 사용하여 Amazon S3에 저장된 로그 파일을 암호화할 수 있습니다. 자세한 내용은 Amazon EMR 관리 안내서에서 Amazon S3에 저장된 로그 파일 암호화를 참조하세요.

• Amazon Linux 2 지원 - EMR 버전 5.30.0 이상에서 EMR은 Amazon Linux 2 OS를 사용합니다. 새로운 사용자 지정 Amazon Machine Image(AMI)는 Amazon Linux 2 AMI를 기반으로 해야 합니다. 자세한 내용은 사용자 지정 AMI 사용을 참조하십시오.

• Presto 단계적 자동 조정 - 5.30.0 버전을 사용하는 EMR 클러스터의 경우 Auto Scaling 제한 시간을 설정할 수 있습니다. 이 제한 시간을 통해 Presto에서 노드가 서비스 해제되기 전에 실행을 완료할 수 있습니다. 자세한 내용은 단계적 서비스 해제 기능이 있는 자동 조정 사용 단원을 참조하십시오.

• 새 할당 전략 옵션을 사용한 플릿 인스턴스 생성 - 새 할당 전략 옵션은 EMR 버전 5.12.1 이상에서 사용할 수 있습니다. 이를 통해 클러스터 프로비저닝 속도가 빨라지고 스팟 할당이 더 정확해지며 스팟 인스턴스 중단이 줄어듭니다. 기본이 아닌 EMR 서비스 역할은 업데이트해야 합니다. 인스턴스 플릿 구성을 참조하세요.

• sudo systemctl stop 및 sudo systemctl start 명령 – Amazon Linux 2 OS를 사용하는 EMR 버전 5.30.0 이상에서 EMR은 sudo systemctl stop 및 sudo systemctl start 명령을 사용하여 서비스를 다시 시작합니다. 자세한 내용은 Amazon EMR에서 서비스를 다시 시작하려면 어떻게 해야 하나요?를 참조하세요.

변경 사항, 향상된 기능 및 해결된 문제

• EMR 버전 5.30.0은 기본적으로 Ganglia를 설치하지 않습니다. 클러스터 생성 시 Ganglia를 설치하도록 명시적으로 선택할 수 있습니다.

• Spark 성능 최적화

• Presto 성능 최적화

• Python 3은 Amazon EMR 버전 5.30.0 이상의 기본값입니다.

• 프라이빗 서브넷의 서비스 액세스에 대한 기본 관리형 보안 그룹이 새 규칙으로 업데이트되었습니다. 서비스 액세스에 대한 사용자 지정 보안 그룹을 사용하는 경우, 기본 관리형 보안 그룹과 동일한 규칙을 포함시켜야 합니다. 자세한 내용은 서비스 액세스에 대한 Amazon EMR 관리형 보안 그룹(프라이빗 서브넷)을 참조하세요. Amazon EMR에 대해 사용자 지정 서비스 역할을 사용하는 경우 EMR에서 보안 그룹이 올바르게 생성되는지 여부를 검증할 수 있도록 ec2:describeSecurityGroups에 대한 권한을 부여해야 합니다. EMR_DefaultRole을 사용하는 경우 이 권한은 이미 기본 관리형 정책에 포함되어 있습니다.

알려진 문제

• 이전 AL2에서 더 낮은 '최대 열린 파일' 한도[최신 릴리스에서 수정됨]. Amazon EMR 릴리스: emr-5.30.x, emr-5.31.0, emr-5.32.0, emr-6.0.0, emr-6.1.0, emr-6.2.0은 Amazon Linux 2(AL2)의 이전 버전에 기반합니다. 이전 버전에서는 Amazon EMR 클러스터가 기본 AMI에서 생성되는 경우 '최대 열린 파일'에 대한 ulimit 설정이 더 낮습니다. Amazon EMR 릴리스 5.30.1, 5.30.2, 5.31.1, 5.32.1, 6.0.1, 6.1.1, 6.2.1, 5.33.0, 6.3.0 이상에는 더 높은 '최대 열린 파일' 설정을 포함한 영구적 수정 사항이 포함되어 있습니다. 열린 파일 한도가 낮은 릴리스의 경우 Spark 작업을 제출할 때 'Too many open files' 오류가 발생합니다. 영향을 받는 릴리스에서 Amazon EMR 기본 AMI의 '최대 열린 파일'에 대한 기본 ulimit 설정은 4,096개이며, 이는 최신 Amazon Linux 2 AMI의 65,536개 파일 제한보다 낮습니다. '최대 열린 파일'에 대한 더 낮은 ulimit 설정을 사용하면 Spark 드라이버와 실행기가 4,096개가 넘는 파일을 열려고 할 때 Spark 작업이 실패합니다. 이 문제를 해결하기 위해 Amazon EMR에는 클러스터 생성 시 ulimit 설정을 조정하는 부트스트랩 작업(BA) 스크립트가 있습니다.

  이 문제에 대한 영구 수정 사항이 포함되지 않은 이전 Amazon EMR 버전을 사용하는 경우 다음 해결 방법을 통해 instance-controller ulimit를 최대 65,536개의 파일로 명시적으로 설정할 수 있습니다.

  명령줄에서 ulimit를 명시적으로 설정합니다.

  1. /etc/systemd/system/instance-controller.service를 편집하여 Service 섹션에 다음 파라미터를 추가합니다.

     LimitNOFILE=65536

     LimitNPROC=65536

  2. InstanceController 다시 시작

     $ sudo systemctl daemon-reload

     $ sudo systemctl restart instance-controller

  부트스트랩 작업(BA)을 사용하여 ulimit 설정

  클러스터 생성 시 부트스트랩 작업(BA) 스크립트를 사용하여 instance-controller ulimit를 65,536개 파일로 구성할 수도 있습니다.

  #!/bin/bash
  for user in hadoop spark hive; do
  sudo tee /etc/security/limits.d/$user.conf << EOF
  $user - nofile 65536
  $user - nproc 65536
  EOF
  done
  for proc in instancecontroller logpusher; do
  sudo mkdir -p /etc/systemd/system/$proc.service.d/
  sudo tee /etc/systemd/system/$proc.service.d/override.conf << EOF
  [Service]
  LimitNOFILE=65536
  LimitNPROC=65536
  EOF
  pid=$(pgrep -f aws157.$proc.Main)
  sudo prlimit --pid $pid --nofile=65535:65535 --nproc=65535:65535
  done
  sudo systemctl daemon-reload

• Managed Scaling

  Presto가 설치되지 않은 5.30.0 및 5.30.1 클러스터에서 Managed Scaling을 수행하면 애플리케이션 장애가 발생하거나 균일한 인스턴스 그룹 또는 인스턴스 플릿이 ARRESTED 상태로 유지될 수 있습니다. 특히 스케일 다운 작업 이후 바로 스케일 업 작업이 수행되는 경우가 이에 해당합니다.

  해결 방법으로 작업에 Presto가 필요하지 않더라도 Amazon EMR 릴리스 5.30.0 및 5.30.1에서 클러스터를 생성할 때 설치할 애플리케이션으로 Presto를 선택합니다.

• 여러 프라이머리 노드와 Kerberos 인증을 사용하는 클러스터에서 알려진 문제

  Amazon EMR 릴리스 5.20.0 이상에서 여러 프라이머리 노드와 Kerberos 인증을 사용하여 클러스터를 실행하는 경우, 클러스터를 일정 시간 실행한 후 스케일 다운 또는 단계 제출과 같은 클러스터 작업에 문제가 발생할 수 있습니다. 기간은 정의한 Kerberos 티켓 유효 기간에 따라 다릅니다. 스케일 다운 문제는 제출한 자동 스케일 다운 및 명시적 스케일 다운 요청 모두에 영향을 미칩니다. 이외의 다른 클러스터 작업도 영향을 받을 수 있습니다.

  해결 방법:

  • 여러 프라이머리 노드가 있는 EMR 클러스터의 리드 프라이머리 노드에 대한 hadoop 사용자로 SSH 연결합니다.

  • 다음 명령을 실행하여 hadoop 사용자의 Kerberos 티켓을 갱신합니다.

    kinit -kt <keytab_file> <principal>

    일반적으로 keytab 파일은 /etc/hadoop.keytab에 있으며, 보안 주체는 hadoop/<hostname>@<REALM> 양식입니다.

  참고

  이 해결 방법은 Kerberos 티켓이 유효한 기간에 작동합니다. 이 기간은 기본적으로 10시간이지만 Kerberos 설정으로 구성할 수 있습니다. Kerberos 티켓이 만료되면 위 명령을 다시 실행해야 합니다.

• Hue 4.6.0의 기본 데이터베이스 엔진은 SQLite이며, 이 때문에 외부 데이터베이스에서 Hue를 사용하려고 하면 문제가 발생합니다. 이 문제를 해결하려면 hue-ini 구성 분류에서 engine을 mysql로 설정합니다. 이 문제는 Amazon EMR 버전 5.30.1에서 수정되었습니다.

• Hive 파티션 위치 형식과 함께 Spark를 사용하여 Amazon S3의 데이터를 읽고, Amazon EMR 릴리스 5.30.0~5.36.0 및 6.2.0~6.9.0에서 Spark를 실행하는 경우 클러스터가 데이터를 제대로 읽지 못하는 문제가 발생할 수 있습니다. 파티션에 다음과 같은 특성이 모두 있는 경우 이러한 상황이 발생할 수 있습니다.

  • 둘 이상의 파티션이 동일한 테이블에서 스캔됩니다.

  • 하나 이상의 파티션 디렉터리 경로가 하나 이상의 다른 파티션 디렉터리 경로의 접두사입니다. 예를 들어 s3://bucket/table/p=a는 s3://bucket/table/p=a b의 접두사입니다.

  • 다른 파티션 디렉터리에서 접두사 뒤에 오는 첫 번째 문자의 UTF-8 값이 / 문자(U+002F)보다 작습니다. 예를 들어 s3://bucket/table/p=a b에서 a와 b 사이에 있는 공백 문자(U+0020)가 이 카테고리에 속합니다. !"#$%&‘()*+,-와 같은 14개의 비제어 문자가 있습니다. 자세한 내용은 UTF-8 인코딩 테이블 및 유니코드 문자를 참조하세요.

  이 문제를 해결하려면 spark-defaults 분류에서 spark.sql.sources.fastS3PartitionDiscovery.enabled 구성을 false로 설정합니다.