하둡 2.x 버전부터는 하둡에 많은 변화가 있었다. 그 중에 YARN이라는 자원관리자의 등장은 가장 큰 변화 가운데 하나다. YARN은 하둡 설치에서 맵리듀스 작업 외에도 다양한 애플리케이션 모델을 제공하기 때문에 확장성과 클러스터 이용률, 사용자 기민성 측면에서 이전 하둡에 비해 장점이 많다. 이번 절에서는 Yarn 의 기본적인 소개와 아키텍처, 설치 방법에 대해 알아보도록 하겠다.

Yarn 소개

기존의, 맵리듀스는 모든 애플리케이션에 적합하지는 않다. 그래프 기반 처리와 메시지 전달 인터페이스(Message Passing Interface: MPI)를 사용해 반복적 모델링을 하는 구글 프레겔(Pregel)이나 아파치 지라프(Giraph)와 같은 다른 프로그래밍 모델이 더 나은 서비스를 제공한다. 게다가 맵리듀스는 기본적으로 배치 지향적이지만, 실시간 혹은 준 실시간 처리 지원은 사용자에게 매우 중요한 요소다. 하둡의 매우 강력한 컴퓨팅 환경은 관리자에게 운영비용 절감을 통한 하둡 ROI 제고는 물론, 하둡 HDFS와 다른 스토리지 시스템 간 데이터 이동 절감을 비롯한 여러 효율성을 제고했다.
현재 하둡을 도입하거나 혹은 데이터를 중요하게 생각하는 기업에서의 고민은 점점 늘어나는 하드웨어 비용일 것이다. 실무를 담당하는 기업ㆍ기관의 데이터센터에서는 처리 성능을 향상시킬 필요가 있다. 이를 수용한 이유 때문인지 최근에는 하드웨어 가격이 내려가 더 많은 노드를 추가하길 바라고 시스템 환경 또한 그렇게 실현되고 있다. 그리고 자원을 효율적으로 관리하고 만족시키기 위해서 YARN이 등장했다. YARN은 프레임워크로서 플랫폼을 지향하기 위해 통합됐고, 기존의 하위 버전의 애플리케이션과 완전히 호환된다. 이렇게 YARN이 포함된 하둡 2.x 플랫폼의 컴포넌트는 다음 그림과 같다.

[그림 Ⅲ-1-14] YARN 컴포넌트

YARN은 분산 애플리케이션을 구현하기 위한 범용적인 자원 관리 프레임워크를 지원한다. 아파치 하둡 2.X 등장에 따라 맵리듀스는 완전히 재조명됐고, YARN에서 맵리듀스는 MRv2라고 불렸다. YARN은 기존의 맵리듀스 애플리케이션과의 완벽한 호환되고 1)거의 모든 분산 애플리케이션을 새로 지원하기 시작했다.

YARN 아키텍처

Yarn 컴포넌트

YARN은 주요한 세 가지 핵심 컴포넌트를 갖고 있다. 자원 스케줄러로서 기능만 하는 리소스매니저(ResourceManager, RM)와 사용자 애플리케이션을 실행ㆍ관장하는 애플리케이션마스터 (ApplicationMaster, AM), AM 실행 컨테이너를 관리하는 노드매니저 (NodeManager, NM)가 있다 [그림 Ⅲ-1-15]는 YARN의 새로운 아키텍처다. 새로운 기능을 추가하여 YARN은 아파치 하둡 워크플로에 새 컴포넌트를 제공했다. 이 컴포넌트는 최종 사용자를 위해 정밀하게 제어하고 하둡 에코시스템의 고급 기능을 지원한다.
YARN은 3개의 주요 컴포넌트에 의존한다. 첫 번째 가장 중요한 컴포넌트는 모든 클러스터 자원을 중재하는 리소스매니저(ResourceManager, RM)다. 리소스매니저는 2개의 파트로 플러그인이 가능한 스케줄러와 클러스터의 사용자 잡을 관리하는 애플리케이션매니저(ApplicationManager)가 있다. 두번째 컴포넌트는 해당 노드에서 사용자의 잡과 워크플로우를 관리하는 각 노드의 노드매니저(NodeManager, NM)다. 중앙 리소스매니저와 노드매니저의 그룹은 클러스터의 통합된 컴퓨팅 인프라를 관할한다. 세 번째 컴포넌트는 애플리케이션마스터(ApplicationMaster, AM)로 사용자 잡의 라이프사이클을 관리한다. 애플리케이션마스터는 사용자 애플리케이션이 있는 곳에 위치한다. YARN의 핵심 컴포넌트를 조금 더 살펴보자.

[그림 Ⅲ-1-15] 새로운 YARN 아키텍처

리소스매니저

리소스매니저(Resource Manager, RM)는 클러스터 자원을 중재하는 마스터다. 그러므로 YARN에서 실행되는 분산 애플리케이션을 관리한다. 각 노드의 노드매니저들, 각 애플리케이션의 애플리케이션마스터와 함께 동작한다.
RM은 주로 스케줄링 역할에 치중한다. 다중 애플리케이션이 자원을 사용하려면 RM의 스케줄러는 스케줄링 정책에 따라 자원을 할당할지를 결정한다. 그러나 애플리케이션의 상태는 관리하지 않는다. RM은 확장성과 대체 프로그래밍 패러다임을 지원하는 중요한 설계 요구 사항을 만족한다. RM은 실행중인 애플리케이션으로부터 자원을 역으로 다시 회수할 수도 있다. 이러한 상황은 클러스터 자원이 부족하거나 스케줄러가 이미 애플리케이션에 할당됐던 자원을 반환 요청할 때 발생한다.
RM의 실패는 클러스터 가용성에 영향을 준다. RM이 실패 상태의 클러스터를 복구하면 실행중인 AM을 재시작할 것이다. 프레임워크의 재시작 기능은 대부분 장애복구를 위한 것이며, 사용자의 파이프라인을 자동으로 복구한다.

스케줄링 컴포넌트

앞서 RM의 주요 역할이 스케줄링이라고 소개했다. YARN이 제공하는 스케줄러는 기본 스케줄러인 FIFO, Capacity, Fair 스케줄러가 있다. 또한 사용자의 스케줄러를 작성해 스케줄러 설정을 yarn-default.xml에서 설정할 수 있다. 현재 실행중인 스케줄러 확인은 http:// your_ cluster:8088/cluster/scheduler에서 할 수 있다. 여기서는 간단히 FIFO, Capacity, Fair 스케줄러를 설명한다.

FIFO 스케줄러

하둡 버전 1.X부터 존재했던 스케줄러다. FIFO(First In First Out) 의미처럼 FIFO 스케줄러는 작업 큐에서 가장 오래된 잡을 먼저 처리하는 스케줄러다. FIFO 스케줄러는 잡의 우선순위나 범위가 없다. 그러나 FIFO 스케줄러는 작은 워크로드에 대해 실용적이지만 기능면에서 훌륭하지는 않고 대용량 공유 클러스터를 사용한 경우에 문제가 발생할 수 있다.

캐퍼시티 스케줄러

캐퍼시티(Capacity) 스케줄러는 하둡 클러스터를 공유하기 위해 여러 그룹을 허용하는 스케줄러다. 캐퍼시티 스케줄러를 사용하려면 큐를 캐퍼시티 사이즈에 맞게 미리 결정해야 한다. 관리자는 큐의 한계점을 지정할 수 있으며, ACL(application control language) 수준에서 엄격하게 통제할 수 있다. 캐퍼시티 스케줄러는 또한, 각 사용자나 그룹에 최소 처리 용량을 보장해 클러스터를 공유할 수 있다. 캐퍼시티 큐의 속성을 통해 안전한 방법으로 관리자가 런타임을 변경할 수 있다. 하지만 관리자가 런타임에 큐 추가가 가능하나, 제거는 불가능하고 기존의 애플리케이션이 완료될 때까지 런타임 큐 중지도 불가능하다.
캐퍼시티 스케줄러는 런타임 애플리케이션의 기본 값보다 더 큰 메모리 자원의 요구사항을 선택적으로 지정할 수 있다. 노드매니저와 교섭해 가장 적합한 노드에 컨테이너를 배치한다. 그럼 언제 캐퍼시티 스케줄러를 사용하는 것이 좋을까? 캐퍼시티 스케줄러는 사용자와 그룹 간 워크로드가 투명하게 잘 알려졌을 경우 가장 잘 동작한다. 이런 캐퍼시티 스케줄러에 FIFO와 유사한 계층형 스케줄러를 사용할 수 있다.

페어 스케줄러

캐퍼시티 스케줄러를 야후가 내놓고 호튼웍스가 발전시켰다면, 페어(Fair) 스케줄러는 클라우데라가 발전시켰다. 페어 스케줄러는 모든 애플리케이션에서 시간에 따라 자원을 균등하게 공유ㆍ할당하는 방법이다. 페어 스케줄러는 모든 애플리케이션을 큐에 소속되게 만든다. 큐에서 컨테이너는 가장 적은 자원이 있는 애플리케이션을 할당한다. 기본적으로 Default라는 단일 큐를 공유한다.
애플리케이션은 구체적으로 컨테이너 자원을 요청하여 큐에 제출한다. 페어 스케줄러는 더 많은 컨테이너를 갖는 큐에 가중치를 주고, 최소/최대 공유와 같은 정책을 지원한다. 그러나 기본적인 아이디어는 가능한 한 균등하게 자원을 공유하는 것이다. 페어 스케줄러에서 단일 애플리케이션이 작동하고 있을 때, 해당 애플리케이션은 (필요한 경우) 전체 클러스터를 요청할 수 있다. 추가 애플리케이션이 제출되면 사용하지 않는 자원이 새로운 애플리케이션에 균등하게 할당되고, 각 애플리케이션은 거의 동일한 자원을 사용한다.
균등한 공유를 제공하는 것 외에 페어 스케줄러는 최소 보장 공유로 어떤 사용자와 그룹 혹은 애플리케이션이 항상 충분한 자원을 유용하게 얻을 수 있게 큐에 할당한다. 큐에 대기 중인 애플리케이션이 있으면 큐는 최소 공유를 한다.
페어 스케줄러는 컨테이너의 요구 사항에 따라 메모리의 가변 양과 스케줄을 요청할 수 있다. 애플리케이션의 메모리 부족 때문에 바로 사용할 수 없는 컨테이너가 부여되면, 애플리케이션은 컨테이너를 예약하고 다른 애플리케이션은 컨테이너가 해제될 때까지 사용할 수 없다. 총 예약된 메모리 수치는 RM UI에서 알 수 있다. 수치가 클수록 새로운 잡은 큐를 얻으려는 시간이 더 걸릴 수 있다.
페어 스케줄러의 새로운 기능은 계층적 큐를 지원하는 것이다. 계층적 큐의 용도 중 하나는 그룹의 경계와 계층을 표현하는 것이다. 예를 들어 부서별로 구조를 결정할 수 있으면서 큐마다 실행 시간에 따른 특성을 부여할 수도 있다.

컨테이너

컨테이너의 기본 개념은 램, CPU 코어, 디스크 등의 물리적 자원 그 자체를 말하며 단일 노드에서도 여러 컨테이너가 존재할 수 있다. 따라서 컨테이너는 지정 클러스터의 단일 노드의 자원(메모리, CPU)을 나타낸다. NM은 컨테이너를 감독하고 RM은 컨테이너를 스케줄링한다. AM이 시작되면, AM은 RM과 교섭을 통해 컨테이너를 요청한다.

노드매니저

노드매니저(NodeManager, NM)는 하둡 클러스터의 개별 컴퓨팅 노드, 즉 인프라를 관리한다. 역할은 RM과 최신의 상태를 공유하고 애플리케이션 컨테이너의 생명주기를 관리하며, 개별 컨테이너 자원을 모니터링하고 노드의 상태 등을 관리한다. 하둡 시작 시에 NM은 RM에 등록한 다음, 자신의 상태를 하트비트를 통해 보내고 RM의 명령을 기다린다. 즉 NM의 RM이 NM에 할당된 애플리케이션 컨테이너를 관리하는 것이다. NM은 컨테이너의 할당을 확인하고 컨테이너 환경을 설정한다. NM은 RM의 명령에 따라 컨테이너를 종료한다.

애플리케이션마스터

애플리케이션마스터(ApplicationMaster, AM)는 쉽게 클러스터의 애플리케이션을 실행ㆍ조정하는 데몬이다. 애플리케이션마다 애플리케이션을 소유하는 AM이 존재한다. AM은 RM과 컨테이너 할당과 같은 자원 교섭을 하고 태스크 실행을 하며, NM과 함께 모니터링을 한다. AM이 관장하는 애플리케이션은 그저 애플리케이션일 뿐이다. AM은 맵리듀스, MPI 등을 특별한 오브젝트가 아닌 하나의 애플리케이션으로서 실행한다.

YARN에서 자원할당 프로세스

YARN에서 자원할당 프로세스는 [그림 Ⅲ-1-16]과 같다.

[그림 Ⅲ-1-16] 클라이언트가 RM에게 자원요청

클라이언트는 애플리케이션을 만들어 RM에게 요청하면, RM은 애플리케이션 ID로 응답한다. 이때 클라이언트는 RM으로부터 발행받은 애플리케이션 ID와 함께 사용자, 큐, 잡파일, 보안 토큰 등의 여러 정보를 다시 컨테이너 실행 컨텍스트를 통해 전달한다. 이 전달 메커니즘을 통해 RM은 NM에게 자원을 할당하라고 요구한다. NM이 컨테이너를 요청해 컨테이너를 할당 받아 애플리케이션은 동작하게 된다. 동작하는 동안 지속적인 하트비트로 RM, NM, AM 간 통신이 [그림 Ⅲ-1-17]처럼 이루어진다.

[그림 Ⅲ-1-17] RM, NM, AM 간의 통신

YARN에서 자원 정의와 관리 매커니즘

YARN은 운영체제의 프로세스에 매핑돼 컨테이너를 실행한다. 이때 컨테이너에는 실행에 필요한 의존적인 파일이 있다. 이 파일들은 YARN 시스템이 시작할 때 꼭 필요한 파일이다. 그리고 애플리케이션이 시작될 때도 마찬가지다. 이때 해당 파일이 어디에 있는지, 논리적으로 내부의 가시성은 어떤지 기술해야 한다. 라이브러리나 클래스 파일이 위치를 모르면, 당연히 프로그램은 실행되지 않을 것이기 때문이다.
컨테이너가 시작되면, AM은 컨테이너를 위해 컨테이너가 필요한 파일들을 명시할 수 있도록 지역화(Localization) 작업을 한다. 이러한 자원 지역화는 노드매니저가 사용자의 애플리케이션에 제공하는 중요한 서비스다. 이러한 자원 지역화에 대한 정의를 살펴본다.

지역화

로컬 파일시스템에 원격지의 자원을 복사하고 다운로드하는 과정이다. 자원은 로컬 머신에 복사된 이후에 로컬에 접근할 수 있다.

① 로컬리소스

컨테이너 실행에 필요한 파일ㆍ라이브러리를 나타낸다. 지역화 서비스는 실행 이전에 자원 지역화를 담당한다. 로컬 리소스는 다음과 같다.

• URL: 로컬 리소스를 다운로드해야 할 원격 위치
• 크기: 로컬 리소스의 바이트 크기
• 타임스탬프: 컨테이너 시작 전에 원격 파일 시스템 자원의 최종 수정 본
• 유형: 자원의 구체적인 유형(파일, 아카이브, 패턴)
• 패턴: 유형이 패턴인 경우, 아카이브로부터 항목을 추출하기 위한 패턴
• 로컬자원 가시성: 가시성은 PUBLIC, PRIVATE 혹은 APPLICATION 중 하나

② 지역화 과정

[그림 Ⅲ-1-18] 노드매니저에서 리소스 지역화 과정

아파치 하둡 YARN 설치

아파치 하둡 2.X는 다음과 같은 두 가지 핵심 컴포넌트가 있다.

• 데이터를 저장하기 위한 하둡 분산 파일 시스템(HDFS)
• 데이터 처리를 위해 구현해야 하는 애플리케이션의 하둡 YARN

그 밖의 피그나 하이브와 같은 에코시스템은 두 가지 핵심 컴포넌트를 완전히 설치한 후에 추가해 사용할 수 있다. 최소 권장 설치환경은 램 2GB, 2GB의 하드 디스크 여유공간이면 충분하다. 하지만 벤더 샌드박스와 설치관리자를 통한 설치는 4GB 램이 필요하다. 필자 또한 4GB 램을 권장한다. 여러 노드에서 설치하고 GUI 환경에서 하려면 클라우데라의 Cloudera Manager 혹은 호튼웍스의 Ambari등을 이용하기를 권고한다. 여기서는 단일 노드에서 설치할 것이다. 운영체제는 여러 리눅스 중에서도 CentOS-6.5 버전을 사용할 것이다.

Yarn 설치 및 환경설정

아파치 하둡 다운로드

root 권한으로 다음을 실행한다.

JAVA_HOME 설정

하둡 2.X에서 권장하는 자바 버전은 http://wiki.apache.org/hadoop/HadoopJavaVersions에서 확인할 수 있다. 리눅스에 깔려 있는 OpenJDK를 사용할 수도 있으나, 기본적인 자바는 오라클에서 릴리즈한 것을 권장한다. 자바를 설치했다면 다음과 같은 내용을 글로벌 환경으로 설정한다.

사용자와 그룹 생성

분리된 계정으로 다양한 데몬을 실행하는 것이 좋다. hadoop 그룹에 yarn, hdfs, mapred 3가지 계정을 생성한다.

데이터와 로그 디렉터리 생성

하둡은 다양한 데이터와 로그 디렉터리에 대한 다양한 권한이 필요하기 때문에 다음과 같이 nn, snn, dn으로 3가지 디렉터리를 생성한다.

YARN이 설치된 루트 디렉터리로 이동해 로그 디렉터리를 만들고 소유권과 그룹을 다음처럼 설정한다.

core-site.xml 설정

하둡 경로(/opt/yarn/hadoop-2.6.0)를 기준으로 /etc/hadoop/core-site.xml 파일을 수정한다. 없으면 만들면 된다. 파일 내용을 다음과 같이 한다.

hdfs-site.xml 설정

이번에는 /etc/hadoop/hdfs-site.xml 파일을 수정한다. 단일 노드에서 파일 블록을 굳이 복제할 필요가 없기 때문에 dfs.replication의 값은 1로 설정한다. hdfs-site.xml에 이전에 생성한 네임노드와 보조 네임노드, 데이터노드의 데이터 디렉터리를 지정한다. 데이터를 저장하기 위해 HDFS의 다양한 컴포넌트가 사용하는 디렉터리다. 다음과 같이 구성한다.

mapred-site.xml 설정

하둡 버전 2.X의 새로운 설정 옵션은 mapreduce.framework.name 속성이다. 이것은 맵리듀스 프레임워크의 이름을 지정한다. 맵리듀스 프레임워크의 이름을 “yarn”이라고 지정한다. 다음과 같은 내용을 /etc/hadoop/mapred-site.xml에 작성한다.

yarn-site.xml 설정

yarn.nodemanager.aux-services 속성은 mapreduce.shuffle이라는 보조 서비스를 사용할지를 노드매니저에 알려준다. 보조 서비스를 구현하는 노드매니저에 전달한 후, 서비스를 구현하는 수단으로서 클래스 이름을 전달한다. 이런 특정 설정을 통해 어떤 방식으로 셔플이 일어날지를 맵리듀스에게 알려준다. 기본적으로 비 맵리듀스 잡에 대해서는 노드매니저가 데이터를 셔플하지 않기 때문에, 맵리듀스 서비스를 설정할 필요가 있다. /etc/hadoop/yarn-site.xml 파일에 다음과 같은 내용으로 수정한다.

Java heap 메모리 설정

하둡 설치는 각 하둡 프로세스에 대해 힙 메모리 크기를 결정하는 환경 변수를 /etc/hadoop/*-env.sh라는 파일에 정의한다. 대부분 프로세스의 힙 메모리 값은 1GB다. 단일 노드에서 사용하기 때문에 많은 메모리를 사용할 필요는 없다. 따라서 다음과 같은 설정으로 다운그레이드한다. “#”이 있다면 주석이므로 제거한다. 먼저 /etc/hadoop/hadoop-env.sh 파일을 수정한다.

다음과 같이 /etc/hadoop/mapred.sh를 수정한다.

마지막으로 다음을 반영하기 위해 /etc/hadoop/yarn-env.sh 파일을 수정한다.

Yarn 실행

HDFS 포맷

HDFS 네임노드를 시작하려면 포맷을 해야한다. 네임노드 서비스는 파일시스템의 모든 메타데이터를 추적하고 포맷 프로세스는 초기에 /etc/hadoop/hdfs-site.xml에서 dfs.namenode.name.dir 속성 값에 할당한 값(예를 들어, /var/data/hadoop/hdfs/nn)을 사용한다. 일반적으로 “hdfs” 사용자 계정으로 네임노드 디렉터리를 포맷한다. 하둡 설치 기준으로 bin 디렉터리로 이동해 다음을 실행한다.

포맷이 제대로 됐다면 메시지의 끝 부분에 다음과 같은 것을 볼 수 있다.

HDFS 서비스 시작

bin 디렉터리에서 hdfs 사용자로서 다음을 실행한다.

앞의 명령어는 다음과 같은 것을 보여준다.

보조 네임노드와 데이터 노드도 같은 방식으로 시작한다.

정상적인지 확인하기 위해 모든 서비스가 실행 중인지 확인하는 명령어 jps를 실행한다(실제 PID(자바 프로세스 ID) 값은 아래에 나온 것과는 다를 수 있다).

프로세스가 시작되지 않았다면 로그 파일을 조사해야 한다. 모든 하둡 서비스는 hadoop-daemon.sh 스크립트를 사용해 중지시킬 수 있다. 데이터노드 서비스를 중지하려면 /opt/yarn/hadoop-2.6.0/sbin 디렉터리에서 hdfs 사용자로 다음과 같이 입력한다.

네임노드와 보조 네임노드도 같은 방식으로 한다.

YARN 서비스 시작

HDFS 서비스와 함께 YARN 서비스도 시작한다. 한 개의 리소스매니저와 한 개의 노드매니저는 yarn 계정으로 접속하여 시작해야 한다.

서비스가 실행되고 있는지 확인하려면 jps 명령어를 실행한다.

HDFS 서비스와 유사하게 YARN 서비스는 다음 명령으로 중지시킬 수 있다.

웹 기반 서비스 체크

http://localhost:50070를 실행하면 YARN 기반의 HDFS상태에 관한 웹 서비스를 확인할 수 있다.

[그림 Ⅲ-1-19] HDFS 파일 시스템의 웹페이지

http://localhost:8088을 실행하면 YARN에서 실행되는 모든 애플리케이션 상태 웹 서비스를 확인할 수 있다.

[그림 Ⅲ-1-20] YARN 리소스매니저의 웹페이지

샘플 예제 실행

정상적으로 설치됐는지 확인하려면 샘플로 제공한 PI 애플리케이션을 실행해 보자. 이 PI 애플리케이션은 준 난수 몬테 칼로(quasi-Monte Carlo) 방법과 맵리듀스를 사용한 것이다. 사용자를 hdfs로 변경하고 다음과 같이 실행한다.

다음과 같이 실행하면 전체 예제를 볼 수 있다. 각 예제의 옵션 목록을 보려면, 예제 이름을 명령어에 추가해야 한다.

YARN의 설치와 개념, 예제를 애플리케이션 규모가 큰 클러스터 제품 없이 학습할 수 있었다. 구성의 많은 부분이 단일 노드에서 설치를 하기 위해 간소화됐음을 고려해야 한다. 다수의 노드, 즉 클러스터 기반에 설치하려면 많은 스크립트를 작성하는 것보다 클라우데라 매니저나 Ambari를 사용해 설치하는 것이 좋다.