Amazon EKS 환경에서 다양한 Spark 애플리케이션 제출 방법 비교하기

Amazon EKS 환경에서는 다양한 방법으로 Spark 애플리케이션을 제출할 수 있습니다. 현재 Amazon EKS 환경에서 지원하는 Spark 애플리케이션 제출 방법에는 spark-submit CLI를 활용하는 방법, Spark Operator를 활용하는 방법, AWS CLI 활용하는 방법, EMR Container Controller를 활용하는 방법, 총 4가지 방법이 존재합니다. 본 게시글에서는 Amazon EKS 환경에서 Spark 애플리케이션을 제출할 수 있는 4가지 방법에 대해서 소개하여, 고객분들이 적절한 방식으로 Spark 애플리케이션을 제출할 수 있도록 가이드를 제시합니다.

Spark on Kubernetes 아키텍처

[그림 1] Spark on Kubernetes 아키텍처

Amazon EKS 환경에서 다양한 방식의 Spark 애플리케이션 제출 방법을 이해하기 위해서는 Spark 애플리케이션을 쿠버네티스 클러스터에 처리하는 Spark on Kubernetes의 아키텍처를 이해하고 있어야 합니다. [그림 1]은 Spark on Kubernetes 아키텍처를 나타내고 있습니다.

Spark on Kubernetes에서 Spark의 핵심 구성요소인 Driver는 Driver Pod 안에서 동작하며, Driver 구동에 필요한 Driver 관련 설정 정보는 Driver Configs ConfigMap을 통해서 Driver에게 전달됩니다. 이와 유사하게 Task를 처리하는 Spark의 Executor들은 각각의 별도의 Executor Pod에서 동작하며, Executor가 필요한 설정들은 Executor Configs ConfigMap을 통해서 Executor에게 전달됩니다.

일반적으로 Spark 애플리케이션을 제출할 때 이용하는 Spark 공식 CLI인 spark-submit CLI는 Spark on Kubernetes에서도 동일한 방식으로 사용 가능합니다. 사용자는 spark-submit CLI를 통해서 Spark 애플리케이션의 정보, Spark 애플리케이션이 동작할 쿠버네티스 클러스터, Driver/Executor의 스펙을 명시하고 실행합니다. 이후에 spark-submit CLI는 설정된 정보를 바탕으로 쿠버네티스 클러스터에 접근하여 Driver 동작을 위한 Driver Configs ConfigMap 및 Driver Pod를 생성하며, 이후에 Driver는 다시 Executor Configs ConfigMap 및 Executor Pod들을 생성하여 Spark 애플리케이션을 수행합니다.

살펴본 Spark on Kubernetes 아키텍처는 업스트림 쿠버네티스 환경을 제공하는 Amazon EKS 클러스터에서도 크게 달라지지 않습니다. spark-submit CLI를 이용하는 경우에는 동일한 아키텍처를 가지며, Spark Operator, AWS CLI, EMR Container Controller를 이용하는 방식들도 내부적으로 모두 spark-submit CLI을 이용하는 방식이기 때문에 모두 유사한 아키텍처로 Spark 애플리케이션을 처리합니다. 각 제출 방식에 따라서 달라지는 부분은 spark-submit CLI를 실행하는 방식 및 spark-submit CLI에 설정되는 기본 설정들뿐입니다.

spark-submit CLI를 활용하여 Spark 애플리케이션 제출

[그림 2] spark-submit CLI를 활용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처

[그림 2]는 Amazon EKS 클러스터에서 spark-submit을 이용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처를 나타내고 있습니다. Spark 애플리케이션이 처리되는 부분은 [그림 1]의 Kubernetes on Spark 아키텍처와 동일합니다.

$ spark-submit \
  --master k8s://xxxx.xx.ap-northeast-2.eks.amazonaws.com \
  --deploy-mode cluster \
  --driver-cores 1 \
  --driver-memory 512m \
  --num-executors 1 \
  --executor-cores 1 \
  --executor-memory 512m \
  --conf spark.kubernetes.namespace=spark \
  --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
  --conf spark.kubernetes.container.image=public.ecr.aws/r1l5w1y9/spark-operator:3.2.1-hadoop-3.3.1-java-11-scala-2.12-python-3.8-latest \
  --conf spark.kubernetes.driver.secretKeyRef.AWS_ACCESS_KEY_ID=k8ssecretname:accesskeyname \
  --conf spark.kubernetes.driver.secretKeyRef.AWS_SECRET_ACCESS_KEY=k8ssecretname:secretaccesskeyname \
  local:///opt/spark/examples/src/main/python/pi.py

[Text 1] spark-submit CLI 사용 예제

[Text 1]은 spark-submit CLI를 이용하여 Spark 애플리케이션을 제출하는 예제입니다. spark-submit CLI는 “master” 설정에 “k8s”로 시작하는 URL을 통해서 쿠버네티스 클러스터에 Spark 애플리케이션이 제출된다는 사실을 파악합니다. 또한 spark-submit CLI는 “conf” 설정을 통해서 Driver/Executor Pod가 생성되는 쿠버네티스 Namespace 이름, Driver/Executor Pod가 이용하는 Container Image 이름과 같이 Spark on Kubernetes에 특화된 설정값을 얻습니다. 이러한 설정값들을 바탕으로 spark-submit CLI는 EKS Cluster API에 접근하여 Executor Pod를 생성합니다.

[그림 2]에서는 Spark 애플리케이션 처리 과정 이외에 Spark History 서버의 아키텍처도 나타내고 있습니다. 일반적으로 완료된 Spark 애플리케이션의 처리 내역을 확인하기 위해서 Spark History 서버를 이용합니다. Spark History 서버가 동작하기 위해서는 Driver가 남기는 Event Log에 접근이 필요합니다. 따라서 spark-submit CLI 실행 시 Event Log 활성화 및 Event Log의 경로를 설정해 주어야 합니다. 일반적으로 Amazon EKS 환경에서는 Event Log를 Amazon S3에 저장합니다.

$ spark-submit \
  --master k8s://xxxx.xx.ap-northeast-2.eks.amazonaws.com \
  --deploy-mode cluster \
  --driver-cores 1 \
  --driver-memory 512m \
  --num-executors 1 \
  --executor-cores 1 \
  --executor-memory 512m \
  --conf spark.kubernetes.namespace=spark \
  --conf spark.kubernetes.authenticate.driver.serviceAccountName=spark \
  --conf spark.kubernetes.container.image=public.ecr.aws/r1l5w1y9/spark-operator:3.2.1-hadoop-3.3.1-java-11-scala-2.12-python-3.8-latest \
  --conf spark.eventLog.enabled=true \
  --conf spark.eventLog.dir=s3a://xxx.s3bucketname \
  --conf spark.kubernetes.driver.secretKeyRef.AWS_ACCESS_KEY_ID=k8ssecretname:accesskeyname \
  --conf spark.kubernetes.driver.secretKeyRef.AWS_SECRET_ACCESS_KEY=k8ssecretname:secretaccesskeyname \
  local:///opt/spark/examples/src/main/python/pi.py

[Text 2] Event Log 설정이 적용된 spark-submit CLI 사용 예제

[Text 2]는 Event Log 관련 설정을 포함하여 spark-submit CLI를 이용하여 Spark 애플리케이션을 제출하는 예제입니다. “eventLog.enabled” 설정을 통해서 Event Log를 활성화하고, “eventLog.dir” 설정을 통해서 Event Log가 저장되는 S3 Bucket을 명시합니다.“kubernetes.driver.secretKeyRef” 설정을 통해서 S3 Bucket 접근을 위한 Access Key, Secret Access Key가 저장되어 있는 쿠버네티스 Secret을 명시합니다. Spark History 서버는 어디에든 설치해서 이용해도 관계 없습니다. 가장 손쉽게 설치해서 이용하는 방법은 Amazon EKS 클러스터에 Helm Chart를 통해서 설치 및 이용하는 방법입니다.

Spark Operator를 활용하여 Spark 애플리케이션 제출

[그림 3] Spark Operator를 활용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처

Spark Operator는 Spark 애플리케이션 제출을 쿠버네티스의 Object로 관리하게 도와주는 도구입니다. Spark Operator를 이용하는 경우 사용자는 spark-submit CLI를 직접 실행하는 형태가 아니라 Spark Operator가 제공하는 Spark Object인 SparkApplication 또는 ScheduledSparkApplication Object를 생성하여 Spark 애플리케이션을 제출합니다. [그림 3]은 Spark Operator를 활용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처입니다.

Spark Operator를 이용하기 위해서는 Spark Operator를 Helm Chart를 통해서 Amazon EKS Cluster에 설치해야 합니다. 설치 이후에 Amazon EKS Cluster에 SparkApplication, ScheduledSparkApplication Object가 생성되면 Spark Operator는 내부적으로 spark-submit CLI를 이용하여 Spark 애플리케이션을 Amazon EKS 클러스터에 제출합니다.

SparkApplication Object는 일회성으로 Spark 애플리케이션을 제출하는 경우에 이용하며, ScheduledSparkApplication Object는 주기적으로 Spark 애플리케이션을 제출하는 경우에 이용합니다.

apiVersion: "sparkoperator.k8s.io/v1beta2"
kind: SparkApplication
metadata:
  name: pi-logs
  namespace: spark
spec:
  type: Python
  mode: cluster
  image: "public.ecr.aws/r1l5w1y9/spark-operator:3.2.1-hadoop-3.3.1-java-11-scala-2.12-python-3.8-latest"
  mainApplicationFile: local:///opt/spark/examples/src/main/python/pi.py
  sparkVersion: "3.1.1"
  driver:
    cores: 1
    memory: "512m"
    serviceAccount: spark
  executor:
    instances: 1
    cores: 1
    memory: "512m"
  sparkConf:
    spark.eventLog.enabled: "true"
    spark.eventLog.dir: "s3a://xxx.s3bucketname"
    spark.kubernetes.driver.secretKeyRef.AWS_ACCESS_KEY_ID: "aws-secrets:key"
    spark.kubernetes.driver.secretKeyRef.AWS_SECRET_ACCESS_KEY : "aws-secrets:secret"

[Text 3] Event Log 설정이 적용된 spark-submit CLI 사용 예제

[Text 3]은 Event Log 설정이 적용된 SparkApplication Object의 예제입니다. [Text 2]와 동일한 Driver/Executor Pod 스펙과 동일한 컨테이너 이미지를 이용하고 있습니다. “spec” 부분에 Spark 애플리케이션 관련 설정들이 포함되며, “sparkConf” 설정 부분은 submit-submit CLI의 “conf” 설정 부분에 해당합니다. 따라서 Spark on Kubernetes에 특화된 설정들이 “sparkConf” 설정에 포함되어 있습니다.

SparkOperator를 이용할 경우 spark-submit CLI를 이용하는 대비 얻게 되는 장점은 크게 세 가지 입니다. 첫 번째로 Spark 애플리케이션이 처리가 완료될 때까지 대기하지 않아도 됩니다. spark-submit CLI를 이용하여 Spark 애플리케이션을 제출하는 경우 Spark 애플리케이션이 처리될 때까지 spark-submit CLI를 실행시켜 두어야 합니다. 반면에 Spark Operator를 이용하면 사용자는 Spark Object를 생성만 하면 Spark Operator 스스로 Spark 애플리케이션을 제출하고 제출한 Spark 애플리케이션이 완료되기까지 대기합니다.

$ kubectl -n spark get sparkapplications.sparkoperator.k8s.io
NAME              STATUS            ATTEMPTS    START                                   FINISH                                   AGE
pi               RUNNING             1         2023-08-30T12:55:26Z                   <no value>                                17d
pi-eventlog     COMPLETED            1         2023-08-10T03:40:55Z               2023-08-10T03:42:52Z                          20d

[Text 4] Spark Application Object 조회 결과

두 번째로는 제출한 Spark 애플리케이션의 결과를 kubectl 명령어를 통해서 빠르게 확인이 가능하다는 점입니다. Spark Operator는 Spark 애플리케이션 제출 이후에 제출 결과를 Spark Object에 저장합니다. 따라서 사용자는 kubectl 명령어를 통해서 Spark Object 조회를 통해서 손쉽게 Spark 애플리케이션의 제출 결과를 확인할 수 있습니다. [Text 4]는 kubectl 명령어를 통해서 Spark Application을 조회하였을 경우의 예제입니다.

마지막으로 ScheduledSparkApplication Object를 통해서 AWS Eventbridge와 같은 별도의 서비스 이용 없이 간편하게 예약된 스케줄링에 따라서 Spark 애플리케이션을 제출할 수 있다는 장점을 갖습니다.

AWS CLI를 활용하여 Spark 애플리케이션 제출

AWS CLI에서 제공하는 “emr-containers start-job-run” 명령어를 통해서 Amazon EKS 클러스터에 Spark 애플리케이션 제출이 가능합니다. “emr-containers start-job-run” 명령어는 내부적으로 EMR on EKS에서 제공하는 StartJobRun API를 이용하여 Spark 애플리케이션을 제출합니다.

[그림 4] AWS CLI를 활용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처

[그림 4]는 AWS CLI를 활용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처입니다. AWS CLI를 통해서 StartJobRun API가 호출되면 Amazon EKS 클러스터에는 먼저 Job Runner Pod가 생성됩니다. Job Runner Pod는 내부적으로 spark-submit CLI를 이용하여 Spark 애플리케이션을 제출하고, 제출한 Spark 애플리케이션이 종료될때까지 대기하여 Spark 애플리케이션의 실행 결과를 Amazon EMR에게 알려주는 역할을 수행합니다. 즉 사용자 대신 Job Runner Pod가 spark-submit CLI를 대신 실행하고, 실행 결과를 확인하는 역할을 수행합니다.

EMR on EKS의 StartJobRun API는 AWS에서 제공하는 API이기 때문에 AWS 환경에 특화된 몇 가지 기능을 제공합니다. 첫 번째 기능은 EMR on EKS 환경에 최적화를 위해서 Spark 애플리케이션의 일부 설정을 자동으로 적용해주는 기능입니다. 적용되는 설정에는 Jar Class Path를 시작으로 EMR FS 관련 설정, Java 런타임 관련 등 다양한 설정들이 포함되어 있습니다. spark-submit CLI 또는 Spark Operator를 통해서도 EMR on EKS 환경에 최적화된 설정이 가능하지만, 사용자가 일일이 설정을 적용해야 합니다.

두 번째 기능으로 관리형 Spark History 서버 및 Amazon S3 기반의 Event Log 저장소를 이용할 수 있습니다. 사용자는 별도의 Spark History 서버를 운영할 필요가 없으며, Event Log 저장을 위한 Amazon S3 Bucket도 관리할 필요가 없습니다. StartJobRun API를 호출하면서 Event Log와 관련된 별도의 설정을 수행하지 않았다면 Event Log는 Amazon EMR에서 관리하는 별도의 Amazon S3에 저장됩니다. 별도의 Event Log 설정을 통해서 사용자가 원하는 Amazon S3의 Bucket에 Event Log를 저장할 수도 있습니다.

세 번째 기능은 Log 수집 기능입니다. StartJobRun API 호출을 통해서 Spark 애플리케이션 제출 시 생성되는 Job Runner Pod, Driver Pod, Executor Pod의 Stdout/Stderr는 간단한 설정으로 Amazon S3 또는 AWS Cloudwatch Logs에 저장할 수 있습니다. StartJobRun API는 기본적으로 Driver Pod에만 Sidecar Container로 Fluentd를 구동하여 Event Log만을 수집합니다.

하지만 Log 수집 기능을 설정하면 Job Runner Pod, Executor Pod에도 Sidecar Container로 Fluentd를 구동시키며, 모든 Fluentd에서 Pod의 Stdout/Stderr를 Amazon S3 또는 AWS Cloudwatch Logs에 저장합니다. 일반적으로 많이 이용되는 Log 수집기를 DaemonSet으로 배포하고 Log를 별도로 수집하는 방식도 적용이 가능합니다.

$ aws emr-containers start-job-run \
  --virtual-cluster-id xxx \
  --name=pi-logs \
  --region ap-northeast-2 \
  --execution-role-arn arn:aws:iam::xxx:role/xxx \
  --release-label emr-6.8.0-latest \
  --job-driver '{
    "sparkSubmitJobDriver":{
      "entryPoint": "local:///usr/lib/spark/examples/src/main/python/pi.py",
      "sparkSubmitParameters": "--conf spark.driver.cores=1 --conf spark.driver.memory=512M --conf spark.executor.instances=1 --conf spark.executor.cores=1 --conf spark.executor.memory=512M"
    }
  }' \
  --configuration-overrides '{
        "monitoringConfiguration": {
        "persistentAppUI": "ENABLED",
        "cloudWatchMonitoringConfiguration": {
        "logGroupName": "spark-startjobrun",
        "logStreamNamePrefix": "pi-logs"
      },
      "s3MonitoringConfiguration": {
        "logUri": "s3://ssup2-spark/startjobrun/"
      }
    }
  }'

[Text 5] Event Log 설정이 적용된 AWS CLI 사용 예제

[Text 5]는 Log 수집 기능이 설정된 AWS CLI의 예제를 나타내고 있습니다. StartJobRun API를 통해서 Spark 애플리케이션을 제출하기 위해서는 EMR on EKS에서 관리하는 가상의 Cluster인 Virtual Cluster를 먼저 특정 Amazon EKS 클러스터의 Namespace를 대상으로 생성해야 합니다. Virtual Cluster가 생성되면 고유한 Virtual Cluster ID가 발급되며, 이 발급된 Virtual Cluster ID를 “virtual-cluster-id” 설정을 통해서 StartJobRun API에 전달해야 합니다.

“release-label” 설정을 통해서 어떤 EMR 버전을 이용할지 결정하며 EMR 버전에 따라서 Driver/Executor Pod에서 이용하는 컨테이너 이미지가 결정됩니다. “name” 설정을 통해서 제출한 Spark 애플리케이션의 이름을 설정하며, “execution-role-arn” 설정을 통해서 Virtual Cluster에서 Spark 애플리케이션 제출 시 이용해야하는 AWS IAM Role을 명시합니다. “job-driver” 설정을 통해서 Spark 애플리케이션 지정 및 spark-submit CLI의 conf 설정을 수행하며, “configuration-overrides” 설정을 통해서 Log 수집 기능을 적용합니다.

$ aws emr-containers list-job-runs --virtual-cluster-id xxx
{
  "jobRuns": [
    {
      "id": "xxx",
      "name": "pi-logs",
      "virtualClusterId": "xxx",
      "arn": "arn:aws:emr-containers:ap-northeast-2:xxx:/virtualclusters/xxx/jobruns/xxx",
      "state": "COMPLETED",
      "clientToken": "xxx",
      "executionRoleArn": "arn:aws:iam::xxx:role/ts-eks-emr-eks-emr-cli",
      "releaseLabel": "emr-6.8.0-latest",
      "createdAt": "2023-09-04T13:20:50+00:00",
      "createdBy": "arn:aws:iam::xxx:user/ssupp",
      "finishedAt": "2023-09-04T13:26:28+00:00",
      "stateDetails": "JobRun completed successfully. It ran for 4 Minutes 53 Seconds",
      "tags": {}
    }
  ]
}

[Text 6] Spark Application Object 조회 결과

제출한 Spark 애플리케이션 정보는 EMR on EKS 서비스에서 관리합니다. 따라서 AWS CLI 또는 AWS 관리 콘솔을 통해서 제출한 Spark 애플리케이션의 결과를 확인할 수 있습니다. [Text 6]은 AWS CLI를 통해서 제출한 Spark 애플리케이션을 조회한 예제입니다.

이름	타입	설명
Spark Default Configs	ConfigMap	Spark 애플리케이션에 적용될 기본 설정 값을 저장합니다. EMR on EKS 환경에 최적화된 설정 값들이 기본적으로 적용되어 있습니다. (spark-defaults.conf)
Pod Template	ConfigMap	Pod Template은 spark-submit이 제공하는 기능이며 Sidecar 컨테이너 설정과 같이 세세한 Pod 설정을 위한 기능입니다. Fluentd Sidecar 컨테이너도 Pod Template 기능을 통해서 설정됩니다.
Fluentd	ConfigMap	Sidecar 컨테이너로 동작하는 Fluentd의 설정 값입니다.
Event Log S3	Secret	Driver Pod에서 동작하는 Fluentd Sidecar 컨테이너가 Amazon EMR이 관리하는 Amazon S3에 Event Log를 저장하기 위한 인증 및 접근 정보입니다.

[표 1] Job Runner Pod가 이용하는 ConfigMap 및 Secret

StartJobRun API를 통해서 제공하는 3가지 기능은 Job Runner Pod에 Volume으로 붙어 spark-submit CLI에게 다양한 설정값을 전달하는 Job Runner의 ConfigMap 및 Secret을 통해서 구현됩니다. Job Runner Pod에 설정되는 ConfigMap 및 Secret은 [표 1]에 정리되어 있습니다.

EMR Container Controller를 활용하여 제출

[그림 5] ACK EMR Container Controller를 활용하여 Spark 애플리케이션을 제출하는 경우의 아키텍처

[그림 5]는 ACK EMR Container Controller를 통해서 StartJobRun API를 통해서 Spark 애플리케이션을 제출하는 과정을 나타내고 있습니다. Spark Operator와 동일하게 ACK EMR Container Controller를 이용하기 위해서는 EKS 클러스터에 설치가 필요합니다. 사용자는 JobRun Object 생성을 통해서 StartJobRun API를 통해서 Spark 애플리케이션을 제출할 수 있습니다. 이외의 부분들은 AWS CLI를 이용하여 Spark 애플리케이션을 제출할 때와 동일합니다.

apiVersion: emrcontainers.services.k8s.aws/v1alpha1
kind: JobRun
metadata:
  name: pi-logs
  namespace: emr-ack
spec:
  name: pi-logs
  virtualClusterID: xxx
  executionRoleARN: "arn:aws:iam::xxx:role/xxx"
  releaseLabel: "emr-6.8.0-latest"
  jobDriver:
    sparkSubmitJobDriver:
      entryPoint: "local:///usr/lib/spark/examples/src/main/python/pi.py"
      entryPointArguments:
      sparkSubmitParameters: "--conf spark.driver.cores=1 --conf spark.driver.memory=512M --conf spark.executor.instances=1 --conf spark.executor.cores=1 --conf spark.executor.memory=512M"
    configurationOverrides: |
      MonitoringConfiguration:
        PersistentAppUI: "ENABLED"
        CloudWatchMonitoringConfiguration:
          LogGroupName: "spark-startjobrun"
          LogStreamNamePrefix: "pi-logs"
        S3MonitoringConfiguration:
          LogUri: "s3://ssup2-spark/startjobrun/"

[Text 7] Event Log 설정이 적용된 Job Run 예제

[Text 7]은 Event Log 설정이 적용된 Job Run 예제를 나타내고 있습니다. [Text 5]와 동일한 Driver/Executor Pod 스펙과 동일한 컨테이너 이미지, 동일한 Log 수집 설정을 이용하고 있습니다. AWS CLI의 설정 값들이 그대로 “spec” 설정 부문에 명시되어 있는 것을 확인할 수 있습니다.

$ kubectl -n emr-cli get jobruns.emrcontainers.services.k8s.aws
NAME          JOB-ID               STATE
pi        000000032irldp3gmll    SUBMITTED
pi-logs   000000032irp0t1ukal    COMPLETED

[Text 8] Job Run Object 조회 결과

[Text 8]은 Job Run은 Spark Operator와 동일하게 쿠버네티스 Object이기 때문에 Spark Operator의 Spark Object와 동일하게 사용자는 kubectl 명령어를 통해서 Spark Object 조회를 통해서 손쉽게 Spark 애플리케이션의 제출 결과를 확인할 수 있습니다. [Text 7]은 kubectl 명령어를 통해서 Job Run을 조회하였을 경우의 예제입니다.

결론

지금까지 EKS 클러스터 환경에서 이용 가능한 4가지 Spark 애플리케이션 제출 방법에 대해서 분석하였고, 각 제출 방식에 따른 장단점을 [표 2]에 정리하였습니다.

	spark-submit	Spark Operator	AWS CLI	EMR Container Controller
AWS 의존성	낮음	낮음	높음	높음
이용 API	EKS 클러스터 API	EKS 클러스터 API	EMR on EKS API	EKS 클러스터 API
Spark 애플리케이션 정보 조회	spark-submit CLI에서 출력	Spark Object 조회	EMR on EKS API를 통한 Job 조회	JobRun Object 조회 / EMR on EKS API를 통한 Job 조회
EMR on EKS 최적화 설정	사용자 설정	사용자 설정	기본 적용	기본 적용
Spark History 서버	사용자 구축 서버	사용자 구축 서버	EMR 관리형 서버 / 사용자 구축 서버	EMR 관리형 서버 / 사용자 구축 서버
Log 수집	사용자 설정	사용자 설정	EMR 관리형 설정 / 사용자 설정	EMR 관리형 설정 / 사용자 설정
예약 스케줄링	사용자 구현	Spark Operator 기능 이용 / 사용자 구현	사용자 구현	사용자 구현

[표 2] EKS 클러스터 환경에서 이용 가능한 Spark 애플리케이션 제출 방법 비교

spark-submit CLI를 직접 이용하는 방법 이외의 Spark Operator, AWS CLI, EMR Container Controller 방법들도 모두 내부적으로는 spark-submit CLI를 이용하며 Spark 애플리케이션을 제출하고 처리합니다. 따라서 EKS 클러스터 환경에서도 기존에 익숙하다는 이유만으로 spark-submit CLI를 직접 이용하는 것보다는 다양한 Spark 애플리케이션 제출 방식을 비교해 보고 요구사항에 맞는 Spark 애플리케이션 제출 방식을 선택하여 이용하시는 것을 권장 드립니다.

AWS 기술 블로그