AWS EMR Cost optimization

AWS EMR 비용을 최적화 하려면?
(Apache Spark, Zeppelin/Jupyter notebook 서비스 대상)
2021.09
freepsw

2
AWS EMR ( Elastic MapReduce) ?
빅데이터 프레임워크(hadoop, spark, hive 등)의 실행 및 운영을 쉽게 해 주는 관리형 서비스(사용량 기반)
Web UI에서 간단한 설정으로 Big Data Framework를
빠르게 구성 가능
EMR에서 지원하는
Big Data Framework

3
기존 오픈소스 Apache Hadoop과 무엇이 다른가?
https://www.slideshare.net/AmazonWebServices/best-practices-for-managing-hadoop-framework-based-workloads-on-amazon-emr-aws-online-tech-talks
Apache Hadoop 구성 AWS EMR 구성
• 운영자가 직접 물리 서버(On-prem) 또는 클라우드 서버(EC2 등)
에 Apache Hadoop 환경을 구성
• 저장/관리할 데이터가 증가되면 서버를 증설해야 하는 구조.
• 즉, Computing과 Storage node가 결합됨
• 사용자가 쉽고 빠르게 Hadoop Cluster 구성 가능하며, Storage
와 Computing을 분리하여 구성 가능
사용량 기반으로 쉽게 Hadoop Cluster를 운영할 수 있으며, 필요한 리소스(Computing)만 추가하여 구성 가능
클러스터의 유연한 확장 가능

4
AWS에서 말하는 EMR의 장점은?
운영관리가 필요 없고, 낮은 가격으로 원하는 작업을 할 수 있다고 강조함.

5
그런데 실제 사용해 보면?
모든 선택은 사용자 직접
Cluster 사이즈 (Master, Core, Task)
EC2 Instance Type (100개 이상)
원하는 오픈소스 버전
성능이 너무 낮으면?
Cluster 개수 축소
EC2 Instance Type 변경 (낮은 사양)
EC2 계약 방식 변경 등…
비용이 너무 높으면?
Cluster 개수 증가
EC2 Instance Type 변경 (높은 사양)
상황에 따라서 기대보다 더 많은 비용이 청구!
대부분 성능향상을 위해
높은 비용의 서버를 많이 할당함
비용증가 성능 저하

AWS EMR의 과금 방식은?
전체 비용은 EMR 사용료 + EC2 Instance(Master, Core, Task)의 초당 사용료로 구성됨 (Region별로 다름)
EMR 사용료 산정 방식
• 가장 많은 비용은 클러스터를 구성하는 EC2 인스턴스가 차지
• EMR 비용은 클러스터 구성/관리 등의 운영 비용
사용 시간
AWS EMR 사용료 예시
• Region별, Instance 별로 EMR 요금이 부과됨. (약 20% 부과)
• 즉, Instance가 고 사양이며 노드 수가 많아지면 비용 증가
• EMR을 실제로 구성하는 것은 Master, Core, Task Node들이며,
• 이 Node(server)는 EC2 Instance로 실행
• 예를 들어 (Seoul Region, On-demand Instance인 경우)
• Master node 1대 : m5.xlarge (0.236$/h) + EMR(0.048$/h)
• Core node 3대 : r5.8xlarge(2.432$/h) + EMR(0.27$/h)
• 10시간 사용
• 전체 비용
• ( (0.236 + 0.048) + (2.432 + 0.27)*3대 ) * 10시간 = 83.9$

7
비용을 최적화 할 AWS EMR 서비스는?
Data 분석가들이 가장 많이 사용하는 notebook환경(Jupyter, Zeppelin)과 분산처리 엔진인 Apache Spark
데이터 분석가는 AWS EMR을 어떻게 활용할까?
• 분석가는 Notebook UI에서 거의 모든 분석을 수행하며,
• 대용량 처리가 필요한 경우에만 Apache spark 작업을 실행
1. Notebook을 활용하여 python으로 데이터 분석
데이터 분석가
2. 대용량 데이터 분석은 spark cluster 활용
• Apache spark의 Cluster 성능에 따라 작업 시간에 영향
AWS EMR의 내부 동작 구조는?
• AWS EMR에서는 물리적으로 Master와 Core/Task 노드로 분리
되어 동작하며, 각 노드 별로 필요한 자원을 할당해야 한다.
Master node
- Notecook의 python 코드가 실행되는 서버
- Python(pandas 등)으로 처리할 데이터가 많다
면 cpu/mem 많이 확보
- Spark driver가 동작함 (client mode인 경우)
Core/Task node
- Pyspark 코드가 실행되는 서버
- 데이터가 분산되어 다수의 서버에서 실행
- 분산처리 성능을 향상하려면 Core/Task 노
드의 cpu/mem을 증가
- 노드의 수량도 조절 필요
데이터 분석가
Master
Node
Core/Task
Node

8
최소의 서버 대수로
(Instance 비용 절감)
저가의 서버를 이용하여
(Instance 비용 절감)
빠르게 작업을 완료
(사용시간 단축)
모든 서버의 자원(cpu, memory 등)을
100% 활용할 수 있으려면?
적절한 EMR Cluster 사이즈는 어떻게?
어떤 EC2 Instance 유형을 선택해야 할까?
최적의 EC2 Instance는?
Apache Spark의 성능을 향상하려면?
어떻게 비용을 최적화 할 것인가?
최소의 서버 규모로, 저가의 서버를 이용하여, 빠르게 원하는 작업을 완료

최적의 EMR Cluster를 구성하려면?
9

10
최적의 EMR Cluster를 구성하기 위한 고민들 …
최소의 Cluster size로 가능한 낮은 비용의 EC2 Instance를 이용하여 짧은 시간에 작업을 완료
EMR Cluster 구성은?
EC2 Instance 계약 방식은?
서비스 실패를 최소화하려면?
(Spot Instance 사용시)
• Node 유형별 적합한 서버 자원을 할당
• Master Node : Cluster 관리 용도 및 분석용 notebook(jupyter, zeppelin) 실행 용도
• Core/Task Node : Apache Spark에서 분산 처리에 필요한 용도
• EMR Cluster의 사이즈를 몇개로 구성해야 할까?
• 단기 작업 실행 용도 : 높은 성능으로 빠르게 처리 (다수의 고성능 노드 할당)
• 장기 클러스터 운영 용도 : 평균적인 성능으로 다수의 작업을 안정적으로 처리 (Scale out을 고려한 할당)
• 어떤 계약 방식을 사용할 것인가?
• 일부 장애를 감안한 Spot Instance : 가장 싼 가격이지만, 서버가 불시에 중지 될 수 있음(작업 실패 가능성)
• 미리 싼 가격으로 구매하는 Reserved Instance : 오랜 기간 동안 싼 가격(On-demand 대비 60%)에 사용
• 기본은 On-Demand : 필요시 바로 구매, 가장 비싼 가격
• 분석 업무의 목적에 따라 계약 방식 선택 필요
• 다만, Spot Instance를 사용하는 경우 서버 중지로 인한 대안 고려 (작업 재처리로 인한 비용 과도 발생)
• Spot Instance 사용시, Master node instance 회수로 인한 작업 실패를 방지할 것인가?
• Master Node가 회수되거나, Core Node(Driver 실행 중인)가 회수되는 경우 모든 작업이 실패
• 이로 인한 재 작업 시간/비용 소요
• 오래 실행되는 작업은 Master, Core Node를 On-Demand로 활용 검토

11
AWS EMR Cluster에서 각 Node들은 어떤 역할을 할까?
EMR Cluster에서 각 Node의 역할
• 각 Node 별로 클러스터 관리 및 spark 실행에 필요한 프로세스를 관리
https://www.slideshare.net/JulienSIMON5/amazon-elastic-map-reduce-the-concepts https://medium.com/nerd-for-tech/aws-elastic-map-reduce-intro-55206fd47c85
EMR cluster 관리를 위한 Yarn과 Spark 실행에 필요한 프로세스 실행에 필요한 프로세스로 구성됨
Node 별 상세 설명
• Master Node
• EMR Cluster 전체 자원 관리 (Resource Manager)
• HDFS의 Name Node로 Core Node의 Data Node 관리
• Apache Spark의 Driver 실행 (Zeppelin/Jupyter의 경우)
• 노드 종료 시 EMR 전체 서비스 중지 (작업 실패)
• Core Node
• 현재 Node의 리소스 관리(Node Manger)
• EMR Cluster의 Application을 관리 (Application Master)
• HDFS의 Data Node로 데이터를 저장/관리하는 역할
• Apache Spark의 Driver 실행 (Application Master에서 관리)
• Apache Spark Executor 실행
• 노드 종료 시 Spark Driver 종료로 작업 실패 가능(HDFS에
check point로 복구 가능)
• Task Node
• 현재 Node의 리소스 관리(Node Manger)
• Apache Spark Executor 실행
• 노드 종료 시 Driver에서 다른 Node로 작업 재분배
Resource
Manager
Name Node
Node Manager
Spark Driver
Executor
YARN
HDFS/Spark
Application
Master
Spark
Executor
Data Node
Node Manager
Web UI
Spark Driver Livy server
• Core Node는 자체적으로 HDFS Data Node를 실행하여 분산 파일을
저장/조회 가능함.
• Task Node는 병렬 처리를 위한 용도로만 사용 (데이터 저장 없음)

12
Master Node는 어떻게 선택해야 하나?
• 순수 python(pandas 등)을 이용하는 작업은 master node 자원을 사용
(Zeppelin, Hue, Jupyter 등)
• Memory 및 Disk I/O가 높은 인스턴스 유형 선택 (R5 Type)
• 나머지 core/task 노드의 자원 스펙은 최소화하여 비용 절감 (m5 Type)
용도별로 적합한 Master Node 자원을 선택
단일 Python 분석을 위한
Master Node Type
대용량 분석 작업용
Master Node Type
• 분산 데이터 처리 및 학습을 하는 경우 Master Node 자원 최소화
• 만약, Notebook환경(zeppelin, jupyter)에서 spark code 실행 시,
• Client mode인 경우에는 spark driver가 master node에서 실행 됨.
• 이때는 spark driver의 역할에 따라서 자원을 충분히 할당
• EMR Cluster 사이즈가
• 50개 이하는 m5.xlarge 권장
• 50개 이상은 부하에 따라 m5.xlarge 이상을 선택
R5 계열 Type 권장
작업량에 따라 메모리 선택
(R5d or R5n)
M5 계열 Type 권장
(m5.xlarge)
1. 최적의 EMR 클러스터 구성

13
최적의 Core/Task Node 사이즈는 어떻게 결정할까?
Apache spark의 작업은 배포 모드에 따라 EMR 클러스터 노드의 자원을 다르게 사용함.
EMR에서 Spark Job의 실행 절차 (client mode)
• Master node에서 spark driver가 실행됨
EMR에서 Spark Job의 실행 절차 (cluster mode)
https://aws.amazon.com/ko/blogs/korea/submitting-user-applications-with-spark-submit/
• Notebook에서 pyspark 코드 실행 시 동작 구조는 아래와 같다
https://docs.cloudera.com/HDPDocuments/HDP3/HDP-3.1.4/running-spark-applications/content/using_livy_with_interactive_notebooks.html
Master Node Core/Task Node
Master Node Core Node Task Node
• Resource Manager가 지정한 Node(Core or Task)에서 실행됨
• Notebook에서 pyspark 코드 실행 시 동작 구조는 아래와 같다
Master Node Core Node Core/Task Node
Master Node Core Node Task Node

14
최적의 Core/Task Node 사이즈는 어떻게 결정할까?
처리할 데이터 사이즈와 원하는 작업 완료 시간에 따라서 조정
어떻게 Core/Task Node 사이즈를 결정할까? Core와 Task Node를 둘 다 사용해야 할까?
• Core Node (필수 1개 이상)
• HDFS를 실행하여 spark에서 데이터 관리 가능 (데이터 복구 등)
• Application Master는 Core Node에서만 실행
• Spark driver는 Application Master에서만 실행됨.
• Task Node (옵션 0개 이상)
• 병렬 처리(computing) 용도로만 활용
• Core/Task Node 비용은?
• Instance Type이 동일하면, 동일한 비용을 과금.
• 보통은 Core Node만 할당하여 작업을 실행
• 낮은 비용으로 성능 향상을 위해서
• Task Node를 Spot Instance로 많이 활용
• Task Node는 중지 되어도 전체 spark job에 영향 없음
• 다만, Job의 전체 메모리가 부족해 지지 않도록 개수 고려
https://enterprise-docs.anaconda.com/en/latest/admin/advanced/config-livy-server.html
https://livy.incubator.apache.org/get-started/
• 자원 모니터링을 통한 사용량 측정
• 실제 실행하지 않고 필요한 자원을 예측하는 것은 쉽지 않음.
• 동작하는 pyspark 코드를 실행하여 자원을 얼마나 사용하는지 모
니터링 후, 필요한 자원을 재할당
• 어떻게 서버의 자원을 모니터링 할까?
• AWS EMR에서 기본으로 제공하는 Ganglia Web UI 활용
• 각 서버(Master, Core, Task)의 자원 사용량을 그래프로 확인
• 어떤 정보를 확인할까?
• Master Node
• 자원이 충분히 활용되는가? (더 싼 서버로 대체?)
• Core/Task Node
• 최대/평균 Memory 사용량 (서버 대수 조정, 스펙 조정)
• 최대/평균 CPU 사용량 (서버 대수 조정, 스펙 조정)

15
AWS EMR 자원을 모니터링 하려면?
Cluster node 자원 모니터링 (Ganglia) Spark 성능 최적화 방안
Cluster Node의 자원 사용량과 Apache spark의 처리 상태 모니터링
• 전체 EMR Cluster에서 사용하는 각 CPU/Memory/NW 사용률
• 각 Node별 CPU/Memory/NW 사용률
• 처리 중인 Apache Spark job의 현재 처리 상태 확인
• Stage의 개수 및 각 Stage의 처리 속도
• Task의 개수 변화 (너무 많거나 적은지)
• 사용중인 Memory 현황 등
• Apache spark의 job이 모든 자원을 충분히 사용하는지 확인
• 어떤 자원이 부족한지 확인하여 자원 재할당

16
EMR Cluster 자원 모니터링 예시 (1/2)
동일한 모델로 약 500개 모델 학습 (평균 30~40G 데이터 처리), 최대 83시간 소요 (1개 모델 당 10분)
Cluster 구성 (총 18대) : Master 1대(r4.8xlarge) , Core 2대 (r4.8xlarge), Task 15 (r4.8xlarge)
Job 현황 분석 (CPU, Memory) Job 현황 분석 (Master Node, Spark 설정)
• 메모리 사용량 (전체 4.3 TB)
• 최대 3TB 사용 (전체의 70%만 활용)
• CPU 사용량 (544 core) : 최대 60% 사용
• Master node 사용량 : 자원 사용률 낮음
Master
node
• Network 사용량 : 평균 1~1.5G 네트워크 전송 (데이터 셔플링 많음)
Spot 노드 회수로
자원 축소 발생

17
EMR Cluster 자원 모니터링 예시 (2/2)
자원 사용률 향상 및 비용절감을 위한 방안
자원 사용률 최대화 방안 (성능 향상) Node의 비용 최소화 방안
• Spark 병렬 작업 설정 변경
• Executor core/memory/size 설정 변경
• 주어진 자원(cpu/memory)를 최대한 활용
• 권장한 가이드에 따라 변경 후 최적화 필요
• Spark 성능 개선 옵션 변경
• Broadcast join 적극 활용 (데이터 size에 따라 결정)
• 500번의 loop에서 재사용하는 데이터 cache 적용
• Instance Type 변경 검토
• Shuffle이 많이 발생하는 구조라면,
• Disk I/O, Network Bandwidth가 높은 R5d, R5n 검토
• 실험을 통해 성능 개선 결과 확인 필요
• Master node 인스턴스 변경
• 범용 스펙인 m5.xlarge 노드
• Cluster 고가용성 확보
• Master Node HA 구성 또는 On-Demand 구성
• Task Node 사이즈 축소
• 약 70%의 CPU/Memory만 사용함.
• 이를 감안하여 15 * 70% = 11대 노드로 조정

18
Core/Task Node size & EC Instance 계약 방식
용도별로 적합한 Master Node 자원을 제공
Spot Instance 활용 방안
• 작업의 중요도가 낮으며, 작업이 실패한 경우 재처리 가능한 업무에 활용
• 임시로 할당 받은 서버로, 언제든 회수될 수 있음.
• 고려할 사항으로
• Master node가 회수되는 경우
• 전체 EMR Cluster 중지로 작업 실패
• Core node가 회수되는 경우
• spark driver가 실행되는 Application Master 삭제
• Core Node가 1개인 경우 작업 실패
• 대부분 Task Node에 Spot Instance를 사용
• Core Node에 활용하는 경우 Core Node를 2개 이상으로 설정
Spot 시간당 요금
Reverved (1년)
시간당 요금
EC2 Instance 계약 방식 별 요금 비교
• Apache Spark에서 많이 활용하는 R5계열(Memory-Intensive) 서버 비교
• On-Demand 대비 비용 절감 효과는 Spot Instance가 가장 높음 (약 80%)
80% 절감
38% 절감
• 위 비용은 Seoul Region 기준으로 산정

19
Spot Instance 사용시 ,에러로 인한 재처리 작업 최소화 (1/2)
긴 시간 동안 실행중인 작업이 Master/Core Node의 종료로 인해 실패하는 경우가 많음
• Master Node 회수
• EMR Cluster 전체 종료
• Spark Job 실패
• Core Node 회수
• 1대인 경우 : Spark Driver 종료로 Job 실패
• 2대인 경우 : 다른 Core Node에서 Spark Driver 실행 (Job 유지)
• Task Node 회수
• Driver가 실행되지 않으므로,
• 다른 Task Node에서 작업을 분산하여 처리함. (Job 유지)
Spark Job 실패 유형
( Spot Instance 사용시 서버가 회수 되는 경우 )

20
Spot Instance 사용시 ,에러로 인한 재처리 작업 최소화 (2/2)
Spot Instance로 구성하는 경우 자원 회수로 인한 재작업 비용 최소화
m5.xlarge 3대 + Core(r5.8xlarge) * 10대
(0.236$*3대 + 0.527$*10대) * 10 시간
EMR cluster HA(High Availability) 구성
• Master Node HA 구성
• 3대의 Master Node로 구성하여 장애 시 정상 동작
• 기존 1대 대비 3배의 비용 추가 되지만,
• Cluster 에러로 인한 재처리 비용 대비 효율적
• HA 구성 시 비용 비교
• 10시간 소요되는 작업이 Cluster 에러로 실패하는 경우 비용 (spot 요금)
On-Demand Instance 활용
• On-Demand Instance 적용하여 장애를 방지
• Master Node, Core Node 대상
• 전체 서비스에 영향을 주는 Node의 에러를 사전에 방지
• Spot 비용 대비 비용이 증가하나, 재처리로 인한 비용보다 절감
• Master Node(m5.xlarge)
• 0.062$(spot) >> 0.192$(on-demand) (0.17$ / hour 증가)
• Core Node(r5.8xlarge)
• 0.527$(spot) >> 2.432$(on-demand) (1.9$ / hour 증가)
m5.xlarge 1대 + Core(r5.8xlarge) * 10대
(0.0629 $ + 0.527$*10대) * 10 시간
53$
+
Error 비용
59$
• 기존 대비 HA 구성에 따른 비용 증가 약 6$ 추가(10시간 기준)
• HA 구성은 On-demand Type만 선택가능
• Master Node HA 구성 시
1. 비용 효율적인 EMR 클러스터 구성
연간 최대 2,800만원 절감 가능
(중요 EMR Cluster에 HA 적용하여 재 작업 제거 시)

비용 대비 높은 성능의 서버를 선택하려면?
(저가의 서버 활용)
21

22
Node 유형 별 Instance type 적용
단일 Python 작업 또는 분산 작업의 유형(NW 성능, Memory 성능)에 따른 선택 필요
대용량 병렬 처리/분석용 Instance Type
• 현재 가장 많이 사용하는 Instance Type은
• Memory 최적화 Type인 R6, R5, R4 계열
• 최신 Instance의 비용 대비 성능이 가장 좋음
• R6 (40% 향상)> R5 (40%향상) > R4
• R5 계열
• R5a 계열 권장
• R5와 동일한 성능이며, AMD CPU 사용 (동일 비용)
• R5d 계열 권장 (Nvme SSD 지원)
• Apache Spark에서 grouping/join 작업이 많은 경우,
• 임시 파일을 Disk에 저장 (이때 성능 개선 효과)
• R6g 계열
• 가장 최신 세대의 Instance.
• ARM기반 프로세서로 CPU 처리 성능 향상
• 동일 비용으로 높은 처리 가능
다양한 용도별 Instance Type
2. 최적의 Instance Type
• 단일 Python 작업(Juypter Notebook)은 대부분 단일 CPU만 사용함.
• Master Node에서만 실행됨.
• 분석 작업의 유형에 따라서 CPU/Memory 최적화 인스턴스 선택
• 대량의 데이터를 전처리 하는 용도 (Disk I/O 속도 중요)
• R5d 계열 권장 (Nvme SSD 제공)
• 외부(S3)의 대용량 데이터 처리 및 데이터 shuffling이 많은 작업
• R5dn 계열 권장 (Nvme SSD + 최대 25G의 높은 NW 대역폭 제공)
• 머신 러닝 모델 학습 용도 (8G 이하 데이터)
• Multi-Core processing으로 모델 학습 시 (sklearn, keras 등)
• C5, C6 계열 권장
• 멀티 CPU를 통한 병렬 학습에 효과적

처리 성능을 높여서 빠르게 작업을 완료하려면?
(성능 최적화)
23

24
Apache Spark 성능 최적화
분산 자원 할당 최적화 (Executor) Spark 성능 최적화 방안
3. 성능 최적화를 통한 사용 비용 절감
분산 처리 성능을 최적화하여, EMR Cluster 사용시간 및 비용 절감
• Executor 당 Core 수 : 5 이하 (범용적인 용도)
• 너무 적으면, executor 수 증가로 NW 및 데이터 셔플링
• 너무 많으면, executor 수 감소로 GC 부하 및 쓰레드 부하
• Executor 당 메모리 사이즈 : 4G ~ 64G
• 너무 큰 경우, GC로 인한 부하 증가
• 너무 적은 경우 분산 작업에 필요한 메모리 공간 부족
EMR Cluster
Core Node
(R5.4xlarge 10 대)
• 노드 당 CPU Core : 16 core, OS용 1 core 제외 = 15 core
• 10대 : 150 core
• 노드 당 Memory : 128 G, OS 및 기타 10% 제외 = 115G
• 10대 : 1150 G
• Executor 당 core : 5 core
• 1개 노드에 실행 가능한 Executor : 15 core / 5 core = 3 executor
• Executor 당 할당 가능한 메모리 : 115G / 3 executor : 38 G
최적 자원 할당 방법 (예시)
• Spark 병렬 처리 수준 : 전체 Core 개수 이상
• 너무 적으면, CPU가 유휴 상태로 방치됨. (자원 미사용)
• 너무 많으면, Task 스케줄링 비용 증가/과도한 자원 사용
• spark.default.parallelism
• Cache 활용 (성능향상)
• 한번 읽어온 데이터를 여러 번 읽을 경우 메모리에 저장
• .cache()
• Shuffle Partition 개수 조정 : 전체 Core 개수 이하
• 집계 SQL(Join, group by) 실행 시 할당되는 파티션 수
• spark.sql.shuffle.partitions
• BroadcastJoin 활용 (20M 이하는 적극 활용)
• 데이터의 shuffling이 없으며, 처리 성능 향상

25
어떻게 Apache Spark의 성능을 측정할까? (1/3)
Spark History Server의 분석 흐름 Executor 처리 성능 확인 (예시)
Spark History Server을 이용한 모니터링 및 성능 확인
• Spark History Server에서 ”Executors” Tab을 선택
• “Input”에서 데이터 이동이 많이 발생하는 것을 볼 수 있다.
• Stage간 데이터 이동이 많음 (groupby, join으로 인한 shuffling)
• 또한 특정 Executor 2개에서 각 680개의 Task가 실행되고 있다.
• 즉, 작업이 정상적으로 분산되어 처리되지 않음.
Job 확인
Stage 확인
• 실행한 spark code가 실제 어떤 방식으로 동작하는가?
• Cache가 적용된 영역은 어디인가?
https://sparkbyexamples.com/spark/spark-web-ui-understanding/
• Stage 내부의 Task가 어떻게 실행되었는가?
• Task 실행시 어떤 구간에서 많은 시간이 소요되었나?
상세 Stage 흐름
파악
• 개별 stage의 실행 순서 및 캐시 적용 확인
• Task/Partition 단위로 그래프로 시각화
Executor 처리
성능 확인
• Executor의 자원(cpu,mem)이 많이 사용되고 있는가?
• 특정 Executor에 Task가 너무 많이 할당되지 않았나?
• Executor간 데이터 이동이 많지 않은가? (Shuffle)
원본 데이터는 80M인데,
Spark job 실행을 위한 데이터 이동이 많음
• 분석가가 실행한 Spark job은 아래와 같은 단위로 성능 확인 가능

26
각 Stage 별 Task 실행 시간 확인 (예시) Task 분석 결과 예시
Spark Job의 각 Stage 별로 작업이 분산되어 실행되었는지 확인
• 좌측 Stage에서 실행된 총 Task 수 : 15개
• Task 실행 시간
• 전반적으로 하나의 Task가 오랜 시간 동안 실행됨.
• 이로 인해, 작업이 동시에 실행되지 못함. (병렬처리 효과 작음)
• Scheduler Delay 는 작음
• 좌측의 Stage에서 partition을 증가시키면?
• 데이터 분산 및 병렬 처리가 증가하고,
• 아래와 같이 작은 여러 개의 작업이 동시에 실행됨.
• 선택한 Stage의 Task들이 어떤 Executor에서 실행되었고,
• 각 Task의 구간별 소요시간을 확인 가능(Scheduler Delay 등)
15개 Task 실행 완료
위의 라인 1개가 Task 개
Executor 1
Executor 2
Executor3
이전 Task 완료 전 까지
다른 Task 대기중
자원할당을 위한
Scheduler delay 증가

각 Stage 간 데이터 이동 크기 확인 (예시)
Stage간 데이터 이동이 과도하지 않은지 확인
• “Stage” Tab에서 확인
• Stage간의 데이터 이동(input)이 빈번하고, 사이즈가 크다면 이를 최소
화 할 수 있도록 데이터를 사전에 전처리(Filter 등) 하는 것이 좋다.
Stage간 데이터 이동이 많으면,
성능이 저하될 수 있음.

28
정리해 보면,
업무 목적에 따라서 필요한 항목들을 조합하여 선택
최적의 EMR Cluster를
구성하려면?
비용 대비 높은 성능의 서버를
선택하려면?
성능을 높여서
빠르게 작업을 완료하려면?
• 적절한 Cluster Size 선정
• Ganglia 등으로 서버 자원 모니터링
• 모든 서버 자원이 최대한 활용되도록
클러스터 구성
• EC2 계약 방식 선택
• 작업의 중요도에 따라 선택
• On-Demand, Reserved, Spot
• 에러로 인한 재처리 작업 최소화
• 작업이 취소되지 않도록 가용성 확보
(Spot Instance 사용시)
• 최적의 Instance Type 선택
• 처리 성능 향상으로 자원 사용료 절감
• Node type 별 Instance type
• Master : Cluster 관리 용도
• Core/Task : 실제 작업 처리 용도
• 대용량 병렬 처리/분석 용도 (Apache spark)
• Memory Optimized Instance
• Storage I/O, Network I/O 성능 고려
• 데이터 shuffling 발생 시
• Apache Spark 성능 옵션 최적화
• Executor 자원 할당 최적화
• 모니터링을 통한 Job 최적화
• 분산 작업의 병목없이 처리
• 데이터의 불필요한 이동(shuffle) 최소화

최적화에 정답은 없으며,
업무 목적에 맞게 클러스터를 구성하고,
이를 모니터링(측정)하고,
측정결과를 반영한 성능/비용 최적화가 필요
29

AWS EMR Cost optimization

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to AWS EMR Cost optimization

Similar to AWS EMR Cost optimization (20)

More from SANG WON PARK

More from SANG WON PARK (15)

AWS EMR Cost optimization