YARN의 내부동작

리소스 매니저

앞서 설명했듯이 클러스터마다 존재하는 리소스 매니저는 클러스터 전반의 자원관리와 잡들의 스케줄링을 담당합니다. 그런데 여기서 스케줄링이라 함은 자원요청에 맞춰 잡을 실행해도 된다는 허가를 해준다는 의미이지 이 잡의 실행여부를 끝까지 책임진다는 것은 아닙니다(이는 뒤에서 설명할 애플리케이션 마스터의 역할입니다). 이 스케줄러의 경우에는 하둡 1.0처럼 플러그인 구조를 갖고 있어서 필요하다면 다른 형태의 스케줄러를 만들어 사용할 수 있습니다. 뒤의 “YARN 실행과정에서 좀더 자세히 설명하겠지만 리소스 매니저는 클라이언트로부터 애플리케이션 실행 요청을 받으면 그 애플리케이션의 실행을 책임질 애플리케이션 마스터를 실행해줍니다.

 

리소스 매니저는 클러스터내의 서버마다 설치된 노드 매니저(뒤에서 설명합니다)와 통신을 통해 각 서버마다 할당된 자원과 사용중의 자원의 상황을 알 수 있으며 애플리케이션 마스터들과의 통신을 통해 필요한 자원이 무엇인지 어떤 자원들이 더 이상 필요가 없는지등을 알아내서 관리하게 됩니다.

 

< 리소스 매니저의 웹인터페이스 화면 >

리소스 매니저는 웹 브라우저로 접근할 수 있으며 이 웹인터페이스의 포트번호는 기본값이 8088입니다. 이 번호를 바꾸고 싶다면 이는 yarn.resourceman­ager.webapp.address라는 파라미터로 yarn-site.xml에서 변경해줄 수 있습니다. 참고로 YARN 클라이언트들이 리소스매니저와 통신을 할때 사용되는 기본 포트번호는 8032이며 이는 yarn.resourceman­ager.address라는 프로퍼티를 통해 변경가능합니다.

 

노드 매니저

 

노드 매니저는 하둡 1.0으로 치면 태스크트래커에 해당한다고 볼 수 있는데 클러스터 내의 서버마다 하나씩 실행됩니다. 노드 매니저는 노드내의 자원을 관리하고 이를 리소스 매니저에게 계속 보고합니다. 그리고 하나의 이상의 컨테이너들을 것을 관리하는데 구체적으로 컨테이너의 자원사용상태(CPU와 메모리)을 모니터하고 컨테이너가 종료될때까지 계속  그 상태를 트랙합니다. 바로 뒤에서 다시 설명하겠지만 컨테이너는 하나의 JVM에 해당하며 이 안에서는 어떤 자바프로그램도 실행할 수 있고 원한다면 셸 명령어를 실행할 수도 있습니다.컨테이너는 하둡 1.0으로 보면 태스크마다 할당된다고 보면 가장 비슷할 듯 합니다.

 

< 노드 매니저의 웹인터페이스 화면 >

 

노드 매니저는 웹 브라우저로접근할 수 있으며 이 웹인터페이스의 포트번호는 기본값이 50060입니다. 이 번호를 바꾸고 싶다면 이는 yarn.nodeman­ager.webapp.address라는 파라미터로 관리되며 앞서 리소스 매니저와 마찬가지로 yarn-site.xml에서 변경해줄 수 있습니다.

 

컨테이너

모든 잡은 결국 여러 개의 태스크로 나눠지며 각 태스크는 하나의 컨테이너안에서 실행이 됩니다. 앞서 이야기한 것처럼 컨테이너는 결국 하나의 JVM에 해당하며 현재로는 요청된 메모리 크기(자바힙)에 의해 컨테이너의 수가 결정됩니다. 

그럼 누가 어떤 잡을 실행하는데 필요한 자원(결국 컨테이너들)을 요청하고 누가 이 요청의 허락여부를 결정할까요? 뒤에서 다시 설명하겠지만 (그리고 사실 앞에서 설명되었지만) 필요한 자원의 요청은 애플리케이션 마스터에 의해 이뤄지고 허락 여부는 리소스 매니저에 의해 결정됩니다. 컨테이너안에서 실행할 수 있는 프로그램은 단순히 자바 프로그램뿐만이 아니고 커맨드라인에서 실행할 수 있는 프로그램이라면 무엇이든 실행가능합니다. 물론 어떤 프로그램이든 실행할 수 있으려면 그 프로그램의 실행에 필요한 환경이 이미 설치되어있어야 하는데 이를 준비하는 것은 애플리케이션 마스터의 역할입니다 (부트스트래핑이라고 부르는 것이 바로 그 준비과정입니다). 컨테이너내에서 특정 프로그램을 실행하기 위해서 애플리케이션 마스터가 컨테이너에게 넘겨야할 정보는 다음과 같습니다.

  • 프로그램의 실행을 위한 커맨드라인 명령어
  • 환경변수들
  • 프로그램 실행전에 미리 설치되어야하는 것들 (보조 데이터파일, jar과 같은 라이브러리 파일들, …)
  • 보안관련 토큰들


위에 보면 마지막에 보안관련 토큰들이 있습니다. 그 이유는 누군가 거짓으로 애플리케이션 마스터를 사칭하는 것을 막기 위해서입니다.  


애플리케이션 마스터

 

이게 실제 우리가 YARN위에서 실행시키는 잡마다 하나씩 존재하게 됩니다.이 애플리케이션 마스터가 결국 해당 잡에 필요한 리소스(최종적으로는 컨테이너가 됩니다)를 리소스 매니저로부터 받아 (리소스 매니저를 통해) 노드매니저들로 태스크들을 분담해서 실행(태스크들은 결국 앞서 이야기한 컨테이너안에서 실행되는것이죠)하는 역할을 담당합니다. 

잡의 실행이 종료되면 해당 애플리케이션 마스터는 없어집니다.
 애플리케이션 마스터는 하나의 YARN 클러스터안에 몇개가 동시에 실행 중일 수 있으며 각기 다른 타입의 애플리케이션일 수 있습니다. 예를 맵리듀스 프레임웍 애플리케이션이 실행되면서 동시에 Storm 애플리케이션이 실행되고 Giraph 기반의 애플리케이션이 실행될 수 있다는 것입니다 (물론 클러스터의 용량이 허용하는 한다는 전제에서 말입니다).

YARN 실행과정


자 그럼 전체 웍플로우를 다시 한번 정리해보겠습니다.


1. YARN 라이언트(YARN API를 사용) 리소스 매니저에게 잡 실행을 요청

  - 정확히는 잡을 실행할 애플리케이션 마스터 코드를 리소스 매니저에게 넘긴다.

2. 리소스 매니저는 노드 매니저를 하나 랜덤하게라 그 노드위에서 애플리케이션 매니저를 실행한다. 정확히는 그 노드 매니저가 존재하는 서버상의 컨테이너 하나가 실행되어 그 안에서 애플리케이션 마스터가 실행된다.

3. 애플리케이션 매니저는 리소스 매니저에게 잡 실행에 요한 컨테이너들의 할당을 요청한다. 모든 리소스 요청은 리소스 매니저를 통해야한다. 나중에 애플리케이션매니저들은 이 컨테이너들을 리소스 매니저에게 되돌려 어야한다.

4. 리소스 매니저는 애플리케이션 매니저를 대신하여 노드매니저들에게 스크 실행을 명령한다. 각 태스크는 각기 하나의 컨테이너에서 실행된다.

YARN 코드 작성


그러면 YARN상에서 동작하는 코드를 작성한다는 것은 무슨 의미일까요? YARN API를 이용해야하는데 그게 결코 쉽지 않습니
다. 하둡 2.0을 설치하면  맵리듀스 프레임웍(버전 2.0) 이외에도 YARN API를 사용해 예제로 만든 DistributedShell이란 예제프로그램이 같이설치됩니다. 이를 보면 YARN 위에서 돌아가는 프로그램을 어떻게 만들수 있을지 예를 볼 수 있습니다. YARN의 약점은 다음과 같습니다. 

  • 굉장히 잡하다
    • 프로토콜이 굉장히 로우레벨이다. 즉 우는데 시간이 걸린다. lots of boiler plate code is needed
    • 클라이언트는 필요한 모든 JAR 일들을 HDFS에 준비해두어야 한다
    • 클라이언트는 필요한 환경과 클래스 스등을 정해야한다.
  • 애플리케이션이 끝난 에야 로그가 는다.
    • 오랫동안 도는 애플리케이션이나 그로 해 는 애플리케이션의 경우에는 제가 된다
  • 애플리케이션 마스터가 새로운 SPOF(Single Point Of Failure)이다
  • 컨테이너와 애플리케이션 마스터간에 직접적인 통신 메커니즘이 바로 지원되지 는다.
  • 위와 은 이유들로 인해 버깅이 지 않다.

그런 이유로 인해 YARN API를 사용하기 쉽게 만들어주는 아파치 오픈소스 프로젝트가 만들어졌습니다. 그 이름이 위브(WEAVE)라는 것인데 Continuuity라는 회사가 주축이 되어 진행되고 있습니다 (여담으로 이 회사의 아키텍트인 Andreas Neumann이 야후때 몇가지 프로젝트를 같이 했었던 전 직장동료입니다). 위브의 특징은 다음과 같습니다.

  • 오픈소스 파치 프로젝트(http://continuuity.github.io/weave/)
  • YARN상에서 애플리케이션 마스터의 개발(드,디버깅, 실행)을 쉽게 해준다.
    • DSL을 이용해 애플리케이션을 정
    • API를 이용해 컨테이너 태스크 드를 작성
    • 서비스 발견, 로깅, 모니터링, 메트릭스 수집과 관련된 기능 제
    • 부적으로 zookeeper를 사용하며 자체 애플리케이션 마스터와 컨테이너를 공한다.

물론 기존의 자바 기반의 맵리듀스 프로그램이나 Pig/Hive등을 사용하는 경우라면 위에서 언급한 것처럼 YARN API를 사용해서 프로그래밍을 할 필요가 없습니다 (소스레벨에서 호환이 되기 때문에 자바 프로그램을 재컴파일하던지 아니면 Pig/Hive자체를 YARN용으로 재컴파일해야할 수는 있습니다).

'그냥..잡담..' 카테고리의 다른 글

YARN의 내부동작  (0) 2015.03.16
트랙백 : 없음 댓글 : 없음