YARN #2

. YARN과 맵리듀스 1의 차이점

맵리듀스1에는 job의 실행 과정을 제어하는 하나의 jobtracker와 하나 이상의 tasktracker 두 데몬이 있으며, jobtracker는 여러 tasktracker에서 실행되는 task를 스케줄링 함으로써 시스템에서 실행되는 모든 잡을 조율 한다.

tasktracker는 task를 실행하고 진행 상황을 jobtracker에 전송하기 때문에 jobtracker는 각 job의 전체적인 진행 상황을 파악할 수 있다. task가 실패하면 jobtracker는 다른 tasktracker에 그 task를 다시 스케줄링 할 수 있다.

맵리듀스1에서 jobtracker는 잡 스케줄링(task와 tasktracker를 연결)과 태스크 진행 모니터링(task를 추적하고, 실패하거나 느린 task를 다시 시작하고, 전체 카운터를 유지하는 방법으로 task 장부를 기록)을 맡고 있다.

 

반면 YARN은 이런 역할을 분리된 객체인 리소스 매니저와 애플리케이션 마스터 (맵리듀스 job 당 하나)를 통해 처리한다. 또한 jobtracker는 완료된 job에 대한 job 이력을 저장하는 역할도 맡고 있는데, 이 기능은 jobtracker의 부하를 줄이기 위해 별도의 데몬인 히스토리 서버를 통해 수행될 수도 있다.

YARN에서 이와 동일한 역할은 애플리케이션의 이력을 저장하는 타임라인 서버가 맡고 있다

 

YARN을 사용하여 얻는 이익 (맵리듀스1의 여러 한계를 극복)

¤ 확장성

YARN은 맵리듀스1 보다 큰 클러스터에서 실행 될 수 있다.

맵리듀스 1은 4,000 노드나 40,000태스크를 넘어서면 병목현상이 발생한다.

잡트래커가 잡과 태스크를 모두 관리하기 때문이다.

YARN은 리소스매니저와 애플리케이션 마스터를 분리하는 구조이므로 이러한 한계를 극복할 수 있다.

YARN은 10,000 노드와 100,000 태스크까지 확장할 수 있도록 설계되었다.

잡트래커와 달리 애플리케이션(여기서는 맵리듀스 잡)의 각 인스턴스는 별도의 전용 애플리케이션 마스터를 가진다. 애플리케이션 마스터는 해당 애플리케이션이 실행될 때만 존재한다. 사실 이 모델은 구글의 맵리듀스 논문과 더 유사한데, 이 논문에서 마스터는 워커 집합에서 실행되는 맵과 리듀스 태스크를 코디네이션(조정)할 때 시작된다고 설명하고 있다.

 

¤ 가용성

고가용성은 서비스 데몬에 문제가 발생했을 때 서비스에 필요한 작업을 다른 데몬이 이어받을 수 있도록 상태 정보를 항상 복사해두는 방법으로 구현된다. 하지만, 잡트래커의 메모리에 있는 복잡한 상태 정보가 매우 빠르게 변경되는 상황에서 잡트래커 서비스에 HA를 적용하는 것은 매우 어려운 일이다. 각 태스크의 상태는 수 초마다 변경되기 때문이다.

잡트래커의 역할이 YARN에서는 리소스 매니저와 애플리케이션 마스터로 분리되었기 때문에 HA 서비스가 ‘분할 후 정복(divide and conquer)’ 문제로 바뀌었다. 먼저 리소스 매니저의 HA를 제공한 후 YARN애플리케이션(각 애플리케이션 기준)을 지원하면 된다. 실제로 하둡2는 리소스 매니저와 맵리듀스 잡을 위한 애플리케이션 마스터 모두 HA를 제공한다.

 

¤ 효율성

맵리듀스 1에서 각 태스크트래커는 맵 슬롯과 리듀스 슬롯으로 구분된 고정 크기 ‘슬롯’의 정적 할당 설정을 가지고 있다.

맵 슬롯은 맵 태스크 실행에만 사용할 수 있고 리듀스 슬롯은 리듀스 태스크에만 사용할 수 있다.

YARN에서 노드 매니저는 정해진 개수의 슬롯 대신 일종의 리소스 풀을 관리한다.

YARN에서 실행되는 맵리듀스는 클러스터의 맵 슬롯은 남아 있지만 리듀스 슬롯이 없어서 리듀스 태스크가 마냥 대기하고 있는 상황(맵리듀스1에서 발생 가능)은 절대 발생하지 않는다. 태스크를 실행할 수 있는 자원이 있으면 애플리케이션은 그 자원을 받을 자격이 있다.

게다가 YARN의 지원은 잘 쪼개져 있기 때문에 애플리케이션은 필요한 만큼만 자원을 요청할 수 있다. 기존에는 개별 슬롯을 사용했기 때문에 특정 태스크를 위해 너무나 많거나(자원의 낭비) 너무 적게(실패의 원인)자원을 할당했다.

 

¤ 멀티테넌시(다중 사용자)

특정 측면에서 YARN의 가장 큰 장점은 하둡이 맵리듀스를 뛰어넘어 다양한 분산 애플리케이션을 수용할 수 있다는 것이다. 맵리듀스는 YARN의 애플리케이션 중 하나일 뿐이다. 뿐만 아니라 사용자는 서로 다른 버전의 맵리듀스를 동일한 YARN 클러스터에서 수행하는 것도 가능하다. 이는 맵리듀스 업그레이드 과정을 관리하기 쉽게 만든다. 그러나 잡 히스토리 서버나 셔플 핸들러 같은 일부 맵리듀스나 YARN 자신은 업그레이드를 위해 별도의 이중화 된 클러스터가 여전히 필요하다.

 

YARN의 출현

1) Hadoop이 처음 나왔을 때는 지금처럼 여러 개의 서브 프로젝트로 구성되지 않았다.

2) Hadoop 이라는 하나의 프로젝트 내에 hdfs와 mapreduce가 자바의 패키지로 분리되어 있었다.

3) 점차 Hadoop이 많이 사용되어지고 수 천대 이상으로 구성되면서 아래와 같은 추가 요구사항 발생

(1) Hadoop 클러스터는 다수의 서버로 구성되어 많은 컴퓨팅 리소스를 가진다.

-> 이것을 하나의 컴퓨팅 플랫폼(mapreduce)에만 할당하는 것은 비효율 적이다.

-> mapreduce 외에 spark, storm과 같은 다른 컴퓨팅 플랫폼이 출현하였고 이들을 사용하는 요구사항도 증가

(2) 여러 개의 컴퓨팅 플랫폼을 동시에 실행할 경우 서버의 리소스(주로 메모리)가 부족하여

정상적으로 수행되던 작업들이 다른 작업에 의해 문제가 발생

-> mapreduce 이외에 다른 클러스터를 구성할 경우 클러스터 전체의 사용 효율이 떨어지는 경우가 많음

4) 이런 요구사항을 해결하기 위해 Hadoop 프로젝트에서는 YARN이라는 새로운 서브 프로젝트를 만듬