하둡 완벽 가이드 - 4. YARN

사용자의 입장으로만 하둡을 바라보게 되어 깊이가 부족하다는 생각을 하게 되었다.
하둡 완벽 가이드를 읽고 이해한대로 정리한다.

---

YARN은 (yet another resource negotiator)은 하둡의 클러스터 자원 관리 시스템이다. 
맵리듀스의 성능을 높이기 위해 하둡2에서 도입되었고, 그 외의 분산 컴퓨팅 도구도 지원한다.

YARN은 클러스터의 자원을 요청하고 사용하기 위한 API를 제공한다. 이 API는 사용자 코드에서 직접 호출할 수는 없고, YARN이 내장된 분산 컴퓨터 프레임워크에서 고수준 API를 작성해야하며, 사용자는 자원 관리의 자세한 내용을 알 수 없다.

맵리듀스, 스파크 같은 분산 프레임워크가 YARN 어플리케이션으로서 cluster compute layer와 cluster storage layer 위에서 작동된다. 피그, 하이브, 크런치와 같은 애플리케이션은 맵리듀스, 스파크, 테즈(일부 또는 모두)에서 구동되는 처리 프레임워크의 예이며 YARN에 직접 접근하지는 않는다.

4.1 YARN 애플리케이션 수행 해부해보기

YARN은 리소스 매니저와 노드 매니저 두 가지 유형의 장기 실행 데몬을 통해 핵심 서비스를 제공한다.
리소스 매니저는 클러스터 당 하나 존재하고, 클러스터 전체 자원의 사용량을 관리하고
노드 매니저는 클러스터의 모든 노드마다 존재하고, 각 노드의 컨테이너를 구동하고 모니터링 한다.
컨테이너에서는 자원(메모리, CPU등)의 사용 한도를 가진 특정 애플리케이션 프로세스가 실행되는 위치다. (unix 프로세스 or 리눅스 cgroup)

YARN이 애플리케이션을 실행하는 방법은 다음과 같다.
1단계: 클라이언트는 YARN에서 애플리케이션을 구동하기 위해 리소스 매니저에 어플리케이션 마스터 프로세스의 구동을 요청한다.
2a-b단계: 리소스 매니저는 컨테이너에서 애플리케이션 마스터를 시작할 수 있는 노드 매니저를 하나 찾는다.
애플리케이션 마스터가 한번만 실행되는지는 애플리케이션마다 다르다. 단순 계산을 단일 컨테이너에서 수행하고 클라이언트에 결과를 반환하고 종료하거나,
3단계: 리소스 매니저에 더 많은 컨테이너를 요청 한 후
4a-b단계: 분산 처리를 수행하는 경우도 있다.

YARN 자체는 클라이언트, 마스터, 프로세스와 같은 애플리케이션이 서로 통신하는 기능은 제공하지 않고, 하둡의 RPC와 같은 원격 호출 방식을 이용하여 상태 변경을 전달하고 클라이언트로부터 결과를 받는다. 방법은 애플리케이션에 따라 다르다.

4.1.1 자원 요청

YARN은 유연한 자원 요청 모델을 가지고 있다. 다수의 컨테이너를 요청할 때 각 컨테이너마다 필요한 컴퓨터 자원, 지역성 제약을 포함하여 요청할 수 있다.

가끔은 지역성 제약이 불가능할 때가 있는데, 할당이 실패하도록 설정하거나 제약을 조금 느슨하게 적용하는 것도 선택이 가능하다.

4.1.2 애플리케이션의 수명

YARN 애플리케이션의 수명은 몇 초 부터 몇 일 또는 몇 달이 걸리는 것도 가능하다. 그래서 수명 자체로 애플리케이션을 분류하지 않고, 사용자가 실행하는 잡의 방식으로 애플리케이션을 분류하는 것이 좋다. 
1. 사용자의 잡 당 하나의 애플리케이션이 실행되는 방식 (ex, 맵리듀스 잡)
2. 워크플로우나 사용자의 잡 세션 당 하나의 애플리케이션이 실행되는 방식 (ex, 스파크) 순차적으로 실행되는 잡이 동일한 컨테이너 사용 가능!
3. 서로 다른 사용자들이 공유할 수 있는 장기 애플리케이션 실행 방식 (ex, 아파치 슬라이더, 임팔라) 애플리케이션 마스터 구동 오버헤드를 피할 수 있음!

4.1.3 YARN 애플리케이션 만들기

기존 애플리케이션을 활용할 수 있다. DAG를 실행하고 싶으면 스파크나 테즈, 스트리밍 처리는 스파크, 쌈자, 스톰
YARN 애플리케이션을 쉽게 만들 수 있도록 도와주는 프로젝트도 있다. 아파치 슬라이더, 아파치 트윌
복잡한 스케쥴링 요구사항이 있는 애플리케이션은 YARN 프로젝트의 일부로 제공되는 분산 쉘

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

하둡 구버전(하둡 1이하)의 맵리듀스 분산 구현은 "맵리듀스 1", YARN(하둡 2이상)을 이용한 구현은 "맵리듀스 2"로 구분한다.

맵리듀스1: 잡의 실행과정을 제어하는 두가지 데몬이 있다. 하나의 잡트래커와 하나 이상의 태스크트래커이다. 잡 트래커는 여러 태스크트래커에서 실행되는 태스크를 스케줄링함으로서 시스템에서 실행되는 모든 잡을 조율한다.

YARN: 맵리듀스1의 잡트래커의 역할을 리소스 매니저와 애플리케이션 마스터(맵리듀스 잡당 하나)로 분리해 각 객체에서 처리한다. 또한, 잡트래커의 완료된 잡에 대한 잡 이력을 저장하는 로직은 별도의 데몬인 히스토리 서버를 통해 수행될 수도 있게 구성되었다. (YARN에서는 타임라인 서버가 한다)
태스크트래커는 YARN의 노드 매니저와 같다. 

잡트래커의 역할이 분리되었으므로 병목이 줄어들어 확장성이 좋아졌고,
리소스 매니저와 어플리케이션 마스터에 나누어 상태 정보가 저장되므로 분할후 정복 문제로 바뀐 HA 서비스를 지원하며,
태스크트래커에 설정된 고정된 크기의 맵, 리듀스 슬롯 대신 잘게 쪼개진 자원을 리소스 풀으로 관리하여 필요한 만큼 자원을 사용하여 효율성이 좋아졌으며,
다양한 분산 애플리케이션을 수용할 수 있는 (맵리듀스, spark,... 심지어 맵리듀스1, 맵리듀스 2도 같이..) 멀티테넌시도 지원한다.

4.3 YARN 스케줄링

YARN은 스케줄러와 설정 정책을 사용자가 직접 선택할 수 있도록 기능을 제공하고 있다.

4.3.1 스케줄러 옵션

FIFO 스케줄러: 애플리케이션을 큐에 하나씩 넣고 순서대로 실행. 쉽지만 공유 클러스터에서는 대형 애플리케이션 실행 시 클러스터의 모든 자원을 점유해버릴 수 있는 문제가 있다.
Capacity 스케줄러: 작은 잡이 제출되면 즉시 분리된 전용 큐에서 처리한다. 자원을 미리 예약해두기 때문에 전체 클러스터의 효율성이 떨어진다.
Capacity 스케줄러를 위해 큐를 나누고 각 큐의 기본 자원량, 최대 자원량을 설정할 수 있다. 큐 탄력성이라고 한다. 잡을 제출할 때 큐를 선택해서 제출 할 수 있다.
Fair 스케줄러: 실행 중인 모든 잡의 자원을 동적으로 분배한다. 잡이 추가될 때마다 클러스터 자원의 절반을 이 잡에 할당한다.
사용자별로 큐를 가질 수 있으므로, 아무도 자원을 사용하지 않을 때는 어플리케이션이 전체 자원을 사용할 수 있으나 여러 사용자가 자원을 사용할 때는 큐 내에서 균등하게 자원이 공유된다.