[빅데이터] 하둡2와 얀(YARN)

기존의 하둡에서는 에코 시스템에 대한 적절한 리소스 관리 방안이 없었다.

 

또한 SPOF(Single point of failure, 단일 고장점) 라는, 시스템의 구성 요소 중 고장나서는 안되는 요소가 고장나는 일이 발생했다.

하둡에서는 네임노드가 SPOF에 해당되는데, 이 문제의 극복을 위해 네임노드의 이중화가 필요해졌다.

 

또한 데이터노드 블록들의 단일 네임스페이스 문제도 발생했다.

 

이러한 여러 문제점을 개선하기 위해 하둡2와 YARN이 등장했다.

 

 

하둡2의 특징은 다음과 같다.

1) YARN을 포함

2) 네임노드의 고가용성

3) HDFS 페더레이션, 스냅샷 지원

4) NFSv3 파일 시스템 지원

5) 성능 개선

 

 

이 중 가장 눈여겨 볼 만한 점은 바로 YARN이다.

YARN은 (Yet Another Resource Negotiation)으로, 말 그대로 또다른 리소스 협상가이다.

 

기존의 하둡1은 잡트래커에 여러 가지 문제가 있었다. 가장 먼저 메모리 상에 전체 잡의 실행 정보를 유지하기에 메모리가 부족할 경우 잡 상태 모니터링 및 새로운 잡의 실행 요청이 불가능했다.

 

또한 잡 트래커는 맵리듀스 프로그램의 단일 고장점 (SPOF) 이기 때문에 에러 발생 시 맵리듀스 잡 자체가 불가능했다.

 

추가로 고정된 맵 슬롯과 리듀스 슬롯만 사용하고, 이로 인해 타조, 임팔라 등의 다른 시스템과 자원 공유가 불가능했다. 클러스터의 확장성 또한 떨어졌으며, 모든 문제를 맵리듀스 구조에 맞춰야 하는 비효율성과 어려움이 있었다.

 

YARN은 이러한 문제를 해결하기 위해 개발되었다.

 

 

 

YARN

YARN 아키텍처

1) 리소스 매니저

•  얀의 마스터 서버로, 글로벌 스케줄러, 전체 클러스터에서 가용한 모든 시스템 자원을 관리한다.
•  클러스터에 하나만 존재한다.
•  어플리케이션의 리소스 요청을 처리하여 분배 및 모니터링을 담당한다.

 

2) 노드매니저

•  맵리듀스의 태스크 트래커로써, 각 슬레이브에서 하나의 데몬으로 실행된다.
•  컨테이너 실행 및 컨테이너 라이프 사이클을 모니터링한다.

 

3) 컨테이너

•  CPU, 메모리, 디스크, 네트워크와 같은 다양한 시스템 자원이다.

 

4) 어플리케이션 마스터

•  하나의 어플리케이션을 관리하는 마스터.
•  어플리케이션에 필요한 리소스를 스케줄링하고, 노드 마스터에 어플리케이션이 필요한 컨테이너를 실행하도록 요청한다.

 

YARN의 작업 흐름은 다음과 같다.

1.  클라이언트가 리소스 매니저에 신규 어플리케이션 ID 요청
2.  클라이언트가 어플리케이션 마스터 및 어플리케이션 실행 시 공통 리소스를 HDFS에 업로드
3.  클라이언트가 리소스 매니저에게 실행 요청 후 모니터링
4.  리소스 매니저가 노드 매니저에 어플리케이션 마스터 실행 요청
5.  노드 매니저는 컨테이너에 어플리케이션 마스터 실행
6.  어플리케이션 마스터가 어플리케이션 실행 시 필요한 리소스를 HDFS에 업로드
7.  어플리케이션 마스터가 노드매니저에 어플리케이션 실행 요청

 

 

 

 

 

네임노드 고가용성 (High Availablity, HA)

 

모든 클라이언트는 네임노드를 통해서만 HDFS에 접근할 수 있다.

그만큼 네임노드는 중요한 역할을 수행하고, 단일 고장점이었다.

 

이러한 네임노드의 이중화가 필요했고, 하둡2는 이러한 네임노드를 활성-대기 상태의 한 쌍의 네임 노드로 구현했다.

 

활성 네임노드에 장애가 발생할 경우 대기 네임노드가 역할을 이어받는 형식이다.

 

하둡1에서는 네임노드만이 editlogs 파일을 작성할 수 있었다. 하지만 하둡2에서는 저널노드가 도입되어 작성된 editlogs의 복제본을 갖게 되었다.

 

활성 네임노드는 언제든 역할을 넘겨줄 수 있도록 저널노드에 주기적으로 에디트로그를 저장한다. 그리고 대기 네임노드는 주기적으로 저널노드를 조회하며 자신의 fsimage 파일을 갱신한다.

 

이러한 특징으로 인해 기존의 보조 네임노드는 필요가 없어졌다.

 

추가로 액티브노드와 스탠바이노드의 구분을 위해 네임노드의 상태 정보를 저장하는데 주키퍼를 채택하여 사용했다.

 

 

 

HDFS 페더레이션과 스냅샷

 

페더레이션이란 연합이다.

 

기존의 HDFS에서는 네임노드의 확장이 불가능했고, 모든 클라이언트가 하나의 네임노드만을 사용했다.

이러한 특징으로 인해 하나의 잡에 문제가 발생하면 전체 잡에 영향이 갔다.

 

또한 네임스페이스(디렉토리)와 블록 관리가 서로 다른 기능임에도 코드 상 연결되어 있어 복잡도가 높고 확장하기 어려운 구조를 가지고 있었다.

 

이를 개선하기 위해 하둡2에서는 네임노드가 자신만의 네임스페이스를 가져, 여러 개의 네임노드를 실행하여 파일을 관리했다.

 

즉, 이전에는 /root 하나에만 있었다면 지금은 /usr1 /usr2 ... /usrN 으로 나뉘어 N개의 네임노드로 파일을 관리할 수 있게 되었다.

 

또한 블록 풀이라는 개념을 도입하였는데, 블록 풀은 네임스페이스에 속하는 블록의 정보로 네임노드간 통신의 필요성을 없앴다.

 

추가로 스냅샷을 지원하여 HDFS의 복원이 가능하도록 만들었다.