Hadoop2 ) YARN

날짜:


하둡 1 VS 하둡 2 


  • 하둡은 에코시스템 환경이 중요한데(하둡 하나만으로는 부족) 하둡클러스터에서 하둡 에코시스템이 적절하게 시스템 자원을 분배받고, 할당된 자원이 모니터링 되고 해제 되어야했음 (여기서 자원은 무엇을 뜻하냐...? 스톰과 카프카만 봐도 주키퍼에 등록되어서 사용되는 걸보니... 스케줄링 인것인가) 
  • SPOF(Single Point Of Failure, 단일 고장점) : 네임노드 서버 하나에서 모든 데이터노드들의 메타데이터를 관리하고 스케줄링하는데 만약 이 하나의 서버가 장애가 오면 그 네임노드가 구성하는 하둡 클러스터는 고장이남. 네임노드의 이중화가 필요


YARN(Yet Another Resource Negotiator, 또다른 리소스 협상가)


  • 하둡 1의 맵리듀스 프레임워크는 무조건 맵리듀스 API로 만든 프로그램만 실행할 수 있었음 하지만 YARN은 맵리듀스 외에 다른 종류의 애플리케이션도 구현가능(예를 들어 Spark on yarn, yarn과 비슷한 개념> 톰캣 서버를 통해 여러 종류의 웹 애플리케이션 실행 가능) 
  • 왜 YARN을 개발했지?
    • 맵리듀스 SPOF 
      • 잡트래커(모든 맵리듀스의 잡실행 요청 받음, 전체 잡의 스케줄링 및 리소스 관리)가 돌아가지 않으면 테스크트래커가 작동중이라도 맵리듀스를 사용 못함
      • 잡트래커의 메모리 이슈
        • 잡트레커는 메모리 상에 전체 잡의 실행 정보를 유지하고 맵리듀스의 잡 관리에 활용함.
        • 즉 메모리에 많은 정보를 입력하다 보니 많은 메모리가 필요해짐 
        • 만약 잡트래커에 메모리가 부족하면 잡트래커는 잡의 상태 모니터링을 못하고 새로운 잡도 실행 요청 못함 
        • SPOF
    • 맵리듀스 리소스 관리 방식 
      • 맵리듀스는 슬롯이란 개념으로 클러스터에서 실행할 수 있는 태스크의 개수를 관리 즉, 태스크 수행 단위
        • 슬롯은 넣다 라는 뜻. 그러니까 한번에 실행되는 태스크들의 묶음 이라고 볼 수 있지 않을까?(다빈 피셜)
    • 맵 슬롯과 리듀스 슬롯으로 구분되는데 실행중인 잡이 맵슬롯만 사용하고 있거나 리듀스 슬롯만 사용한다면 다른 슬롯은 잉여자원이 되서 리소스가 낭비
    • 맵리듀스 리소스는 맵리듀스 기반의 프레임워크만 자원을 공유해서 다른 에코시스템은 자원을 공유할 수 가 없음(여기서 자원이란...?)
  • 클러스터 확장성
    • 최대 단일 클러스터 4000대, 최대 동시 실행 태스크는 40,000개
    • 맵과 리듀스 로 정해진 구조 외에 다른 알고리즘을 지원하는데 한계가 있음 
  • 버전 통일성
    • 맵리듀스 잡을 실행하는 클라이언트(사용자가 만든 맵리듀스 프로그램+하둡에서 제공하는 맵리듀스 API)와 맵리듀스 클러스터 버전이 반드시 동일해야함 



YARN의 목표 


  • 잡트래커의 주요기능 추상화 
    • 잡트래커의 주요 기능인 클러스터 자원 관리와 애플리케이션 라이프 사이클 관리를 분리 했음 
  • 다양한 데이터 처리 애플리케이션 수용
    • 기존 맵리듀스는 반드시 맵리듀스 API로 구현된 프로그램만 실행
    • 벗 얀에서 맵리듀스는 실행되는 애플리케이션들 중 하나일 뿐

YARN의 특징 

  • 확장성 
    • 수용가능한 단일 클러스터 규모가 10000 노드까지 확대됨 (전보다 두배 이상) -> 데이터 처리 작업의 개수도 증가
  • 클러스터 활용 개선
    • 자원관리를 위해 리소스 매니저라는 새로운 컴포넌트 개발 
    • 리소스 매니저는 실제로 사용 가능한 단위로 자원을 관리(CPU, 메모리, 디스크, 네트워크 등)하는데 얀에서 실행되는 애플리케이션에 이 자원을 배분함
    • 개별 에코시스템의 자원 배분을 고민하지 않아도 됨
  • 워크로드(발생하는 모든 작업) 확장
    • 얀은 맵리듀스, 인터랙티브 질의, 실시간 처리, 그래프 알고리즘 등 다양한 형태의 워크로드 확장이 가능   



  • 맵리듀스 호환성

    • 기존 맵리듀스 프로그램을 그대로 얀에서 사용가능(얀에 맵리듀스 포함되어 있으니까) 

YARN 아키텍쳐



  • 리소스 매니저
    • 글로벌 스케줄러 --> 자원관리만 한다 
    • 전체 클러스터에서 사용할 수 있는 모든 시스템 자원들(CPU, 메모리, 디스크, 네트워크 등)을 관리 
    • 얀 클러스터에서 실행되는 프로그램이 리소스를 요청하면 적절하게 분배하고 리소스 사용 상태를 모니터링함
    • 얀의 마스터 서버로 하나 또는 이중화를 위해 두개의 서버에만 실행됨
  • 노드매니저 
    • 얀의 worker 서버
    • 리소스 매니저를 제외한 모든 서버에서 실행 
    • 컨테이너를 실행시키고, 컨테이너의 라이프 사이클을 모니터링 
      • 컨테이너 장애상황
      • 컨테이너가 요청한 리소스 보다 많이 사용하고 있는 지 감시(요청한 리소스보다 더 많이 사용하면 해당 컨테이너 kill)
    • 컨테이너(뜻 : 개발, 운송 및 배포를 위해 소프트웨어를 표준화된 단위로 패키징)
      • 노드매니저가 실행되는 서버의 자원을 표현(CPU, Disk, Memory, Network..) 
      • 리소스 매니저가 요청에 의해 컨테이너가 실행된다. 
      • 하나의 서버에 여러 컨테이너 있을 수 있음 
      • 맵리듀스의 태스크트래커가 태스크 단위로 잡을 실행한것 처럼--> 노드매니저는 컨테이너를 단위로 애플리케이션을 실행하고 각 상태를 스케줄링
  • 애플리케이션 마스터  
    • 하나의 애플리케이션(프로그램)을 관리하는 마스터서버 
    • 클라이언트가 얀에 애플리케이션 실행을 요청하면 얀은 하나의 애플리케이션에 하나의 애플리케이션 마스터를 할당 
      • 얀 클러스터에 1. 맵리듀스 잡 과 2. 스톰 애플리케이션 실행을 요청하면 두개의 애플리케이션 마스터가 실행
    • 애플리케이션에 필요한 리소스를 스케줄링
    • 노드매니저에게 애플리케이션에 필요한 컨테이너를 실행시킬것을 요청
      • 애플리케이션 마스터 -요청-> 리소스매니저 -자원할당-> 노드매니저 -실행-> 컨테이너
    • 애플리케이션 마스터는 컨네이터에서 실행됨(컨테이너는 자원. 애플마스터는 자원을 요청해서 쓰는거니까)

댓글

댓글 쓰기