YARN 애플리케이션
YARN 애플리케이션을 작성하는 것은 가능한 기존 애플리케이션을 활용하는 편이 좋다. 예로 방향성 비순환 그래프(driected acyclic graph, DAG) 를 실행하고 싶으면 스파크나 테즈가 더 적합하고 스트리밍 처리는 스파크, 쌈자 또는 스톰을 사용하는 것이 좋다.
YARN 애플리케이션을 쉽게 만들 수 있도록 도와주는 프로젝트가 있다. 아파치 슬라이더는 기존의 분산 애플리케이션을 YARN 위에서 실행하도록 해준다. 사용자는 HBase와 같은 자신의 애플리케이션 인스턴스를 다른 사용자와 상관없이 클러스터에서 실행할 수 있다. 이렇게 되면 여러 사용자가 동일한 애플리케이션의 서로 다른 버전을 실행할 수도 있다. 슬라이더는 애플리케이션이 실행되는 노드의 수를 변경하거나 실행 애플리케이션을 중지하고 다시 시작하게 제어할 수 있다.
아파치 트윌은 슬라이더와 비슷하지만 YARN에서 실행되는 분산 애플리케이션을 개발할 수 있는 간단한 프로그래밍 모델을 추가로 제공하고 있다. 트윌은 자바 Runnable 객체를 확장한 클러스터 프로세스를 정의한 후 클러스터의 YARN 컨테이너에서 이를 실행하는 기능을 제공한다. 실시간 로깅과 명령메시지 기능 등을 제공한다.
YARN 프로젝트의 일부로 제공되는 분산쉘을 사용하면 YARN 애플리케이션을 작성하는 방법에 대한 좋은 예제를 얻을 수 있다. 분산 쉘은 클라이언트 또는 애플리케이션 마스터가
YARN과 맵리듀스 1의 차이점
하둡 구버전(하둡 1과 이전 버전)의 맵리듀스 분산 구현은 맵리듀스 1로, YARN(하둡 2와 이후 버전)을 이용한 구현은 맵리듀스 2로 구분해서 언급한다.
구버전과 신버전의 맵리듀스 API는 맵리듀스 1과 맵리듀스 2의 구현과 다른 의미다. 맵리듀스 api는 사용자 측면의 클라이언트 기능으로, 맵리듀스 프로그램을 작성하는 방법을 결정한다. 반면 구현은 맵리듀스 프로그램을 실행하는 서로 다른 방식을 의미한다. 따라서 총 4개의 조합이 가능하며, 구버전과 신버전의 맵리듀스 API는 맵리듀스 1과 맵리듀스 2 모두에서 실행할 수 있다.
맵리듀스 1에는 잡의 실행 과정을 제어하는 하나의 잡트래커와 하나 이상의 태스크 트래커 등 두 종류의 데몬이 있다. 잡트래커는 여러 태스크트래커에서 실행되는 태스크를 스케줄링함으로썬 시스템에서 실행되는 모든 잡을 조율한다. 태스크트래커는 태스크를 실행하고 진행 상황을 잡트래커에 전송하기 때문에 잡트래커는 각 잡의 전체적인 진행 상황을 파악할 수 있다. 태스크가 실패하면 잡트래커는 다른 태스크트래커에 그 태스크를 다시 스케줄링 할 수 있다.
맵리듀스1에서 잡트래커는 잡 스케줄링 (태스크와 태스크트래커를 연결)과 태스크 진행 모니터링(태스크를 추적하고, 실패하거나 느린 태스크를 다시 시작하고, 전체 카운터를 유지하는 방법으로 태스크 장부를 기록한다)을 맡고 있다. 반면 YARN은 이러한 역할을 분리된 객체인 리소스 매니저와 애플리케이션 마스터(맵리듀스 잡 당 하나)를 통해 처리한다. 도한 잡 트래커는 완료된 잡에 대한 잡 이력을 저장하는 역할도 맡고 있는데 이 기능은 잡트래커의 부하를 줄이기 위해 별도의 데몬인 히스토리 서버를 통해 수행될 수도 있다. YARN에서 이와 동일한 역할은 애플리케이션의 이력을 저장하는 타임라인 서버가 맡고 있다.
태스크트래커는 YARN의 노드 매니저와 같다.
| MapReduce 1 | YARN |
|---|---|
| 잡트래커 | 리소스 매니저, 애플리케이션 마스터, 타임라인 서버 |
| 태스크트래커 | 노드 매니저 |
| 슬롯 | 컨테이너 |
YARN은 맵리듀스 1의 여러 한계를 극복하기 위해 설계되었다. YARN을 사용하여 얻을 수 있는 이익은 다음과 같다.
- 확장성
YARN은 맵리듀스 1보다 큰 클러스터에서 실행될 수 있다. 맵리듀스 1은 4,000 노드나 40,000 태스크를 넘어서면 병목현상이 발생한다. 잡트래커가 잡과 태스크를 모두 관리하기 때문이다. YARN은 리소스 매니저와 애플리케이션 마스터를 분리하는 구조이므로 이러한 한계를 극복할 수 있다. YARN은 10,000 노드와 100,000 태스크까지 확장할 수 있도록 설계되었다.
- 가용성
고가용성(HA)은 서비스 데몬에 문제가 발생했을 때 서비스에 필요한 작업을 다른 데몬이 이어받을 수 있도록 상태 정보를 항상 복사해두는 방법으로 구현된다. 하지만 잡트래커의 메모리에 있는 복잡한 상태 정보가 매우 빠르게 변경되는 상황에서 잡트래커 서비스에 HA를 적용하는 것은 매우 어려운 일이다. 각 태스크의 상태는 수 초마다 변경되기 때문이다.
잡트래커의 역할이 YARN에서는 리소스 매니저와 애플리케이션 마스터로 분리되었기 때문에 HA 서비스가 분할 후 정보 문제로 바뀌었다. 먼저 리소스 매니저의 HA를 제공한 후 YARN 애플리케이션(각 애플리케이션 기준)을 지원하면 된다. 실제로 하둡 2는 리소스 매니저와 맵리듀스 잡을 위한 애플리케이션 마스터 모두에 HA를 제공한다.
- 효율성
맵리듀스 1에서 각 태스크트래커는 맵 슬롯과 리듀스 슬롯으로 구분된 고정 크기 슬롯의 정적 할당 설정을 가지고 있다. 맵 슬롯은 맵 태스크 실행에만 사용할 수 있고 리듀스 슬롯은 리듀스 태스크에만 사용할 수 있다.
YARN 에서 노드 매니저는 정해진 개수의 슬롯 대신 일종의 리소스 풀을 관린한다. YARN에서 실행되는 맵리듀스는 클러스터의 맵 슬롯은 남아 있지만 리듀스 슬롯이 없어서 리듀스 태스크가 마냥 대기하고 있는 상황(맵리듀스 1에서 발생할 수있는)은 절대 발생하지 않는다. 태스크를 실행할 수 있는 자원이 있으면 애플리케이션은 그 자원을 받을 자격이 있다.
- 멀티테넌시(다중 사용자)
특정 측면에서 YARN의 가장 큰 장점은 하둡이 맵리듀스를 뛰어넘어 다양한 분산 애플리케이션을 수용할 수 있다는 것이다. 맵리듀스는 YARN의 애플리케이션 중 하나일 뿐이다.
뿐만 아니라 사용자는 서로 다른 버전의 맵리듀스를 동일한 YARN 클러스터에서 수행하는 것도 가능하다. 이는 맵리듀스 업그레이드 과정을 관리하기 쉽게 만든다. 그러나 잡 히스토리 서버나 셔플 핸들러 같은 일부 맵리듀스나 YARN 자신은 업그레이드를 위해 별도의 이중화된 클러스터가 여전히 필요하다.