[Hadoop_기초] Udemy course - 섹션 8-1. Yarn & Tez & Mesos & Zookeeper

67강. Yarn 설명

이번 섹션에서는 전반적으로 클러스터를 작동하게 만드는 리소스들을 관리하는 툴에 대해서 다루었다.

기본적으로 yarn이 있고 그 위에 작동하는 tez가 있고, 클러스터의 작업을 관리하는  oozie와 zepplin 그리고 관리 콘솔인 hue에 대해서 정리했다.

 

Yarn이란?

• Yet Another Resource Negotiator
  • 하둡2에서 소개되었으며 핵심 요소이다. 
  • 하둡 클러스터의 모든 리소스를 관리한다. 
  • 맵리듀스와 클러스터의 리소스 관리에 따른 문제를 분리시켰다.
    • 하둡1에서는 맵리듀스와 리소스 교섭자까지 모두 하나의 덩어리였다.
  • 리소스 교섭자로서 yarn을 분리함으로써 yarn위에 spark와 tez같은 맵리듀스의 대안이 개발되었다.
   

• 위의 그림과 같이 yarn이 작동하고 있으며 그 위에 구축된 spark나 tez같은 어플리케이션이 yarn을 사용하면서 작동된다.
• HDFS는 빅데이터를 블록으로 쪼개고 복사한 후에 클러스터의 다양한 노드에 걸쳐 분산 저장하는 시스템이면, yarn은 저장소 레이어 위에 작동한다.
  • yarn은 클러스터의 컴퓨팅 계층이며 HDFS클러스터에 있는 특정 데이터 청크 처리에 따라 특정 작업이나 작업 또는 기본적으로 애플리케이션 청크를 실행할 수 있다.
  • yarn은 이렇게 클러스터의 컴퓨팅 작업을 분산한다.
• 방향성 비사이클 그래프(DAG)방식으로 사용할 필요가 없다면  Yarn으로 리소스 관리를 하는 것이 무난하다.

 

Yarn의 작동방식

• 맵리듀스 스크립트를 가진 클라이언트 노드가 HDFS클러스터에 직접 요청하는 경우가 종종있다.
• 보통 yarn리소스 관리자에게 요청을하고 (맵리듀스) 어플리케이션을 실행하게 된다.
• 이때 yarn은 먼저 특정한 노드에서 실행 중인 가용한 노드 관리자에게 요청한다.
• 맵리듀스 마스터를 실행하고 실질적으로 작업을 수행하는 워커에 작업을 분산한다.
• 이 다수의 워커 컨테이너들이 HDFS와 각각 소통하면서 필요한 데이터를 가지고 온다.
• 결국 Yarn이 하는 일은 이 모든 애플리케이션 프로세스를 어디에서 실행할지 알아내는 것이다. 
  • 어디서 노드를 구분하며 어떻게 분산해서 클러스터에 걸쳐 처리할 지 계산한다.
  • 그리고 네트워크를 통한 데이터의 이동을 최소화 한다.
• 클러스터의 CPU 사용을 최적화 하며, 데이터를 최대한 지역적으로유지해서 프로세스가 최대한 빠르게 데이터 블록을 가져온다. (데이터의 지역성)
• 고가용성 하둡환경에서는 다수의 리소스 관리자가 있고 주키퍼를 사용해서 마스터가 누구인지 추적한다.
  • 단일 리소스 관리자만 존재하는 단일 실패 지점의 한계를 이렇게 극복한다.
• 실패복원력 또한 가진다.
  • 애플리케이션 실행 시에 작업에 대한 스케줄 옵션이 다양한다.
  • FIFO(선입선처리)
    • 먼저 들어온 순서대로 처리한다. 이후에 요청된 것은 바로 앞에 것이 종료될때까지 기다린다. 
  • Capacity
    • 충분한 여유 용량이 있을 경우 병렬로 실행된다.
  • Fair
    • 전체 클러스터에서 실행되는 거대한 작업의 틈새에서 소규모 작업들을 실행한다.

 

68강.   Tez 설명

• 방향성 비순환 그래프(DAG)구조이다.
  • 맵리듀스는 작업들이 순차적이고 서로 의지하지만
  • 테스는 불필요한 과정을 제거하고 다양한 부분과 단계를 병렬로 처리하며 불필요한 종속성을 제거한다.
  • 클러스터의 물리적 데이터 흐름을 최적화해서 필요없는 데이터의 움직임을 없애서 클러스터의 리소스 사용도 최적화한다.
• 하이브, 피그 , 맵리듀스 등의 하둡 기반의 데이터 처리 엔진들이 더 빠르게 작동될 수 있게 해준다.
• 하이브 또는 피그 작업이 있는 경우, 맵리듀스의 대안으로서 기본 기술을 사용하지 않고 작동되도록 구성할 수 있다.
• 클라이언트 코드(하이브, 피그 등)를 실행하는 애플리케이션 프레임 워크이다.

• 맵리듀스의 경우 위의 그림을 참고하면, 각 맵리듀스 단계에서 매퍼와 리듀서의 결과물이 다른 매퍼와 리듀서에게 전달되고 또 다른 매퍼와 리듀서가 위에서 구름으로 표현된 HDFS에 있는 데이터를 통합한다. 
  • 이를 통해 최종 매퍼와 리듀서를 거쳐 결과를 구한다.
• 테즈는 이를 효율화 한것이다.

 

69강. [활동] Tez에서 Hive 사용 및 성능이점 측정하기

 

70강. Mesos설명

Yarn처럼 리소스교섭자이나 Yarn과는 또 조금 다르다

Mesos란?

• 트위터 프로젝트
  • 데이터 센터에 있는 컴퓨터 리소스를 관리하기 위해 개발
• yarn이 하는 작업과 유사하지만 yarn은 하둡 작업에 국한되었다는 큰 차이점이 있다.
  • Yarn위에서 애플리케이션이 작동하기 위해서는 데이터 지역성이 필요하다
  • 이에반해 메소스는 좀 더 일반적으로 사용할 수 있다.
• 컴퓨팅 리소스 풀 전체에 분산해야 하거나 오래된 종류의 애플리케이션을 작성하기 위해 만들어졌다.
• 메소스 위에서 작동하는 것들 대부분이 스트리밍 데이터를 처리하는데 사용된다.
• Myriad라는 패키지를 사용해서 하둡 yarn을 메소스와 통합할 수 있다.
  •  yarn이 메소스와 통신하며 그 리소스를 사용하고 그 둘이 상호작용하게 할 수 있다.
  • 이를 통해 하둡 컴퓨터 리소스를 데이터 센터의 다른 컴퓨터 리소스와 혼합해서 사용할 수 있다.

 

Mesos의 차별점(yarn과 비교)

• 파티션할 필요가 없다.
• 하둡리소스에 국한되지 않고 범용적으로 사용
  • 실질적으로 하둡에코시스템은 아니다. 
  • 그러나 하둡 에코 시스템 내의 일부 요소들이 메소스와 통신하며 그 위에서 작동할 수 있다.
  • spark가 대표적이다.
  • spark는 심지어 yarn이 아닌 메소스를 대상으로 개발 된것.
• 스케줄링 방식의 차이
  • yarn은 단일 스케줄러(monolithic). yarn에게 작업을 주면 yarn이 어디서 실행할지 정한다. 즉 하나의 트랜잭션
    • 메모리 기반 스케줄링이다
  • 메소스는 이중단계 시스템이다.(two-tiered)
    •  메소스는 리소스가 사용가능한 상태인지 확인/결정하고 리소스를 프레임워크에 제안
    • 프레임워크를 구축하는 사람이 메소스의 제안을 수락할지 거절할지 결정
    • 그리고 원하는 스케줄 알고리즘 지정
      • 각 애플리케이션 작동과 관련된 리소스 사용의 결정권한을 리소스 교섭자만이 가지고 있는 것이 아니며, 애플리케이션 입장에서 더 맞는 job을 선택할 수 있는 자율성을 획득했다고 보면 되는 걸까?
    • 확장성에 용이
    • 대규모 리소스와 다양한 생애주기를 가진 대규모 작업을 다룰 때 좋은 접근법
    • CPU 기반 스케줄링
• yarn은 빅데이터를 처리하고 하둡 클러스터의 의미를 추출하는 등의 더 긴 분석 작업에 최적화

 

Mesos 적용할 때 고려사항

• 하둡 뿐 아니라 모든 애플리케이션을 실행할 수 있는 아키텍쳐에서 사용
• 대규모 컴퓨터 클러스터에 걸쳐(즉 전체 데이터 센터를 활용) 애플리케이션을 실행하는 컨테이너를 관리할 대안
• spark와 storm같이 yarn이 아닌 메소스에서 작동되는 애플맅케이션을 사용하더라도 데이터 저장을 HDFS클러스터를 활용한다면 yarn이 적절한 선택일 수도 있다.
  • yarn은 데이터 지역성을 가짐으로써, 각 데이터에 대한 처리한 데이터가 위치한 그 노드에서 처리하려고 하기 때문이다.
  • 해당 부분은 최적화에서 중요하다
• 스파크 사용시 메소스를 적용한다면 하나의 슬레이브에 하나의 집행자로 제한된다.
  • 그에 반해 yarn은 노드별로 여럿의 집행자를 실행할 수 있다.
• Myriad 시스템으로 yarn와 메소스가 통신하여 리소를 사용한다면?
  • 사일로 데이터센터는 컴퓨터 세트 일부를 떼어내서 yarn 하둡 클러스터로 사용하고 나머지는 메소스나 다른 것에 의해서 관리된다
  • 하둡 클러스터를 충분히 활용하지 못한다면 잉여 리소스를 낭비하는 셈

 

 

71강.  Zookeeper 설명

Zookeeper란?

• 전체 클러스터에서 데이터를 일관성있게 유지하는 중요한 시스템이다.
  • 분산시스템을 사용 중이라면, 클라이언트는 누가 마스터 노드인지 일관성있게 인지하고 있어야 한다.
  • 일관성을 중요시하는 시스템을 구축한다면 이를 중재하는 별도의 시스템이 필요하다.
    • 어떤 작업자에게 어떤 작업을 분배할지, 
    • 어떤 작업자가 실패하면 어디까지 작업했는지
    • 어떤 작업자가 가용한 지 등
•  Drill과 같이 여러 서버들에 걸쳐서 사용되는 시스템에서도 zookeeper가 필요하다. 
  • Hbase, MR, Storm,Solr 등도 사용

 

Zookeeper의 실패모드(failure mode)

• 주키퍼는 현재 마스터 노드를 추적하고 그 마스터가 다운되면 그 상태를 알아차린다. 그리고 다른 백업 마스터 중에서 하나를 선별해 새 마스터로 지정하고 추적한다. 
• worker 가 다운되어도 주키퍼가 알아차린다. 어떤 작업자로부터 일정시간동안 응답이 없으면 애플리케이션에게 이 사실을 전달하고 해당 작업을 다시 적절하게 분산한다. 
• 네트워크 문제가 있을 경우
  • 네트워크 실패모드를 주키퍼가 인지하고 일정하지 않은 보고를 하는 작업자를 찾아낸 후에 애플리케이션에게 해결을 지시한다.

 

Zookeeper의 주요역할

•  master election(마스터 선출)
  • 한번에 하나의 노드만 마스터가 될 수 있다.
• crash detection
  • 노드가 끊어지거나 일정 기간동안 심장 박동을 보내는데 실패하면 사라지는 단기성 데이터를 가짐으로 노드의 가용성을 확인한다. 
• Group management
  • 어떤 작업자가 가용한지 추적한다.
• metadata
  • 일관성이 필요한 클러스터와 관련된 메타데이터 유지
  • 미결작업(outstanding tasks), 작업부여(task assignment)
  • 어떤 작업자나 마스터가 다운되면 새로운 노드가 와서 그 작업을 이어갈때 어디부터 해야할 지를 알 수 있다.

 

Zookeeper's API

특정한 문제에 대한 특정한  API를 제공하는 대신, 주키퍼는 굉장히 일관성 있는 작은 분산 파일 시스템을 제공한다.

그 어떤 애플리케이션이나 분산 시스템도 읽거나 기록할 수 있다. 

이를 통해 실패를 다루는 로직을 개별 애플리케이션에게 떠넘긴다. 

 

🤔하지만 클러스터의 모든 노드에 데이터가 안정적이고 일관성 있게 저장되도록 보장합니다

 

일종의 독자적인 소형 분산 클러스터에 있는 파일시스템이다.

단일 클러스터의 구조같지만 위와 같은 파일 시스템 구조가 여러 클러스터에 분산/복제되어있다.

여기서 각 경로의 file을 znode의 개념으로 치환해서 생각하면 된다.

-> /master는 마스터 노드가 무엇인지에 대한 정보를 가지고 있고, 만약 이 노드가 다운되면, 해당 노들르 놓아주고 다른 노드가 자리를 차지하게 된다. 

-> /wokers의 하단의 노드의 순서로 위계관계가 형성된다.  여러 작업노드 중 하나가 다운되면 노드의 단기성 상태가 사라지고 다른 작업자가 이 상황을 통보받아 적절히 응답한다. 

 

 

통보(notification)

매우 중요한 기능.

클라이언트가 znode의 통보를 구독할 수 있고 znode가 사라지거나 변화가 생기면 주키퍼가 해당 사실을 통보한다. 

그러면 모든 클라이언트가 지속적으로 데이터를 확인할 필요가 없으며 네트워크에도 여유가 생긴다. 

 

예를 들어, 특정 클라이언트가 마스터 znode에게 작성해서 자신을 마스터로 등록했고 만약 그 마스터가 다운되면 znode의 단기성 본성(*하단에 언급됨)으로 인해 그 마스터는 비워지고 다른 모든 클라이언트는 마스터가 바뀌엇으며 이전 마스터에는 아무것도 없음을 통보받는다. 

 

즉 znode의 단기성으로 인해 클라이언트가 실패하거나 주키퍼로의 연결을 잃어버리면 바로 발견할 수 있다.

 

persistent and ephemeral znode(znode의 잔류성과 단기성)

잔류성 znode는 데이터를 기록한 주체가 다운되어도 그 데이터 자체가 삭제되지 않는 이상 잔류한다. 

즉 작업자에게 부여한 작업은 마스터 노드가 실패해도 잔류한다. 

마스터가 다운되어도 미결작업에 대한 정보가 있는 것이다. 이를 통해 새 마스터가 이전 마스터의 중단 지점부터 다시 진행할 수 있다. 

 

단기성 노드는 생성한 클라이언트가 실패하거나 연결이 끊기면 자동으로 사라진다.

 

Zookeeper 아키텍쳐

 

애플리케이션의 모든 클라이언트는 주키퍼 클라이언트와 연결되고 주키퍼 앙상블과 소통한다. 

보통 둘이상의 주키퍼 서버가 존재하여 단일 실패 지점을 방지한다. 

 

주키퍼가 단일 서버에서 운영되는 경우, 주키퍼 서버가 다운되면 전체 시스템이 사용불가상태가 된다. 

그래서 둘 이상의 주키퍼 서버가 필요하고 이를 주키퍼 앙상블이라고 부른다. 

 

주키퍼 클라이언트가 이 모든 서버의 목록을 가지고 있는다.

 

주키퍼 앙상블은 그 자체의 데이터 복제를 담당한다. 

작업자 중 하나가 znode에 무언가를 작성하려 한다면 지정된 복제 팩터가 돌아올때까지 기다려야 한다. 

예를 들어 일관성 수준으로 3개의 서버를 지정한다면 적어도 세개 이상의 서버에 복제될때까지 기록되었다고 응답하지 않는 것이다. 

 

이렇게 일관성을 보장받는 것을 주키퍼 정족수(quorum)라고 한다.

몇개의 서버에서 동의해야 하는지 그 숫자를 지정할 수 있다. 

따라서 네개 이상의 주키퍼 서버를 사용한다. 

 

주키퍼 서버 5개가 앙상블에 있고? 정족수를 2로 지정했다면?

두 서버가 한 데이터 센터에 있고 나머지가 다른 곳에 있는 상황에서 네트워크 파티션이 생긴다면 갑자기 서로 통신할 수 없게된다. 이에 따라 일관성 없는 상태에 빠질수도 있다. 

즉 클라이언트가 이 두 서버와 소통하며 노드에 포함된 것에는 서로 동의하지만 이 노드를 다른 세곳에 복사할 수 없다.

이때 다른 클라이언트가 정족수에 포함되지 않은 다른 두 노드와 소통하는 경우 다른 답이 나올 것이고 이런 경우를 분할 뇌 시나리오라고 부른다. 즉 주키퍼의 한 부분이 어떤 답을 제공하고 다른 부분이 또 다른 답을 제공하는 상황이다. 

이러한 상황에서 해결책은 최소한 정족수 3을 갖는 것이다. 

 

즉 안정적인 운영을 위해서는 적어도 5개의 서버와 정족수 3을 갖는 것이 중요하다. 

 

몽고DB, Hbase의 경우 일관성 >  가용성 , 카산드라는 일관성 <= 가용성,

이는 결국 애플리케이션의 특성에 따라 선택하는 것이 중요. 

영화를 추천하는 서비스는 일관성이 그리 중요하지 않지만 금융 시스템에서는 일관성이 매우 중요하다. 

 

72강.[활동] Zookeeper로 실패한 마스터 시뮬레이션

 

 

 

Reference

• Apache Mesos vs Hadoop Yarn Comparison