[Hadoop] 하둡 완벽 가이드 필기 - YARN

 

하둡 완벽 가이드 책에서 YARN 에 대해 공부 한 내용을 여기 적는다.

 

 

- YARN 은 클러스터 자원을 요청하고 사용하기 위한 API 를 제공하지만,

사용자가 직접 API 를 사용할 순 없고, 고수준의 API 만 사용 가능하다.

따라서 사용자는 자원 관리의 자세한 내용은 알 수 없다.

 

- YARN 이 제공하는 서비스는 Resource Manager , Node Manager 두 가지 장기 실행 데몬을 통해 이루어진다.

RM 은 클러스터 전체 자원의 사용량을 관리한다.

모든 머신에서 실행되는 NM는 컨테이너를 구동하고 모니터링한다.

 

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

컨테이너는 리눅스의 cgroup 이나 Unix 프로세스 라고 함.

 

- 각 NM 는 주기적(기본 1초)으로 RM 에게 하트비트를 보낸다.

이를 통해 NM 가 실행중인 컨테이너의 정보와, 새로운 컨테이너를 위한 가용 자원에 대한 정보를 주고받는다.

 

- 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 애플리케이션의 수명은 사용자가 실행하는 job 의 방식에 따라 달라진다.

 

- 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 내에 여러 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 기능을 제공한다.

 

 

아래는 Hadoop MR 의 상황을 전제로 하는 설명임.

- NM 위에서 실행중이던 Task 가 실패하는 상황에서 어떤 일이 벌어지는지 알아본다.

사용자 코드가 Runtime error 를 뱉거나, JVM 이 갑자기 종료되는 등의 연유로 task 가 실패할 수 있다.

NM 는 task 가 실패 한 것을 알아차리고 AM 에게 에러를 보고한다.

이 에러는 사용자 로그에 최종적으로 기록되며, AM은 해당 task 를 실패로 표시하고

해당 리소스를 다른 task 에서 사용할 수 있도록 컨테이너를 풀어준다.

task 가 멈춘 경우(동작은 하는데 그냥 딜레이가 지속되는 경우)

AM 은 task 의 진행 상황을 받지 못함을 알게 된 후 얼마동안(보통 10분) 기다렸다가

해당 태스크를 실패로 표시한다.

AM 은 멈춘 task 를 다시 스케줄링 한다.

동작하다가 멈췄던 노드 외에 다른 노드 위에서 task 가 실행되도록 스케줄링을 다시 한다.

만약 이러한 동작이 4번 반복되면 재시도(스케줄링)를 하지 않고 전체 job 이 실패한 것으로 간주한다.

 

- AM 이 실패하는 상황에서 어떤 일이 벌어지는지 알아본다.

AM이 실패하면, Am 이 주기적으로 하트비트를 보내던 RM 이 AM의 실패를 알아차린다.

RM 은 다른 NM 위에 새로운 컨테이너에서 AM을 새롭게 시작한다.

YARN 위에서 동작하는 애플리케이션이 실패하면 재시도를 하게 되는데,

mapreduce.am.max-attempts 값 만큼 재시도한다.

default value is 2

YARN 위에서 동작하는 모든 AM 에 대해 일괄적으로 최대 시도 횟수의 제한을 줄 수 있다.

각 애플리케이션은 이 횟수를 넘길 수 없다.

yarn.resourcemanager.am.max-attempts 로 설정 가능하며 기본값은 2이다.

따라서 AM 의 시도 횟수를 늘리고싶다면 yarn 설정값을 늘려야 한다.

 

- NM 가 실패하는 상황에서 어떤 일이 벌어지는지 알아본다.

NM 이 실패하거나 굉장히 느리게 수행 중이라면,

RM 로 하트비트 전송하는 것이 중단되거나 굉장히 느리게 전송한다.

RM 은 NM 로부터 10분 동안 하트비트를 받지 못하면 해당 NM 를

컨테이너를 스케줄링하는 노드 풀에서 제거한다.

....

 

- RM 이 실패하는 상황에서 어떤 일이 벌어지는지 알아본다.

RM 이 실패하면 job 이나 태스크 컨테이너를 실행할 수 없기 때문에 굉장히 치명적이다.

HA(고가용성)을 달성하기 위해 Standby RM 을 대기시키는 것이 좋다.

새로운 RM 가 시작되면 상태 저장소(HDFS, Zookeeper) 로부터 애플리케이션 정보를 읽고

클러스터에서 실행 중인 모든 애플리케이션의 AM 을 재시작한다. 

Standby RM 을 Active 로 전환시키는 것은 장애 극복 관리자 failover controller 가 담당한다.

주키퍼가 제공하는 리더 선출 기능을 사용하여 active 가 될 standby RM 을 선택한다.

failover controller 는 RM 이 내부적으로 지니고 있는 기능이다. 

Client 와 NM 는 새롭게 Active 가 된 RM 을 찾기 위해 많은 Standby RM 들을

round robin 방식으로 돌아다니며 연결을 시도한다.