Tools/Hadoop

하둡 클러스터와 리소스 할당

칼쵸쵸 2023. 9. 26. 20:31

- 특정 상황에서 데이터 분석가들에게 대부분의 리소스가 할당되어 SLA(서비스 수준 협약)을 준수 하지 못하는 경우가 있다.

- 데이터 엔지니어링 측면에서 중요한 잡들이 동작함과 동시에 데이터 분석에 필요한 리소스를 제공할 수있어야 한다.

 

 

Capacity 스케줄러


- https://blog.cloudera.com/yarn-capacity-scheduler/

capacity 및 계층적 설계

YARN은 현재 메모리 및/또는 코어에 대해 예약하는 리소스에 대한 최소 할당과 최대 할당을 정의합니다. 

YARN용 작업자를 실행하는 각 서버에는 예약에 사용할 수 있는 메모리 및/또는 코어가 될 수 있는 리소스 할당을 제공하는 NodeManager가 있습니다. 모든 노드 관리자의 리소스 집합은 capacity 스케줄러가 사용할 수 있는 모든 리소스의 'root'로 제공됩니다.

 

capacity 스케줄러의 기본 기본 사항은 대기열 배치 및 리소스 할당 방법에 관한 것입니다. 대기열은 클러스터 대기열의 'root'가 되는 최상위 상위 항목을 사용하여 계층적 설계로 배치됩니다.

 

여기에서 리프(하위) 대기열은 루트에서 할당되거나 자체적으로 리프를 가질 수 있는 분기가 할당될 수 있습니다.

capacity는 계층 구조에서 상위 항목의 최소 및 최대 백분율로 이러한 대기열에 할당됩니다. 

최소 capacity은 클러스터에서 모든 것이 최대로 실행되는 경우 대기열에서 사용할 수 있을 것으로 예상되는 리소스의 양입니다. 최대 capacity은 대기열이 다른 대기열의 최소 capacity 요구 사항을 충족하는 데 사용되지 않는 리소스를 사용할 수 있도록 하는 탄력적 capacity입니다.

 

 

- root부터 시작하는 계층 구조의 Queue를 사용

- 각 Queue마다 부모 Queue를 기준으로 min, max capacity를 설정 가능

- 분기된 leaf queue들은 min capacity의 합이 100이 되어야함.

- 해당 Queue는 자신의 capacity 뿐만 아니라, 다른 Queue의 남는 리소스를 사용 가능.
   ( Queue Elasticity )

   A.capacity가 20%, B.capacity가 80% 일 때, B의 사용량이 현재 없다면 A가 100% 사용 가능.

 

Minimum User Percentage and User Limit Factor

 

Minimum User Percentage (최소 사용자 비율): Capacity Scheduler에서 각 큐에 대한 최소 사용자 비율을 나타내는 설정입니다. 예를 들어, 클러스터의 전체 리소스 중 100%가 있다고 가정하면, 특정 큐에 대한 최소 사용자 비율을 설정하여 해당 큐에 항상 일정량의 리소스가 할당되도록 할 수 있습니다. 이것은 특정 큐를 유지하고 중요한 작업을 수행하기 위해 필요한 최소 리소스를 보장하는 데 유용합니다.

예를 들어, 만약 "Queue A"에 대한 최소 사용자 비율을 10%로 설정하면, "Queue A"는 전체 리소스 중 적어도 10%의 리소스를 사용하게 됩니다. 이렇게 하면 "Queue A"가 항상 일정량의 리소스를 사용할 수 있으며 다른 큐로부터 강제로 리소스를 빼앗기지 않습니다.

 

- Min User Percentage는 다수의 사용자가 리소스를 사용할 때 보장받을 수 있는 최소 리소스

    - 10%의 설정 값이라면, 10명의 사용자가 있을 때 각 사용자는 10% 사용 가능함.

    - 최소 값 설정이므로, 남는 리소스가 있다면 더 할당 받을 수 있음.

- User Limit Factor는 사용자 한명이 사용할 수 있는 최대 리소스 양.

    - Min Capacity의 곱으로 계산됨.

    - Min Capactiy가 10%이고 User Limit Factor가 3의 설정 값이라면, 사용자 한명이 30% 사용 가능.

 


User Limit Factor (사용자 제한 요소):
각 큐에서 각 사용자 또는 애플리케이션에 대한 리소스 사용을 제한하는 데 사용되는 설정입니다. User Limit Factor는 특정 큐에서 사용자가 요청한 리소스 양에 대한 제한을 설정합니다.

예를 들어, "Queue B"에 대한 User Limit Factor가 2.0으로 설정되어 있다면, 사용자가 해당 큐에서 요청한 리소스가 해당 큐의 전체 리소스 할당을 초과하지 못하도록 제한됩니다. 이것은 공정한 리소스 분배를 위해 사용될 수 있으며, 한 사용자 또는 애플리케이션이 다른 사용자 또는 애플리케이션에게 과도한 리소스를 빼앗아가는 것을 방지합니다.


AD-HOC

알 수 없는 작업 및 새 워크로드가 실행될 수 있으며 리소스 할당 동작에 대한 기대는 없지만 애플리케이션별 튜닝 요구 사항을 파악하기 위해 애플리케이션을 초기에 실행


PREFERENCE
리소스를 먼저 확보하고 더 오래 유지해야 하는 애플리케이션입니다. 이는 애플리케이션 캐치업, 비상 실행 또는 기타 운영 요구 사항과 같은 여러 가지 이유 때문일 수 있습니다.


MACHINE LEARNING 

MACHINE LEARNING  애플리케이션은 일반적으로 긴 실행 시간과 크거나 집약적인 리소스 요구 사항이 특징입니다. 일부 기계 학습 워크로드에 대한 작업 종료는 기간을 크게 연장하여 장기적으로 영향을 미칠 수 있습니다.


DASHBOARDING 
동시성(새로 고침 빈도)은 낮지만 일일 쿼리 수가 많습니다. 대시보드는 예상 시간에 새로 고쳐야 하지만 매우 예측 가능한 워크로드입니다.


EXPLORATION 
탐색 사용자는 대기 시간이 짧은 쿼리가 필요하며 매우 큰 데이터 세트를 전환하려면 처리량이 필요합니다. 사용자가 대화형 경험을 제공하기 위해 탐색하는 동안 리소스가 사용되도록 보류될 가능성이 높습니다.


BATCH WORKFLOW 
변환 및 일괄 워크로드에 대한 일반적인 컴퓨팅 요구 사항을 제공하도록 설계되었습니다. 설정은 개별 애플리케이션 대기 시간이 아닌 애플리케이션 처리량에 가장 자주 관심을 갖습니다.


ALWAYS ON 
완료 개념이 없고 항상 실행 중인 응용 프로그램입니다. 리소스를 대기하면서 새로운 작업이 도착하기를 기다리는 응용 프로그램입니다. Slider 배포된 인스턴스(예: LLAP)와 같은 것을 포함할 수 있습니다.

 

Fair Scheduler

Fair 스케줄러 (Fair Scheduler)는 Hadoop 클러스터에서 작업들 간의 리소스를 공정하게 분배하는 데 사용되는 스케줄링 알고리즘 중 하나입니다. 이 스케줄러는 다양한 작업들이 클러스터 리소스를 공유할 때 효율적으로 동작하도록 설계되었습니다. 아래는 Fair 스케줄러에 대한 주요 특징과 작동 방식에 대한 개요입니다:

공정한 리소스 분배: Fair 스케줄러는 모든 큐 또는 애플리케이션 간에 리소스를 공정하게 분배하려고 시도합니다. 즉, 모든 큐가 평등한 접근 기회를 갖게 되어, 우선 순위 큐와 같은 개념이 없는 경우에 유용합니다.

풀 기반 리소스 할당: Fair 스케줄러는 여러 리소스 풀 (pools)을 정의하고 각 풀에 리소스 할당 비율을 설정합니다. 각 큐는 하나 이상의 풀에 속할 수 있으며, 풀의 할당 비율에 따라 리소스가 분배됩니다.

우선 순위 지원: Fair 스케줄러는 각 큐 또는 애플리케이션에 우선 순위를 지정할 수 있습니다. 따라서 일부 큐는 다른 큐보다 높은 우선 순위를 가지고 리소스를 더 빨리 할당받을 수 있습니다.

프리페치 및 튜닝: Fair 스케줄러는 큐별로 리소스를 미리 가져올 수 있는 프리페치 메커니즘을 지원합니다. 또한, 사용자 지정 설정을 통해 스케줄링 동작을 세밀하게 조정할 수 있습니다.

설정 가능한 정책: Fair 스케줄러의 동작은 사용자 지정 설정을 통해 변경 가능합니다. 이를 통해 클러스터의 특정 요구 사항에 맞게 조정할 수 있습니다.

분석 및 모니터링: Fair 스케줄러는 작업 수행 내역을 쉽게 추적하고 모니터링할 수 있는 도구와 통합될 수 있습니다.

 

Fair 스케줄러의 동작 방식을 이해하기 위해 간단한 예시를 들어보겠습니다. 가상의 Hadoop 클러스터에는 다음과 같은 큐가 설정되어 있다고 가정해봅시다:

  1. Queue A (Fair Share: 50%): 리소스의 50%를 할당받는 큐입니다.
  2. Queue B (Fair Share: 30%): 리소스의 30%를 할당받는 큐입니다.
  3. Queue C (Fair Share: 20%): 리소스의 20%를 할당받는 큐입니다.

이제 각 큐에 속한 작업들이 제출되면 Fair 스케줄러는 리소스를 어떻게 할당하는지 살펴보겠습니다:

시나리오 1: 리소스가 충분한 경우

  • Queue A에 3개의 작업이 제출되면 각 작업은 리소스의 50%를 할당받게 됩니다.
  • Queue B에 2개의 작업이 제출되면 각 작업은 리소스의 30%를 할당받게 됩니다.
  • Queue C에 1개의 작업이 제출되면 리소스의 20%를 할당받게 됩니다.
  • 리소스가 충분하기 때문에 각 큐의 Fair Share 비율에 따라 리소스가 할당됩니다.

시나리오 2: 리소스가 한정된 경우

  • Queue A에 5개의 작업이 제출되고 리소스가 부족한 상황이면, 각 작업은 Fair Share 비율에 따라 리소스를 공평하게 할당받지 못할 수 있습니다.
  • Queue A의 Fair Share 비율이 높기 때문에 Queue B와 Queue C에 할당된 리소스가 적을 수 있습니다.
  • 그러나 Fair 스케줄러는 이러한 상황에서도 각 큐가 적어도 자신의 Fair Share 비율만큼의 리소스를 보장하려고 노력합니다. 그래서 Queue A에 더 많은 리소스가 할당될 것입니다.

시나리오 3: 우선 순위 큐 설정

  • Queue A에 3개의 작업이 제출되고 Queue B에 2개의 작업이 제출되었습니다.
  • 그러나 Queue A에 높은 우선 순위를 부여했으므로 Queue A의 작업이 먼저 리소스를 할당받게 됩니다.
  • 리소스가 여전히 Fair Share에 따라 분배되지만 우선 순위가 높은 Queue A에 먼저 할당됩니다.

 

Capacity 스케줄러 예시:

가상의 Hadoop 클러스터에는 Capacity 스케줄러를 사용하는 큐가 설정되어 있다고 가정합니다:

  1. Queue A (Capacity: 60%): 리소스의 60%를 할당받는 큐입니다.
  2. Queue B (Capacity: 40%): 리소스의 40%를 할당받는 큐입니다.

이제 각 큐에 속한 작업들이 제출되면 Capacity 스케줄러의 동작을 살펴보겠습니다:

시나리오 1: 리소스가 충분한 경우

  • Queue A에 4개의 작업이 제출되고 리소스가 충분하면 각 작업은 리소스의 60%를 할당받게 됩니다.
  • Queue B에 2개의 작업이 제출되고 마찬가지로 리소스의 40%를 할당받게 됩니다.
  • 리소스가 충분하기 때문에 각 큐의 Capacity 비율에 따라 리소스가 할당됩니다.

시나리오 2: 리소스가 부족한 경우

  • Queue A에 6개의 작업이 제출되고 리소스가 부족한 상황이면, 각 작업은 Capacity 비율에 따라 리소스를 공평하게 할당받지 못할 수 있습니다.
  • Queue A의 Capacity 비율이 높기 때문에 Queue B에 할당된 리소스가 적을 수 있습니다.
  • Capacity 스케줄러는 여전히 각 큐가 정의된 Capacity 비율에 따라 리소스를 분배하려고 시도하지만 리소스 부족으로 제한됩니다.

Fair 스케줄러와의 비교:

이제 Fair 스케줄러와 비교하겠습니다. Fair 스케줄러는 리소스가 부족한 경우에도 각 큐의 Fair Share 비율을 존중하려고 노력합니다. 따라서 Queue B에도 일정량의 리소스가 할당될 가능성이 높습니다. 그러나 Capacity 스케줄러는 Capacity 비율에 따라 엄격하게 리소스를 할당하므로 리소스 부족 상황에서는 특정 큐에게 우선권을 부여합니다.

요약하면, Capacity 스케줄러는 Capacity 비율을 기반으로 리소스를 엄격하게 할당하는 반면, Fair 스케줄러는 공정성을 중시하고 Fair Share 비율에 따라 리소스를 분배합니다. 어떤 스케줄러를 선택할지는 클러스터의 운영 환경 및 요구 사항에 따라 다를 수 있습니다. Capacity 스케줄러는 우선순위를 더 중요하게 생각하는 환경에서 사용될 수 있고, Fair 스케줄러는 공정한 리소스 공유가 필요한 환경에서 사용될 수 있습니다.

'Tools > Hadoop' 카테고리의 다른 글

하둡 네임노드와 HDFS  (0) 2023.09.11
MapReduce 이해 하기  (0) 2023.07.25
Hadoop YARN 아키텍쳐  (0) 2023.07.02
Hadoop HDFS 아키텍쳐  (0) 2023.07.02
Hadoop 컴퓨팅과 클러스터  (0) 2023.07.02