YARN

YARN은 (Yet Another Resource Negotiator) 하둡의 클러스터 자원관리 시스템이다. YARN은 수백, 수천개의 노드로 구성된 클러스터에서 작업이 제출되면 수많은 작업들을 관리하고, 특정 작업에 사용할 자원(CPU, RAM)을 관리해주는 분산자원관리 기능을 담당한다.

YARN의 특징

• YARN 은 클러스터 자원을 요청하고 사용하기 위한 API 를 제공하지만, 사용자가 직접 API 를 사용할 순 없고, 고수준의 API 만 사용 가능하다. 따라서 사용자는 자원 관리의 자세한 내용은 알 수 없다.

• YARN 이 제공하는 서비스는 Resource Manager , Node Manager 두 가지 장기 실행 데몬을 통해 이루어진다.
  RM 은 클러스터 전체 자원의 사용량을 관리한다.
  모든 머신에서 실행되는 NM는 컨테이너를 구동하고 모니터링한다.

• 자원의 사용 한도(메모리나 CPU)를 갖는 애플리케이션 프로세스는 컨테이너에서 실행된다. 컨테이너는 리눅스의 cgroup 이나 Unix 프로세스 라고 한다.

• 각 NM 는 주기적(기본 1초)으로 RM 에게 하트비트를 보낸다.
  이를 통해 NM 가 실행중인 컨테이너의 정보와, 새로운 컨테이너를 위한 가용 자원에 대한 정보를 주고받는다.

1. Resource Manager

Resource Manager는 Resource Allocation에 대한 최상위 권위자로, 어디에 자원을 할당할지 결정하여 Cluster들의 활용을 최적화시킨다. 또한 일에 대한 처리 요청을 받으면, Request들의 일부를 해당하는 Node Manager로 전달한다. 이러한 역할을 수행하는 Resource Manager는 크게 2가지로 구성되는데, Scheduler와 Applications Manager이다.

1) Scheduler

Scheduler는 Capacities(용량), Queue(대기줄) 등의 제한조건에 따라 실행중인 다양한 Applications들에 자원을 할당한다. Resource Manager의 Scheduler는 Application의 상태를 추적하거나 모니터링하지 않는, 순수한 Scheduler이다. 또한 순수한 스케줄러이기 때문에 Hardware failures나 Application failures에 의한 재시작 역시 보장하지 않으며, Application들의 자원 요구에 기반하여 Scheduling 기능을 수행한다. 이것은 메모리, CPU, 디스크, 네트워크와 같은 요소들을 포함하는 (resource) Container를 기반으로 작동한다.
또한 Scheduler는 Plug-in Policy를 사용하는데, 현재는 Capacity Scheduler와 Fair Scheduler를 플러그인으로 사용한다. Capacity Scheduler는 Larger Cluster를 여러 사용자가 함께 사용하는 Multi-tenancy를 구현하여 할당된 용량의 제한하에 적시에 Application들에 응용을 할당할 수 있게 해준다. Fair Scheduler는 YARN으로 하여금 Larger Cluster들이 공평하게 자원을 공유할 수 있게 해준다.

2) Applications Manager

Applications Manager는 Job의 제출을 수락하고, Application Master를 실행하기 위한 첫번째 컨테이너를 설정하고 실패 시 Application Master의 Container를 재시작하게 해준다. Application Master는 Scheduler를 통해 적합한 Container를 선정하고, 그것을 Tracking하고 진행 상황을 모니터링하는 역할을 수행한다.

2. Node Manager

Node Manager는 개별 노드들을 관리하고 주어진 노드에서 사용자의 작업 및 Work Flow를 관리한다. Node Manger는 Resource Manager에 등록되며 노드의 상태를 판별하기 위한 heartbeats를 전송한다. 그 중에서 Node Manager의 가장 중요한 임무는 Resource Manager을 통해 할당받은 Container를 관리하는 것이다. Container의 자원 사용량을 감시하고, 이를 Resource Manager로 보내는데, 문제가 발생한 경우 Resource Manager로부터 Container를 Kill하라는 명령을 받아 수행하기도 한다.

3. Application Master

여기서 말하는 Application은 프레임워크에 제출된 단일 작업을 의미하며, 각각의 단일 작업은 고유한 Application Master를 지니게 된다. Application Master는 클러스터에서 응용의 실행을 조정하고 오류를 관리한다. 또한 Node Manager와 함께 작동하여 Task를 실행시키고 모니터링하며 Resource Manger를 통해 자원을 협상한다. 자원을 협상한 후에는 Resource Manager로부터 적당한 Resource(conatiner)를 할당받고 그것들의 상태를 추적하고 모니터링한다. 한번 Application Master가 실행되면 주기적으로 Resource Manager에 heartbeats를 전송하여 상태를 확인시켜주고, 자원의 요구사항을 갱신한다.

4. Container

Container는 하나의 노드에 할당받은 자원들로, Container Life Cycle(CLC)에 해당하는 Container Launch Context를 통해 관리된다. 레코드에는 환경 변수 맵, 원격 액세스 가능한 스토리지에 저장된 종속성, 보안 토큰, 노드 관리자 서비스의 페이로드 및 프로세스를 만드는 데 필요한 명령이 포함된다. 또한 Container는 특정 호스트에서 특정 양의 자원 (메모리, CPU 등)을 사용하도록 응용 프로그램에 권한을 부여한다.

YARN 애플리케이션 구동 요청과정

1. Client 가 RM 에게 애플리케이션 실행을 위한 Application Master의 구동을 요청한다.

2. RM 이 컨테이너에서 AM 을 시작할 수 있는 NM 를 하나 찾는다.

   • AM 이 딱 한 번만 실행될지 아닐지는 애플리케이션마다 다르다고 한다.

3. AM 에서 애플리케이션이 단일 컨테이너에서 실행하고 그 결과값을 Client 에게 넘길 수도 있고(우버) RM 에게 더 많은 컨테이너를 요청한 후 분산 처리를 수행할 수도 있다.

• YARN 자체는 Client, Masters, Process 와 같은 애플리케이션이 서로 통신하는 기능을 제공하진 않는다. 대부분 주요 YARN 애플리케이션은 하둡의 RPC 같은 원격 호출 방식을 이용하여 상태 변경을 전달하고 Client 로부터 결과를 받는다.

• YARN 에서 다수의 컨테이너를 요청할 때 각 컨테이너에 필요한 자원(메모리나 CPU 등)의 용량 뿐 아니라 해당 요청에 대한 컨테이너의 지역성 제약도 표현 가능하다.

• 애플리케이션이 필요한 복제본을 저장하고 있는 노드에 컨테이너를 요청했을 때, 그 노드에서 컨테이너를 시작할 수 없으면 동일한 랙의 다른 노드에서 컨테이너를 시작하려고 시도하고, 그 마저도 시작이 불가능하면 클러스터의 임의 노드에서 다시 시도한다.

• 이로 미루어 보아, 여기서 말하는 지역성 제약이라는 건 데이터 지역성이 적용되는 노드에 컨테이너를 구동하는 걸 말 한다.

• YARN 애플리케이션은 실행 중에 아무 때나 자원 요청이 가능하다. Spark 의 경우 처음 할당 받은 컨테이너에서 executor 를 구동하고, 추가적인 자원을 요청하지 않는다. 그 이유는 처음에 모든 요청을 다 했기 때문이다.

• Spark 의 경우 YARN 에서 제공하는 컨테이너를 재사용한다.

YARN의 스케줄링 방식

YARN 애플리케이션의 수명은 사용자가 실행하는 job 의 방식에 따라 달라진다.

Capacity Scheduling

• Capacity Scheduling은 큐 탄력성을 이용한다.

  • Queue A 50% 와 Queue B 50% 가 있다고 하자.
  • QA 에서 큰 애플리케이션이 구동되고 있지만 QB 에서는 아무런 애플리케이션도 구동되지 않고 있다.
  • 이 때, QB 의 자원이 놀고 있기 때문에 QA 는 QB 의 자원까지 빌려서 큰 애플리케이션을 처리할 수 있다.
  • 이것이 큐 탄력성이다.

• 만약 QA 에 maximum-capacity 가 70으로 제한되어있다면, QB 에게서 20(70-50=20) 만큼의 자원만 빌릴 수 있다.

• 또한, QA 에서 Queue 를 다시 나눌 수 있다. 이를테면 QA 내의 자원을 40, 60 씩 이용하는 Queue A-1, Queue A-2.

• Hadoop 버전에 따라 다르지만, 일반적으로 기본 스케줄러는 Capacity 이다.

Fair Scheduler

• Fair Scheduler 내에 여러 Queue 들이 무조건 Fair 여야 할 필요는 없다. 어떤 Queue를 Fifo policy 에 따라가도록 만들 수도 있다.

• Fair Scheduler 는 애플리케이션을 Queue에 분배할 때, 규칙에 따라 분배한다.

규칙은 사용자가 직접 넣을 수 있다.
다음과 같은 규칙을 사용자가 만들었다고 하자.

<queuePlacementPolicy>

  <rule name = "specified" create="false"/>

  <rule name = "primaryGroup" create="false"/>

  <rule name = "default" queue="dev.eng" />

</queuePlacementPolicy>

애플리케이션을 처음 실행할 때 어떤 Queue에 분배할 건지 가장 위에 있는 specified 규칙부터 살펴본다. 규칙은 위에서 아래로 순차적으로 적용되며, 규칙에 해당되지 않으면 다음 규칙을 적용한다.

• specified 는 지정된 큐에 애플리케이션을 배치한다.
  • 지정된 큐가 없거나 큐를 따로 지정하지 않았으면 이 규칙은 적용되지 않고 다음 규칙을 살펴본다.
• primaryGroup 은 사용자의 유닉스 그룹의 이름을 갖는 큐에 애플리케이션을 배치한다.
  • 큐가 존재하지 않으면 큐를 자동으로 생성하는 대신 다음 규칙을 살펴본다.
• default 는 catch-all로, 항상 dev.eng 큐에 애플리케이션을 배치한다.

규칙은 위에서 아래로 순차적으로 적용되며, 규칙에 해당되지 않으면 다음 규칙을 적용한다.
기본 규칙은 다음과 같다.

<queuePlacementPolicy>

  <rule name = "specified"/>

  <rule name = "default"/>

</queuePlacementPolicy>

• 즉, 큐를 명시하지 않으면 사용자 이름의 큐를 사용한다(사용자 이름의 큐가 없으면 자동 생성)

Delay Scheduling

• 바쁜 클러스터에서 애플리케이션이 데이터 지역성 이점을 얻기 위해 특정 노드를 요청하면, 요청하는 시점에 그 노드에 다른 컨테이너가 실행되고 있을 가능성이 농후하다. 지역성 요구 수준을 조금 낮춰 동일한 랙에 컨테이너를 할당할 수도 있지만, 요청한 특정 노드에서 실행되고 있는 컨테이너가 끝날 때 까지 (몇 초보단 길지만) 기다리면 요청한 노드에서 컨테이너를 할당받을 수 있는 기회가 주어진다.
  이렇게 하면 클러스터의 효율성도 높아진다. Fair, Capacity Scheduler 모두 이러한 Delay Scheduling 기능을 제공한다.