[Hadoop] Yarn (resource manager) - part 1

Hadoop YARN 의 배경

하둡 온디맨드

• 공유 HDFS 내에 존재하는 영속적인 데이터를 공유하기 위한 private computing cluster를 수동으로 배포하고 해체하는 multitenency 이슈를 해결하기 위해 개발된 하둡 플랫폼

• 범용 하드웨어의 공유 클러스터에서 작동하는 하둡 맵리듀스와 HDFS 인스턴스를 프로비저닝하고 관리하는 YARN의 선행 프로젝트

• 단점 :
  데이터 로컬리티 : 맵리듀스 잡트래커는 HDFS 내 입력데이터 인접한 곳에 잡을 배치하려고하지만, HOD의 리소스매니저인 토크sms HDFS에 데이터가 어떻게 분산되어있는지 데이터 로컬리티에 대한 정보가 없기 때문에
  적은 양의 큰 작업과 많은 양의 작은 작업을 야기해 작은 작업들이 호스트에서 동작하게 만들었다.
  토크/마우이의 일시적인 개선으로 랙을 인식하는 방식으로 HDFS 데이터에 대한 위치를 인지하게 만들었지만, 맵리듀스 작업의 셔플이 랙을 통해서 일어나게 되면서 사용자의 워크로드 속도를 현저히 감소시켰다.

  클러스터 이용률 : 아파치 피그와 하이브 등의 햐이레벨 프레임워크는 DAG로 워크플로우를 구성하는데, HOD는 단일 잡이나 잡 사이에 클러스터 조정이 되지 않아 보틀넥이 되는 작업이 종료되지 않은 상태에서는 수백/수천대의 유휴 노드들이 발생하는 이슈가 있다.

  탄력성 : 하둡 워크플로우에서 맵 태스트는 짧고 빠르며, 리듀스 태스크는 과중한 IO로 오래 걸린다. 그러나 HOD는 클러스터를 확장하고 축소하는 방법을 지원하고 있지 않기 때문에 리듀스 태스크가 진행되는 동안 맵 태스크는 모두 종료되어 유휴 노드가 발생해 클러스터 이용률에 영향을 미친다.

공유 맵리듀스 컴퓨팅 클러스터

• HOD의 단점은 다음 단계로의 발전하게 했고, 공유 HDFS 인스턴스에 맵리듀스 클러스터를 공유하는 모델로 전환됐다.

• 단점 :
  확장성 : HOD의 구성요소에서 분리되어 공유 맵리듀스 클러스터에 적용된 잡트래커가 수천대의 이상의 노드를 가진 클러스터로 확장될 떄 잡트래커 하트비트의 지연으로 리소스 락킹이 정상 동작하지 않는 이슈가 생겼다.

  신뢰성과 가용성 : 공유 클러스터를 사용하면서 HOD의 private cluster에서 실행되는 단일워크플로우 장애로 인한 손실이 잡트래커의 장애로 실행중인 모든 잡에 대한 손실을 발생 시켜 신뢰성 이슈가 있었고,
  공유 클러스터에 새 버전의 하둡을 배포할때 발생하는 클러스터 다운타임으로 가용성 이슈가 있었다.

  맵 리듀스 프로그래밍의 오용 : DAG의 형태로 워크플로우가 구성되는 맵리듀스 프로그래밍에 머신러닝 알고리즘과 같이 동일 작업을 여러번 반복해야 결과에 수렴하는 작업을 수행하는 형태로 프로그래밍 되어 DAG가 아닌 방식으로 동작하는 워크플로우의 지원이 필요했다.

  사용자 로그 : 태스크 트래커 데몬에 의해 각 노드에서 일정 기간동안 남아 관리되던 사용자 로그가 개별노드가 죽거나 오프라인일 경우 로그를 손실하게 되는 현상이 발생했다.

YARN

• 'Yet Another Resource Negotiator'의 줄임말로 하둡 클러스터의 하위호환성을 제공하면서 HOD(하둡 온디맨드)와 기존 맵리듀스 클러스터의 단점을 보완 및 해결하여 맵리듀스의 데이터 처리와 자원 스케줄링을 분리해 클러스터 이용률과 확장성을 제공하고 비맵리듀스 어플리케이션을 허용하는 클러스터의 운영체제와 같다.
• YARN 설계 단계에서의 요구사항
  1. 확장성
  2. 사용성
  3. 멀티테넌시
  4. 로컬리티 인식
  5. 클러스터 이용률
  6. 보안 및 모니터링
  7. 신뢰성과 가용성
  8. 다양한 프로그래밍 모델 지원
  9. 유연한 자원 모델
  10. 맵리듀스 하위 호환성