YARN이란? (하둡분산자원관리)

하둡(Hadoop) 프로젝트의 YARN(Yet Another Resource Negotiaor) 모듈은 분산 환경에서의 자원관리를 담당합니다.

 

이 글에서는 YARN과 관련해 다음과 같은 항목을 다룹니다:

 

• 목적과 탄생배경 (이번글)
• YARN (하둡분산자원관리) 주요개념 및 아키텍쳐
• YARN(하둡분산자원관리) 실행 구조 및 흐름
• YARN 리소스매니저(Resource Manager)
• YARN 노드매니저(Node Manager)
• 운영과 관련한 사항들

 

관련글:

• 하둡이란? (Apache Hadoop)
• HDFS란? (하둡분산파일시스템)

---

 

YARN은 2006년 야후의 이 하둡을 오픈소스로 출시한지 6년 후인, 2012년에 하둡 모듈로 정식 포함되었습니다. 6년여 기간 동안 YARN 없이도 맵리듀스와 HDFS를 사용했다는 것인데요. YARN이 하둡 모듈로 포함되며 맵리듀스의 JobTracker 역할을 대체하였습니다. 

 

이러한 YARN은 수백, 수천개의 노드로 구성된 클러스터에서 작업이 제출되면 수많은 작업들을 관리하고, 특정 작업에 사용할 자원(CPU, RAM)을 관리해주는 분산자원관리 기능을 담당합니다. 이 글에서는 YARN이 어떤 것이며 왜 탄생했는지 알아보며 요구사항별로 좀 더 상세히 알아보고자 합니다.

 

Hadoop 2.0 YARN Architecture - Image from Author inspired by [2]

하둡 맵리듀스의 JobTracker의 한계성에 대한 부분은 2006년 야후에 하둡이 도입되던 시기부터 거론되었습니다. 또한, YARN 탄생 이전의 하둡 환경에서 다양한 사용자와 사용 패턴이 증가하면서 맵리듀스의 JobTracker에 기반한 도구로는 대응이 불가능한 요구사항들이 나타났습니다. 

 

오랜 기간에 걸쳐 하둡 환경에 발생한 다양한 요구사항이 YARN 설계의 고려사항이 되며 기능으로 포함되게 되었습니다. 아래에서는 시기순으로 어떠한 요구사항들이 발생하여 YARN의 설계 목적이 되고, 그 자세한 배경은 무엇인지 살펴보겠습니다.

 

요구사항1 - 확장성

야후에서 2006년 하둡을 도입한 주요 목적은 WebMap이라는 애플리케이션을 대체하기 위함이었습니다. 검색엔진의 기반으로 알려진 웹의 그래프를 만드는 이 애플리케이션은 당시 1000억개 이상의 노드와 1조개 이상의 엣지를 가지고 있었습니다. 이전의 인프라인 "Dreadnaught"라는 도구는 800개의 머신에서 돌아가며 그 확장성의 최대한을 사용하고 있어서 더 확장성있는 도구로의 이전이 시급했습니다. 해당 도구도 맵리듀스와 비슷한 구조의 연산을 수행하고 있었기에 하둡으로 이전이 가능하였고, 웹의 증가 속도를 고려할 때 수만개 이상의 노드까지도 확장 가능한 하둡을 선택하게 되었습니다. 

 

하둡에 대한 야후의 첫 투자는 위의 검색엔진 인프라로 시작되었으나, 리서치 팀, 데이터 사이언티스트들 등의 다양한 부서의 니즈가 몰려들면서 다양한 요구사항과 하둡 진화 방향성에 영향을 미쳤습니다.

 

요구사항2 - Serviceability

Ad hoc cluster 형태로 발전하기 이전의 하둡 초기 사용자들은 하둡을 마치 데스크톱 애플리케이션과 유사하게 사용하였습니다. 몇 개의 노드를 띄워 클러스터를 구성하고 데이터를 HDFS에 밀어 넣고 맵리듀스 작업을 실행하여 원하는 결과를 얻고는 클러스터를 삭제하였습니다.

 

하지만 HDFS를 통해 연구 목적의 데이터가 공유되고 다양한 목적으로 데이터가 공유되면서 HDFS는 점점 공유된(shared) 영속적인(persistent) 저장소가 되었습니다. 이러한 storage 사용 패턴의 변화는 컴퓨팅에 대한 공유사용 요구를 지속적으로 발생시켰습니다만 아쉽게도 다수의 사용자를 위해 맵리듀스 클러스터를 공유하는 것은 어려운 일이었습니다. 야후에서는 이러한 요구사항에 대처하기 위해 HOD(Hadoop on Demand)를 개발하였습니다.

 

HOD를 살펴보고 그 한계점을 돌아보면, YARN의 기원이 되는 분산자원관리 도구의 모습이 어떤 형태로 발전해왔는지 잘 알 수 있습니다. 

 

HOD는 위의 공유 클러스터를 다수 사용자 작업에 자원을 분산하는 문제를 풀기 위해 전통적인 리소스 매니저인 Torque와 클러스터 스케쥴러인 Maui를 사용하였습니다. 전통적인 리소스 매니저는 high performance 컴퓨팅 환경에서 pooled 클러스터 자원 공유를 위해 많이 사용되어 있었기에, HOD는 그러한 구현을 하둡 외부의 도구에 완전히 아웃소싱할 수 있었습니다.

 

HOD 세션의 주요 3단계는 1) 클러스터에 자원 할당, 2) 할당된 클러스터에서 하둡 작업 실행, 3) 클러스터 할당 제거로 이뤄집니다. HOD를 통해 HDFS 클러스터도 배포할 수 있으나, 주로 HDFS는 static하게 설치하고 persistent하게 유지하며 transient한 작업들이 해당 HDFS에서 데이터를 읽어서 처리하고 저장하고 사라지는 형태로 많이 사용되었습니다.

 

매 작업요청에 새로운 클러스터를 만들어 할당했기 때문에, 사용자는 다양한 하둡 버젼의 소프트웨어를 실행할 수 있었습니다. 당시 하둡 커뮤니티는 3달에 1번 major revision이 발생하여서 이러한 HOD의 flexibility는 매우 중요한 요소였습니다. 그리고 이러한 부분(decoupled from users’ applications)은 YARN에도 그대로 반영되었습니다.

 

다양한 애플리케이션이 실행되지만, 공통적으로 요구되는 분산환경에서의 로깅 관리와 같은 경우는 HOD에서 처리되었습니다.

 

요구사항3 - Multitenancy

리소스가 존재하고 정책을 위반하지 않는 한, 사용자는 HOD를 통해 다수의 맵리듀스 클러스터를 동시에 생성할 수 있었습니다. 한 유저에 의해 생성된 모든 클러스터와 각 클러스터의 정보 등이 제공되었습니다 (Torque Job ID, HOD RingMaster process 위치, Hadoop JobTracker 및 네임노드 데몬 RPC 주소 등). 

 

HOD의 리소스 관리 레이어에서는 사용자가 클러스터 자원을 abusing하는 것을 제한하는 방법이 존재하였으나 허점이 많았고, 외부 scripts 등을 통해 보조하였습니다. 이 부분에서, HOD의 주요 제약 중 하나는 클러스터의 각 노드는 오로지 하나의 사용자에게만 사용될 수 있는 부분이었습니다 (이러한 부분이 아래 Secure 부분에서의 HOD의 장점이기도 하였습니다).

 

HOD의 유용한 장점은 추후 다른 자원관리 도구에도 계승되었습니다. 어떤 사용자가 클러스터 자원을 어느 정도 사용했는지 기록하는 history는 사이즈가 점점 커져감에 따라서 독립된 프로세스(JobHistoryServer)로 처리하고, 하나의 작업이 노드의 모든 리소스를 과도하게 사용해 해당 노드의 다른 프로세스(예로, 데이터노드)를 다운시키는 것을 막기 위한 리소스 제한 부분이 그러한 요소들이었습니다. 

 

요구사항4 - Locality Awareness

또 다른 HOD의 결점 중 하나는 데이터 Locality를 인식하지 못하는 부분이었습니다. 맵리듀스 작업의 경우 JobTracker가 맵 작업 노드를 데이터를 가진 HDFS 데이터노드와 가깝게 할당하기 위해 온갖 노력을 하는 반면 HOD 내부의 Torque는 HDFS에 블록이 어떻게 나누어져 저장되어 있는지 알지 못합니다. 그렇기에 Torque를 통해 할당받은 노드에서 JobTracker가 최적화해도 data locality는 매우 낮았습니다. 

 

HOD에서 이 부분을 개선하기 위해 Torque/Maui를 변경하여 TaskTracker들을 rack들에 고르게 분배하도록 했지만, 이는 맵-리듀스 중 데이터 transfer 성능에 악영향을 미치는 단점이 있었습니다. 그렇기에 Locality Aware는 YARN의 중요한 요구사항이 되었습니다.

 

요구사항5 - High Cluster Utilization

맵리듀스는 맵 - 셔플 - 리듀스의 여러 단계로 구성됩니다. HOD 사용 시, 클러스터의 크기는 job이 실행되는 동안 조정할 수 없었고 그렇기에 하나의 리듀스 task로 인해 수백개 노드의 리소스가 사용이 안되고 있는 상황이 발생하기도 하였습니다. 게다가 사용자가 맵리듀스 클러스터를 모두 사용하고 다시 해당 리소스가 가용해지기까지 오랜 시간이 걸리기도 하였습니다. 

 

HOD의 여러 부분은 사용자에게 큰 도움이 되었지만, 클러스터 사용률과 같은 부분은 더욱 개선할 수 있는 여지가 많이 존재하였습니다.

 

이러한 부분은 작업 중에 자원 할당을 변경할 수 있는 부분 이외에도, 작업 간의 자원 비율 조정, 작업 큐 간의 자원 비율 제한 및 조정과도 연관되어 추후 YARN의 중요한 기능들로 발전하였습니다. HOD가 사용하던 스케쥴러를 대신하여 좀 더 세련된 스케쥴링 알고리즘을 도입하였습니다(Capacity Scheduler와 Fair Scheduler 그리고 추가적인 연구들 [3]). 

 

요구사항6 - Secure and Auditable Operation

Multitenancy가 지원되어 한 클러스터를 다양한 작업과 사용자가 사용하고, 한 노드에도 여러 사용자의 작업이 존재하는 상황에서의 Security는 비교적 단순한 HOD 구조와 비교해 매우 복잡했습니다. 특히 TaskTracker의 실행 주체가 아닌 job을 소유한 user로 히스토리가 기록되어야 했습니다. 

 

YARN에서 위의 Security를 넘어서 인증과 접근권한이 기존 개념과 새롭게 생성된 개념들에 적용되어야 했습니다. 유저가 인증이 되고 적절한 접근 권한을 가졌다면 스케쥴러 Queue, Job에 접근할 수 있어야 했습니다. 또, Job의 Task 간에도 JobToken를 통한 인증을 통한 접근이 되도록 하였습니다.

요구사항7 - Reliability and Availability

공유 클러스터로 거듭나며 JobTracker는 하나의 작업만이 아닌 다수의 사용자의 다수의 작업을 관리하게되었습니다. 또한, Queue, Fair Scheduling 등의 새로 추가된 요소들도 복잡도를 높였습니다. 그럴수록 JobTracker의 실패로 인한 피해가 더욱 커져갔기에 안정성에 대한 부분이 많이 요구되었습니다.

 

요구사항8 - Support for Programming Model Diversity

맵리듀스가 다양한 처리 형태를 제공하긴 하였지만 모든 대규모 컴퓨팅에 적합한 모델은 아니었습니다. 예로, 머신러닝 알고리즘의 경우나 BSP(Bulk-Synchronous parallel model)의 경우 맵리듀스로 구현 시 매우 느린 성능과 클러스터에 부하를 보여주곤 했습니다. 하지만, 당시의 자원관리도구는 다양한 프로그래밍 모델을 Job 레벨에서 지원하지 못하였습니다.

 

YARN이 다음 세대의 플랫폼이 되기 위해서는, 이러한 다양한 프로그래밍 모델에 대한 지원은 필수적이었습니다.

 

그러한 요구사항을 반영하여 현재의 YARN은 Tez, Spark 등 다양한 엔진을 Job 레벨에서의 설정을 통해 실행할 수 있게 되었습니다.

 

요구사항9 - Flexible Resource Model

TaskTracker의 Typed slots은 사용률을 매우 낮게 만들었습니다. 각 노드의 맵과 리듀스의 capability를 분리한 것은 cross-task-type 간의 데드락을 막았지만 자원 사용의 병목을 발생시켰습니다.

 

맵-리듀스 단계 전환의 시작점은 각 Job의 설정을 통해 사용자가 조정할 수 있었습니다. 리듀스 task들을 늦게 시작하는 것은 클러스터의 throughput을 높일 수 있었던 반면, 일찍 시작하는 것은 latency를 낮출 수 있었습니다. 맵과 리듀스 slots은 클러스터 운영자에 의해 설정되어 고정되었기에 미사용되는 맵 capacity는 리듀스에 사용되지 못하고, 그 반대도 불가능하였습니다.

 

위 상황에 대한 해결책인 각 노드에서의 다이내믹 slots typing은 스케쥴링을 매우 복잡하게 만들지만 그만큼 클러스터를 효율적으로 사용할 수 있는 방법이었습니다. 또한, 수년간 하드웨어가 발전함에 따라 메모리는 더이상 CPU 대비 희소한 자원이 아니었고, 그렇기에 기존의 RAM 중심의 자원 할당 알고리즘은 더이상 유효하지 않았기에 개선이 필요하였습니다.

 

YARN은 이 2가지와 관련되어 자원 할당 구조를 좀 더 유연하게 개선하였습니다.

요구사항10 - Backward Compatibility

YARN은 기존에 어떠한 방식으로든 운영되고 있던 다양한 버젼의 HDFS, MapReduce, HOD 환경에 연동되거나 그 역할을 대체하며 탄생하게 되었습니다. 그렇기에 기존 환경과의 호환성은 필수적인 부분이었습니다. 

 

 

Reference
[1] Apache Hadoop YARN: yet another resource negotiator

[2] Apache Hadoop YARN: Moving beyond MapReduce and Batch Processing with Apache Hadoop 2

[3] Project HaSTE: Hadoop YARN Scheduling Based on Task-Dependency and Resource-Demand.