목차 1. Yarn(Yet Another Resource Negotiator) 2. Spark Infra Architecture 3. EMR에서의 Spark 활용
1. Yarn(Yet Another Resource Negotiator)
클러스터의 리소스 관리 및 application 라이브 사이클 관리를 위한 프레임웍
Architecture
Scheduler : 자원 분배 역할(3가지 방식 제공) → 누가 누가 놀고 있나…너구나!
Application Master: Application별(SparkContext 또는 SparkSession) 생성되는 자원으로 Container 실행 및 작업 실행 역할 → Container들아 일 열심히 해!
Container: 실제 작업을 수행 → 데이터 읽고, 변환하고, 쓰고
Node Labels
워크로드 또는 비즈니스케이스에 따라서 Application 수행 시 서버의 특성에 맞게 인프라를 제공하는 방식
예시
Batch를 수행하는 Application vs Stream을 수행하는 Application
가벼운 작업을 수행하는 Application vs 무거운 작업을(ML) 수행하는 Application
2. Spark Infra Architecture
2-1. Submit Mode
Cluster Mode: Application Master내에 Driver 구동
Client Mode: Client 시스템내에 Driver 구동
Cluster Mode가 일반적으로 많이 사용되며 아래 설명들은 Custer Mode를 가정하고 설명
2-1. 장애 상황
OOM(out of memory), 네트웍 장애, Node 장애 상황 발생
이미 Spark 및 Yarn에서는 다양한 retry 옵션 제공하고 있음
yarn.resourcemanager.am.max-attempts
spark.yarn.maxAppAttempts
spark.task.maxFailures
Spark의 RDD는 immutable 하기 때문에 특정 Task 및 Executor가 장애가 발생한 경우에는 재 처리 시 처음부터 처리될 필요 없음 → 요런 장애는 수용할 만함
Application Master 장애가 발생한 경우에는 처음부터 다시 작업 처리가 필요함 → batch형 ETL 작업시에는 크게 이슈는 없을 수 있지만 분석가가 분석하는 상황에서 발생하면 곤란할 수 있음
3. EMR에서의 Spark 활용
Workload
ETL 처리용
Transient EMR: ETL용으로 활용되는 EMR로 단기 Instance로 활용 하는 경우가 일반적임→ 필요할때 생성해서 작업을 수행하고 끝나면 삭제 처리
분석가 데이터 분석용
Permanent EMR: 분석가 분석용으로 활용되는 EMR로 장기 Instance로 활용하는 경우가 일반적임 → 지속적으로 EMR을 구동하여 운영함
Infra Architecture
Node별 역할
Master Node
클러스터 관리
일반적인 분산 Application의 마스터 역할
Core Node
Hadoop 클러스터 환경에서 Data Node 역할
HDFS 구성 시 Core Node에 스토리지가 구성됨
Task Node
EMR에서만 제공되는 Node
일반적으로 메모리 작업이 필요한 Spark, Presto등과 같은 솔루션에서 스토리지를 제외한 컴퓨팅파워가 필요한 경우 활용
비용 최적화 관점
EMR의 경우 AWS 관리형 서비스중에 가격이 높은 서비스로 비용 최적화를 위해 Task Node에 대해서는 Spot Instance를 혼합하여 사용하는 것이 일반적임
Spot Instance
장점: 해당 리전에 가용 가능한 EC2 pool내에서 현재 활용되지 않는 EC2 자원에 대해 온디맨드에 비해 저렴한 가격으로 Instance를 활용할 수 있는 기능
단점: 해당 Instance를 언제 뺏길지 모름
Spot Instance 활용 시 문제점
Permanent EMR의 경우 비용 최소화를 위해 Task Node를 Spot Instance로 활용하는 경우가 많은데 만약 Application Master가 Task Node에 구동된 상태에서 자원이 뺏길 경우 전체 재 실행으로 인해 시간이 오래 소요되거나 최악의 경우 Application 실패 할 수 있음 → 분석가로부터 잦은 VoC 발생
Spot Instance 활용 이슈 해결 방안
EMR Cluster 구성
Master Node: On-demand
Core Node: On-demand
Task Node: Spot
Node별 labeling 처리
Yarn labeling 기능을 통해 Core Node와 Task Node에 labeling 처리를 하고 Resource Manager에서 아래와 조건으로 리소스 분배
Core Node : Application Master만 기동
Task Node: Executor만 기동
고려 사항
Core Node는 Application Master만 기동되기 때문에 가용성을 유지하면서 최소의 Spec 및 Node로 구성 → 놀고있는 자원이 많으면 돈낭비..
Task Node는 Core Node 대비 높은 Spec 및 Node로 구성
관련 설정 정보
# 전체 클러스터에 대한 설정
{
"classification":"spark-defaults",
"properties":{
"spark.yarn.executor.nodeLabelExpression":"TASK",
"spark.yarn.am.nodeLabelExpression":"CORE"
},
"configurations":[]
},
{
"classification":"capacity-scheduler",
"properties":{
"yarn.scheduler.capacity.root.accessible-node-labels.TASK.capacity":"100",
"yarn.scheduler.capacity.root.default.accessible-node-labels.TASK.capacity":"100"
},
"configurations":[]
}
# Task Instance에 대한 설정 내역
[{
"classification":"yarn-site",
"properties":{
"yarn.nodemanager.node-labels.provider.configured-node-partition":"TASK",
"yarn.node-labels.am.default-node-label-expression":"CORE",
"yarn.nodemanager.node-labels.provider":"config"
},
"configurations":[]
}]
# 추가 shell 명령어 실행(master node에서 실행)
yarn rmadmin -addToClusterNodeLabels "TASK(exclusive=false)
적용 결과
Label 처리 결과
Core Node : 10.1.1.183 서버에 실행
Task Node: 10.1.1.168, 10.1.1.133 두 서버에 실행
Application 생성 결과
SparkContext 생성시 10.1.1.183 서버에 Application Master(Driver), 10.1.1.133서버에 Executor가 구동된 모습을 볼 수 있음
여기까지 ‘Spark 6편: Yarn Resource Manager 라벨링’에 대해 소개해드렸습니다. 유익한 정보가 되셨길 바랍니다. 감사합니다.
