Apache Hadoop YARN: yet another resource negotiator

세션대비

  • Haram Lee
  • 2026-03-12
  • projects / YBIGTA-DE / DE
#data-engineering

1. Introduction

  • 기존 Hadoop(MapReduce v1)의 한계

    1. 특정 프로그래밍 모델(MapReduce) 과 자원 관리 인프라가 강하게 결합되어 있었음
      → 개발자들이 MapReduce 모델을 억지로 비틀어 사용하게 됨

    2. 작업 제어 흐름(control flow) 이 중앙(JobTracker)에서 처리됨
      → 스케줄러/마스터의 확장성 문제와 병목이 계속 발생

  • YARN: 기존 monolithic 구조에서 벗어나려는 설계

    • 자원 관리 기능을 프로그래밍 모델과 분리

    • 스케줄링 관련 기능 일부를 애플리케이션별 컴포넌트로 넘김

    • MapReduce는 이제 YARN 위에서 실행되는 여러 애플리케이션 중 하나일 뿐임

    • 그래서 Spark, Tez, Giraph, Storm 같은 다른 프레임워크도 같은 클러스터 위에서 돌릴 수 있게 됨

2. History

YARN이 왜 필요했는지를 실무 경험에서 끌어낸 섹션.

핵심 요구사항은 대충 이런 것들:

  1. Scalability

    • 클러스터가 커지고 작업 수가 많아져도 중앙 스케줄러가 버텨야 함

  2. Multi-tenancy

    • 여러 팀/사용자가 하나의 공유 클러스터를 함께 써야 함

  3. Serviceability

    • 프레임워크와 자원 관리 계층이 분리되어야 업그레이드/운영이 쉬움

  4. Locality awareness

    • 데이터를 가진 노드/랙 근처에 작업을 붙여야 성능이 좋음

  5. High cluster utilization

    • 유휴 자원을 줄이고 클러스터를 촘촘히 써야 함

  6. Reliability / Availability

    • 중앙 장애나 노드 장애에 덜 취약해야 함

  7. Secure and auditable operation

    • 인증/보안/감사가 가능한 멀티테넌트 환경이어야 함

  8. Support for programming model diversity

    • MapReduce 말고 다른 계산 모델도 지원해야 함

  9. Flexible resource model

    • 고정된 map/reduce slot 대신 더 유연한 자원 모델 필요

  10. Backward compatibility

  • 기존 Hadoop 생태계를 너무 깨면 안 됨

즉 요약하면,

  • 예전 Hadoop은 MapReduce만 너무 잘 돌리도록 설계되어 있었고

  • 실제 사용자는 훨씬 다양한 워크로드를 올리기 시작했기 때문에

  • 자원 관리 플랫폼과 실행 프레임워크를 떼어낼 필요가 생긴 것.

3. Architecture

  • ResourceManager(RM): 클러스터마다 하나

    • 클러스터 전체 자원 상태와 노드 생존 여부를 추적

    • 자원 할당 불변식(fairness, capacity, locality 같은 정책)을 유지

    • 여러 테넌트 간 경쟁을 조정

  • ApplicationMaster(AM): 애플리케이션마다 하나

    • RM에 자원을 요청

    • 받은 자원으로 실제 실행 계획을 세움

    • 장애와 skew를 고려해 실행을 조정

  • NodeManager(NM): 노드마다 하나

    • 실제 worker 데몬

    • container 실행/종료/모니터링 담당

즉 구조는 대충:

  • RM = 중앙 자원 관리자

  • AM = 각 애플리케이션의 감독관

  • NM = 각 머신의 실행 관리자

3.1 Overview

  • RM은 애플리케이션 수요, 우선순위, 자원 가용성에 따라 container라는 형태의 자원 임대(lease)를 특정 노드에 할당한다.

  • Container = 특정 노드에 묶인 논리적 자원 묶음

    • 예: 2GB RAM + 1 CPU

    • 그냥 “프로세스”라기보다, 그 프로세스가 쓸 수 있는 자원 약속에 가깝다

  • NodeManager(NM) 는 각 노드에서

    • 자원 가용성 모니터링

    • 장애 보고

    • container 생명주기 관리(시작/종료)
      를 담당

  • RM-NM 통신은 heartbeat 기반
    → 중앙이 계속 polling하는 게 아니라, 각 노드가 주기적으로 상태를 올림

  • 클라이언트가 작업을 제출하면:

    1. RM이 접수

    2. AM용 container 하나를 먼저 확보

    3. 그 위에서 AM이 뜸

    4. 이후 AM이 자기 작업용 container들을 더 요청함

여기서 중요한 감각:

  • RM은 “자원만” 본다

  • AM은 “이 자원으로 무슨 일을 어떻게 돌릴지”를 본다

3.2 Resource Manager

RM은 세 가지 인터페이스를 가진다.

  1. 애플리케이션 제출 클라이언트용 공용 인터페이스

  2. 자원을 협상하는 AM용 공용 인터페이스

  3. 클러스터 모니터링과 자원 관리용 NM 대상 내부 인터페이스

ResourceRequest

AM은 하나 이상의 ResourceRequest로 자원 요구를 표현한다.

  1. 필요한 container 개수

  2. container당 자원량

  3. locality 선호

  4. 애플리케이션 내부 우선순위

즉 “나 2GB/1CPU짜리 container 200개 필요하고, 가능하면 이 노드/이 랙 근처면 좋고, 이 요청이 더 급해” 같은 식으로 말하는 것.

RM이 하는 일

  • NM heartbeat를 통해 올라온 가용 자원을 보고 요청을 추적/업데이트/충족

  • container를 할당하고, 그 container에 접근할 수 있는 token을 생성

  • 종료된 container의 exit status를 해당 AM에 전달

  • 새 NM이 클러스터에 합류하면 그 정보도 AM에 알려 줌

preemption

  • RM은 필요하면 애플리케이션에게 자원을 돌려달라고 요청할 수 있다.

  • 자원이 부족하고 스케줄링 불변식을 유지해야 할 때 발생

  • AM은

    • 덜 중요한 container를 반납하거나

    • 작업 상태를 checkpoint하고

    • 다른 container로 계산을 옮기는 식으로 대응할 수 있음

  • 협조하지 않으면 결국 RM이 NM에 지시해 강제 종료할 수도 있음

RM이 하지 않는 일

RM은 살아 있는 자원 스케줄링만 담당한다.
즉 RM은 다음을 하지 않는다.

  • 애플리케이션 실행 제어

  • task fault tolerance

  • 실행 중인 애플리케이션 상태/메트릭 제공

  • 프레임워크별 완료 작업 리포트 제공

이런 건 AM 또는 프레임워크별 서비스로 이동했다.
이게 핵심이다. JobTracker가 너무 많은 걸 하던 구조를 쪼갠 것.

3.3 Application Master

  • application은

    • 고정된 프로세스 집합일 수도 있고

    • 논리적 작업 설명일 수도 있고

    • 장기 실행 서비스일 수도 있다

  • 그리고 AM도 결국 클러스터 안에서 실행되는 하나의 container다.

동작

  • RM이 먼저 AM을 띄울 container를 확보

  • AM은 RM에 등록(register)

  • 이후 주기적으로 heartbeat를 보내

    • 살아 있음을 알리고

    • 자원 요구를 갱신함

  • heartbeat 응답으로 특정 노드에 묶인 container lease를 받음

  • 받은 자원 상황에 따라 실행 계획을 바꿀 수 있음

    • 자원이 넉넉하면 병렬도 늘리고

    • 부족하면 계획 축소 가능

late binding

네가 여기서 헷갈린 게 당연함. 이건 이렇게 이해하면 된다.

  • 어떤 요청을 보낼 때는 “이 작업 돌릴 자원 좀 주세요”라고 하지만,

  • 실제로 자원을 받을 때는 “이 노드에 2GB/1CPU짜리 container 하나 줄게” 식으로 받음

  • 그 container에 정확히 어떤 task를 올릴지는 AM이 나중에 결정한다

즉,

  • 요청과 실제 실행 작업이 1:1로 고정돼 있지 않고

  • container는 일단 일반적인 자원 lease

  • 그 의미는 프레임워크가 정한다

예를 들어 MapReduce AM은:

  • container를 하나 받으면

  • 아직 안 끝난 map task 중 입력 데이터가 가까운 걸 골라 거기에 붙인다

  • task 실패 시 다시 다른 container에 재배치할 수도 있다

그래서 “container의 의미는 가변적이고 프레임워크별”이라는 네 느낌이 맞다.

중요한 포인트

  • YARN은 container 안에서 무슨 일이 돌아가는지 잘 모른다

  • container exit status의 의미를 해석하는 것도 AM 책임

  • AM이 진짜 “애플리케이션 운영체제” 같은 역할을 한다고 보면 된다

3.4 Node Manager

  • NM은 YARN의 worker 데몬

  • 역할:

    • container lease 진위 인증

    • container 의존성 관리

    • 실행 모니터링

    • container에 로컬 서비스 제공

CLC (Container Launch Context)

YARN의 모든 container는 CLC로 기술된다.
포함 내용:

  • 환경 변수

  • 원격 저장소에 있는 의존성

  • 보안 토큰

  • NM 서비스용 payload

  • 실제 프로세스를 생성하는 명령

즉 “이 container를 어떤 환경으로, 무슨 파일을 받아서, 어떤 명령으로 실행할지”를 담은 실행 명세서다.

container 시작

  • NM은 lease 진위를 확인

  • 자원 제한에 맞게 환경 구성

  • 모니터링 설정

  • 필요한 파일/실행파일/tarball 등을 로컬로 복사

  • 그 다음 실제 프로세스를 띄움

container 종료

NM은 RM이나 AM 지시에 따라 container를 종료할 수 있다.

  • 애플리케이션이 끝났거나

  • 스케줄러가 다른 테넌트를 위해 자원을 회수해야 하거나

  • 자원 한도를 넘겼거나

  • 해당 작업이 더 이상 필요 없을 때

종료 후에는 로컬 작업 디렉터리를 정리한다.
애플리케이션이 끝나면 그 앱의 모든 자원은 클러스터 전체에서 폐기된다.

unhealthy node

  • NM은 노드 상태도 주기적으로 검사

  • 디스크 문제나 관리자 스크립트 결과로 이상이 발견되면

  • 자기 상태를 unhealthy로 바꾸고 RM에 보고

  • 그러면 이후 그 노드에 새 할당을 멈추거나, 실행 중인 것들을 죽일지는 정책에 따라 결정

local / auxiliary services

여기 네가 “아… 씨 뭐래” 한 부분은 이렇게 보면 된다.

  • NM은 단순히 프로세스만 띄우는 게 아니라,

  • 그 노드에서 container들이 공통으로 쓸 만한 로컬 서비스를 제공할 수 있음

  • 예:

    • 로그 수집 서비스

    • MapReduce용 shuffle 보조 서비스

즉 애플리케이션마다 매번 구현하지 않아도 되는 노드 공통 기능을 NM에 플러그인처럼 붙일 수 있다는 뜻이다.

3.5 YARN framework/application writers

프레임워크 작성자 입장에서는 대충 이렇게 하면 된다.

  1. AM용 CLC를 만들어 RM에 애플리케이션 제출

  2. RM이 AM을 시작하면, AM은 RM에 등록하고 heartbeat로 생존/자원 요구를 주기적으로 알림

  3. RM이 container를 할당하면, AM은 해당 NM에서 실행할 CLC를 구성

  4. 필요하면 실행 중 container 상태를 모니터링하고, 더 이상 필요 없으면 종료

  5. 작업이 끝나면 AM은 RM 등록 해제 후 종료

  6. 필요하면 자기 클라이언트/제어평면을 따로 만들어 작업 상태를 보고할 수 있음

중요:

  • container 내부 작업 진행률을 모니터링하는 책임은 오직 AM에 있다

  • YARN은 그 내부 의미를 모른다

3.6 Fault tolerance and availability

RM

  • 논문 시점에서 RM은 여전히 단일 장애 지점(SPOF) 이다.

  • RM은 영속 저장소에서 상태를 복구할 수 있음

  • 하지만 복구 후에는 클러스터 안의 모든 container, 살아 있는 AM까지 포함해 다 죽이고

  • 새 AM 인스턴스를 다시 띄운다

즉:

  • “RM이 죽어도 아무 일도 없었다” 수준은 아니고

  • “상태를 일부 복구해서 다시 시작은 가능” 정도다

그리고 논문은

  • AM이 RM 재시작을 survive하도록 하는 프로토콜을 작업 중

  • standby RM으로 passive/active failover를 작업 중
    이라고 말한다.
    즉 이 시점에는 완성 아님, 진행 중이다.

NM 실패

  • RM이 heartbeat timeout으로 감지

  • 그 노드의 container를 전부 죽은 것으로 표시

  • 해당 AM들에게 알림

  • 이후 어떻게 복구할지는 AM 책임

AM 실패

  • AM도 클러스터 안에서 도는 프로세스라 실패할 수 있음

  • 하지만 클러스터 전체 가용성을 망치진 않음

  • RM이 AM을 재시작할 수는 있음

  • 다만 AM 상태 복구는 플랫폼이 자동으로 다 해주지 않는다

  • 재시작된 AM이 기존 실행 상태와 어떻게 다시 맞출지는 프레임워크 책임이 큼

container 실패

  • container 실패 처리는 전적으로 프레임워크에 맡겨짐

  • RM은 종료 이벤트를 모아 해당 AM에 전달

  • 예를 들어 MapReduce AM은 이 알림을 받고 map/reduce task를 재시도함

4. YARN in real world

4.1 야후!

이 부분은 “YARN이 실제로 쓸 만했냐?”를 보여주는 운영 사례다.

  • Yahoo는 생산 클러스터를 classic Hadoop에서 YARN으로 업그레이드

  • 전체적으로 하루 약 500,000 jobs

  • 저장 용량은 350PB 이상

  • 하루 총 계산량은 230 compute-years/day 이상 수준이라고 보고함

2500노드 클러스터 예시에서는:

  • Hadoop 1.0에서 하루 약 77k jobs

  • YARN에서는 보통 100k jobs

  • 지속적으로 125k jobs/day

  • 피크는 150k jobs/day까지 처리 가능했다고 보고

또 작업 수뿐 아니라 task 수도 크게 증가:

  • 4M → 평균 10M 수준

  • 지속적으로 12M

  • 피크 15M 정도

그리고 CPU 활용률도 크게 올랐다고 한다.

  • 이전엔 머신당 대략 3.2개 코어 정도 계속 바쁘던 수준

  • YARN 이후엔 약 6개 코어, 피크는 10코어까지 활용

  • 운영팀 표현으로는
    “2500대 클러스터에 1000대 추가한 것과 비슷한 효과” 였다고 함

하지만 병목도 있음

  • YARN 로그 집계(log aggregation)가 HDFS NameNode에 부담을 주어서

  • 큰 클러스터에서는 NameNode가 병목처럼 보이기도 했음

  • 또 아주 많은 small application이 몰리면 heartbeat 처리 등 스케일 이슈도 있었지만 개선 중이었다고 함

4.2 Applications and framework

YARN 위에 올라간 대표 프레임워크들:

  • Apache Hadoop MapReduce

  • Apache Tez

  • Spark

  • Dryad

  • Giraph

  • Storm

  • REEF

  • Hoya

각각 대충 이렇게 보면 됨.

  • MapReduce
    기존 Hadoop 1.x 앱과 높은 호환성을 유지하면서 YARN 위로 올라옴

  • Tez
    MapReduce보다 더 일반적인 DAG 실행 프레임워크

  • Spark
    반복 계산, 인터랙티브 쿼리, ML에 강한 모델

  • Dryad
    DAG 기반 실행 모델

  • Giraph
    그래프 계산 프레임워크

  • Storm
    실시간 스트림 처리

  • REEF
    YARN 위 프레임워크를 만들기 쉽게 해주는 meta-framework

  • Hoya
    YARN 위에서 동적으로 HBase 클러스터를 띄우는 도구

즉 YARN은 “프레임워크를 위한 플랫폼” 역할을 한다.

5. Experiments

5.1 Sort Record

  • YARN 위 MapReduce 구현은 당시 GraySort 기록을 보유

  • 1.42TB/min 정렬

  • 대회 외부 실험에서는 1.61TB/min, 1.50TB/min MinuteSort 결과도 냄

  • 실험 환경:

    • 노드 2100개

    • 2개의 2.3GHz 6코어 Xeon E5-2630

    • 64GB 메모리

    • 3TB 디스크 12개

이건 “YARN이 느슨한 구조라 성능 떨어지는 거 아냐?”에 대한 반례 같은 섹션이다.

5.2 MapReduce Benchmark

260노드 클러스터에서 Hadoop 1.2.1 vs YARN(2.1.0)을 비교.

대략 요약하면:

  • RandomWriter: 거의 비슷하거나 약간 불리

  • Sort: YARN이 더 빠름

  • Shuffle: YARN이 더 빠름

  • AM Scalability: YARN이 크게 더 좋음

  • Terasort: 오히려 약간 느림

  • Scan / DFSIO: 파일시스템 측면에서는 약간 뒤처지는 구간도 있음

논문 해석 포인트:

  • Sort / Shuffle 성능 향상은 주로

    • MapReduce runtime 개선

    • map-side sort 개선

    • reduce client의 pipeline/batching

    • Netty 기반 server-side shuffle
      덕분이라고 설명함

  • HDFS benchmark 쪽은 YARN이 압도적 우위라기보다 비슷하거나 일부 약간 불리한 구간도 있음

  • 대신 전체적으로는 확장성과 클러스터 활용률에서 큰 이점이 있었다고 본다

그리고 단일 작업 성능뿐 아니라, 큰 차이는 heartbeat 주기와 중앙 병목 완화에서도 나왔다.

  • Hadoop 1.x에선 큰 클러스터에서 heartbeat가 30~40초 간격까지 벌어질 수 있었음

  • YARN에선 NodeManager heartbeat가 1~3초

  • 그래서 스케줄링 반응성이 좋아짐

5.3 Preemption

  • work-preserving preemption

  • CapacityScheduler에서

    • A 큐: 80%

    • B 큐: 20%
      보장

실험:

  1. 각 큐가 보장치 이상 절대 못 씀

  2. 100%까지 써도 되지만 preemption 없음

  3. 100%까지 써도 되고 preemption 있음

결과:

  • preemption이 있으면 B가 자원을 넉넉히 쓰고 있어도

  • A가 자원을 요구할 때 scheduler가 preemption 요청

  • AM이 checkpoint 후 container를 반납

  • 그러면 A가 몇 초 안에 자기 보장치(80%)를 회복 가능

  • preemption이 없으면 이 재균형에 약 20분 걸림

중요한 건 “kill해서 날리는 preemption”이 아니라,

  • 체크포인트 후 반납

  • 그래서 기존 작업도 최대한 보존한다는 점.

5.4 Improvements with Apache Tez

  • TPC-DS Query 12를 Hive+MapReduce와 Hive+Tez로 비교

  • Hive를 MapReduce로 실행하면 여러 job으로 나뉨

  • Tez에서는 하나의 더 자연스러운 DAG로 표현 가능

    • 단일 Map 이후 여러 Reduce 단계가 연결된 구조

  • 20노드 클러스터, scale factor 200에서:

    • MapReduce: 54초

    • Tez: 31초

왜 빨라졌나?

  • 여러 MapReduce job을 따로따로 스케줄링/런치하는 오버헤드 감소

  • 중간 결과를 매번 HDFS에 굳이 써두지 않아도 되는 경우가 생김

즉 YARN의 장점은 “MR이 빨라졌다”뿐 아니라,

  • MR 말고 더 알맞은 실행 모델을 올릴 수 있게 해줬다는 데 있다.

5.5 REEF

  • YARN의 장점 중 하나는 그 위 프레임워크가
    container 재사용 방식이나 통신 방식을 자유롭게 설계할 수 있다는 것

  • REEF는

    • container reuse

    • push-based communication
      을 제공함

  • 실험에서는 첫 명령은 container 확보 비용이 커서 느리지만,

  • 이후 명령은 이미 떠 있는 container에 바로 전달 가능

  • 평균 지연이 12초 이상 → 31ms 수준으로 감소

Discussion