1. YARN Scheduler

클러스터 Scheduler 가 갖춰야 할 조건

1. Multi-tenency

 - 자고로 클러스터라 함은 많은 사용자들이 다양한 어플리케이션을 돌리게 마련인데, 클러스터는 이렇게 다양한 workload 를 일제히 돌릴 수 있어야 한다.

2. Scalability

마찬가지로 많은 Application 이 돌고 있는 상황에서도 클러스터의 사이즈를 늘릴 수 있어야 한다. 어떠한 부정적인 현상이 발생하지 않은채로!

Scheduler

YARN 에서의 스케쥴링은 RM 이 클러스터의 리소스를 트래킹하고, 리소스를 필요로 하는 job 에 이를 할당한다. 즉, 스케줄러는 RM 기능의 일부분이고, 어떠한 정책에 의해서 이를 결정하게 된다. YARN 은 이렇게 공통의 리소스를 큐를 이용해서 관리하는데, 큐의 자세한 내용은 다음에 알아보도록 하겠다. 그리고 AM 이 task 의 리소스를 NM 에게 container 와 리소스 할당을 요청하게 된다. 이러한 접근은 RM 이 모든 컨테이너를 트래킹할 필요가 없기 때문에 Scaling 하는데 도움이 된다.

YARN 스케줄러에는 Fair 스캐줄러와 Capacity 스캐줄러가 존재한다. 아래서 그 두가지에 대해 살펴보기로 하자.

Fair 스캐줄러

YARN 스케줄러 중에 가장 인기있게 쓰이는 스케줄러 입니다. 이것은 큐내의 모든 잡이 공평하게 리소스를 점유하는 방식이다.

Hierarchical Queues

가장 최상단 Parent Queue 에는 Root Queue 가 있다. 그리고 위 설정에 의하면 Root 의 자식 Queue 로 Datascience, Sales, Marketing Queue 가 있는것이다. Datascience, Sales, Marketing Queue는 각각

• datascience > short_jobs
• sales > northamerica, europe
• marketing > reports, website

의 자식 Queue 를 가지고 있다. 이는 fair-scheduler.xml 파일에 xml 형태로 설정한다. weight 값은 상대적인 값이고, 동일 Level 에 있는 Queue 들의 weight 을 모두 더하면 부모 Queue 의 100% Resource 와 동일하다.

예시 ) marketing queue 의 자식 queue 인 reports => 40.0, website => 20.0 의 weight 을 가지고 있다. 즉 Marketing 이 가지고 있는 총 Resource 에서 40.0 / 40.0 + 20.0 의 Resource 를 점유할 수 있고, website 는 20.0 / 40.0 + 20.0 의 Resource 를 점유할 수 있는 것이다.

Fair 스케줄러 종류

• FairSharePolicy (default) : 공평하게
• FifoPolicy : 먼저 들어온것 부터
• DominantResourceFairnessPolicy : CPU 와 Memory 사용량에 따라 CPU 를 많이 쓰는 job 은 vcores 를 많이 할당해주고, Memory  를 많이 쓰는 job 은 memory 를 많이 할당해주는 방식

FairSharePolicy vs FifoPolicy

2개의 Queue 가 있다고 가정하자. 하나는 FairSharePolicy, 다른 하나는 FIFO Policy 로 적용되어 있다고 가정하자. 그리고 유저는 각각의 큐에 3개의 잡을 Submit 한다. 첫 번째 job 을 submit 하고 바로 두번째 job 을 submit 한다. 그리고 충분히 ( 2개의 잡이 정상적으로 잘 작동할때까지) 기다린 후 3번째 job 을 submit 한다. 

 첫번째 job 은 resource limit 의 6배, 두번째 잡은 4배, 3번째 잡은 2배라고 가정하겟다.

• FIFO : 1번째 잡이 다 끝나야 2번째 잡이 시작한다. 그리고 2번째 잡이 끝나야 3번째 잡이 시작된다.
• Fair Share : 3개의 잡이 모두 동시에 run 될수 있다. 각각의 잡은 유휴한 Resource 의 1/3 씩을 가지고 시작이 될것이다.

2. Capacity 스케줄러 ( Cloudera Manager 에서는 제공하지 않음 )

Queue 마다 각자의 Capacity 를 정할 수 있다. 단, Queue 가 현재 유휴한 자원보다 더 큰 자원을 요구하는 job 이 들어온 경우에 동일 레벨의 Queue 에 유휴 자원이 존재한다면 그 자원을 "우선" 빌려서 job 을 실행할 수 있다. 이 경우 문제가 우선 "대여"를 해준 Queue 에 새로운 job 이 들어오면 이전의 job 이 끝날 때까지 그 자원을 사용할 수 없다. FIFO 방식으로 처리 되기 때문이다.

 이 경우 문제되는 것이 abusive user 가 자꾸 Many Resource 를 필요로 하고 Long Time 한 job 을 보내게 되면 해당 Queue 와 동일 Level 에 있는 Queue 들은 job 이 pending 되는 현상이 발생한다. 그래서 yarn.scheduler.capacity.{{Queue full path}}.maximum-capacity 설정을 통해 내가 부모 Queue Capacity 의 몇 퍼센트를 최대로 먹을 수 있는지 설정하게 된다.

참고로 우리 회사에서는 Capacity 보다는 Fair 스케줄러를 쓰는데 Capacity 스케줄러의 문제가 동일 계정의 User 가 job 을 연속적으로 날리게 되면 job 이 FIFO 방식으로 처리 되어 뒤에 날린 job 이 pending 되어 Fair 스케줄러를 쓴다.

---

ㅁ 참조

http://blog.cloudera.com/blog/2017/02/untangling-apache-hadoop-yarn-part-5-using-fairscheduler-queue-properties/

http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.2/bk_yarn_resource_mgt/content/flexible_scheduling_policies.html

http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.3.2/bk_yarn_resource_mgt/content/resource_distribution_workflow.html