Amazon EMR FAQ

Amazon EMR은 Apache Spark, Apache Hive 및 Presto와 같은 오픈 소스 프레임워크를 사용하여 데이터 처리, 대화식 분석 및 기계 학습을 위한 업계 최고의 클라우드 빅 데이터 플랫폼입니다. EMR을 사용하면 기존 온프레미스 솔루션의 50%도 안 되는 비용으로 표준 Apache Spark보다 1.7배 이상 빠르게 페타바이트 규모의 분석을 실행할 수 있습니다.

Amazon EMR에서는 컴퓨팅 용량 또는 오픈 소스 애플리케이션 관리를 고민하지 않고도 데이터 변환 및 분석에 집중하면서 비용을 절감할 수 있습니다. EMR을 사용하면 Amazon EC2에서와 같이 대량 또는 소량의 용량을 프로비저닝하고 변화하는 컴퓨팅 수요를 관리하도록 크기 조정 규칙을 설정할 수 있습니다. 그리고 인프라에서 변화를 사용자에게 알리고 즉각적으로 작업을 수행할 수 있도록 CloudWatch 알림을 설정할 수 있습니다. Kubernetes를 사용하는 경우 EMR을 사용하여 Amazon EKS 클러스터에 워크로드를 제출할 수도 있습니다. EC2 또는 EKS 사용 여부에 관계없이 EMR의 최적화된 런타임 이점을 활용하여 분석 속도를 높이고 비용과 시간을 모두 절감할 수 있습니다.

Amazon EC2, Amazon Elastic Kubernetes Service(EKS) 또는 온프레미스 AWS Outposts를 사용하여 EMR에 워크로드를 배포할 수 있습니다. EMR 콘솔, API, SDK 또는 CLI로 워크로드를 실행 및 관리하고 Amazon Managed Workflows for Apache Airflow(MWAA) 또는 AWS Step Functions를 사용하여 조율할 수 있습니다. 대화식 경험을 위해서 EMR Studio 또는 SageMaker Studio를 사용할 수 있습니다.

Amazon EMR에 가입하려면 Amazon EMR 세부 정보 페이지(http://aws.amazon.com/emr)에서 [지금 가입] 버튼을 클릭합니다. Amazon EMR에 액세스하려면 Amazon EC2 및 Amazon S3에 가입해야 합니다. 이러한 서비스에 아직 가입하지 않은 경우, Amazon EMR 가입 과정 중에 서비스 가입 안내 메시지가 표시됩니다. 가입 후에는 서비스 사용 방법을 알아보는 데 가장 유용한 시작 안내서를 비롯한 Amazon EMR 설명서를 참조하세요.

서비스 수준 계약(SLA)을 참조하세요.

이 도움말 및 자습서에서 샘플 코드를 확인할 수 있습니다. EMR Studio를 사용하는 경우, 노트북 예제 세트를 통해 기능을 둘러볼 수 있습니다.

Amazon EMR Studio에서 R, Python, Scala 및 PySpark로 작성된 데이터 과학 및 데이터 엔지니어링 애플리케이션을 개발하고 시각화하며 디버깅할 수 있습니다. 예를 들어, Eclipse, Spyder, PyCharm 또는 RStudio를 사용하여 데스크톱에서 데이터 처리 작업을 개발하고 Amazon EMR에서 실행할 수도 있습니다. 새 클러스터를 구동할 때 소프트웨어 구성에서 JupyterHub 또는 Zeppelin을 선택하고 하나 이상의 인스턴스를 사용하여 Amazon EMR에서 애플리케이션을 개발할 수도 있습니다.

명령줄 도구 또는 API에서는 프로그래밍 방식으로 클러스터를 시작하고 실행 중인 클러스터의 진행 상태를 모니터링하고, 클러스터에 사용자 정의 기능을 추가로 생성(여러 프로세스 단계, 일정 예약, 워크플로, 모니터링 등의 순서)하거나, 기타 Amazon EMR 고객을 위한 유용한 도구 또는 애플리케이션을 개발할 수 있는 기능을 제공합니다. 반면 AWS Management Console은 사용하기 쉬운 그래픽 인터페이스를 제공하는데, 이를 통해 웹 브라우저에서 직접 클러스터를 시작하고 모니터링할 수 있습니다.

예. 작업이 실행 중인 경우 AddJobFlowSteps API를 사용하여 옵션에서 단계를 추가할 수 있습니다. AddJobFlowSteps API는 현재 단계 순서의 마지막에 새로운 단계를 추가합니다. 클러스터에 조건부 논리를 구현하거나 디버깅을 수행하기 위해 필요하다면 이 API를 사용할 수도 있습니다.

Amazon SNS에 가입하여 클러스터가 끝날 때 SNS 주제에 클러스터를 게시할 수 있습니다. 또한 AWS Management Console에서 클러스터 진행률을 보거나 명령줄, SDK 또는 API를 사용하여 클러스터의 상태를 확인할 수 있습니다.

예. 모든 단계가 완료되면 자동 종료 플래그를 설정하여 클러스터를 자동으로 종료할 수 있습니다.

Amazon EMR 5.30.0 이상 및 Amazon EMR 6.x 시리즈는 Amazon Linux 2를 기반으로 합니다. Amazon Linux 2에 기반하여 생성된 사용자 지정 AMI를 지정할 수도 있습니다. 이렇게 하면 사실상 거의 모든 애플리케이션에 대해 정교한 사전 구성을 수행할 수 있습니다. 자세한 내용은 사용자 지정 AMI 사용을 참조하세요.

예. 클러스터에 서드 파티 소프트웨어 패키지를 설치하기 위해 부트스트랩 작업을 사용할 수 있습니다. 또한, Hadoop 분산 캐시 메커니즘을 사용하여 정적으로 컴파일된 실행 파일을 업로드할 수 있습니다. EMR 6.x은 YARN NodeManager를 허용하여 EMR 클러스터 호스트 또는 Docker 컨테이너 내에 바로 컨테이너를 실행하는 Hadoop 3을 지원합니다. 자세한 내용은 설명서를 참조하세요.

클러스터에 관한 정보를 수집하는 데 사용할 수 있는 도구는 여러 가지가 있어 무엇이 잘못되었는지 판정하는 데 도움이 됩니다. Amazon EMR Studio를 사용하는 경우 Spark UI 및 YARN Timeline Service와 같은 도구를 시작하여 디버깅을 단순화할 수 있습니다. Amazon EMR 콘솔에서 Apache Spark, Tez UI 및 YARN 타임라인 서버용 영구 애플리케이션 사용자 인터페이스, 여러 개의 클러스터 내 애플리케이션 사용자 인터페이스 및 모든 YARN 애플리케이션에 대한 Amazon EMR 콘솔의 애플리케이션 요약 보기에 오프클러스터 방식으로 액세스할 수 있습니다. 또한 이러한 웹 인터페이스를 통해 SSH를 사용하여 마스터 노드에 연결하고 클러스터 인스턴스를 볼 수 있습니다. 자세한 내용은 설명서를 참조하세요.

노트북을 사용해 작업을 제출할 수 있도록 EMR Studio가 통합 개발 환경(IDE)을 제공하므로 데이터 사이언티스트와 데이터 엔지니어는 R, Python, Scala 및 PySpark에서 작성한 데이터 엔지니어링 및 데이터 사이언스 애플리케이션을 쉽게 개발, 시각화 및 디버깅할 수 있습니다.

단일 로그인 기능, 완전관리형 Jupyter 노트북, 자동화 인프라 프로비저닝 및 AWS 콘솔 또는 클러스터 로그인 없이 작업을 디버깅하는 능력을 갖춘 완전관리형 애플리케이션입니다. 데이터 사이언티스트와 분석가는 사용자 지정 커널 및 라이브러리를 설치하고, GitHub 및 BitBucket과 같은 코드 리포지토리를 사용하여 동료와 협업하거나 Apache Airflow, AWS Step Functions 및 Amazon Managed Workflows for Apache Airflow와 같은 오케스트레이션 서비스를 사용하여 파라미터화된 노트북을 예약된 워크플로의 일부로 실행할 수 있습니다. 자세한 내용은 ‘Amazon MWAA를 사용하여 Amazon EMR 노트북에서 분석 작업 오케스트레이션’ 섹션을 참조하세요. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Apache Spark용 EMR 런타임을 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다. 관리자가 EMR Studio for analysts를 설정함으로써 기존 EMR 클러스터에서 애플리케이션을 실행하거나 EMR용으로 사전 정의된 AWS CloudFormation 템플릿을 사용하여 새 클러스터를 생성할 수 있습니다.

EMR Studio를 통해 기업 자격 증명을 사용하여 AWS 콘솔에 로그인하지 않고도 완전관리형 Jupyter 노트북에 바로 로그인하고, 노트북을 몇 초 안에 사용하며, 샘플 노트북에 온보딩하고, 데이터 탐색을 수행할 수 있습니다. 또한, 노트북에서 사용자 지정 커널 및 Python 라이브러리를 로드해 환경을 사용자 지정할 수 있습니다. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Apache Spark용 EMR 런타임을 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다. GitHub 및 기타 리포지토리를 통해 노트북을 공유해 동료와 협업할 수 있습니다. 또한, 지속적 통합 및 배포 파이프라인으로 직접 노트북을 실행할 수도 있습니다. 노트북에 다른 파라미터 값을 전달할 수 있습니다. Apache Airflow 등의 워크플로우 통합 서비스를 사용하여 노트북을 연결하고, 노트북을 예정된 워크플로우에 통합할 수 있습니다. 또한 Spark UI 및 YARN 타임라인 서비스와 같은 기본 애플리케이션 인터페이스를 사용해 가능한 한 적은 클릭으로 클러스터 및 작업을 디버깅할 수 있습니다.

크게 다섯 가지 차이점이 있습니다.

1. EMR Studio용 AWS Management Console에 액세스할 필요가 없습니다. EMR Studio는 AWS Management Console의 외부에 호스팅합니다. AWS Management Console에 대한 액세스를 데이터 사이언티스트 또는 데이터 엔지니어에게 제공하지 않는 경우 유용합니다.

2. AWS IAM Identity Center(AWS SSO의 후속 서비스)를 사용하여 ID 제공업체의 엔터프라이즈 보안 인증 정보를 사용하여 EMR Studio에 로그인할 수 있습니다. 

3. EMR Studio는 노트북 우선 경험을 제공합니다. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Apache Spark용 EMR 런타임을 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다. 클러스터에 코드를 실행하여 최대한 단순하게 노트북을 기존 클러스터에 연결하거나 새로운 것을 프로비저닝할 수 있습니다.

4. EMR Studio는 단순화된 사용자 인터페이스 및 추상적인 하드웨어 구성을 가지고 있습니다. 예를 들어 클러스터 양식을 설치하고 새 클러스터를 시작하기 위해 해당 양식을 사용할 수 있습니다. 

5. EMR Studio는 단순화된 디버깅 경험을 활성화하여 한 지점의 자연 애플리케이션 사용자 인터페이스에 최소한의 클릭을 사용하여 액세스할 수 있습니다.

EMR Studio와 SageMaker Studio는 모두 Amazon EMR에서 사용할 수 있습니다. EMR Studio는 R, Python, Scala 및 PySpark에서 작성한 데이터 엔지니어링 및 데이터 사이언스 애플리케이션을 쉽게 개발, 시각화 및 디버깅할 수 있는 통합 개발 환경(IDE)을 제공합니다. Amazon SageMaker Studio는 모든 기계 학습 개발 단계를 수행할 수 있는 웹 기반의 단일 시각적 인터페이스를 제공합니다. SageMaker Studio는 모델을 구축, 훈련 및 배포하는 데 필요한 액세스 권한, 제어 및 가시성을 각 단계별로 완벽하게 제공합니다. 신속하게 데이터를 업로드하고, 새로운 노트북을 생성하며, 모델을 훈련 및 튜닝하고, 단계를 앞뒤로 이동하며 실험을 조정하고, 결과를 비교하며, 모델을 프로덕션에 배포하여 한 곳에서 생산성을 크게 높일 수 있습니다. 

관리자가 먼저 EMR Studio를 설치해야 합니다. Amazon EMR Studio의 고유 로그인 URL을 관리자에게 받으면 기업 자격 증명을 사용해 Studio에 직접 로그인할 수 있습니다.

아니요. 관리자가 EMR Studio를 설치하고 Studio 액세스 URL을 제공하면 고객 팀은 기업 자격 증명을 사용해 로그인할 수 있습니다. AWS Management Console에 로그인할 필요는 없습니다. EMR Studio에서 팀은 작업을 수행하고 관리자가 구성한 리소스에 액세스할 수 있습니다.

AWS IAM Identity Center(AWS SSO의 후속 서비스)는 EMR Studio의 Single Sign-On(SSO) 서비스 제공업체입니다. AWS IAM이 지원하는 ID 제공업체 목록은 설명서에서 찾을 수 있습니다.

Workspace는 Jupyter Notebook를 구성하도록 지원합니다. Workspace 내 모든 노트북은 동일한 Amazon S3 위치에 저장되며 동일 클러스터에서 실행됩니다. 또한 GitHub 저장소 같은 코드 저장소를 workspace 내 모든 노트북에 링크할 수 있습니다. Workspace를 클러스터에 첨부하기 전에 생성 및 구성할 수 있으나 노트북을 실행하기 전에 클러스터와 연결해야 합니다.

예. 작업 공간은 클러스터에 연결하지 않고도 생성하거나 열 수 있습니다. 작업 공간은 실행해야 할 때에만 클러스터에 연결해야 합니다. EMR Studio 커널 및 애플리케이션은 EMR 클러스터에서 실행되므로 성능을 최적화한 Amazon EMR Runtime for Apache Spark를 사용하는 분산 데이터 처리의 이점을 누릴 수 있습니다.

모든 Spark 쿼리는 EMR 클러스터에서 실행되므로 클러스터에서 Spark 애플리케이션이 사용하는 모든 런타임 라이브러리를 설치해야 합니다. 노트북 셀 내부에 노트북 범위의 라이브러리를 쉽게 설치할 수 있습니다. 또한 클러스터의 마스터 노드에 SSH를 사용하여 연결된 동안 또는 노트북 셀 내부에서 클러스터 마스터 노드에 Jupyter Notebook 커널 및 Python 라이브러리를 설치할 수도 있습니다. 자세한 내용은 설명서를 참조하세요. 부트스트랩 작업 또는 사용자 지정 AMI를 사용하여 클러스터를 생성할 때 필요한 라이브러리를 설치할 수도 있습니다. 자세한 내용은 부트스트랩 작업을 생성하여 추가 소프트웨어 설치 및 Amazon EMR 관리 안내서에서 사용자 지정 AMI 사용을 참조하세요.

Workspace는 Workspace의 노트북 파일과 함께 정기적으로 Workspace를 생성할 때 지정한 Amazon S3 위치에 ipynb 파일 형식으로 자동 저장됩니다. 노트북 파일 이름은 Amzon EMR Studio의 노트북 이름과 같습니다.

Git 기반 리포지토리를 Amazon EMR Studio 노트북에 연결하여 노트북을 버전 제어 환경에 저장할 수 있습니다.

EMR Studio에서는 Amazon Elastic Compute Cloud(Amazon EC2)에서 실행되는 Amazon EMR 또는 Amazon Elastic Kubernetes Service(Amazon EKS) 기반 Amazon EMR에서 노트북 코드를 실행할 수 있습니다. 노트북을 기존 또는 새 클러스터에 연결할 수 있습니다. EMR Studio에서 사전 구성 클러스터 양식을 사용하여 AWS Service Catalog를 통해 클러스터 생성 및 클러스터 이름, 인스턴스 수, 그리고 인스턴스 유형을 특정하는 클러스터 생성이라는 2가지 방법으로 EMR 클러스터를 열 수 있습니다.

예, WorkSpace를 열어 좌측의 EMR 클러스터 아이콘을 선택하고, Detach 버튼을 누른 다음, 클러스터 선택 드롭 다운 목록의 클러스터를 선택하고 Attach 버튼을 누릅니다.

EMR Studio에서 좌측의 Workspaces 탭을 선택하고 사용자 및 기타 사용자가 동일한 AWS 계정에서 생성한 모든 Workspaces를 볼 수 있습니다.

각 EMR Studio를 다른 AWS 서비스와 상호 운영하려면 권한이 필요합니다. EMR Studios에 필수 승인을 제공하기 위해 관리자는 EMR Studio 서비스 역할을 제공된 정책을 반영하여 생성해야 합니다. 또한 Studio 수준 권한을 정의하는 EMR Studio의 사용자 역할을 지정해야 합니다. AWS IAM Identity Center(AWS SSO의 후속 서비스)의 사용자 및 그룹을 EMR Studio에 추가할 때 사용자 또는 그룹에 세션 정책을 할당하여 세분화된 권한 제어를 적용할 수 있습니다. 세션 정책은 관리자가 여러 IAM 역할을 만들 필요 없이 사용자 권한을 세분화하는 데 도움이 됩니다. 세션 정책에 관한 자세한 내용은 AWS Identity and Access Management 사용 설명서에서 정책 및 권한을 참조하세요.

예. 고가용성(복수 마스터) 클러스터, Kerberized 클러스터 및 AWS Lake Formation 클러스터는 현재 지원하지 않습니다.

Amazon EMR Studio는 추가 비용 없이 제공됩니다. EMR Studio 사용 시 Amazon Simple Storage Service 스토리지 및 Amazon EMR 클러스터에 해당되는 요금이 부과됩니다. 요금 옵션 및 세부 정보는 Amazon EMR 요금을 참조하세요.

새 고객에게는 EMR Notebooks 대신, Amazon EMR Studio 사용을 권장합니다. EMR Notebooks는 Jupyter Notebook에 기반한 관리 환경으로, 데이터 사이언티스트, 분석가 및 개발자가 EMR 클러스터를 사용하여 데이터를 준비하고 시각화하며, 동료와 협업하고, 애플리케이션을 구축하며, 대화식 분석을 수행할 수 있습니다. 새 고객에는 EMR Studio 사용을 권장하고 있지만 호환성을 위해 EMR Notebooks도 지원됩니다.

EMR Notebooks를 사용하여 Apache Spark 애플리케이션을 구축하고 최소한의 노력으로 EMR 클러스터에서 인터랙티브 쿼리를 실행할 수 있습니다. 여러 사용자가 콘솔에서 직접 서버리스 노트북을 만들거나 기존의 공유 EMR 클러스터에 연결하거나 콘솔에서 직접 클러스터를 프로비저닝하고 즉시 Spark에서 실험을 시작할 수 있습니다. 노트북을 분리하고 다시 새 클러스터에 연결할 수도 있습니다. 노트북은 S3 버킷에 자동으로 저장되며, 콘솔에서 저장된 노트북을 검색하여 작업을 재개할 수 있습니다. EMR Notebooks는 Anaconda 리포지토리에 있는 라이브러리로 사전에 패키지되므로, 노트북 코드에서 이 라이브러리를 가져와 사용하며, 이를 사용해 데이터를 조작하고 결과를 시각화할 수 있습니다. 또한, EMR notebooks에는 통합된 Spark 모니터링 기능이 있어서, Spark 작업 진행을 모니터링하고 노트북 내에서 코드를 디버그할 수 있습니다.

EMR Notebooks를 시작하려면 EMR 콘솔을 열고 탐색 창에서 [Notebooks]를 선택합니다. 여기에서 [Create Notebook]을 선택하고 노트북 이름을 입력하고 EMR 클러스터를 선택하거나 바로 새로 만들어 사용할 노트북에 대한 서비스 역할을 제공하고 노트북 파일을 저장할 S3 버킷을 선택하고 [Create Notebook]을 클릭합니다. 노트북에서 [준비(Ready)] 상태를 표시하면 [열기(Open)]를 선택하여 노트북 편집기를 시작합니다.

EMR Notebooks는 EMR 릴리스 5.18.0 또는 이후 버전을 실행하는 EMR 클러스터에 연결할 수 있습니다.

EMR Notebooks는 추가 비용 없이 사용자에게 제공됩니다. 평상시대로 계정에 연결된 EMR 클러스터에 요금이 부과됩니다. https://aws.amazon.com/emr/pricing/에서 클러스터 요금에 관한 자세한 내용을 확인할 수 있습니다. 

Amazon EMR은 데이터를 클러스터로 가져오는 다양한 방법을 제공합니다. 가장 일반적인 방식은 데이터를 Amazon S3에 업로드하고 Amazon EMR 내장 기능을 사용하여 데이터를 클러스터에 로딩하는 것입니다. Hadoop의 분산 캐시 기능을 사용하여 파일을 배포 파일 시스템에서 로컬 파일 시스템으로 옮길 수 있습니다. 자세한 내용은 설명서를 참조하세요. 대신 데이터를 온프레미스에서 클라우드로 마이그레이션한다면 AWS의 Cloud Data Migration 서비스 중 하나를 사용할 수 있습니다.

Hadoop 시스템 로그와 사용자 로그는 클러스터를 생성할 때 지정한 Amazon S3 버킷에 보관됩니다. 영구 애플리케이션 UI는 오프 클러스터, Spark History Server, Tez UI 및 YARN 타임라인 서버 로그를 실행하며, 애플리케이션 종료 후 30일 간 사용할 수 있습니다.

현재 Amazon EMR은 Amazon S3로 로그를 이동할 때 이를 압축하지 않습니다.

Q: 로그를 압축합니까?

예. 마지막으로, AWS Direct Connect를 사용하여 AWS로 전용 네트워크 연결을 설정할 수 있습니다. 대용량 데이터를 가지고 있다면 AWS Import/Export를 사용하세요. 자세한 내용은 설명서를 참조하세요.

아니요. 클러스터별로 입력 데이터가 다르므로 작업 시간을 예측할 수 없습니다.

Amazon EMR 요금은 간단하고 예측 가능합니다. 사용한 모든 시간(초)에 대해 초당 요금을 지불하며 최소 요금은 1분입니다. AWS 요금 계산기를 사용하여 청구액을 추산할 수 있습니다. Amazon EC2를 포함하는 다른 Amazon Web Services를 사용 시 요금은 Amazon EMR과 별도로 청구됩니다.

Amazon EMR 청구는 클러스터가 단계를 시작할 준비를 하면 시작됩니다. Amazon EMR 청구는 클러스터 종료 요청 시 종료됩니다. Amazon EC2 청구 시작 및 종료 시점에 관한 자세한 내용은 Amazon EC2 청구 FAQ를 참조하세요.

결제 및 비용 관리 콘솔에서 사용을 추적할 수 있습니다.

AWS Management Console에서 각 클러스터에는 [정규화된 인스턴스 시간] 열이 있습니다. 이 열은 지금까지 해당 클러스터가 사용한 대략적인 컴퓨팅 시간을 표시하며, 시간은 가장 가까운 시간으로 올림 처리됩니다.

정규화된 인스턴스 시간은 m1.small 사용 1시간을 정규화된 컴퓨팅 시간 1시간으로 계산한 컴퓨팅 시간입니다. 설명서를 보고 인스턴스 패밀리 내 다른 크기의 목록과 시간 당 해당하는 표준화 팩터를 볼 수 있습니다.

예를 들어, 노드 10개의 r3.8xlarge 클러스터를 1시간 동안 실행하는 경우, 콘솔에 표시되는 정규화된 인스턴스 시간은 640시간(10(노드 수) x 64(정규화 인자) x 1(클러스터가 실행된 시간) = 640)이 됩니다.

이것은 추정치이며, 청구 목적으로 사용해서는 안 됩니다. 청구 대상 Amazon EMR 사용량은 Billing and Cost Management 콘솔을 참조하십시오.

예. Amazon EMR은 온디맨드, 스팟 및 예약 인스턴스를 원활하게 지원합니다. Amazon EC2 예약 인스턴스에 관한 자세한 내용은 여기를 클릭하십시오. Amazon EC2 스팟 인스턴스에 관한 자세한 내용을 보려면 여기를 클릭하세요. Amazon EC2 용량 예약에 관한 자세한 내용을 보려면 여기를 클릭하세요.

명시된 경우를 제외하면 요금에는 VAT 및 해당 판매세를 비롯한 관련 조세 공과가 포함되지 않습니다. 청구지 주소가 일본으로 되어 있는 고객의 경우, AWS 서비스 사용 시 일본 소비세의 적용을 받게 됩니다. 자세히 알아보세요. 

Amazon EMR은 두 개의 Amazon EC2 보안 그룹(마스터용 및 다른 클러스터 노드용)에서 인스턴스를 시작합니다. 마스터 보안 그룹에는 서비스와의 통신을 위해 열려 있는 포트가 있습니다. 또한, 시작할 때 지정한 키를 사용하여 인스턴스에 SSH 연결할 수 있도록 SSH 포트가 열려있습니다. 다른 노드는 다른 보안 그룹에서 시작합니다. 이 보안 그룹은 마스터 인스턴스와의 상호작용만 허용합니다. 기본적으로 두 보안 그룹 모두 다른 고객에게 속한 Amazon EC2 인스턴스와 같은 외부 소스가 액세스하지 못하도록 설정되어 있습니다. 둘 다 계정 내에 있는 보안 그룹이므로, 표준 EC2 도구나 대시보드를 사용하여 보안 그룹을 다시 구성할 수 있습니다. EC2 보안 그룹에 관한 자세한 내용은 여기를 클릭해 확인하세요. 또한, 규칙을 통해 예외 목록에 추가하지 않은 모든 포트에서 퍼블릭 액세스를 허용하는 경우 클러스터 생성을 방지하기 위해 사용하는 각 리전에서 Amazon EMR 퍼블릭 액세스 차단을 구성할 수 있습니다.

Amazon S3는 저장된 데이터를 무단 액세스로부터 보호하는 인증 메커니즘을 제공합니다. 데이터를 업로드하는 고객이 달리 명시하지 않는 한 해당 고객만 데이터에 액세스할 수 있습니다. Amazon EMR 고객은 보안 전송을 위해 Amazon S3에 HTTPS 프로토콜을 사용하여 데이터를 전송할 수도 있습니다. 또한 Amazon EMR은 Amazon S3와 Amazon EC2 간에 데이터를 전송 시 항상 HTTPS를 사용합니다. 보안을 강화하기 위해 고객은 일반적인 데이터 암호화 도구를 사용하여 Amazon S3에 업로드하기 전에 입력 데이터를 암호화할 수 있습니다. 이 경우 Amazon EMR이 Amazon S3에서 데이터를 가져올 때, 고객은 클러스터 시작 부분에 복호화 단계를 추가해야 합니다.

예. AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 로그 파일을 사용자에게 전달하는 웹 서비스입니다. CloudTrail에서 작성되는 AWS API 호출 내역을 통해 보안 분석, 리소스 변경 사항 추적 및 규정 준수 감사를 수행할 수 있습니다. AWS CloudTrail 세부 정보 페이지에서 CloudTrail에 대해 자세히 알아보고 CloudTrail의 AWS Management Console을 통해 활성화하십시오.

기본적으로 Amazon EMR 애플리케이션 프로세스는 다른 AWS 서비스를 호출할 때 EC2 인스턴스 프로파일을 사용합니다. 멀티 테넌트 클러스터의 경우, Amazon EMR은 Amazon S3 데이터에 대한 사용자 액세스를 관리할 수 있도록 세 가지 옵션을 제공합니다.

1. AWS Lake Formation과 통합을 통해 AWS Lake Formation에서 AWS Glue Data Catalog의 데이터베이스, 테이블 및 열 액세스에 대한 세분화된 권한 부여 정책을 정의하고 관리할 수 있습니다. 대화식 EMR Spark 워크로드에 대해 Amazon EMR Notebooks 및 Apache Zeppelin을 통해 제출되는 작업에 권한 부여 정책을 적용하고 감사 이벤트를 AWS CloudTrail로 전송할 수 있습니다. 이 통합을 활성화하면 Security Assertion Markup Language(SAML) 2.0과 호환되는 엔터프라이즈 자격 증명 시스템에서 EMR Notebooks 또는 Apache Zeppelin으로의 연동 Single Sign-On도 활성화할 수 있습니다.

2. Apache Ranger와의 기본 통합을 통해 신규 또는 기존 Apache Ranger 서버를 설정하여 Hive Metastore를 통해 Amazon S3 데이터의 데이터베이스, 테이블 및 열에 액세스하는 사용자에 대한 세분화된 권한 부여 정책을 정의하고 관리할 수 있습니다. Apache Ranger는 Hadoop 플랫폼 전체에 걸쳐 포괄적인 데이터 보안을 활성화, 모니터링 및 관리하는 오픈 소스 도구입니다.
   
   이 기본 통합을 사용하면 Apache Ranger 정책 관리 서버에서 세 가지 유형의 권한 부여 정책을 정의할 수 있습니다. Hive에 대한 테이블, 열 및 행 수준 권한 부여, Spark에 대한 테이블 및 열 수준 권한 부여 및 Amazon S3에 대한 접두사 및 객체 수준 권한 부여를 설정할 수 있습니다. Amazon EMR은 클러스터에 해당 Apache Ranger 플러그인을 자동으로 설치 및 구성합니다. 이러한 Ranger 플러그인은 승인 정책을 위해 정책 관리 서버와 동기화되고, 데이터 액세스 제어를 적용하고 감사 이벤트를 Amazon CloudWatch Logs로 전송합니다.

3. Amazon EMR User Role Mapper를 사용하면 AWS IAM 권한을 활용하여 AWS 리소스에 대한 액세스를 관리할 수 있습니다. 사용자(또는 그룹)과 사용자 지정 IAM 역할 간의 매핑을 생성할 수 있습니다. 사용자 또는 그룹은 사용자 지정 IAM 역할에 의해 허용되는 데이터에만 액세스할 수 있습니다. 현재 이 기능은 AWS Labs를 통해 제공됩니다.

Amazon EMR은 동일한 Amazon EC2 가용 영역에 있는 해당 클러스터에 대해 모든 노드를 시작합니다. 동일한 영역에서 클러스터를 실행하면 작업 흐름의 성능이 개선됩니다. 기본적으로 Amazon EMR은 클러스터를 실행하기 위해 가장 가용성이 높은 리소스가 있는 가용 영역을 선택합니다. 그러나 필요하다면 다른 가용 영역을 지정할 수 있습니다. 또한, 저렴한 요금의 온디맨드 인스턴스, 최적의 스팟 용량을 위해 할당을 최적화하는 옵션을 이용하거나 온디맨드 용량 예약을 사용할 수 있습니다.

Amazon EMR을 지원하는 AWS 리전 목록은 모든 AWS 글로벌 인프라가 나와 있는 AWS 리전 표를 참조하세요.

EMR은 로스앤젤레스 AWS 로컬 영역에서 클러스터 시작을 지원합니다. 미국 서부(오레곤) 리전에서 EMR을 사용하여 로스앤젤레스 AWS 로컬 영역과 연관된 서브넷에서 클러스터를 시작할 수 있습니다.

클러스터를 생성하는 경우, 일반적으로 데이터가 저장되어 있는 리전을 선택해야 합니다.

예. 가능합니다. 데이터를 한 리전에서 다른 리전으로 전송할 경우, 대역폭 요금이 부과됩니다. 대역폭 요금 정보는 EC2 세부 정보 페이지의 요금 섹션을 참조하십시오.

AWS GovCloud (US) 리전은 미국 정부 기관과 고객을 위해 설계되었습니다. 이 리전은 미국 ITAR 요구 사항을 준수합니다. GovCloud에서 EMR은 스팟 인스턴스 또는 enable-debugging 기능을 지원하지 않습니다. EMR 관리 콘솔은 아직 GovCloud에서 사용할 수 없습니다.

Amazon EMR on Amazon EC2

Amazon EMR on Amazon EKS

Amazon EMR on AWS Outposts

시작

관리

태그 지정

클러스터는 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 모음입니다. 클러스터의 각 인스턴스는 노드라고 하며, 노드 유형이라고 하는 클러스터 내 역할을 보유합니다. Amazon EMR은 각 노드 유형에 서로 다른 소프트웨어 구성 요소를 설치하며, Apache Hadoop과 같은 분산 애플리케이션에서 각 노드에 역할을 제공할 수도 있습니다. 모든 클러스터에는 ‘j-’로 시작되는 고유한 식별자가 있습니다.

Amazon EMR 클러스터의 노드는 다음과 같이 세 가지 유형이 있습니다.

1. 프라이머리 노드: 처리를 위해 다른 노드 사이에서 데이터 및 태스크 분산을 조정하도록 소프트웨어 구성 요소를 실행하여 클러스터를 관리하는 노드. 프라이머리 노드는 태스크 상태를 추적하고 클러스터 상태를 모니터링합니다. 각 클러스터에는 프라이머리 노드가 있으며, 프라이머리 노드에서만 단일 노드 클러스터를 생성할 수 있습니다.

2. 코어 노드: 클러스터의 Hadoop 분산 파일 시스템(HDFS)에서 태스크를 실행하고 데이터를 저장하는 소프트웨어 구성 요소를 포함하는 노드. 다중 노드 클러스터에는 하나 이상의 코어 노드가 있습니다.

3. 태스크 노드: HDFS에서 태스크만 실행하고 데이터를 저장하지 않는 소프트웨어 구성 요소를 포함하는 노드. 태스크 노드는 선택 사항입니다.

하나의 클러스터 단계는 사용자가 정의한 처리 단위로, 대체로 데이터를 처리하는 하나의 알고리즘에 매핑됩니다. 단계란 Java, Ruby, Perl, Python, PHP, R 또는 C++로 작성된 스트리밍 프로그램 또는 Java jar로서 구현된 하둡 MapReduce 애플리케이션입니다. 예를 들어, 단어가 문서에 등장하는 빈도를 계산하여 빈도수에 따라 정렬하여 출력하려고 할 때 첫 번째 단계는 MapReduce 애플리케이션에서 각 단어의 출현 횟수를 계수하는 것이며, 두 번째 단계는 MapReduce 애플리케이션에서 개수를 기준으로 첫 번째 단계의 출력 결과를 정렬하는 것입니다.

STARTING – EC2 인스턴스를 구성하는 것으로 클러스터가 시작됩니다.
BOOTSTRAPPING – 부트스트랩 작업이 클러스터에서 실행되고 있습니다.
RUNNING – 클러스터가 현재 실행 중인 단계입니다.
WAITING – 클러스터가 현재 활성 상태이나, 실행할 단계가 없습니다.
TERMINATING – 클러스터를 종료하는 중입니다.
TERMINATED – 클러스터가 오류 없이 종료되었습니다.
TERMINATED_WITH_ERRORS – 클러스터 종료 시 오류가 발생했습니다.

PENDING – 실행 대기 상태인 단계입니다.

RUNNING – 현재 실행 중인 단계입니다.

COMPLETED – 단계가 성공적으로 완료되었습니다.

CANCELLED – 이전 단계가 실패했거나 클러스터가 실행되기 전에 중단되어 해당 단계가 실행 전에 취소되었습니다.

FAILED – 단계를 수행하는 동안 실패했습니다.

간단한 클러스터 요청 양식을 작성하면 AWS Management Console을 통해 클러스터를 시작할 수 있습니다. 요청 양식에서 클러스터의 이름, 입력 데이터의 Amazon S3 내 위치, 처리 애플리케이션, 원하는 데이터 출력 위치, 사용하려는 Amazon EC2 인스턴스 수와 유형을 지정합니다. 필요에 따라 클러스터 로그 파일과 실행 중인 클러스터에 로그인하기 위한 SSH 키를 저장할 위치를 지정할 수도 있습니다. 또는 RunJobFlow API를 사용하거나 명령줄 도구에서 'create' 명령을 사용하여 클러스터를 시작할 수 있습니다. EMR Studio를 통해 클러스터를 실행하려면 위의 EMR Studio 섹션을 참조하세요.

AWS Management Console에서 클러스터를 선택하고 [종료] 버튼을 클릭하여 언제든지 클러스터를 종료할 수 있습니다. 또는 TerminateJobFlows API를 사용할 수 있습니다. 실행 중인 클러스터를 종료하면 Amazon S3에 보관되지 않은 결과를 잃게 되고, 모든 Amazon EC2 인스턴스가 종료됩니다.

원하는 만큼 얼마든지 클러스터를 시작할 수 있습니다. 시작 시 모든 클러스터에 대한 인스턴스 수는 20개로 제한됩니다. 더 많은 인스턴스가 필요한 경우, Amazon EC2 인스턴스 요청 양식을 작성합니다. Amazon EC2 한도를 늘리면 새로운 한도가 Amazon EMR 클러스터에 자동으로 적용됩니다.

입력 데이터와 데이터 처리 애플리케이션을 Amazon S3에 업로드할 수 있습니다. 그러면 Amazon EMR은 지정한 수만큼 Amazon EC2 인스턴스를 시작합니다. 서비스는 클러스터를 실행하면서, S3 URI 계획을 사용하여 Amazon S3의 입력 데이터를 실행 중인 Amazon EC2 인스턴스로 가져옵니다. 클러스터가 완료되면 Amazon EMR은 출력 데이터를 Amazon S3로 전달합니다. 그러면 Amazon S3에서 출력 데이터를 검색하거나 이 데이터를 다른 클러스터에서 입력 데이터로 사용할 수 있습니다.

Amazon EMR은 Hadoop 데이터 처리 엔진을 사용하여 MapReduce 프로그래밍 모델에 구현된 컴퓨팅을 수행합니다. 고객은 map()과 reduce() 함수에 대한 알고리즘을 실행합니다. 서비스는 하나의 단일 마스터와 여러 개의 다른 노드로 구성된, 고객이 지정한 수의 Amazon EC2 인스턴스를 시작합니다. Amazon EMR은 이 인스턴스에서 하둡 소프트웨어를 실행합니다. 마스터 노드는 입력 데이터를 블록으로 분할하여 블록 처리를 다른 노드에 분배합니다. 그러면 각 노드는 할당된 데이터에서 map 함수를 실행하고 중간 데이터를 생성합니다. 중간 데이터는 정렬되고 분할되어 reducer 함수를 노드에서 로컬로 적용하는 프로세스로 전송됩니다. 마지막으로, reducer 작업의 출력이 파일에 수집됩니다. 하나의 ‘클러스터’가 이러한 일련의 MapReduce 단계를 포함할 수 있습니다.

인스턴스 유형 및 리전별 요금에 관한 자세한 내용은 EMR 요금 페이지를 참조하세요.

클러스터를 실행하는 데 걸리는 시간은 클러스터의 유형, 입력 데이터의 양, 클러스터에서 사용하기로 선택한 Amazon EC2 인스턴스의 수와 유형 등 여러 가지 요인에 따라 달라집니다.

예. 마스터 노드가 3개인 EMR 클러스터(5.23 버전 이상)를 시작할 수 있으며, YARN Resource Manager, HDFS Name Node, Spark, Hive, Ganglia 같은 고가용성 애플리케이션을 지원할 수 있습니다. Amazon EMR은 기본 마스터 노드에 장애가 발생하거나 Resource Manager 또는 Name Node 같은 중요 프로세스에 장애가 발생하는 경우 자동으로 예비 마스터 노드로 장애 조치됩니다. 덕분에 마스터 노드가 잠재적 단일 장애 지점이 아니므로 장기 실행 EMR 클러스터를 중단 없이 실행할 수 있습니다. 장애 발생 시 Amazon EMR은 장애가 발생한 마스터 노드를 동일한 구성과 부트스트랩 작업을 통해 새 마스터 노드로 자동 교체합니다. 

예. Amazon EMR은 노드 장애에 대한 내결함성이 있으며, 노드에 장애가 발생해도 작업을 계속 실행합니다. 또한, Amazon EMR은 코어 노드에 장애가 발생하면 새로운 코드를 프로비저닝합니다. 하지만 해당 클러스터의 모든 노드가 손실되는 경우에는 Amazon EMR에서 노드를 교체하지 않습니다.

예. SSH로 클러스터 노드에 연결하고 이곳에서 직접 하둡 명령을 실행할 수 있습니다. 특정 노드에 SSH 연결해야 할 경우, 먼저 마스터 노드에 SSH 연결한 후 해당 노드에 SSH 연결해야 합니다.

부트스트랩 작업은 클러스터를 실행하기 전에 사용자에게 사용자 정의 설치 프로그램을 실행하는 방법을 제공하는 Amazon EMR의 기능입니다. 부트스트랩 작업은 클러스터를 실행하기 전에 소프트웨어를 설치하거나 인스턴스를 구성하는 데 사용할 수 있습니다. 부트스트랩 작업에 관한 자세한 내용은 EMR의 개발자 안내서에서 참조할 수 있습니다.

Bash, Perl, Python, Ruby, C++ 또는 Java와 같이 클러스터 인스턴스에 이미 설치된 언어로 부트스트랩 작업 스크립트를 작성할 수 있습니다. 사전 정의된 부트스트랩 작업도 사용할 수 있습니다. 스크립트가 일단 작성되면 Amazon S3로 업로드하고 클러스터를 시작할 때 해당 위치를 참조하도록 해야 합니다. 부트스트랩 작업의 사용 방법에 대한 자세한 내용은 개발자 안내서를 참조하십시오.

EMR의 기본 Hadoop 구성은 대부분의 작업에 적합합니다. 그러나 클러스터의 특정 메모리와 처리 요구 사항에 따라 설정을 조정해야 할 수 있습니다. 예를 들어, 클러스터 작업이 메모리를 많이 사용하는 경우, 코어당 작업 수 및 작업 추적 힙 크기를 줄일 수 있습니다. 이 경우, 사전 정의된 부트스트랩 작업을 사용하여 시작 시 클러스터를 구성합니다. 구성에 관한 자세한 내용과 사용 지침은 개발자 안내서의 메모리 집약적 부트스트랩 작업 구성 섹션을 참조하세요. 클러스터 설정을 원하는 값으로 사용자 정의할 수 있는 사전 정의된 부트스트랩 작업도 추가로 사용할 수 있습니다. 사용 지침은 개발자 안내서의 Hadoop 부트스트랩 작업 구성 섹션을 참조하세요.

예. 노드에는 (1) 하둡 분산 파일 시스템(HDFS)을 사용하여 영구 데이터를 호스팅하고 하둡 작업을 실행하는 코어 노드와 (2) 하둡 작업을 실행만 작업 노드, 두 가지 노드가 있습니다. 클러스터를 실행하는 동안 코어 노드 수를 늘리고 작업 노드 수를 늘리거나 줄일 수 있습니다. 이때 API, Java SDK 또는 명령줄 클라이언트를 사용하여 실행합니다. 실행 중인 클러스터의 크기를 변경하는 방법에 관한 자세한 내용은 개발자 안내서의 실행 중인 클러스터 크기 조정 섹션을 참조하세요. 또한 EMR Managed Scaling을 사용할 수도 있습니다.

코어 노드는 HDFS의 영구 데이터를 호스팅하므로 삭제할 수 없습니다. 코어 노드는 클러스터가 완료될 때까지 필요한 용량만큼 예약해야 합니다. 작업 노드는 추가하거나 삭제할 수 있습니다. 또한 HDFS를 포함하지 않으므로, 일시적으로만 필요한 용량에 적합합니다. 스팟 인스턴스 상에서 작업 인스턴스 플릿을 실행하여 비용을 최소화하면서 용량을 늘릴 수 있습니다.

실행 중인 클러스터에서 노드 수를 변경해야 하는 상황은 여러 가지가 있습니다. 클러스터의 속도가 예상보다 느린 경우 또는 시간 요구 사항이 변경된 경우, 코어 노드의 수를 늘려 클러스터의 성능을 향상할 수 있습니다. 클러스터 단계에 따라 필요한 용량이 다른 경우는 적은 수의 코어 노드로 시작하여 클러스터의 다양한 용량 요구 사항에 따라 작업 노드의 수를 늘리거나 줄일 수 있습니다. 또한 EMR Managed Scaling을 사용할 수도 있습니다.

예. 사전 정의된 단계를 워크플로에 포함함으로써 필요한 용량이 서로 다른 단계 간에 클러스터의 크기를 자동으로 조정하도록 할 수 있습니다. 모든 단계는 차례대로 실행되기 때문에 이렇게 하면 주어진 클러스터 단계를 실행할 노드 수를 설정할 수 있습니다.

EMR CLI 내의 모든 IAM 사용자가 볼 수 있는 새 클러스터를 생성하려면 클러스터를 생성할 때 --visible-to-all-users 플래그를 추가합니다. 예: elastic-mapreduce --create --visible-to-all-users. Management Console에서 Create Cluster Wizard를 실행하고 [Advanced Options] 창에서 [Visible to all IAM Users]를 선택하면 됩니다.

기존 클러스터를 모든 IAM 사용자가 볼 수 있도록 하려면 EMR CLI를 사용해야 합니다. --set-visible-to-all-users를 사용하고 클러스터 식별자를 지정합니다. 예: elastic-mapreduce --set-visible-to-all-users true --jobflow j-xxxxxxx. 해당 클러스터를 생성한 사용자만 이 작업을 수행할 수 있습니다.

자세한 내용은 EMR 개발자 안내서의 사용자 권한 구성 섹션을 참조하세요.

활성화된 Amazon EMR 클러스터에 태그를 추가할 수 있습니다. Amazon EMR 클러스터는 Amazon EC2 인스턴스로 구성되어 있으며, Amazon EMR 클러스터에 추가된 태그는 해당 클러스터에 있는 각각의 활성화된 Amazon EC2 인스턴스에 전파됩니다. 활성화된 클러스터의 일부였으나 이미 종료된 클러스터 또는 Amazon EC2 인스턴스의 경우에는 태그를 추가, 편집 또는 제거할 수 없습니다.

아니요. Amazon EMR은 태그에 의한 리소스 기반 권한을 지원하지 않습니다. 하지만 Amazon EC2 인스턴스에 전파된 태그는 일반적인 Amazon EC2 태그처럼 작동한다는 점을 명심해야 합니다. 따라서 Amazon EMR에서 전파된 태그가 IAM 정책의 조건에 부합할 경우에는 태그에 Amazon EC2의 IAM 정책이 적용됩니다.

Amazon EMR 클러스터에는 최대 10개의 태그를 추가할 수 있습니다.

예. Amazon EMR은 클러스터에 추가된 태그를 해당 클러스터의 기본 EC2 인스턴스에 전파합니다. Amazon EMR 클러스터에 태그를 추가하면 관련 Amazon EC2 인스턴스에도 나타납니다. 반대로 Amazon EMR 클러스터에서 태그를 제거할 경우, 해당 태그는 관련 Amazon EC2 인스턴스에서도 제거됩니다. 하지만 Amazon EC2에 대한 IAM 정책을 사용하고 있으며 Amazon EMR의 태그 지정 기능을 사용할 계획이라면 Amazon EC2 태그 지정 API CreateTags 및 DeleteTags 사용에 대한 권한이 부여되어야 합니다.

여기에서 AWS 결제 보고서에 사용할 태그를 선택하세요. 그런 다음, 같은 태그 키 값을 가진 리소스를 기준으로 결제 정보를 정리하면 모든 리소스 비용의 합을 볼 수 있습니다.

Amazon EMR 클러스터와 연관된 Amazon EC2 인스턴스에는 아래와 같이 2개의 시스템 태그가 존재합니다.

• aws:elasticmapreduce:instance-group-role=CORE

  • Key = instance-group role ; Value = [CORE or TASK];

• aws:elasticmapreduce:job-flow-id=j-12345678

  • Key = job-flow-id ; Value = [JobFlowID]

예. 태그는 Amazon EMR 클러스터의 일부인 Amazon EC2 인스턴스에서 바로 추가 또는 제거할 수 있습니다. 하지만 연결된 Amazon EC2 인스턴스에 직접 변경한 내용은 Amazon EMR의 태그 지정 시스템과 동기화되지 않으므로 이 방법을 권장하지는 않습니다. 연결된 Amazon EC2 인스턴스와 클러스터 모두에 올바른 태그가 지정될 수 있도록 Amazon EMR 클러스터의 태그는 Amazon EMR 콘솔, CLI 또는 API에서 추가하거나 제거하는 것이 좋습니다.

Amazon EMR Serverless는 Amazon EMR의 새로운 배포 옵션으로, 이 옵션을 사용하면 클러스터 구성, 관리 및 크기 조정 없이 Apache Spark 및 Apache Hive와 같은 빅 데이터 프레임워크를 실행할 수 있습니다.

데이터 엔지니어, 분석가 및 사이언티스트는 EMR Serverless를 사용하여 Apache Spark 및 Apache Hive와 같은 오픈 소스 프레임워크에서 애플리케이션을 구축할 수 있습니다. 이러한 프레임워크를 사용하여 데이터를 변환하고 대화형 SQL 쿼리와 기계 학습 워크로드를 실행할 수 있습니다.

EMR Studio, AWS CLI 또는 API를 사용하여 작업을 제출하고 작업 상태를 추적하며 EMR Serverless에서 실행할 데이터 파이프라인을 구축할 수 있습니다. EMR Studio에서 시작하려면 AWS Management Console에 로그인하고 분석(Analytics) 범주에서 Amazon EMR로 이동한 다음, Amazon EMR Serverless를 선택합니다. AWS Management Console의 지침에 따라 분석(Analytics) 범주에서 Amazon EMR로 이동하고 Amazon EMR Serverless를 선택합니다. 시작 안내서의 지침에 따라 EMR Serverless 애플리케이션을 생성하고 작업을 제출합니다. CLI를 사용하여 애플리케이션을 시작하고 작업을 제출하려면 AWS CLI에서 애플리케이션 상호 작용 페이지를 참조하세요. GitHub 리포지토리에서 EMR Serverless 예제와 샘플 코드를 찾아볼 수도 있습니다.

EMR Serverless는 현재 Apache Spark와 Apache Hive 엔진을 지원합니다. Apache Presto 또는 Apache Flink와 같은 추가 프레임워크에 대한 지원을 받고 싶다면 emr-feedback@amazon.com으로 요청을 보내주세요.

EMR Serverless는 아시아 태평양(뭄바이), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 캐나다(중부), 유럽(프랑크푸르트), 유럽(아일랜드), 유럽(런던), 유럽(파리), 유럽(스톡홀름), 남아메리카(상파울루), 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(캘리포니아 북부) 및 미국 서부(오레곤)의 AWS 리전에서 제공됩니다.

Amazon EMR은 EC2 기반 클러스터, EKS 클러스터, Outposts 또는 Serverless에서 애플리케이션을 실행할 수 있는 옵션을 제공합니다. EC2 기반 EMR 클러스터는 애플리케이션 실행에 대한 최대한의 제어와 유연성을 필요로 하는 고객에게 적합합니다. EC2 기반 EMR 클러스터를 사용하면 애플리케이션별 성능 요구 사항을 충족하는 EC2 인스턴스 유형을 선택하고, Linux AMI를 사용자 지정하고, EC2 인스턴스 구성을 사용자 지정하고, 오픈 소스 프레임워크를 사용자 지정 및 확장하며, 추가 사용자 지정 소프트웨어를 클러스터 인스턴스에 설치할 수 있습니다. EKS 기반 Amazon EMR은 EKS를 기반으로 표준화하여 애플리케이션 전체의 클러스터를 관리하거나 동일한 클러스터에서 다른 버전의 오픈 소스 프레임워크를 사용하려는 고객에게 적합합니다. AWS Outposts 기반 Amazon EMR은 EMR을 데이터 센터와 더 가까운 위치의 Outpost 내에서 실행하려는 고객을 위한 옵션입니다. EMR Serverless는 클러스터 관리 및 운영 없이 오픈 소스 프레임워크를 사용하여 애플리케이션을 실행하는 것을 선호하는 고객에게 적합합니다.

EMR Serverless는 EMR 릴리스 레이블 6.6 이상을 지원합니다. EMR Serverless는 다른 EMR 배포 옵션에서 제공되는 것과 동일한 성능 최적화 EMR 런타임을 제공하며 표준 오픈 소스 프레임워크의 API와 100% 호환됩니다.

BilledResourcesUtilization은 사전 초기화된 용량이 작업에 사용된 기간만 고려하며 해당 용량의 유휴 시간은 고려하지 않습니다.

작업자의 런타임 지속 시간이 60초 미만인 경우 BilledResourceUtilization은 이를 60초로 계산하고 TotalResourceUtilization은 이를 초 단위로 반올림합니다. 또한 BilledResourceUtilization에서는 20GB의 무료 스토리지가 계산에서 제외됩니다.

Amazon EMR Serverless에서는 오픈 소스 분석 프레임워크를 사용하는 하나 이상의 EMR Serverless 애플리케이션을 생성할 수 있습니다. 애플리케이션을 생성하려면 다음 속성을 지정해야 합니다. 1) 사용하려는 오픈 소스 프레임워크 버전에 대한 Amazon EMR 릴리스 버전 2) Apache Spark 3.1 또는 Apache Hive 3.0 등 애플리케이션에서 사용하려는 특정 분석 엔진 애플리케이션을 생성한 후에는 데이터 처리 작업을 실행하거나 애플리케이션에 대한 대화형 요청을 시작할 수 있습니다.

EMR Serverless 애플리케이션은 내부에서 작업자를 사용하여 워크로드를 실행합니다. 작업이 제출되면 EMR Serverless가 작업에 필요한 리소스를 계산하고 작업자를 예약합니다. EMR Serverless는 워크로드를 태스크로 분할하고, 오픈 소스 프레임워크로 작업자를 프로비저닝 및 설정한 다음, 작업이 완료되면 작업자를 해제합니다. EMR Serverless는 작업의 모든 수준에서 필요한 워크로드와 병렬 처리에 따라 작업자를 자동으로 확장하거나 축소합니다. 따라서 워크로드를 실행하는 데 필요한 작업자 수를 예측할 필요가 없습니다. 이 작업자의 기본 크기는 애플리케이션 유형과 Amazon EMR 릴리스 버전에 따라 다릅니다. 작업 실행을 예약할 때 이 크기를 재정의할 수 있습니다.

EMR Serverless를 사용하는 경우, 최소 및 최대 동시 작업자 수와 작업자의 vCPU 및 메모리 구성을 지정할 수 있습니다. 또한 애플리케이션의 리소스에 대한 최대 용량 제한을 설정하여 비용을 제어할 수도 있습니다.

애플리케이션을 여러 개 생성하는 것이 좋은 경우를 열거하면 다음과 같습니다.

1. 서로 다른 오픈 소스 프레임워크 사용

2. 여러 사용 사례에 서로 다른 버전의 오픈 소스 프레임워크 사용

3. 한 버전에서 다른 버전으로 업그레이드할 때 A/B 테스트 수행

4. 테스트 및 프로덕션 시나리오를 위한 개별 논리 환경 유지

5. 비용 제어 및 사용량 추적이 독립되어 있는 여러 팀에 개별 논리 환경 제공

6. 서로 다른 사업부 애플리케이션 분리

예. EMR Studio 또는 update-application API/CLI 호출을 사용하여 초기 용량, 최대 용량 제한 및 네트워크 구성과 같은 애플리케이션 속성을 수정할 수 있습니다.

작업자가 사전에 초기화되지 않은 EMR Serverless 애플리케이션은 필요한 리소스를 결정하고 프로비저닝하는 데 최대 120초가 걸립니다. EMR Serverless는 애플리케이션을 위한 대기 중인 작업자 풀을 생성하여 작업자를 초기화된 상태로 유지하고 몇 초 안에 응답할 수 있게 하는 선택적 기능을 제공합니다. 이 기능을 사전 초기화된 용량이라고 하며 애플리케이션의 initial-capacity 파라미터를 설정하여 각 애플리케이션에 대해 구성할 수 있습니다.

사전 초기화된 용량을 사용하면 작업을 즉시 시작할 수 있으므로 시간에 민감한 작업을 구현하는 데 적합합니다. EMR Serverless 애플리케이션을 시작할 때 사전 초기화하려는 작업자 수를 지정할 수 있습니다. 그런 다음 사용자가 작업을 제출하면 사전 초기화된 작업자를 사용하여 작업을 즉시 시작할 수 있습니다. 사전 초기화에 선택된 작업자보다 많은 작업자가 작업에 필요한 경우 EMR Serverless가 자동으로 작업자를 추가합니다(지정된 최대 동시 작업자 제한까지). 작업이 완료되면 EMR Serverless가 지정된 사전 초기화 작업자 수로 돌아가 해당 수를 다시 유지합니다. 15분간 유휴 상태인 작업자는 자동으로 종료됩니다. 애플리케이션의 기본 유휴 제한 시간은 updateApplication API 또는 EMR Studio를 사용하여 변경할 수 있습니다.

EMR Studio, SDK/CLI 또는 Apache Airflow 커넥터를 사용하여 EMR Serverless 작업을 제출하고 관리할 수 있습니다.

PySpark의 경우 virtualenv를 사용하여 Python 종속성을 패키지로 만들고 작업 실행 중에 작업자에서 종속성을 사용할 수 있도록 하는 --archives 옵션을 사용하여 아카이브 파일을 전달할 수 있습니다. Scala 또는 Java의 경우, 종속성을 jar 패키지로 만들고 Amazon S3에 업로드한 다음 EMR Serverless 작업 실행에서 --jars 또는 --packages 옵션을 사용하여 전달하면 됩니다.

EMR Serverless는 Java 기반 UDF를 지원합니다. 이 UDF를 jar 패키지로 만들고 S3에 업로드한 다음, Spark 또는 HiveQL 스크립트에서 사용할 수 있습니다.

자세한 내용은 지원되는 작업자 구성을 참조하세요.

예. EMR Studio를 사용하거나 cancelJobRun API/CLI를 호출하여 실행 중인 EMR Serverless 작업을 취소할 수 있습니다.

작업 제출 시 적절한 스토리지 옵션을 선택하여 EMR Serverless의 작업자에게 별도의 스토리지를 추가할 수 있습니다. EMR Serverless는 두 가지 임시 스토리지 옵션을 제공합니다.

• 표준 스토리지: 이 옵션을 선택하면 기본적으로 작업자당 20GB의 임시 스토리지가 제공됩니다. 작업 제출 시 이를 사용자 정의하여 작업자당 20GB에서 최대 200GB까지 스토리지 용량을 늘릴 수 있습니다.

• 셔플에 최적화된 디스크 스토리지: 이 옵션을 선택하면 작업자당 최대 2TB의 임시 스토리지가 제공되며, 셔플을 많이 사용하는 워크로드에 맞게 최적화할 수 있습니다.

EMR Serverless 코드 샘플은 GitHub 리포지토리에서 찾을 수 있습니다.

EMR Serverless는 온디맨드 작업자와 사전 초기화된 작업자라는 두 가지 옵션을 작업자에게 제공합니다.

온디맨드 작업자는 작업에 필요한 경우에만 시작되고 작업이 완료되면 자동으로 릴리스됩니다. 이렇게 하면 사용한 리소스에 대해서만 비용을 지불하고 유휴 용량에 따른 추가 비용을 피할 수 있습니다. 온디맨드 작업자는 워크로드에 따라 애플리케이션을 확장하거나 축소하므로 리소스의 오버 또는 언더프로비저닝에 대해 걱정할 필요가 없습니다.

사전 초기화된 작업자는 작업자가 몇 초 만에 응답할 준비가 되도록 할 수 있는 선택적 기능입니다. 이렇게 하면 애플리케이션을 위한 작업자 웜 풀을 효과적으로 생성할 수 있습니다. 이를 통해 작업을 즉시 시작할 수 있으므로 반복적인 애플리케이션과 시간에 민감한 작업에 이상적입니다.

네. 여러 AZ에서 EMR Serverless 애플리케이션을 구성할 수 있습니다. 여러 AZ를 설정하는 프로세스는 사용하는 작업자 유형에 따라 달라집니다.

온디맨드 작업자만 사용하는 경우 EMR Serverless는 기본적으로 여러 AZ에 작업을 분산하지만 각 작업은 하나의 AZ에서만 실행됩니다. 서브넷을 AZ에 연결하여 사용할 AZ를 선택할 수 있습니다. AZ에 장애가 발생하면 EMR 서버리스는 자동으로 다른 정상 AZ에서 작업을 실행합니다.

사전 초기화된 작업자를 사용하는 경우 EMR 서버리스는 지정한 서브넷에서 정상 AZ를 선택합니다. 채용공고는 신청을 중단할 때까지 해당 AZ에서 제출됩니다. AZ가 손상되면 애플리케이션을 다시 시작하여 다른 정상 AZ로 전환할 수 있습니다.

EMR Serverless는 VPC 연결 없이 구성된 경우 동일한 리전의 특정 AWS 리소스에만 액세스할 수 있습니다. 고려 사항을 참조하세요. 다른 리전 또는 AWS 외 리소스의 AWS 리소스에 액세스하려면 AWS 리소스의 퍼블릭 엔드포인트로 라우팅할 VPC 액세스와 NAT 게이트웨이를 설정해야 합니다.

Amazon EMR Serverless 애플리케이션과 작업 수준 지표는 30초마다 Amazon CloudWatch에 게시됩니다.

실행 중이거나 완료된 EMR Serverless 작업을 EMR Studio에서 선택한 다음, Spark UI 또는 Tez UI 버튼을 클릭하여 작업을 시작할 수 있습니다.

예. 자체 VPC의 리소스에 액세스하도록 Amazon EMR Serverless 애플리케이션을 구성할 수 있습니다. 자세한 내용은 설명서에서 VPC 액세스 구성 섹션을 참조하세요. 

각 EMR Serverless 애플리케이션은 다른 애플리케이션과 격리되어 보안 Amazon VPC에서 실행됩니다.

Amazon EMR Serverless는 계정당 최대 동시 vCPU라고 하는 새로운 서비스 할당량을 도입했습니다. 이 vCPU 기반 할당량을 사용하면 애플리케이션이 리전 내에서 스케일 업할 수 있는 최대 집계 vCPU 수를 설정할 수 있습니다. 기존 애플리케이션 수준의 작업자 기반 할당량(최대 활성 작업자 수)은 2023년 2월 1일에 지원이 종료됩니다.

AWS Service Quotas 관리 콘솔에서 할당량을 보고 관리하며 할당량 증가를 요청할 수 있습니다. 자세한 내용은 Service Quotas 사용 설명서에서 ‘할당량 증가 요청’을 참조하세요.

EMR Serverless에서는 두 가지 비용 제어 수단을 제공합니다. 1. 계정당 최대 동시 vCPU 할당량은 계정의 리전 내 모든 EMR Serverless 애플리케이션에 적용됩니다. 2. maximumCapacity 파라미터는 특정 EMR Serverless 애플리케이션의 vCPU를 제한합니다. 리전 내 모든 애플리케이션에서 사용하는 최대 동시 vCPU를 제한하려면 vCPU 기반 할당량을 사용하고, 특정 애플리케이션에서 사용하는 리소스를 제한하려면 maximumCapacity 속성을 사용해야 합니다. 예를 들어, 5개의 애플리케이션이 있고 각 애플리케이션이 최대 1,000개의 vCPU로 스케일 업이 가능한 경우, 각 애플리케이션에 대해 maximumCapacity 속성을 1,000개의 vCPU로 설정하고 계정 수준 vCPU 기반 할당량은 5 * 1,000 = 5,000개의 vCPU로 구성합니다.

계정 수준 vCPU 할당량을 초과하는 경우, EMR Serverless는 새 용량의 프로비저닝을 중지합니다. 할당량을 초과한 후에 새 애플리케이션을 생성하려고 하면 다음 오류 메시지가 나타나며 애플리케이션 생성에 실패합니다. "Application failed to create as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console.(계정당 최대 동시 vCPU 서비스 할당량을 초과했으므로 애플리케이션을 생성하지 못합니다. AWS Service Quotas 콘솔을 사용하여 서비스 할당량을 보고 관리할 수 있습니다.)" 할당량을 초과한 후 새 작업을 제출하면 다음 오류 메시지가 나타나며 작업에 실패합니다. "Job failed as you have exceeded the maximum concurrent vCPUs per account service quota. You can view and manage your service quota using AWS Service Quotas console.(계정당 최대 동시 vCPU 서비스 할당량을 초과했으므로 작업에 실패합니다. AWS Service Quotas 콘솔을 사용하여 서비스 할당량을 보고 관리할 수 있습니다.)" 자세한 내용은 설명서를 참조하세요.

Amazon EMR Serverless는 3가지 면에서 비용을 절감하는 데 도움이 될 수 있습니다. 첫째, 클러스터 관리, 보호 및 확장으로 인한 운영 간접비가 없습니다. 둘째, EMR Serverless는 작업 처리의 각 단계에서 자동으로 작업자를 확장하고 필요하지 않을 때 자동으로 축소합니다. 작업자 실행이 시작될 때부터 중지될 때까지 사용된 총 vCPU, 메모리 및 스토리지 리소스에 대해 요금이 부과되며 최소 1분 단위로 가장 가까운 초로 반올림됩니다. 예를 들어 작업을 처리하는 처음 10분 동안에는 작업자 10개가 필요하고 다음 5분간은 작업자 50개가 필요할 수 있습니다. 이 경우 세분화된 자동 크기 조정을 통해 10분간 작업자 10개와 5분간 작업자 50개에 대한 요금만 발생합니다. 따라서 미활용 리소스에 대한 요금을 지불하지 않아도 됩니다. 셋째, EMR Serverless에는 Apache Spark 및 Apache Hive와 Presto를 위한 Amazon EMR 성능 최적화 런타임이 포함됩니다. Amazon EMR 런타임은 API와 호환되며 표준 오픈 소스 분석 엔진보다 최대 2배 이상 더 빠르기 때문에 작업이 더 빠르게 실행되며 컴퓨팅 비용은 줄어듭니다.

현재 EC2 기반 EMR 클러스터의 사용률에 따라 달라집니다. EC2 온디맨드 인스턴스를 사용하여 EMR 클러스터를 실행하는 경우 현재 클러스터 사용률이 70% 미만이면 EMR Serverless의 총 소유 비용(TCO)이 더 낮습니다. EC2 Savings Plans를 사용하는 경우 현재 클러스터 사용률이 50% 미만이면 EMR Serverless의 TCO가 더 낮습니다. EC2 스팟 인스턴스를 사용하는 경우, EC2 기반 Amazon EMR 및 EKS 기반 Amazon EMR의 비용 효율성은 계속해서 증가합니다.

예. 작업이 완료된 후 작업자를 중지하지 않으면 사전 초기화된 작업자에 대한 요금이 발생합니다.

PySpark의 경우 virtualenv를 사용하여 Python 종속성을 패키지로 만들고 작업 실행 중에 작업자에서 종속성을 사용할 수 있도록 하는 --archives 옵션을 사용하여 아카이브 파일을 전달할 수 있습니다. Scala 또는 Java의 경우, 종속성을 jar 패키지로 만들고 Amazon S3에 업로드한 다음 EMR Serverless 작업 실행에서 --jars 또는 --packages 옵션을 사용하여 전달하면 됩니다.

PySpark의 경우 virtualenv를 사용하여 Python 종속성을 패키지로 만들고 작업 실행 중에 작업자에서 종속성을 사용할 수 있도록 하는 --archives 옵션을 사용하여 아카이브 파일을 전달할 수 있습니다. Scala 또는 Java의 경우, 종속성을 jar 패키지로 만들고 Amazon S3에 업로드한 다음 EMR Serverless 작업 실행에서 --jars 또는 --packages 옵션을 사용하여 전달하면 됩니다.

Amazon EMR Serverless는 Apache Spark 워크로드에 대한 로컬 스토리지 프로비저닝을 제거하여 데이터 처리 비용을 최대 20% 줄이고 디스크 용량 제약으로 인한 작업 실패를 방지합니다. EMR Serverless는 인프라 결정을 요구하지 않고도 셔플과 같은 중간 데이터 작업을 자동으로 처리합니다. 이 최적화를 통해 Spark의 동적 리소스 할당(DRA)은 중간 데이터를 컴퓨팅 작업자와는 독립적으로 자동 처리하므로 임시 로컬 데이터를 보존하기 위해 실행 상태를 유지하는 대신, 처리에 더 이상 필요하지 않은 순간에 컴퓨팅 리소스를 릴리스할 수 있습니다. 이 자동 개선 기능은 대규모 집계, 조인 및 정렬이 많은 분석과 같은 광범위한 변환 워크로드에 더 큰 탄력성을 제공하므로 로컬에 저장된 데이터의 제약을 받지 않고 작업 단계 전반에 걸쳐 컴퓨팅 리소스를 동적으로 확장 및 축소할 수 있습니다.

EMR 버전 7.12 이상을 사용할 때는 간단히 옵트인하면 됩니다. Spark 작업은 별도의 구성 없이도 최적화된 중간 데이터 처리의 이점을 자동으로 활용할 수 있습니다. Spark Live UI를 사용하여 실시간으로 작업을 모니터링할 수 있으며, Spark 기록 서버에서 완료된 작업에 대한 자세한 셔플 및 단계별 유출 지표를 볼 수 있습니다.

중간 데이터는 작업이 실행되는 동안에만 저장되며 작업이 완료되면 자동으로 삭제되므로 작업 수명 주기 이후에도 데이터가 지속되지는 않습니다.

이 자동 최적화는 다중 보호 계층을 통해 EMR Serverless와 동일한 엔터프라이즈급 보안 표준을 유지합니다. 모든 데이터는 EMR Serverless 애플리케이션과 중간 데이터 처리 계층 간에 전송되는 동안 그리고 임시 저장되는 동안에도 AWS에서 관리하는 암호화 키를 사용하여 암호화됩니다. 이 기능은 네임스페이스 내의 작업별 식별자 아래에 중간 데이터를 저장하여 특정 작업에서만 데이터에 액세스할 수 있도록 함으로써 엄격한 데이터 격리 및 액세스 제어를 적용합니다. 기존 EMR 서버리스 액세스 제어 및 권한은 계속 적용되므로 테이블 또는 Lake Formation 정책에 따라 관리되는 데이터는 항상 완벽하게 보호됩니다. 보안 강화를 위해 EMR Serverless는 작업의 실행 역할이 아닌 서비스 소유 역할을 사용하여 중간 데이터 처리를 처리하므로 권한 에스컬레이션이나 계정 간 무단 액세스를 방지합니다. 보안 검사에 실패하는 경우, 데이터를 항상 보호할 수 있도록 작업이 즉시 중지됩니다.