기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 작업 실행
애플리케이션을 프로비저닝한 후 애플리케이션에 작업을 제출합니다. 이 섹션에서는를 사용하여 이러한 작업을 AWS CLI 실행하는 방법을 다룹니다. 또한 이 섹션에서는 EMR Serverless에서 사용할 수 있는 각 애플리케이션 유형의 기본값도 식별합니다.
**Topics**
+ [
# 작업 실행 상태
](job-states.md)
+ [
# 유예 기간이 있는 EMR Serverless 작업 실행 취소
](job-cancellation-grace-period.md)
+ [
# EMR Studio 콘솔에서 작업 실행
](jobs-studio.md)
+ [
# 에서 작업 실행 AWS CLI
](jobs-cli.md)
+ [
# 실행 IAM 정책.
](jobs-cli-execution.md)
+ [
# 셔플 최적화 디스크 사용
](jobs-shuffle-optimized-disks.md)
+ [
# Amazon EMR Serverless에 서버리스 스토리지 사용
](jobs-serverless-storage.md)
+ [
# 지속적으로 스트리밍되는 데이터를 처리하기 위한 스트리밍 작업
](jobs-streaming.md)
+ [
# EMR Serverless 작업을 실행하는 경우 Spark 구성 사용
](jobs-spark.md)
+ [
# EMR Serverless 작업을 실행하는 경우 Hive 구성 사용
](jobs-hive.md)
+ [
# EMR Serverless 작업 복원력
](jobs-resiliency.md)
+ [
# EMR Serverless에 대한 메타스토어 구성
](metastore-config.md)
+ [
# EMR Serverless에서 다른 AWS 계정의 S3 데이터 액세스
](jobs-s3-access.md)
+ [
# EMR Serverless에서 오류 해결
](jobs-troubleshoot.md)
+ [
# 작업 수준 비용 할당 활성화
](jobs-job-level-cost-allocation.md)
# 작업 실행 상태
Amazon EMR Serverless 작업 대기열에 작업을 제출하면 작업이 `SUBMITTED` 상태로 전환됩니다. 작업 상태는 `FAILED`, `SUCCESS` 또는 `CANCELLING`에 도달할 때까지 `SUBMITTED`에서 `RUNNING` 상태를 통과합니다.
다음은 가능한 작업 실행 상태입니다.
****
| State | 설명 |
| --- | --- |
| 제출됨 | EMR Serverless에 작업 실행을 제출할 때 초기 작업 상태. 애플리케이션에 작업이 예약되기를 기다립니다. EMR Serverless는 우선순위를 지정하고 작업 실행을 예약합니다. |
| 대기됨 | 작업 실행은 애플리케이션 수준 작업 실행 동시성이 완전히 점유되면 이 상태로 대기합니다. 동시성에 대한 자세한 내용은 [EMR Serverless 애플리케이션의 작업 동시성 및 대기열 입력](applications-concurrency-queuing.md) 섹션을 참조하세요. |
| 보류중 | 스케줄러는 애플리케이션 실행의 우선순위를 지정하고 일정을 예약하기 위해 작업 실행을 평가하고 있습니다. |
| 예약됨 | EMR Serverless는 애플리케이션에 대한 작업 실행을 예약했으며 작업을 실행할 리소스를 할당하고 있습니다. |
| 실행 중 | EMR Serverless는 작업에 처음 필요한 리소스를 할당했으며, 작업이 애플리케이션에서 실행 중입니다. Spark 애플리케이션에서 이는 Spark 드라이버 프로세스가 running 상태임을 의미합니다. |
| 실패 | EMR Serverless가 애플리케이션에 작업 실행을 제출하지 못했거나 실패한 상태로 완료되었습니다. 이 작업 실패에 대한 자세한 내용은 StateDetails 섹션을 참조하세요. |
| Success | 작업 실행이 완료되었습니다. |
| 취소 중 | CancelJobRun API에서 작업 실행 취소를 요청했거나 작업 실행 제한 시간이 초과되었습니다. EMR Serverless는 애플리케이션에서 작업을 취소하고 리소스를 해제하려고 합니다. |
| 취소됨 | 작업 실행이 취소되었으며 사용된 리소스가 해제되었습니다. |
# 유예 기간이 있는 EMR Serverless 작업 실행 취소
데이터 처리 시스템에서 갑작스러운 종료가 발생하면 자원 낭비, 불완전한 작업 수행 및 잠재적인 데이터 불일치가 발생할 수 있습니다. Amazon EMR Serverless를 사용하면 작업 실행을 취소할 때 유예 기간을 지정할 수 있습니다. 이 기능을 사용하면 작업 종료 전에 진행 중인 작업을 적절하게 정리 및 완료할 수 있습니다.
작업 실행을 취소할 때 최종적으로 종료하기 전에 작업이 정리 작업을 수행할 수 있는 `shutdownGracePeriodInSeconds` 파라미터를 사용하여 유예 기간(초)을 지정합니다. 동작과 기본 설정은 배치 작업과 스트리밍 작업마다 매우 다릅니다.
## 배치 작업의 유예 기간
배치 작업의 경우 EMR Serverless를 사용하면 유예 기간 동안 실행되는 사용자 지정 정리 작업을 구현할 수 있습니다. 이러한 정리 작업을 애플리케이션 코드의 JVM 종료 후크의 일부로 등록할 수 있습니다.
**기본 동작**
종료의 기본 동작은 유예 기간이 없는 종료입니다. 이는 다음 두 작업으로 구성됩니다.
+ 즉시 종료
+ 리소스가 즉시 릴리스됩니다.
**구성 옵션**
정상 종료되는 설정을 지정할 수 있습니다.
+ 종료 유예 기간의 유효한 범위: 15\$11,800초(선택 사항)
+ 즉시 종료(유예 기간 없음): 0초
### 정상 종료 활성화
배치 작업의 정상 종료를 구현하려면 다음 단계를 따르세요.
1. 사용자 지정 종료 논리가 포함된 애플리케이션 코드에 종료 후크를 추가합니다.
------
#### [ Example in Scala ]
```
import org.apache.hadoop.util.ShutdownHookManager
// Register shutdown hook with priority (second argument)
// Higher priority hooks run first
ShutdownHookManager.get().addShutdownHook(() => {
logger.info("Performing cleanup operations...")
}, 100)
```
[ShutdownHookManager](https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/api/org/apache/hadoop/util/ShutdownHookManager.html) 사용
------
#### [ Example in PySpark ]
```
import atexit
def cleanup():
# Your cleanup logic here
print("Performing cleanup operations...")
# Register the cleanup function
atexit.register(cleanup)
```
------
1. 작업을 취소할 때 이전에 추가된 후크가 실행될 수 있도록 유예 기간을 지정합니다.
**예제**
```
# Default (immediate termination)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID
# With 5-minute grace period
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 300
```
## 스트리밍 작업의 유예 기간
계산에 외부 데이터 소스에서 읽거나 쓰는 작업이 포함되는 Spark Structured Streaming에서는 갑작스러운 종료로 인해 원치 않는 결과가 발생할 수 있습니다. 스트리밍 작업은 데이터를 마이크로 배치 단위로 처리하며, 이러한 작업을 중간에 중단할 경우 후속 시도에서 중복 처리가 발생할 수 있습니다. 이러한 상황은 이전 마이크로 배치의 최신 체크포인트가 기록되지 않았을 때 발생하며, 이로 인해 스트리밍 작업이 재시작될 때 동일한 데이터가 다시 처리됩니다. 이러한 중복 처리는 컴퓨팅 리소스를 낭비할 뿐만 아니라 비즈니스 운영에도 영향을 미칠 수 있으므로 갑작스러운 시스템 중단을 방지하는 것이 매우 중요합니다.
EMR Serverless는 스트리밍 쿼리 리스너를 통한 정상 종료 를 기본적으로 지원합니다. 이 작업을 수행하면 작업 종료 전에 진행 중인 마이크로 배치를 적절하게 완료할 수 있습니다. 이 서비스는 스트리밍 애플리케이션에 대한 마이크로 배치 간의 정상 종료를 자동으로 관리하여 현재 마이크로 배치가 처리를 완료하고 체크포인트가 올바르게 기록되며 종료 프로세스 중에 새로운 데이터를 수집하지 않고 스트리밍 컨텍스트가 완전히 종료되도록 합니다.
**기본 동작**
+ 기본적으로 120초 유예 기간이 활성화되어 있습니다.
+ 내장 스트리밍 쿼리 리스너가 정상 종료를 관리합니다.
**구성 옵션**
+ 종료 유예 기간의 유효한 범위: 15\$11,800초(선택 사항)
+ 즉시 종료: 0초
### 정상 종료 활성화
스트리밍 작업에 대한 정상 종료를 구현하려면:
작업을 취소할 때 진행 중인 마이크로 배치가 완료될 때까지 기다리도록 유예 기간을 지정합니다.
**예제**
```
# Default graceful shutdown (120 seconds)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID
# Custom grace period (e.g. 300 seconds)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 300
# Immediate Termination
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 0
```
### 사용자 지정 종료 후크 추가(선택 사항)
EMR Serverless는 기본적으로 내장된 스트리밍 쿼리 리스너를 통해 정상 종료를 관리하지만, 선택적으로 개별 스트리밍 쿼리에 대해 사용자 지정 종료 논리를 구현할 수 있습니다. EMR Serverless는 정상 종료 리스너를 우선순위 60으로 등록(ShutdownHookManager 사용)합니다. 우선순위가 높은 후크가 먼저 실행되므로 우선순위가 60보다 높은 사용자 지정 정리 작업을 등록하여 EMR Serverless 종료 프로세스가 시작되기 전에 실행되도록 할 수 있습니다.
사용자 지정 후크를 추가하려면 애플리케이션 코드에 종료 후크를 추가하는 방법을 보여주는 이 주제의 첫 번째 예제를 참조하세요. 여기서 우선순위는 100이고 이는 60보다 높은 우선순위입니다. 따라서 이 종료 후크가 먼저 실행됩니다.
**참고**
사용자 지정 종료 후크는 선택 사항이며, EMR Serverless에서 자동으로 처리하는 정상 종료 기능에는 필요하지 않습니다.
### 유예 기간 요금 및 배치 지속 시간
유예 기간(120초)의 기본값을 사용하는 경우:
+ 배치 지속 시간이 120초 미만인 경우 배치 완료에 필요한 실제 시간에 대해서만 요금이 부과됩니다.
+ 배치 지속 시간이 120초를 초과하면 최대 유예 기간(120초)에 대한 요금이 청구되지만, 강제로 종료되므로 쿼리가 정상적으로 종료되지 않을 수 있습니다.
비용을 최적화하고 정상 종료를 보장하려면:
+ 배치 지속 시간이 120초를 초과하는 경우: 배치 기간과 일치하도록 유예 기간을 늘리는 것이 좋습니다.
+ 배치 지속 시간이 120초 미만인 경우: 실제 처리 시간에 대해서만 요금이 부과되므로 유예 기간을 조정할 필요가 없습니다.
## 고려 사항
### 유예 기간 동작
+ 유예 기간은 등록된 종료 후크가 완료될 때까지 시간을 제공합니다.
+ 유예 기간보다 훨씬 앞선 경우에도 종료 후크가 완료되는 즉시 작업이 종료됩니다.
+ 정리 작업이 유예 기간을 초과하면 작업이 강제로 종료됩니다.
### 서비스 동작
+ 유예 기간 종료는 실행 중 상태의 작업에만 사용할 수 있습니다.
+ CANCELLING 상태 중의 후속 취소 요청은 무시됩니다.
+ 내부 서비스 오류로 인해 EMR Serverless가 유예 기간 종료를 시작하지 못하는 경우:
+ 서비스는 최대 2분 동안 재시도를 수행합니다.
+ 재시도가 실패하면 작업이 강제로 종료됩니다.
### 결제
작업은 유예 기간 동안 소요된 시간을 포함하여 작업이 완전히 종료될 때까지 사용된 컴퓨팅 리소스에 대해 요금이 청구됩니다.
# EMR Studio 콘솔에서 작업 실행
EMR Serverless 애플리케이션에 작업 실행을 제출하고 EMR Studio 콘솔에서 작업을 볼 수 있습니다. EMR Studio 콘솔에서 EMR Serverless 애플리케이션을 생성하거나 탐색하려면 [콘솔에서 시작하기](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console)의 지침을 수행합니다.
## 작업 제출
**작업 제출** 페이지에서 다음과 같이 EMR Serverless 애플리케이션에 작업을 제출할 수 있습니다.
------
#### [ Spark ]
1. **이름** 필드에 작업 실행 이름을 입력합니다.
1. **런타임 역할** 필드에 EMR Serverless 애플리케이션이 작업 실행을 위해 수임할 수 있는 IAM 역할의 이름을 입력합니다. 런타임 역할에 대한 자세한 내용은 [Amazon EMR Serverless에 대한 작업 런타임 역할](security-iam-runtime-role.md) 섹션을 참조하세요.
1. **스크립트 위치** 필드에 실행하려는 스크립트 또는 JAR에 대한 Amazon S3 위치를 입력합니다. Spark 작업의 경우 스크립트는 Python(`.py`) 파일 또는 JAR(`.jar`) 파일일 수 있습니다.
1. 스크립트 위치가 JAR 파일인 경우 **기본 클래스** 필드에 작업의 진입점인 클래스 이름을 입력합니다.
1. (선택 사항) 나머지 필드의 값을 입력합니다.
+ **스크립트 인수** - 기본 JAR 또는 Python 스크립트에 전달할 인수를 입력합니다. 코드에서 이러한 파라미터를 읽습니다. 배열의 각 인수를 쉼표로 분리합니다.
+ **Spark 속성** - Spark 속성 섹션을 확장하고 이 필드에 Spark 구성 파라미터를 입력합니다.
**참고**
Spark 드라이버 및 실행기 크기를 지정하는 경우 메모리 오버헤드를 고려합니다. `spark.driver.memoryOverhead` 및 `spark.executor.memoryOverhead` 속성에서 메모리 오버헤드 값을 지정합니다. 메모리 오버헤드의 기본값은 컨테이너 메모리의 10%(최소 384MB)입니다. 실행기 메모리 및 메모리 오버헤드를 합한 값이 작업자 메모리를 초과할 수 없습니다. 예를 들어, 30GB 작업자의 최대 `spark.executor.memory`는 27GB여야 합니다.
+ **작업 구성** - 이 필드에서 작업 구성을 지정합니다. 이러한 작업 구성을 사용하여 애플리케이션에 대한 구성 객체를 재정의할 수 있습니다.
+ **추가 설정** - AWS Glue Data Catalog를 메타스토어로 활성화 또는 비활성화하고 애플리케이션 로그 설정을 수정합니다. 메타스토어 구성에 대해 자세히 알아보려면 [EMR Serverless에 대한 메타스토어 구성](metastore-config.md) 섹션을 참조하세요. 애플리케이션 로깅 옵션에 대해 자세히 알아보려면 [로그 저장](logging.md)섹션을 참조하세요.
+ **태그** - 애플리케이션에 사용자 지정 태그를 할당합니다.
1. **작업 제출**을 선택합니다.
------
#### [ Hive ]
1. **이름** 필드에 작업 실행 이름을 입력합니다.
1. **런타임 역할** 필드에 EMR Serverless 애플리케이션이 작업 실행을 위해 수임할 수 있는 IAM 역할의 이름을 입력합니다.
1. **스크립트 위치** 필드에 실행하려는 스크립트 또는 JAR에 대한 Amazon S3 위치를 입력합니다. Hive 작업의 경우 스크립트는 Hive(`.sql`) 파일이어야 합니다.
1. (선택 사항) 나머지 필드의 값을 입력합니다.
+ **초기화 스크립트 위치** - Hive 스크립트가 실행되기 전에 테이블을 초기화하는 스크립트의 위치를 입력합니다.
+ **Hive 속성** - Hive 속성 섹션을 확장하고 이 필드에 Hive 구성 파라미터를 입력합니다.
+ **작업 구성** - 작업 구성을 지정합니다. 이러한 작업 구성을 사용하여 애플리케이션에 대한 구성 객체를 재정의할 수 있습니다. Hive 작업의 경우 `hive.exec.scratchdir` 및 `hive.metastore.warehouse.dir`은 `hive-site` 구성에 필요한 속성입니다.
```
{
"applicationConfiguration": [
{
"classification": "hive-site",
"configurations": [],
"properties": {
"hive.exec.scratchdir": "s3://DOC-EXAMPLE_BUCKET/hive/scratch",
"hive.metastore.warehouse.dir": "s3://DOC-EXAMPLE_BUCKET/hive/warehouse"
}
}
],
"monitoringConfiguration": {}
}
```
+ **추가 설정** - AWS Glue 데이터 카탈로그를 메타스토어로 활성화 또는 비활성화하고 애플리케이션 로그 설정을 수정합니다. 메타스토어 구성에 대해 자세히 알아보려면 [EMR Serverless에 대한 메타스토어 구성](metastore-config.md) 섹션을 참조하세요. 애플리케이션 로깅 옵션에 대해 자세히 알아보려면 [로그 저장](logging.md)섹션을 참조하세요.
+ **태그** - 애플리케이션에 사용자 지정 태그를 할당합니다.
1. **작업 제출**을 선택합니다.
------
## 작업 실행 액세스
애플리케이션 **세부 정보** 페이지의 **작업 실행** 탭에서 작업 실행을 보고 작업 실행에 대해 다음 작업을 수행할 수 있습니다.
**작업 취소** - `RUNNING` 상태인 작업 실행을 취소하려면 이 옵션을 선택합니다. 작업 실행 전환에 대해 자세히 알아보려면 [작업 실행 상태](job-states.md) 섹션을 참조하세요.
**작업 복제** - 이전 작업 실행을 복제하고 다시 제출하려면 이 옵션을 선택합니다.
# 에서 작업 실행 AWS CLI
AWS CLI에서 개별 작업을 생성, 설명 및 삭제할 수 있습니다. 한 눈에 볼 수 있도록 모든 작업을 나열할 수도 있습니다.
새 작업을 제출하려면 `start-job-run`을 사용합니다. 작업별 속성과 함께 실행하려는 애플리케이션의 ID를 제공합니다. Spark 예제는 [EMR Serverless 작업을 실행하는 경우 Spark 구성 사용](jobs-spark.md) 섹션을 참조하세요. Hive 예제는 [EMR Serverless 작업을 실행하는 경우 Hive 구성 사용](jobs-hive.md) 섹션을 참조하세요. 이 명령은 `application-id`, ARN 및 새 `job-id`를 반환합니다.
각 작업 실행에는 제한 시간이 설정되어 있습니다. 작업 실행이 이 기간을 초과하면 EMR Serverless에서 자동으로 취소합니다. 기본 제한 시간은 12시간입니다. 작업 실행을 시작하는 경우 작업 요구 사항을 충족하는 값으로 이 제한 시간 설정을 구성할 수 있습니다. `executionTimeoutMinutes` 속성을 사용하여 값을 구성합니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--execution-timeout-minutes 15 \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/scripts/create_table.sql",
"parameters": "--hiveconf hive.exec.scratchdir=s3://amzn-s3-demo-bucket/hive/scratch --hiveconf hive.metastore.warehouse.dir=s3://amzn-s3-demo-bucket/hive/warehouse"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.client.cores": "2",
"hive.client.memory": "4GIB"
}
}]
}'
```
작업을 설명하려면 `get-job-run`을 사용합니다. 이 명령은 새 작업에 대한 작업별 구성과 설정 용량을 반환합니다.
```
aws emr-serverless get-job-run \
--job-run-id job-id \
--application-id application-id
```
작업을 나열하려면 `list-job-runs`를 사용합니다. 이 명령은 작업 유형, 상태 및 기타 개략적인 수준의 속성을 포함하는 약식 속성 세트를 반환합니다. 전체 작업을 보지 않으려는 경우 보려는 최대 작업 수를 50개까지 지정할 수 있습니다. 다음 예제에서는 두 개의 마지막 작업 실행을 보도록 지정합니다.
```
aws emr-serverless list-job-runs \
--max-results 2 \
--application-id application-id
```
작업을 취소하려면 `cancel-job-run`을 사용합니다. 취소하려는 작업의 `application-id` 및 `job-id`를 제공합니다.
```
aws emr-serverless cancel-job-run \
--job-run-id job-id \
--application-id application-id
```
에서 작업을 실행하는 방법에 대한 자세한 내용은 [EMR Serverless API 참조](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html)를 AWS CLI참조하세요.
# 실행 IAM 정책.
EMR Serverless에서 작업 실행을 제출할 때 실행 역할 외에도 실행 IAM 정책을 지정할 수 있습니다. 작업 실행에서 가정하는 결과 권한은 실행 역할과 지정된 실행 IAM 정책의 권한 교차입니다.
## 시작하기
실행 IAM 정책을 사용하는 단계:
`emr-serverless` 애플리케이션을 생성하거나 기존 애플리케이션을 사용한 다음, 다음 aws cli를 실행하여 인라인 IAM 정책으로 작업 실행을 시작합니다.
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options \
--execution-iam-policy '{"policy": "inline-policy"}'
```
## CLI 명령 예제
다음 정책이 시스템의 `policy.json` 파일에 저장되어 있는 경우:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
],
"Sid": "AllowS3Getobject"
}
]
}
```
------
그런 다음 다음 AWS CLI 명령을 사용하여이 정책으로 작업을 시작할 수 있습니다.
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policy": '$(jq -c '. | @json' policy.json)'
}'
```
AWS 및 고객 관리형 정책을 모두 사용하여 ARNs.
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policyArns": [
"arn:aws:iam::aws:policy/AmazonS3FullAccess",
"arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
]
}'
```
동일한 요청에서 인라인 IAM 정책과 관리형 정책 ARN을 모두 지정할 수 있습니다.
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policy": '$(jq -c '. | @json' policy.json)',
"policyArns": [
"arn:aws:iam::aws:policy/AmazonS3FullAccess",
"arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
]
}'
```
## 중요 정보
+ `execution-role-policy`에서 `policy` 필드의 최대 길이는 2048자입니다.
+ `execution-iam-policy`의 `policy` 필드에 지정된 인라인 IAM 정책 문자열은 json 문자열 표준을 준수해야 하며, 이전 예제와 같이 이스케이프된 줄 바꿈과 따옴표가 없어야 합니다.
+ 최대 10개의 관리형 정책 ARNs 목록을 `execution-iam-policy`의 `policyArns` 필드에 값으로 지정할 수 있습니다.
+ 관리ARNs은 유효한 AWS 또는 고객 관리형 정책 ARN 목록이어야 합니다. 고객 관리형 정책 ARN을 지정하면 정책은 EMR-S JobRun의 동일한 AWS 계정에 속해야 합니다.
+ 인라인 IAM 정책과 관리형 정책을 모두 사용하는 경우, 인라인 및 관리형 정책에 사용하는 일반 텍스트는 합쳐서 2,048자를 초과할 수 없습니다.
+ JobRun에서 가정한 결과 권한은 실행 역할과 지정된 실행 IAM 정책의 권한 교차입니다.
## 정책 교차
작업 실행에서 가정하는 결과 권한은 실행 역할과 지정된 실행 IAM 정책의 권한 교차입니다. 즉, JobRun이 작동하려면 두 위치 모두에서 필요한 권한을 지정합니다. 그러나 인라인 정책에서 업데이트하거나 덮어쓰지 않을 권한에 대해 추가적인 포괄 허용 문을 지정할 수 있습니다.
예제
다음과 같은 실행 IAM 역할 정책이 제공된 경우:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:us-west-2:123456789012:log-group::log-stream"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/MyCompany1table"
],
"Sid": "AllowDYNAMODBDescribetable"
}
]
}
```
------
그리고 다음 인라인 IAM 정책도 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket/tenant1",
"arn:aws:s3:::my-test-bucket/tenant1/*"
],
"Sid": "AllowS3Getobject"
},
{
"Effect": "Allow",
"Action": [
"logs:*",
"dynamodb:*"
],
"Resource": [
"*"
],
"Sid": "AllowLOGS"
}
]
}
```
------
JobRun에서 가정한 결과 권한은 다음과 같습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket/tenant1",
"arn:aws:s3:::my-test-bucket/tenant1/*"
],
"Sid": "AllowS3Getobject"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:us-west-2:123456789012:log-group::log-stream"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/MyCompany1table"
],
"Sid": "AllowDYNAMODBDescribetable"
}
]
}
```
------
# 셔플 최적화 디스크 사용
Amazon EMR 릴리스 7.1.0 이상을 사용하면 Apache Spark 또는 Hive 작업을 실행할 때 셔플 최적화 디스크를 사용하여 I/O 집약적 워크로드의 성능을 개선할 수 있습니다. 셔플 최적화 디스크는 표준 디스크에 비해 더 높은 IOPS(초당 I/O 작업 수)를 제공하여 셔플 작업 중에 데이터 이동을 더 빠르게 하고 지연 시간을 줄일 수 있습니다. 셔플 최적화 디스크를 사용하면 워커당 최대 2TB의 디스크 크기를 연결할 수 있으므로 워크로드 요구 사항에 적합한 용량을 구성할 수 있습니다.
## 주요 이점
셔플 최적화 디스크는 다음과 같은 이점을 제공합니다.
+ **높은 IOPS 성능** - 셔플 최적화 디스크는 표준 디스크보다 높은 IOPS를 제공하므로 Spark 및 Hive 작업과 기타 셔플 집약적 워크로드 중에 보다 효율적이고 빠른 데이터 셔플링이 가능합니다.
+ **더 큰 디스크 크기** - 셔플 최적화 디스크는 워커당 20GB\$12TB의 디스크 크기를 지원하므로 워크로드에 따라 적절한 용량을 선택할 수 있습니다.
## 시작하기
워크플로에서 셔플 최적화 디스크를 사용하려면 다음 단계를 참조하세요.
------
#### [ Spark ]
1. 다음 명령을 사용하여 EMR Serverless 릴리스 7.1.0 애플리케이션을 생성합니다.
```
aws emr-serverless create-application \
--type "SPARK" \
--name my-application-name \
--release-label emr-7.1.0 \
--region
```
1. `spark.emr-serverless.driver.disk.type` 및/또는 `spark.emr-serverless.executor.disk.type` 파라미터를 포함하거나 셔플 최적화 디스크로 실행하도록 Spark 작업을 구성합니다. 사용 사례에 따라 하나 또는 두 파라미터를 모두 사용할 수 있습니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi
--conf spark.executor.cores=4
--conf spark.executor.memory=20g
--conf spark.driver.cores=4
--conf spark.driver.memory=8g
--conf spark.executor.instances=1
--conf spark.emr-serverless.executor.disk.type=shuffle_optimized"
}
}'
```
자세한 내용은 [Spark 작업 속성](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults)을 참조하세요.
------
#### [ Hive ]
1. 다음 명령을 사용하여 EMR Serverless 릴리스 7.1.0 애플리케이션을 생성합니다.
```
aws emr-serverless create-application \
--type "HIVE" \
--name my-application-name \
--release-label emr-7.1.0 \
--region
```
1. `hive.driver.disk.type` 및/또는 `hive.tez.disk.type` 파라미터를 포함하거나 셔플 최적화 디스크로 실행하도록 Hive 작업을 구성합니다. 사용 사례에 따라 하나 또는 두 파라미터를 모두 사용할 수 있습니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "s3:///emr-serverless-hive/query/hive-query.ql",
"parameters": "--hiveconf hive.log.explain.output=false"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.exec.scratchdir": "s3:///emr-serverless-hive/hive/scratch",
"hive.metastore.warehouse.dir": "s3:///emr-serverless-hive/hive/warehouse",
"hive.driver.cores": "2",
"hive.driver.memory": "4g",
"hive.tez.container.size": "4096",
"hive.tez.cpu.vcores": "1",
"hive.driver.disk.type": "shuffle_optimized",
"hive.tez.disk.type": "shuffle_optimized"
}
}]
}'
```
자세한 내용은 [Hive 작업 속성](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-hive.html#hive-defaults)을 참조하세요.
------
**사전 초기화된 용량으로 애플리케이션 구성**
Amazon EMR 릴리스 7.1.0을 기반으로 애플리케이션을 생성하려면 다음 예제를 참조하세요. 이러한 애플리케이션에는 다음과 같은 속성이 있습니다.
+ 사전 초기화된 Spark 드라이버 5개(각각 vCPU 2개, 메모리 4GB, 50GB의 셔플 최적화 디스크 포함).
+ 사전 초기화된 실행기 50개(각각 vCPU 4개, 메모리 8GB, 500GB의 셔플 최적화 디스크 포함).
이 애플리케이션에서 Spark 작업을 실행하면 먼저 사전 초기화된 작업자를 소비한 다음, 온디맨드 작업자를 최대 용량인 400vCPU 및 1,024GB의 메모리로 확장합니다. 선택적으로 `DRIVER` 또는 `EXECUTOR`의 용량을 생략할 수 있습니다.
------
#### [ Spark ]
```
aws emr-serverless create-application \
--type "SPARK" \
--name \
--release-label emr-7.1.0 \
--initial-capacity '{
"DRIVER": {
"workerCount": 5,
"workerConfiguration": {
"cpu": "2vCPU",
"memory": "4GB",
"disk": "50GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
},
"EXECUTOR": {
"workerCount": 50,
"workerConfiguration": {
"cpu": "4vCPU",
"memory": "8GB",
"disk": "500GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
}
}' \
--maximum-capacity '{
"cpu": "400vCPU",
"memory": "1024GB"
}'
```
------
#### [ Hive ]
```
aws emr-serverless create-application \
--type "HIVE" \
--name \
--release-label emr-7.1.0 \
--initial-capacity '{
"DRIVER": {
"workerCount": 5,
"workerConfiguration": {
"cpu": "2vCPU",
"memory": "4GB",
"disk": "50GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
},
"EXECUTOR": {
"workerCount": 50,
"workerConfiguration": {
"cpu": "4vCPU",
"memory": "8GB",
"disk": "500GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
}
}' \
--maximum-capacity '{
"cpu": "400vCPU",
"memory": "1024GB"
}'
```
------
# Amazon EMR Serverless에 서버리스 스토리지 사용
Amazon EMR 릴리스 7.12 이상에서는 Apache Spark 작업을 실행할 때 서버리스 스토리지를 사용하여 로컬 디스크 프로비저닝을 제거하고 데이터 처리 비용을 줄이며 디스크 용량 제약으로 인한 작업 실패를 방지합니다. 서버리스 스토리지는 용량 구성 없이 작업에 대한 셔플, 디스크 유출 및 디스크 캐싱 작업을 자동으로 처리하고 중간 데이터를 무료로 저장합니다. Amazon EMR Serverless는 워크로드 수요에 따라 자동으로 확장되는 완전 관리형 서버리스 스토리지에 중간 데이터를 저장하고 Spark가 유휴 시 즉시 컴퓨팅 작업자를 해제하여 컴퓨팅 비용을 절감할 수 있습니다.
## 주요 이점
EMR Serverless용 서버리스 스토리지는 다음과 같은 이점을 제공합니다.
+ **제로 구성 스토리지 -** 서버리스 스토리지를 사용하면 각 애플리케이션 또는 작업에 대해 로컬 디스크 유형과 크기를 구성할 필요가 없습니다. EMR Serverless는 용량 계획 없이 중간 데이터 작업을 자동으로 관리합니다.
+ **자동 조정을 통해 작업 실패 방지** - 스토리지 용량은 워크로드 수요에 따라 자동으로 조정되므로 디스크 용량 부족으로 인한 작업 실패를 방지합니다.
+ **데이터 처리 비용 절감** - 서버리스 스토리지는 두 가지 메커니즘을 통해 처리 비용을 절감합니다. 첫째, 중간 데이터 스토리지는 무료로 제공되며 컴퓨팅 및 메모리 리소스에 대해서만 비용을 지불하면 됩니다. 둘째, Spark의 동적 리소스 할당과 분리된 스토리지를 통해 Spark는 유휴 시 로컬 디스크에 중간 데이터를 보존하는 대신 작업자를 즉시 해제할 수 있습니다. 이렇게 하면 Spark 단계당 스케일 아웃 및 스케일 인이 더 빨라지므로 이후 단계에서 초기 단계보다 더 적은 작업자가 필요한 작업의 컴퓨팅 비용이 절감됩니다.
+ **작업 수준 격리를 통한 암호화된 스토리지 -** 모든 중간 데이터는 전송 중 및 저장 시 엄격한 작업 수준 격리를 통해 암호화됩니다.
+ **세분화된 액세스 제어 지원** - 서버리스 스토리지는 AWS Lake Formation 통합을 통해 세분화된 액세스 제어를 지원합니다.
## 시작하기
Spark 워크플로에서 EMR Serverless용 서버리스 스토리지를 사용하려면 다음 단계를 참조하세요.
1. **EMR Serverless 애플리케이션 생성**
spark-defaults 분류에서 spark 속성을 `spark.aws.serverlessStorage.enabled` **true**로 설정하여 서버리스 스토리지가 활성화된 EMR Serverless 릴리스 7.12(또는 이상) 애플리케이션을 생성합니다.
```
aws emr-serverless create-application \
--type "SPARK" \
--name my-application \
--release-label emr-7.12.0 \
--runtime-configuration '[{
"classification": "spark-defaults",
"properties": {
"spark.aws.serverlessStorage.enabled": "true"
}
}]' \
--region
```
1. **Spark 작업 시작**
애플리케이션에서 작업 실행을 시작합니다. EMR Serverless용 서버리스 스토리지는 작업의 셔플과 같은 중간 데이터 작업을 자동으로 처리합니다.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3:///script.py",
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=20g
--conf spark.driver.cores=4
--conf spark.driver.memory=8g
--conf spark.executor.instances=10"
}
}'
```
애플리케이션 수준에서 활성화되지 않은 경우에도 작업 수준에서 EMR Serverless용 서버리스 스토리지를 활성화할 수 있습니다. 그러면 작업을 처리하기 위해 서버리스 스토리지로 활성화된 작업자 노드가 시작됩니다. 동일한 Spark 속성을 **false**로 설정하여 특정 작업에 대한 서버리스 스토리지를 비활성화`spark.aws.serverlessStorage.enabled`할 수도 있습니다.
```
# Turn on serverless storage for EMR serverless for a specific job
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi
--conf spark.aws.serverlessStorage.enabled": "true"
}
}'
```
**참고**
기존 로컬 디스크 프로비저닝을 계속 사용하려면 `spark.aws.serverlessStorage.enabled` 구성을 생략하거나 **false**로 설정합니다.
## 고려 사항 및 제한 사항
+ **릴리스 버전** - 서버리스 스토리지는 Amazon EMR 릴리스 7.12 이상에서 지원됩니다.
+ **데이터 볼륨 제한** - 각 작업은 작업 실행당 최대 총 200GB의 중간 데이터를 읽고 쓸 수 있습니다. 이 제한을 초과하는 작업은 서버리스 스토리지 제한에 도달했음을 나타내는 오류 메시지와 함께 실패합니다.
+ **작업 실행 제한 시간** - 서버리스 스토리지는 최대 24시간의 실행 제한 시간이 있는 작업을 지원합니다. 실행 제한 시간을 늘리도록 구성된 작업은 오류 메시지와 함께 실패합니다.
+ **사전 초기화된 용량** - 사전 초기화된 용량 작업자는 서버리스 스토리지를 지원하지 않습니다. 사전 초기화된 용량을 구성하면 작업 수준에서 서버리스 스토리지를 명시적으로 비활성화하는 작업에서만 사용됩니다. 서버리스 스토리지가 활성화된 작업은 항상 온디맨드로 새 작업자를 프로비저닝하며 애플리케이션 수준의 구성에 관계없이 사전 초기화된 용량을 사용하지 않습니다.
+ **워크로드 유형** - 스트리밍 및 대화형 작업에는 서버리스 스토리지가 지원되지 않습니다.
+ **작업자 구성** - vCPUs가 1개 또는 2개인 작업자에는 서버리스 스토리지가 지원되지 않습니다.
## 지원됨 AWS 리전
EMR Serverless는 다음 리전에서 서버리스 스토리지를 지원합니다.
+ 미국 동부(버지니아 북부)
+ US West (Oregon)
+ 유럽(아일랜드)
# 지속적으로 스트리밍되는 데이터를 처리하기 위한 스트리밍 작업
EMR Serverless의 스트리밍 작업은 스트리밍 데이터를 거의 실시간으로 분석 및 처리할 수 있는 작업 모드입니다. 이러한 장기 실행 작업은 스트리밍 데이터를 폴링하고 데이터가 도착하면 지속적으로 결과를 처리합니다. 스트리밍 작업은 실시간에 가까운 분석, 사기 탐지 및 추천 엔진과 같이 실시간 데이터 처리가 필요한 태스크에 가장 적합합니다. EMR Serverless 스트리밍 작업은 기본 제공 작업 복원력, 실시간 모니터링, 향상된 로그 관리, 스트리밍 커넥터와의 통합과 같은 최적화를 제공합니다.
다음은 스트리밍 작업의 몇 가지 사용 사례입니다.
+ **실시간에 가까운 분석** - Amazon EMR Serverless에서 스트리밍 작업을 사용하면 스트리밍 데이터를 거의 실시간으로 처리할 수 있으므로, 로그 데이터, 센서 데이터 또는 클릭스트림 데이터와 같은 연속 데이터 스트림에 대한 실시간 분석을 수행하여 인사이트를 도출하고 최신 정보를 기반으로 시기 적절한 결정을 내릴 수 있습니다.
+ **사기 탐지** - 데이터 스트림을 분석하고 의심스러운 패턴 또는 이상이 발생할 때 이를 식별하는 경우 스트리밍 작업을 사용하여 금융 거래, 신용카드 작업 또는 온라인 활동에서 실시간에 가까운 사기 탐지를 실행할 수 있습니다.
+ **추천 엔진** - 스트리밍 작업에서는 사용자 활동 데이터를 처리하고 추천 모델을 업데이트할 수 있습니다. 이를 통해 행동과 선호도에 따라 개인화된 실시간 추천이 제공됩니다.
+ **소셜 미디어 분석** - 스트리밍 작업에서 트윗, 게시물, 댓글 등의 소셜 미디어 데이터를 처리할 수 있으므로, 조직은 추세를 모니터링하고, 감정을 분석하며, 브랜드 평판을 실시간에 가깝게 관리할 수 있습니다.
+ **사물 인터넷(IoT) 분석** - 스트리밍 작업에서 IoT 디바이스, 센서 및 연결된 기계의 고속 데이터 스트림을 처리하고 분석할 수 있으므로 이상 탐지, 예측 유지 보수 및 기타 IoT 분석 사용 사례를 실행할 수 있습니다.
+ **클릭스트림 분석** - 스트리밍 작업은 웹 사이트 또는 모바일 애플리케이션의 클릭스트림 데이터를 처리 및 분석할 수 있습니다. 이러한 데이터를 사용하는 비즈니스는 분석을 실행하여 사용자 행동에 대해 자세히 알아보고, 사용자 경험을 개인화하며, 마케팅 캠페인을 최적화할 수 있습니다.
+ **로그 모니터링 및 분석** - 스트리밍 작업은 서버, 애플리케이션 또는 네트워크 디바이스의 로그 데이터를 처리할 수도 있습니다. 이를 통해 이상 탐지, 문제 해결, 시스템 상태 및 성능이 제공됩니다.
**주요 이점**
EMR Serverless에서 스트리밍 작업은 다음 요소를 조합한 *작업 복원력*을 자동으로 제공합니다.
+ **자동 재시도** - EMR Serverless는 사용자의 수동 입력 없이 실패한 모든 작업을 자동으로 재시도합니다.
+ **가용 영역(AZ) 복원력** - 원래 AZ에 문제가 발생하는 경우 EMR Serverless는 스트리밍 작업을 정상 AZ로 자동 전환합니다.
+ **로그 관리:**
+ **로그 교체** - 보다 효율적인 디스크 스토리지 관리를 위해 EMR Serverless는 장기 스트리밍 작업에 대한 로그를 정기적으로 교체합니다. 이렇게 하면 모든 디스크 공간을 소비할 수 있는 로그 누적을 방지합니다.
+ **로그 압축** - 관리형 지속성으로 로그 파일을 효율적으로 관리하고 최적화할 수 있습니다. 또한 압축을 통해 관리형 Spark 기록 서버를 사용하는 경우 디버그 환경을 개선합니다.
**지원되는 데이터 소스 및 데이터 싱크**
EMR Serverless는 다양한 입력 데이터 소스 및 출력 데이터 싱크와 함께 작동합니다.
+ 지원되는 입력 데이터 소스 – Amazon Kinesis Data Streams, Amazon Managed Streaming for Apache Kafka, 자체 관리형 Apache Kafka 클러스터. 기본적으로 Amazon EMR 릴리스 7.1.0 이상에는 [Amazon Kinesis Data Streams 커넥터](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html)가 포함되어 있으므로 추가 패키지를 빌드하거나 다운로드하지 않아도 됩니다.
+ 지원되는 출력 데이터 싱크 - AWS Glue Data Catalog 테이블, Amazon S3, Amazon Redshift, MySQL, PostgreSQL Oracle, Oracle, Microsoft SQL, Apache Iceberg, Delta Lake 및 Apache Hudi.
## 고려 사항 및 제한 사항
스트리밍 작업을 사용하는 경우 다음 고려 사항 및 제한 사항에 유의합니다.
+ 스트리밍 작업은 [Amazon EMR 릴리스 7.1.0 이상](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html)에서 지원됩니다.
+ EMR Serverless에서는 스트리밍 작업이 장기간 실행될 것으로 예상하므로, 작업의 런타임을 제한하도록 실행 제한 시간을 설정할 수 없습니다.
+ 스트리밍 작업은 [구조화된 스트리밍 프레임워크](https://spark.apache.org/streaming/)에 빌드된 Spark 엔진과만 호환됩니다.
+ EMR Serverless는 스트리밍 작업을 무기한 재시도하며, 사용자는 최대 시도 횟수를 사용자 지정할 수 없습니다. 실패한 시도 횟수가 시간당 기간에 설정된 임계치를 초과하면 작업 재시도를 중지하기 위해 스래시 방지가 자동으로 포함됩니다. 기본 임계치는 1시간 동안 실패한 시도 5회입니다. 이 임계치를 1\$110회 시도로 구성할 수 있습니다. 자세한 내용은 [작업 복원력](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/SECTION-jobs-resiliency.xml.html)을 참조하세요.
+ 스트리밍 작업에는 런타임 상태 및 진행 상황을 저장하는 체크포인트가 있으므로, EMR Serverless는 최신 체크포인트에서 스트리밍 작업을 재개할 수 있습니다. 자세한 내용은 Apache Spark 설명서의 [Recovering from failures with Checkpointing](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing)을 참조하세요.
# 스트리밍 작업 시작하기
스트리밍 작업을 시작하는 방법을 알아보려면 다음 지침을 참조하세요.
1. [Amazon EMR Serverless 시작하기](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html)를 수행하여 애플리케이션을 생성합니다. 애플리케이션이 [Amazon EMR 릴리스 7.1.0](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html) 이상을 실행해야 합니다.
1. 애플리케이션이 준비되면 다음 AWS CLI 예제와 마찬가지로 `mode` 파라미터를 로 설정`STREAMING`하여 스트리밍 작업을 제출합니다.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3"
}
}'
```
# 지원되는 스트리밍 커넥터
스트리밍 커넥터는 스트리밍 소스에서 데이터를 쉽게 읽을 수 있고 스트리밍 싱크에 데이터를 쓸 수도 있습니다.
다음은 지원되는 스트리밍 커넥터입니다.
**Amazon Kinesis Data Streams 커넥터**
Apache Spark용 [Amazon Kinesis Data Streams 커넥터](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html)를 사용하면 Amazon Kinesis Data Streams에서 데이터를 소비하고 쓰는 스트리밍 애플리케이션 및 파이프라인을 빌드할 수 있습니다. 커넥터는 샤드당 최대 2MB/초의 전용 읽기 처리량 속도로 향상된 팬아웃 소비를 지원합니다. 기본적으로 Amazon EMR Serverless 7.1.0 이상에는 커넥터가 포함되어 있으므로, 추가 패키지를 빌드하거나 다운로드하지 않아도 됩니다. 커넥터에 대한 자세한 내용은 GitHub의 [spark-sql-kinesis-connector](https://github.com/awslabs/spark-sql-kinesis-connector/) 페이지를 참조하세요.
다음은 Kinesis Data Streams 커넥터 종속성을 사용하여 작업 실행을 시작하는 방법에 대한 예제입니다.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--jars /usr/share/aws/kinesis/spark-sql-kinesis/lib/spark-streaming-sql-kinesis-connector.jar"
}
}'
```
Kinesis Data Streams에 연결하려면 VPC 액세스로 EMR Serverless 애플리케이션을 구성하고 VPC 엔드포인트를 사용하여 프라이빗 액세스를 허용하거나 NAT 게이트웨이를 사용하여 퍼블릭 액세스를 얻어야 합니다. 자세한 내용은 [VPC 액세스 구성](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html)을 참조하세요. 또한 필요한 데이터 스트림에 액세스하는 데 필요한 읽기 및 쓰기 권한이 작업 런타임 역할에 있는지 확인해야 합니다. 작업 런타임 역할을 구성하는 방법에 대해 자세히 알아보려면 [Amazon EMR Serverless에 대한 작업 런타임 역할](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/security-iam-runtime-role.html)을 참조하세요. 필요한 모든 권한의 전체 목록은 GitHub의 [spark-sql-kinesis-connector](https://github.com/awslabs/spark-sql-kinesis-connector/?tab=readme-ov-file#how-to-use-it) 페이지를 참조하세요.
**Apache Kafka 커넥터**
Spark의 구조화된 스트리밍에 대한 Apache Kafka 커넥터는 Spark 커뮤니티의 오픈 소스 커넥터이며, Maven 리포지토리에서 사용할 수 있습니다. 이 커넥터를 사용하면 Spark의 구조화된 스트리밍 애플리케이션이 자체 관리형 Apache Kafka 및 Amazon Managed Streaming for Apache Kafka에서 데이터를 읽고 쓸 수 있습니다. 커넥터에 대한 자세한 내용은 Apache Spark 설명서의 [Structured Streaming \$1 Kafka Integration Guide](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html)를 참조하세요.
다음 예제에서는 작업 실행 요청에 Kafka 커넥터를 포함하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--packages org.apache.spark:spark-sql-kafka-0-10_2.12:"
}
}'
```
Apache Kafka 커넥터 버전은 EMR Serverless 릴리스 버전 및 해당 Spark 버전에 따라 달라집니다. 올바른 Kafka 버전을 찾으려면 [Structured Streaming \$1 Kafka Integration Guide](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html)를 참조하세요.
Amazon Managed Streaming for Apache Kafka를 IAM 인증과 함께 사용하려면 Kafka 커넥터가 IAM을 사용하여 Amazon MSK에 연결되도록 다른 종속 항목을 포함합니다. 자세한 내용은 GitHub의 [aws-msk-iam-auth repository](https://github.com/aws/aws-msk-iam-auth)를 참조하세요. 또한 작업 런타임 역할에 필요한 IAM 권한이 있는지 확인해야 합니다. 다음 예제에서는 IAM 인증과 함께 커넥터를 사용하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--packages org.apache.spark:spark-sql-kafka-0-10_2.12:,software.amazon.msk:aws-msk-iam-auth:"
}
}'
```
Amazon MSK의 Kafka 커넥터 및 IAM 인증 라이브러리를 사용하려면 VPC 액세스를 통해 EMR Serverless 애플리케이션을 구성합니다. 서브넷에는 인터넷 액세스 권한이 있어야 하며, NAT Gateway를 사용하여 Maven 종속 항목에 액세스해야 합니다. 자세한 내용은 [VPC 액세스 구성](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html)을 참조하세요. Kafka 클러스터에 액세스하려면 서브넷에 네트워크 연결이 있어야 합니다. 이는 Kafka 클러스터가 자체 관리형인지 여부에 상관없이 Amazon Managed Streaming for Apache Kafka를 사용하는 경우에도 적용됩니다.
# 스트리밍 작업 로그 관리
스트리밍 작업은 Spark 애플리케이션 로그 및 이벤트 로그의 로그 교체와 Spark 이벤트 로그의 로그 압축을 지원합니다. 이 경우 리소스를 효과적으로 관리하는 데 도움이 됩니다.
**로그 교체**
스트리밍 작업은 Spark 애플리케이션 로그 및 이벤트 로그에 대한 로그 교체를 지원합니다. 로그 교체는 장기 스트리밍 작업에서 사용 가능한 모든 디스크 공간을 차지할 수 있는 대형 로그 파일 생성을 방지합니다. 로그 교체를 사용하면 디스크 스토리지를 저장하고 디스크 공간 부족으로 인한 작업 실패를 방지할 수 있습니다. 자세한 정보를 알아보려면 [로그 교체](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/rotating-logs.html)를 참조하세요.
**로그 압축**
스트리밍 작업은 관리형 로깅이 사용 가능한 경우 항상 Spark 이벤트 로그에 대한 로그 압축도 지원합니다. 관리형 로깅에 대한 자세한 내용은 [관리형 스토리지를 사용하는 로깅](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-managed-storage)을 참조하세요. 스트리밍 작업은 장기간 실행될 수 있으며, 이벤트 데이터의 양은 시간이 지남에 따라 누적되어 로그 파일 크기가 크게 증가할 수 있습니다. Spark 기록 서버는 이러한 이벤트를 읽고 Spark 애플리케이션 UI의 메모리에 로드합니다. 이 프로세스는 특히 Amazon S3에 저장된 이벤트 로그가 매우 큰 경우 지연 시간과 비용을 높일 수 있습니다.
로그 압축은 이벤트 로그 크기를 줄이므로, Spark 기록 서버는 언제든지 1GB를 초과하는 이벤트 로그를 로드하지 않아도 됩니다. 자세한 내용은 Apache Spark 설명서의 [Monitoring and Instrumentation](https://spark.apache.org/docs/latest/monitoring.html)을 참조하세요.
# EMR Serverless 작업을 실행하는 경우 Spark 구성 사용
`type` 파라미터가 `SPARK`로 설정된 애플리케이션에서 Spark 작업을 실행할 수 있습니다. 작업은 Amazon EMR 릴리스 버전과 호환되는 Spark 버전과 호환되어야 합니다. 예를 들어, Amazon EMR 릴리스 6.6.0을 사용하여 작업을 실행할 때 작업은 Apache Spark 3.2.0과 호환되어야 합니다. 각 릴리스의 애플리케이션 버전에 대한 자세한 내용은 [Amazon EMR Serverless 릴리스 버전](release-versions.md) 섹션을 참조하세요.
## Spark 작업 파라미터
[`StartJobRun` API](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)를 사용하여 Spark 작업을 실행하는 경우 다음 파라미터를 지정할 수 있습니다.
**Topics**
+ [
### Spark 작업 런타임 역할
](#spark-defaults-executionRoleArn)
+ [
### Spark 작업 드라이버 파라미터
](#spark-defaults-jobDriver)
+ [
### Spark 구성 재정의 파라미터
](#spark-defaults-configurationOverrides)
+ [
### Spark 동적 리소스 할당 최적화
](#spark-defaults-dynamicResourceAllocation)
### Spark 작업 런타임 역할
**`executionRoleArn`**을 사용하여 애플리케이션이 Spark 작업을 실행하는 데 사용하는 IAM 역할에 대한 ARN을 지정합니다. 이 역할에는 다음 권한이 있어야 합니다.
+ S3 버킷 또는 데이터가 상주하는 기타 데이터 소스에서 읽기
+ PySpark 스크립트 또는 JAR 파일이 상주하는 S3 버킷 또는 접두사에서 읽기
+ 최종 출력을 쓰려는 S3 버킷에 쓰기
+ `S3MonitoringConfiguration`에서 지정하는 S3 버킷 또는 접두사로 로그 쓰기
+ S3 버킷의 데이터를 암호화하기 위해 KMS 키를 사용하는 경우 KMS 키에 대한 액세스
+ SparkSQL을 사용하는 경우 AWS Glue 데이터 카탈로그에 액세스
Spark 작업이 다른 데이터 소스에서 데이터를 읽거나 쓰는 경우 이 IAM 역할에서 적절한 권한을 지정합니다. IAM 역할에 이러한 권한을 제공하지 않으면 작업이 실패할 수 있습니다. 자세한 정보는 [Amazon EMR Serverless에 대한 작업 런타임 역할](security-iam-runtime-role.md) 및 [로그 저장](logging.md) 섹션을 참조하세요.
### Spark 작업 드라이버 파라미터
**`jobDriver`**를 사용하여 작업에 대한 입력을 제공합니다. 작업 드라이버 파라미터는 실행하려는 작업 유형에 대해 하나의 값만 허용합니다. Spark 작업의 경우 파라미터 값은 `sparkSubmit`입니다. 이 작업 유형을 사용하여 Spark 제출을 통해 Scala, Java, PySpark 및 기타 지원되는 작업을 실행할 수 있습니다. Spark 작업에는 다음 파라미터가 있습니다.
+ **`sparkSubmitParameters`** - 작업에 전송하려는 추가 Spark 파라미터입니다. 이 파라미터를 사용하여 드라이버 메모리 또는 실행기 수와 같은 기본 Spark 속성(예: `--conf` 또는 `--class`에 정의된 속성)을 재정의합니다.
+ **`entryPointArguments`** - 기본 JAR 또는 Python 파일에 전달하려는 인수의 배열입니다. entrypoint 코드를 사용하여 이러한 파라미터를 읽는 작업을 처리해야 합니다. 배열의 각 인수를 쉼표로 분리합니다.
+ **`entryPoint`** – Amazon S3에서 실행하려는 기본 JAR 또는 Python 파일에 대한 참조입니다. Scala 또는 Java JAR을 실행하는 경우 `--class` 인수를 `SparkSubmitParameters`에서 기본 항목 클래스를 지정합니다.
자세한 내용은 [Launching Applications with spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit)을 참조하세요.
### Spark 구성 재정의 파라미터
모니터링 수준 및 애플리케이션 수준 구성 속성을 재정의하려면 **`configurationOverrides`**를 사용합니다. 이 파라미터는 다음 두 필드를 포함하는 JSON 객체를 수락합니다.
+ **`monitoringConfiguration`** - 이 필드를 사용하여 EMR Serverless 작업에서 Spark 작업의 로그를 저장할 Amazon S3 URL(`s3MonitoringConfiguration`)을 지정합니다. 애플리케이션을 호스팅 AWS 계정 하는 동일한와 작업이 실행되는 AWS 리전 동일한 로이 버킷을 생성했는지 확인합니다.
+ **`applicationConfiguration`** - 애플리케이션에 대한 기본 구성을 재정의하기 위해 이 필드에서 구성 객체를 제공할 수 있습니다. 간편 구문을 사용하여 구성을 제공하거나 JSON 파일의 구성 객체를 참조할 수 있습니다. 구성 객체는 분류, 속성 및 선택적 중첩 구성으로 이루어져 있습니다. 속성은 해당 파일에서 재정의하려는 설정으로 구성됩니다. 단일 JSON 객체에서 여러 애플리케이션에 대해 다양한 분류를 지정할 수 있습니다.
**참고**
사용 가능한 구성 분류는 특정 EMR Serverless 릴리스에 따라 다릅니다. 예를 들어 사용자 지정 Log4j `spark-driver-log4j2` 및 `spark-executor-log4j2`에 대한 분류는 릴리스 6.8.0 이상에서만 사용할 수 있습니다.
애플리케이션 재정의 및 Spark 제출 파라미터에서 동일한 구성을 사용하는 경우 Spark 제출 파라미터가 우선합니다. 구성의 우선순위는 다음과 같습니다(최상위부터 최하위의 순서).
+ `SparkSession`을 생성하는 경우 EMR Serverless에서 제공하는 구성.
+ `--conf` 인수와 함께 `sparkSubmitParameters`의 일부로 제공하는 구성.
+ 작업을 시작하는 경우 애플리케이션 재정의의 일부로 제공하는 구성.
+ 애플리케이션을 생성하는 경우 `runtimeConfiguration`의 일부로 제공하는 구성.
+ 해당 릴리스에 대해 Amazon EMR에서 사용하는 최적화된 구성.
+ 애플리케이션의 기본 오픈 소스 구성.
애플리케이션 수준에서 구성을 선언하고 작업 실행 중에 구성을 재정의하는 방법에 대한 자세한 내용은 [EMR Serverless에 대한 기본 애플리케이션 구성](default-configs.md) 섹션을 참조하세요.
### Spark 동적 리소스 할당 최적화
`dynamicAllocationOptimization`을 사용하여 EMR Serverless에서 리소스 사용을 최적화합니다. Spark 구성 분류에서 이 속성을 `true`로 설정하면 EMR Serverless가 실행기 리소스 할당을 최적화하여 EMR Serverless에서 작업자를 생성하고 릴리스하는 속도에 맞게 Spark에서 실행기를 요청하고 취소하는 속도를 조정할 수 있습니다. 이렇게 하면 EMR Serverless는 여러 단계에서 작업자를 더 최적으로 재사용하므로 동일한 성능을 유지 관리하면서 여러 단계에서 작업을 실행할 때 비용이 절감됩니다.
이 속성은 모든 Amazon EMR 릴리스 버전에서 사용할 수 있습니다.
다음은 `dynamicAllocationOptimization`을 사용하는 샘플 구성 분류입니다.
```
[
{
"Classification": "spark",
"Properties": {
"dynamicAllocationOptimization": "true"
}
}
]
```
동적 할당 최적화를 사용하는 경우 다음을 고려합니다.
+ 이 최적화는 동적 리소스 할당을 활성화한 Spark 작업에 대해 사용할 수 있습니다.
+ 비용 효율성을 극대화하기 위해 워크로드를 기반으로 작업 수준 설정 `spark.dynamicAllocation.maxExecutors` 또는 [애플리케이션 수준 최대 용량](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/app-behavior.html#max-capacity) 설정을 사용해 워커의 조정 상한을 구성하는 것이 좋습니다.
+ 단순한 작업에서는 비용 절감 효과를 느끼지 못할 수도 있습니다. 예를 들어, 작업이 작은 데이터세트에서 실행되거나 한 단계에서 실행을 완료하는 경우 Spark에는 더 많은 수의 실행기 또는 다중 조정 이벤트가 필요하지 않을 수 있습니다.
+ 큰 단계, 더 작은 단계, 이후 다시 큰 단계로 구성된 시퀀스의 작업은 작업 런타임에서 회귀가 발생할 수 있습니다. EMR Serverless는 리소스를 더 효율적으로 사용하므로, 더 큰 단계에 대해 사용 가능한 작업자 수가 줄어들어 런타임이 길어질 수 있습니다.
## Spark 작업 속성
다음 표에는 선택적 Spark 속성과 Spark 작업을 제출할 때 재정의할 수 있는 기본값이 나와 있습니다.
**선택적 Spark 속성 및 기본값**
| Key(키) | 설명 | 기본값 |
| --- | --- | --- |
| spark.archives | Spark에서 각 실행기의 작업 디렉터리로 추출하는 쉼표로 구분된 아카이브 목록. 지원되는 파일 형식은 .jar, .tar.gz, .tgz 및 .zip입니다. 추출할 디렉터리 이름을 지정하려면 추출하려는 파일 이름 뒤에 \$1을 추가합니다. 예를 들어 file.zip\$1directory입니다. | NULL |
| spark.authenticate | Spark의 내부 연결 인증을 켜는 옵션. | TRUE |
| spark.driver.cores | 드라이버가 사용하는 코어 수. | 4 |
| spark.driver.extraJavaOptions | Spark 드라이버에 대한 추가 Java 옵션. | NULL |
| spark.driver.memory | 드라이버가 사용하는 메모리의 양. | 14G |
| spark.dynamicAllocation.enabled | 동적 리소스 할당을 켜는 옵션. 이 옵션은 워크로드에 따라 애플리케이션에 등록된 실행기 수를 스케일 업 또는 스케일 다운합니다. | TRUE |
| spark.dynamicAllocation.executorIdleTimeout | Spark에서 제거하기 전에 실행기가 유휴 상태를 유지할 수 있는 시간. 이는 동적 할당을 켜는 경우에만 적용됩니다. | 60초 |
| spark.dynamicAllocation.initialExecutors | 동적 할당을 켜는 경우 실행할 초기 실행기 수. | 3 |
| spark.dynamicAllocation.maxExecutors | 동적 할당을 켜는 경우 실행기 수의 상한. | 6.10.0 이상의 경우 `infinity` 6.9.0 이하의 경우 `100` |
| spark.dynamicAllocation.minExecutors | 동적 할당을 켜는 경우 실행기 수의 하한. | 0 |
| spark.emr-serverless.allocation.batch.size | 실행기 할당의 각 주기에서 요청할 컨테이너 수. 각 할당 주기 사이 간격은 1초입니다. | 20 |
| spark.emr-serverless.driver.disk | Spark 드라이버 디스크. | 20G |
| spark.emr-serverless.driverEnv.[KEY] | 환경 변수를 Spark 드라이버에 추가하는 옵션. | NULL |
| spark.emr-serverless.executor.disk | Spark 실행기 디스크. | 20G |
| spark.emr-serverless.memoryOverheadFactor | 드라이버 및 실행기 컨테이너 메모리에 추가할 메모리 오버헤드를 설정합니다. | 0.1 |
| spark.emr-serverless.driver.disk.type | Spark 드라이버에 연결된 디스크 유형. | 표준 |
| spark.emr-serverless.executor.disk.type | Spark 실행기에 연결된 디스크 유형. | 표준 |
| spark.executor.cores | 각 실행기에서 사용할 코어 수. | 4 |
| spark.executor.extraJavaOptions | Spark 실행기에 대한 추가 Java 옵션. | NULL |
| spark.executor.instances | 할당할 Spark 실행기 컨테이너 수. | 3 |
| spark.executor.memory | 각 실행기가 사용하는 메모리의 양. | 14G |
| spark.executorEnv.[KEY] | 환경 변수를 Spark 실행기에 추가하는 옵션. | NULL |
| spark.files | 각 실행기의 작업 디렉터리에 배치할 쉼표로 구분된 파일 목록. SparkFiles.get(fileName)을 사용하여 실행기에서 이러한 파일의 파일 경로에 액세스할 수 있습니다. | NULL |
| spark.hadoop.hive.metastore.client.factory.class | Hive 메타스토어 구현 클래스. | NULL |
| spark.jars | 드라이버 및 실행기의 런타임 클래스 경로에 추가할 추가 jar. | NULL |
| spark.network.crypto.enabled | AES 기반 RPC 암호화를 켜는 옵션. 여기에는 Spark 2.2.0에 추가된 인증 프로토콜이 포함됩니다. | FALSE |
| spark.sql.warehouse.dir | 관리형 데이터베이스 및 테이블의 기본 위치. | \$1PWD/spark-warehouse의 값 |
| spark.submit.pyFiles | Python 앱에 대한 PYTHONPATH에 배치할 .zip, .egg 또는 .py 파일의 쉼표로 구분된 목록. | NULL |
다음 표에는 기본 Spark 제출 파라미터가 나와 있습니다.
**기본 Spark 제출 파라미터**
| Key(키) | 설명 | 기본값 |
| --- | --- | --- |
| archives | Spark에서 각 실행기의 작업 디렉터리로 추출하는 쉼표로 구분된 아카이브 목록. | NULL |
| class | 애플리케이션의 기본 클래스(Java 및 Scala 앱용). | NULL |
| conf | 임의의 Spark 구성 속성. | NULL |
| driver-cores | 드라이버가 사용하는 코어 수. | 4 |
| driver-memory | 드라이버가 사용하는 메모리의 양. | 14G |
| executor-cores | 각 실행기에서 사용할 코어 수. | 4 |
| executor-memory | 실행기가 사용하는 메모리의 양. | 14G |
| files | 각 실행기의 작업 디렉터리에 배치할 쉼표로 구분된 파일 목록. SparkFiles.get(fileName)을 사용하여 실행기에서 이러한 파일의 파일 경로에 액세스할 수 있습니다. | NULL |
| jars | 드라이버 및 실행기 클래스 경로에 포함할 jar의 쉼표로 구분된 목록. | NULL |
| num-executors | 실행할 실행기 수. | 3 |
| py-files | Python 앱에 대한 PYTHONPATH에 배치할 .zip, .egg 또는 .py 파일의 쉼표로 구분된 목록. | NULL |
| verbose | 추가 디버그 출력을 켜는 옵션. | NULL |
## 리소스 구성 모범 사례
### StartJobRun API를 통해 드라이버 및 실행기 리소스 구성
**참고**
Spark 드라이버와 실행기 코어 및 메모리 속성은 지정된 경우 StartJobRun API 요청에 직접 지정합니다.
이러한 방식으로 리소스를 구성하면 EMR Serverless가 작업을 실행하기 전에 올바른 리소스를 할당할 수 있습니다. 이는 스크립트 실행이 시작되기 전에 드라이버 및 실행기 워커가 사전 프로비저닝되는 경우가 있기 때문에 너무 늦게 평가되는 .py 또는 .jar 파일과 같은 사용자 스크립트에 제공되는 설정과는 대조적입니다. 작업 제출 중에 이러한 리소스를 구성하는 방법으로는 다음의 두 가지 방법이 지원됩니다.
#### 옵션 1: sparkSubmitParameters 사용
```
"jobDriver": {
"sparkSubmit": {
"entryPoint": "s3://your-script-path.py",
"sparkSubmitParameters": "—conf spark.driver.memory=4g \
—conf spark.driver.cores=2 \
—conf spark.executor.memory=8g \
—conf spark.executor.cores=4"
}
}
```
#### 옵션 2: spark-defaults 분류에 configurationOverrides 사용
```
"configurationOverrides": {
"applicationConfiguration": [
{
"classification": "spark-defaults",
"properties": {
"spark.driver.memory": "4g",
"spark.driver.cores": "2",
"spark.executor.memory": "8g",
"spark.executor.cores": "4"
}
}
]
}
```
## Spark 예제
다음 예제에서는 `StartJobRun` API를 사용하여 Python 스크립트를 실행하는 방법을 보여줍니다. 이 예제를 사용하는 엔드투엔드 자습서는 [Amazon EMR Serverless 시작하기](getting-started.md) 섹션을 참조하세요. [EMR Serverless Samples](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/pyspark) GitHub 리포지토리에서 PySpark 작업을 실행하고 Python 종속 항목을 추가하는 방법에 대한 추가 예제를 찾을 수 있습니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://us-east-1.elasticmapreduce/emr-containers/samples/wordcount/scripts/wordcount.py",
"entryPointArguments": ["s3://amzn-s3-demo-destination-bucket/wordcount_output"],
"sparkSubmitParameters": "--conf spark.executor.cores=1 --conf spark.executor.memory=4g --conf spark.driver.cores=1 --conf spark.driver.memory=4g --conf spark.executor.instances=1"
}
}'
```
다음 예제에서는 `StartJobRun` API를 사용하여 Spark JAR을 실행하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}'
```
# EMR Serverless 작업을 실행하는 경우 Hive 구성 사용
`type` 파라미터가 `HIVE`로 설정된 애플리케이션에서 Hive 작업을 실행할 수 있습니다. 작업은 Amazon EMR 릴리스 버전과 호환되는 Hive 버전과 호환되어야 합니다. 예를 들어, Amazon EMR 릴리스 6.6.0을 사용하여 애플리케이션에서 작업을 실행할 때 작업은 Apache Hive 3.1.2와 호환되어야 합니다. 각 릴리스의 애플리케이션 버전에 대한 자세한 내용은 [Amazon EMR Serverless 릴리스 버전](release-versions.md) 섹션을 참조하세요.
## Hive 작업 파라미터
[`StartJobRun` API](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html)를 사용하여 Hive 작업을 실행하는 경우 다음 파라미터를 지정합니다.
**Topics**
+ [
### Hive 작업 런타임 역할
](#hive-defaults-executionRoleArn)
+ [
### Hive 작업 드라이버 파라미터
](#hive-defaults-jobDriver)
+ [
### Hive 구성 재정의 파라미터
](#hive-defaults-configurationOverrides)
### Hive 작업 런타임 역할
**`executionRoleArn`**을 사용하여 애플리케이션이 Hive 작업을 실행하는 데 사용하는 IAM 역할에 대한 ARN을 지정합니다. 이 역할에는 다음 권한이 있어야 합니다.
+ S3 버킷 또는 데이터가 상주하는 기타 데이터 소스에서 읽기
+ Hive 쿼리 파일 및 init 쿼리 파일이 상주하는 S3 버킷 또는 접두사에서 읽기
+ Hive Scratch 디렉터리와 Hive Metastore 웨어하우스 디렉터리가 상주하는 S3 버킷에 읽기 및 쓰기
+ 최종 출력을 쓰려는 S3 버킷에 쓰기
+ `S3MonitoringConfiguration`에서 지정하는 S3 버킷 또는 접두사로 로그 쓰기
+ S3 버킷의 데이터를 암호화하기 위해 KMS 키를 사용하는 경우 KMS 키에 대한 액세스
+ AWS Glue 데이터 카탈로그에 대한 액세스
Hive 작업이 다른 데이터 소스에서 데이터를 읽거나 쓰는 경우 이 IAM 역할에서 적절한 권한을 지정합니다. IAM 역할에 이러한 권한을 제공하지 않으면 작업이 실패할 수 있습니다. 자세한 정보는 [Amazon EMR Serverless에 대한 작업 런타임 역할](security-iam-runtime-role.md) 섹션을 참조하세요.
### Hive 작업 드라이버 파라미터
**`jobDriver`**를 사용하여 작업에 대한 입력을 제공합니다. 작업 드라이버 파라미터는 실행하려는 작업 유형에 대해 하나의 값만 허용합니다. 작업 유형으로 `hive`를 지정하면 EMR Serverless는 Hive 쿼리를 `jobDriver` 파라미터에 전달합니다. Hive 자산에는 다음 파라미터가 있습니다.
+ **`query`** - Amazon S3에서 실행하려는 Hive 쿼리 파일에 대한 참조입니다.
+ **`parameters`** - 재정의하려는 추가 Hive 구성 속성입니다. 속성을 재정의하려면 이 파라미터에 `--hiveconf property=value`로 전달합니다. 변수를 재정의하려면 이 파라미터에 `--hivevar key=value`로 전달합니다.
+ **`initQueryFile`** - init Hive 쿼리 파일입니다. Hive는 쿼리 전에 이 파일을 실행하고 이를 사용하여 테이블을 초기화할 수 있습니다.
### Hive 구성 재정의 파라미터
모니터링 수준 및 애플리케이션 수준 구성 속성을 재정의하려면 **`configurationOverrides`**를 사용합니다. 이 파라미터는 다음 두 필드를 포함하는 JSON 객체를 수락합니다.
+ **`monitoringConfiguration`** - 이 필드를 사용하여 EMR Serverless 작업에서 Hive 작업의 로그를 저장할 Amazon S3 URL(`s3MonitoringConfiguration`)을 지정합니다. 애플리케이션을 호스팅 AWS 계정 하는 동일한와 작업이 실행되는 AWS 리전 동일한에서이 버킷을 생성해야 합니다.
+ **`applicationConfiguration`** - 애플리케이션에 대한 기본 구성을 재정하도록 이 필드에 구성 객체를 제공할 수 있습니다. 간편 구문을 사용하여 구성을 제공하거나 JSON 파일의 구성 객체를 참조할 수 있습니다. 구성 객체는 분류, 속성 및 선택적 중첩 구성으로 이루어져 있습니다. 속성은 해당 파일에서 재정의하려는 설정으로 구성됩니다. 단일 JSON 객체에서 여러 애플리케이션에 대해 다양한 분류를 지정할 수 있습니다.
**참고**
사용 가능한 구성 분류는 특정 EMR Serverless 릴리스에 따라 다릅니다. 예를 들어 사용자 지정 Log4j `spark-driver-log4j2` 및 `spark-executor-log4j2`에 대한 분류는 릴리스 6.8.0 이상에서만 사용할 수 있습니다.
애플리케이션 재정의 및 Hive 파라미터에서 동일한 구성을 전달하는 경우 Hive 파라미터가 우선합니다. 다음 목록은 가장 높은 우선순위에서 가장 낮은 우선순위로 구성의 우선순위를 나열합니다.
+ `--hiveconf property=value`를 사용하여 Hive 파라미터의 일부로 제공하는 구성.
+ 작업을 시작하는 경우 애플리케이션 재정의의 일부로 제공하는 구성.
+ 애플리케이션을 생성하는 경우 `runtimeConfiguration`의 일부로 제공하는 구성.
+ 해당 릴리스에 대해 Amazon EMR에서 할당하는 최적화된 구성.
+ 애플리케이션의 기본 오픈 소스 구성.
애플리케이션 수준에서 구성을 선언하고 작업 실행 중에 구성을 재정의하는 방법에 대한 자세한 내용은 [EMR Serverless에 대한 기본 애플리케이션 구성](default-configs.md) 섹션을 참조하세요.
## Hive 작업 속성
다음 표에는 Hive 작업 제출 시 구성하는 필수 속성이 나와 있습니다.
**필수 Hive 작업 속성**
| 설정 | 설명 |
| --- | --- |
| hive.exec.scratchdir | EMR Serverless가 Hive 작업 실행 중에 임시 파일을 생성하는 Amazon S3 위치. |
| hive.metastore.warehouse.dir | Hive의 관리형 테이블에 대한 데이터베이스의 Amazon S3 위치. |
다음 표에는 선택적 Hive 속성과 Hive 작업을 제출하는 경우 재정의할 수 있는 기본값이 나와 있습니다.
**선택적 Hive 속성 및 기본값**
| 설정 | 설명 | 기본값 |
| --- | --- | --- |
| fs.s3.customAWSCredentialsProvider | 사용하려는 AWS 자격 증명 공급자입니다. | com.amazonaws.auth.DefaultAWSCredentialsProviderChain |
| fs.s3a.aws.credentials.provider | S3A 파일 시스템에 사용할 AWS 자격 증명 공급자입니다. | com.amazonaws.auth.DefaultAWSCredentialsProviderChain |
| hive.auto.convert.join | 입력 파일 크기에 따라 공통 조인을 맵 조인으로 자동 변환하는 옵션. | TRUE |
| hive.auto.convert.join.noconditionaltask | Hive가 입력 파일 크기에 따라 공통 조인을 맵 조인으로 변환하는 경우 최적화를 켜는 옵션. | TRUE |
| hive.auto.convert.join.noconditionaltask.size | 조인은 이 크기 미만의 맵 조인으로 직접 변환됩니다. | 최적의 값은 Tez 태스크 메모리를 기반으로 계산됩니다. |
| hive.cbo.enable | Calcite 프레임워크를 사용하여 비용 기반 최적화를 켜는 옵션. | TRUE |
| hive.cli.tez.session.async | Hive 쿼리가 컴파일되는 동안 백그라운드 Tez 세션을 시작하는 옵션. false로 설정하면 Hive 쿼리가 컴파일된 후 Tez AM이 시작됩니다. | TRUE |
| hive.compute.query.using.stats | Hive를 활성화하여 메타스토어에 저장된 통계를 사용해 특정 쿼리에 응답하는 옵션. 기본 통계의 경우 hive.stats.autogather를 TRUE로 설정합니다. 보다 고급 쿼리 컬렉션의 경우 analyze table queries를 실행합니다. | TRUE |
| hive.default.fileformat | CREATE TABLE 문의 기본 파일 형식. CREATE TABLE 명령에서 STORED AS [FORMAT]을 지정하는 경우 이 값을 명시적으로 재정의할 수 있습니다. | TEXTFILE |
| hive.driver.cores | Hive 드라이버 프로세스에 사용할 코어 수. | 2 |
| hive.driver.disk | Hive 드라이버의 디스크 크기. | 20G |
| hive.driver.disk.type | Hive 드라이버의 디스크 유형. | 표준 |
| hive.tez.disk.type | Tez 작업자의 디스크 크기. | 표준 |
| hive.driver.memory | Hive 드라이버 프로세스당 사용할 메모리 양. Hive CLI 및 Tez Application Master는 이 메모리를 헤드룸의 20%로 균등하게 공유합니다. | 6G |
| hive.emr-serverless.launch.env.[KEY] | Hive 드라이버, Tez AM 및 Tez 태스크와 같은 모든 Hive별 프로세스에서 KEY 환경 변수를 설정하는 옵션. | |
| hive.exec.dynamic.partition | DML/DDL에서 동적 파티션을 켜는 옵션. | TRUE |
| hive.exec.dynamic.partition.mode | 엄격한 모드 또는 비엄격 모드를 사용할지 여부를 지정하는 옵션. 엄격한 모드에서는 실수로 모든 파티션을 덮어쓰는 경우를 대비하여 하나 이상의 정적 파티션을 지정합니다. 비엄격 모드에서는 모든 파티션이 동적으로 허용됩니다. | strict |
| hive.exec.max.dynamic.partitions | Hive가 총 생성하는 최대 동적 파티션 수. | 1000 |
| hive.exec.max.dynamic.partitions.pernode | Hive가 각 매퍼 및 감소기 노드에서 생성하는 최대 동적 파티션 수. | 100 |
| hive.exec.orc.split.strategy | BI, ETL 또는 HYBRID 값 중 하나가 예상됩니다. 사용자 수준 구성이 아닙니다. BI에서는 쿼리 실행과는 반대로, 분할 생성에 더 적은 시간을 소비하도록 지정합니다. ETL에서는 분할 생성에 더 많은 시간을 소비하도록 지정합니다. HYBRID에서는 휴리스틱을 기반으로 앞서 언급된 전략 중 하나를 지정합니다. | HYBRID |
| hive.exec.reducers.bytes.per.reducer | 감소기당 크기. 기본값은 256MB입니다. 입력 크기가 1G인 경우 작업은 4개의 감속기를 사용합니다. | 256000000 |
| hive.exec.reducers.max | 최대 감소기 수. | 256 |
| hive.exec.stagingdir | Hive가 테이블 위치 내부 및 hive.exec.scratchdir 속성에 지정된 스크래치 디렉터리 위치에서 생성하는 임시 파일을 저장하는 디렉터리의 이름. | .hive-staging |
| hive.fetch.task.conversion | NONE, MINIMAL 또는 MORE 값 중 하나가 예상됩니다. Hive는 선택한 쿼리를 단일 FETCH 태스크로 변환할 수 있습니다. 이 경우 지연 시간이 최소화됩니다. | MORE |
| hive.groupby.position.alias | Hive가 GROUP BY 문에서 열 위치 별칭을 사용하도록 하는 옵션. | FALSE |
| hive.input.format | 기본 입력 형식. CombineHiveInputFormat에 문제가 발생하면 HiveInputFormat으로 설정합니다. | org.apache.hadoop.hive.ql.io.CombineHiveInputFormat |
| hive.log.explain.output | Hive 로그의 쿼리에 대한 확장 출력에 대한 설명을 켜는 옵션. | FALSE |
| hive.log.level | Hive 로깅 수준. | INFO |
| hive.mapred.reduce.tasks.speculative.execution | 감소기에 대한 투기적 시작을 켜는 옵션. Amazon EMR 6.10.x 이하에서만 지원됩니다. | TRUE |
| hive.max-task-containers | 최대 동시 컨테이너 수. 구성된 매퍼 메모리에 이 값을 곱하여 계산과 태스크 선점에서 사용하는 사용 가능한 메모리를 결정합니다. | 1000 |
| hive.merge.mapfiles | 맵 전용 작업이 끝날 때 작은 파일이 병합되는 옵션. | TRUE |
| hive.merge.size.per.task | 작업 종료 시 병합된 파일의 크기. | 256000000 |
| hive.merge.tezfiles | Tez DAG 끝에서 작은 파일 병합을 켜는 옵션. | FALSE |
| hive.metastore.client.factory.class | IMetaStoreClient 인터페이스를 구현하는 객체를 생성하는 팩토리 클래스의 이름. | com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory |
| hive.metastore.glue.catalogid | Glue 데이터 카탈로그가 AWS 메타스토어 역할을 하지만 작업과 다른 AWS 계정 에서 실행되는 경우 작업이 실행 중인의 ID AWS 계정 입니다. | NULL |
| hive.metastore.uris | 메타스토어 클라이언트가 원격 메타스토어에 연결하는 데 사용하는 Thrift URI. | NULL |
| hive.optimize.ppd | 조건자 푸시다운을 켜는 옵션. | TRUE |
| hive.optimize.ppd.storage | 스토리지 핸들러에 대한 조건자 푸시다운을 켜는 옵션. | TRUE |
| hive.orderby.position.alias | Hive가 ORDER BY 문에서 열 위치 별칭을 사용하도록 하는 옵션. | TRUE |
| hive.prewarm.enabled | Tez에 대한 컨테이너 예열을 켜는 옵션. | FALSE |
| hive.prewarm.numcontainers | Tez에 대해 예열할 컨테이너 수. | 10 |
| hive.stats.autogather | Hive가 INSERT OVERWRITE 명령 중에 기본 통계를 자동으로 수집하도록 하는 옵션. | TRUE |
| hive.stats.fetch.column.stats | 메타스토어에서 열 통계 가져오기를 끄는 옵션. 열 수가 많으면 열 통계 가져오기 비용이 많이 들 수 있습니다. | FALSE |
| hive.stats.gather.num.threads | partialscan 및 noscan 분석 명령이 파티션된 테이블에 대해 사용하는 스레드 수. 이는 StatsProvidingRecordReader를 구현하는 파일 형식(예: ORC)에만 적용됩니다. | 10 |
| hive.strict.checks.cartesian.product | 엄격한 Cartesian 조인 검사를 켜는 옵션. 이러한 검사에서는 카테시안 곱(교차 조인)을 허용하지 않습니다. | FALSE |
| hive.strict.checks.type.safety | 엄격한 유형의 안전 검사를 켜고 string 및 double과 bigint의 비교를 끄는 옵션. | TRUE |
| hive.support.quoted.identifiers | NONE 또는 COLUMN의 값이 예상됩니다. NONE은 식별자에 영숫자와 밑줄 문자만 유효함을 의미합니다. COLUMN은 열 이름에 모든 문자가 포함될 수 있음을 의미합니다. | COLUMN |
| hive.tez.auto.reducer.parallelism | Tez 자동 감소기 병렬 처리 기능을 켜는 옵션. Hive는 여전히 데이터 크기를 예측하고 병렬 처리 예측을 설정합니다. Tez는 소스 버텍스의 출력 크기를 샘플링하고 필요에 따라 런타임 시 예측을 조정합니다. | TRUE |
| hive.tez.container.size | Tez 태스크 프로세스당 사용할 메모리 양. | 6144 |
| hive.tez.cpu.vcores | 각 Tez 태스크에 사용할 코어 수. | 2 |
| hive.tez.disk.size | 각 태스크 컨테이너의 디스크 크기. | 20G |
| hive.tez.input.format | Tez AM에서 분할 생성을 위한 입력 형식. | org.apache.hadoop.hive.ql.io.HiveInputFormat |
| hive.tez.min.partition.factor | 자동 감소기 병렬 처리를 켤 때 Tez에서 지정하는 감소기의 하한. | 0.25 |
| hive.vectorized.execution.enabled | 벡터화된 쿼리 실행 모드를 켜는 옵션. | TRUE |
| hive.vectorized.execution.reduce.enabled | 쿼리 실행의 감소 측 벡터화 모드를 켜는 옵션. | TRUE |
| javax.jdo.option.ConnectionDriverName | JDBC 메타스토어의 드라이버 클래스 이름. | org.apache.derby.jdbc.EmbeddedDriver |
| javax.jdo.option.ConnectionPassword | 메타스토어 데이터베이스와 연결된 암호. | NULL |
| javax.jdo.option.ConnectionURL | JDBC 메타스토어의 JDBC 연결 문자열. | jdbc:derby:;databaseName=metastore\$1db;create=true |
| javax.jdo.option.ConnectionUserName | 메타스토어 데이터베이스와 연결된 사용자 이름. | NULL |
| mapreduce.input.fileinputformat.split.maxsize | 입력 형식이 org.apache.hadoop.hive.ql.io.CombineHiveInputFormat인 경우 분할 계산 중 분할의 최대 크기. 값이 0이면 제한이 없음을 나타냅니다. | 0 |
| tez.am.dag.cleanup.on.completion | DAG가 완료될 때 셔플 데이터 정리를 켜는 옵션. | TRUE |
| tez.am.emr-serverless.launch.env.[KEY] | Tez AM 프로세스에서 KEY 환경 변수를 설정하는 옵션. Tez AM의 경우 이 값은 hive.emr-serverless.launch.env.[KEY] 값을 재정의합니다. | |
| tez.am.log.level | EMR Serverless가 Tez App Primary에 전달하는 루트 로깅 수준. | INFO |
| tez.am.sleep.time.before.exit.millis | EMR Serverless는 AM 종료 요청 후 이 기간 이후에 ATS 이벤트를 푸시해야 합니다. | 0 |
| tez.am.speculation.enabled | 느린 태스크의 투기적 시작이 수행되는 옵션. 이 기능은 일부 태스크가 불량 또는 느린 머신으로 인해 느리게 실행될 때 작업 지연 시간을 줄이는 데 도움이 될 수 있습니다. Amazon EMR 6.10.x 이하에서만 지원됩니다. | FALSE |
| tez.am.task.max.failed.attempts | 태스크에 실패하기 전에 특정 태스크에 대해 실패할 수 있는 최대 시도 횟수. 이 수치는 수동으로 종료된 시도를 계산에 포함하지 않습니다. | 3 |
| tez.am.vertex.cleanup.height | 모든 종속 버텍스가 완료된 경우 Tez AM에서 버텍스 셔플 데이터를 삭제하는 거리. 값이 0이면 이 기능이 꺼집니다. Amazon EMR 버전 6.8.0 이상에서 이 기능을 지원합니다. | 0 |
| tez.client.asynchronous-stop | EMR Serverless가 Hive 드라이버를 종료하기 전에 ATS 이벤트를 푸시하도록 하는 옵션. | FALSE |
| tez.grouping.max-size | 그룹화된 분할의 크기 상한(바이트). 이 제한은 지나치게 큰 분할을 방지합니다. | 1073741824 |
| tez.grouping.min-size | 그룹화된 분할의 크기 하한(바이트). 이 제한은 너무 많은 작은 분할을 방지합니다. | 16777216 |
| tez.runtime.io.sort.mb | Tez가 출력을 정렬하는 경우 소프트 버퍼의 크기가 정렬됩니다. | 최적의 값은 Tez 태스크 메모리를 기반으로 계산됩니다. |
| tez.runtime.unordered.output.buffer.size-mb | Tez에서 디스크에 직접 쓰지 않는 경우 사용할 버퍼의 크기. | 최적의 값은 Tez 태스크 메모리를 기반으로 계산됩니다. |
| tez.shuffle-vertex-manager.max-src-fraction | EMR Serverless에서 현재 버텍스에 대한 모든 태스크를 예약하기 전에 완료해야 하는 소스 태스크의 비율(ScatterGather 연결의 경우). 현재 버텍스에서 예약할 준비가 된 작업 수는 min-fraction\$1max-fraction 사이에서 선형으로 조정됩니다. 이 값은 기본값 또는 tez.shuffle-vertex-manager.min-src-fraction 중 큰 값으로 설정됩니다. | 0.75 |
| tez.shuffle-vertex-manager.min-src-fraction | EMR Serverless에서 현재 버텍스에 대한 태스크를 예약하기 전에 완료해야 하는 소스 태스크의 비율(ScatterGather 연결의 경우). | 0.25 |
| tez.task.emr-serverless.launch.env.[KEY] | Tez 태스크 프로세스에서 KEY 환경 변수를 설정하는 옵션. Tez 태스크의 경우 이 값은 hive.emr-serverless.launch.env.[KEY] 값을 재정의합니다. | |
| tez.task.log.level | EMR Serverless가 Tez 태스크에 전달하는 루트 로깅 수준. | INFO |
| tez.yarn.ats.event.flush.timeout.millis | 종료하기 전에 이벤트가 플러시될 때까지 AM에서 기다려야 하는 최대 시간. | 300000 |
## Hive 작업 예제
다음 코드 예제에서는 `StartJobRun` API를 사용하여 Hive 쿼리를 실행하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/emr-serverless-hive/query/hive-query.ql",
"parameters": "--hiveconf hive.log.explain.output=false"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.exec.scratchdir": "s3://amzn-s3-demo-bucket/emr-serverless-hive/hive/scratch",
"hive.metastore.warehouse.dir": "s3://amzn-s3-demo-bucket/emr-serverless-hive/hive/warehouse",
"hive.driver.cores": "2",
"hive.driver.memory": "4g",
"hive.tez.container.size": "4096",
"hive.tez.cpu.vcores": "1"
}
}]
}'
```
[EMR Serverless Samples](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/hive) GitHub 리포지토리에서 Hive 작업을 실행하는 방법에 대한 추가 예제를 찾을 수 있습니다.
# EMR Serverless 작업 복원력
EMR Serverless 릴리스 7.1.0 이상에는 작업 복원력에 대한 지원이 포함되어 있으므로 수동으로 입력하지 않고도 실패한 작업을 자동으로 재시도합니다. 작업 복원력의 또 다른 이점은 AZ에 문제가 발생할 경우 EMR Serverless가 작업 실행을 다른 가용 영역(AZ)으로 이동한다는 점입니다.
작업에 대한 작업 복원력을 활성화하려면 작업에 대한 재시도 정책을 설정합니다. 재시도 정책은 언제라도 실패하면 EMR Serverless에서 작업을 자동으로 재시작하도록 보장합니다. 배치 작업 및 스트리밍 작업 모두에 대해 재시도 정책이 지원되므로 사용 사례에 따라 작업 복원력을 사용자 지정합니다. 다음 표에서는 배치 및 스트리밍 작업 간 작업 복원력의 동작과 차이를 비교합니다.
| | Batch 작업 | 스트리밍 작업 |
| --- | --- | --- |
| 기본 동작 | 작업을 다시 실행하지 않습니다. | 애플리케이션이 작업을 실행하는 동안 체크포인트를 생성하므로 항상 작업 실행을 재시도합니다. |
| 재시도 지점 | 배치 작업에는 체크포인트가 없으므로 EMR Serverless는 항상 처음부터 다시 작업을 실행합니다. | 스트리밍 작업은 체크포인트를 지원하므로, Amazon S3의 체크포인트 위치에 런타임 상태 및 진행 상황을 저장하도록 스트리밍 쿼리를 구성합니다. EMR Serverless는 체크포인트에서 작업 실행을 재개합니다. 자세한 내용은 Apache Spark 설명서의 [Recovering from failures with Checkpointing](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing)을 참조하세요. |
| 최대 재시도 횟수 | 최대 10회의 재시도를 허용합니다. | 스트리밍 작업에는 기본 제공 스래시 방지 제어 기능이 있으므로 1시간 후에도 계속 실패하면 애플리케이션은 작업 재시도를 중지합니다. 1시간 내 기본 재시도 횟수는 5회입니다. 이 재시도 횟수를 1\$110회로 구성할 수 있습니다. 최대 시도 횟수는 사용자 지정할 수 없습니다. 값이 1이면 재시도를 수행하지 않음을 나타냅니다. |
EMR Serverless에서 작업을 재실행하려고 하면 시도 번호로 작업을 인덱싱하므로 시도 전반에 걸쳐 작업의 수명 주기를 추적합니다.
EMR Serverless API 작업 또는 AWS CLI 를 사용하여 작업 복원력을 변경하거나 작업 복원력과 관련된 정보에 액세스합니다. 자세한 내용은 [EMR Serverless API 안내서](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html)를 참조하세요.
기본적으로 EMR Serverless는 배치 작업을 재실행하지 않습니다. 배치 작업에 대한 재시도를 활성화하려면 배치 작업 실행을 시작할 때 `maxAttempts` 파라미터를 구성합니다. `maxAttempts` 파라미터는 배치 작업에만 적용됩니다. 기본값은 1입니다. 작업을 다시 실행하지 않음을 의미합니다. 허용되는 값은 1\$110(경계 포함)입니다.
다음 예제에서는 작업 실행을 시작할 때 최대 10회의 시도 횟수를 지정하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run
--application-id \
--execution-role-arn \
--mode 'BATCH' \
--retry-policy '{
"maxAttempts": 10
}' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
}
}'
```
EMR Serverless는 스트리밍 작업이 실패할 경우 스트리밍 작업을 제한 없이 재시도합니다. 복구할 수 없는 반복 장애로 인한 스래싱을 방지하려면 `maxFailedAttemptsPerHour`를 사용하여 스트리밍 작업 재시도에 대한 스래시 방지 제어를 구성합니다. 이 파라미터를 사용하면 EMR Serverless에서 재시도를 중지하기 1시간 전에 허용되는 최대 실패 시도 횟수를 지정할 수 있습니다. 기본값은 5입니다. 허용되는 값은 1\$110(경계 포함)입니다.
```
aws emr-serverless start-job-run
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--retry-policy '{
"maxFailedAttemptsPerHour": 7
}' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
}
}'
```
또한 다른 작업 실행 API 작업을 사용하여 작업에 대한 정보를 얻을 수도 있습니다. 예를 들어, `GetJobRun` 작업과 함께 `attempt` 파라미터를 사용하여 특정 작업 시도에 대한 세부 정보를 가져올 수 있습니다. `attempt` 파라미터를 포함하지 않는 경우 작업은 최신 시도에 대한 정보를 반환합니다.
```
aws emr-serverless get-job-run \
--job-run-id job-run-id \
--application-id application-id \
--attempt 1
```
`ListJobRunAttempts` 작업은 작업 실행과 관련된 모든 시도에 대한 정보를 반환합니다.
```
aws emr-serverless list-job-run-attempts \
--application-id application-id \
--job-run-id job-run-id
```
`GetDashboardForJobRun` 작업은 작업 실행을 위해 애플리케이션 UI에 액세스하는 데 사용하는 URL을 생성하고 반환합니다. `attempt` 파라미터를 사용하면 특정 시도에 대한 URL을 가져올 수 있습니다. `attempt` 파라미터를 포함하지 않는 경우 작업은 최신 시도에 대한 정보를 반환합니다.
```
aws emr-serverless get-dashboard-for-job-run \
--application-id application-id \
--job-run-id job-run-id \
--attempt 1
```
## 재시도 정책으로 작업 모니터링
또한 작업 복원력 지원에는 새 이벤트 **EMR Serverless 작업 실행 재시도**가 추가되었습니다. EMR Serverless는 작업을 재시도할 때마다 이 이벤트를 게시합니다. 이 알림을 사용하여 작업 재시도를 추적할 수 있습니다. 이벤트에 자세한 내용은 [Amazon EventBridge 이벤트](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html)를 참조하세요.
## 재시도 정책을 사용한 로깅
EMR Serverless가 작업을 재시도할 때마다 자체 로그 세트가 생성됩니다. EMR Serverless가 덮어쓰지 않고 이러한 로그를 Amazon S3 및 Amazon CloudWatch에 전달할 수 있도록 하기 위해 EMR Serverless는 S3 로그 경로 및 CloudWatch 로그 스트림 이름의 형식에 작업의 시도 번호를 포함하도록 접두사를 추가합니다.
다음은 해당 형식에 대한 예제입니다.
```
'/applications//jobs//attempts//'.
```
이 형식을 사용하면 EMR Serverless가 각 작업 시도에 대한 모든 로그를 Amazon S3 및 CloudWatch의 지정된 위치에 게시할 수 있습니다. 자세한 내용을 알아보려면 [로그 저장](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html)을 참조하세요.
**참고**
EMR Serverless는 재시도가 활성화된 모든 배치 작업 및 모든 스트리밍 작업에서만 이 접두사 형식을 사용합니다.
# EMR Serverless에 대한 메타스토어 구성
*Hive 메타스토어*는 스키마, 파티션 이름 및 데이터 유형을 포함하여 테이블에 대한 구조 정보를 저장하는 중앙 집중식 위치입니다. EMR Serverless를 사용하면 작업에 액세스할 수 있는 메타스토어에서 이 테이블 메타데이터를 유지할 수 있습니다.
Hive 메타스토어에 대한 두 가지 옵션이 있습니다.
+ AWS Glue 데이터 카탈로그
+ 외부 Apache Hive 메타스토어
## Glue 데이터 카탈로그를 AWS 메타스토어로 사용
Glue 데이터 카탈로그를 AWS 메타스토어로 사용하도록 Spark 및 Hive 작업을 구성할 수 있습니다. 영구 메타스토어가 필요하거나 여러 애플리케이션, 서비스 또는 AWS 계정에서 메타스토어를 공유해야 하는 경우에 이 구성을 사용하는 것이 좋습니다. 데이터 카탈로그에 대한 자세한 내용은 [AWS Glue 데이터 카탈로그 채우기를 참조하세요](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html). AWS Glue 요금에 대한 자세한 내용은 [AWS Glue 요금을](https://aws.amazon.com/glue/pricing) 참조하세요.
애플리케이션 AWS 계정 과 동일한 또는 다른에서 AWS Glue 데이터 카탈로그를 사용하도록 EMR Serverless 작업을 구성할 수 있습니다 AWS 계정.
### AWS Glue 데이터 카탈로그 구성
Data Catalog를 구성하려면 사용할 EMR Serverless 애플리케이션 유형을 선택합니다.
------
#### [ Spark ]
EMR Studio를 사용하여 EMR Serverless Spark 애플리케이션에서 작업을 실행하는 경우 Glue 데이터 카탈로그가 기본 AWS 메타스토어입니다.
SDKs 사용하는 경우 작업 실행의 `sparkSubmit` 파라미터`com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory`에서 `spark.hadoop.hive.metastore.client.factory.class` 구성을 로 AWS CLI설정합니다. 다음 예제에서는 AWS CLI를 사용하여 Data Catalog를 구성하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/code/pyspark/extreme_weather.py",
"sparkSubmitParameters": "--conf spark.hadoop.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory --conf spark.driver.cores=1 --conf spark.driver.memory=3g --conf spark.executor.cores=4 --conf spark.executor.memory=3g"
}
}'
```
또는 Spark 코드에서 새 `SparkSession`을 생성할 때 이 구성을 설정할 수 있습니다.
```
from pyspark.sql import SparkSession
spark = (
SparkSession.builder.appName("SparkSQL")
.config(
"spark.hadoop.hive.metastore.client.factory.class",
"com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory",
)
.enableHiveSupport()
.getOrCreate()
)
# we can query tables with SparkSQL
spark.sql("SHOW TABLES").show()
# we can also them with native Spark
print(spark.catalog.listTables())
```
------
#### [ Hive ]
EMR Serverless Hive 애플리케이션의 경우 Data Catalog가 기본 메타스토어입니다. 즉, EMR Serverless Hive 애플리케이션에서 작업을 실행하면 Hive는 애플리케이션 AWS 계정 과 동일한의 데이터 카탈로그에 메타스토어 정보를 기록합니다. Data Catalog를 메타스토어로 사용하기 위해 가상 프라이빗 클라우드(VPC)가 필요하지 않습니다.
Hive 메타스토어 테이블에 액세스하려면 AWS Glue에 [대한 IAM 권한 설정에 설명된 필수 AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/getting-started-access.html) 정책을 추가합니다.
------
### EMR Serverless 및 AWS Glue 데이터 카탈로그에 대한 교차 계정 액세스 구성
EMR Serverless에 대한 교차 계정 액세스를 설정하려면 먼저 AWS 계정다음에 로그인합니다.
+ `AccountA` - EMR Serverless 애플리케이션을 생성한 AWS 계정 입니다.
+ `AccountB` - EMR Serverless 작업이 액세스하도록 실행하려는 AWS Glue 데이터 카탈로그가 AWS 계정 포함된 입니다.
1. `AccountB`의 관리자 또는 기타 승인된 자격 증명이 `AccountB`의 Data Catalog에 리소스 정책을 연결해야 합니다. 이 정책은 `AccountB` 카탈로그의 리소스에서 작업을 수행할 수 있는 `AccountA`별 교차 계정 권한을 부여합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:*:123456789012:catalog"
],
"Sid": "AllowGLUEGetdatabase"
}
]
}
```
------
1. 역할이 `AccountB`의 Data Catalog 리소스에 액세스할 수 있도록 `AccountA`에서 EMR Serverless 작업 런타임 역할에 IAM 정책을 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:*:123456789012:catalog"
],
"Sid": "AllowGLUEGetdatabase"
}
]
}
```
------
1. 작업 실행을 시작합니다. 이 단계는 `AccountA`의 EMR Serverless 애플리케이션 유형에 따라 약간 다릅니다.
------
#### [ Spark ]
다음 예제와 같이 `spark.hadoop.hive.metastore.glue.catalogid`에서 `sparkSubmitParameters` 속성을 설정합니다. *`AccountB-catalog-id`*를 `AccountB`의 Data Catalog ID로 바꿉니다.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/scripts/test.py",
"sparkSubmitParameters": "--conf spark.hadoop.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory --conf spark.hadoop.hive.metastore.glue.catalogid=AccountB-catalog-id --conf spark.executor.cores=1 --conf spark.executor.memory=1g --conf spark.driver.cores=1 --conf spark.driver.memory=1g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/logs/"
}
}
}'
```
------
#### [ Hive ]
다음 예제와 같이 `hive.metastore.glue.catalogid` 분류에서 `hive-site` 속성을 설정합니다. *`AccountB-catalog-id`*를 `AccountB`의 Data Catalog ID로 바꿉니다.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/hive/scripts/create_table.sql",
"parameters": "--hiveconf hive.exec.scratchdir=s3://amzn-s3-demo-bucket/hive/scratch --hiveconf hive.metastore.warehouse.dir=s3://amzn-s3-demo-bucket/hive/warehouse"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.metastore.glue.catalogid": "AccountB-catalog-id"
}
}]
}'
```
------
### AWS Glue 데이터 카탈로그 사용 시 고려 사항
Hive 스크립트에서 `ADD JAR`을 사용하여 보조 JAR을 추가할 수 있습니다. 추가 고려 사항은 [AWS Glue 데이터 카탈로그 사용 시 고려 사항을](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html#emr-hive-glue-considerations-hive) 참조하세요.
# 외부 Hive 메타스토어 사용
Amazon Aurora 또는 Amazon RDS for MySQL과 같은 외부 Hive 메타스토어에 연결하도록 EMR Serverless Spark 및 Hive 작업을 구성할 수 있습니다. 이 섹션에서는 Amazon RDS Hive 메타스토어를 설정하고, VPC를 구성하며, 외부 메타스토어를 사용하도록 EMR Serverless 작업을 구성하는 방법을 설명합니다.
## 외부 Hive 메타스토어 생성
1. [VPC 생성](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC)의 지침에 따라 프라이빗 서브넷이 있는 Amazon Virtual Private Cloud(Amazon VPC)를 생성합니다.
1. 새 Amazon VPC 및 프라이빗 서브넷을 사용하여 EMR Serverless 애플리케이션을 생성합니다. VPC에서 EMR Serverless 애플리케이션을 구성하는 경우 먼저 지정한 각 서브넷에 대해 탄력적 네트워크 인터페이스를 프로비저닝합니다. 그러면 지정된 보안 그룹이 해당 네트워크 인터페이스에 연결합니다. 이렇게 하면 애플리케이션 액세스 제어 기능이 지원됩니다. VPC를 설정하는 방법에 대한 자세한 내용은 [데이터에 연결하도록 EMR Serverless 애플리케이션에 대한 VPC 액세스 구성](vpc-access.md) 섹션을 참조하세요.
1. Amazon VPC의 프라이빗 서브넷에서 MySQL 또는 Aurora PostgreSQL 데이터베이스를 생성합니다. Amazon RDS 데이터베이스 생성 방법에 대한 자세한 내용은 [Amazon RDS DB 인스턴스 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html)을 참조하세요.
1. [Amazon RDS DB 인스턴스 수정](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html)의 단계에 따라 EMR Serverless 보안 그룹에서 JDBC 연결을 허용하도록 MySQL 또는 Aurora 데이터베이스의 보안 그룹을 수정합니다. EMR Serverless 보안 그룹 중 하나에서 RDS 보안 그룹에 인바운드 트래픽 규칙을 추가합니다.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/emr/latest/EMR-Serverless-UserGuide/external-metastore.html)
## Spark 옵션 구성
**JDBC 사용**
Amazon RDS for MySQL 또는 Amazon Aurora MySQL 인스턴스를 기반으로 Hive 메타스토어에 연결하도록 EMR Serverless Spark 애플리케이션을 구성하려면 JDBC 연결을 사용합니다. 작업 실행의 `spark-submit` 파라미터에서 `--jars`와 함께 `mariadb-connector-java.jar`을 전달합니다.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/scripts/spark-jdbc.py",
"sparkSubmitParameters": "--jars s3://amzn-s3-demo-bucket/mariadb-connector-java.jar
--conf spark.hadoop.javax.jdo.option.ConnectionDriverName=org.mariadb.jdbc.Driver
--conf spark.hadoop.javax.jdo.option.ConnectionUserName=
--conf spark.hadoop.javax.jdo.option.ConnectionPassword=
--conf spark.hadoop.javax.jdo.option.ConnectionURL=
--conf spark.driver.cores=2
--conf spark.executor.memory=10G
--conf spark.driver.memory=6G
--conf spark.executor.cores=4"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/spark/logs/"
}
}
}'
```
다음 코드 예제는 Amazon RDS에서 Hive 메타스토어와 상호 작용하는 Spark 진입점 스크립트입니다.
```
from os.path import expanduser, join, abspath
from pyspark.sql import SparkSession
from pyspark.sql import Row
# warehouse_location points to the default location for managed databases and tables
warehouse_location = abspath('spark-warehouse')
spark = SparkSession \
.builder \
.config("spark.sql.warehouse.dir", warehouse_location) \
.enableHiveSupport() \
.getOrCreate()
spark.sql("SHOW DATABASES").show()
spark.sql("CREATE EXTERNAL TABLE `sampledb`.`sparknyctaxi`(`dispatching_base_num` string, `pickup_datetime` string, `dropoff_datetime` string, `pulocationid` bigint, `dolocationid` bigint, `sr_flag` bigint) STORED AS PARQUET LOCATION 's3:///nyctaxi_parquet/'")
spark.sql("SELECT count(*) FROM sampledb.sparknyctaxi").show()
spark.stop()
```
**Thrift 서비스 사용**
Amazon RDS for MySQL 또는 Amazon Aurora MySQL 인스턴스를 기반으로 Hive 메타스토어에 연결하도록 EMR Serverless Hive 애플리케이션을 구성할 수 있습니다. 이를 수행하려면 기존 Amazon EMR 클러스터의 기본 노드에서 Thrift 서버를 실행합니다. 이 옵션은 EMR Serverless 작업 구성을 단순화하는 데 사용할 Thrift 서버가 있는 Amazon EMR 클러스터가 이미 있는 경우에 적합합니다.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/thriftscript.py",
"sparkSubmitParameters": "--jars s3://amzn-s3-demo-bucket/mariadb-connector-java.jar
--conf spark.driver.cores=2
--conf spark.executor.memory=10G
--conf spark.driver.memory=6G
--conf spark.executor.cores=4"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/spark/logs/"
}
}
}'
```
다음 코드 예제는 Thrift 프로토콜을 사용하여 Hive 메타스토어에 연결하는 진입점 스크립트(`thriftscript.py`)입니다. `hive.metastore.uris` 속성은 외부 Hive 메타스토어에서 읽도록 설정해야 합니다.
```
from os.path import expanduser, join, abspath
from pyspark.sql import SparkSession
from pyspark.sql import Row
# warehouse_location points to the default location for managed databases and tables
warehouse_location = abspath('spark-warehouse')
spark = SparkSession \
.builder \
.config("spark.sql.warehouse.dir", warehouse_location) \
.config("hive.metastore.uris","thrift://thrift-server-host:thift-server-port") \
.enableHiveSupport() \
.getOrCreate()
spark.sql("SHOW DATABASES").show()
spark.sql("CREATE EXTERNAL TABLE sampledb.`sparknyctaxi`( `dispatching_base_num` string, `pickup_datetime` string, `dropoff_datetime` string, `pulocationid` bigint, `dolocationid` bigint, `sr_flag` bigint) STORED AS PARQUET LOCATION 's3:///nyctaxi_parquet/'")
spark.sql("SELECT * FROM sampledb.sparknyctaxi").show()
spark.stop()
```
## Hive 옵션 구성
**JDBC 사용**
Amazon RDS MySQL 또는 Amazon Aurora 인스턴스에서 외부 Hive 데이터베이스 위치를 지정하려는 경우 기본 메타스토어 구성을 재정의할 수 있습니다.
**참고**
Hive에서 메타스토어 테이블에 대한 여러 쓰기를 동시에 수행할 수 있습니다. 두 클러스터 사이에서 메타스토어 정보를 공유하는 경우, 동일한 메타스토어 테이블의 다른 파티션에 쓰고 있지 않은 한, 동시에 동일한 메타스토어 테이블에 쓰지 않도록 해야 합니다.
`hive-site` 분류에서 다음 구성을 설정하여 외부 Hive 메타스토어를 활성화합니다.
```
{
"classification": "hive-site",
"properties": {
"hive.metastore.client.factory.class": "org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClientFactory",
"javax.jdo.option.ConnectionDriverName": "org.mariadb.jdbc.Driver",
"javax.jdo.option.ConnectionURL": "jdbc:mysql://db-host:db-port/db-name",
"javax.jdo.option.ConnectionUserName": "username",
"javax.jdo.option.ConnectionPassword": "password"
}
}
```
**Thrift 서버 사용**
Amazon RDS for MySQL 또는 Amazon Aurora MySQL 인스턴스를 기반으로 Hive 메타스토어에 연결하도록 EMR Serverless Hive 애플리케이션을 구성할 수 있습니다. 이를 수행하려면 기존 Amazon EMR 클러스터의 메인 노드에서 Thrift 서버를 실행합니다. 이 옵션은 Thrift 서버를 실행하고 EMR Serverless 작업 구성을 사용하려는 Amazon EMR 클러스터가 이미 있는 경우에 적합합니다.
EMR Serverless가 원격 Thrift 메타스토어에 액세스할 수 있도록 `hive-site` 분류에서 다음 구성을 설정합니다. 외부 Hive 메타스토어에서 읽도록 `hive.metastore.uris` 속성을 설정해야 합니다.
```
{
"classification": "hive-site",
"properties": {
"hive.metastore.client.factory.class": "org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClientFactory",
"hive.metastore.uris": "thrift://thrift-server-host:thirft-server-port"
}
}
```
# EMR Serverless에서 AWS Glue 다중 카탈로그 계층 구조 작업
AWS Glue 다중 카탈로그 계층 구조에서 작동하도록 EMR Serverless 애플리케이션을 구성할 수 있습니다. 다음 예제에서는 AWS Glue 다중 카탈로그 계층 구조에서 EMR-S Spark를 사용하는 방법을 보여줍니다.
다중 카탈로그 계층 구조에 대해 자세히 알아보려면 [Amazon EMR에서 Spark를 사용하여 AWS Glue Data Catalog의 다중 카탈로그 계층 구조 작업을 참조하세요](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Iceberg 및 AWS Glue 데이터 카탈로그와 함께 Redshift Managed Storage(RMS) 사용
다음은 Iceberg와 AWS Glue 데이터 카탈로그의 통합을 위해 Spark를 구성하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/myscript.py",
"sparkSubmitParameters": "--conf spark.sql.catalog.nfgac_rms = org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.rms.type=glue
--conf spark.sql.catalog.rms.glue.id=Glue RMS catalog ID
--conf spark.sql.defaultCatalog=rms
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
}
}'
```
통합 후 카탈로그에 있는 테이블의 샘플 쿼리:
```
SELECT * FROM my_rms_schema.my_table
```
## Iceberg REST API 및 AWS Glue 데이터 카탈로그와 함께 Redshift Managed Storage(RMS) 사용
다음은 Spark를 Iceberg REST 카탈로그와 함께 작동하도록 구성하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/myscript.py",
"sparkSubmitParameters": "
--conf spark.sql.catalog.rms=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.rms.type=rest
--conf spark.sql.catalog.rms.warehouse=Glue RMS catalog ID
--conf spark.sql.catalog.rms.uri=Glue endpoint URI/iceberg
--conf spark.sql.catalog.rms.rest.sigv4-enabled=true
--conf spark.sql.catalog.rms.rest.signing-name=glue
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
}
}'
```
카탈로그에 있는 테이블의 샘플 쿼리:
```
SELECT * FROM my_rms_schema.my_table
```
# 외부 메타스토어 사용 시 고려 사항
+ MariaDB JDBC와 호환되는 데이터베이스를 메타스토어로 구성할 수 있습니다. 이러한 데이터베이스의 예로는, RDS for MariaDB, MySQL, Amazon Aurora가 있습니다.
+ 메타스토어는 자동으로 초기화되지 않습니다. 메타스토어가 Hive 버전의 스키마로 초기화되지 않은 경우 [Hive 스키마 도구](https://cwiki.apache.org/confluence/display/Hive/Hive+Schema+Tool)를 사용합니다.
+ EMR Serverless는 Kerberos 인증을 지원하지 않습니다. EMR Serverless Spark 또는 Hive 작업에서는 Kerberos 인증과 함께 Thrift 메타스토어 서버를 사용할 수 없습니다.
+ 다중 카탈로그 계층 구조를 사용하도록 VPC 액세스를 구성합니다.
# EMR Serverless에서 다른 AWS 계정의 S3 데이터 액세스
한 AWS 계정에서 Amazon EMR Serverless 작업을 실행하고 다른 계정에 속한 Amazon S3 버킷의 데이터에 액세스하도록 구성할 수 AWS 있습니다. 이 페이지에서는 EMR Serverless에서 S3에 대한 교차 계정 액세스를 구성하는 방법을 설명합니다.
EMR Serverless에서 실행되는 작업은 S3 버킷 정책 또는 수임된 역할을 사용하여 다른 AWS 계정에서 Amazon S3의 데이터에 액세스할 수 있습니다.
## 사전 조건
Amazon EMR Serverless에 대한 교차 계정 액세스를 설정하려면 두 AWS 계정에 로그인한 상태에서 작업을 완료합니다.
+ **`AccountA`** - Amazon EMR Serverless 애플리케이션을 생성한 AWS 계정입니다. 교차 계정 액세스를 설정하기 전에 이 계정에서 다음과 같은 준비를 완료합니다.
+ 작업을 실행하려는 Amazon EMR Serverless 애플리케이션.
+ 애플리케이션에서 작업을 실행하는 데 필요한 권한이 있는 작업 실행 역할. 자세한 정보는 [Amazon EMR Serverless에 대한 작업 런타임 역할](security-iam-runtime-role.md) 섹션을 참조하세요.
+ **`AccountB`** - Amazon EMR Serverless 작업에서 액세스하려는 S3 버킷이 포함된 AWS 계정입니다.
## S3 버킷 정책을 사용하여 교차 계정 S3 데이터에 액세스
account A에서 account B의 S3 버킷에 액세스하려면 다음 정책을 account B의 S3 버킷에 연결합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePermissions1",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket-name"
]
},
{
"Sid": "ExamplePermissions2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::my-bucket-name/*"
]
}
]
}
```
------
S3 버킷 정책을 통한 S3 교차 계정 액세스에 대한 자세한 내용은 **Amazon Simple Storage Service 사용 설명서의 [예제 2: 버킷 소유자가 교차 계정 버킷 권한 부여](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html)를 참조하세요.
## 수임된 역할을 사용하여 교차 계정 S3 데이터에 액세스
Amazon EMR Serverless에 대한 교차 계정 액세스를 설정하는 또 다른 방법은 AWS Security Token Service (AWS STS)의 `AssumeRole` 작업을 사용하는 것입니다.는 사용자에게 제한된 권한의 임시 자격 증명을 요청할 수 있는 글로벌 웹 서비스 AWS STS 입니다. `AssumeRole`로 생성한 임시 보안 자격 증명을 사용하여 EMR Serverless 및 Amazon S3에 대해 API 직접 호출을 수행할 수 있습니다.
다음 단계에서는 수임된 역할을 사용하여 EMR Serverless에서 교차 계정 S3 데이터에 액세스하는 방법을 보여줍니다.
1. `AccountB`에서 Amazon S3 버킷(*cross-account-bucket*)을 생성합니다. 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [버킷 생성](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)을 참조하세요. DynamoDB에 대한 크로스 계정 액세스를 원하는 경우 `AccountB`에서 DynamoDB 테이블을 생성합니다. 자세한 내용은 **Amazon DynamoDB 개발자 안내서의 [DynamoDB 테이블 생성](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html)을 참조하세요.
1. *교차 계정 버킷*에 액세스할 수 `AccountB`에서 `Cross-Account-Role-B` IAM 역할을 생성합니다.
1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) IAM 콘솔을 엽니다.
1. **역할**을 선택하고 새 역할(`Cross-Account-Role-B`)을 생성합니다. IAM 역할 생성에 대한 자세한 내용은 IAM 사용 설명서의 [IAM 역할 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html)을 참조하세요.
1. 다음 정책 명령문에서 볼 수 있듯이 *cross-account-bucket* S3 버킷에 액세스할 수 있는 `Cross-Account-Role-B`에 대한 권한을 지정하는 IAM 정책을 생성합니다. 그런 다음, IAM 정책을 `Cross-Account-Role-B`에 연결합니다. 자세한 내용은 *IAM 사용자 설명서*에서 [IAM 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)을 참조하세요.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::cross-account-bucket",
"arn:aws:s3:::cross-account-bucket/*"
],
"Sid": "AllowS3"
}
]
}
```
------
DynamoDB 액세스가 필요한 경우 교차 계정 DynamoDB 테이블에 액세스할 권한을 지정하는 IAM 정책을 생성합니다. 그런 다음, IAM 정책을 `Cross-Account-Role-B`에 연결합니다. 자세한 내용은 *IAM 사용 설명서*의 [Amazon DynamoDB: 특정 테이블에 대한 액세스 허용](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html)을 참조하세요.
다음은 DynamoDB 테이블(`CrossAccountTable`)에 대한 액세스를 허용하는 정책입니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:*:123456789012:table/CrossAccountTable"
],
"Sid": "AllowDYNAMODB"
}
]
}
```
------
1. `Cross-Account-Role-B` 역할에 대한 신뢰 관계를 편집합니다.
1. 역할에 대한 신뢰 관계를 구성하려면 2단계에서 생성한 역할(`Cross-Account-Role-B`)에 대해 IAM 콘솔에서 **신뢰 관계** 탭을 선택합니다.
1. **신뢰 관계 편집**을 선택합니다.
1. 다음 정책 문서를 추가합니다. 그러면 `AccountA`에서 `Job-Execution-Role-A`가 `Cross-Account-Role-B` 역할을 수임할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/Job-Execution-Role-A",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
1. `AccountA`를 AWS STS 수임할 수 있는 `AssumeRole` 권한을 `Job-Execution-Role-A`에 부여합니다`Cross-Account-Role-B`.
1. AWS 계정의 IAM 콘솔에서를 `AccountA`선택합니다`Job-Execution-Role-A`.
1. 다음 정책 명령을 `Job-Execution-Role-A`에 추가하여 `Cross-Account-Role-B` 역할에서 `AssumeRole` 작업을 허용합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Cross-Account-Role-B"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
## 수임된 역할 예제
계정 내 모든 S3 리소스에 액세스하기 위해 단일 역할을 사용하거나, Amazon EMR 6.11 이상 버전에서는 서로 다른 계정 간 S3 버킷에 액세스할 때 적용할 여러 IAM 역할을 구성할 수 있습니다.
**Topics**
+ [
### 하나의 수임된 역할로 S3 리소스에 액세스
](#jobs-s3-access-how-to-assumed-role-single)
+ [
### 여러 수임된 역할로 S3 리소스에 액세스
](#jobs-s3-access-how-to-assumed-role-multiple)
### 하나의 수임된 역할로 S3 리소스에 액세스
**참고**
단일 수임된 역할을 사용하도록 작업을 구성하면 `entryPoint` 스크립트를 포함하여 작업 전반의 모든 S3 리소스가 해당 역할을 사용합니다.
단일 수임된 역할을 사용하여 계정 B의 모든 S3 리소스에 액세스하려면 다음 구성을 지정합니다.
1. EMRFS 구성 `fs.s3.customAWSCredentialsProvider`를 `com.amazonaws.emr.AssumeRoleAWSCredentialsProvider`로 지정합니다.
1. Spark의 경우 `spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` 및 `spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`을 사용하여 드라이버 및 실행기에서 환경 변수를 지정합니다.
1. Hive의 경우 `hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`, `tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`, `tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`을 사용하여 Hive 드라이버, Tez 애플리케이션 기본 및 Tez 태스크 컨테이너에서 환경 변수를 지정합니다.
다음 예제에서는 가정된 역할을 사용하여 교차 계정 액세스로 EMR Serverless 작업 실행을 시작하는 방법을 보여줍니다.
------
#### [ Spark ]
다음 예제에서는 S3에 대한 교차 계정 액세스로 EMR Serverless Spark 작업 실행을 시작하기 위해 수임된 역할을 사용하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "entrypoint_location",
"entryPointArguments": [":argument_1:", ":argument_2:"],
"sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "spark-defaults",
"properties": {
"spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.AssumeRoleAWSCredentialsProvider",
"spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
}
}]
}'
```
------
#### [ Hive ]
다음 예제에서는 S3에 대한 교차 계정 액세스로 EMR Serverless Hive 작업 실행을 시작하기 위해 수임된 역할을 사용하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "query_location",
"parameters": "hive_parameters"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
"hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
}
}]
}'
```
------
### 여러 수임된 역할로 S3 리소스에 액세스
EMR Serverless 릴리스 6.11.0 이상을 사용하면 여러 교차 계정 버킷에 액세스할 때 가정할 여러 IAM 역할을 구성할 수 있습니다. 계정 B의 여러 수임된 역할을 사용하여 다른 S3 리소스에 액세스하려면 작업 실행을 시작할 때 다음 구성을 사용합니다.
1. EMRFS 구성 `fs.s3.customAWSCredentialsProvider`를 `com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider`로 지정합니다.
1. S3 버킷 이름에서 수임할 계정 B의 IAM 역할로의 매핑을 정의하려면 EMRFS 구성 `fs.s3.bucketLevelAssumeRoleMapping`을 지정합니다. 값은 `bucket1->role1;bucket2->role2` 형식이어야 합니다.
예를 들어, `arn:aws:iam::AccountB:role/Cross-Account-Role-B-1`을 사용하여 버킷 `bucket1`에 액세스하고 `arn:aws:iam::AccountB:role/Cross-Account-Role-B-2`를 사용하여 버킷 `bucket2`에 액세스할 수 있습니다. 다음 예시는 여러 계정 간 역할을 통해 계정 간 액세스로 EMR Serverless 작업 실행을 시작하는 방법을 보여줍니다.
------
#### [ Spark ]
다음 예제에서는 여러 수임된 역할을 사용하여 EMR Serverless Spark 작업 실행을 생성하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "entrypoint_location",
"entryPointArguments": [":argument_1:", ":argument_2:"],
"sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "spark-defaults",
"properties": {
"spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider",
"spark.hadoop.fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
}
}]
}'
```
------
#### [ Hive ]
다음 예는 가정된 여러 역할을 사용하여 EMR Serverless Hive 작업 실행을 생성하는 방법을 보여줍니다.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "query_location",
"parameters": "hive_parameters"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
"fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
}
}]
}'
```
------
# EMR Serverless에서 오류 해결
다음 정보를 사용하여 Amazon EMR Serverless 작업 시 발생하는 일반적인 문제를 진단하고 수정할 수 있습니다.
**Topics**
+ [
## 오류: 계정이 동시에 사용할 수 있는 최대 vCPU의 서비스 제한에 도달하여 작업이 실패했습니다.
](#jobs-troubleshoot-allowed-capacity-vcpu)
+ [
## 오류: 애플리케이션이 maximumCapacity 설정을 초과하여 작업이 실패했습니다.
](#jobs-troubleshoot-maxcapacity)
+ [
## 오류: 애플리케이션이 maximumCapacity를 초과하여 워커를 할당할 수 없어 작업이 실패했습니다.
](#jobs-troubleshoot-worker-allocated)
+ [
## 오류: S3 액세스가 거부되었습니다. 필요한 S3 리소스에서 작업 런타임 역할의 S3 액세스 권한을 확인하세요.
](#jobs-troubleshoot-s3)
+ [
## 오류: ModuleNotFoundError: 모듈이 없습니다. EMR Serverless에서 Python 라이브러리를 사용하는 방법은 사용 설명서를 참조하세요.
](#jobs-troubleshoot-module)
+ [
## 오류: 역할을 수임할 수 없습니다. 해당 역할이 없거나 필요한 신뢰 관계로 설정되지 않았기 때문입니다.
](#jobs-troubleshoot-runtime-role)
## 오류: 계정이 동시에 사용할 수 있는 최대 vCPU의 서비스 제한에 도달하여 작업이 실패했습니다.
이 오류는 계정이 최대 용량을 초과했기 때문에 EMR Serverless에서 작업을 제출할 수 없음을 나타냅니다. 계정의 최대 용량을 늘립니다. [EMR Serverless Service Quotas](https://console.aws.amazon.com/servicequotas/home/services/emr-serverless/quotas)에서 서비스 한도를 확인합니다.
## 오류: 애플리케이션이 maximumCapacity 설정을 초과하여 작업이 실패했습니다.
이 오류는 애플리케이션이 구성된 최대 용량을 초과했기 때문에 EMR Serverless에서 작업을 제출할 수 없음을 나타냅니다. 애플리케이션의 최대 용량을 늘립니다.
## 오류: 애플리케이션이 maximumCapacity를 초과하여 워커를 할당할 수 없어 작업이 실패했습니다.
이 오류는 작업을 완료할 수 없음을 나타냅니다. 애플리케이션이 maximumCapacity 설정을 초과했기 때문에 워커를 할당할 수 없습니다.
## 오류: S3 액세스가 거부되었습니다. 필요한 S3 리소스에서 작업 런타임 역할의 S3 액세스 권한을 확인하세요.
이 오류는 S3 리소스에 대한 액세스 권한이 작업에 없음을 나타냅니다. 작업에서 사용해야 하는 S3 리소스에 액세스할 수 있는 권한이 작업 런타임 역할에 있는지 확인합니다. 런타임 역할에 대한 자세한 내용은 [Amazon EMR Serverless에 대한 작업 런타임 역할](security-iam-runtime-role.md) 섹션을 참조하세요.
## 오류: ModuleNotFoundError: 모듈이 없습니다. EMR Serverless에서 Python 라이브러리를 사용하는 방법은 사용 설명서를 참조하세요.
이 오류는 Spark 작업에 대해 Python 모듈을 사용할 수 없음을 나타냅니다. 종속 Python 라이브러리를 작업에 사용할 수 있는지 확인합니다. Python 라이브러리를 패키징하는 방법에 대한 자세한 내용은 [EMR Serverless에서 Python 라이브러리 사용](using-python-libraries.md) 섹션을 참조하세요.
## 오류: 역할을 수임할 수 없습니다. 해당 역할이 없거나 필요한 신뢰 관계로 설정되지 않았기 때문입니다.
이 오류는 작업에 대해 지정한 작업 런타임 역할이 존재하지 않거나 EMR Serverless 권한에 대한 신뢰 관계가 역할에 없음을 나타냅니다. IAM 역할이 있는지 확인하고 역할의 신뢰 정책을 올바르게 설정했는지 확인하려면 [Amazon EMR Serverless에 대한 작업 런타임 역할](security-iam-runtime-role.md)의 지침을 참조하세요.
# 작업 수준 비용 할당 활성화
작업 수준 비용 할당을 사용하면 애플리케이션 수준에서 모든 비용을 집계하는 대신 개별 작업 실행 수준에서 EMR Serverless에 대한 세분화된 결제 속성을 사용할 수 있습니다. 활성화하면 AWS Cost Explorer기 및 비용 및 사용 보고서에서 작업 실행과 연결된 특정 작업 실행 IDs 및 태그를 기준으로 비용을 필터링하고 추적하여 제출된 작업 실행 요금을 더 잘 파악할 수 있습니다.
## 기본 동작
작업 수준 비용 할당은 기본적으로 활성화되어 있지 않습니다.
## 기능을 활성화 또는 비활성화하는 방법
애플리케이션 생성 중에 작업 수준 비용 할당을 구성하거나 기존 애플리케이션에 맞게 업데이트할 수 있습니다.
새 애플리케이션을 생성할 때 `jobLevelCostAllocation` 파라미터를 지정합니다.
```
# Enable job-level cost allocation:
aws emr-serverless create-application \
--name "my-application" \
--release-label "emr-7.12.0" \
--type "SPARK" \
--job-level-cost-allocation-configuration '{
"enabled": true
}'
# Disable job-level cost allocation:
aws emr-serverless create-application \
--name "my-application" \
--release-label "emr-7.12.0" \
--type "SPARK" \
--job-level-cost-allocation-configuration '{
"enabled": false
}'
```
기존 애플리케이션의 `jobLevelCostAllocationConfiguration` 파라미터를 업데이트합니다.
```
# Enable job-level cost allocation:
aws emr-serverless update-application \
--application-id \
--job-level-cost-allocation-configuration '{
"enabled": true
}'
# Disable job-level cost allocation:
aws emr-serverless update-application \
--application-id \
--job-level-cost-allocation-configuration '{
"enabled": false
}'
```
## 고려 사항 및 제한
+ 작업 수준 비용 할당을 활성화해도 기능이 활성화되기 전에 완료된 작업 실행에 대한 비용이 소급 적용되지 않습니다. 기능을 활성화한 후 시작된 작업 실행은 세분화된 비용 속성을 갖습니다.
+ 작업 수준 비용 할당 파라미터는 애플리케이션이 CREATED 또는 STOPPED 상태일 때만 업데이트할 수 있습니다.
+ 작업 수준 비용 할당이 활성화되면 비용은 애플리케이션이 아닌 개별 작업 실행에 기인합니다. 애플리케이션 수준에서 집계된 비용을 보려면 해당 애플리케이션 내의 모든 작업 실행에 일관된 태그(예: application-name 또는 application-id)를 적용하고 Cost Explorer 또는 Cost and Usage Reports에서 해당 태그를 기준으로 필터링해야 합니다.