EXCELSIOR

하둡2 - 얀(YARN) 본문

DataBase/Hadoop

하둡2 - 얀(YARN)

Excelsior-JH 2016. 11. 4. 00:19

1. 얀(YARN)의 등장배경

- YARN = Yet Another Resource Negotiator 이다. 이를 번역하면 "(또 다른) 리소스 협상가"라고 할 수 있다.


① 맵리듀스의 단일 고장점(Single Point of Failure, SPOF)

잡트래커는 모든 맵리듀스 잡의 실행 요청을 받고, 전체 잡의 스케줄링 관리와 리소스 관리를 담당한다. 그래서 클라이언트가 맵리듀스 잡을 실 행하려면 반드시 잡트래커가 실행 중이어야 하며, 태스크트래커가 실행 중이라도 잡 트래커가 돌아가고 있지 않다면 맵리듀스 잡 실행이 불가능하다.


② 잡트래커의 메모리 이슈

잡트래커는 메모리 상에 전체 잡의 실행정보를 유지하고, 이를 맵리듀스 잡 관리에 활용한다. 이렇게 메모리에 많은 정보를 유지하다 보니 잡트래커도 자연스럽게 많은 메모리가 필요해졌다. 실제로 하둡 클러스터를 운영할 때 잡트래커에 힙 메모리를 여유있게 할당해주는 이유도 바로 이러한 특징 떄문이다. 하지만 잡트래커의 메모리가 부족하다면 잡의 상태를 모니터링할 수도 없고, 새로운 잡의 실행을 요청할 수도 없다. 이때문에 잡트래커는 맵리듀스의 SPOF가 됐다.


③ 맵리듀스 리소스 관리 방식

맵리듀스는 슬롯이라는 개념으로 클러스터에서 실행할 수 있는 태스크 개수를 관리한다. 이때 슬롯은 맵 테스크를 실행하기 위한 맵 슬롯과 리듀스 태스크를 실행하기 위한 리듀스 슬롯으로 구분된다. 설정한 맵 슬롯과 리듀스 슬롯을 모두 사용하고 있을 때는 문제가 없으나 실행 중인 잡이 맵 슬롯만 사용하고 있거나, 혹은 리듀스 슬롯만 사용하고 있다면 다른 슬롯은 잉여 자원이 되기 떄문에 전체 클러스터 입장에서는 리소스가 낭비되는 셈이다. 또한 맵리듀스의 자원을 다른 에코시스템과 공유하는데도 문제가 있다. 하이브나 피그같은 맵리듀스 기반 시스템은 상관이 없지만 타조, 임팔라, 지라프처럼 맵리듀스 기반이 아닌 시스템은 자원을 공유할 수가 없다.


④ 클러스터 확장성

최대 단일 클러스터는 4,000대, 최대 동시 실행 태스크는 40,000개가 한계다. 그리고 맵리듀스는 맵과 리듀스라는 정해진 구조외에 다른 알고리즘을 지원하는데 한계가 있다. 예를 들어, K-Means나 페이지랭크(PageRank)알고리즘의 경우 프레겔(Pregel, 구글에서 개발한 분산 그래프 분석 오픈소스프레임워크)에서는 맵레듀스 대비 10배 이상의 성능을 보여준다.


⑤ 버전 통일성

맵리듀스 잡 실행을 요청하는 클라이언트와 맵리듀스 클러스터의 버전이 반드시 동일해야 한다는 부분도 문제점 중의 하나이다.



2. 얀의 특징

1) 잡트래커의 주요 기능 추상화

잡트래커는 클러스터 자원 관리와 애플리케이션 라이프 사이클 관리라는 두 가지 핵심 기능을 수행합니다. 얀은 이 두 가지 기능을 분리하고 새로운 추상화 레이어를 만들었다.


2) 다양한 데이터 처리 어플리케이션의 수용

기존 맵리듀스느 반드시 맵리듀스 API로 구현된 프로그램만 실행할 수 있었다. 하지만 얀은 맵리듀스도 얀에서 실행되는 애플리케이션의 하나로 인식한다.


① 확장성

얀은 수용 가능한 단일 클러스터 규모를 10,000 노드까지 확대했으며, 클러스터 규모 확대로 인해 처리 가능한 데이터 처리 작업의 개수도 증가했다.


② 클러스터 활용 개선

얀은 자원 관리를 위해 ResourceManager라는 새로운 컴포넌트를 개발했다. 기존 맵리듀스는 맵 슬롯과 리듀스 슬롯이라는 개념으로 자원을 관리했지만 리소스매니저는 CPU, 메모리, 디스크, 네트워크 등 실제 가용한 단위로 자원을 관리하고, 얀에서 실행되는 어플리케이션에 자원을 배분한다. 


③ 워크로드 확장

하둡1은 맵리듀스, 하이브, 피그 등 맵리듀스 기반의 어플리케이션만 실행할 수 있었다. 하지만 얀은 맵리듀스 외에도 인터랙티브 질의, 실시간 처리, 그래프 알고리즘 등 다양한 형태의 워크로드 확장이 가능하다.


④ 맵리듀스 호환성

얀은 기존 맵리듀스 프로그램 코드를 수정하지 않고도 얀에서 실행할 수 있다.



3. 얀 아키텍처(YARN Architecture)


1) 리소스매니저는 글러볼 스케줄러라고 정의할 수 있다. 리소스매니저는 전체 클러스터에서 가용한 모든 시스템 자원을 관리한다. 얀 클러스터에서 실행되는 애플리케이션이 리소스를 요청하면 이를 적절하게 분배하고, 리소스 사용 상태를 모니터링한다.


2) 노드매니저는 맵리듀스의 태스크트래커의 기능을 담당한다. 태스크트래커가 각 슬레이브 서버마다 하나의 데몬이 실행된 것처럼 노드매니저도 각 슬레이브에서 하나의 데몬이 실행된다. 노드매니저는 컨테이너(Container)를 실행하고, 컨테이너의 라이프 사이클을 모니터링한다.


3) 컨테이너는 노드매니저가 실행되는 서버의 시스템 자원을 표현한다. CPU, 메모리, 디스크, 네트워크 같은 다양한 시스템 자원을 표현한다. 맵리듀스의 태스크트래커가 태스크 단위로 잡을 실행했다면 노드매니저는 컨테이너 단위로 애플리케이션을 실행하고 각 상태를 스케줄링한다.


4) 애플리케이션마스터는 하나의 애플리케이션을 관리하는 마스터 서버다. 클라이언트가 얀에 애플리케이션 실행을 요청하면 얀은 하나의 애플리케이션에 하나의 애플리케이셔마스터를 할당한다. 예를 들어, 얀 클러스터에 하나의 맵리듀스 잡과 하나의 스톰 애플리케이션 실행을 요청했다면 두 개의 애플리케이션마스터가 실행된다. 애플리케이션마스터는 애플리케이션에 필요한 리소스를 스케줄링하고, 노드매니저에 애플리케이션이 필요한 컨테이너를 실행할 것을 요청한다.



'DataBase > Hadoop' 카테고리의 다른 글

하둡2 예제실행  (0) 2016.11.11
하둡2 설치 및 실행 (가상 분산 모드)  (4) 2016.11.08
하둡2 - 네임노드 HA  (0) 2016.11.07
하둡2 - 얀(YARN)  (0) 2016.11.04
매퍼(Mapper) 와 리듀서(Reducer) 클래스  (0) 2016.10.14
MapReduce 개념  (0) 2016.10.13
0 Comments
댓글쓰기 폼