Hadoop의 개요 #4 - MapReduce와 YARN

하둡 개념을 잡을 때, 맵리듀스와 얀의 관계에 대해 이해하는게 참 힘들었다. YARN의 또다른 이름이 MapReduce2이다. 아니 왜...? 

당시 공부 할때, 맵리듀스와 얀 둘이 아예 다른 개념인것 같았다. 

우선 개념만! 공부할 때는 뜬구름 속 이야기 같아서 머리에 텍스트만 늘었을 뿐, 개념들이 형상화 되어 내 것이 되지 못했기 때문이다. 

그러다보니 이해도 안되고 왜 얀이 맵리듀스의 진화형인지 도통 모르겠더라. 

 

 

 

ㅠㅠ가만히 있을 수는 없으니까...그냥 삽질 몇번 하다보니 개념이 잡히게 되었다. 역시 나는 손을 움직여야한다

대략적으로 개념을 잡고 가자면, 하둡 1.0에서는 오로지 맵리듀스 방식으로 HDFS에 저장된 데이터를 처리했었다.

 

맵리듀스는 대량의 데이터를 처리할 때 괜찮은 성능을 제공하는 알고리즘이지만, Disk 기반으로 작동하다보니 느릴 수 밖에 없었고(메모리기반으로 작동되는 spark랑 속도가 대략 10배 이상 차이가 난다.) 또 맵리듀스 방식의 프로그래밍은 소스도 복잡하다. 이를 대비해 Pig나 Hive라는 맵리듀스 기반의 대용량 데이터 처리 프로그램이 있지만! 

어쨌든, 맵리듀스는 느리다. 
그리고 좀 어이가 없는게 맵리듀스는 데이터 처리일(자바프로그램) 뿐 아니라 아예 그 일(job)을 관리까지 해야해한다.  나는 편의점에서 껌 하나 사려는데 내가 

껌 공장

까지 가서 껌 품질 관리도 하고 껌 개수 배분도(내가 사려는 만큼) 해야하고 어쩌다 보니 껌 포장도 내가 하는 느낌이랄까?여간 귀찮은게 아니다. 

껌하나 사려고... 껌 공장에 취직하는 꼴이니!

HDFS에 저장된 데이터를 쓰려면 무조건 맵리듀스 방식을 고수해야하는 것이다.  

 

YARN은 이런 맵리듀스의 문제점을 개선하기 위해 하둡 2.x부터 나온 기능이다. 

YARN은 데이터 처리일(job)을 관리해주는 역할을 한다.

즉 나는 편의점에 껌(맵리듀스)을 사러가면 난 편의점에 들어온 껌만 사면된다. 

나머지는 껌 공장 직원(YARN)이 알아서 해주는 것이다. 

맵리듀스는 그 하둡에서 데이터를 처리하기 위해 작동되는 애플리케이션들 중 하나가 되었다.

 

대략적인 개념만 이렇게 잡고 아래에 정리해둔 글을 읽으면 좀 더 이해가 쉬울 것이다.(아마도..)

 

■ 맵리듀스(MapReduce)

 

 

1) 구글에서 대용량 데이터 처리를 분산 병렬 컴퓨팅에서 처리하기 위한 목적으로 제작하여 2004년 발표한 소프트웨어 프레임워크

2) 페타바이트 이상의 대용량 데이터를 신뢰도가 낮은 컴퓨터로 구성된 클러스터 환경에서 병렬 처리를 지원하기 위해서 개발

3) HDFS에 저장된 파일을 분산 배치 분석을 할 수 있게 도와주는 프레임워크

4) 맵(Map) : 입력파일을 한 줄씩 읽어서 데이터를 변형

5) 리듀스(Reduce) : 맵의 결과 데이터를 집계(즉, 모은다)

 

6) 맵리듀스 아키텍쳐(하둡 1.0 기준)

 

① 클라이언트

- 사용자가 실행한 맵리듀스 프로그램과 하둡에서 제공하는 맵리듀스 API

- 사용자는 맵리듀스 API로 맵리듀스 프로그램 개발, 하둡에서 실행

 

② 잡트래커

- 잡(job): 클라이언트가 하둡에 실행을 요청할 때 발생되는 맵리듀스 프로그램은 job이라는 단위로 관리

- 하둡 클러스터에 등록된 전체 잡의 스케줄링을 관리/모니터링

- 스케줄링 관리

- 잡을 처리하기 위해 몇 개의 맵과 리듀스를 실행할지 계산

- 계산된 맵과 리듀스는 어떤 태스크트래커에서 실행할지 결정한 뒤 잡을 나눔

- 스케줄링 모니터링

- 하트비트로 태스크트래커와 통신하면서 상태과 작업 실행정보를 받음

- 태스크트래커에 장애 생기면 다른 대기중인 태스크 트래커에게 태스크 실행

- 전체 하둡 클러스터에서 하나만 실행됨

- 보통 네임노드 서버에 설치하지만 따로 설치해도 됨

 

③ 태스크트래커

- 하둡의 데이터노드 서버에서 실행되는 데몬(데몬: 백그라운드에서 여러 작업을 수행하는 프로그램, 사용자가 직접 제어하지 않음)

- 사용자가 설정한 맵리듀스 프로그램 실행

- 잡트래커가 명령을 하면 요청 받은 맵과 리듀스 수만큼의 맵 태스크와 리듀스 태스크를 생성

- 맵 태스크, 리듀스 태스크: 사용자가 만든 맵과 리듀스 프로그램

 

■ YARN(Yet Another Resource Negotiator, 또다른 리소스 협상가)

 

 

1) 맵리듀스의 문제

- 하둡 1.0의 맵리듀스 프레임워크는 무조건 맵리듀스 API로 만든 프로그램만 실행

- 맵리듀스 SPOF(Single Point Of Failure, 단일 고장점) 문제: 잡트래커에 문제가 생기면 테스크트래커가 작동중이라도 맵리듀스를 사용 못함

- 잡트래커에 메모리가 부족하면 잡의 상태 모니터링을 못하고 새로운 잡도 실행 요청 못함

- 맵리듀스는 슬롯(한번에 실행되는 태스크들의 묶음)이란 개념으로 클러스터에서 실행할 수 있는 태스크의 개수를 관리 즉, 태스크 수행 단위

- 맵 슬롯과 리듀스 슬롯으로 구분되는데 실행중인 잡이 맵 슬롯만 사용하고 있거나 리듀스 슬롯만 사용한다면 다른 슬롯은 잉여자원이 되서 리소스가 낭비

- 맵리듀스 리소스는 맵리듀스 기반의 프레임워크만 자원을 공유해서 다른 에코시스템은 자원을 공유할 수 가 없음

- 맵과 리듀스 로 정해진 구조 외에 다른 알고리즘을 지원하는데 한계가 있음

- 맵리듀스 잡을 실행하는 클라이언트와 맵리듀스 클러스터 버전이 반드시 동일해야함

2) YARN의 목표

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

- 잡트래커의 주요 기능인 클러스터 자원 관리와 애플리케이션 라이프 사이클 관리를 분리

- 다양한 데이터 처리 애플리케이션 수용

- 기존 맵리듀스는 반드시 맵리듀스 API로 구현된 프로그램만 실행

- 얀에서 맵리듀스는 실행되는 애플리케이션들 중 하나일 뿐임

 

3) YARN의 장점

① 확장성

- 수용가능한 단일 클러스터 규모가 10000 노드까지 확대됨 (전보다 두배 이상)

- 데이터 처리 작업의 개수도 증가

② 클러스터 활용 개선

- 자원관리를 위해 리소스 매니저라는 새로운 컴포넌트 개발

- 리소스 매니저는 실제로 사용 가능한 단위로 자원을 관리(CPU, 메모리, 디스크, 네트워크 등)하는데 얀에서 실행되는 애플리케이션에 이 자원을 배분함

- 개별 에코시스템의 자원 배분을 고민하지 않아도 됨

③ 워크로드(발생하는 모든 작업) 확장

- 얀은 맵리듀스, 인터랙티브 질의, 실시간 처리, 그래프 알고리즘 등 다양한 형태의 워크로드 확장이 가능

 

 

4)　YARN 아키텍쳐

 

 

 

①　리소스 매니저

- 얀의 마스터 서버로 하나 또는 이중화를 위해 두개의 서버에만 실행됨

- 글로벌 스케줄러: 클러스터 자원관리

- 최적의 데이터 노드를 찾아준다

- 전체 클러스터에서 사용할 수 있는 모든 시스템 자원들(CPU, 메모리, 디스크, 네트워크 등)을 관리

- 얀 클러스터에서 실행되는 프로그램이 리소스를 요청하면 적절하게 분배하고 리소스 사용 상태를 모니터링

 

②　노드매니저

- 얀의 worker 서버

- 맵리듀스의 태스크트래커 기능 담당

- 리소스 매니저를 제외한 모든 서버에서 실행

- 컨테이너를 실행시키고, 컨테이너의 라이프 사이클을 모니터링

- 컨테이너 장애상황 모니터링

- 컨테이너가 요청한 리소스 보다 많이 사용하고 있는 지 감시

③　컨테이너

- 노드매니저가 실행되는 서버의 자원을 표현(CPU, Disk, Memory, Network..)

- 리소스 매니저가 요청에 의해 컨테이너가 실행

- 하나의 서버에 여러 컨테이너 있을 수 있음

- 맵리듀스의 태스크트래커가 태스크 단위로 잡을 실행한것 처럼 노드매니저는 컨테이너를 단위로 애플리케이션을 실행하고 각 상태를 스케줄링

 

④　애플리케이션 마스터

- 하나의 애플리케이션(프로그램)을 관리하는 마스터서버

- 클라이언트가 얀에 애플리케이션 실행을 요청하면 얀은 하나의 애플리케이션에 하나의 애플리케이션 마스터를 할당

- 예를 들어, 얀 클러스터에 ‘맵리듀스 잡’과 ‘스톰 애플리케이션’ 실행을 요청하면 두개의 애플리케이션 마스터가 실행

- 애플리케이션에 필요한 리소스를 스케줄링

- 노드매니저에게 애플리케이션에 필요한 컨테이너를 실행시킬 것을 요청

- 애플리케이션 마스터는 컨네이터에서 실행됨