YARN에서 Spark 실행하기
YARN에서 Spark 실행하기 (Running Spark on YARN)
Spark를 YARN (Hadoop NextGen) 클러스터 위에서 실행하는 방법을 안내하는 가이드예요. 배포 모드(cluster mode / client mode) 선택부터 준비 사항, YARN 전용 설정, 디버깅, Kerberos 인증, 셔플 서비스 구성, Oozie 연동까지 폭넓게 다룹니다.
출처: 문서
본문
목차 (Table of Contents)
- 보안 (Security)
- YARN에서 Spark 실행하기
- 준비 사항 (Preparations)
- 설정 (Configuration)
- 애플리케이션 디버깅 (Debugging your Application)
- 리소스 할당 및 설정 개요 (Resource Allocation and Configuration Overview)
- 스테이지 수준 스케줄링 개요 (Stage Level Scheduling Overview)
- 중요 참고 사항 (Important notes)
- Kerberos
- 외부 셔플 서비스 구성하기
- Apache Oozie로 애플리케이션 실행하기
- Spark History Server로 Spark Web UI 대체하기
- 여러 버전의 Spark Shuffle Service 실행하기
- Spark 애플리케이션의 다른 JDK 구성하기
YARN (Hadoop NextGen)에서 실행하는 지원이 Spark 0.6.0 버전에 추가되었고, 이후 릴리스에서 계속 개선되었어요.
보안 (Security)
인증 같은 보안 기능은 기본적으로 활성화되어 있지 않아요. 인터넷이나 신뢰할 수 없는 네트워크에 열려 있는 클러스터를 배포할 때는, 승인되지 않은 애플리케이션이 클러스터에서 실행되는 것을 막기 위해 클러스터에 대한 접근을 보호하는 것이 중요합니다. Spark를 실행하기 전에 Spark Security와 이 문서의 특정 보안 섹션을 확인하세요.
YARN에서 Spark 실행하기
Apache Hadoop은 3.5.0부터 Java 17을 지원하며, Apache Spark는 4.0.0부터 최소 Java 17을 요구해요. Hadoop 버전이 3.5.0보다 오래된 YARN 클러스터에서 실행할 때는 Spark 애플리케이션에 다른 JDK를 구성해야 합니다. 자세한 내용은 Spark 애플리케이션의 다른 JDK 구성하기를 참고하세요.
HADOOP_CONF_DIR 또는 YARN_CONF_DIR이 Hadoop 클러스터의 (클라이언트 측) 설정 파일이 들어 있는 디렉터리를 가리키는지 확인하세요. 이러한 설정은 HDFS에 쓰고 YARN ResourceManager에 연결하는 데 사용됩니다. 이 디렉터리에 포함된 설정은 YARN 클러스터에 배포되어 애플리케이션이 사용하는 모든 컨테이너가 동일한 설정을 사용하게 됩니다. 설정이 YARN이 관리하지 않는 Java 시스템 속성이나 환경 변수를 참조한다면, 그것들도 Spark 애플리케이션의 설정(driver, executor, client 모드에서는 AM)에 설정해야 해요.
YARN에서 Spark 애플리케이션을 실행하는 데 사용할 수 있는 배포 모드가 두 가지 있어요. cluster 모드에서는 Spark driver가 YARN이 클러스터에서 관리하는 애플리케이션 마스터 프로세스 안에서 실행되고, 클라이언트는 애플리케이션을 시작한 후 떠날 수 있어요. client 모드에서는 driver가 클라이언트 프로세스에서 실행되고, 애플리케이션 마스터는 YARN에서 리소스를 요청하는 데만 사용됩니다.
Spark가 지원하는 다른 클러스터 관리자에서는 마스터 주소를 --master 파라미터에 지정하지만, YARN 모드에서는 ResourceManager의 주소를 Hadoop 설정에서 가져와요. 따라서 --master 파라미터는 yarn이 됩니다.
cluster 모드에서 Spark 애플리케이션을 실행하려면:
$ ./bin/spark-submit --class path.to.your.Class --master yarn --deploy-mode cluster [options] <app jar> [app options]
예를 들어:
$ ./bin/spark-submit --class org.apache.spark.examples.SparkPi \
--master yarn \
--deploy-mode cluster \
--driver-memory 4g \
--executor-memory 2g \
--executor-cores 1 \
--queue thequeue \
examples/jars/spark-examples*.jar \
10
위 명령은 기본 Application Master를 시작하는 YARN 클라이언트 프로그램을 시작해요. 그런 다음 SparkPi는 Application Master의 하위 스레드로 실행됩니다. 클라이언트는 주기적으로 Application Master를 폴링해 상태 업데이트를 받아 콘솔에 표시합니다. 애플리케이션이 끝나면 클라이언트는 종료되어요. driver와 executor 로그를 보는 방법은 아래 애플리케이션 디버깅 섹션을 참고하세요.
client 모드에서 Spark 애플리케이션을 실행하려면 cluster를 client로 바꾸면 됩니다. 아래는 client 모드로 spark-shell을 실행하는 방법이에요:
$ ./bin/spark-shell --master yarn --deploy-mode client
다른 JAR 추가하기 (Adding Other JARs)
cluster 모드에서는 driver가 클라이언트와 다른 머신에서 실행되므로, SparkContext.addJar는 클라이언트에 로컬인 파일에 대해서는 바로 동작하지 않아요. 클라이언트의 파일을 SparkContext.addJar에 사용할 수 있게 하려면, 실행 명령에 --jars 옵션으로 포함시키세요.
$ ./bin/spark-submit --class my.main.Class \
--master yarn \
--deploy-mode cluster \
--jars my-other-jar.jar,my-other-other-jar.jar \
my-main-jar.jar \
app_arg1 app_arg2
준비 사항 (Preparations)
YARN에서 Spark를 실행하려면 YARN 지원으로 빌드된 Spark의 바이너리 배포판이 필요해요. 바이너리 배포판은 프로젝트 웹사이트의 다운로드 페이지에서 받을 수 있습니다. 다운로드할 수 있는 Spark 바이너리 배포판에는 두 가지 변형이 있어요. 하나는 특정 버전의 Apache Hadoop으로 미리 빌드된 것으로, 이 Spark 배포판은 내장 Hadoop 런타임을 포함하므로 with-hadoop Spark 배포판이라고 부릅니다. 다른 하나는 사용자가 제공한 Hadoop으로 미리 빌드된 것으로, 이 Spark 배포판은 내장 Hadoop 런타임을 포함하지 않으므로 더 작지만 사용자가 Hadoop 설치를 별도로 제공해야 합니다. 이 변형을 no-hadoop Spark 배포판이라고 부릅니다. with-hadoop Spark 배포판은 이미 내장 Hadoop 런타임을 포함하므로 기본적으로, 작업이 Hadoop Yarn 클러스터에 제출될 때 jar 충돌을 막기 위해 Yarn의 classpath를 Spark에 채우지 않습니다. 이 동작을 덮어쓰려면 spark.yarn.populateHadoopClasspath=true를 설정할 수 있어요. no-hadoop Spark 배포판은 Hadoop 런타임을 얻기 위해 기본적으로 Yarn의 classpath를 채워요. with-hadoop Spark 배포판에서 애플리케이션이 클러스터에만 있는 특정 라이브러리에 의존한다면, 위에서 언급한 속성을 설정해 Yarn classpath를 채우도록 시도할 수 있습니다. 그렇게 해서 jar 충돌 문제가 발생하면 꺼버리고 애플리케이션 jar에 해당 라이브러리를 포함해야 해요.
Spark를 직접 빌드하려면 Building Spark를 참고하세요.
Spark 런타임 jar를 YARN 쪽에서 접근 가능하게 하려면 spark.yarn.archive 또는 spark.yarn.jars를 지정할 수 있어요. 자세한 내용은 Spark 속성을 참고하세요. spark.yarn.archive도 spark.yarn.jars도 지정하지 않으면, Spark는 $SPARK_HOME/jars 아래의 모든 jar로 zip 파일을 만들어 분산 캐시에 업로드합니다.
설정 (Configuration)
Spark on YARN의 대부분의 설정은 다른 배포 모드와 동일해요. 이에 대한 자세한 내용은 설정 페이지를 참고하세요. 아래는 Spark on YARN에 특화된 설정들입니다.
애플리케이션 디버깅 (Debugging your Application)
YARN 용어에서 executor와 application master는 "컨테이너(containers)" 안에서 실행돼요. YARN에는 애플리케이션 완료 후 컨테이너 로그를 처리하는 두 가지 모드가 있습니다. 로그 집계(log aggregation)가 켜져 있으면(yarn.log-aggregation-enable 설정), 컨테이너 로그는 HDFS에 복사되고 로컬 머신에서는 삭제됩니다. 이러한 로그는 yarn logs 명령으로 클러스터 어디에서든 볼 수 있어요.
yarn logs -applicationId <app ID>
이 명령은 주어진 애플리케이션의 모든 컨테이너에서 나온 모든 로그 파일 내용을 출력합니다. HDFS 셸이나 API로 HDFS에서 컨테이너 로그 파일을 직접 볼 수도 있어요. 그 위치는 YARN 설정(yarn.nodemanager.remote-app-log-dir와 yarn.nodemanager.remote-app-log-dir-suffix)을 보면 찾을 수 있습니다. 로그는 Spark Web UI의 Executors 탭에서도 볼 수 있어요. Spark history server와 MapReduce history server 둘 다 실행하고 yarn-site.xml에 yarn.log.server.url을 제대로 구성해야 합니다. Spark history server UI의 로그 URL은 MapReduce history server로 리다이렉트되어 집계된 로그를 보여줍니다.
로그 집계가 켜져 있지 않으면, 로그는 각 머신의 YARN_APP_LOGS_DIR 아래에 로컬로 보관됩니다. 이 경로는 Hadoop 버전과 설치에 따라 보통 /tmp/logs 또는 $HADOOP_HOME/logs/userlogs로 구성돼요. 컨테이너의 로그를 보려면 그 컨테이너가 있는 호스트에 가서 이 디렉터리를 봐야 합니다. 하위 디렉터리는 애플리케이션 ID와 컨테이너 ID별로 로그 파일을 정리합니다. 로그는 Spark Web UI의 Executors 탭에서도 볼 수 있고, MapReduce history server를 실행할 필요는 없어요.
컨테이너별 실행 환경을 검토하려면 yarn.nodemanager.delete.debug-delay-sec를 큰 값(예: 36000)으로 늘린 다음, 컨테이너가 실행된 노드에서 yarn.nodemanager.local-dirs를 통해 애플리케이션 캐시에 접근하세요. 이 디렉터리에는 각 컨테이너 실행에 사용된 실행 스크립트, JAR, 모든 환경 변수가 들어 있어요. 이 과정은 특히 classpath 문제를 디버깅하는 데 유용합니다. (참고로 이 기능을 활성화하려면 클러스터 설정에 대한 관리자 권한과 모든 node manager의 재시작이 필요합니다. 따라서 호스팅 클러스터에는 적용되지 않아요.)
application master 또는 executor에 사용자 정의 log4j2 설정을 사용하려면 다음 옵션이 있어요:
spark-submit으로 애플리케이션과 함께 업로드할--files목록에 추가해 사용자 정의log4j2.properties를 업로드합니다.spark.driver.extraJavaOptions(driver용) 또는spark.executor.extraJavaOptions(executor용)에-Dlog4j.configurationFile=<설정 파일 위치>를 추가합니다. 파일을 사용하는 경우file:프로토콜을 명시적으로 제공하고, 파일이 모든 노드에 로컬로 존재해야 합니다.$SPARK_CONF_DIR/log4j2.properties파일을 갱신하면 다른 설정과 함께 자동으로 업로드됩니다. 여러 옵션이 지정되면 다른 두 옵션이 이 옵션보다 우선순위가 높다는 점을 참고하세요.
첫 옵션의 경우, executor와 application master가 동일한 log4j 설정을 공유하므로 같은 노드에서 실행될 때 문제(예: 같은 로그 파일에 쓰기 시도)가 발생할 수 있다는 점을 참고하세요.
YARN이 로그를 제대로 표시하고 집계할 수 있도록 로그 파일을 넣을 적절한 위치의 참조가 필요하다면 log4j2.properties에서 spark.yarn.app.container.log.dir을 사용하세요. 예를 들어 appender.file_appender.fileName=${sys:spark.yarn.app.container.log.dir}/spark.log처럼요. 스트리밍 애플리케이션의 경우 RollingFileAppender를 구성하고 파일 위치를 YARN의 로그 디렉터리로 설정하면 큰 로그 파일로 인한 디스크 오버플로를 피할 수 있고, YARN의 로그 유틸리티로 로그에 접근할 수 있어요.
application master와 executor에 사용자 정의 metrics.properties를 사용하려면 $SPARK_CONF_DIR/metrics.properties 파일을 갱신하세요. 다른 설정과 함께 자동으로 업로드되므로 --files로 직접 지정할 필요는 없습니다.
Spark 속성 (Spark Properties)
| 속성 이름 | 기본값 | 의미 | 도입 버전 |
|---|---|---|---|
spark.yarn.am.memory |
512m |
client 모드에서 YARN Application Master에 사용할 메모리 양 (JVM 메모리 문자열 형식, 예: 512m, 2g). cluster 모드에서는 spark.driver.memory를 사용합니다. 소문자 접미사, 즉 kibi, mebi, gibi, tebi, pebibyte에 대해 각각 k, m, g, t, p를 사용하세요. |
1.3.0 |
spark.yarn.am.resource.{resource-type}.amount |
(none) |
client 모드에서 YARN Application Master에 사용할 리소스 양. cluster 모드에서는 spark.yarn.driver.resource.<resource-type>.amount를 사용합니다. 이 기능은 YARN 3.0+에서만 사용할 수 있어요. 참고: YARN Resource Model 문서. 예를 들어 YARN에서 GPU 리소스를 요청하려면 spark.yarn.am.resource.yarn.io/gpu.amount를 사용하세요. |
3.0.0 |
spark.yarn.applicationType |
SPARK |
더 구체적인 애플리케이션 유형을 정의합니다. 예: SPARK, SPARK-SQL, SPARK-STREAMING, SPARK-MLLIB, SPARK-GRAPH. 20자를 초과하지 않도록 주의하세요. |
3.1.0 |
spark.yarn.driver.resource.{resource-type}.amount |
(none) |
cluster 모드에서 YARN Application Master에 사용할 리소스 양. 이 기능은 YARN 3.0+에서만 사용할 수 있어요. 참고: YARN Resource Model 문서. 예: YARN에서 GPU 리소스를 요청하려면 spark.yarn.driver.resource.yarn.io/gpu.amount를 사용하세요. |
3.0.0 |
spark.yarn.executor.resource.{resource-type}.amount |
(none) |
executor 프로세스당 사용할 리소스 양. 이 기능은 YARN 3.0+에서만 사용할 수 있어요. 참고: YARN Resource Model 문서. 예: YARN에서 GPU 리소스를 요청하려면 spark.yarn.executor.resource.yarn.io/gpu.amount를 사용하세요. |
3.0.0 |
spark.yarn.resourceGpuDeviceName |
yarn.io/gpu |
Spark 리소스 유형 gpu를 GPU를 나타내는 YARN 리소스에 매핑합니다. 기본적으로 YARN은 yarn.io/gpu를 사용하지만, YARN이 사용자 정의 리소스 유형으로 구성된 경우 이를 재매핑할 수 있어요. spark.{driver/executor}.resource.gpu.* 설정을 사용할 때 적용됩니다. |
3.2.1 |
spark.yarn.resourceFpgaDeviceName |
yarn.io/fpga |
Spark 리소스 유형 fpga를 FPGA를 나타내는 YARN 리소스에 매핑합니다. 기본적으로 YARN은 yarn.io/fpga를 사용하지만, YARN이 사용자 정의 리소스 유형으로 구성된 경우 이를 재매핑할 수 있어요. spark.{driver/executor}.resource.fpga.* 설정을 사용할 때 적용됩니다. |
3.2.1 |
spark.yarn.am.cores |
1 |
client 모드에서 YARN Application Master에 사용할 코어 수. cluster 모드에서는 spark.driver.cores를 사용합니다. |
1.3.0 |
spark.yarn.am.waitTime |
100s |
cluster 모드에서만 사용됩니다. YARN Application Master가 SparkContext 초기화를 기다리는 시간. |
1.3.0 |
spark.yarn.submit.file.replication |
기본 HDFS 복제 수 (보통 3) |
애플리케이션용으로 HDFS에 업로드된 파일의 HDFS 복제 수준. Spark jar, app jar, 분산 캐시 파일/아카이브 등을 포함합니다. | 0.8.1 |
spark.yarn.stagingDir |
파일시스템의 현재 사용자 홈 디렉터리 | 애플리케이션 제출 중 사용되는 스테이징 디렉터리. | 2.0.0 |
spark.yarn.preserve.staging.files |
false |
작업이 끝날 때 스테이징된 파일(Spark jar, app jar, 분산 캐시 파일)을 삭제하지 않고 보존하려면 true로 설정합니다. |
1.1.0 |
spark.yarn.scheduler.heartbeat.interval-ms |
3000 |
Spark application master가 YARN ResourceManager에 하트비트하는 간격(ms). 값은 YARN 설정의 만료 간격, 즉 yarn.am.liveness-monitor.expiry-interval-ms의 절반으로 상한이 정해집니다. |
0.8.1 |
spark.yarn.scheduler.initial-allocation.interval |
200ms |
보류 중인 컨테이너 할당 요청이 있을 때 Spark application master가 YARN ResourceManager에 적극적으로 하트비트하는 초기 간격. spark.yarn.scheduler.heartbeat.interval-ms보다 크면 안 됩니다. 보류 중인 컨테이너가 계속 있으면 spark.yarn.scheduler.heartbeat.interval-ms에 도달할 때까지 연속된 적극적 하트비트에서 할당 간격이 두 배가 됩니다. |
1.4.0 |
spark.yarn.historyServer.address |
(none) | Spark history server의 주소, 예: host.com:18080. 주소에는 스킴(http://)이 없어야 합니다. history server는 선택 서비스이므로 기본적으로 설정되지 않아요. 이 주소는 Spark 애플리케이션이 끝날 때 YARN ResourceManager에 주어져, ResourceManager UI의 애플리케이션을 Spark history server UI에 연결합니다. 이 속성에는 YARN 속성을 변수로 사용할 수 있으며 Spark가 런타임에 치환해요. 예를 들어 Spark history server가 YARN ResourceManager와 같은 노드에서 실행되면 ${hadoopconf-yarn.resourcemanager.hostname}:18080으로 설정할 수 있습니다. |
1.0.0 |
spark.yarn.dist.archives |
(none) | 각 executor의 작업 디렉터리로 추출될 아카이브의 쉼표 구분 목록. | 1.0.0 |
spark.yarn.dist.files |
(none) | 각 executor의 작업 디렉터리에 놓일 파일의 쉼표 구분 목록. | 1.0.0 |
spark.yarn.dist.jars |
(none) | 각 executor의 작업 디렉터리에 놓일 jar의 쉼표 구분 목록. | 2.0.0 |
spark.yarn.dist.forceDownloadSchemes |
(none) |
YARN의 분산 캐시에 추가되기 전에 로컬 디스크로 다운로드될 리소스의 스킴 쉼표 구분 목록. YARN 서비스가 Spark가 지원하는 스킴(http, https, ftp)을 지원하지 않거나, 로컬 YARN 클라이언트의 classpath에 있어야 하는 jar에 사용됩니다. 와일드카드 *는 모든 스킴의 리소스를 다운로드하는 것을 나타냅니다. |
2.3.0 |
spark.executor.instances |
2 |
정적 할당용 executor 수. spark.dynamicAllocation.enabled가 있으면 초기 executor 집합은 적어도 이 크기만큼 커집니다. |
1.0.0 |
spark.yarn.am.memoryOverhead |
AM 메모리 * 0.10, 최소 384 | spark.driver.memoryOverhead와 같지만 client 모드의 YARN Application Master용입니다. |
1.3.0 |
spark.yarn.queue |
default |
애플리케이션이 제출되는 YARN 큐의 이름. | 1.0.0 |
spark.yarn.jars |
(none) | YARN 컨테이너에 배포할 Spark 코드를 포함하는 라이브러리 목록. 기본적으로 Spark on YARN은 로컬에 설치된 Spark jar를 사용하지만, Spark jar는 HDFS의 세계 읽기 가능 위치에 둘 수도 있어요. 그러면 YARN이 노드에 캐시해서 애플리케이션 실행 때마다 배포할 필요가 없습니다. 예를 들어 HDFS의 jar를 가리키려면 이 설정을 hdfs:///some/path로 설정하세요. 글롭(glob)이 허용됩니다. |
2.0.0 |
spark.yarn.archive |
(none) | YARN 캐시에 배포할 필요한 Spark jar를 포함하는 아카이브. 설정하면 이 설정이 spark.yarn.jars를 대체하고 아카이브가 모든 애플리케이션 컨테이너에서 사용됩니다. 아카이브는 루트 디렉터리에 jar 파일을 포함해야 해요. 이전 옵션과 마찬가지로 아카이브도 HDFS에 호스팅해 파일 배포를 빠르게 할 수 있습니다. |
2.0.0 |
spark.yarn.appMasterEnv.[EnvironmentVariableName] |
(none) | YARN에서 실행되는 Application Master 프로세스에 EnvironmentVariableName이 지정한 환경 변수를 추가합니다. 여러 개를 지정해 여러 환경 변수를 설정할 수 있어요. cluster 모드에서는 Spark driver의 환경을 제어하고, client 모드에서는 executor 런처의 환경만 제어합니다. |
1.1.0 |
spark.yarn.containerLauncherMaxThreads |
25 |
executor 컨테이너 실행에 YARN Application Master에서 사용할 최대 스레드 수. | 1.2.0 |
spark.yarn.am.defaultJavaOptions |
(none) | client 모드에서 YARN Application Master를 위한 spark.yarn.am.extraJavaOptions 앞에 붙일 기본 JVM 옵션 문자열. 이 옵션으로 최대 힙 크기(-Xmx)를 설정하는 것은 불법입니다. 최대 힙 크기는 spark.yarn.am.memory로 설정할 수 있어요. 관리자가 설정하도록 의도된 옵션입니다. |
4.2.0 |
spark.yarn.am.extraJavaOptions |
(none) | client 모드에서 YARN Application Master에 전달할 추가 JVM 옵션 문자열. cluster 모드에서는 spark.driver.extraJavaOptions를 사용합니다. 이 옵션으로 최대 힙 크기(-Xmx)를 설정하는 것은 불법입니다. 최대 힙 크기는 spark.yarn.am.memory로 설정할 수 있어요. spark.yarn.am.defaultJavaOptions가 이 설정 앞에 붙습니다. |
1.3.0 |
spark.yarn.am.extraLibraryPath |
(none) | client 모드에서 YARN Application Master 실행 시 사용할 특별한 라이브러리 경로를 설정합니다. | 1.4.0 |
spark.yarn.populateHadoopClasspath |
with-hadoop 배포판에서는 false, no-hadoop 배포판에서는 true |
yarn.application.classpath와 mapreduce.application.classpath에서 Hadoop classpath를 채울지 여부. false로 설정하면 Hadoop 런타임을 번들하는 with-Hadoop Spark 배포판이 필요하거나 사용자가 Hadoop 설치를 별도로 제공해야 합니다. |
2.4.6 |
spark.yarn.maxAppAttempts |
YARN의 yarn.resourcemanager.am.max-attempts |
애플리케이션 제출에 시도할 최대 횟수. YARN 설정의 전역 최대 시도 수보다 크면 안 됩니다. | 1.3.0 |
spark.yarn.am.attemptFailuresValidityInterval |
(none) | AM 실패 추적의 유효 간격을 정의합니다. AM이 정의된 간격 이상 실행되었으면 AM 실패 횟수가 재설정됩니다. 설정하지 않으면 이 기능은 활성화되지 않아요. | 1.6.0 |
spark.yarn.am.clientModeTreatDisconnectAsFailed |
false | yarn-client의 깨끗하지 못한 연결 해제를 실패로 처리합니다. yarn-client 모드에서는 일반적으로 어떤 경우에는 애플리케이션이 사용자에 의해 의도적으로 종료되었는지 실제 오류인지 알 수 없기 때문에 애플리케이션이 항상 SUCCESS 최종 상태로 끝납니다. 이 설정은 Application Master가 driver에서 깨끗하지 못하게(즉 적절한 종료 핸드셰이크 없이) 연결 해제되면 애플리케이션이 FAILED 최종 상태로 종료되도록 동작을 바꿔, 호출자가 진짜 실패인지 판단할 수 있게 합니다. 이 설정이 있고 사용자가 클라이언트 애플리케이션을 부적절하게 종료하면 실제로는 실패가 아니어도 FAILED 상태가 표시될 수 있어요. | 3.3.0 |
spark.yarn.am.clientModeExitOnError |
false | yarn-client 모드에서 이 값이 true일 때, driver가 최종 상태가 KILLED 또는 FAILED인 애플리케이션 리포트를 받으면 해당 SparkContext를 중지하고 코드 1로 프로그램을 종료합니다. 이 값이 true이고 다른 애플리케이션에서 호출되면 부모 애플리케이션도 종료시킵니다. | 3.3.0 |
spark.yarn.am.tokenConfRegex |
(none) | 이 설정의 값은 작업의 설정 파일(예: hdfs-site.xml)에서 설정 항목 목록을 grep해 RM에 보내는 데 사용되는 정규식입니다. RM은 위임 토큰을 갱신할 때 이를 사용해요. 이 기능의 전형적인 사용 사례는 YARN 클러스터가 여러 다운스트림 HDFS 클러스터와 통신해야 하는 환경에서 위임 토큰을 지원하는 것입니다. 이때 YARN RM은 이러한 클러스터에 연결할 설정(예: dfs.nameservices, dfs.ha.namenodes., dfs.namenode.rpc-address.)을 갖지 않을 수 있어요. 이 시나리오에서 Spark 사용자는 설정 값을 `^dfs.nameservices$ | ^dfs.namenode.rpc-address.*$ |
spark.yarn.submit.waitAppCompletion |
true |
YARN cluster 모드에서 클라이언트가 애플리케이션 완료까지 기다렸다가 종료할지 제어합니다. true로 설정하면 클라이언트 프로세스가 살아 있어 애플리케이션 상태를 보고합니다. 그렇지 않으면 클라이언트 프로세스는 제출 후 종료됩니다. |
1.4.0 |
spark.yarn.am.nodeLabelExpression |
(none) | AM이 스케줄링될 노드 집합을 제한하는 YARN 노드 레이블 표현식. 노드 레이블 표현식을 지원하는 YARN 버전은 2.6 이상뿐이라 이전 버전에서 실행하면 이 속성은 무시됩니다. | 1.6.0 |
spark.yarn.executor.nodeLabelExpression |
(none) | executor가 스케줄링될 노드 집합을 제한하는 YARN 노드 레이블 표현식. 노드 레이블 표현식을 지원하는 YARN 버전은 2.6 이상뿐이라 이전 버전에서 실행하면 이 속성은 무시됩니다. | 1.4.0 |
spark.yarn.tags |
(none) | YARN ApplicationReports에 나타나는 YARN 애플리케이션 태그로 전달할 문자열 쉼표 구분 목록. YARN 앱을 쿼리할 때 필터링에 사용할 수 있어요. | 1.5.0 |
spark.yarn.priority |
(none) | YARN이 보류 중인 애플리케이션의 순서 정책을 정의하는 애플리케이션 우선순위. 정수 값이 높을수록 활성화될 기회가 좋습니다. 현재 YARN은 FIFO 순서 정책을 사용할 때만 애플리케이션 우선순위를 지원해요. | 3.0.0 |
spark.yarn.config.gatewayPath |
(none) | 게이트웨이 호스트(Spark 애플리케이션이 시작되는 호스트)에서 유효하지만 클러스터의 다른 노드에서 같은 리소스에 대한 경로와 다를 수 있는 경로. spark.yarn.config.replacementPath와 함께 이기종 설정을 가진 클러스터를 지원하는 데 사용되어, Spark가 원격 프로세스를 올바르게 실행할 수 있게 합니다. 교체 경로는 보통 YARN이 내보내는(따라서 Spark 컨테이너에 보이는) 일부 환경 변수를 참조합니다. 예를 들어 게이트웨이 노드에 Hadoop 라이브러리가 /disk1/hadoop에 설치되어 있고 Hadoop 설치 위치가 YARN에 의해 HADOOP_HOME 환경 변수로 내보내진다면, 이 값을 /disk1/hadoop으로, 교체 경로를 $HADOOP_HOME으로 설정하면 원격 프로세스 실행에 사용되는 경로가 로컬 YARN 설정을 제대로 참조하게 됩니다. |
1.5.0 |
spark.yarn.config.replacementPath |
(none) | spark.yarn.config.gatewayPath 참고. |
1.5.0 |
spark.yarn.rolledLog.includePattern |
(none) | 정의된 include 패턴과 일치하는 로그 파일을 필터링하는 Java Regex. 일치하는 로그 파일이 롤링 방식으로 집계됩니다. YARN의 롤링 로그 집계와 함께 사용되며, YARN 쪽에서 이 기능을 활성화하려면 yarn-site.xml에 yarn.nodemanager.log-aggregation.roll-monitoring-interval-seconds를 구성해야 합니다. Spark log4j appender는 실행 중 제거되는 파일을 처리할 수 있는 FileAppender나 다른 appender로 바꿔야 해요. log4j 설정에 구성된 파일 이름(예: spark.log)을 기반으로, 집계해야 할 모든 로그 파일을 포함하도록 정규식(spark*)을 설정해야 합니다. |
2.0.0 |
spark.yarn.rolledLog.excludePattern |
(none) | 정의된 exclude 패턴과 일치하는 로그 파일을 필터링하는 Java Regex. 일치하는 로그 파일은 롤링 방식으로 집계되지 않습니다. 로그 파일 이름이 include와 exclude 패턴 둘 다에 일치하면 결국 이 파일은 제외됩니다. | 2.0.0 |
spark.yarn.executor.launch.excludeOnFailure.enabled |
false | YARN 리소스 할당 문제가 있는 노드를 제외(exclude)하는 기능을 활성화하는 플래그. 제외 오류 한계는 spark.excludeOnFailure.application.maxFailedExecutorsPerNode로 구성할 수 있어요. |
2.4.0 |
spark.yarn.exclude.nodes |
(none) | 리소스 할당에서 제외되는 YARN 노드 이름의 쉼표 구분 목록. | 3.0.0 |
spark.yarn.metrics.namespace |
(none) | AM 메트릭 보고의 루트 네임스페이스. 설정하지 않으면 YARN 애플리케이션 ID가 사용됩니다. | 2.4.0 |
spark.yarn.report.interval |
1s |
cluster 모드에서 현재 Spark 작업 상태 보고 간격. | 0.9.0 |
spark.yarn.report.loggingFrequency |
30 |
다음 애플리케이션 상태가 기록될 때까지 처리되는 애플리케이션 리포트의 최대 수. 상태 변화가 있으면 처리된 리포트 수에 관계없이 애플리케이션 상태가 기록됩니다. | 3.5.0 |
spark.yarn.clientLaunchMonitorInterval |
1s |
앱 시작 시 client 모드 AM의 상태 요청 간격. | 2.3.0 |
spark.yarn.includeDriverLogsLink |
false |
cluster 모드에서 클라이언트 애플리케이션 리포트에 driver 컨테이너 로그에 대한 링크를 포함할지 여부. ResourceManager의 REST API 폴링이 필요하므로 RM에 약간의 추가 부하가 생깁니다. | 3.1.0 |
spark.yarn.unmanagedAM.enabled |
false |
client 모드에서 unmanaged am을 사용해 클라이언트의 일부로 Application Master 서비스를 실행할지 여부. | 3.0.0 |
spark.yarn.shuffle.server.recovery.disabled |
false | 보안 요구 사항이 더 높은 애플리케이션에 대해, 비밀번호가 db에 저장되지 않도록 하려면 true로 설정합니다. 이런 애플리케이션의 셔플 데이터는 External Shuffle Service가 재시작된 후 복구되지 않습니다. | 3.5.0 |
SHS 사용자 정의 executor 로그 URL에 사용 가능한 패턴
| 패턴 | 의미 |
|---|---|
{{HTTP_SCHEME}} |
YARN HTTP 정책에 따라 http:// 또는 https://. (yarn.http.policy로 구성) |
{{NM_HOST}} |
컨테이너가 실행된 노드의 "host". |
{{NM_PORT}} |
컨테이너가 실행된 node manager의 "port". |
{{NM_HTTP_PORT}} |
컨테이너가 실행된 node manager http 서버의 "port". |
{{NM_HTTP_ADDRESS}} |
컨테이너가 할당된 노드의 Http URI. |
{{CLUSTER_ID}} |
Resource Manager의 클러스터 ID. (yarn.resourcemanager.cluster-id로 구성) |
{{CONTAINER_ID}} |
컨테이너의 ID. |
{{USER}} |
시스템 환경의 SPARK_USER. |
{{FILE_NAME}} |
stdout, stderr. |
예를 들어, NodeManager http 서버가 리다이렉트하도록 두지 않고 로그 URL 링크를 Job History Server로 직접 가리키고 싶다면 spark.history.custom.executor.log.url을 아래처럼 구성할 수 있어요:
{{HTTP_SCHEME}}<JHS_HOST>:<JHS_PORT>/jobhistory/logs/{{NM_HOST}}:{{NM_PORT}}/{{CONTAINER_ID}}/{{CONTAINER_ID}}/{{USER}}/{{FILE_NAME}}?start=-4096
참고: <JHS_HOST>와 <JHS_PORT>를 실제 값으로 바꿔야 합니다.
리소스 할당 및 구성 개요 (Resource Allocation and Configuration Overview)
설정 페이지의 Custom Resource Scheduling and Configuration Overview 섹션을 꼭 읽어보세요. 이 섹션은 리소스 스케줄링의 YARN 특화 측면만 다룹니다.
YARN은 사용자가 Spark와 함께 사용하려는 모든 리소스를 지원하도록 구성되어야 해요. YARN의 리소스 스케줄링은 YARN 3.1.0에 추가되었습니다. 리소스 구성과 격리(isolation) 설정에 대한 자세한 내용은 YARN 문서를 참고하세요. 이상적으로는 리소스가 격리되어 executor가 할당된 리소스만 볼 수 있어야 해요. 격리를 활성화하지 않았다면, 리소스가 executor 간에 공유되지 않도록 보장하는 발견(discovery) 스크립트를 만드는 책임이 사용자에게 있습니다.
YARN은 사용자 정의 리소스 유형을 지원하지만 GPU(yarn.io/gpu)와 FPGA(yarn.io/fpga)에는 내장 유형이 있어요. 그 때문에 이 두 리소스 중 하나를 사용한다면, Spark가 Spark 리소스 요청을 YARN 리소스로 변환할 수 있고 spark.{driver/executor}.resource. 설정만 지정하면 됩니다. GPU나 FPGA에 사용자 정의 리소스 유형을 YARN과 함께 사용한다면 spark.yarn.resourceGpuDeviceName과 spark.yarn.resourceFpgaDeviceName으로 Spark 매핑을 바꿀 수 있어요. FPGA나 GPU 이외의 리소스를 사용한다면 YARN(spark.yarn.{driver/executor}.resource.)과 Spark(spark.{driver/executor}.resource.) 양쪽 설정을 모두 지정해야 합니다.
예를 들어 사용자가 각 executor에 GPU 2개를 요청하려고 한다면, spark.executor.resource.gpu.amount=2만 지정하면 Spark가 YARN에서 yarn.io/gpu 리소스 유형을 요청하는 것을 처리해요.
사용자가 정의한 YARN 리소스를 acceleratorX라고 부른다면, spark.yarn.executor.resource.acceleratorX.amount=2와 spark.executor.resource.acceleratorX.amount=2를 지정해야 합니다.
YARN은 각 컨테이너에 할당된 리소스의 주소를 Spark에 알려주지 않아요. 그 때문에 사용자는 executor가 시작 시 실행해 해당 executor에서 사용 가능한 리소스를 발견하는 발견 스크립트를 지정해야 합니다. 예제 스크립트는 examples/src/main/scripts/getGpusResources.sh에서 찾을 수 있어요. 스크립트는 실행 권한이 설정되어야 하고, 악의적인 사용자가 수정하지 못하도록 권한을 설정해야 해요. 스크립트는 ResourceInformation 클래스 형식의 JSON 문자열을 STDOUT으로 써야 합니다. 이 JSON에는 리소스 이름과 그 executor에서만 사용 가능한 리소스 주소 배열이 있습니다.
스테이지 수준 스케줄링 개요 (Stage Level Scheduling Overview)
스테이지 수준 스케줄링은 YARN에서 지원됩니다:
- 동적 할당(dynamic allocation)이 비활성화된 경우: 사용자가 스테이지 수준에서 서로 다른 태스크 리소스 요구 사항을 지정할 수 있고, 시작 시 요청된 동일한 executor를 사용합니다.
- 동적 할당이 활성화된 경우: 사용자가 스테이지 수준에서 태스크와 executor 리소스 요구 사항을 지정할 수 있고, 추가 executor를 요청합니다.
YARN 특화적으로 주의할 점은 각 ResourceProfile이 YARN에서 서로 다른 컨테이너 우선순위를 요구한다는 것입니다. 매핑은 단순히 ResourceProfile id가 우선순위가 되며, YARN에서는 숫자가 낮을수록 우선순위가 높아요. 즉 먼저 만들어진 프로필이 YARN에서 더 높은 우선순위를 가집니다. 보통은 Spark가 한 스테이지를 끝낸 후 다른 스테이지를 시작하므로 중요하지 않지만, 유일하게 영향을 받을 수 있는 경우는 job server 형태의 시나리오이므로 염두에 두세요. 기본 default 프로필과 사용자 정의 ResourceProfile 사이에 사용자 정의 리소스가 처리되는 방식의 차이가 있습니다. 사용자가 Spark가 스케줄링하지 않고도 추가 리소스를 가진 YARN 컨테이너를 요청할 수 있도록, spark.yarn.executor.resource. 설정으로 리소스를 지정할 수 있어요. 그 설정은 기본 default 프로필에서만 사용되고 다른 사용자 정의 ResourceProfile에는 전파되지 않습니다. 이는 스테이지에 그 리소스가 없기를 원할 때 제거할 방법이 없기 때문이에요. 그 결과 default 프로필은 spark.yarn.executor.resource.에 정의된 사용자 정의 리소스에 더해 Spark가 정의한 GPU나 FPGA 리소스를 얻게 됩니다. Spark는 GPU와 FPGA 리소스를 YARN 내장 유형 yarn.io/gpu와 yarn.io/fpga로 변환하지만 다른 리소스의 매핑은 알지 못합니다. 다른 Spark 사용자 정의 리소스는 default 프로필에 대해 YARN으로 전파되지 않아요. 따라서 Spark가 사용자 정의 리소스를 기준으로 스케줄링하면서 YARN에서도 요청하게 하려면 YARN(spark.yarn.{driver/executor}.resource.)과 Spark(spark.{driver/executor}.resource.) 설정 둘 다에 지정해야 합니다. 추가 리소스가 있는 YARN 컨테이너만 원하고 Spark가 그 리소스로 스케줄링하지 않게 하려면 Spark 설정은 빼세요. 이제 사용자 정의 ResourceProfile의 경우, 현재 Spark 스케줄링을 끄지 않고 YARN 리소스만 지정하는 방법이 없습니다. 즉 사용자 정의 ResourceProfile에 대해서는 ResourceProfile에 정의된 모든 리소스를 YARN에 전파합니다. GPU와 FPGA도 여전히 YARN 내장 유형으로 변환합니다. 이는 지정한 사용자 정의 리소스의 이름이 YARN에서 정의된 것과 일치해야 함을 요구합니다.
중요 참고 사항 (Important notes)
- 코어 요청이 스케줄링 결정에서 존중되는지는 어떤 스케줄러가 사용되는지와 어떻게 구성되는지에 달려 있어요.
cluster모드에서는 Spark executor와 Spark driver가 사용하는 로컬 디렉터리가 YARN용으로 구성된 로컬 디렉터리(Hadoop YARN 설정yarn.nodemanager.local-dirs)가 됩니다. 사용자가spark.local.dir을 지정하면 무시됩니다.client모드에서는 Spark executor가 YARN용으로 구성된 로컬 디렉터리를 사용하고, Spark driver는spark.local.dir에 정의된 것을 사용해요. 이는client모드에서 Spark executor만 YARN 클러스터에서 실행되고 Spark driver는 실행되지 않기 때문입니다.--files와--archives옵션은 Hadoop과 유사하게 #으로 파일 이름을 지정하는 것을 지원해요. 예를 들어--files localtest.txt#appSees.txt를 지정하면, 로컬에localtest.txt라는 이름의 파일을 HDFS에 업로드하지만appSees.txt라는 이름으로 링크됩니다. 애플리케이션은 YARN에서 실행할 때 이를appSees.txt라는 이름으로 참조해야 해요.--jars옵션은cluster모드에서 로컬 파일과 함께 사용할 때SparkContext.addJar함수가 동작하게 해줍니다. HDFS, HTTP, HTTPS, FTP 파일과 함께 사용할 때는 필요하지 않아요.
Kerberos
Spark의 표준 Kerberos 지원은 Security 페이지에 다뤄져 있어요.
YARN 모드에서 Hadoop 파일시스템에 접근할 때, Spark는 hadoop 설정의 기본 파일시스템 외에도 Spark 애플리케이션의 스테이징 디렉터리를 호스팅하는 서비스에 대한 위임 토큰(delegation token)을 자동으로 획득합니다.
YARN 특화 Kerberos 설정
| 속성 이름 | 기본값 | 의미 | 도입 버전 |
|---|---|---|---|
spark.kerberos.keytab |
(none) | 위에서 지정한 principal의 keytab을 포함하는 파일의 전체 경로. 이 keytab은 YARN Distributed Cache를 통해 YARN Application Master가 실행되는 노드로 복사되고, 로그인 티켓과 위임 토큰을 주기적으로 갱신하는 데 사용됩니다. --keytab 명령줄 인자와 같아요. ("local" 마스터에서도 동작합니다.) |
3.0.0 |
spark.kerberos.principal |
(none) | 보안 클러스터에서 실행할 때 KDC에 로그인하는 데 사용되는 principal. --principal 명령줄 인자와 같아요. ("local" 마스터에서도 동작합니다.) |
3.0.0 |
spark.yarn.kerberos.relogin.period |
1m | kerberos TGT를 갱신해야 하는지 확인하는 주기. TGT 갱신 기간(또는 TGT 갱신이 활성화되지 않은 경우 TGT 수명)보다 짧은 값으로 설정해야 합니다. 대부분의 배포에서는 기본값이면 충분해요. | 2.3.0 |
spark.yarn.kerberos.renewal.excludeHadoopFileSystems |
(none) | 리소스 스케줄러의 위임 토큰 갱신에서 호스트가 제외될 Hadoop 파일시스템의 쉼표 구분 목록. 예: spark.yarn.kerberos.renewal.excludeHadoopFileSystems=hdfs://nn1.com:8032,hdfs://nn2.com:8032. 이것은 현재 YARN에서 동작하는 것으로 알려져 있어, YARN Resource Manager가 애플리케이션의 토큰을 갱신하지 않습니다. 리소스 스케줄러가 토큰을 갱신하지 않으므로, 원래 토큰 만료보다 오래 실행되는 애플리케이션이 그 토큰을 사용하려 하면 아마 실패할 것이라는 점을 참고하세요. |
3.2.0 |
Kerberos 문제 해결 (Troubleshooting Kerberos)
Hadoop/Kerberos 문제를 디버깅하는 것은 "어려울" 수 있어요. 유용한 기법 중 하나는 HADOOP_JAAS_DEBUG 환경 변수를 설정해 Hadoop에서 Kerberos 연산의 추가 로깅을 활성화하는 것입니다.
export HADOOP_JAAS_DEBUG=true
JDK 클래스는 시스템 속성 sun.security.krb5.debug와 sun.security.spnego.debug=true를 통해 Kerberos와 SPNEGO/REST 인증의 추가 로깅을 활성화하도록 구성할 수 있어요.
-Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true
이 모든 옵션은 Application Master에서 활성화할 수 있어요:
spark.yarn.appMasterEnv.HADOOP_JAAS_DEBUG true
spark.yarn.am.extraJavaOptions -Dsun.security.krb5.debug=true -Dsun.security.spnego.debug=true
마지막으로 org.apache.spark.deploy.yarn.Client의 로그 수준을 DEBUG로 설정하면, 로그에 획득한 모든 토큰의 목록과 만료 상세 정보가 포함됩니다.
외부 셔플 서비스 구성하기 (Configuring the External Shuffle Service)
YARN 클러스터의 각 NodeManager에서 Spark Shuffle Service를 시작하려면 다음 지침을 따르세요:
- Spark를 YARN 프로필로 빌드합니다. 사전 패키징된 배포판을 사용한다면 이 단계는 건너뛰어도 됩니다.
spark-<version>-yarn-shuffle.jar을 찾습니다. Spark를 직접 빌드한다면$SPARK_HOME/common/network-yarn/target/scala-<version>아래에, 배포판을 사용한다면yarn아래에 있어야 해요.- 이 jar를 클러스터의 모든
NodeManager의 classpath에 추가합니다. - 각 노드의
yarn-site.xml에서yarn.nodemanager.aux-services에spark_shuffle을 추가하고,yarn.nodemanager.aux-services.spark_shuffle.class를org.apache.spark.network.yarn.YarnShuffleService로 설정합니다. - 셔플 중 가비지 컬렉션 문제를 피하기 위해
etc/hadoop/yarn-env.sh에서YARN_HEAPSIZE(기본 1000)를 설정해NodeManager's힙 크기를 늘립니다. - 클러스터의 모든
NodeManager를 재시작합니다.
YARN에서 shuffle service가 실행될 때 사용할 수 있는 추가 설정 옵션은 다음과 같아요:
| 속성 이름 | 기본값 | 의미 | 도입 버전 |
|---|---|---|---|
spark.yarn.shuffle.stopOnFailure |
false |
Spark Shuffle Service 초기화에 실패가 있을 때 NodeManager를 중지할지 여부. Spark Shuffle Service가 실행되지 않는 NodeManager에서 실행되는 컨테이너로 인한 애플리케이션 실패를 방지합니다. | 2.1.0 |
spark.yarn.shuffle.service.metrics.namespace |
sparkShuffleService |
shuffle service 메트릭을 NodeManager의 Hadoop metrics2 시스템에 내보낼 때 사용할 네임스페이스. | 3.2.0 |
spark.yarn.shuffle.service.logs.namespace |
(not set) |
YARN shuffle service의 로그를 내보낼 때 로거 이름을 만들 때 클래스 이름에 추가될 네임스페이스. 예: org.apache.spark.network.yarn.YarnShuffleService.logsNamespaceValue. 일부 로깅 프레임워크는 로거 이름이 클래스 이름처럼 보이길 기대하므로, 유효한 Java 패키지나 클래스 이름이 되고 공백을 포함하지 않는 값을 제공하는 것이 일반적으로 권장됩니다. |
3.3.0 |
spark.shuffle.service.db.backend |
ROCKSDB | YARN에서 work-preserving restart가 활성화될 때, shuffle service 상태 저장소에서 사용되는 디스크 기반 저장소를 지정합니다. 기본값 ROCKSDB로 ROCKSDB와 LEVELDB(deprecated)를 지원해요. RocksDB/LevelDB의 원래 데이터 저장소는 이제 자동으로 다른 종류의 저장소로 변환되지 않습니다. 원래 데이터 저장소는 유지되고, 저장소 유형 전환 시 새 유형 데이터 저장소가 생성됩니다. |
3.4.0 |
위 지침은 기본 shuffle service 이름인 spark_shuffle이 사용되었다고 가정합니다. 여기서 어떤 이름이든 사용할 수 있지만, YARN NodeManager 설정에서 사용된 값은 Spark 애플리케이션의 spark.shuffle.service.name 값과 일치해야 해요.
shuffle service는 기본적으로 NodeManager가 사용하는 Hadoop Configuration(예: yarn-site.xml)에서 모든 설정을 가져옵니다. 그러나 spark-shuffle-site.xml이라는 파일을 사용해 shuffle service를 독립적으로 구성할 수도 있는데, 이 파일은 shuffle service의 classpath에(기본적으로 NodeManager의 classpath와 공유됨) 놓아야 해요. shuffle service는 이를 표준 Hadoop Configuration 리소스로 취급해 NodeManager의 설정 위에 오버레이합니다.
Apache Oozie로 애플리케이션 실행하기
Apache Oozie는 워크플로의 일부로 Spark 애플리케이션을 실행할 수 있어요. 보안 클러스터에서는 실행된 애플리케이션이 클러스터 서비스에 접근하려면 관련 토큰이 필요합니다. Spark가 keytab으로 실행되면 이 작업은 자동이에요. 그러나 Spark를 keytab 없이 실행하려면 보안 설정의 책임을 Oozie에 넘겨야 합니다.
보안 클러스터용 Oozie 구성과 작업 자격 증명 획득에 대한 자세한 내용은 Oozie 웹사이트의 특정 릴리스 문서 "Authentication" 섹션에서 찾을 수 있어요.
Spark 애플리케이션의 경우, Oozie 워크플로는 애플리케이션이 필요로 하는 모든 토큰을 Oozie가 요청하도록 설정되어야 합니다. 여기에는 다음이 포함됩니다:
- YARN resource manager.
- 로컬 Hadoop 파일시스템.
- I/O의 소스나 목적지로 사용되는 모든 원격 Hadoop 파일시스템.
- Hive —사용 시.
- HBase —사용 시.
- 애플리케이션이 상호작용하는 경우 YARN timeline server.
Spark가 Hive, HBase, 원격 HDFS 토큰을 획득하려 시도하다(그리고 실패하다)가 않도록, Spark 설정에서는 해당 서비스의 토큰 수집을 비활성화해야 합니다.
Spark 설정에는 다음 줄이 포함되어야 해요:
spark.security.credentials.hive.enabled false
spark.security.credentials.hbase.enabled false
설정 옵션 spark.kerberos.access.hadoopFileSystems는 설정하지 않아야 합니다.
Spark History Server로 Spark Web UI 대체하기
애플리케이션 UI가 비활성화된 상태에서 실행 중인 애플리케이션의 추적 URL로 Spark History Server 애플리케이션 페이지를 사용할 수 있어요. 이는 보안 클러스터에서 바람직할 수 있고, Spark driver의 메모리 사용량을 줄이는 데도 도움이 됩니다. Spark History Server를 통한 추적을 설정하려면 다음을 하세요:
- 애플리케이션 쪽에서 Spark 설정에
spark.yarn.historyServer.allowTracking=true를 설정합니다. 이렇게 하면 애플리케이션의 UI가 비활성화된 경우 Spark가 history server의 URL을 추적 URL로 사용하도록 지시합니다. - Spark History Server에서
spark.ui.filters설정의 필터 목록에org.apache.spark.deploy.yarn.YarnProxyRedirectFilter를 추가합니다.
history server 정보가 애플리케이션 상태와 최신이 아닐 수 있다는 점을 인지하세요.
여러 버전의 Spark Shuffle Service 실행하기
이 섹션은 YARN 버전 >= 2.9.0에서 실행할 때만 적용됩니다.
어떤 경우에는 서로 다른 버전의 Spark를 사용하는 Spark Shuffle Service 인스턴스를 여러 개 실행하는 것이 바람직할 수 있어요. 주어진 버전의 shuffle service가 항상 다른 버전의 Spark와 호환되는 것은 아니므로, 예를 들어 여러 Spark 버전을 실행하는 애플리케이션의 혼합 워크로드가 있는 YARN 클러스터를 실행할 때 유용합니다. YARN 2.9.0 이후 버전은 격리된 클래스로더 안에서 shuffle service를 실행하는 기능을 지원하므로(YARN-4577 참고), 여러 Spark 버전이 단일 NodeManager 안에서 공존할 수 있어요. yarn.nodemanager.aux-services.<service-name>.classpath와, YARN 2.10.2/3.1.1/3.2.0부터는 yarn.nodemanager.aux-services.<service-name>.remote-classpath 옵션을 구성할 수 있습니다. 참고로 YARN 3.3.0/3.3.1에는 yarn.nodemanager.aux-services.<service-name>.system-classes 설정이 필요한 문제가 있습니다. 자세한 내용은 YARN-11053을 참고하세요. 별도의 classpath를 설정하는 것 외에도, 두 버전이 서로 다른 포트에 알리도록 보장해야 합니다. 이는 위에서 설명한 spark-shuffle-site.xml 파일로 달성할 수 있어요. 예를 들어 다음과 같은 구성을 가질 수 있습니다:
yarn.nodemanager.aux-services = spark_shuffle_x,spark_shuffle_y
yarn.nodemanager.aux-services.spark_shuffle_x.classpath = /path/to/spark-x-path/fat.jar:/path/to/spark-x-config
yarn.nodemanager.aux-services.spark_shuffle_y.classpath = /path/to/spark-y-path/fat.jar:/path/to/spark-y-config
또는
yarn.nodemanager.aux-services = spark_shuffle_x,spark_shuffle_y
yarn.nodemanager.aux-services.spark_shuffle_x.classpath = /path/to/spark-x-path/*:/path/to/spark-x-config
yarn.nodemanager.aux-services.spark_shuffle_y.classpath = /path/to/spark-y-path/*:/path/to/spark-y-config
두 spark-*-config 디렉터리는 각각 spark-shuffle-site.xml라는 파일 하나를 포함합니다. 이들은 Hadoop Configuration 형식의 XML 파일로, 각각 포트 번호와 메트릭 이름 접두사를 조정하는 몇 가지 설정을 포함합니다:
<configuration>
<property>
<name>spark.shuffle.service.port</name>
<value>7001</value>
</property>
<property>
<name>spark.yarn.shuffle.service.metrics.namespace</name>
<value>sparkShuffleServiceX</value>
</property>
</configuration>
값은 두 서비스마다 서로 달라야 합니다.
그런 다음 Spark 애플리케이션 설정에서 하나는 다음과 같이 구성하고:
spark.shuffle.service.name = spark_shuffle_x
spark.shuffle.service.port = 7001
다른 하나는 다음과 같이 구성해야 해요:
spark.shuffle.service.name = spark_shuffle_y
spark.shuffle.service.port = <other value>
Spark 애플리케이션의 다른 JDK 구성하기
어떤 경우에는 YARN node manager와 다른 JDK를 사용해 Spark 애플리케이션을 실행하는 것이 바람직할 수 있어요. 이는 YARN 컨테이너와 spark-submit 프로세스에 JAVA_HOME 환경 변수를 설정해 달성할 수 있습니다.
참고로 Spark는 한 애플리케이션의 모든 JVM 프로세스가 같은 버전의 JDK를 사용한다고 가정합니다. 그렇지 않으면 JDK 직렬화 문제가 발생할 수 있어요.
모든 노드에 /opt/openjdk-17에 미리 설치된 JDK를 사용하도록 Spark 애플리케이션을 구성하려면:
$ export JAVA_HOME=/opt/openjdk-17
$ ./bin/spark-submit --class path.to.your.Class \
--master yarn \
--conf spark.yarn.appMasterEnv.JAVA_HOME=/opt/openjdk-17 \
--conf spark.executorEnv.JAVA_HOME=/opt/openjdk-17 \
<app jar> [app options]
선택적으로, YARN 클러스터 노드에 다른 JDK를 설치하는 것을 피하고 싶을 수 있습니다. 이런 경우 YARN의 Distributed Cache를 사용해 JDK를 배포하는 것도 가능해요. 예를 들어 Java 21로 Spark 애플리케이션을 실행하려면 JDK 21 tarball openjdk-21.tar.gz를 준비해 로컬 노드의 /opt에 압축을 풀고, Spark 애플리케이션을 제출합니다:
$ export JAVA_HOME=/opt/openjdk-21
$ ./bin/spark-submit --class path.to.your.Class \
--master yarn \
--archives path/to/openjdk-21.tar.gz \
--conf spark.yarn.appMasterEnv.JAVA_HOME=./openjdk-21.tar.gz/openjdk-21 \
--conf spark.executorEnv.JAVA_HOME=./openjdk-21.tar.gz/openjdk-21 \
<app jar> [app options]
더 알아보기 (Learn more)
- Spark 설정 가이드:
spark.yarn.*설정 항목들을 전체적으로 확인해요. - 클러스터 모드 개요 (Cluster Mode Overview): 드라이버, executor, 클러스터 관리자의 개념을 알아봐요.
- Spark Standalone: YARN 외의 다른 클러스터 관리자도 비교해 보세요.