YARN으로 설계하는 클러스터 자원 스케줄링과 멀티테넌시

MapReduce 병목을 넘겨 애플리케이션별 자원을 배분하는 방식

YARN은 Apache Hadoop의 자원 관리 계층이다. Spark, Hive, MapReduce, Flink 같은 분산 애플리케이션을 한 클러스터에서 실행할 때 스케줄링, 격리, 모니터링을 맡는다. MapReduce v1의 JobTracker 병목을 해소하고, 멀티테넌시 환경에서 클러스터 활용률을 높이기 위한 프레임워크이기도 하다.

클러스터의 CPU, 메모리, 디스크, 네트워크와 GPU 같은 커스텀 리소스를 추상화한 뒤, 스케줄러 정책에 따라 컨테이너 단위로 배정한다. 클라이언트가 애플리케이션을 제출하면 ResourceManager가 먼저 ApplicationMaster용 컨테이너를 할당한다. 이후 ApplicationMaster가 작업 컨테이너를 요청하고 배치하며, 각 NodeManager는 자신이 담당하는 노드에서 컨테이너의 수명주기를 관리한다.

전역 제어와 노드 실행을 나누는 구조

ResourceManager가 조율하는 클러스터 자원

ResourceManager(RM)는 클러스터 전체의 자원 풀과 애플리케이션 간 자원 경쟁을 관리한다. 내부적으로 Scheduler는 자원 할당을 담당하고, ApplicationsManager(RMAppManager)는 애플리케이션 수명주기를 담당한다.

고가용성 구성에서는 ZooKeeper 기반 Active/Standby HA를 지원하며, 페일오버가 일어나면 상태를 복원한다.

NodeManager가 담당하는 실행 노드

NodeManager(NM)는 개별 슬레이브 노드의 자원을 모니터링하고 ResourceManager에 보고한다. 컨테이너 생성, 시작, 중지도 이 계층의 역할이다.

주기적인 하트비트로 상태와 가용 자원을 전달하며, cgroups와 TC 등을 이용해 자원을 격리한다. GPU, FPGA 같은 커스텀 리소스 플러그인을 지원하고 Docker/LCE 기반 런타임도 선택할 수 있다.

ApplicationMaster가 애플리케이션을 운영하는 방법

ApplicationMaster(AM)는 특정 애플리케이션의 오케스트레이션을 맡는다. 컨테이너 요청과 할당, 재시도, 진행 상태 추적을 수행한다.

AM은 최초에 할당된 AM 컨테이너에서 기동한다. 이후 작업 컨테이너를 동적으로 확장하거나 축소하며, 실패하면 설정된 최대 시도 횟수 안에서 재시작할 수 있다. 작업 상태 체크포인트와의 연계도 가능하다.

Container는 실행과 격리의 단위다

컨테이너는 CPU vcores, 메모리(MB), 디스크, 네트워크, GPU 등의 커스텀 리소스로 정의되는 실행 샌드박스다. 프로세스, 파일시스템, 자원을 격리하고 HDFS Log Aggregation을 통한 로그 수집·집계와 연결된다.

세분화된 태스크는 작업 컨테이너에서 수행된다. AM 컨테이너는 애플리케이션의 제어플레인 역할을 맡는다.

애플리케이션 제출부터 장애 재할당까지

⤢✕

큐 정책이 만드는 워크로드 경계

CapacityScheduler는 큐 기반 멀티테넌시를 제공한다. 최소·최대 용량, 프리엠션, DRF(Dominant Resource Fairness)를 지원하므로 SLA에 따라 자원 경계를 설계할 수 있다.

FairScheduler는 공유 클러스터의 공정성에 초점을 둔다. 최근 Hadoop 3.x에서는 더 이상 권장되지 않는다는 안내가 있어 최신 정보 확인이 필요하다. 노드 라벨과 플레이스먼트 제약은 특정 워크로드를 정해진 노드 집합에 격리 배치할 때 사용한다.

스케줄러	성능(대기/처리량)	확장성	일관성(자원 격리)	안정성(스파이크 대응)	운영 편의
CapacityScheduler	예측 가능, SLA 우선	대규모 큐/테넌트	강한 큐 격리, ACL	프리엠션/최소보장	정책 명확, 관리 용이
FairScheduler	짧은 대기, 공정성	중간	중간, 공유 지향	부하 변동에 민감	정책 유연, 조정 필요

혼합 워크로드에서의 적용 지점

Spark 스트리밍, Hive 배치, ML 트레이닝을 동시에 실행하는 클러스터에서는 큐, 우선순위, 프리엠션으로 SLA를 분리할 수 있다. 팀별 큐와 최대치 제한을 두면 과다 사용을 막으면서 남는 용량은 다른 테넌트가 사용할 수 있다.

GPU 타입과 개수를 기준으로 컨테이너를 할당하면 데이터 사이언스와 딥러닝 작업을 동적으로 확장할 수 있다. 데이터와 컴퓨트를 가깝게 배치해야 하는 경우에는 로컬리티와 노드 라벨을 이용하고, 노드 장애 시에는 자동 우회한다.

Kerberos 인증, 큐 ACL, 로그 집계, 메트릭은 작업 추적과 거버넌스에 사용된다.

GPU와 큐를 구성하는 최소 예시

전제조건은 Hadoop 3.3+, Linux cgroups 활성화이며 Kerberos는 선택 사항이다. GPU를 쓸 경우에는 드라이버와 권한 구성이 필요하다.

GPU 리소스 활성화(yarn-site.xml):

<configuration>
  <property>
    <name>yarn.resource-types</name>
    <value>yarn.io/gpu</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource-plugins</name>
    <value>yarn.io/gpu</value>
  </property>
  <property>
    <name>yarn.scheduler.capacity.resource-calculator</name>
    <value>org.apache.hadoop.yarn.util.resource.DominantResourceCalculator</value>
  </property>
</configuration>

큐 용량 구성(capacity-scheduler.xml):

yarn.scheduler.capacity.root.queues=prod,dev
yarn.scheduler.capacity.root.prod.capacity=60
yarn.scheduler.capacity.root.prod.maximum-capacity=80
yarn.scheduler.capacity.root.dev.capacity=40
yarn.scheduler.capacity.root.dev.maximum-capacity=70
yarn.scheduler.capacity.maximum-am-resource-percent=0.2

Spark on YARN 제출 예시:

spark-submit \
  --master yarn \
  --deploy-mode cluster \
  --conf spark.yarn.queue=prod \
  --conf spark.executor.instances=20 \
  --conf spark.executor.resource.gpu.amount=1 \
  --conf spark.task.resource.gpu.amount=0.125 \
  app.jar

격리 수준과 운영 복잡도를 함께 다루기

큐는 팀, 우선순위, SLA에 따라 나누고 최대치와 프리엠션을 설정한다. 격리를 강하게 할수록 미사용 용량을 다른 작업으로 넘기기 어려워진다.

DRF, cgroups, 노드 라벨은 다차원 자원의 공정성을 확보하는 수단이다. 다만 엄격한 격리는 처리량을 낮출 수 있다. RM HA와 State Store, AM 재시도, 체크포인트는 복구 체계를 구성하지만 운영 복잡도를 높인다.

보안 측면에서는 Kerberos/SPNego, 큐 ACL을 적용하고 Docker 런타임을 쓴다면 이미지 검증과 레지스트리 통제를 함께 고려한다. 보안 강화에는 오버헤드가 따른다. RM/NM JMX, Timeline Service/AMS2, 로그 집계, 큐별 SLO 대시보드는 운영 상태를 추적하는 수단이며, 세밀한 모니터링은 메트릭 저장 비용을 발생시킨다.

자원 통합이 가져오는 운영 변화

미사용 용량 공유와 DRF 기반 배분으로 자원 활용률은 20~~40%p 개선될 수 있다. 프리엠션, 우선순위, 로컬리티 최적화는 작업 대기시간을 30~~60% 단축하는 효과로 이어진다.

AM 재시작과 RM HA는 장애 내성을 높여 실패 재시도 성공률을 높인다. 멀티테넌시 통합은 운영 비용 절감에, ACL과 감사 로그는 거버넌스 강화에 연결된다.