YARN (Yet Another Resource Negotiator)

핵심 인사이트 (3줄 요약)

본질: 하둡 1.0의 단일 맵리듀스(MapReduce) 전용 엔진 한계를 타파하기 위해 등장한 하둡 2.0의 심장으로, 클러스터 전체의 자원(CPU, 메모리) 할당 기능과 애플리케이션 실행/모니터링 기능을 완전히 분리한 분산 운영체제급 리소스 스케줄러입니다.

가치: 하나의 거대한 데이터 클러스터 위에서 맵리듀스뿐만 아니라 아파치 스파크(Spark), 플링크(Flink), 실시간 스트리밍 등 다양한 연산 엔진들이 서로 자원을 뺏기지 않고 평화롭게 공존하며 동시에 구동할 수 있는 멀티테넌트(Multi-tenant) 환경을 구축했습니다.

융합: 컨테이너(Container) 기반의 격리 사상을 채택하여 현대의 쿠버네티스(Kubernetes) 오케스트레이션과 기술적 철학을 공유하며, 데이터 지역성(Data Locality)을 고려한 정교한 자원 분배 정책의 코어 엔진 역할을 수행합니다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

과거 하둡 1.0 시대, 하둡은 오직 '맵리듀스(MapReduce)'라는 단일 배치 작업만을 위해 돌아가는 폐쇄적인 시스템(JobTracker 기반)이었습니다. 이 구조의 치명적 한계는 중앙의 JobTracker가 4,000대 노드의 자원 상태도 확인하고, 각 작업이 잘 도는지 모니터링도 하며, 장애 복구까지 혼자 다 처리해야 한다는 점이었습니다. 결과적으로 클러스터가 커지면 중앙의 JobTracker가 과부하로 폭발(병목)해버려 스케일 아웃이 불가능해졌고, 무엇보다 스파크나 그래프 분석 같은 새로운 연산 엔진을 올릴 수가 없었습니다.

이 병목을 해소하고 하둡을 진정한 '데이터 센터의 분산 운영체제'로 탈바꿈시킨 혁명이 바로 **YARN(Yet Another Resource Negotiator)**의 등장입니다. 야후(Yahoo!) 주도로 개발된 YARN은 극단적인 역할 분리 철학을 가져왔습니다. "중앙 관제탑은 오직 전체 자원(RAM/CPU) 분배만 신경 쓰고(ResourceManager), 개별 애플리케이션의 실행과 장애 감시는 각 작업을 대표하는 현장 소장(ApplicationMaster)을 노드에 띄워서 위임하자!"

이 아키텍처 혁신 덕분에 하둡 클러스터는 특정 프레임워크에 종속되지 않는 범용 자원 플랫폼이 되었습니다. 오늘날 데이터 엔지니어들이 동일한 하둡 장비 위에서 낮에는 실시간 스트림(Spark Streaming)을 띄우고, 밤에는 무거운 배치(MapReduce/Hive)를 돌려 인프라 활용률을 100%로 쥐어짤 수 있게 된 것은 순전히 YARN 덕분입니다.

이 도식은 하둡 1.0의 병목 구조가 YARN의 위임형 아키텍처로 진화하며 얻은 확장의 자유를 시각화한 것입니다.

[과거: 하둡 1.0 (JobTracker 중앙 독재 병목)]
                ┌─> Task (Map)
 [JobTracker] ──┼─> Task (Reduce)   ==> 수만 개의 태스크를 혼자 감시하다가
 (자원+스케줄링)  └─> Task (Map)         메모리 터지고 병목 발생! 💥

[혁신: 하둡 2.0 YARN (권한 위임 분산 구조)]
 [ResourceManager] (중앙: 난 전체 CPU/RAM 양만 관리할게. 태스크 감시는 안해!)
         │
         ├──(자원 협상)──> [ApplicationMaster A (스파크 전담 현장 소장)] ---> Worker 제어
         └──(자원 협상)──> [ApplicationMaster B (Hive 전담 현장 소장)]  ---> Worker 제어

이 흐름의 핵심은 '권한의 하방 위임'입니다. 수만 개의 태스크 상태 추적이라는 엄청난 오버헤드를 중앙 마스터에서 떼어내어, 클러스터의 임의 노드에 동적으로 뜨는 ApplicationMaster들에게 떠넘겼습니다. 따라서 YARN 클러스터는 노드가 10,000대를 넘어가도 중앙 마스터가 터지지 않는 진정한 무한 확장의 지위를 얻어냈습니다. 실무에서는 이 구조 변화 덕분에 OOM(Out of Memory)으로 클러스터 전체가 뻗는 대재앙이 사라졌습니다.

📢 섹션 요약 비유: 회장님(JobTracker)이 전 직원의 책상 배정과 개별 업무 실적까지 혼자 감시하다가 과로사하는 회사에서, 회장님(ResourceManager)은 각 부서에 예산만 던져주고 실제 팀원 관리와 프로젝트 책임은 각 팀장(ApplicationMaster)이 현장에서 전담하는 체계적 대기업으로 승격한 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

YARN은 철저하게 마스터-슬레이브(Master-Slave) 구조 위에서 동적인 '컨테이너(Container)' 단위로 자원을 격리하고 할당합니다.

구성 요소	역할	내부 동작	프로토콜	비유
ResourceManager (RM)	글로벌 자원 스케줄링 (Master)	클러스터 전체의 가용 CPU/RAM을 파악하고 페어(Fair), 캐파시티(Capacity) 큐에 따라 자원을 분배합니다.	RPC / Scheduler	중앙 예산 부처
NodeManager (NM)	로컬 노드 자원 관리 (Worker)	각 서버 1대마다 떠서, 실제 컨테이너를 띄우고 메모리/CPU 사용량을 감시하며 RM에게 보고합니다.	Hearbeat 통신	각 건물 관리인
ApplicationMaster (AM)	앱 생명주기 관리 (App 단위)	작업이 제출되면 1개씩 생성되며, RM에게 필요한 컨테이너(자원)를 구걸(협상)하고 장애 복구를 책임집니다.	RPC Negotiation	프로젝트 외주 팀장
Container	논리적 자원 격리 단위	'RAM 2GB, CPU 1코어' 형태로 격리된 실행 공간. 이 안에서 Spark Executor나 Map 태스크가 돕니다.	cgroups / JVM	임대 사무실

이 다이어그램은 사용자가 스파크(Spark) 잡을 YARN에 제출했을 때 벌어지는 아키텍처 내부의 5단계 동적 자원 할당 시퀀스를 보여줍니다.

┌──────────────── YARN Application Execution Flow ────────────────┐
│                                                                 │
│ [Client] ──1. Job 제출 (Spark 앱)──> [ResourceManager]              │
│                                       (전체 큐/자원 확인)             │
│                                            │                    │
│                    2. 첫 컨테이너 띄워라 명령 │                    │
│                                            ▼                    │
│ [NodeManager 1] <────────────────── [ApplicationMaster 생성]       │
│                                            │ (스파크 잡의 대장)      │
│     ▲                   3. 나 컨테이너 100개 필요해! 자원 협상 요청 │
│     │                           (Resource Negotiation)          │
│     │ 5. Task 실행 명령                        ▼                    │
│ [NodeManager 2~N] <──4. 컨테이너 할당 티켓 발급── [ResourceManager] │
│      │                                                          │
│  [Container] ─ (그 안에서 Spark Executor가 메모리를 잡고 연산 시작)  │
└─────────────────────────────────────────────────────────────────┘

이 도식에서 가장 놀라운 점은 ApplicationMaster(AM)의 존재 방식입니다. AM은 고정된 마스터 서버에 뜨지 않고, 워커 노드(NodeManager) 중 자원이 남는 아무 곳의 첫 번째 컨테이너 안에서 동적으로 스폰(Spawn)됩니다. 만약 AM이 띄워진 노드의 하드웨어가 죽어버리면, RM은 이를 감지하고 다른 노드에 새 AM을 띄워 처음부터 다시 복구시킵니다. 따라서 이 배치는 특정 마스터 노드의 SPOF(단일 장애점) 한계를 극복하고, 클러스터 자원을 극도로 탄력적으로 유동화하는 결과를 낳습니다.

심층 동작 원리

스케줄러 큐 (Queues): RM 내부에는 트리 구조의 큐(예: root.marketing, root.data_science)가 존재하며, 부서별로 가용할 수 있는 최대 RAM/CPU 파이가 엄격히 통제됩니다.
자원 협상 (Negotiation): AM은 RM에게 "데이터가 있는 IP 192.168.1.10에 4GB짜리 컨테이너를 달라(데이터 지역성 요구)"고 구체적으로 요청합니다.
지연 스케줄링 (Delay Scheduling): RM은 해당 노드에 4GB가 당장 없으면 즉시 다른 노드를 주지 않고, 지역성을 살리기 위해 수 초간 기다려주는 유연성을 발휘합니다.
선점 (Preemption): 특정 부서가 자원을 초과 점유하고 있고 급한 VIP 큐가 굶고 있다면, 스케줄러는 실행 중인 남의 컨테이너를 강제로 죽여(Kill) 자원을 뺏어버립니다.

📢 섹션 요약 비유: 거대한 뷔페 식당(클러스터)에서 매니저(RM)는 테이블(자원) 빈자리만 안내해 주고 맙니다. 각 테이블에 앉은 손님 대표(AM)가 알아서 자기 일행들에게 고기를 가져다 먹일지 스파게티를 먹일지(태스크 실행) 지휘하며 질서를 유지하는 자동화 시스템입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

현대 데이터 엔지니어링 생태계에서 YARN의 라이벌이자 진화 방향인 컨테이너 오케스트레이션 도구 **쿠버네티스(Kubernetes, K8s)**와의 아키텍처 비교는 가장 중요한 아키텍처 의사결정 지점입니다.

항목	YARN (Hadoop Ecosystem)	Kubernetes (Cloud Native)	실무 판단 포인트
설계 목적	대규모 데이터 프로세싱(Batch/Data) 전용	마이크로서비스(MSA) 및 무상태 웹 서비스 범용	워크로드의 근본적 성격
격리 기술	JVM 프로세스 위주, cgroups (비교적 약한 격리)	Docker 컨테이너, Namespaces (강력한 OS 레벨 격리)	환경/라이브러리 종속성 충돌 여부
데이터 지역성	HDFS와 완벽히 통합되어 최우선 보장 연산	데이터 위치 개념 약함 (CSI 등 외부 연결 의존)	대용량 I/O 속도 방어의 필수성
장기 실행(Long-running)	비교적 취약, 배치 잡 중심 스케줄링	자가 치유(ReplicaSet) 기반 365일 서비스에 최적	웹 API 서버 vs 데이터 잡

이 비교 매트릭스는 온프레미스의 데이터 왕자(YARN)와 클라우드의 제왕(K8s) 간의 워크로드 차이를 보여주는 대조 매트릭스입니다.

┌── 자원 스케줄링 패러다임 차이 ──┐

[YARN 강점: Batch Data Processing]
"이 스파크 잡은 데이터가 노드 A에 있으니 무조건 노드 A 근처에 띄워!"
=> I/O 속도 극대화에 목숨 욺 (Data Locality 사수)

[Kubernetes 강점: Microservices]
"웹 서버 파드 3개가 죽었네? 클러스터 안 아무 노드에나 빨리 띄워 복구해!"
=> 무중단 서비스와 빠른 복원력에 목숨 욺 (빠른 재배치 사수)
└────────────────────────────┘

A 방식(YARN)은 철저히 '하둡 HDFS'라는 스토리지 구조와 피가 섞여 있어, 데이터가 있는 곳으로 연산을 밀어 넣는 데 미친 성능을 보여줍니다. 반면 B 방식(K8s)은 개발자가 파이썬, 고(Go), 노드(Node) 등 어떤 언어로 짠 환경이든 도커 이미지로 말아 올리기만 하면 라이브러리 충돌 없이 깔끔하게 격리해 돌려주는 이식성이 뛰어납니다. 실무에서는 스파크(Spark) 잡을 돌릴 때 레거시 하둡 클러스터가 있다면 YARN을 쓰고, 클라우드 네이티브로 신규 구축한다면 데이터 지역성 손실을 캐시로 메꾸면서 Spark on K8s 아키텍처로 넘어가고 있는 거대한 과도기적 융합 국면에 있습니다.

📢 섹션 요약 비유: YARN이 중장비를 동원해 거대한 광산(데이터)을 순식간에 캐고 철수하는 데 특화된 야전 공병대라면, 쿠버네티스는 다양한 상점(마이크로서비스)들이 폐업해도 즉시 새 상점을 열어 1년 내내 불이 꺼지지 않게 관리하는 거대한 쇼핑몰 관리단과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

현장의 데이터 엔지니어에게 YARN 튜닝은 "큐(Queue) 설계와 메모리 OOM 방어"라는 두 가지 전쟁으로 요약됩니다.

실무 의사결정 및 자원 설계 시나리오

부서 간 자원 경합 (Multi-tenant) 문제
- 현상: 마케팅 팀이 제출한 엄청난 스파크 배치 잡이 클러스터의 CPU 100%를 독식하여, 데이터 사이언티스트들의 주피터 노트북 쿼리가 3시간째 대기(Pending) 상태에 빠집니다.
- 판단: YARN의 Capacity Scheduler를 도입하여 큐를 찢습니다. 마케팅 큐(Max 70%), 사이언스 큐(Min 30%)로 보장(Guarantee) 자원을 설정하고, 선점(Preemption) 기능을 켜서 마케팅이 선넘게 자원을 먹고 있으면 YARN이 마케팅 컨테이너를 Kill하여 사이언스 팀에게 자원을 강제 반환하도록 설계합니다.
스파크 Executor OOM (메모리 초과 사망) 방어
- 상황: YARN이 스파크 워커에게 4GB 컨테이너를 줬는데, 스파크 잡이 내부적으로 파이썬(PySpark) 프로세스를 띄우며 오프힙(Off-heap) 메모리를 과다 사용해 4.5GB를 씁니다.
- 판단: YARN NodeManager는 즉시 "물리 메모리 제한 초과(Physical memory limits exceeded)" 에러를 뱉으며 컨테이너를 무자비하게 암살(Kill)합니다. 엔지니어는 spark.yarn.executor.memoryOverhead 파라미터를 넉넉히(기본 10% -> 20%) 튜닝하여 YARN에게 처음부터 더 큰 컨테이너를 요구하도록 타협안을 마련해야 합니다.

안티패턴 (치명적 결함 사례)

단일 Default 큐 방치: 클러스터를 구축하고 수백 명이 쓰는데 YARN 큐를 하나(default)로만 두면, 나쁜 쿼리 하나를 던진 주니어 개발자가 전사의 빅데이터 인프라를 다운시킬 수 있습니다. 반드시 용도/부서별로 자원을 격리(Quotas)해야 합니다.

이 흐름도는 실무에서 클러스터 자원 고갈 시 스케줄러가 개입하는 선점(Preemption) 정책 플로우를 보여줍니다.

[상황: VIP 부서(A큐)가 급하게 스파크 잡 제출] -> 클러스터 자원 0% 남음
       │
       ├─ RM 스케줄러: "A큐의 최소 보장 자원이 지켜지지 않고 있다!" 판단
       │
       ├─ (희생양 탐색) 현재 할당량을 초과해서 막 쓰고 있는 B부서 컨테이너 색출
       │
       ├─ (경고 1차) B부서의 ApplicationMaster에게 "15초 안에 자원 반납해" 시그널 전송
       │
       └─ (강제 킬) 안 뱉으면 NodeManager에게 OS kill(-9) 명령 하달 -> 자원 회수
                 │
                 └──> 회수한 자원을 VIP A큐에 즉시 할당하여 서비스 지연 방지

이 흐름의 핵심은 제한된 자원 하에서 '공평함(Fairness)'을 수리적으로 강제한다는 점입니다. 이 선점 기능이 없으면 무거운 배치 잡 하나가 끝날 때까지 전체 클러스터가 먹통이 되는 데드락(Deadlock)에 빠집니다. 따라서 실무 관리자는 큐의 깊이(Depth)와 우선순위 가중치를 어떻게 세팅하느냐에 따라 클러스터의 투자 대비 효용(ROI)을 2배 이상 끌어올릴 수 있습니다.

📢 섹션 요약 비유: 왕복 2차선 도로(자원)에서 평소에는 화물차(마케팅 배치)가 2차선을 다 막고 달려도 놔두지만, 구급차(VIP 사이언스 쿼리)가 등장하면 사이렌(Preemption)을 울려 화물차를 갓길로 쫓아내고 길을 터주는 스마트 교통 통제 시스템입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

YARN의 도입은 하둡을 단순한 데이터 저장고에서 거대한 분산 애플리케이션 플랫폼(Data Operating System)으로 격상시킨 위대한 아키텍처 리팩토링입니다.

정성적 효과	정량적 지표 및 변화
클러스터 활용률 극대화	주야간 워크로드 혼합 배치로 서버 유휴 시간 제로화 (ROI 2배 상승)
다양한 연산 엔진 생태계 폭발	Spark, Tez, Flink, Storm 등이 단일 HDFS 위에서 동시 공존 실행 가능
무한한 스케일 아웃 확보	JobTracker의 단일 병목 소멸로 노드 한계가 4,000대에서 10,000대 이상으로 돌파

미래의 자원 관리 표준은 점차 YARN에서 쿠버네티스(Kubernetes)로 헤게모니가 넘어가고 있습니다. 더 가볍고, 클라우드 네이티브하며, 딥러닝(GPU) 자원 격리까지 완벽하게 지원하기 때문입니다. 하지만 YARN이 정립한 '자원 할당과 애플리케이션 수명주기 관리의 분리', '계층적 큐(Queue)를 통한 부서별 자원 보장'이라는 철학은 분산 컴퓨팅의 바이블로 남아 모든 현대적 스케줄러의 뼛속에 스며들어 있습니다. YARN의 스케줄링 메커니즘을 튜닝해 본 경험은 클라우드 시대 비용 최적화(FinOps) 엔지니어링의 가장 든든한 밑거름이 될 것입니다.

📢 섹션 요약 비유: YARN은 무질서하게 난개발되던 데이터의 도시에 훌륭한 신도시 구획(격리)을 짜고 도로망(자원 분배)을 깔아, 수십 개의 다국적 기업(스파크, 하이브)이 한 도시 안에서 싸우지 않고 평화롭게 장사할 수 있게 만든 위대한 도시 계획가입니다.

📌 관련 개념 맵 (Knowledge Graph)

ApplicationMaster (각 스파크 잡마다 1개씩 떠서 현장에서 컨테이너를 구걸하고 태스크를 책임지는 핵심 위임자)
Apache Spark (YARN이라는 자원 풀 위에서 동작함으로써 하둡 생태계의 디스크 I/O를 대체하며 왕좌에 오른 인메모리 엔진)
Capacity Scheduler / Fair Scheduler (YARN이 다수 사용자의 쿼리를 교통 정리하고 자원을 쪼개주는 트리 구조의 큐 스케줄링 알고리즘)
Preemption (선점, 자원이 부족할 때 스케줄러가 남의 컨테이너를 강제로 죽여 우선순위가 높은 큐에 바치는 생존 메커니즘)
Kubernetes (컨테이너 오케스트레이션의 클라우드 대세로, YARN의 빅데이터 자원 관리 왕좌를 위협하는 현대적 아키텍처)

👶 어린이를 위한 3줄 비유 설명

학교 운동장에 장난감 수만 개(자원)가 있는데, 예전엔 교장 선생님 혼자서 1,000명의 아이들에게 일일이 장난감을 나눠주다 쓰러졌어요!
그래서 새로 온 똑똑한 선생님(YARN)은 각 반 반장(ApplicationMaster)들에게 "너희 반에 필요한 장난감 개수만 나한테 말해!"라고 규칙을 바꿨어요.
그러면 선생님은 전체 수량만 확인하고 반장에게 박스째로 넘겨주고, 진짜로 누가 무슨 장난감을 갖고 놀지(작업 실행)는 반장이 알아서 관리하니까 학교가 엄청나게 평화롭고 빠르게 돌아가게 된 거랍니다!