오늘은 YARN이다!
YARN의 구조
Yarn은 하둡의 cluster resource management system이다.
Yarn은 분산저장&처리시스템을 보완해주고 MapReduce 작업의 효율을 높여준다.
YARN은 cluster의 자원을 requesting과 working을 하기위해 API를 제공한다.
여기서 API는 Spark, MapReduce, 등등 분석할 수 있는 알고리즘, 연산을 말한다.
이 API들은 user code에 의해 바로 쓰지 않고 분산컴퓨팅 framework를 위한 condition을 제공한다.
위의 hadoop의 모델처럼 Storage Layer에 HDFS, HBase, Computing 에 YARN, Application에 Spark, MapReduce.
Yarn은 크게 Resource Manager, Node Manager로 두 개로 나뉜다.
Node Manager는 Application Master, Container로 이루어져있다.
Node Manager는 크게 모든 node에 존재하며, node를 실행하고 container를 주시한다.
Application Master는 Resource Manager가 부여하며, 맵리듀스 할건지 spark 할건지 정해준다.
Container는 memory, CPU, 등 자원에 맞춰서 Application Master가 맞춰준대로 application에 맞게 process를 진행한다.
Resource Manager는 cluster의 resource를 관리한다.
YARN의 연산 과정
- YARN 위에 Application을 실행하기위해, client는 Resource Manager를 contact해서, Resource Manager가 NodeManager로 부여한 Application Master를 실행하라고 요청
- Resource Managers 는 Container에 있는 Applicaiton master를 실행할 수있는 NodeManager를 찾음.
- Resource Manager (Application Manger)로부터 맵리듀스 할건지 spark 할건지 요청을 받은 Applicaiton Master가 요청받은대로 Container에게 Application에 맞게 연산하라고 지시한다.
- Container는 연산을 진행을 하고 연산이 끝나면 Client에게 return한다. 만약에 연산이 더 필요하면, Application Master 가 ResourceManager에게 resource를 allocate 받기 위해 heartbeat를 보낸다.
- Application Master는 분산 컴퓨팅을 하기 위해 다른 Container를 사용한다.
YARN이 하는 역할!
- YARN은 resource Request 하는 유동적인 모델이다.
- Container가 요청하는 Request는 컴퓨터 자원의 양을 표현하고 container를 위한 locality constraint에 도움을 준다.
- Locality : 비슷한 속성을 가지는 data 들 끼리 근처에 모여있는 것을 말한다.
- Locality가 되어야 분산 프로세싱 알고리즘에서 cluster의 bandwidth를 효과적으로 사용한다 라는 보장에 힘을 실어준다.
- 따라서 locality constraint는 Container 보고 특정 node, rack, off-rack에 data를 보내는 요청을 하게 만든다.
- YARN Application들은 resource request를 그때그때마다 요청한다. (Spark)
YARN이 version_1과 다른 점
위에 그림을 보면, JobTracker가 현재 Resource Manager, Application Master 두개를 분리를 하였으며,
추가적으로 timeline server도 추가 시켰다. timeline server는 History가 쌓인 것을 관리한다.
나머지 TaskTracker -> NodeManager, Slot -> Container 로 바뀜을 알 수 있다.
이렇게 바뀜으로써 흔히 4가지 성능을 높일 수 있었다.
Scalability
YARN은 version_1보다 큰 cluster를 연산한다.
version_1에서는 JobTracker가 많은 역할을 하다보니 bottleneck이 형성되었다.
그래서 YARN에서는 JobTracker를 ResourceManager, Application Manager로 분리하였다.
따라서 YARN에서 scale-up이 가능했던 이유이다.
실제로 version_1에서는 4000 node, 40,000 task -> 10,000 node, 100,000 task로 발전하였다.
Availability
HA (High Availability)는 서비스를 제공하는 daemon failing이 일어날 때, 서비스를 이어나가기 위해
다른 daemon에 현재의 상태를 replicating을 하는 것을 말한다.
하지만 JobTracker는 여러 기능들이 모여 있었기 때문에, state가 복잡하고 빠르게 바뀌며, HA를 이루는 것은
매우 힘들다고 볼 수 있다.
YARN으로 업그레이드하며 JobTracker가 가지지 못하는 HA를 YARN이 이뤄냈음을 알 수 있다.
Utilization
JobTracker는 fixed-size slot을 static allocation을 통해 configure했다.
이 말은 Map Task는 Map만, Reduce Task는 Reduce만, 진행한다는 의미이다.
여기서 Trade-off는 Map이 진행이 되는 동안 Reduce Task는 놀고있는 것이다.
이를 보완하여, YARN은 dynamice allocation을 통해서 resource를 slot이 아닌 pool로 manage한다.
연결 풀[1] 또는 커넥션 풀(connection pool)은 소프트웨어 공학에서 데이터베이스로의 추가 요청이 필요할 때 연결을 재사용할 수 있도록 관리되는 데이터베이스 연결의 캐시이다. 연결 풀을 사용하면 데이터베이스의 명령 실행의 성능을 강화할 수 있다. 각 사용자마다 데이터베이스 연결을 열고 유지보수하는 것은 비용이 많이 들고 자원을 낭비한다. 연결 풀의 경우 연결이 수립된 이후에 풀에 위치해 있으므로 다시 사용하면 새로운 연결을 수립할 필요가 없어진다. 모든 연결이 사용 중이면 새로운 연결을 만들고 풀에 추가된다. 연결 풀은 사용자가 데이터베이스에 연결을 수립하는데까지 대기해야하는 시간을 줄이기도 한다.
한 마디로 pool을 빈 공간이라고 생각하면된다.
빈 공간에 처음 연산인 Map을 많이 할당해서 넣고 Reduce를 소량 넣는다. (Map마다 끝나는 시간이 다르기 때문)
Map이 일정이상 끝났다면, Reduce Task를 할당해서 dynamic allocation을 이뤄낼 수 있다.
따라서 Reduce Task가 cluster에서 놀지 않는다는 장점, 최대한 Utilization이 되었다라고 할 수 있다.
Multitenancy
YARN의 큰 장점 중 하나는 여러 Application들을 hadoop에서 동시에 올릴 수 있다는 것이다.
MapReduce는 단순히 YARN의 Application에 그치지 않는다.
YARN cluster 위에서 각자 다른 버전의 MapReduce를 run 할 수 있다.
Scheduling in YARN
FIFO Scheduler :
FIFO (First-In-First-out) Scheduler는 순서가 정해져있기 때문에 configuration에 있어서 최적화라는 장점이 존재한다.
단점은 다른 job들이 실행하지 못하고, 그만큼 대기시간이 길기 때문에 비효율적이다.
Capacity Scheduler는 queue를 하나 더 할당해서 여러 job을 run 가능한 장점이 존재한다.
단점은 queue를 미리 할당하다보니, job2 가 실행되지 않을 때는 bandwidth 낭비가 존재한다.
Fair Scheduler는 job이 들어올 경우 유동적으로 queue를 분배한다. 그래서 bandwidth 낭비 없이 사용이 가능하다.
단점은 그만큼 configuration이 너무 어렵다.
우리는 FIFO Scheduler, Capacity Scheduler, Fair Scheduler 여러 스케쥴러가 있지만, 각자 장,단점이 존재한다. 그 단점을 낮추고 장점에 맞춰서 어떤것이 나랑 맞는지 생각해볼 필요가 있다.
Delay Scheduling
모든 YARN scheduler들은 locality request를 보장하려한다.
busy한 cluster에서는 만약 application이 특정 node에 request를 한다면, 다른 컨테이너가 해당 노드에서 run할 것이다.
그 이유는 이미 cluster에 모든 연산이 돌아가기에, 특정 node를 정해도 다른 node에서 돌아간다는 말이다.
따라서 같은 rack으로 container를 부여받기 위해, cluster가 바쁘다면 locality requirement를 늘려서
data를 같은 local에 두어 접근이 쉽게 해 성능이 좋게하는 Data Locality를 보장하기 위해
같은 rack에 container 를 부여한다.
결국 Data Locality를 최대한 보장하기위해 아무 node에 부여하는 것이 아니라, 조금 기다렸다가 scheduling
하는 것을 Delay Scheduling이다.
Summary
'대학원 공부 > computer science' 카테고리의 다른 글
linux : windows에서 .sh 파일 실행하기 (0) | 2019.10.29 |
---|---|
Computer Structure : CPU vs GPU 차이점 (0) | 2019.10.28 |
Big Data : Hadoop : lecture_2 : Hadoop_basic_1 (0) | 2019.10.26 |
Big Data : Hadoop : lecture_1 : Overview of Hadoop (0) | 2019.10.25 |
Big Data : Hadoop : WordCount 예제 (0) | 2019.10.25 |
댓글