Yarn이란?

Yarn의 등장

• 2012년 이전 Yarn의 등장 전까지 Hadoop(v.1.x)을 이용해서 대용량 프로세싱 작업을 위해선 MapReduce를 사용해야 했음

• Hadoop 2.0과 함께 Yarn이 등장하며 MapReduce제약에서 자유롭게 multi processing프로그램을 Hadoop 자원을 이용해서 만들 수 있게 됨

• Yarn은 대용량 Multi-processing 처리에 있어서 성능의 향상과 유연한 execution engine에 장점이 있음(Spark 등의 사용 가능)

Yarn의 대표적인 Use-Case

• Yarn을 통해 Batch위주의 작업에서 벗어나 반복 작업과 Streaming processing까지도 가능해짐

• Yarn을 통한 대용량의 단일 클러스터 방식이 갖는 장점은 다음과 같음

  • 한 애플리케이션이 사용하지 않을 때 다른 애플리케이션이 자원을 점유할 수 있으므로 Cluster의 Utilization을 높일 수 있음

  • 단일 클러스터에서 데이터 저장, 조회뿐만 아니라, 멀티프로세싱 애플리케이션까지 모두 동작하므로 운영 비용을 낮출 수 있음

  • 데이터 저장소와 데이터를 활용하는 애플리케이션이 같은 클러스터에서 동작하므로, 데이터 이동에 대한 작업이나 비용이 감소

Container란?

• 컨테이너의 사전적 정의는 소프트웨어 서비스를 실행하는 데 필요한 특정 버전의 프로그래밍 언어의 런타임과 소프트웨어 실행에 필요한 라이브러리 등을 함께 담고 있는 응용 프로그램 코드의 경량 패키지

• Cloud, kubernetes를 중심으로 컨테이너화를 활용하는 전략이 가속화 되고 있음

• Container의 장점은 다음과 같음

  • Separation of respoinsibility

    • 개발자는 Application의 로직과 그것의 직접적인 dependency에만 관심을 집중할 수 있음

  • Workload portability

    • 컨테이너는 가상화된 환경으로 어디서나 동작할 수 있기에 인프라로부터 자유롭게 다양한 환경에서 구동이 가능

  • Application isolation

    • 컨테이너는 CPU, memory, storage, network resources를 운영체제 수준에서 가상화 함. 따라서 같은 호스트에 있는 다른 애플리케이션의 영향이나 간섭 없이 독립된 리소스를 관리할 수 있음

Yarn Architecture

• Yarn과 HDFS는 완전히 독립적임. HDFS는 Storage 기능을 제공하고, Yarn은 application을 구동하는 기능을 제공

• Yarn의 Architecture는 크게 3개지 역할을 하는 컴포넌트로 구성

  • Resource Manager
  • Application Master
  • Node Manager

• Resource Manager(RM)

  • 통상 Cluster 당 하나 존재
  • Master 서버의 역할
  • Datanode의 위치과 resource의 양을 알고 있음(Rack Awareness 포함)
  • 내부적으로 여러개의 서비스로 구성 가장 중요한 요소는 Scheduler로 리소스 할당을 결정

• Application Master(AM)

  • 하나의 애플리케이션이 리소스를 어떻게 사용할지 조정하는 역할
  • Yarn에 제출되는 job에서 가장 먼저 시작하는 container
  • RM에게 리소스를 요청하고, Node Manager가 제공해준 container 위에서 함께 동작

• Node Managers(NM)

  • 클러스터에 여거래 존재. 인프라의 slave
  • RM에게 주기적으로 heart beat를 전송
  • NM은 클러스터에 리소스를 제공. NM이 관리하는 리소스는 v-core 수와 memory 양
  • NM은 RM의 지시를 받아 해당 노드에 있는 컨테이너의 상태를 보고하고 관리

Resource Manager

• RM의 기능과 역할

  • RM은 Yarn 클러스터에서 사용가능한 리소스를 관리
  • Pluggable한 YarnScheduler를 포함. 구현체마다 다른 정책을 가짐
  • RM은 Scheduler와 Application Manager를 주요 컴포넌트로 가짐

• Scheduler

  • Scheduler는 다양한 애플리케이션에 capacities, queue 등의 제약 하에 리소스를 할당
  • Scheduler가 애플리케이션 상태를 모니터링 하지는 않음. 애플리케이션 장애나 HW failure에 의한 장애 등에 의한 restart도 하지 않음
  • Scheduler에는 다양한 policy plugin이 존재. 대표적으로 Capacity Scheduler 및 Fair Scheduler 등이 존재

• Application Manager

  • AM은 제출된 애플리케이션의 리스트를 관리하는 인터페이스
  • Job의 제출을 받고, AM이 뜰 컨테이너를 선정하고, 실패에 대해 Application Matser Container를 재시작하는 역할을 담당

Yarn의 작업 흐름

1. 클라이언트는 애플리케이션 실행을 요청. RM은 실행 요청이 유효하면 클라이언트에 새로운 Application ID를 할당

2. RM은 NM에게 AM 실행을 요청

3. NM는 RM의 요청을 받아 컨테이너에서 AM을 실행. 이때 컨테이너는 새로운 JVM을 생성해 AM을 실행함

4. AM은 RM에게 애플리케이션을 실행하기 위한 리소스를 요청. RM은 전체 클러스터의 리소스 상태를 확인한 후 AM에게 NM 목록을 전달

5. AM은 할당받는 NM들에게 컨테이너 실행을 요청

6. NM들은 컨테이너에 새로운 JVM을 생성하고, 애플리케이션을 실행. 애플리케이션이 종료되면 AM도 종료됨. 마지막으로 RM이 종료된 AM에게 할당했던 리소스를 해제함

Auxiliary Service

• Yarn 클러스터에서 맵리듀스 애플리케이션을 실행할 경우, 맵 테스크는 노드 매니저의 컨테이서에서 실행

• 그런데 노드 매니저는 컨테이너에서 실행중이던 애플리케이션이 종료될 경우 컨테이너도 함께 종료시킴

• 이렇게 컨테이너가 종료된다면 맵 테스크는 리듀스 테스크에 데이터를 전달할 수 없게됨

• Yarn은 이러한 상황의 방지를 위해 Auxiliary Service(보조 서비스)를 제공. 즉, 노드 매니저 사이의 서비스 제어를 위한 기능임

• 다른 노드 매니저 사이에 데이터를 전달하거나 다른 노드 매니저를 제어할 수 있게 해주는 서비스라고 이해하면 쉬움

• 즉, Auxiliary Service를 맵리듀스에 적용하면 맵을 실행하는 노드 매니저와 리듀스를 실행하는 노드 매니저 사이에 셔플(데이터 전송 및 재배치)가 가능해짐