[Spark] AWS EMR vs Glue ETL 비교 정리하기 (성능, 비용, 특징, 실행 방법,...)

spark를 써봤다고 면접에서 어필을 할 때 나오는 단골 질문 중 하나인 어떤 제품을 통해 Spark를 실행 시켰으며 어떤 장점 때문에(왜) 해당 제품을 선택했나요? 다른 제품을 고려하지 않은 이유는? 에 대해 정리해보겠습니다.
(사실 제 경우에는 Glue ETL을 많이 사용하지 않았기에 정확하게 비교해 볼만한 기회가 없었습니다.)

---

1. AWS EMR이란

EMR은 Spark 를 포함한 Hadoop Ecosystem이 탑재된 하둡 클러스터입니다. 따라서 Hive Job 및 다양한 작업을 실행할 수 있습니다.
EMR(Elastic Map Reduce)는 크게 3가지로 나뉩니다.

1. EMR on EC2
2. EMR Serverless
3. EMR on EKS

이번 포스트에는 EMR on EC2와 EMR Serverless에 대해 간단하게 정리하고 AWS Glue와 특징을 비교해보겠습니다.

---

1) 특징

EMR on EC2

항목	설명
배포 방식	EC2, EKS 기반 클러스터 직접 구성
인프라 제어	EC2 인스턴스 타입, 수량, 스팟/온디맨드 선택 가능
자동 확장	가능 (Auto Scaling 설정 필요)
성능 최적화	사용자 설정에 따라 가능 (노드 유형, 인스턴스 타입 등)
시작 시간	수 분 소요 (클러스터 부팅 필요)
비용	클러스터 전체 실행 시간 기준 요금
제어 수준	매우 높음 (SSH 접근, 커스텀 구성 가능)
유즈케이스	장기 실행 배치, 데이터 웨어하우징, 복잡한 DAG 기반 처리 등

EMR Serverless

항목	설명
배포 방식	완전 관리형, 서버리스
인프라 제어	불필요 (용량은 자동 할당)
자동 확장	자동 (사용량에 따라 스케일 인/아웃)
성능 최적화	리소스 유닛 단위로 설정 가능 (CPU, Memory)
시작 시간	몇 초 ~ 1분 이내
비용	실제 작업 시간과 리소스 사용량 기준 과금
제어 수준	낮음 (SSH 접근 불가, 설정 제한적)
유즈케이스	짧은 실행의 일회성 ETL, 트리거 기반 Spark 처리, 비정기 배치 등

 

EMR on EC2 vs EMR Serverless

항목	EMR on EC2	EMR Serverless
운영 방식	사용자가 클러스터 구성	완전 서버리스
비용 모델	클러스터 시간 기준	작업 시간 + 리소스 단위
스케일링	수동/자동 설정	완전 자동
시작 속도	느림 (분 단위)	빠름 (초 단위)
유연성/제어	높음 (SSH, 설치 등 가능)	낮음 (제한된 설정)
사용 예	정기 배치, 대규모 처리	간헐적 ETL, 이벤트 기반 처리

use case

상황	추천
짧고 비정기적인 작업	✅ EMR Serverless
지속적 배치 처리, 비용 최적화 필요	✅ EMR on EC2 (스팟 인스턴스 적극 활용)
인프라 관리 피하고 싶을 때	✅ EMR Serverless
복잡한 튜닝과 제어가 필요한 경우	✅ EMR on EC2

 

---

2) 사용법 및 코드

제 블로그에 EMR job을 제출하는 법 부터 코드의 구성 등등 다양한 포스트가 있으니 이번 포스트에는 자세히 다루지 않겠습니다.

EMR on EC2

2023.07.30 - [BigData/Apache Airflow] - [Airflow] EMR create + Step 제출(Spark job) + StepSensor Dag 구성하기(feat. ETL)

[Airflow] EMR create + Step 제출(Spark job) + StepSensor Dag 구성하기(feat. ETL)

EMR serverless

2023.08.27 - [BigData/Spark & Spark Tuning] - [Spark] EMR Serverless + Airflow로 spark job 제출해보기 (EmrServerlessStartJobOperator, boto3 + PythonOperator)

[Spark] EMR Serverless + Airflow로 spark job 제출해보기 (EmrServerlessStartJobOperator, boto3 + PythonOperator)

---

3) 비용 산정 방식

EMR on EC2

항목	설명
EC2 인스턴스 요금	마스터/코어/태스크 노드의 EC2 시간당 요금 (온디맨드/스팟 선택 가능)
EBS 볼륨 요금	인스턴스에 연결된 스토리지 (GB/월 단위)
EMR 요금	EC2 위에서 실행된 EMR 클러스터에 대해 추가 요금 발생
S3 사용 요금	데이터를 저장/읽을 경우 별도 과금

예: m5.xlarge (4vCPU, 16GB RAM) 코어 노드 3개 + 마스터 1개, 2시간 운영

- EC2 요금 (서울 리전): 약 $0.23/hour × 4 × 2 = $1.84
- EMR 요금: 약 $0.045/hour × 4 × 2 = $0.36
- 합계: 약 $2.20 + EBS + S3 요금

EMR Serverless

1. 비용 구성

항목	설명
vCPU 시간당 요금	작업 중 할당된 vCPU 수 × 실행 시간
메모리 GB-시간 요금	작업 중 할당된 메모리(GB) × 실행 시간
I/O 비용	Shuffle 용 임시 데이터 저장 공간 사용량 (GB)

 
2. 시간당 리소스 비용

리소스	시간당 비용
vCPU	$0.052624 / vCPU-hour
Memory	$0.006844 / GB-hour
Disk (Shuffle I/O)	$0.000111 / GB

예: Spark 작업 실행에 vCPU 4개, 메모리 16GB 사용, 15분 동안 실행

- vCPU 요금: 4 × (15/60) × 0.052624 ≈ $0.0526
- 메모리 요금: 16 × (15/60) × 0.006844 ≈ $0.0274
- 합계: 약 $0.08 + I/O 비용

 

---

비용 비교 표

항목	EMR on EC2	EMR Serverless
과금 단위	인스턴스 시간 단위	리소스 × 실행 시간
최소 비용	클러스터가 작동하는 한 계속 발생	작업 실행 시간 동안만 발생
스케일링	수동 또는 자동 설정 필요	자동 확장 및 축소
제어권	EC2 설정 자유로움	제한적 (서버리스 제어 범위 내)
예측 가능성	상대적으로 낮음 (작동 시간 + 설정 복잡성)	높음 (사용한 리소스 기반)
spot instance 사용 가능	O (최대 90% 할인 가능)	X
짧은 작업 효율	비효율적	매우 유리
장시간 작업 효율	스팟 활용 시 비용 최적화 가	단가 높아질 수 있음

---

2. AWS Glue란

크게 Glue는 2개의 제품으로 나뉩니다.

1. Glue ETL(최근에 Data Integration이 추가, Zero ETL) - Data Integration은 향후에 다뤄보도록 하겠습니다.
2. Glue Data Catalog

Glue ETL은 서버리스 기반의 데이터 통합(ETL: Extract, Transform, Load) 서비스입니다. 복잡한 인프라 설정 없이 데이터를 추출(Extract), 변환(Transform), 적재(Load)하는 작업을 손쉽게 자동화가 가능합니다.
 
Glue Data Catalog는 s3에 있는 데이터를 기준으로 External Table을 만들 수 있는 메타스토어 DB의 개념이며, Glue Crawler를 통해 스키마 유추를 가능할 수 있게 해줍니다.

---

1) 특징

항목	설명
서버리스	인프라 구성/운영 불필요. AWS가 리소스 자동 할당 및 확장
Spark 기반	내부적으로 Apache Spark 엔진을 사용해 병렬 데이터 처리
Glue Data Catalog	스키마 정보를 자동 수집/관리 (메타데이터 중앙 저장소)
자동화 도구	Glue Crawler로 자동 스키마 추출, 스케줄링 및 트리거 지원
GUI 지원	Glue Studio를 통한 시각적 ETL 개발 가능 (Drag & Drop UI)
다양한 데이터 소스 지원	S3, RDS, Redshift, JDBC, Kafka, DynamoDB 등과 통합 가능
Job 언어	PySpark, Scala (Glue 4.0 기준 일부 Python 라이브러리 지원)
워크플로우 구성	여러 Job 및 Crawler를 연결하는 Workflow 기능 제공

---

2) glue 예시 코드

from awsglue.context import GlueContext
from awsglue.job import Job
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext

# Spark 및 GlueContext 초기화
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session

# Job 파라미터 설정
args = getResolvedOptions(sys.argv, ['JOB_NAME'])
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# 데이터 소스에서 데이터 로드
datasource = glueContext.create_dynamic_frame.from_catalog(
    database="my_database",
    table_name="my_table"
)

# 데이터 변환 (예: 컬럼 이름 변경)
transformed_data = datasource.apply_mapping([
    ("old_column", "string", "new_column", "string"),
    # 추가 변환 규칙
])

# 변환된 데이터를 S3에 저장
glueContext.write_dynamic_frame.from_options(
    frame=transformed_data,
    connection_type="s3",
    connection_options={"path": "s3://my-bucket/output/"},
    format="parquet"
)

job.commit()

---

3) 실제 job 생성 프로세스

glue studio에서 job생성을 누른다.

ETL을 Glue의 특징 중 하나인 GUI로 구성할 수 있는 칸이 있으며

script만으로도 Job을 구성할 수 있게 지원도 한다.

Job details에서는 Spark 혹은 Spark streaming 을 선택할 수 있으며, glue 및 python의 version을 선택 할 수 있습니다.
또한 worker(CPU와 Memory)의 크기를 선택할 수 있으며, worker 수, scale in/out 여부, retry 횟수, job timeout시간 등 조정 할 수 있는 파라미터가 많습니다.(spark streaming의 경우 job timeout이 0이 default입니다.)

worker의 경우, Glue버전, worker type에 따라 다르지만 최대 299까지 지원

워커 타입	DPU 수	DPU 비용	vCPU 수	메모리	디스크 용량	최대 워커 수
G.0.25X(glue for ray)	0.25	$0.11	2	4 GB	84 GB (약 34 GB 사용 가능)	50
G.1X	1	$0.44	4	16 GB	256 GB (약 235 GB 사용 가능)	299
G.2X	2	$0.88	8	32 GB	256 GB (약 235 GB 사용 가능)	149
G.4X	4	...	16	64 GB	256 GB (약 235 GB 사용 가능)	74
G.8X	8	...	32	128 GB	512 GB (약 487 GB 사용 가능)	37

---

4) 비용 산정 방식

Glue에서는 Redshift의 데이터  처리 단위인 RPU와 비슷하게 DPU(Dynamic Processing Unit)의 개념을 사용합니다.

DPU (Dynamic Processing Unit)

• AWS Glue에서 작업 처리 성능(리소스)을 측정하는 단위
• 각 DPU는 특정한 양의 vCPU와 메모리(RAM)를 의미
• Glue는 작업(Job)을 실행할 때 최소 1개 이상의 DPU를 할당

glue version에 따라 사용할 수 있는 worker의 타입이 다르며 worker 스펙은 아래와 같음
(G 옆에 붙은 숫자가 DPU숫자를 의미)

계산 방식

worker number X DPU x (사용한 분 / 60) x $ DPU당 비용 = 총 비용
ex) 20 DPU × (15분 ÷ 60) × $0.44 = 약 $2.20

---

3. EMR vs Glue

1) 특징(장단점)

가장 큰 특징적인 차이는 아래와 같은 것 같습니다.

1. Serverless이냐 아니냐(Managed service인지, 자원이 autoscaling이 되는지)
2. 파라미터를 통한 spark job 튜닝이 되는지
3. hadoop ecosystem을 사용할 수 있는지 여부

1-1) Serverless 여부

• serverless인 제품의 특징은 full managed라는 점입니다. 특히나 자원의 autoscaling이 자동으로 되기 때문에 인프라를 관리할 필요도, 자원에 대한 걱정을 할 필요도 없습니다.
• 그 중에서도 EMR Serverless는 세부적인 spark config 튜닝이 가능하지만 glue는 spark config튜닝은 불가능한 것이 가장 큰 차이입니다.
• EMR on EC2는 인프라관리(노드 관리)를 포함하여 인프라가 provisioning되는 시간 등 관리포인트가 있지만, 노드를 구성하는 다양한 타입의 노드와(물론 하나의 클러스터에는 같은 계열의 노드를 사용하긴 해야합니다.) spot instance를 사용 가능하므로 큰 workload의 경우 최적의 튜닝이 가능하다는 장점이 있습니다.

---

1-2) spark job 튜닝 가능 여부

[Glue]
Glue는 기본적으로 DPU (Data Processing Unit) 기반으로 작업을 처리하며, worker 수(자원 단위)를 설정 가능

• executor/core 수, memoryOverhead, shuffle spill config 등 Spark 파라미터 튜닝의 한계가 있음(glue 3.0까지는)
• Glue는 리소스를 자동 조정하긴 하지만 정밀 튜닝은 불가능

glue 4.0 부터 몇개의 parameter를 전달할 수 있게 되었는데, 아래와 같은 항목은 여전히 불가능하고, spark3.0 feature나 partition 숫자는 변경 가능하게 되었습니다.

항목	설정 가능 여부	비고
spark.executor.instances	❌	Glue는 워커 수만 설정 가능, executor 수 직접 지정 불가
spark.executor.cores	❌	코어 수는 워커 타입(G.1X 등)과 워커 수에 의해 내부적으로 결정됨
spark.executor.memory	❌	워커 타입에 따라 고정된 메모리 크기 사용 (ex. G.1X = 16GB)
spark.executor.memoryOverhead	❌	내부적으로 Glue에서 설정하며 사용자 변경 불가
spark.task.cpus	❌	Task-level CPU 제어 불가
spark.dynamicAllocation.enabled	❌	Glue는 자체 워커 확장 메커니즘을 사용하며 이 옵션 사용하지 않음
spark.sql.shuffle.partitions	✅	파티션에 대한 설정 변경 가능
spark.sql.adaptive.enabled	✅	glue 4.0 부터 spark3.0의 특징인 AQE를 껐다 켰다 가능
enable-continuous-cloudwatch-log	✅	동작 관련 파라미터 설정 가능

 
[EMR]
EMR on EC2 및 EMR Serverless는 물리 node뿐만 아니라 spark config인 spark.executor.memory, spark.sql.shuffle.partitions, parallelism,AQE,shuffle 등 모든 설정을 조정할 수 있어 I/O 집중 작업, 대규모 shuffle, skew tuning 등에서 큰 장점이 있습니다.

---

1-3) hadoop eco 사용 여부

EMR 자체가 Hadoop cluster이므로 HDFS, Hive, presto, trino 이외의 hadoop ecosystem을 사용하려면 EMR을 사용하는 것이 맞고, 필요가 없는 경우에는 glue를 사용해도 무방합니다.

---

2) 종합적인 비교

항목	EMR on EC2	EMR Serverless	Glue ETL
서비스 유형	관리형 클러스터 서비스	서버리스 Spark/Hive 실행 서비스	서버리스 ETL 서비스
런타임 환경	EC2 기반 클러스터 구성 및 수동 관리	서버리스, 자동 리소스 관리	서버리스, 자동 리소스 관리
지원 엔진	Spark, Hive, Presto, Hadoop, HBase 등	Spark, Hive	Spark, Python Shell, Ray (4.0+)
클러스터 제어	사용자 제어: 수동 시작/중지/스케일링	클러스터 없이 실행, 자동 확장 및 종료	클러스터 없이 자동 실행, Glue Job 단위 실행
스토리지 연동	S3, HDFS, EBS, RDS, DynamoDB 등	S3, Glue Catalog, JDBC, RDS 등	S3, Glue Catalog, JDBC, Redshift, RDS 등
스케일링	수동 또는 Auto Scaling 설정 필요	자동 확장 및 축소 (초 단위 자원)	자동 확장 (워크플로우 기반)
요금 구조	EC2 인스턴스 비용 + EMR 요금	vCPU-sec + memory-sec 과금	DPU 시간 단위 과금 (기본 1 DPU = 4 vCPU + 16 GB)
튜닝 가능성	매우 높음: 모든 Spark/YARN 설정 가능	제한적: 일부 Spark 설정만 지원	제한적: Glue 4.0+ Spark config 일부 가능
작업 제출 방식	콘솔, CLI, Step API, SDK ,Airflow	콘솔, CLI, SDK, Step Function, Airflow	콘솔, Glue Studio, CLI, SDK, Airflow
작업 모니터링	CloudWatch, Spark UI, Ganglia	CloudWatch, Spark UI	CloudWatch, Glue 콘솔, Spark History Server
UI 및 개발 환경	- JupyterHub (EMR Notebook) - EMR Studio (Zeppelin 기반 IDE) - AWS CLI/SDK/Step Functions	- JupyterHub (EMR Notebook) - EMR Studio (Zeppelin 기반 IDE) - AWS CLI/SDK/Step Functions	- AWS Glue Studio (Visual ETL Designer) - Jupyter on SageMaker or local 개발 후 업로드
Spark version 제어	사용자가 지정 가능	사용자가 지정 가능	Glue 3.0, 4.0 등에서 제한된 버전 선택 가능
라이브러리 추가	Bootstrap, init script 등으로 자유롭게 가능	s3에 있는 파일을 통해 전달능	.whl, .egg 파일 업로드 또는 Python 라이브러리만 일부 지원 (제한적)
대표 Use Case	대규모 커스터마이즈 Spark 작업, 실시간 처리	비정기적 또는 자동 확장 Spark/Hive 작업	일상적 ETL, 정기 데이터 변환 및 적재
적합 대상	클러스터 제어가 필요한 엔지니어링 팀	클러스터 관리 없이 Spark 실행하고 싶은 개발자	GUI 중심의 ETL/데이터 엔지니어링 사용자

 
결론:

1. big workload를 튜닝하여 사용하고 싶을 때는 EMR이 맞는 선택
   (Spot instance와 세밀한 노드 설정과 spark config tuning 모두 가능)
2. 튜닝이 필요하지 않을 정도의 작은 workload, 간편하게, test용, GUI를 이용하여 ETL를 하고 싶을 때는 Glue가 적합
3. Spark 튜닝은 필요하지만 엄청 크고 긴 작업은 아닐 때, EMR Serverless가 EMR on EC2보다는 적합
4. Spark streaming이 필요한 경우에는 EMR on EC2가 적합(Serverless는 대체로 비싸다. 동일 workload를 상시로 사용하는 경우에는 당연히 더 비싸진다.)
5. Hadoop eco를 사용하는 경우에는 EMR이 맞는 선택
6. Informatica, talend와 같은 legacy platform으로부터 ETL할 때는 Glue도 좋은 선택

---

이번에 정확히 알게 될 것 같고, 면접에서 왜 glue도 있는데 EMR을 사용하셨어요? 라고 묻는다면, "big workload를 처리하기 위해 EMR에서 지원하는 세밀한 자원조정과 spark configuration을 사용하기 위해 Glue 대신에 EMR을 사용했었습니다." 라고 말하면 될 것 같습니다.