[빅데이터 전문가의 하둡관리] 하둡 클러스터의 리소스 할당

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

 

 

---

 

 

 

하둡의 리소스 할당

 

 

• 리소스 배정은 하둡 관리자에게 있어 핵심적인 업무라고 할 수 있다
  • 클러스터의 가장 중요한 리소스인 메모리와 CPU는 한정되어 있기 때문
  • 하둡 관리자는 조직 그룹 간에 적절하게 리소스를 할당해 각각의 SLA 수준을 만족시키도록 해야 한다!

 

• 클러스터의 작업량 관리하기 => 리소스 스케줄러를 이용한다!
  • 리소스 스케줄링이란? = 태스크에 우선순위를 부여, 얀 컨테이너에 태스크를 할당하는 것이다

 

• 하둡의 리소스 스케줄러는 3개가 있다.
  1. FIFO 스케줄러
  2. Capacity 스케줄러
  3. Fair 스케줄러

 

하나씩 간단히 알아보자.

 

 

---

 

 

 

FIFO 스케줄러

 

하나의 Job이 클러스터의 모든 자원을 점유한다

 

 

• task가 제출된 순서대로 1개씩 실행되며, 동시 실행되지 않는다.
• 운영 환경에서는 사용이 권장되지 않는다. 왜냐하면...

 

1) 리소스 독점문제

  -> 첫 번째 작업이 클러스터의 모든 리소스를 점유하면, 이후 작업은 대기해야 한다!!

 

2) 우선순위 고려 불가 문제

  -> 테스트 task를 처리하느라 중요한 production task가 대기로 밀릴 수도 있다!!

 

3) 클러스터 활용도가 낮아지는 문제

  -> task A가 메모리를 많이 사용하지만 CPU를 사용하지 않는다면? CPU는 유휴 상태로 방치된다...

  -> 그러므로 task를 동시 실행하는 다른 스케줄러를 사용하는 것이 클러스터 리소스를 최대한 활용하는 방법이다~!

 

 

 

---

 

Capacity 스케줄러

 

Job은 자기 큐 안의 자원을 점유한다

 

 

• 큐 기반 정적 할당 = 클러스터 리소스를 고정 비율로 큐별로 분배한다

 

• 각 큐는 설정된 용량 이상을 사용할 수 없다 (큐 별 리소스 격리!)
  • 단, 클러스터에서 리소스가 남을 때는 한가한 큐의 리소스를 바쁜 큐에 빌려줄 수도 있다. (default: enabled)
  • 빌려준 자원은 언제든 회수될 수 있다

 

• 유스케이스: 여러 팀이 동일한 클러스터를 사용하며, 각자의 리소스가 보장되어야 할 때 적합하다.

 

• 예시: A부서큐와 B부서큐에 40%, 60%에 리소스를 나눠주고 이 비율이 지속적으로 유지된다.

 

---

 

Fair 스케줄러

 

클러스터 자원은 실행중인 Job들에 동적으로 배분된다

 

• 클러스터 리소스를 태스크 간에 동적으로 분배한다.
  • 태스크 수와 리소스 요구량에 따라 클러스터 리소스를 실시간으로 조정한다.

 

• 우선순위가 상대적으로 높은 태스크가 없고, 공정한 리소스 분배가 중요한 환경에 적합하다

 

• 예시: A큐와 B큐의 리소스는 task수에 따라 동적으로 조정된다. A큐에 1개 task, B큐에 1개 task가 있을 때는 50%+50%의 분배가 이루어지고, B큐의 task가 3개로 늘어난다면 두 큐에 자원 분배는 25%+75%로 조정될 수 있다

 

 

 

 

 

---

 

 

그리고 가장 많이 사용되는 Capacity 스케줄러에 대해 딥 다이브 해보자!!

 

 

 

Capacity 스케줄러

1. 클러스터의 리소스 할당 제어를 큐(Queue)에 의존하는 방식이다.

 

 

 

2. 큐의 리소스 관리

• 큐에 제출된 Application은 FIFO 방식이다
• 큐에 제출된 Application이 일단 실행되면 리소스를 선점할 수 없다
  • 즉 이미 실행된 앱의 리소스는 회수하지 않는다

 

 

 

3. 한가한 큐의 리소스는 다른 큐에 빌려줄 수 있다.

 

 

 

4. 큐 생성하기

• 큐는 계층 구조를 가지고 있다 (부모 큐와 자식 큐)
• 설정을 통해 각 큐를 유저와 맵핑할 수 있으며, 리소스를 할당할 수도 있다

 

 

 

5. 큐의 리소스는 소프트 리미트와 하드 리미트에 따라 할당된다.

• 소프트 리미트: 최소 할당 용량
• 하드 리미트: 최대 할당 용량
  • 하드 리미트를 주어서 특정 큐가 과도하게 리소스를 독점하는 것을 방지한다.

 

 

 

6. User 별 Capacity 제한

 

(문제) submit된 application은 FIFO 방식이므로 뒤에 제출된 잡은 밀릴 수도 있다.

 

(해결.1) 한 사용자가 사용할 수 있는 큐의 리소스 최대 사용량을 설정할 수 있다. 예를 들어 0.25로 둔다면, 한 사용자는 큐에 소프트 리미트의 25%만 사용 가능 -> 그리고 남은 자원은 다른 사용자에게 분배되거나 유휴상태로 유지

      - 0.25일 때? => 각 사용자의 리소스 사용량을 제한하여 사용자들에게 공정 분배하지만 자원의 유휴 상태가 발생할 수도 있음
      - 1일 때? => 자원 활용도는 높지만, 특정 사용자가 리소스를 독점할 가능성이 있음

(해결.2)  실행되는 애플리케이션 수 제한하기
    - 한 큐에서 실행되는 애플리케이션 최대 개수를 제한하고
    - 애플리케이션에 할당할 수 있는 최대 리소스를 설정하여 특정 앱이나 큐가 자원을 독점하지 못하게 하는 방법

 

 

 

 

7. Capacity 설정 바꾸기

 

// Capacity 스케줄러 활성화
<property>
    <name>yarn.resourcemanager.scheduler.class</name>
    <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler</value>
</property>


// ApplicationMaster(AM)가 차지할 수 있는 최대 리소스 비율
<property>
  <name>yarn.scheduler.capacity.maximum-am-resource-percent</name>
  <value>0.1</value> <!-- 기본값: 10% -->
</property>


// 큐당 애플리케이션 최대 개수
<property>
  <name>yarn.scheduler.capacity.root.<queue-name>.maximum-applications</name>
  <value>100</value> <!-- 기본값: 제한 없음 -->
</property>


// root 큐 설정
<property>
  <name>yarn.scheduler.capacity.root.queues</name>
  <value>banana,apple,grape</value> <!-- 기본값: default 큐 1개 -->
</property>

 

---

 

 

 

Capacity 스케줄러와 Fair 스케줄러의 비교

 

비슷한 점

  1. 계층적 큐 지원

  2. 모든 큐가 root 또는 default 큐의 자식들
    root
     ├── default
     ├── production
     │    ├── critical
     │    └── noncritical
     └── testing

  3. 애플리케이션은 최하위 자식큐에만 submit 할 수 있다

  4. 큐에 소프트 리미트, 하드 리미트를 설정할 수 있다

  5. 큐 별로 애플리케이션 최대 수를 제한할 수 있다

  6. 애플리케이션을 다른 큐로 이동할 수 있다. (default: false)

 

 

 

다른 점

  1. 스케줄러의 리소스 할당 방식
    a. Fair 스케줄러는 자체적인 스케줄링 정책이 있음
    b. Capacity 스케줄러는 큐별로 FIFO 원칙으로 스케줄링함

  2. 공정한 동적 배분 VS 선점 정적 배분

 

---

이 포스팅은 2024년 10월 ~ 12월에 공부한 도서인 빅데이터 전문가의 하둡관리 13장을 공부한 후 작성하였습니다.