4. Yarn ( 하둡 기초 )

[ "하둡 완벽 가이드 4판" ] 공부한 후 정리한 내용 입니다

 

 

4. Yarn ( Hadoop 클러스터 자원 관리 시스템 )

클러스터 자원을 효율적으로 관리 + 분산 애플리케이션을 실행할 수 있게 해주는 자원관리 시스템

---

1) Yarn과 하둡 구조

• 하둡 생태계는 크게 세 계층으로 나뉨

계층	역할	예시
저장	데이터 저장	HDFS
계산	데이터 처리	YARN
애플리케이션	데이터 처리 로직	MapReduce, Spark, Tez

>> 즉, YARN은 계산 계층에서 클러스터 자원 관리 + 애플리케이션 실행 환경 제공

---

1.1 YARN 핵심 구성

• yarn은 두 가지 핵심 데몬 사용 ( 리소스 매니저 + 노드 매니저 )

구성 요소	역할
ResourceManager	클러스터 전체 자원을 관리, 어떤 작업에 얼마만큼 자원을 줄지 결정 (유일한 존재)
NodeManager	각 노드에서 컨테이너 실행, 상태 모니터링

 

컨테이너

• 애플리케이션이 실행되는 격리된 공간
• Unix 프로세스 혹은 Linux cgroup 기반
• cgroup: CPU, 메모리 등 자원 사용 제한 가능

---

1.2 YARN 에서 애플리케이션 실행 흐름

yarn 실행 흐름 아키텍처

1. 클라이언트 → ResourceManager
   • "이 작업 실행해 주셈!"
   • 예: Spark job, MapReduce job
2. ResourceManager → NodeManager
   • RM은 실행할 컨테이너 위치 결정 후 NM에 애플리케이션 마스터(Application Master, AM) 실행 요청
3. 애플리케이션 마스터 → 작업 수행
   • 직접 작업하거나, 노드 매니저에 추가 컨테이너 요청 후 작업 분산 처리
   • MapReduce 예시: AM이 여러 매퍼/리듀서를 조정

• YARN 자체는 애플리케이션 간 통신, 결과 처리 기능은 제공하지 않음 ( 환경만 제공 )
• 상태 변경, 결과 전송 등은 각 애플리케이션이 Hadoop RPC 등을 통해 직접 처리

---

1.3 YARN 자원 요청

• yarn은 리소스( cpu + 메모리 ) 만 요청하는 것이 아니라 "컨테이너 위치" 까지 지정 가능 ( 데이터 지역성 )

예시: MapReduce의 "Map Task"
1. 데이터 블록이 있는 노드
2. 같은 랙 내 다른 노드
3. 클러스터 전체

또한, 동적 자원 요청도 가능 >> 실패 task 재실행할 컨테이너 요청

즉, YARN은 유연하게 자원을 요청하고, 데이터 근처에서 작업 실행을 최적화합니다.

---

1.4 애플리케이션 수명

• yarn 애플리케이션 = 애플리케이션 마스터( AM ) + 컨테이너

유형	특징	예시
일회성	작업 끝나면 종료	MapReduce Job
세션형	한 세션 동안 유지, 컨테이너 재사용 가능	Spark Job
장기 실행형	항상 실행, 여러 사용자 공유 가능	Impala, Slider

• 장기 실행형은 빠른 응답과 새 AM 구동 오버헤드 회피 가능

---

1.5 yarn 위에서 애플리케이션 만들기

• 애플리케이션 만들 떄는 "처리 방식에 맞는" 프레임워크나 관리 도구 선택하면 됨

[ 프레임워크 선택 ]

• 방향성 비순환 그래프(DAG) 처리: Spark, Tez
• 스트리밍 처리: Spark Streaming, Samza, Storm

[ 애플리케이션 관리 도구 ]

도구	특징
Apache Slider	분산 애플리케이션 실행, 노드 수 조절, 중지/재시작 제어
Apache Twill	자바 Runnable 객체 기반, 실시간 로깅, 명령 메시지 제공
Distributed Shell	YARN Client API 사용 예제, 복잡한 스케줄링 실습용

• 즉, YARN 위에서 애플리케이션을 만들 때는 처리 방식과 요구사항에 따라 도구 선택

---

 

 

 

2) Yarn VS MapReduce1 차이 정리

• 하둡은 처음 MR1 구조로 만들어졌지만,, >>  확장성 + 효율성의 한계로 YARN 기반 MR2 구조로 발전함

---

2.1 MR1 vs MR2 ( YARN ) 개념 정리

항목	MapReduce1	MapReduce2 ( Yarn )
핵심 구조	JobTracker + TaskTracker	ResourceManager + NodeManager + ApplicationMaster
자원 단위	슬롯	컨테이너(Container)
잡 관리 방식	JobTracker가 모든 잡 관리	RM이 자원 관리, AM이 잡별 관리
확장성	낮음 (JobTracker 병목)	높음 (작업 분산 관리)
가용성(HA)	적용 어려움	RM/AM 분리로 HA 가능
지원 애플리케이션	MapReduce만 가능	Spark, Tez, MR 등 다양한 프레임워크 가능

---

2.2 MR1 구조

• JobTracker (마스터): 전체 잡 스케줄링, 진행상황 모니터링
• TaskTracker (워커): 실제 태스크 실행, JobTracker에 상태 보고

[ 문제점 ]

• JobTracker가 모든 작업을 혼자 관리 → 클러스터 커지면 병목 발생
• 확장성 제한 + 장애 시 전체 중단

---

 

2.3 MR2 ( Yarn ) 구조

구성요소	역할
ResourceManager (RM)	클러스터 전체 자원 관리 및 스케줄링
ApplicationMaster (AM)	각 애플리케이션(잡)별 작업 관리 (자기 팀장 역할)
NodeManager (NM)	실제 컨테이너 실행, 자원 사용 모니터링
Container	실행 단위 (CPU, 메모리 등 자원 단위)

• 즉, yarn 에서는 JobTracker의 역할이 리소스 매니저 + 애플리케이션 마스터로 분리되 병목이 해결

---

2.4 MR2 ( Yarn ) 장점 정리

[ 확장성 ]

• MR1: JobTracker가 모든 잡 관리 → 큰 클러스터에서 병목
• MR2: RM은 자원만 관리, AM이 잡별로 관리
  → 클러스터가 커져도 부하 분산 O

 

[ 가용성 (High Availability) ]

• MR1: JobTracker의 상태 정보가 계속 바뀌어 복제 어려움 → HA 불가
• MR2: RM + AM 분리로 HA 적용 용이
  • RM HA, AM HA 모두 가능
  • 장애 발생 시 다른 노드가 이어받음

 

[ 효율성 ]

• MR1: 고정 슬롯 구조 → Map 슬롯 / Reduce 슬롯 따로 설정
  → 남는 슬롯 발생 시 비효율
• MR2: 컨테이너 기반 동적 자원 할당
  • 필요한 만큼만 자원 요청
  • 남는 자원 재활용 가능

MR1: 리듀스 슬롯 비어도 맵 슬롯 부족하면 대기
MR2: 빈 자원 있으면 아무 작업이나 실행 가능

 

 

[ 멀티테넌시 ]

• MR1: MapReduce만 가능
• MR2: Spark, Tez, Samza 등 여러 프레임워크 공존 가능
  → YARN은 "범용 자원 관리 플랫폼" 이 됨

---

2.5 요약 정리

• MR1은 “잡트래커 혼자 다 하는 구조” → 병목과 비효율
• MR2(YARN)는 “역할 분리 + 컨테이너 기반 자원 관리”로 확장성 + 효율성 + 가용성 + 멀티테넌시를 모두 해결했습니다

---

 

 

 

3) Yarn 스케줄링

• Yarn은 클러스터 자원을 여러 Job에게 나눠주는 역할을 함
• 즉, "누가 얼마나 자원을 가져갈까"를 결정 하는 것이 Yarn 스케줄러
• 상황에 따라 최적의 정책은 다르기에.. "사용자가 직접 스케줄링 설정"

---

3.1 스케줄러 종류

스케줄러	특징	추천 상황
FIFO	먼저 들어온 작업부터 순서대로 실행	혼자 쓰는 환경
Capacity	큐별로 리소스 비율 지정 (예: A 70%, B 30%)	사용자별 비율이 명확할 때
Fair	공평하게 자원을 나눔 (동적 분배)	다양한 Job이 섞여 있을 때

 

 

[ FIFO 스케줄러 ]

- 먼저 온 놈부터 드루와!!

• 큐에 들어온 순서대로 Job 실행
• 설정이 간단하고 직관적
• but.. 큰 Job 하나가 클러스터 전체를 독점할 수도 있음

 

[ Capacity 스케줄러 ]

- 큐별로 미리 리소스 나눠!!

• 큐 단위로 리소스 비율 미리 할당 (예: A큐 70%, B큐 30%)
• 사용자가 많거나 조직별 비율을 줄 때 좋음

장점: 장기 Job + 짧은 Job 동시에 가능
단점: 남는 큐가 놀면 전체 활용률 떨어짐.. ↓

 

 

[ Fair 스케줄러 ]

- 모두 공평하게 균등 배분해서 쓰자!!

• Job이 들어오면 자원을 동적으로 반반 나눔
• 큐별 자원 예약 없음 → 자원 활용도 높음
• 단, 가용량이 실시간으로 바뀌어 예측이 어려움

추천: 다양한 Job이 섞인 환경

---

3.2 Capacity 스케줄러 자세히!!

[ 기본 개념 ]

• 각 조직/사용자에게 고정 비율의 자원 할당
• 큐별 계층 구조(조직별, 사용자별 트리) 가능
• 큐 안에서는 FIFO 방식으로 실행

 

[ 큐 탄력성 ]

• 다른 큐가 안 쓰는 자원을 잠깐 빌려쓰기 가능
• 하지만!
  • 자원 회수 지연 가능 ( 비선점.. 바로 안 뺏음 )
  • 자원 과점 문제 : 특정 큐가 과점할 위험 있음 → maximum-capacity 설정으로 제한 가능

 

[ 주요 설정 & 옵션 ]

항목	설명
큐 계층 구조	조직별 / 사용자별 큐 트리 구성
가용량 / 최대 가용량	기본 및 최대 비율 지정
사용자 최대 자원	한 유저가 쓸 수 있는 최대치 제한
동시 실행 앱 수	한 큐 내 실행 가능한 앱 수 제한
ACL (접근제어)	특정 사용자만 큐 접근 허용

 

 

[ 큐 지정 방법 ]

• MapReduce 잡 기준:
  mapreduce.job.queuename=test1
  👉 큐가 없으면 에러, 지정 안 하면 기본 큐(default)로 들어감.
• 큐 이름은 최하위 큐 이름만 사용 (예: test1, test2)
• root.test1 처럼 전체 경로는 사용 불가.

 

 

[ 설정 예시 ]

• capacity-scheduler.xml :  큐 설정 파일

<configuration>
  <property>
    <name>yarn.scheduler.capacity.root.queues</name>
    <value>test1,test2</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.test1.capacity</name>
    <value>40</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.test2.capacity</name>
    <value>60</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.test2.maximum-capacity</name>
    <value>75</value>
  </property>

  <property>
    <name>yarn.scheduler.capacity.root.test2.queues</name>
    <value>sy,jw</value>
  </property>
</configuration>

 

 

 

• 큐 구조

root
 ├─ test1 (40%)
 └─ test2 (60%)
     ├─ sy (50%)
     └─ jw (50%)

---

3.3 Fair 스케줄러 자세히!!

[ 기본 개념 ]

• 모든 애플리케이션에 공평하게 리소스 분배!
• 기본 단위는 큐(queue)
• 사용자 단위 큐도 생성 가능 (ex. user1 큐, user2 큐)

ex..)
사용자1 Job 실행 >> 사용자1 : 100%
사용자2 Job 실행 >> 사용자1 : 50%, 사용자2 : 50%
사용자2 Job 추가 >> 사용자1 : 50%, 사용자2 : 25%, 사용자2 : 25%

 

 

 

 

[ 활성화 방법 ]

• yarn-site.xml >> 아래 설정 추가 ( Fair 스케줄 쓸거임!! )

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

 

 

[ 설정 예시 ]

• fair-scheduler.xml : 큐 설정 파일

<allocations>
  <queue name="test1">
    <weight>2</weight>
    <schedulingPolicy>FIFO</schedulingPolicy>
    <minResources>1024 mb,1 vcores</minResources>
    <maxResources>4096 mb,4 vcores</maxResources>
    <maxRunningApps>2</maxRunningApps>
  </queue>

  <queue name="test2">
    <weight>3</weight>
    <schedulingPolicy>FAIR</schedulingPolicy>
    <minResources>1024 mb,1 vcores</minResources>
    <maxResources>6144 mb,6 vcores</maxResources>
    <maxRunningApps>4</maxRunningApps>

    <queue name="sy"><weight>1</weight></queue>
    <queue name="jw"><weight>1</weight></queue>
  </queue>
</allocations>

 

• test1: FIFO / 최소~최대 자원 지정 / 동시 2개 Job
• test2: FAIR / 동시 4개 Job
• sy, jw: test2 하위 큐 (균등 공유)

 

 

[ 큐 배치 규칙 ]

• queuePlacementPolicy

<queuePlacementPolicy>
  <rule name="specified" />
  <rule name="user" />
</queuePlacementPolicy>

 

• specified → 지정된 큐에 배치
• user → 사용자 이름과 동일한 큐 (없으면 자동 생성)

📌 추가 설정

• yarn.scheduler.fair.allow-undeclared-pools=false
  → 미리 선언되지 않은 큐 자동 생성 금지
• yarn.scheduler.fair.user-as-default-queue=false
  → 큐 명시 안해도 default 큐 사용 가능

---

3.4 선점

• 공평하지 않게 자원이 몰릴 경우, 다른 큐의 컨테이너를 뺏어서 재분배!
• 설정: yarn.scheduler.fair.preemption=true

 

[ 두 가지 타임아웃 필요 ]

종류	설명
최소 공유 선점 타임아웃	최소 보장 자원 못받을 경우 다른 큐에서 자원 빼앗음
균등 공유 선점 타임아웃	균등 자원 절반 이하만 받았을 때 다른 큐에서 자원 빼앗음

 

 

설정 키

• 공통 설정: defaultMinSharePreemptionTimeout
• 큐별 설정: minSharePreemptionTimeout
• 균등 공유 기준(기본 0.5): fairSharePreemptionThreshold

 

[ 요약 ]

• 최소 공유 선점 타임아웃 : 아 이정도는 반드시 줘야됨..
• 균등 공유 선점 타임아웃 : 공평하게 나눠야하는 기준..
• 죽은 컨테이너?? 알빠 아님 Yarn이 재실행 보장

---

3.5 지연 스케줄링

• 컨테이너를 데이터와 가까운 노드에 배치하려는 기법. ( 지역성 )
• 바로 실행하지 않고 “조금 기다렸다가” 더 좋은 노드(데이터가 있는 곳)에서 실행.

 

[ 하트비트(Heartbeat) ]

• NodeManager ↔ ResourceManager 간 주기적 신호 교환
• 현재 실행 컨테이너 / 사용 가능한 리소스 정보 전달 ( new 컨테이너 실행할 가용 리소스 확인!! )
• 하트비트 받을 때마다 새 컨테이너 실행 기회 발생

 

[ 설정 예시 ]

• capacity 스케줄러

<property>
  <name>yarn.scheduler.capacity.node-locality-delay</name>
  <value>3</value>
</property>

## 최대 3번 하트비트 기다림
## 3번 동안 데이터가 있는 노드가 안비면.. ㅠㅠ 다른 노드에서 실행 ( 쩔수 없구만!! )

 

• Fair 스케줄러

<property>
  <name>yarn.scheduler.fair.locality.threshold.node</name>
  <value>0.5</value>
</property>

<property>
  <name>yarn.scheduler.fair.locality.threshold.rack</name>
  <value>0.5</value>
</property>

## 설명 ##
locality.threshold.node = 0.5
→ 클러스터 노드의 절반(50%) 범위까지 탐색 허용
locality.threshold.rack
→ 데이터가 있는 랙 대신 다른 랙에서 실행할 수도 있는 비율

 

 

[ 정리하면 ]

• “좋은 노드”를 우선 탐색
• 일정 횟수(또는 범위) 기다리다 못 찾으면
  👉 “같은 랙 내 다른 노드”로 확장
  👉 그래도 안 되면 “다른 랙”으로 확장

 

[ 트레이드 오프 ]

• 너무 오래 기다리면 리소스 낭비 (자원이 놀게 됨)
• 너무 짧게 설정하면 데이터 지역성(Locality) 이 떨어짐 (데이터 이동량 ↑, 속도 ↓)

따라서, 적당한 딜레이 설정이 성능의 핵심!

---

3.6 우성 자원 공평성 ( DRF )

• YARN은 CPU와 메모리 두 가지를 동시에 고려해서 자원을 나눠야 함. 하지만 단순히 “개수”로만 나누면 불공평해짐.

 

[ 우성 자원 ]

• 각 애플리케이션이 "가장 많이 사용하는 자원"

## 작업 예시 ##
앱 A가 CPU 2% + 메모리 3% 쓴다면 → 우성 자원: 메모리 (3%)
앱 B가 CPU 6% + 메모리 1% 쓴다면 → 우성 자원: CPU (6%)

 

DRF 적용 전

• B가 훨씬 많은 리소스를 차지 (불공평)

 

DRF 적용 후

• A와 B의 “우성 자원 비율”이 같아지도록 조정
  → 즉, A는 B의 절반 자원만큼 할당받음
  → 결과적으로 CPU와 메모리를 모두 고려한 공평한 분배 실현!

>> DRF는 각 앱의 우성 자원 비율이 동일하게 되도록 자원 분배 <<

 

 

[ DRF 활성 방법 ]

• 기본적으로 YARN은 메모리만 기준으로 리소스를 계산함.
• 즉, DRF는 기본 비활성화 상태 → 명시적으로 설정해야 함.

 

[ 설정 예시 ]

• Capacity 스케줄러 설정 ( capacity-scheduler.xml )

<property>
  <name>yarn.scheduler.capacity.resource-calculator</name>
  <value>org.apache.hadoop.yarn.util.resource.DominantResourceCalculator</value>
</property>

 

• Fair 스케줄러 설정 ( fair-scheduler.xml  )

<allocations>
  <defaultQueueSchedulingPolicy>drf</defaultQueueSchedulingPolicy>
</allocations>

## 모든 큐에 기본적으로 DRF 정책 적용 (원하면 특정 큐에만 적용도 가능)

---

 

 

 

1. YARN 개념: 하둡의 자원 관리 계층, 다양한 분산 애플리케이션 실행 지원.
2. 리소스매니저: 클러스터 전체 자원 관리 및 스케줄링 담당.
3. 노드매니저: 각 노드에서 컨테이너 실행 및 상태 보고.
4. 컨테이너: 애플리케이션이 실행되는 격리된 자원 단위(CPU+메모리).
5. 애플리케이션마스터(AM): 작업 단위(Job)별 실행 관리 및 컨테이너 요청 담당.
6. 실행 흐름: 클라이언트 요청 → RM이 AM 실행 → AM이 컨테이너 요청 및 작업 분배.
7. 자원 요청: CPU/메모리 + 데이터 지역성 고려 → 최적 노드 배치.
8. 스케줄러 종류: FIFO / Capacity / Fair → 자원 분배 정책 결정.
9. 우성 자원 공평성(DRF): CPU·메모리 중 더 많이 쓰는 자원 기준으로 균등 배분.
10. 지연 스케줄링: 데이터 지역성 위해 최적 노드를 기다려 배치.
11. HA 구조: Active/Standby RM 구성으로 장애 시 자동 복구 지원.