hadoop 1.0 vs 2.0

HADOOP

by 리카르돌 2017. 8. 22. 10:43

hadoop 1.0 vs 2.0 아키텍처 리뷰

하둡 2.0 의 리소스 관리 플랫폼인 YARN은 하둡 클러스터의 각 어플리케이션에 필요한 리소스를 할당하고 모니터링하는 업무에 집중함으로써 다양한 어플리케이션이 하둡 클러스터의 리소스를 공유할 수 있도록 하는 핵심 요소이다.

하둡의 변화를 한 눈에 알 수 있는 그림으로 하둡 2.0 YARN 은MapReduce 2.0 을 포함하여 다양한 분산처리 환경을 지원한다. YARN 의 특징을 알아 보도록 하자.

JobTracker를 Resource Manager와 Application Master로 분리
하둡 1.0 MapReduce 프레임워크의 JobTracker는 두가지 기능을 수행하고 있다. 하나는 클러스터 전체의 리소스 관리이고 다른 하나는 여러 잡(Job)을 수행하면서 그것들이 성공적으로 끝날때까지 관리해주는 것입니다. 이를 YARN에서는 Resource Manager와 Application Master두개로 분리했다. YARN 클러스터마다 Application Master라는 것이 존재하고 클러스터내의 각 서버마다 Node Manager가 존재한다. 이런 분산환경 위에서 실행되는 잡(Job)마다 하나의 서버가 Application Master로 실행되어 해당 잡(Job)에 필요한 자원을 Resource Manager로부터 받아내고 해당 잡(Job)내의 태스크(Task)들을 관리하는 역할을 하게 된다.

효율적인 자원 관리
또다른 큰 차이점은 각 서버마다 실행되는 Node Manager들이 태스크들을 실행하고 그에 필요한 자원을 관리하기 때문에 하둡 1.0의 MapReduce 프레임워크에서 볼 수 있는 맵퍼와 리듀서의 슬롯수와 같은 개념 자체가 없다. 하둡 1.0 MapReduce 프레임워크의 문제는 맵퍼와 리듀서를 따로 설정하다 보니 맵퍼는 모두 동작하는데 리듀서는 놀고 있거나 혹은 반대의 경우들이 생긴다는 것이었다. 즉, 클러스터 전체의 사용률이 굉장히 낮았다는 것입니다. 하둡 1.0처럼 맵퍼 슬롯과 리듀서 슬롯이 별도로 존재하지 않고 둘다 컨테이너 안에서 동작하며 컨테이너 자체도 따로 슬롯이 있는 것이 아니라 전체 클러스터의 리소스 상황과 요청된 잡(Job)의 리소스 요구에 따라 Container가 몇 개나 실행될지 등이 결정된다.

확장성 범위 확대
하둡 1.0에서는 JobTracker는 하나의 노드이고 거기서 클러스터 전체의 리소스 관리와 실행중인 잡관리를 하다보니 4천대 이상의 클러스터나 4만개 이상의 테스크를 동시에 실행하지 못하는 문제점이 있었다.
YARN에서는 Resource Manager와 Application Master의 분리로 이 문제를 해결하였다.

다양한 분산처리 환경 지원
MapReduce 이외의 다른 분산처리 환경을 지원하며 YARN API를 이용하면 새로운 분산처리 환경의 개발이 가능하다.
예를 들어 버클리대학에서 만든 SPARK라는 분산환경과 다른 아파치 오픈소스 분산처리 시스템인 HAMA와 GIRAPH등이 이미 지원되고 있다. 그리고 트위터의 실시간 분산처리 시스템인 STORM도 YARN위에서 동작하고 있다.
YARN위의 MapReduce 프레임워크의 경우도 YARN API를 사용해서 개발된 것으로 YARN입장에서 보면 하나의 애플리케이션에 불과하다.

최근에 다양한 기업들이 하둡 2.0을 지원한다고 발표하면서 자사의 솔루션과 하둡을 연동하는 움직임이 활발하다.
SAP, RedHat, IBM, EMC 등등 대부분의 벤더들이 지원을 하고 있다
YARN의 도입으로 기존에 MapReduce의 배치처리방식 뿐만 아니라 Batch, Interactive, Realtime, Streaming의 네가지 주요 데이터 처리 방식을 모두 지원하게 되었다.

이제부터 하둡의 진화과정을 살펴보도록 하겠다.

1. 하둡의 등장

하둡은 구글 파일 시스템(GFS)에서 비롯되어 구글이 자사의 서비스 플랫폼을 공개한 후 YAHOO의 개발자 더그 커팅(Doug Cutting)이 만들어낸 빅데이터 처리 기술이다.
구글이 자신들의 검색 서비스를 위해 사용하고 있던 분산파일 시스템인 GFS와 분산처리 시스템 MapReduce에 대한 논문을 발표하면서 구글의 분산 시스템방식이 널리 알려지게 되었다.
당시 오픈 소스 검색 엔진인 넛치(Nutch)를 개발 중이던 더그 커팅은 넛치에서 웹 검색 수준의 대용량 데이터 처리를 위해 여러 대의 컴퓨터를 연결해서 작업을 수행하는 기능을 구현하는데 있어 많은 어려움을 느끼고 있었는데 마침 구글의 논문을 접한 더그 커팅은 여기에 나온 내용을 참고하여 구현한 소프트웨어가 바로 하둡이다.

이렇듯 하둡은 분산처리 시스템인 구글 파일 시스템(GFS)을 대체할 수 있는 하둡 분산 파일 시스템(HDFS)과 데이터를 분산시켜 처리한 뒤 하나로 합치는 기술인 MapReduce를 구현한 오픈소스 프레임워크다. 아파치 소프트웨어 재단 소속으로 HDFS외 PIG, HBASE 같은 프로그래밍 언어를 포함하고 있다.

하둡은 대량의 데이터를 그 구조와 상관없이 저렴한 비용으로 처리할 수 있는 능력을 제공하기 때문에 빅데이터를 말할 때 정말로 필수적으로 등장하는 기술이며 페이스북과 야후, 국내의 네이버 등 인터넷 서비스업체 및 SKT, KT 등 통신업체에서도 활발히 사용되고 있다.

2. 하둡1.0
하둡은 분산 파일 시스템인 HDFS(Hadoop Distributed File System)와 MapReduce로 이루어져 있다.
HDFS는 대용량의 데이터를 효율적으로 저장이 가능하게 하는 파일 시스템이고 MapReduce는 대량의 자원을 다루는 분산병렬 시스템의 효율적인 지원을 위한 목적으로 만들어진 프로그래밍 모델이다.

하둡 1.0은 여러가지 제한 사항이 있다.
단 하나의 NameNode 가 전체 클러스터를 관리하게 되어 단일 장애점(SPOF: single point of failure)이 되며. 최대 4,000 노드와 4만 Task 까지만 확장이 된다. MapReduce 패러다임은 제한된 작업 유형에만 적용시킬 수 있고 이외에 다른 데이터 처리 모델이 없다.
효율적인 방법으로 클러스트의 자원을 활용할 수 없다.

2.1. 하둡1.0 구성요소

하둡의 분산파일 시스템인 HDFS와 분산처리 시스템인 MapReduce는 물리적으로 같은 서버들에 공존하는 것이 일반적이다. 이 두 시스탬 모두 하나의 마스터와 다중 슬레이브 구조를 갖는데 다중 슬레이브들의 경우 각 서버마다 HDFS 슬레이브와 MapReduce 슬레이브가 같이 놓인다 많은 경우 마스터들은 별도 서버에 실행하지만 둘을 같은 서버에 실행하기도 한다.

NameNode
하둡은 Master/Slave 구조를 가진다. Namenode는 HDFS에서 마스터 역할을 하며, 슬레이브 역할을 하는 Datanode에게 I/O 작업을 할당한다. Namenode는 메타데이터를 관리하기 위해 EditLog 와 FsImage 파일을 사용한다.
하둡 1.0에서는 Namenode는 이중화 구성을 할 수 없어서, 하둡 클러스터를 운영할 때 단일 장애 지점이 된다.

※ EditLog 는 HDFS의 메타데이터에 대한 모든 변화를 기록하는 로그 파일이다. (저장/삭제/이동 등의 액션 로그) Namenode의 로컬에 저장된다.
※ FsImage 은 파일 시스템의 네임스페이스(디렉터리명, 파일명, 상태 정보)와 파일에 대한 블록 매핑 정보를 저장하는 파일로 Namenode의 로컬에 저장된다.

Secondary NameNode
HDFS의 블록이 변경되더라도 실시간으로 변경정보를 갱신하지 않는다. Secondary Namenode는 Namenode의 블록정보를 합칠 때 사용하기 위한 노드이며, NameNode의 백업 노드가 아니다.
Secondary Namenode는 주기적으로 NameNode의 파일 시스템 이미지 파일을 갱신하는 역할을 하며, 이러한 작업을 체크포인트라고 한다. 그래서 Secondary NameNode를 체크포인팅 서버라고 표현하기도 한다.

DataNode
실제 데이터는 DataNode에 저장된다. 클라이언트가 HDFS에 파일을 읽거나 쓰기 위해 NameNode에게 요청을 날리면, NameNode는 어느 DataNode의 어디 블록에 파일이 있는지 알려준다. 그러면 클라이언트는 DataNode와 직접 통신하여, 파일을 읽거나 쓰게된다. 다시 말해, DataNode와 블록 위치가 정해지면 클라이언트는 NameNode와는 전혀 통신하지 않고, 해당 DataNode와 직접 통신한다.

클러스터가 처음 시작될 때, 각 DataNode에서 자신의 블록 정보를 NameNode에게 알려준다. DataNode는 주기적으로 NameNode에게 하트비트(heartbeat)와 블록의 목록이 저장된 블록 리포트(blockreport)를 보낸다. 또한 자신의 로컬 디스크에 변경사항이 발생할 때마다 NameNode에게 변경사항을 알려주게 된다.

JobTracker
클러스터 노드에게 실행되는 사용자 애플리케이션을 관리한다. JobTracker는 테스크의 할당과 모니터링을 하는데 만약 어느 노드에서 태스크가 실패하면 태스크를 다른 노드에 재할당하고 재실행하도록 한다. 일반적으로 JobTracker는 마스터 노드, 즉 NameNode가 설치된 노드에서 실행된다.

TaskTracker
테스크을 실제로 처리하는 일은 TaskTracker가 맡는다. Slavenode , 즉 Datanode에는 하나의 TaskTracker만이 존재하며, 여러개의 JVM을 생성해서 다수의 Map과 Reduce를 실행하게 된다.

2.2. 하둡1.0 동작방식

출처 : http://hortonworks.com/blog/apache-hadoop-yarn-background-and-an-overview

① 클라이언트로부터 작업요청을 받은 JobTracker는 TaskTracker별로 처리할 작업 목록을 구성한다.
② TaskTracker 는 주기적으로 heartbeat를 전송하고, JobTracker는 이 메시지의 반환 값에 처리할 작업 ID를 반환한다.
③ 작업 ID를 받은 TaskTracker 는 관련된 작업의 정보를 하둡 파일 시스템에서 가져오고, 수행할 프로그램도 하둡 파일 시스템으로부터 로컬에 저장한다.
④ TaskTracker 에서는 fork 명령을 이용해 Map 과 Reduce 를 실행하고 JobTracker에게 메세지를 전달하면서 파일에 대한 변경사항은 DataNode와 통신한다. DataNode는 다시 NameNode에게 파일 블럭에 대한 정보를 전달한다.

TaskTracker 는 동시에 태스크를 수행할 수 있으며 , 서버당 몇 개의 태스크를 동시에 수행할 것 인지 환경설정으로 설정 가능한다. 만약 TaskTracker 가 문제가 생기거나, 새로운 TaskTracker 가 추가되면 JobTracker 는 자동으로 인식하여 추가 및 제거 작업을 수행한다. 장애가 발생한 TaskTracker 의 작업은 다른 TaskTracker 에 재할당 되고 태스크를 재시작 한다.
하지만 TaskTracker 에서 장애가 발생하는 경우 HDFS와 동일하게 현재 수행 중인 태스크 모두가 실패 처리 된다.

JobTracker 는 실제로 아래의 두가지 기능을 담당하고 있다.
첫째는, TaskTracker의 리소스가 이용 가능한지, 얼마나 사용되고 있는지 등을 관리하는 리소스 관리 기능이다.
두번째는, 실제로 분석을 실행하는 MapReduce 잡을 배포하고 스케쥴링하고 모니터링하는 실행 관리 기능이다.

MapReduce 1.0 구조에서 TaskTracker는 JobTracker에서 일을 받아 와서 실행하고 실행 현황을 다시 보고하는 아주 단순한 역할을 수행한다.

3. 하둡 2.0

3.1. 하둡2.0 구성요소

출처 : http://www.edureka.in/blog/introduction-to-hadoop-2-0-and-advantages-of-hadoop-2-0/

Resource Manager

클러스터마다 존재하며, 클러스터 전반의 자원 관리와 테스크들의 스케쥴링을 담당한다 클라이언트로부터 애플리케이션 실행 요청을 받으면 그 애플리케이션의 실행을 책임질 Application Master를 실행한다. 또한 클러스터 내에 설치된 모든 Node Manager와 통신을 통해서 각 서버마다 할당된 자원과 사용중인 자원의 상황을 알 수 있으며, Application Master들과의 통신을 통해 필요한 자원이 무엇인지 알아내어 관리하게 된다.

Resource Manager내부에는 여러 개의 컴포넌트들이 존재하며, Scheduler, Application Manager, Resource Tracker 세개의 메인 컴포넌트가 있다.

① Scheduler

Node Manager들의 자원 상태를 관리하며 부족한 리소스들을 배정한다. Scheduler 는 프로그램의 상태를 검사하거나 모니터링 하지 않으며, 순수하게 스케쥴링 작업만 담당한다. 스케쥴링이란 자원 상태에 따라서 테스크들의 실행 여부를 허가해 주는 역할만 담당하며, 그 이상의 책임은 지지 않다. 즉, 프로그램 오류나 하드웨어의 오류로 문제가 발생한 프로그램을 재 시작시켜주지 않으며, 프로그램에서 요구하는 리소스(CPU, Disk, 네트워크등)에 관련된 기능만 처리한다.

② Application Manager

Node Manager 에서 특정 작업을 위해서 Application Master를 실행하고, Application Master의 상태를 관리한다. 여기서 Application Master라는 용어가 나오는데 YARN에서 실행되는 하나의 테스크를 관리하는 마스터 서버를 말한다.

③ Resource Tracker

Container가 아직 살아 있는지 확인하기 위해서, Application Master재 시도 최대 횟수, 그리고 Node Manager가 죽은 것으로 간주 될 때까지 얼마나 기다려야 하는지 등과 같은 설정 정보를 가지고 있다.

Node Manager

노드 당 한개씩 존재한다. 해당 Container의 리소스 사용량을 모니터링 하고, 관련 정보를 Resource Manager에게 알리는 역할을 담당한다. Application Master 와 Container로 구성되어 있다.

① Application Master

하나의 프로그램에 대한 마스터 역할을 수행하며, Scheduler 로부터 적절한 Container를 할당 받고, 프로그램 실행 상태를 모니터링하고 관리한다.

② Container
CPU, 디스크(Disk), 메모리(Memory) 등과 같은 속성으로 정의된다. 이 속성은 그래프 처리(Graph processing)와 MPI와 같은 여러 응용 프로그램을 지원하는데 도움이 된다. 모든 작업(job)은 결국 여러 개의 테스크로 세분화되며, 각 테스크는 하나의 Container 안에서 실행이 된다. 필요한 자원의 요청은 Application Master가 담당하며, 승인 여부는 Resource Manager가 담당한다. Container 안에서 실행할 수 있는 프로그램은 자바 프로그램뿐만 아니라, 커맨드 라인에서 실행할 수 있는 프로그램이면 모두 가능하다.

3.2. 하둡 2.0 동작방식

출처 : http://hortonworks.com/blog/apache-hadoop-yarn-concepts-and-applications/

① 클라이언트는Application Master 자체를 실행하는 필요한 데이터를 포함하는 응용프로그램을 제출한다.

② Resource Manager는 Container 할당을 책임지는 Application Master을 시작합니다.

③ Application Master가 Resource Manager에 등록되고 클라이언트가 Resource Manager과 통신할 수 있게 된다.

④ Application Master는 resource-request프로토콜을 통해 적절한 리소스의 Container 를 요청한다.

⑤ Container 가 성공적으로 할당되면, Application Master는 Container 실행 스펙를 Node Manager에게 제공하여 Container 를 실행시킨다. 실행 스펙를 일반적으로 Container 가 Application Master 그 자체와 통신하기 위해 필요한 정보를 포함하고 있다.

⑥ 응용프로그램 코드는 Container 에서 실행되고 진행률, 상태 등의 정보를 응용프로그램-스펙 프로토콜을 통해 응용프로그램의 Application Master 에게 제공한다.

⑦ 응용프로그램 실행 중 클라이언트는 상태, 진행률 등을 얻기 위해 Application Master 와 응용프로그램-스팩 프로토콜을 통해 직접 통신한다.

⑧ 일단 응용프로그램이 완료되고 모든 필요한 작업이 종료되면, Application Master 는 Resource Manager로의 등록을 해제하고 자신의 컨테이너를 다른 용도로 사용할 수 있도록 종료한다.

Resource Manager 는 기본적으로 순수하게 하둡 클러스터의 전체적인 리소스 관리만을 담당하는 심플한 모듈이다.
현재 가용한 리소스들에 대한 정보를 바탕으로 이러한 리소스들을 각 애플리케이션에 일종의 정책으로서 부여하고 그 이용 현황을 파악하는 업무에 집중한다.

Application Master 는 Resource Manager 과 협상하여 하둡 클러스터에서 자기가 담당하는 어플리케이션에 필요한 리소스를 할당받고 Node Manager 과 협의하여 자기가 담당하는 어플리케이션을 실행하고 그 결과를 주기적으로 모니터링한다. 자기가 담당하는 애플이케이션의 실행 현황을 주기적으로 Resource Manager 에게 보고한다.

Application Master 의 정확한 정의는 특정 프레임워크 (MapReduce, Storm 등 다양한 어플리케이션) 별로 잡(Job)을 실행시키기 위한 별도의 라이브러리이다. 예를 들면, 기존의 MapReduce는 MapReduce Application Master 에서, 기존의 스트리밍 처리는 스톰(Storm) Application Master 에서 각자 담당하고 책임을 지게 된다.

즉, 특정한 어플리케이션의 처리 라이브러리를 Application Master 에 올림으로써 하나의 하둡 클러스터에서 다양한 어플리케이션이 돌아 가도록 하는 것이 핵심이다. 이러한 구조의 변화에 의해서 사용자는 데이터의 속성에 맞는 다양한 어플리케이션을 처리하는 별도의 Application Master 을 만들어서 확장시킬 수 있다.

4. 하둡1.0 과 하둡2.0 비교

5. 하둡2.0을 활용한 배포판 소개

<맵알(MAPR) 하둡 플랫폼>

출처 - http://www.acrofan.com/ko-kr/commerce/content/20140623/0001030201

맵알은 하둡 클러스터 내에서 다양한 버전의 하둡 플랫폼을 동시 지원하며, 실시간 데이터 처리를 현실적으로 구현할 수 있다. 기존 MapReduce(MapReduce)는 배치 작업 형태였지만, 스파크(Spark)는 하둡에 저장되는 하둡에 저장되는 데이터를 바로 분석, 비즈니스에 능동 대처할 수 있도록 한다. 특히 MapReduce를 통해 만들어야 했던 코드를 스파크를 활용하면 짧고 간단하게 바꾸어, 크게는 수백배까지 큰 폭의 성능 향상을 얻을 수 있다.

<호튼웍스(Hortonworks) HDP 2.0>

HDP 2.0은 하둡2의 YARN 아키텍처를 포함한다. YARN 은 MapReduce2로도 불리는 리소스 관리 엔진으로, 프로세싱 엔진과 앱에 하드웨어 리소스를 분배하고 관리한다. YARN 도입으로 하둡은 MapReduce뿐 아니라 다양한 데이터처리엔진을 쉽게 플러그인할 수 있다. 호튼웍스는 HDP 2.0을 통해 여러 하둡 스택도 최신 버전으로 업데이트했다. HBASE, 피그, 스쿱, 우지, 주키퍼, 머하웃, 암바리 등이 최신버전으로 탑재됐다.