5 Yarn Architecture 심화

5.1 Resource Manager

Resource Manager는 전체 클러스터의 가용한 리소스를 스케줄링하고, 클러스터에서 실행되는 애플리케이션들에게 리소스를 분배하고 관리한다.
Resource Manager는 NodeManager와 ApplicationMaster를 제어하면서 어플리케이션들이 정상적으로 실행될 수 있게 도와준다.

https://sungsoo.github.io/2014/05/12/an-insight-into-hadoop-yarn-resource-manager.html

5.1.1 Components interfacing RM to the client

ClientService
admin이 아닌 모든 Client의 요청이 여기로 온다고 보면 됨.
ClientService 는 Resource Manager 와 클라이언트 사이의 인터페이스이다.
RM은 이 인터페이스로 클라이언트로부터 오는 모든 RPC 를 핸들링 한다.

• application submission, application termination, obtaining queue information, cluster statistics 등

RPC(Remote Procedure Call)
네트워크를 통해 다른 프로세스(보통은 다른 서버)에 있는 메소드를 로컬 메소드 호출처럼 실행할 수 있도록 하는 기술.
즉, 클라이언트는 "내 PC에서 함수 호출하듯이" 호출하지만, 실제 처리는 원격 서버(RM)에서 일어남.

클라이언트가 RPC를 보낸다 = 클라이언트가 RM의 ClientService 인터페이스에 정의된 메소드를 원격 호출한다는 의미
실제로는 YARN이 제공하는 프로토콜(YarnClientProtocolPB)을 통해 Java에서 메소드처럼 호출하면, 내부적으로는 RPC 요청/응답 메시지가 네트워크로 오가는 구조다.

AdminService

일반 유저의 요청과 admin 요청을 구분하기 위해서 인터페이스를 구분했다.
AdminService로 온 요청은 일반 ClientService 보다 높은 우선순위로 처리된다.
node-list 의 리프레시, queue 설정 등의 동작을 AdminService를 통해 한다.

5.1.2 Components connecting RM to the nodes

아래 Components들은 ResourceManager 내부에 있음

ResourceTrackerService

ResourceTrackerService는 클러스터의 노드들의 heartbeats 를 받고, 그 정보를 YarnScheduler 로 전달하는 역할을 한다.
노드로부터 오는 RPC 들을 처리한다. (노드 등록, 삭제 등)
ResourceTrackerService가 노드(NodeManager)로부터 heartbeat와 상태 정보를 수집하고, 그 정보를 기반으로
노드 상태 관리 컴포넌트(NMLivelinessMonitor, NodesListManager)와 함께 동작한다.

NMLivelinessMonitor

live/dead node 의 상태를 추적한다.
각 노드가 마지막으로 ResourceTrackerservice한테 보냈던 last heartbeat time 을 기억하고 설정된 interval time(default 10min) 동안 heartbeat 를 보내지 않는 노드가 있다면, 해당 노드를 dead 처리하고 RM 로부터 expire 시킨다.
dead 처리된 노드에서 running 중이던 container 들 또한 dead 처리가 되고, 새로운 컨테이너로 스케줄링 된다.

NodesListManager

• 역할: 노드에 대한 검증(validation) 및 상태 관리

  • 노드가 RM에 등록 가능한지 확인하고, 조건을 만족하지 않으면 제외(excluding)
  • host configuration 파일을 읽어 초기 노드 리스트를 세팅

• Decommissioned 노드 처리:

  • 관리자가 노드를 제거(decommission)하면, NodesListManager가 해당 노드를 사용 불가 상태로 표시
  • 이후 heartbeat를 받더라도 새로운 컨테이너 스케줄링에서 제외

• 주 목적: RM이 클러스터 노드 상태를 정확히 파악하고, 잘못된 노드/제외된 노드를 스케줄링에 포함하지 않도록 보장

5.1.3 Components interacting with the per-application AMs

per-application AMs : 각 애플리케이션마다 존재하는 AM들
Components interacting with per-application AMs : RM 내부에서 각 AM과 통신/상태 추적하는 컴포넌트

• ApplicationMasterService, AMLivelinessMonitor 같은 컴포넌트가 각 AM과 RM 사이에서 상태 확인, 등록, heartbeat 처리 등을 담당함

ApplicationMasterService

• 역할: ResourceManager와 각 애플리케이션 AM 사이의 중개자

  • AM 등록/해제(unregister), 종료(termination) 처리
  • AM의 컨테이너 할당 요청 및 해제 요청 처리
  • 요청을 YarnScheduler로 전달하여 실제 리소스 스케줄링 지원

• 상태 관리: AM의 heartbeat를 추적하고, fault-tolerance를 위해 AMLivelinessMonitor와 함께 동작

• 주 목적

  • RM이 각 AM을 제대로 추적하고, 컨테이너 할당과 상태 관리를 안정적으로 수행하도록 하는 중간 매개 역할
  • 내부 구현 세부 사항보다는 "AM과 RM 사이의 통신 및 상태 관리 담당" 정도로 이해하자

AMLivelinessMonitor

AM들의 live 상태, dead 또는 응답이 없는 AMs 를 관리한다.
heartbeat 를 통해 AM의 live /dead 상태를 확인한다.
Resource manager 로부터 AM을 register/de-register 를 한다.

5.1.4 The core of the ResourceManager – the scheduler and related components

아래 컴포넌트들은 Resource Manager 의 핵심 컴포넌트들이다.

ApplicationsManager
ApplicationsManager 는 submit 된 어플리케이션들을 관리한다.
ApplicationsManager가 완료된 어플리케이션의 캐시를 유지하기 때문에 어플리케이션이 종료된 후에도 WebUI를 통해서 확인하거나 커맨드라인으로 확인할 수 있다.

ApplicationACLsManager

권한제어를 하는 컴포넌트이다. (권한 확인 기준표 정도로 이해하자)
application 마다 허용가능한 ACL 리스트를 유지하고, 해당 어플리케이션에 대한 요청이 올때마다 ACL을 확인한다.

YARN에서 ApplicationACLsManager가 하는 역할

• 각 애플리케이션마다 어떤 사용자나 그룹이 접근할 수 있는지를 정의
• AM이나 RM에 요청이 들어올 때, 이 목록을 확인해서 권한이 있는 요청만 처리
• 예를 들어 WebUI에서 특정 애플리케이션 로그를 보는 권한, 컨테이너 상태 조회 권한 등을 제어

ACL : Access Control List
누가 무엇을 할 수 있는지 권한을 정의한 목록

ApplicationMasterLauncher

새로 submit된 Application Master 를 시작하는 역할을 한다.
스레드풀을 만들어놓고 새로운 요청이오면 풀에서 스레드를 할당해서 요청을 처리한다.
또한 Application이 종료되면 Application Master 자원을 정리하는 역할도 한다.

YarnScheduler

어플리케이션에서 요청한 컨테이너의 capacity 에 맞추어서 리소스를 할당하는 역할을 한다.
memory, cpu, disk, network 자원을 관리하고 할당할 수 있다.

ContainerAllocationExpirer

AM도 어떻게 보면 컨테이너다. AM가 실행하는 각각의 컨테이너도 역시 컨테이너고.
결국 yarn 클러스터에서 실행되는 모든 객체는 컨테이너 위에서 돌아가는 건데, 그런 할당된 모든 컨테이너가 AM에 의해 사용되고, 이후 해당 NM에서 실행되도록 보장하는 역할을 한다.

AM은 신뢰할 수 없는 사용자 코드로 실행되고, 할당된 양을 실제로 사용하지 않을 수 있다. 이런 어플리케이션으로 인해 클러스터 전체의 리소스 사용율이 낮을 수 있다.
이 문제를 해결하기 위해 ContainerAllocationExpirer는 해당 NM에서 여전히 사용되지 않는 할당된 컨테이너 목록을 유지, 관리한다.

모든 컨테이너에 대해 해당 NM이 interval 기간(default 10분) 이내에 컨테이너가 실행된 것을 RM에게 보고하지 않으면 해당 컨테이너는 비활성 상태로 간주되고 RM에 의해 expire된다.

5.1.5 TokenSecretManagers (for security)

보안은 얀 아키텍처의 중요한 부분이다. Yarn은 인증된 RPC 요청만 허용하기 때문이다.
Yarn은 RPC를 호출하는 컴포넌트에게 토큰 혹은 보안키와 같은 인증정보를 발급한다.
인증 정보를 발급 받은 컴포넌트는 해당 정보를 유지하고, RPC 요청을 할 때마다 인증 정보를 함께 포함해서 요청해야한다.
RPC 요청을 하는 컴포넌트 뿐만 아니라, RPC호출을 받는 컴포넌트는 어떤 인증정보를 발급했고, 자신에게 요청된 RPC요청이 유효한 인증 정보를 포함하는지를 알아야 한다.
이것을 위해 제공하는 것이 아래 SecretManager 들이다.

ApplicationTokenSecretManager

RM은 ApplicationTokens 로 애플리케이션 별 권한을 구분하는 토큰을 사용한다. 임의의 프로세스가 RM 스케줄링 요청을 전송하지 않도록 하기 위한 토큰이다.

이 컴포넌트는 어플리케이션이 완료될 때까지 각 토큰을 메모리에 로컬로 저장한다. 이 토큰은 유효한 AM 프로세스에서 수신되는 요청을 인증하는 데 사용한다.

발급하지 않은 Application 토큰을 가지고 리소스 매니저한테 리소스를 달라고 하는 프로세스가 있다고 하면 자원을 받아가지 못한다.

ContainerTokenSecretManager

ContainerTokenSecretManager는 RM이 각 노드(NodeManager)에서 실행될 컨테이너를 위해 AM에게 발급하는 특수한 토큰을 관리하는 컴포넌트이다.

이 토큰은 AM이 해당 컨테이너와 안전하게 통신할 수 있도록 사용되며, 쉽게 말하면 AM과 컨테이너 사이의 안전한 "입장권" 역할을 한다.
토큰이 없으면 AM은 컨테이너를 시작하거나 상태를 확인할 수 없기 때문에, YARN에서 보안 환경을 유지하는 데 필수적이다.

RMDelegationTokenSecretManager

RMDelegationTokenSecretManager는 ResourceManager 전용으로 동작하는 delegation-token 관리 컴포넌트이다.
이 컴포넌트는 RPC를 호출하는 클라이언트를 위해 위임 토큰(delegation-token)을 발급하고, 저장하며 필요 시 갱신하는 기능을 수행한다.

ClientRMService가 이 컴포넌트를 이용해 토큰을 생성하면, 해당 토큰이 클라이언트에게 전달되어 클라이언트가 안전하게 ResourceManager와 통신할 수 있도록 한다.

5.2 노드 매니저

Resource Manager는 Primary 역할을 하는 서버에서만 실행되지만, NodeManager는 Worker 역할을 하는 모든 서버에서 실행된다.
NodeManager는 컨테이너의 실행, 모니터링, 종료와 같은 컨테이너의 라이프 사이클을 관리한다.
NodeManager가 실행되는 서버 자원(cpu, memory, disk, network 등)을 모니터링 하고, 이 상태 정보를 Resource Manager에게 전송한다.
또한 다른 종류의 Yarn 어플리케이션이 활용할 수 있는 보조서비스(auxilary service)를 제공한다.

https://data-flair.training/blogs/wp-content/uploads/sites/2/2016/06/Node-Manager.jpg

5.2.1 NodeStatusUpdater

노드가 시작하면, 이 컴포넌트는 요소는 RM(Resource Manager)에 등록하고 모든 노드에서 사용할 수 있는 리소스에 대한 정보를 보낸다.
후속 NM-RM 통신은 모든 노드의 컨테이너 상태에 대한 업데이트를 교환한다.

또한 RM은 NodeStatusUpdater에 신호를 보내 이미 실행 중인 컨테이너를 kill할 수 있다.

5.2.2 Container Manager

Container Manager는 NodeManager의 핵심 구성 요소로서, 각 노드에서 실행되는 컨테이너를 관리하는 책임을 가진다.
Container Manager 내의 각 구성 요소는 노드에서 실행되는 컨테이너를 관리하는 데 필요한 기능의 하위 집합을 수행한다.

• RPC server- 새 컨테이너를 시작하거나 실행을 중지하기 위해 AM(응용 프로그램 마스터)의 요청을 수락하는 컨테이너 관리자이다.
  컨테이너와 함께 작동하고, 모든 요청을 인증하는 TokenSecretManager이다.
  이 노드에서 실행되는 컨테이너에서 수행되는 모든 작업은 보안 도구에 의해 사후 처리될 수 있는 audit log에 기록된다.

• ResourceLocalizationService- 컨테이너에 필요한 다양한 파일 리소스를 안전하게 다운로드하고 구성하는 역할을 담당한다.
  사용 가능한 모든 디스크에 파일을 배포합니다. 또한 다운로드된 파일에 대한 액세스 제어 제한을 적용하고 적절한 사용 제한을 적용한다.

  • 앞에서 예제에서 AM.jar 라는 자르로 올려 놓고 실제 컨테이너에서 그걸 다운 받아 실행을 했음. 그걸 해주는게 ResourceLocalizationService.

• ContainersLauncher- 가능한 한 빨리 컨테이너를 준비하고 시작할 수 있도록 스레드 풀을 유지 관리한다.
  또한 RM 또는 AM(Application Master)에서 컨테이너를 종료하는 요청이 전송될 때 컨테이너의 프로세스를 정리한다.

• AuxServices- NM은 AuxService로 기능을 확장하기 위한 프레임워크를 제공한다.
  이것은 특정 프레임워크가 요구할 수 있는 노드별 맞춤 서비스를 허용하고 나머지 NM으로부터의 샌드박스를 제공한다.

  • NM(NodeManager)에서 AuxService가 실행될 때, 다른 컨테이너나 시스템 환경에 영향을 주지 않고 안전하게 동작하도록 격리된 공간을 제공한다는 뜻.
    NM이 시작되기 전에 AuxService를 설정해야 한다. AuxService는 응용 프로그램의 첫 번째 컨테이너가 노드에서 시작될 때와 응용 프로그램이 완료될 때 알림을 받아 필요한 초기화나 정리 작업을 수행한다

• ContainersMonitor- 컨테이너가 실행되는 동안 리소스 사용률을 관찰한다.
  메모리와 같은 자원의 분리와 공정한 공유를 시행하기 위해, 각 컨테이너는 RM에 의해 그러한 자원의 일부를 할당받는다.
  Containers Monitor(컨테이너 모니터)는 각 컨테이너의 사용량을 지속적으로 모니터링하며, 컨테이너가 할당을 초과할 경우 컨테이너를 죽이라는 신호를 보낸다.
  이는 폭주 컨테이너가 동일한 노드에서 실행되는 다른 정상적인 컨테이너에 악영향을 미치지 않도록 하기 위해 수행된다.

• LogHandler- 컨테이너의 로그를 로컬 디스크에 보관하거나 함께 압축하여 파일 시스템에 업로드하는 등의 옵션이 있는 플러그형 컴포넌트다.

5.2.3 Container Executor

기본 운영 체제와 상호 작용하여 컨테이너에 필요한 파일 및 디렉토리를 안전하게 배치한 후 컨테이너에 해당하는 프로세스를 안전한 방식으로 시작하고 정리한다.

5.2.4 NodeHealthChecker Service

스크립트를 정기적으로 실행해서 노드 상태를 확인한다. 또한 디스크에 임시 파일을 자주 생성하여 디스크 상태를 모니터링한다.

시스템 상태의 모든 변경 사항은 NodeStatusUpdater에 전달되고, NodeStatusUpdater는 이 정보를 RM에게 전달한다.

5.2.5 Security

• ContainerTokenSecretManager: 컨테이너에 대한 수신 요청을 검사하여 모든 수신 요청이 리소스 관리자에 의해 제대로 인증되었는지 확인한다.