YARN REF

지난 2회에 걸쳐 YARN에 대해 살펴보았습니다. 처음에는 하둡 2.0을 한대의 서버에 의사분산모드로 설치하고 예제 맵리듀스 프로그램을 실행해보았습니다. 그 다음 회에서는 YARN의 아키덱쳐에 대해 간략하게 살펴보았습니다. 

1회: 하둡 2.0 (YARN) 설치 방법 
2회: YARN이란?

이번 회에서는 YARN의 동작방식에 대해 좀더 자세히 살펴보겠습니다. 먼저 리소스 매니저, 애플리케이션 마스터, 노드 매니저, 컨테이너에 대해 간단히 다시 정리해보도록 하겠습니다.

리소스 매니저

앞서 설명했듯이 클러스터마다 존재하는 리소스 매니저는 클러스터 전반의 자원관리와 잡들의 스케줄링을 담당합니다. 그런데 여기서 스케줄링이라 함은 자원요청에 맞춰 잡을 실행해도 된다는 허가를 해준다는 의미이지 이 잡의 실행여부를 끝까지 책임진다는 것은 아닙니다(이는 뒤에서 설명할 애플리케이션 마스터의 역할입니다). 이 스케줄러의 경우에는 하둡 1.0처럼 플러그인 구조를 갖고 있어서 필요하다면 다른 형태의 스케줄러를 만들어 사용할 수 있습니다. 뒤의 “YARN 실행과정”에서 좀더 자세히 설명하겠지만 리소스 매니저는 클라이언트로부터 애플리케이션 실행 요청을 받으면 그 애플리케이션의 실행을 책임질 애플리케이션 마스터를 실행해줍니다.

 

리소스 매니저는 클러스터내의 서버마다 설치된 노드 매니저(뒤에서 설명합니다)와 통신을 통해 각 서버마다 할당된 자원과 사용중의 자원의 상황을 알 수 있으며 애플리케이션 마스터들과의 통신을 통해 필요한 자원이 무엇인지 어떤 자원들이 더 이상 필요가 없는지등을 알아내서 관리하게 됩니다.

 

< 리소스 매니저의 웹인터페이스 화면 >

리소스 매니저는 웹 브라우저로 접근할 수 있으며 이 웹인터페이스의 포트번호는 기본값이 8088입니다. 이 번호를 바꾸고 싶다면 이는 yarn.resourceman­ager.webapp.address라는 파라미터로 yarn-site.xml에서 변경해줄 수 있습니다. 참고로 YARN 클라이언트들이 리소스매니저와 통신을 할때 사용되는 기본 포트번호는 8032이며 이는 yarn.resourceman­ager.address라는 프로퍼티를 통해 변경가능합니다.

 

노드 매니저

 

노드 매니저는 하둡 1.0으로 치면 태스크트래커에 해당한다고 볼 수 있는데 클러스터 내의 서버마다 하나씩 실행됩니다. 노드 매니저는 노드내의 자원을 관리하고 이를 리소스 매니저에게 계속 보고합니다. 그리고 하나의 이상의 컨테이너들을 것을 관리하는데 구체적으로 컨테이너의 자원사용상태(CPU와 메모리)을 모니터하고 컨테이너가 종료될때까지 계속  그 상태를 트랙합니다. 바로 뒤에서 다시 설명하겠지만 컨테이너는 하나의 JVM에 해당하며 이 안에서는 어떤 자바프로그램도 실행할 수 있고 원한다면 셸 명령어를 실행할 수도 있습니다.컨테이너는 하둡 1.0으로 보면 태스크마다 할당된다고 보면 가장 비슷할 듯 합니다.

 

< 노드 매니저의 웹인터페이스 화면 >

 

노드 매니저는 웹 브라우저로접근할 수 있으며 이 웹인터페이스의 포트번호는 기본값이 50060입니다. 이 번호를 바꾸고 싶다면 이는 yarn.nodeman­ager.webapp.address라는 파라미터로 관리되며 앞서 리소스 매니저와 마찬가지로 yarn-site.xml에서 변경해줄 수 있습니다.

 

컨테이너

모든 잡은 결국 여러 개의 태스크로 나눠지며 각 태스크는 하나의 컨테이너안에서 실행이 됩니다.앞서 이야기한 것처럼 컨테이너는 결국 하나의 JVM에 해당하며 현재로는 요청된 메모리 크기(자바힙)에 의해 컨테이너의 수가 결정됩니다. 

그럼 누가 어떤 잡을 실행하는데 필요한 자원(결국 컨테이너들)을 요청하고 누가 이 요청의 허락여부를 결정할까요? 뒤에서 다시 설명하겠지만 (그리고 사실 앞에서 설명되었지만) 필요한 자원의 요청은 애플리케이션 마스터에 의해 이뤄지고 허락 여부는 리소스 매니저에 의해 결정됩니다. 컨테이너안에서 실행할 수 있는 프로그램은 단순히 자바 프로그램뿐만이 아니고 커맨드라인에서 실행할 수 있는 프로그램이라면 무엇이든 실행가능합니다. 물론 어떤 프로그램이든 실행할 수 있으려면 그 프로그램의 실행에 필요한 환경이 이미 설치되어있어야 하는데 이를 준비하는 것은 애플리케이션 마스터의 역할입니다 (부트스트래핑이라고 부르는 것이 바로 그 준비과정입니다). 컨테이너내에서 특정 프로그램을 실행하기 위해서 애플리케이션 마스터가 컨테이너에게 넘겨야할 정보는 다음과 같습니다.

• 프로그램의 실행을 위한 커맨드라인 명령어
• 환경변수들
• 프로그램 실행전에 미리 설치되어야하는 것들 (보조 데이터파일, jar과 같은 라이브러리 파일들, …)
• 보안관련 토큰들

위에 보면 마지막에 보안관련 토큰들이 있습니다. 그 이유는 누군가 거짓으로 애플리케이션 마스터를 사칭하는 것을 막기 위해서입니다.  

애플리케이션 마스터

 

이게 실제 우리가 YARN위에서 실행시키는 잡마다 하나씩 존재하게 됩니다.이 애플리케이션 마스터가 결국 해당 잡에 필요한 리소스(최종적으로는 컨테이너가 됩니다)를 리소스 매니저로부터 받아(리소스 매니저를 통해) 노드매니저들로 태스크들을 분담해서 실행(태스크들은 결국 앞서 이야기한 컨테이너안에서 실행되는것이죠)하는 역할을 담당합니다. 

잡의 실행이 종료되면 해당 애플리케이션 마스터는 없어집니다. 애플리케이션 마스터는 하나의YARN 클러스터안에 몇개가 동시에 실행 중일 수 있으며 각기 다른 타입의 애플리케이션일 수 있습니다. 예를 맵리듀스 프레임웍 애플리케이션이 실행되면서 동시에 Storm 애플리케이션이 실행되고Giraph 기반의 애플리케이션이 실행될 수 있다는 것입니다 (물론 클러스터의 용량이 허용하는 한다는 전제에서 말입니다).

YARN 실행과정

자 그럼 전체 웍플로우를 다시 한번 정리해보겠습니다.

1. YARN 클라이언트(YARN API를 사용)가 리소스 매니저에게 잡 실행을 요청한다

  - 정확히는 잡을 실행할 애플리케이션 마스터 코드를 리소스 매니저에게 넘긴다.

2. 리소스 매니저는 노드 매니저를 하나 랜덤하게골라 그 노드위에서 애플리케이션 매니저를 실행한다. 정확히는 그 노드 매니저가 존재하는 서버상의 컨테이너 하나가 실행되어 그 안에서 애플리케이션 마스터가 실행된다.

3. 애플리케이션 매니저는 리소스 매니저에게 잡 실행에 필요한 컨테이너들의 할당을 요청한다. 즉모든 리소스 요청은 리소스 매니저를 통해야한다. 나중에 애플리케이션매니저들은 이 컨테이너들을 리소스 매니저에게 되돌려 주어야한다.

4. 리소스 매니저는 애플리케이션 매니저를 대신하여 노드매니저들에게 태스크 실행을 명령한다. 각 태스크는 각기 하나의 컨테이너안에서 실행된다.

YARN 코드 작성

그러면 YARN상에서 동작하는 코드를 작성한다는 것은 무슨 의미일까요? YARN API를 이용해야하는데 그게 결코 쉽지 않습니다. 하둡 2.0을 설치하면  맵리듀스 프레임웍(버전 2.0) 이외에도 YARN API를 사용해 예제로 만든 DistributedShell이란 예제프로그램이 같이설치됩니다. 이를 보면 YARN 위에서 돌아가는 프로그램을 어떻게 만들수 있을지 예를 볼 수 있습니다. YARN의 약점은 다음과 같습니다. 

• 굉장히 복잡하다
• 프로토콜이 굉장히 로우레벨이다. 즉 배우는데 시간이 걸린다. lots of boiler plate code is needed
• 클라이언트는 필요한 모든 JAR 파일들을 HDFS에 준비해두어야 한다
• 클라이언트는 필요한 환경과 클래스 패스등을 설정해야한다.

• 애플리케이션이 끝난 후에야 로그가 남는다.
• 오랫동안 도는 애플리케이션이나 버그로 인해 죽는 애플리케이션의 경우에는 문제가 된다
• 애플리케이션 마스터가 새로운 SPOF(Single Point Of Failure)이다
• 컨테이너와 애플리케이션 마스터간에 직접적인 통신 메커니즘이 바로 지원되지 않는다.
• 위와 같은 이유들로 인해 디버깅이 쉽지 않다.

그런 이유로 인해 YARN API를 사용하기 쉽게 만들어주는 아파치 오픈소스 프로젝트가 만들어졌습니다. 그 이름이 위브(WEAVE)라는 것인데 Continuuity라는 회사가 주축이 되어 진행되고 있습니다 (여담으로 이 회사의 아키텍트인 Andreas Neumann이 야후때 몇가지 프로젝트를 같이 했었던 전 직장동료입니다). 위브의 특징은 다음과 같습니다.

• 오픈소스 아파치 프로젝트(http://continuuity.github.io/weave/)
• YARN상에서 애플리케이션 마스터의 개발(빌드,디버깅, 실행)을 쉽게 해준다.
• DSL을 이용해 애플리케이션을 정의
• API를 이용해 컨테이너 태스크 코드를 작성
• 서비스 발견, 로깅, 모니터링, 메트릭스 수집과 관련된 기능 제공
• 내부적으로 zookeeper를 사용하며 자체 애플리케이션 마스터와 컨테이너를 제공한다.

물론 기존의 자바 기반의 맵리듀스 프로그램이나 Pig/Hive등을 사용하는 경우라면 위에서 언급한 것처럼 YARN API를 사용해서 프로그래밍을 할 필요가 없습니다 (소스레벨에서 호환이 되기 때문에 자바 프로그램을 재컴파일하던지 아니면 Pig/Hive자체를 YARN용으로 재컴파일해야할 수는 있습니다).

출처 - http://cafe.naver.com/cloudbigdata/181

본 문서는 CDH4 시험 공부용으로 시작한 번역 작업으로 Hortonworks의 Arun Murthy님의 YARN 시리즈 글 중 일부를 번역한 것입니다. 번역한 문서 목록은 다음과 같습니다.

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

• http://hortonworks.com/blog/apache-hadoop-yarn-resourcemanager/

• http://hortonworks.com/blog/apache-hadoop-yarn-nodemanager/

목차

아파치 하둡 얀 - 컨셉 & 응용프로그램

리소스매니저

어플리케이션마스터

자원 모델

리소스리퀘스트 와 컨테이너

컨테이너 시작동안의 컨테이너 특성

얀-자세한 설명

아파치 하둡 얀 - 리소스매니저

리소스매니저 구성 요소

결론

아파치 하둡 얀 - 노드매니저

노드매니저 구성요소

핵심 기능 설명

결론

아파치 하둡 얀 - 컨셉 & 응용프로그램

YARN은 분산 응용프로그램을 관리하는 데 중요한 시스템이다. YARN은 클러스터내의 모든 가용한 자원을 관리하는 중앙 ResourceManager와 리소스매니저로부터 지시를 받고 단일 노드안에서 자원을 관리할 책임이 있는, 노드 당 필요한 NodeManager로 구성되어 있다.

리소스매니저

YARN에서 리소스매니저는 기본적으로(우선적으로) 순수한 스케줄러이다. 리소스매니저는 시스템에서 서로 경쟁하는 응용프로그램들간 사용가능한 자원을 엄격히 제한한다. 얀은 캐파시티 개런티, 평등성과 SLA와 같은 다양한 제약조건들을 지키며 클러스터 유틸라이제이션(모든 자원을 매 시각 전부 사용하고있는)을 최적화한다. 서로다른 제약 규칙을 허용하기 위해 리소스매니저는 필요에 따라 캐파시티나 페어니스 스케쥴링 같은 다양한 알고리즘을 사용할 수 있는 플러거블 스케쥴러를 가지고 있다.

어플리케이션마스터

얀과 하둡맵리듀스 시스템간의 대부분이 유사하다. 그러나 가장 큰 차이점은 어플리케이션마스터의 개념이다. 사실상 어플레키이션마스터는 프레임워크-특화된 라이브러리의 인스턴스이며, 리소스매니저와 자원들을 협상할 책임이 있으며 컨테이너를 실행하고 소비하는 자원을 모니터링하기 위해 노드매니저와 함께 동작한다. 어플리케이션마스터는 리소스마스터로부터 적절한 자원 컨테이너를 협상하고 상태를 추적하고 진행상황을 모니터링할 책임을 가진다. 어플리케이션마스터는 얀이 다음의 핵심 성향을 드러내보이는 것에 기여한다.

• 스케일: 어플리케이션마스터는 기존 리소스매니저의 대부분의 기능을 제공하기 때문에 전체 시스템이 더욱 드라마티컬리 확장될 수 있다. 테스트에서 이미 모던 하드웨어로 구성된 10,000개의 노드 클러스터를 심각한 문제 없이 성공적으로 시뮬레이트하였다. 이것이 리소스매니저를 순수한 스케쥴러로 디자인하는 것을 선택한 핵심이유 중 하나이다. 리소스매니저는 자원들을 장애-허용가능하게 제공하도록 시도하지 않는다. 우리는 이 기능을 애플리케이션마스터 인스턴스의 주요 책임으로 옮겼다. 추가로 응용프로그램마다 애플리케이션마스터의 인스턴스가 있기 때문에 애플리케이션마스터 자체는 클러스터에서 일반적인 병목이 되지 않는다.

• 개방: 모든 응용프로그램 프레임워크 특화 코드를 애플리케이션마스터로 옮긴 것은 시스템을 일반화하여 이제는 맵리듀스, MPI, 그래프 프로세싱등의 다양한 프레임워크를 지원할 수 있다.

핵심 얀 설계의 결정 몇가지는 다음과 같다.

• 응용프로그램 프레임워크 개발자들에게 충분한 유연성과 파워를 주기 위해 모든 복잡도(가능성을 확장하기 위한)를 어플리케이션마스터로 옮긴다.

• 전적으로 사용자-코드이기 때문에 애플리케이션마스터를 신뢰하지 않는다. 예) 애플리케이션마스터는 특권 서비스가 아니다.

• 얀 시스템(리소스매니저와 노드매니저)는 장애가 있거나 악의적인 애플리케이션마스터로부터 스스로를 보호해야만 하고, 애플리케이션마스터에게 어떠한 일이 있어도 자원을 보장해야 한다.

실제로 모든 응용프로그램은 자신만의 애플리케이션마스터 인스턴스를 가진다는 것을 기억하면 유용하다. 그러나 애플리케이션마스터가 응용프로그램들의 집합(맵리듀스 작업을 관리하기 위해 Pig, Hive를 위한 애플리케이션마스터)을 관리하도록 구현하는 것이 완벽하게 실현가능하다. 추가로 이러한 개념은 스스로의 응용프로그램을 관리해야 하는 오래 동작하는 서비스들(얀에서 가상의 HBaseAppMaster를 통하여 HBase를 시작하는 것)을 관리하기 위해서 확장될 수 있다.

자원 모델

얀은 응용프로그램을 위하여 매우 보편적인 자원 모델을 지원합니다. 응용프로그램은 (애플리케이션마스터를 통하여) 다음의 매우 특화된 요구들을 바탕으로 자원들을 요청할 수 있습니다.

• 자원-이름(호스트이름, 랙이름 - YARN-18을 통하여 좀 더 복잡한 네트워크 토폴로지를 지원할 수 있도록 작업중입니다.)

• 메모리(MB 단위)

• CPU(현재는 코어수)

• 미래에 디스크/네트워크 I/O, GPU등의 더 많은 자원 타입을 추가할 것입니다.

리소스리퀘스트 와 컨테이너

얀은 각각의 응용프로그램이 (애플리케이션마스터를 통해서) 클러스터의 자원을 공유하고, 안전하고 다중-임대하는 방법으로 활용하도록 설계되었다. 또한 효과적으로 스케쥴하고 데이터 접근을 최적화(예: 데이터의 이동을 감소)하기 위해 클러스터 토폴로지를 알고 있다. 이러한 목표에 도달하기 위해 중앙 스케쥴러(리소스매니저에 있는)은 클러스터에 있는 모든 응용프로그램들을 대상으로 더 좋은 스케쥴링 결정을 하기위해 응용프로그램의 요청에 대해서 광범위한 정보를 가지고 있다. 이것이 우리를 리소스리퀘스트와 그 결과인 컨테이너를 생각하게 했다. 근본적으로 응용프로그램은 리소스 요구를 만족시키기 위해 애플리케이션마스터를 통하여 특정한 리소스리퀘스트를 요청할 수 있다. 스케쥴러는 애플리케이션마스터에 의해 발생한 초기 리소스리퀘스트에 있는 요구사항을 만족하는 컨테이너를 허가함으로서 리소스 리퀘스트에 응답한다.

먼저 리소스리퀘스트에 대하여 알아보자. 리소스리퀘스트는 다음의 형태로 되어 있다:

<리소스-이름, 우선순위, 리소스-요구사항, 컨테이너의 개수>

더 잘 이해하기 위해 리소스리퀘스트의 각 부분에 대하여 알아보자.

• 리소스-이름은 호스트네임이거나 렉네임 또는 *로 관계없음을 나타낸다. 미래에는 호스트에 있는 가상머신을 위한 더욱 복잡한 토폴로지 또는 복잡한 네트워크를 지원할 것이다.

• 우선순위는 이 요청의 응용프로그램 내부의 우선순위이다.(강조하는데, 이것은 다중 응용프로그램에서의 우선순위가 아니다.)

• 리소스-요구사항은 메모리, cpu 등의 요구되는 능력이다.(얀이 개발되는 중에는 메모리와 cpu만 지원한다.)

• 컨테이너의 개수는 요구되는 컨테이너들의 수이다.

이제 컨테이너에 대하여 살펴보자.

근본적으로 컨테이너는 리소스매니저가 특정한 리소스리퀘스트를 승인한 성공적 결과인 리소스 할당이다. 컨테이너는 응용프로그램에게 특정한 호스트에 있는 특정한 양의 자원을 사용할 수 있는 권리를 승인한다. 애플리케이션마스터는 컨테이너를 얻어야 하며, 태스크를 시작하기 위한 자원으로 사용하기 위해 컨테이너가 위치한 호스트를 관리하는 노드매니저에게 제출해야 한다.당연히 컨테이너 할당은 그 애플리케이션마스터가 클러스터에서 할당을 속일 수 없도록 안전하게 검증된다.

컨테이너 시작동안의 컨테이너 특성

이상에서 설명한 것과 같이, 컨테이너는 그저 클러스터에서 특정 노드(노드매니저)에 있는 특정한 양의 자원을 사용할 수 있는 권리이기 때문에 애플리케이션마스터는 컨테이너를 실제로 실행(런치)하기 위해서 상당히 많은 정보를 노드매니저에게 제공해야만 한다. 얀은 기존의 하둡 맵리듀스와는 틀리게 응용프로그램이 어떠한 프로세스든 실행하도록 허용하며, 자바 응용프로그램에 국한되지도 않는다.

얀 컨테이너 실행 API는 플랫폼 독립적이며 다음의 특징을 가지고 있다.

• 컨테이너에 프로세스를 실행하기 위한 커맨드 라인

• 환경 변수

• jar 파일이나 공유 객체, 보조 데이터 같은 실행에 있어서 머신에 필요한 로컬 리소스

• 보안 관련 토큰

이것이 애플리케이션마스터가 컨테이너를 실행하기 위해서 간단한 쉘 스크립트부터 완전한 가상머신에 서 동작하는 유닉스/윈도우상의 C/Java/Python 프로세스들을 노드매니저와 함께 동작하는 것을 허용한다.

얀-자세한 설명

이상의 개념들을 알고 있는 상태에서 응용프로그램이 개념적으로 어떻게 동작하는지 아는 것은 유용하다.

응용프로그램 실행은 다음의 단계를 거친다:

1. 응용프로그램 제출

2. 응용프로그램을 위한 애플리케이션마스터 인스턴스 생성(bootstrap)

3. 애플리케이션마스터 인스턴스에 의한 응용프로그램 실행 관리

응용프로그램 실행 순서(순서는 다음의 그림에 그려져 있습니다.)에 대하여 알아봅시다.

1. 클라이언트 프로그램이 응용프로그램-특화 애플리케이션마스터 자체를 실행하기 위해 필요한 데이터를 포함한 응용프로그램을 제출한다.

2. 리소스매니저는 애플리케이션마스터를 시작하기 위한 특정 컨테이너를 협상할 책임을 맡고, 애플리케이션마스터를 실행한다.

3. 시작된 애플리케이션마스터는 리소스매니저에 등록된다 - 등록을 함으로서 클라이언트 프로그램이 리소스매니저에게 질의할 수 있다

4. 일반 동작 중 애플리케이션마스터는 리소스리퀘스트 프로토콜을 통해 적절한 리소스 컨테이너를 협상한다.

5. 컨테이너가 성공적으로 할당되면, 애플리케이션마스터는 컨테이너 실행 스펙을 노느메니저에게 제공하여 컨테이너를 실행시킨다. 실행 스펙은 일반적으로 컨테이너가 애플리케이션마스터 그 자체와 통신하기 위해 필요한 정보를 포함하고 있다.

6. 응용프로그램 코드는 컨테이너에서 실행되고 진행률, 상태 등의 정보를 응용프로그램-스펙 프로토콜을 통해 응용프로그램의 애플리케이션마스터에게 제공한다.

7. 응용프로그램 실행 중 응용프로그램을 제출한 클라이언트는 상태, 진행률 등을 얻기 위해 애플리케이션마스터와 응용프로그램-스팩 프로토콜을 통해 직접 통신한다.

8. 일단 응용프로그램이 완료되고 모든 필요한 작업이 종료되면, 애플리케이션마스터는 리소스매니저로의 등록을 해제하고 자신의 컨테이너를 다른 용도로 사용할 수 있도록 종료한다.

9. 
   

   

   
   

아파치 하둡 얀 - 리소스매니저

리소스매니저는 모든 가용한 클러스터 자원을 중재하는 마스터이고, 그렇기 때문에 얀 시스템에서 동작 중인 분산 응용프로그램을 관리하는 것을 돕는다. 리소스마스터는 노드 당 설치되는 노드마스터, 응용프로그램당 생성되는 애플리케이션마스터와 함께 동작한다.

1. 노드매니저는 리소스매니저로부터 명령을 받고 단일 노드상의 자원들을 가용하게 관리한다.

2. 애플리케이션마스터는 리소스매니저와 자원을 협상하는 역할을 하며 컨테이너들이 시작할 수 있도록 노드매니저와 함께 동작한다.

리소스매니저 구성 요소

리소스매니저는 다음의 구성요소를 가지고 있다.

1. 리소스매니저와 클라이언트간의 통신을 하는 구성요소

• ClientService: 리소스매니저의 클라이언트 인터페이스이다. 이 요소는 응용프로그램 제출, 응용프로그램 종료, 큐 정보 획득, 클러스터 상태 등의 클라이언트에서 RM으로 오는 모든 RPC 인터페이스를 관리한다.

• AdminService: 관리 요청이 일반 사용자 요청때문에 서비스를 받지 못하는 경우가 없도록, 그리고 더 높은 우선순위를 가지도록 하기 위해서 노드-목록 갱신, 큐의 설정 등의 관리 명령은 이 별도의 인터페이스를 통하여 수행된다.

2. RM과 노드를 연결하는 구성요소

• ResourceTrackerService: 이 요소는 모든 노드에서 오는 RPC에 응답한다. 또한 새 노드의 등록, 유효하지 않거나 퇴역한 노드로부터의 연결 거부, 노드의 하트비트 획득과 스케쥴러로의 전달을 책임지고 있다. 이 요소는 다음의 NMLivelinessMonitor와 매우 밀접하게 연관되어 있다.

• NMLivelinessMonitor: 운영되고 있는 노드들을 추적하고 내려간(정지한) 노드를 명확히 하기 위해서 이 구성요소는 각 노드의 마지막 하트비트 시간을 추적한다. 미리 정의된 간격의 시간내에 하트비트를 보내지 않는 어떠한 노드든 정지한 것으로 여기고 RM에 의해서 만료된다. 만료된 노드에서 현재 수행중인 모든 컨테이너는 정지한 것으로 표시되고 이후로 만료된 노드에는 어떠한 새 컨테이너도 배정하지 않습니다.

• NodesListManager: 유효 및 제외된 노드의 집합이다. yarn.resourcemanager.nodes.include-path와 yarn.resourcemanager.nodes.exclude-path에 설정된 호스트 설정 파일을 읽고 그 파일들에 기반하여 초기 노드 목록을 생성할 책임이 있다. 또한 시간이 진행됨에 따라 퇴역한 노드에 대한 추적을 유지해야 한다.

3. 애플리케이션당 생성되는 AM과 통신하는 구성요소

• ApplicationMasterService: 이 요소는 모든 AM들과의 RPC를 책임진다. 이 요소는 새 AM의 등록과 종료된 AM으로부터 보내오는 종료/해제 요청, 현재 동작중인 모든 AM으로부터의 컨테이터 배치/해제 요청을 받아 YarnScheduler로 전송하는 역할을 책임진다. 이 요소는 아래에 설명된 AMLivelinessMonitor와 밀접하게 연관되어 있다.

• AMLivelinessMonitor: 동작, 정지/응답없는 AM들의 관리를 돕기 위해서 이 요소는 각 AM의 추적과 마지막 하트비트 시간을 유지한다. 미리 정의된 간격의 시간내에 하트비트를 보내지 않는 어떠한 AM이든 정지한 것으로 여기고 RM에 의해서 만료된다. 만료된 AM에서 현재 수행중인 모든 컨테이너는 정지(dead)한 것으로 표시한다. RM은 동일한 AM을 새 컨테이너에서 동작시키기 위해 스케쥴한다. 이러한 동작은 최대 4번 시도될 수 있다.

4. RM의 핵심 - 스케쥴러와 관련 구성 요소

• ApplicationsManager: 제출된 응용프로그램의 집합을 관리할 책임이 있음. 또한 완료된 응용프로그램의 캐시를 유지하여 웹 UI나 명령행을 통한 사용자의 요청에 대해 응답함.

• ApplicationACLsManager: RM은 클라이언트와 어드민에 권한이 있는 사용자만 접근을 허락하는 문이 필요하다. 이 구성요소는 ACL(Access-Control-List)들을 응용프로그램별로 관리하면서 응용프로그램의 중단, 응용프로그램의 상태 요청등이 있을 때 권한을 강제한다.

• ApplicationMasterLauncher: 어떠한 요청으로 인하여 종료괸 이전의 AM 시도들과 함께 새로 제출된 AM을 실행하기 위한 스레드 풀을 관리한다. 또한 응용프로그램이 정상적으로 혹은 강제로 종료되었을 경우 AM을 청소할 책임을 가지고 있다.

• YarnScheduler: 스케쥴러는 자원들을 수용력, 큐 등의 제한을 조건으로 현재 실행중인 다양한 응용프로그램에 할당할 책임이 있다. 스케쥴러는 메모리, CPU, 디스크, 네트워크 등, 응용프로그램의 자원 요구사항에 기반하여 스케쥴링 함수를 동작시킨다. 현재 메모리만이 지원되고 있으며 CPU에 대한 지원이 완성되기 직전이다.

• ContainerAllocationExpirer: 이 구성요소는 모든 할당된 컨테이너들이 AM들에 의해서 사용되고 있으며 차후에 컨테이너가 해당되는 노드메니저에서 실행되는지 확인할 책임이 있다. AM들은 신뢰할 수 없는 사용자 코드로 실행되며 컨테이너를 사용하지 않고 할당을 유지할 수 있을 수 있으며, 이에 따라 클러스터 사용률이 저하될 수 있다. 이 문제를 해결하기 위해서, ContainerAllocationExpirer는 해당하는 노드에서 사용되고 있지 않는 할당된 컨테이너들의 목록을 유지한다.어떠한 컨테이너이든 해당하는 노드매니저가 정해진 시간- 기본 10분 -안에 RM으로 컨테이너가 동작을 시작하였다고 보고하지 않으면 컨테이너는 정지했다고 가정하고 RM에의해 만료된다.

5. TokenSecretManagers(보안을 위해): 리소스매니저는 토큰, 다양한 RPC 인터페이스에서 인증/허가를 위해 사용되는 비밀키를 관리하기 위해 몇개의 SecretManager를 가지고 있다. 얀 보안에 대한 미래의 글에는 토큰, 비밀키, SecretManager들에 대한 설명을 할 것이며, 현재는 다음의 대략적인 설명만 한다.

• ApplicationTokenSecretManager: RM 스케쥴링 요청을 전송하는 독단적인 프로세스를 피하기 위해 RM은 ApplicationToken이라는 응용프로그램별 토큰을 사용한다. 이 구성요소는 각 토큰을 응용 프로그램이 종료되기전까지 지역적으로 메모리에 저장하고 유효한 AM 프로세스로부터 오는 모든 요청을 인증하기 위해 사용한다.

• ContainerTokenSecretManager: RM에 의해 특정한 노드에 있는 컨테이너를 위해 AM에게 발급하는 특별한 토큰인 ContainerToken을 위한 SecretManager이다. ContainerToken은 컨테이너가 할당된 해당하는 노드매니저와 연결을 생성하기 위해 AM에 의해 사용된다. 이 구성요소는 RM 특정이며 근본적인 마스터와 비밀키를 기록하고 가끔 키를 롤한다.

• RMDelegationTokenSecretManager: 리소스매니저 특정 위임 토큰 SecretManager이다. 이 구성요소는 RM과 통신이 가능하기를 원하는 인증되지않은 프로세서에게 전달할 가능성이 있는 클라이언트에게 위임 토큰을 생성할 책임이 있다.

6. DelegationTokenRenewer: 보안 모드에서 RM은 Kerberos로 인증되며 응용프로그램을 대신하여 파일 시스템 토큰을 갱신하는 서비스를 제공해야 한다. 이 구성요소는 응용프로그램이 동작하는 동안 그리고 토큰이 갱신할 수 없기 전까지 제출된 응용프로그램의 토큰을 갱신한다.

결론

얀에서 리소스매니저는 주로 스케쥴링, 단지 시스템에 있는 가용한 자원들을 경쟁관계에 있는 응용프로그램들 사이에 중재만 하는 것으로 한정되어 있으며 응용프로그램별 상태 관리는 고려하지 않는다. 이러한 분명한 책임 구분과 짝을 이룬 모듈 방식 그리고 강력한 스케쥴러 API로 인하여 RM은 가장 중요한 설계 요구조건인 확장성과 다른 프로그래밍 모델의 지원을 해결할 수 있다. 서로다른 정책 제약 조건을 사용하기 위해서 RM에 있는 스케쥴러는 플러거블하고 다른 알고리즘 사용을 허가한다. 다른 글에서 우리는 캐파시티를 보장하고 큐에 기반하여 스케듈하는 캐파시티스케듈러의 다양한 기능들을 깊이 알아 볼 것이다.

아파치 하둡 얀 - 노드매니저

노드매니저(NM)은 얀의 노드 당 설치되는 에이전트이며, 하둡 클러스터에 있는 각각의 연산 노드를 관리한다. 여기에는 리소스매니저로의 동기화, 컨테이너 생명주기 관리, 각 컨테이너가 사용하는 자원의 사용량 모니터링, 노드 상태/ 로그 관리/ 다른 얀 응용프로그램들이 사용할 수 있는 보조 서비스들을 추적한다.

노드매니저 구성요소

1. NodeStatusUpdater

시작할 때, 이 구성요소는 RM에 등록을 수행하고, 노드에 있는 자원들의 가용에 대한 정보를 송신한다. 이후의 NM-RM 통신은 노드에서 동작중인 새 컨테이너, 완료된 컨테이너 등의 컨테이너 상태에 대한 업데이트를 제공한다.

추가로 RM은 이미 동작중인 컨테이너를 잠재적으로 종료하기 위해서 NodeStatusUpdater에게 신호를 줄 수 있다.

2. ContainerManager

컨테이너매니저는 노드매니저의 핵심이다. 컨테이너매니저는, 노드에서 동작 중인 컨테이너를 관리하기 위해 필요한 기능의 일부를 수행하는 다음의 하위 구성요소를 가진다.

• RPC server: 컨테이너매니저는 애플리케이션마스터로부터 새로운 컨테이너를 시작하거나 동작중인 컨테이너를 정지시키는 요청을 받는다. ContainerManager는 아래에서 설명할  ContainerTokenSecretManager와 협력하여 모든 요청을 인증한다. 이 노드에서 수행중인 컨테이너에 대한 모든 연산은 보안 도구에 의해 후처리될 수 있는 로그에 기록된다.

• ResourceLocalizationService: 컨테이너가 필요한 다양한 파일 리소스를 안전하게 다운로드하고 관리할 책임이 있다. 이 구성요소는 가능한 모든 디스크에 파일을 분산하도록 최선을 다하여 시도한다. 또한 다운로드받은 파일들의 접근 권한과 적절한 사용량를 제한한다.

• ContainersLauncher: 컨테이너를 가능한 빠르게 준비하고 시작하기 위해서 스레드 풀을 유지한다. 또한 RM이나 AMs에서 보내진 요청이 있다면 컨테이너의 프로세스들을 정리한다.

• AuxServices: 노드매니저는 예비 서비스들을 설정하여 노드매니저의 기능을 확장하기 위한 프레임워크를 제공한다. 이 기능은 특정한 프레임워크들이 필요로 하는 노드 별 커스텀 서비스 사용을 허가하면서도 여전히 NM의 다른 부분으로부터 분리한다. 이러한 서비스들은 NM이 시작되기전에 설정되어야 한다. 예비 서비스들은 노드에서 응용프로그램의 첫번째 컨테이너가 시작되었을때와 응용프로그램이 완료되었다고 여겨질 때 통보받는다.

• ContainersMonitor: 컨테이너가 시작된 후 이 구성요소는 컨테이너가 실행되는 동안의 자원 사용 관측을 시작한다. 메모리같은 자원의 공평한 공유와 격리를 강제하기 위해서 각 컨테이너는 RM에 의해서 자원들의 일부를 할당받는다. ContainersMonitor는 각 컨테이너의 사용을 지속적으로 모니터링 하고, 컨테이너가 할당을 넘어선다면, 컨테이너를 종료시키기 위해 신호를 보낸다. 이 것은 탈주자 컨테이너가 동일한 노드에서 실행중인 다른 정상 동작하는 컨테이너들에게 영향을 주는 것을 막는다.

• LogHandler: 컨테이너의 로그들을 로컬 디스크에 유지하거나 압축하여 파일 시스템에 업로드할 수 있도록 설정할 수 있는 탈착가능한 구성요소이다.

3. ContainerExecutor

이 구성요소는 컨테이너가 필요로하는 파일들과 디렉터리들을 안전하게 위치시키기 위해서 그리고 안전한 방법으로 컨테이너에 상응하는 프로세스들을 시작하거나 정리하기 위해서 밑 바탕의 운영체제와 상호작용한다.

4. NodeHealthCheckerService

이 구성요소는 미리 구성된 스크립트를 주기적으로 실행하여 노드의 상태를 점검하는 기능을 제공한다. 또한 특히 디스크에 가끔 임시파일을 생성하여 디스크의 상태를 모니터링한다. 시스템의 모든 상태 변경은 정보를 차례차례 RM으로 전송하는 NodeStatusUpdater로 보고된다.

5. Security

• ApplicationACLsManager: NM은 허가된 사용자만 접근해야 하는 웹UI의 컨테이너 로그 디스플레이 같은 사용자 방향 API를 선별할 필요가 있다. 이 구성요소는 ACL(접근 조정 목록)을 응용프로그램별로 관리하며 그런 요청을 받았을 때 ACL을 강제한다.

• ContainerTokenSecretManager: 이 구성요소는 모든 동작이 RM에 의해서 인증되었는가 확실히 보장하기 위해서 다양한 도착 요청을 확인한다.

6. WebServer

응용프로그램, 주어진 시점에서 실행 중인 컨테이너들, 노드 상태에 관련된 정보들 그리고 컨테이너에 의해서 생성된 로그들의 목록을 보여준다.

핵심 기능 설명

1. 컨테이너 시작

컨테이너 시작을 가능하게 하기 위해서 NM은 컨테이너 명세의 일부로서 컨테이너의 실행시간에 대한 자세한 정보를 수신하기를 기대한다. 이 정보는 컨테이너의 커맨드 라인 명령, 환경 변수, 컨테이너가 필요로 하는 (파일) 리소스들의 목록과 보안 토큰을 포함한다.

컨테이너-시작 요청을 받게 되면 보안이 활성화 되어 있다면, NM은 먼저 사용자, 올바른 자원 할당 등을 검증한다. 그후 NM은 컨테이너를 시작하기 위해서 다음의 단계를 수행한다.

1. 명세된 모든 자원들의 로컬 복사본을 생성한다.(디스트리뷰티드 캐시).

2. 컨테이너가 사용하기 위해 생성한 워킹 디렉터리를 격리하고, 로컬 자원들을 이 디렉터리에서 사용가능한 상태로 만든다.

3. 실제의 컨테이너를 시작하기 위해서 실행 환경과 커맨드 라인을 사용한다.

2. 로그 취합

사용자-로그 처리는 과거 하둡 설치에서 큰 골칫거리 중 하나였다. 사용자-로그를 잘라버리고 태스크트래커처럼 개별 노드에 놔두는 대신 NM은 응용프로그램이 완료된 후 로그들을 안전하게 HDFS등의 파일 시스템으로 옮길 수 있는 옵션을 제공하여 로그의 관리 문제를 해결하였다.

단일 응용프로그램에 속하고 이 NM에서 실행한 모든 컨테이너들의 로그들은 취합되어 파일 시스템의 지정된 위치에 단일 로그 파일(가능하다면 압축된)로 저장된다. 사용자들은 이 로그들을 YARN 커맨드 라인 툴, 웹UI 또는 FS에서 직접 접근한다.

3. 맵리듀스 셔플은 어떻게 NM의 예비 서비스에서 장점을 얻을 수 있는가

맵리듀스 응용프로그램을 실행하기 위해서 필요한 셔플 기능은 예비 서비스로 구현되어 있다. 이 서비스는 Netty 웹 서버를 시작하고 리듀스 태스크의 구체적인 MR 셔플 요청을 어떻게 처리해야 하는지 알고 있다. MR 애플리케이션마스터는 필요할 수 있는 보안 토큰과 함께 셔플 서비스를 위한 서비스 id 를 특정한다. NM은 리듀스 태스크로 전달하는 셔플 서비스가 관계되는 포트와 함께 애플리케이션마스터를 제공한다.

결론

YARN에서, 노드매니저는 주로 컨테이너와 연관되는 프로세스들 등의 추상 컨테이너들을 관리하는 일로 제한되며, 맵리듀스 태스크 같은 애플리케이션별 상태 관리에 관여하지 않는다. 또한 맵과 리듀스 슬롯과 같이 명명된 슬롯의 관념을 폐지한다. 이상에서 기술한 모듈러 구조와 더불어 이러한 명확한 책임 구분 때문에 노드매니저는 훨씬 더 간단히 확장가능하며 코드도 훨씬 더 유지보수 가능하다.

출처 - http://blog.daum.net/minykreva/2

지난 글에서 hadoop 파일시스템의 변화에 대해 간단하게 살펴 보았습니다. 이번 글에서는 mapreduce의 변화에 대해 살펴보도록 하겠습니다. 
hadoop 0.23 버전에서의 가장 큰 변화는 YARN 이라고 할 수 있습니다. YARN은 Yet Another Resource Negotiator 의 약자라고 합니다. hadoop은 YARN을 통해 분산 환경에서의 애플리케이션 서버로 진화하려는 시도를 하고 있습니다. 
0.23 이전 버전의 mapreduce는 분산된 서버에서 안정적으로 map/reduce task를 실행 관리하는 기능을 수행했다면 YARN에서는 분산된 환경에서 다양한 분산 시스템을 운영할 수 있는 환경을 제공하고 있습니다. 그래서 이름에도 Resource 관리라는 개념을 붙였고요. 따라서 hadopo-0.23 에서의 YARN은 MapReduce 뿐만 아니라 사용자가 쉽게(?) 분산된 작업을 만들어서 실행할 수 있는 환경을 제공하고 있습니다. 즉 분산 애플리케이션 서버의 역할을 수행한다고 할 수 있습니다. 
지금 버전에서는 다소 기능이 약하지만 지향하는 방향이 그쪽이라서 버전이 올라갈수록 좋아 질것이라 예상해봅니다. 

먼저 YARN에서 MapReduce의 시스템 실행을 보면 다음 그림과 같습니다. 

YARN은 ResourceManager와 NodeManager 두 종류의 데몬으로 구성되어 있습니다. ResourceManager는 마스터 서버의 역할을 수행하며 1대의 서버에 실행됩니다. NodeManager는 worker 역할을 수행하며 N대의 서버에 실행됩니다. 
ResourceManager 내부에는 Scheduler와 ApplicationManager라는 두개의 메인 컴포넌트로 구성되어 있습니다. 

  - Scheduler: NodeManager들의 자원 상태를 관리한다. 0.23 버전에서 자원은 NodeManager의 여유 메모리로 관리된다. 
  - ApplicationManager: 특정 작업을 위한 Master 서버가 되는 Application Master를 실행하고 Application Master의 상태를 관리한다. 

여기서 Application Master라는 새로운 용어가 나오는데 YARN에서 실행되는 하나의 작업을 관리하는 마스터 서버를 Application Master라고 부릅니다. MapReduce 작업의 경우 JobTracker가 Application Master입니다. 
YARN의 두 데몬과 각 컴포넌트들이 Map/Reduce 작업을 어떻게 실행하는지 위 그림을 보고 간단하게 설명하겠습니다. 

ResourceManager의 Scheduler는 NodeManager로 부터 주기적으로 NodeManager의 상태 정보를 수신하여 가용한 리소스 정보를 관리합니다. 
사용자 요청(MapReduce 작업 실행)을 받으면 ResourceManager의 ApplicationManager는 Scheduler에게 ApplicationMaster(JobTracker)를 실행시키기 위한 NodeManager를 할당 받은 후 해당 NodeManager에 JobTracker를 실행을 요청합니다. NodeManager는 JobTracker를 fork하여 실행합니다. 
JobTracker는 ResourceManager의 Scheduler에게 TaskTracker 실행을 위한 NodeManager 할당을 요청하여 NodeManager 목록을 받습니다. 
각 NodeManager에 TaskTracker 실행을 요청하면 NodeManager는 TaskTracker를 fork하여 실행합니다. 
이후 부터는 기존의 MapReduce 작업 실행과 동일하게 JobTracker에 의해 스케줄링되고 작업이 TaskTracker에 할당되고 실행됩니다. 
작업이 종료되면 JobTracker, TaskTracker 모두 종료됩니다. 기존 버전에서는 JobTracker, TaskTracker는 종료되지 않고 사용자가 실행시킨 Task만 종료되었는데 YARN에서는 JobTracker/TaskTracker 자체가 사용자가 실행시킨 작업이기 때문에 작업이 종료되면 해당 데몬들은 종료시킵니다. 
JobTracker가 종료되면 기존의 작업에 대한 로그 정보들이 유실되는데 이를 위해 JobHistoryServer하는 별도의 데몬이 있습니다. 이 데몬을 실행하면 작업 로그는 이 데몬에 의해 관리되고 이 데몬에서 제공하는 웹 UI를 이용하여 작업 history 정보를 볼 수 있습니다. 
이렇게 많이 바뀌었기 때문에 기존의 MapReudce 작업은 실행되지 않을까 걱정할 수 있는데 기존의 Map/Reduce 프로그램도 잘 돌아가게 구성되어 있습니다.

YARN에서는 JobTracker/TaskTracker는 하나의 특화된 작업입니다. 개발자는 MapReduce 프레임워크와 같은 분산된 환경에서 작업을 처리할 수 있는 다양한 시스템을 YARN 에서 실행시킬 수 있습니다. 예를 들어 그래프 분석을 처리하는 GoldenORB나 Hama와 같은 프로그램은 각각 리소스 관리 체계, 데몬 관리, 사용자 작업 분배 처리 등과 같은 분산 작업에 필요한 모듈을 모두 새로 개발해야 했었습니다. 하지만 YARN에서는 이런 기능들은 미리 제공하고 있어 별도의 추가 개발할 필요 없이 실행하고자 하는 로직만 처리하도록 구성할 수 있도록 해줍니다. 물론 YARN 환경에서도 새로운 분산 시스템을 만드는 것도 쉬운 작업은 아닙니다. MapReduce 프레임워크만 보더라도 아직 복잡하게 구성되어 있으니까요... 작업의 제어, 장애 시 재시도 등에 대한 것들을 개발자가 직접 모두 만들어 줘야하는 것은 여전합니다.

그러면 YARN의 장점은 무엇일까요? 아직까지 직접 만들어 보지 못했기 때문에 정확하게 말할 수는 없지만 다음 정도로 정리해 볼 수는 있을 것 같습니다.

 - Application Master에 대한 장애 관리
    제가 본 코드(10월 버전)에서는 아직 이 기능은 들어오지 않았는데 스펙상 지원된다고 하니 정식 버전에는 지원하지 않을까 생각합니다.

 - 분산된 서버의 리소스 관리 및 리소스 할당, 반납
 - 서버(NodeManager)의 장애 상황 감지 및 통보
 - 표준화된 분산 관리 체계 지원으로 정형화된 프로그램 개발 가능 -> 과거에 어렵고 복잡했던 시스템 개발을 표준화된 모습으로 정리 -> 앱스토어 형태의 생태계 구축 가능

현재까지는 이정도 수준입니다.

그리고 0.23의 코드는 거의 새로 만들어진 수준입니다. Map/Reduce 부분의 경우 JobTracker 클래스 자체가 없어졌습니다. 물론 작업의 스케쥴링, TaskTracker의 처리 등내부적으로 Task를 처리하는 기능에 대한 코드는 그대로 사용하고 있습니다.
YARN의 구현은 새로운 개념이기 때문에 모두 새롭게 만들어졌는데 State Machine을 사용하여 데몬, 작업 등의 상태 처리와 이 상태 변환에 따른 로직 구현으로 되어 있기 때문에 각각에 대한 State를 이해하는 것이 필수라고 할 수 있습니다.

이외에 많은 내용이 있지만 개념만 설명하는 차원이라서 생략하도록 하겠습니다.

출처 - http://www.jaso.co.kr/447