1 What is Yarn?

YARN (Yet Another Resource Negotiator)

Yarn 자바스크립트 패키지 매니저 이름이기도 함. 자바스크립트 쓰는 사람들이 꽤 많고, 하둡의 Yarn은 하둡이 있어야 쓸 수 있는 도구다 보니 헤비유저들이 많다. 유저가 적다 보니 검색할 때 Hadoop Yarn을 붙여서 검색하는 게 검색 히트율이 높을 것.. ㅋㅋ

개념

Hadoop 에코시스템의 클러스터 리소스 관리 프레임워크이다.

• Java로 작성되어 있다.

역할

• CPU, 메모리 등 클러스터 자원(Resource)을 여러 애플리케이션에 효율적으로 분배한다.
• Job 스케줄링과 모니터링을 담당한다.

구성 요소:

1. ResourceManager : 전체 클러스터 자원 관리 및 Job 스케줄링

   • 대표 소스 위치 : hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager
   • 자바 클래스의 FQCN : org.apache.hadoop.yarn.server.resourcemanager.ResourceManager

2. NodeManager : 각 노드에서 리소스 사용 현황 모니터링

   • 대표 소스 위치 : hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-nodemanager
   • 자바 클래스의 FQCN : org.apache.hadoop.yarn.server.nodemanager.NodeManager

3. ApplicationMaster : 각 애플리케이션(Job)의 실행 관리

   • 활용: Hadoop MapReduce, Spark, Tez 등 다양한 분산 처리 프레임워크에서 실행 엔진처럼 동작
   • 대표 소스 위치 및 클래스(FQCN) (프레임워크별):
     • MapReduce :
       • 모듈 위치: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app
       • 클래스(FQCN): org.apache.hadoop.mapreduce.v2.app.MRAppMaster
     • Spark :
       • 모듈 위치: spark-yarn-client
       • 클래스(FQCN): org.apache.spark.deploy.yarn.ApplicationMaster
     • Tez :
       • 모듈 위치: tez-dag-app
       • 클래스(FQCN): org.apache.tez.dag.app.DAGAppMaster

YARN = Hadoop 클러스터의 “운영체제” 역할 (자원 배분 + 작업 스케줄링)

1.1 Yarn의 등장

2012년 이전 Yarn 이 등장하기 이전까지는 Hadoop을 이용해서 대용량 processing 작업을 하려면
MapReduce 모델을 이용해서 Java, Python, Ruby 언어나 Pig framework로 개발해야 했다.

Hadoop 2.0 과 함께 Yarn 이 등장한 뒤로는 MapReduce programming model 제약에서 자유롭게 multi processing 프로그램을 Hadoop 자원을 이용해서 만들 수 있게 되었다.
Yarn은 대용량 multi processing 처리에 있어서 성능의 향상과 유연한 execution engine 이 장점이었다.
시간이 지나면서 Spark 와 같은 분산처리 프레임워크도 Yarn을 지원하게 되었다.

1.2 Yarn의 대표적인 Use-Cases

뿐만 아니라 Yarn 을 통해서 batch 위주의 작업(batch computing)에서 벗어나서 반복 작업과 streaming processing 으로 continuous computing 까지도 가능했다.(+ 배치 컴퓨팅의 성능과 사용성도 향상이 됨)
continuous computing 이 가능해지면서 웹서비스에서 필요한 실시간 대용량 처리가 가능해지고 이를 통해서 다양한 부가가치를 가지는 서비스가 가능해지고 자원의 비용 효율화까지 할 수 있었다.

Yarn 을 통해서 대용량의 단일 클러스터 방식이 아래와 같이 더욱 효율성을 높일 수 있었다.

1. 한 어플리케이션이 사용하지 않을 때 다른 어플리케이션이 자원을 점유할 수 있으므로, cluster 의 utilization 을 높일 수 있었다.
   • 실무적으로는 회사의 특성에 따라 전체적인 리소스 요청/사용량의 fluctuation 이 발생하기는 한다.
2. 단일 클러스터에서 데이터 저장, 조회 뿐만 아니라, 멀티프로세싱 어플리케이션까지 모두 동작하므로 운영 비용을 낮출 수 있다.
3. 데이터 저장소와 데이터를 활용하는 어플리케이션이 같은 클러스터에서 동작하므로, 데이터 이동에 대한 작업이나 비용이 감소한다.

Continuous Computing (연속 컴퓨팅)
배치 처리처럼 주기적으로 실행하는 것이 아니라, 데이터가 유입되는 즉시 끊김 없이 실시간으로 처리하는 방식을 의미한다.
YARN의 자원 관리와 멀티 애플리케이션 실행 지원 덕분에 Spark Streaming, Storm 같은 스트리밍 프레임워크가 단일 클러스터에서 실행 가능해지면서 continuous computing이 가능해졌다.

1.3 Container란?

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

컨테이너화는 개발자들이 더 빠르게 개발하고 소프트웨어를 효과적으로 개발하고, 스케일에 대해서 더 유연하게 대응할 수 있도록 해준다.

Linux 의 cgroup 기능이 컨테이너화가 가능한 초기의 기술적인 기반이 되었다.
최근에는 cloud(Docker), kubernetes를 중심으로 컨테이너화를 활용하는 전략이 가속화되고 있다.

컨테이너를 사용하면 얻을 수 있는 대표적인 이점은 다음과 같다.

1.3.1 Separation of responsibility

컨테이너화 하기 전에는 소프트웨어를 배포할 때, 배포하는 환경을 제약하거나 같이 관리해야 했다.
특정 소프트웨어 개발자 입장에서 배포 환경의 out of scope 이므로 개발 난이도가 높아지거나 관리의 복잡도가 높아지게 된다.

어플리케이션 또는 소프트웨어를 컨테이너화 하면 개발자는 Application 의 로직과 그것의 직접적인 dependency에만 관심을 집중할 수 있다.

굳이 커널의 버전, 시스템 라이브러리의 사소한 업데이트에 관심을 갖지 않아도 된다.

1.3.2 Workload portability

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

• 하지만 현실적으로는 어느정도의 제약이 있다. 현재 쉽게 사용할 수 있는 컨테이너 기술 하에서는 Linux/amd64 환경 하에서는 이 portability가 잘 작동한다.

1.3.3 Application isolation

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

Yarn이 container를 띄운다?
같은 호스트 머신에 여러 작업들이 돌 수 있는데, 그 친구들 끼리 isolation되어 있는 환경을 보장해주겠구나. 라고 떠올리면 됨