YARN 리소스매니저(Resource Manager)

하둡(Hadoop) 프로젝트의 YARN(Yet Another Resource Negotiator) 모듈은 분산 환경에서의 자원관리를 담당합니다.

 

이 글에서는 YARN과 관련해 다음과 같은 항목을 다룹니다:

 

• 목적과 탄생배경
• YARN(하둡분산자원관리) 주요개념 및 아키텍쳐
• YARN(하둡분산자원관리) 실행 구조 및 흐름
• YARN 리소스매니저(Resource Manager) (이번글)
• YARN 노드매니저(Node Manager)
• 운영과 관련한 사항들

---

YARN의 다양한 기능들은 크게 2가지 레이어로 나뉩니다:

• platform 레이어: 리소스 관리와 최상위레벨 스케쥴링을 담당. 리소스매니저와 노드매니저가 해당됨.
• framework 레이어: 애플리케이션의 실행 조정이나 second-레벨 스케쥴링을 담당. 애플리케이션마스터가 해당됨.

 

이러한 기능의 분리와 각 기능을 특정 컴포넌트가 담당하면서 (Hadoop 1 과는 다르게),  중심에 위치한 리소스매니저는 단순한 데몬으로 스케쥴링과 애플리케이션의 요청에 따른 자원할당에만 집중할 수 있었습니다. 아래에서는 이러한 리소스매니저의 주요 컴포넌트와 기능들을 살펴보겠습니다. 

 

리소스매니저 컴포넌트들

위에서 언급된 바와 같이, 리소스매니저는 마스터로 클러스터의 모든 자원들을 관리하고 분배하여 YARN 플랫폼에서 다양한 분산된 애플리케이션이 실행될 수 있도록 합니다. 이 부분을 위해 리소스매니저는 아래와 같이 다양한 컴포넌트와 협업합니다:

 

• 노드마다 존재하는 노드매니저: 노드매니저는 리소스매니저로부터 instruction을 받아서 단일한 노드에 존재하는 리소스를 관리하고 애플리케이션마스터로부터 받은 컨테이너 요청을 처리합니다.
• 애플리케이션마다 존재하는 애플리케이션마스터: 애플리케이션마스터는 리소스매니저와 조율을 통해 리소스를 얻어내고, 컨테이너를 시작 / 모니터 / 중지하기 위해 노드매니저와 커뮤니케이션 합니다.

 

리소스매니저의 컴포넌트들은 내부 컴포넌트를 제외하면, 어떤 외부 서비스와 연동되는지에 따라 그 성격이 구분될 수 있습니다. 리소스매니저와 연동되는 서비스는 위의 2가지인 노드매니저, 애플리케이션마스터와 클라이언트가 존재합니다. 

 

아래 이미지 좌측은 주로 클라이언트 관련, 하단은 애플리케이션마스터 관련, 우측은 노드매니저 관련 컴포넌트라고 할 수 있겠습니다:

ResourceManager Components - Image from Author inspired by [2]

 

아래에서는 다음과 같이 컴포넌트들을 묶어서 기술합니다 (Job 제출 시의 순서와도 연관되어 다음과 같은 순서로 기술):

• 클라이언트 관련 
• 애플리케이션 관련
• 노드 관련
• Core
• security 관련

 

리소스매니저 - 클라이언트

사용자가 클라이언트로 리소스매니저에 접근할 때 가장 먼저 마주하는 부분입니다. 이 부분에서는 Client Service, Addministration Service, Application ACLs Manager, Web Server를 다룹니다.

 

Client Service

클라이언트 서비스(ClientRMService)는 기본적인 클라이언트-리소스매니저 인터페이스인 ApplicationClientProtocol을 implement합니다. 이 컴포넌트는 클라이언트로부터 리소스매니저로 오는 모든 RPC 콜을 처리합니다:

 

• 애플리케이션 제출
• 애플리케이션 종료
• 애플리케이션, 큐, 클러스터 통계, 사용자 ACLs 등의 정보 송신

 

Administration Service

클라이언트 서비스가 특정 유저의 액션을 담당한다면, AdminService는 일반 유저의 요청과 구분되고 한 단계 높은 우선순위를 주기 위해 분리된 인터페이스(ResourceManagerAdministrationProtocol)를 implement하여 구성됩니다. 특징적인 operation은 다음과 같습니다:

• 큐 refreshing: 새로운 큐 추가, 존재하는 큐 중지, 큐 재설정 등을 처리
• 리소스매니저에 의해 관리되는 노드 refreshing: 새로운 노드 추가, 기존 노드 제외 등
• 새로운 유저-그룹 매핑 추가, administrator ACLs 추가 및 갱신, superuser 리스트 CRUD 등

Application ACLs Manager

리소스매니저는 클라이언트나 관리자 요청과 같이 유저와 접점이 되는 API를 다루기에 인가된 사용자에게만 접근가능하여야 합니다. 이 컴포넌트는 애플리케이션마다 존재하는 ACL을  관리하고 실행합니다. 이 ACL은 YARN 설정의 yarn.acl.enable을 통해 설정됩니다. 

 

그러한 접근은 2가지 타입으로 관리됩니다:

 

• view: 누가 애플리케이션과 관련된 정보를 RPC interfaces, web UI, 그리고 웹 서비스에서 볼 수 있는지 관리합니다.
• modify: 유사하게 누가 애플리케이션을 변경할 수 있는지 관리합니다.

 

사용자는 제출하는 애플리케이션에 대해서 ApplicationSubmissionContext에 ACL을 포함하여 특정할 수 있으며, 이 ACL은 ACLsManager를 통해 애플리케이션마다 관리되며 애플리케이션마스터 또는 노드매니저(ContainerLaunchContext의 형태로)도 사용하게 됩니다. 

 

Web Application and Web Services

리소스매니저는 클러스터 상태, 메트릭, 노드 상태별 리스트, 애플리케이션 리스트와 각 애플리케이션 상태; 애플리케이션마스터에 대한 hyper 레퍼런스; 그리고 스케쥴러에 따라 다른 인터페이스 등을 보여주는 웹 애플리케이션을 가지고 있습니다.

 

리소스매니저-애플리케이션 관련

애플리케이션이 클라이언트 부분의 서비스를 통과하면 애플리케이션마스터를 생성하기 위해 마주하는 컴포넌트들입니다.

 

애플리케이션마스터 서비스

이 컴포넌트(ApplicationMasterService)는 모든 애플리케이션마스터들에 대한 응답을 담당합니다. 애플리케이션마스터가 리소스매니저와 커뮤니케이션하기 위해 사용하는 유일한 ApplicationMasterProtocol을 implement합니다:

 

• 새로운 애플리케이션마스터 등록
• 끝나는 애플리케이션마스터로부터의 요청의 종료/해지
• 리소스매니저에 존재하는 애플리케이션에 대응되는 검증된 애플리케이션마스터의 요청을 허가
• 실행되고 있는 애플리케이션마스터로부터  컨테이너 할당 / 제거 요청을 받아 스케쥴러에 포워딩

애플리케이션마스터는 하나의 애플리케이션마스터 내에서 오직 하나의 쓰레드만 리소스매니저에 요청을 넣도록 관리하고, 리소스매니저는 모든 애플리케이션마스터들의 RPC들을 serialize하여 하나의 애플리케이션마스터에서 단 하나의 쓰레드만 요청을 넣도록 관리합니다.

 

애플리케이션마스터 Liveliness 모니터

살아있거나 죽은 애플리케이션마스터 리스트 관리를 돕기 위해, 이 컴포넌트는 각 애플리케이션마스터의 마지막 heartbeat을 기록하고 트래킹합니다. 설정된 시간 동안(디폴트 10분) heartbeat이 없는 애플리케이션마스터는 죽은 걸로 간주되고 리소스매니저가 종료합니다. 그리고 해당 애플리케이션마스터에 귀속되었던 모든 컨테이너 역시 죽은 것으로 마킹됩니다. 

 

리소스매니저는 동일한 애플리케이션을 새로운 애플리케이션 attempt로 실행하기 위해 다시 스케쥴링하며 이 과정을 최대 디폴트로 2번 행합니다.

 

리소스매니저 - 노드 관련

Resource Tracker Service

노드매니저는 주기적으로 리소스매니저에 heartbeat를 보내고, 이 컴포넌트(ResourceTrackerService)가 그러한 노드매니저로부터의 RPC에 응답하는 것을 담당합니다. ResourceTracker 인터페이스를 implement하며 아래 같은 사항들을 처리합니다:

• 새로운 노드 등록
• 등록된 노드로부터의 heartbeat 처리
• 유효한 노드만 리소스매니저와 커뮤니케이션할 수 있도록 하며 다른 노드들을 reject함

 

새로운 노드를  YARN에 추가하기 위해서는 많은 일들이 필요합니다. 해당 노드에 운영자가 먼저 YARN을 설치해야하고, 다른 노드와 유사하게 설정하여 리소스매니저과 통신할 수 있도록 하여야 합니다. 

 

 리소스매니저는 유효하지 않거나 제거된 노드로부터의 요청을 reject하고 리소스매니저에 설정된 최소 리소스 요구사항을 만족하지 못하는 노드도 reject합니다. 성공적인 등록이 완료되면, 리소스매니저는 노드매니저가 애플리케이션마스터의 컨테이너 관련 요청 시 인증용으로 사용할 마스터 키를 노드매니저에게 응답으로 전달합니다. 

 

노드매니저는 애플리케이션마스터가 container launch 요청 시 보내는 노드매니저 토큰과 컨테이너 토큰을 검증하는데 이러한 마스터 키를 사용합니다. 또한, 마스터 키는 보안을 목적으로 주기적으로 heartbeat을 통해  변경되기에 노드매니저는 변경 시 알림을 받고 업데이트합니다. 

 

이렇게 ResourceTrackerService가 받은  heartbeat에 대한 정보는 스케쥴러에 보내져 스케쥴링을 결정하는 데에 사용됩니다.

 

NodeManagers Liveliness Monitor

살아있는 노드와 죽은 노드의 파악을 위해 해당 컴포넌트는 각 노드의 ID를 추적하고 마지막 heartbeat 시각을 기록합니다. 디폴트 10분 동안 heartbeat이 없는 노드는 죽은 것으로 간주되어 리소스매니저에서 삭제됩니다. 또한, 귀속된 컨테이너도 죽은 것으로 마킹됩니다. 

Nodes List Manager

Nodes List Manager는 유효하거나 제외된 노드 리스트로 리소스매니저 메모리에 존재합니다. yarn.resourcemanager.nodes.include-path와 yarn.resourcemanager.nodes.exclude-path 설정을 통하여 파일을 찾고 초기의 노드 리스트 등록을 담당합니다. 또한, 시간이 지나며 운영자에 의해 삭제된 노드도 기록합니다.

 

Core

위의 3가지 외부 서비스 관련 컴포넌트들의 중심에는 다음과 같은 YARN의 핵심 컴포넌트들이 존재합니다.

 

애플리케이션매니저

애플리케이션매니저는 제출된 애플리케이션 관리를 담당합니다. 애플리케이션이 제출되고 나서, 맨 처음 애플리케이션마스터를 위한 리소스를 확인하여 그러한 리소스를 만족시킬 수 있는 리소스가 없을 때(예로, 애플리케이션마스터 메모리를 64GB 요청했는데, 모든 노드 메모리가 32GB일 때) 바로 reject 합니다. 그리고 다른 제출된 애플리케이션이 똑같은 ID를 가지지 않도록 확인 프로세스를 거칩니다. 그리고 그러한 애플리케이션을 스케쥴러로 넘깁니다. 

 

애플리케이션매니저는 또한 종료된 애플리케이션이 완전히 리소스매니저에서 사라지기 전까지 기록하고 관리하는 일을 담당합니다. 애플리케이션이 종료되면, ApplicationSummary를 데몬 로그 파일에 생성하는데 그 ApplicationSummary는 종료 시점의 모든 애플리케이션 정보를 담고 있습니다. 

 

마지막으로, 애플리케이션매니저는 사용자가 애플리케이션 데이터를 요청하는 것을 지원하기 위해 종료된지 오래된 애플리케이션의 정보도 캐싱하고 있습니다. yarn.resourcemanager.max-completed-applications 설정은 몇 개의 종료된 애플리케이션 정보를 들고 있을지 결정하게 됩니다. 

 

애플리케이션마스터 런처 (Launcher)

YARN에서 모든 컨테이너는 애플리케이션마스터에 의해 launch가 시작되지만,  애플리케이션마스터 자체는 리소스매니저에 의해 처리되고, 이 런처가 그 부분을 담당합니다. 이 컴포넌트는 쓰레드풀을 유지하며 노드매니저와 커뮤니케이션을 통해 새롭게 제출된 애플리케이션이나 이전의 애플리케이션 attempt가 실패 후 다시 실행되는 경우 애플리케이션마스터 생성을 진행합니다. 

 

또한, 이 컴포넌트는 노드매니저와 커뮤니케이션을 통해 애플리케이션마스터를 정리하는 일을 담당합니다.

 

YarnScheduler

스케쥴러는 capacities, 큐 등의 제약을 받는 다양한 애플리케이션에 리소스를 할당하고 배분하는 일을 담당합니다. YARN에서 이 부분은 pluggable하게 구현되어 custom 스케쥴러도 사용할 수 있습니다. 기본적으로 Fair와 Capacity 2가지를 제공하며 스케쥴러에 대한 설명은 다른 글에서 좀 더 상세히 전달드리겠습니다. (TODO)

 

ContainerAllocationExpirer

해당 컴포넌트는 할당된 모든 컨테이너가 애플리케이션마스터에 의해 사용되고 이어서 상응하는 노드매니저에 의해 launch되는 것을 보장합니다. 애플리케이션마스터는 신원불명의 사용자 코드를 실행하고 사용하지 않는 컨테이너를 할당 받을 수 있습니다. 그렇기에 클러스터 사용률을 낮출 수 있기에, ContainerAllocationExpirer는 각 노드매니저별 할당되었으나 사용하지 않는 컨테이너 리스트를 관리합니다. 그리고, 설정된 시간 안에(디폴트 10분) 노드매니저가 리소스매니저에 컨테이너 실행시작을 보고하지 않으면 컨테이너는 죽은 것으로 간주되고 리소스매니저에 의해 종료됩니다.

 

또한, 독립적인 노드매니저들은 각 컨테이너에 ContainerToken으로 인코딩된 이 만료시간을 보고 만료시간이 지났는데도 시작하지 않은 컨테이너를 reject합니다. 

 

Security 관련

리소스매니저는 SecretManagers라고 불리는 컴포넌트 묶음을 가지고 있습니다. 이 컴포넌트들은 토큰과 secret key들 관리를 담당하는데 이러한 토큰과 키는 다양한 RPC 인터페이스에서 인증 / 인가에 사용됩니다. 좀 더 상세한 부분은 다른 글에 자세히 기술해두었습니다. (TODO)

 

Reference
[1] Apache Hadoop YARN: yet another resource negotiator

[2] Apache Hadoop YARN: Moving beyond MapReduce and Batch Processing with Apache Hadoop 2