YARN

ResourceManager는 YARN 클러스터에서 자원 관리와 애플리케이션 스케줄링을 담당하는 마스터 데몬 프로세스이다. 클러스터 전체의 자원(CPU, 메모리 등)을 통합적으로 관리하며, 모든 NodeManager로부터 하트비트와 자원 사용 보고를 받아 클러스터의 가용 자원을 추적한다. 클라이언트로부터 애플리케이션을 제출받으면, 적절한 Container를 할당하여 해당 애플리케이션의 ApplicationMaster를 실행시키는 책임을 진다. 일반적으로 클러스터당 하나의 활성 ResourceManager가 실행되며, 고가용성 모드에서는 활성-대기(Active-Standby) 쌍으로 구성된다.

ResourceManager의 핵심 기능은 크게 스케줄링과 애플리케이션 라이프사이클 관리로 나눌 수 있다. 스케줄링 기능은 설치된 스케줄러(FIFO 스케줄러, Capacity 스케줄러, Fair 스케줄러 등)에 따라, 대기 중인 애플리케이션의 자원 요청을 처리하고 가용한 자원이 있는 NodeManager에 컨테이너를 할당한다. 애플리케이션 관리 기능은 제출된 각 애플리케이션에 대해 ApplicationMaster를 시작하고 모니터링하며, ApplicationMaster가 실패할 경우 재시작을 결정한다.

ResourceManager의 주요 구성 요소와 역할은 다음과 같다.

ResourceManager는 YARN REST API를 제공하여 클러스터 상태, 실행 중인 애플리케이션 목록, 큐 정보 등을 조회하고 관리할 수 있게 한다. 또한 보안이 활성화된 클러스터에서는 Kerberos 인증을 통한 접근 제어를 지원한다. ResourceManager의 성능과 안정성은 전체 YARN 클러스터의 효율성을 결정하는 가장 중요한 요소이다.

NodeManager는 YARN 클러스터 내의 각 개별 노드(서버)에서 실행되는 데몬 프로세스이다. 이는 ResourceManager의 지시를 받아 해당 노드의 자원을 관리하고, 애플리케이션 실행을 위한 실제 작업 환경인 Container를 생성 및 모니터링하는 책임을 진다. 모든 클러스터 노드에는 하나의 NodeManager가 설치되어 실행되며, 이는 YARN이 분산 자원 관리를 가능하게 하는 핵심 에이전트 역할을 한다.

NodeManager의 주요 기능은 다음과 같다. 첫째, 주기적으로 ResourceManager에게 자신이 관리하는 노드의 가용 자원(CPU 코어 수, 메모리 용량 등)에 대한 하트비트(heartbeat)를 전송한다. 둘째, ResourceManager의 스케줄러로부터 할당받은 Container 실행 명령을 수신하면, 해당 컨테이너를 실행시키고 필요한 자원을 할당한다. 셋째, 실행 중인 컨테이너의 자원 사용량(CPU, 메모리, 디스크, 네트워크)을 지속적으로 모니터링하여 ResourceManager에 보고한다. 또한, 컨테이너의 생명주기를 관리하며, 작업이 완료되거나 ResourceManager의 명령에 따라 컨테이너를 종료시킨다.

NodeManager는 로컬 디스크와 같은 노드-로컬 자원도 관리한다. 애플리케이션(예: MapReduce) 실행에 필요한 JAR 파일, 캐시 파일, 실행 로그 등을 노드의 로컬 디스크에 저장하고 정리하는 작업을 담당한다. 이를 통해 네트워크 대역폭을 절약하고 데이터 접근 속도를 높이는 로컬화(localization)를 지원한다. 또한, 노드의 상태를 관리하여 노드가 비정상 상태가 되면 ResourceManager에 통보하여 해당 노드가 새로운 작업 할당에서 제외되도록 한다.

보안 및 격리 측면에서 NodeManager는 Linux Container (LXC)나 cgroups 같은 OS 수준의 자원 격리 메커니즘과 연동하여 컨테이너가 할당받은 자원 이상을 사용하지 못하도록 제한할 수 있다. 이는 다중 사용자 환경에서 애플리케이션 간의 간섭을 방지하고 자원 사용의 공정성을 보장하는 데 중요하다.

ApplicationMaster는 YARN에서 개별 애플리케이션(예: MapReduce 잡, Apache Spark 애플리케이션)마다 생성되는 인스턴스로, 해당 애플리케이션의 수명 주기를 전담 관리하는 마스터 프로세스이다. 각 애플리케이션은 자체 ApplicationMaster를 가지며, 이는 ResourceManager로부터 협상을 통해 자원을 할당받고, NodeManager와 협력하여 실제 작업을 실행하는 Container를 관리한다. 애플리케이션의 라이프사이클 동안 ResourceManager와 통신하는 책임을 지는 핵심 구성 요소이다.

ApplicationMaster의 주요 역할은 애플리케이션의 자원 요구 사항을 ResourceManager에 요청하고, 할당받은 자원(Container)을 사용하여 작업을 실행하는 것이다. 이 과정에는 작업의 진행 상황을 모니터링하고, 실패한 태스크를 재시작하며, 애플리케이션이 완료되면 사용한 자원을 정리하고 ResourceManager에 등록을 해제하는 작업이 포함된다. ApplicationMaster 자체도 ResourceManager로부터 자원을 할당받아 하나의 Container에서 실행되는 특수한 태스크이다.

다양한 컴퓨팅 프레임워크는 각자 고유한 ApplicationMaster 구현체를 제공한다. 예를 들어, MapReduce 애플리케이션은 MRAppMaster를 사용하고, Apache Spark는 SparkApplicationMaster를 사용한다. 이는 YARN이 다양한 분산 애플리케이션을 지원할 수 있도록 하는 플러그인 가능한 아키텍처의 핵심이다. ApplicationMaster는 프레임워크별 로직을 캡슐화하여, YARN은 자원 관리와 스케줄링에 집중할 수 있게 한다.

ApplicationMaster의 존재로 인해 YARN의 아키텍처는 중앙 집중식 JobTracker를 가진 이전 Hadoop MapReduce와 구별된다. 이는 확장성과 장애 허용 능력을 크게 향상시켰다. 하나의 ApplicationMaster 장애가 클러스터의 다른 애플리케이션에 영향을 미치지 않으며, ResourceManager는 실패한 ApplicationMaster를 다른 Container에서 재시작할 수 있다.

Container는 YARN에서 애플리케이션 실행을 위한 기본 단위이다. NodeManager가 관리하는 물리적 자원(예: CPU 코어, 메모리)의 묶음으로, 특정 애플리케이션의 태스크가 실행되는 격리된 환경을 제공한다. ApplicationMaster가 ResourceManager로부터 할당받은 자원은 구체적으로 컨테이너의 형태로 표현되며, 각 컨테이너는 특정 노드에서 실행되도록 할당된다. 컨테이너는 리눅스 컨테이너와 같은 OS 수준의 격리 메커니즘을 사용하여 자원 사용을 제한하고, 애플리케이션 간 간섭을 방지한다.

컨테이너의 생명주기는 ApplicationMaster의 요청으로 시작된다. ResourceManager의 스케줄러가 자원을 할당하면, 해당 NodeManager는 컨테이너를 실행하기 위한 환경을 구축하고 지정된 명령어(예: MapReduce의 맵 태스크 실행 명령)를 실행한다. 실행 중인 컨테이너는 애플리케이션의 실제 작업(데이터 처리, 계산 등)을 수행한다. 작업이 완료되거나 실패하면, 컨테이너는 종료되고 그 자원은 NodeManager에 의해 시스템에 반환되어 다른 애플리케이션이 사용할 수 있게 된다.

컨테이너의 자원 할당은 다음과 같은 주요 속성으로 정의된다.

이러한 컨테이너 모델은 YARN의 유연성과 확장성을 가능하게 하는 핵심이다. 다양한 애플리케이션 프레임워크(MapReduce, Apache Spark, Apache Tez 등)는 각자의 ApplicationMaster를 통해 고유한 작업을 수행하는 컨테이너를 생성하고 관리함으로써, 단일 클러스터에서 이기종 워크로드를 효율적으로 실행할 수 있다.

사용자는 yarn 명령어를 통해 애플리케이션을 클라이언트에 제출한다. 클라이언트는 애플리케이션의 실행에 필요한 정보(예: JAR 파일, 설정 파일)를 HDFS에 업로드하고, 애플리케이션 실행 요청을 ResourceManager에 전달한다.

ResourceManager는 요청을 받으면, 새로운 애플리케이션을 위한 고유한 Application ID를 할당하고, 애플리케이션의 상태를 관리하기 위한 ApplicationMaster 프로세스를 실행할 컨테이너를 예약한다. 이 예약된 컨테이너는 클러스터 내 한 NodeManager에서 실행된다. 해당 NodeManager는 컨테이너를 실행하고, 그 안에서 ApplicationMaster 프로세스를 구동한다.

ApplicationMaster가 실행되면, ResourceManager에 등록하여 자신의 존재를 알린다. 이후 ApplicationMaster는 애플리케이션 실행에 필요한 자원(예: CPU 코어, 메모리)을 ResourceManager에 요청한다. ResourceManager의 스케줄러는 클러스터의 가용 자원을 고려하여 요청을 승인하고, 자원이 할당될 NodeManager 목록을 ApplicationMaster에 반환한다.

ApplicationMaster는 자원이 할당된 각 NodeManager와 직접 통신하여 실제 작업(예: MapReduce 태스크)을 실행할 컨테이너의 실행을 지시한다. 작업이 실행되는 동안 ApplicationMaster는 모든 컨테이너의 상태를 모니터링하고, 실패한 태스크가 있으면 새로운 자원을 요청하여 재실행한다. 애플리케이션의 모든 작업이 완료되면, ApplicationMaster는 ResourceManager에 완료를 보고하고 자신의 실행을 종료한다. 최종적으로 ResourceManager는 애플리케이션의 실행을 완료된 것으로 표시하고 사용된 모든 자원을 해제한다.

이 흐름을 단계별로 정리하면 다음과 같다.

애플리케이션마스터는 실행 중인 애플리케이션을 대표하여 리소스매니저에게 자원을 요청한다. 이 요청은 일반적으로 컨테이너의 형태로, 필요한 CPU 코어 수, 메모리 용량, 그리고 선호하는 데이터 위치(예: 특정 노드매니저 또는 랙)를 명시한다. 요청은 지속적이며, 애플리케이션이 더 많은 작업을 처리해야 할 때 추가 자원을 요청하거나, 작업이 완료된 자원을 반환한다.

리소스매니저의 스케줄러는 이러한 요청을 받아 클러스터의 가용 자원과 구성된 정책에 따라 할당을 결정한다. 스케줄러는 노드매니저로부터 주기적으로 받은 하트비트와 자원 보고를 바탕으로 클러스터 전체의 자원 상태를 실시간으로 파악한다. 자원 할당 결정은 큐 기반으로 이루어지며, 각 큐에는 미리 정의된 용량이나 가중치가 부여된다. 스케줄러는 자원 할당을 결정할 때 데이터 지역성을 최적화하려고 노력한다. 요청된 데이터와 가장 가까운 노드에 컨테이너를 할당하여 네트워크 트래픽을 줄이고 처리 성능을 높인다.

자원 할당의 세부 메커니즘은 선택된 스케줄러 유형에 따라 달라진다. 주요 스케줄러의 자원 할당 방식은 다음과 같이 요약할 수 있다.

할당이 승인되면 리소스매니저는 해당 노드매니저에게 컨테이너를 실행하라는 지시를 내린다. 애플리케이션마스터는 직접 할당된 컨테이너와 통신하여 실제 작업(예: 맵 태스크 또는 리듀스 태스크)을 시작하고 모니터링한다. 작업이 완료되면 컨테이너는 해제되고 자원은 클러스터로 반환되어 다른 요청에 사용될 수 있다.

FIFO 스케줄러는 YARN에서 제공하는 가장 기본적인 형태의 스케줄러이다. 이름에서 알 수 있듯이, 이 스케줄러는 애플리케이션을 제출한 순서대로 처리한다. 먼저 제출된 애플리케이션이 먼저 실행되고, 해당 애플리케이션이 필요한 모든 자원을 할당받아 완료될 때까지 다음 애플리케이션은 대기해야 한다.

이 방식은 단순하고 예측 가능한 동작 방식을 가지지만, 몇 가지 명확한 한계를 가진다. 큰 규모의 작업이 먼저 제출되면, 그 작업이 완료될 때까지 후속으로 제출된 모든 짧은 작업들은 장시간 대기하게 된다. 이는 클러스터 자원의 활용률을 저하시키고, 사용자 경험을 나쁘게 만든다. 또한, 다중 사용자 환경이나 프로덕션 환경에서는 중요한 작업에 우선순위를 부여하거나 자원을 공정하게 분배할 수 없다는 단점이 있다.

FIFO 스케줄러의 동작을 요약하면 다음과 같다.

따라서 FIFO 스케줄러는 주로 학습, 테스트, 또는 단일 애플리케이션만을 실행하는 소규모 클러스터에서 사용된다. 다중 사용자와 다양한 워크로드를 처리해야 하는 현대적인 빅데이터 클러스터에서는 Capacity 스케줄러나 Fair 스케줄러와 같은 더 발전된 스케줄러가 표준으로 채택된다.

Capacity 스케줄러는 YARN의 핵심 스케줄러 중 하나로, 대규모 공유 클러스터 환경에서 자원을 효율적으로 관리하고 조직의 다양한 요구사항을 충족하도록 설계되었다. 이 스케줄러는 클러스터 자원을 여러 큐로 논리적으로 분할하여 운영하며, 각 큐에는 미리 정의된 용량(Capacity)이 할당된다. 기본 목표는 클러스터의 처리량을 높이면서도 각 큐가 보장된 최소 자원을 확보할 수 있도록 하는 것이다.

각 큐는 클러스터 전체 자원의 일정 비율을 할당받으며, 이는 해당 큐에 보장된 최소 용량이 된다. 큐는 계층 구조를 형성할 수 있어 부모 큐 아래에 자식 큐를 생성하고 용량을 세분화하여 배분할 수 있다. 한 큐의 할당량을 초과하여 사용하지 않는 자원이 있을 경우, 다른 큐에서 이를 유휴 자원으로 빌려 사용할 수 있는 엘라스틱 기능을 지원한다. 이는 자원 활용도를 극대화하는 데 기여한다.

Capacity 스케줄러의 주요 구성 요소와 정책은 다음과 같은 설정 파일들을 통해 정의된다.

이 스케줄러는 다중 테넌트 환경에 적합하며, 각 부서나 프로젝트별로 자원을 격리하고 예측 가능한 성능을 보장해야 하는 기업 환경에서 널리 채택된다. 또한 애플리케이션의 우선순위를 지원하여 동일 큐 내에서도 중요한 작업에 더 많은 자원을 신속하게 할당할 수 있다.

Fair 스케줄러는 YARN의 세 가지 기본 스케줄러 중 하나로, 애플리케이션 간에 클러스터 자원을 공정하게 분배하는 것을 목표로 한다. 이 스케줄러는 모든 실행 중인 애플리케이션이 시간이 지남에 따라 대략 동등한 양의 자원을 얻도록 보장한다. FIFO 스케줄러의 단점과 Capacity 스케줄러의 복잡성을 보완하기 위해 설계되었다.

Fair 스케줄러는 애플리케이션을 풀(Pool)이라는 논리적 그룹으로 구성하여 관리한다. 각 풀에는 최소 자원 보장량과 최대 자원 사용 한도를 설정할 수 있다. 스케줄러는 먼저 각 풀에 최소 보장 자원을 할당한 후, 남은 자원을 현재 실행 중인 애플리케이션의 수와 필요에 따라 공정하게 재분배한다. 이 방식은 작은 작업이 큰 작업 뒤에서 무기한 대기하는 것을 방지하고, 클러스터 이용률을 높인다.

주요 구성 요소와 동작 방식은 다음과 같다.

Fair 스케줄러는 동적인 환경에 적합하다. 짧은 작업이 제출되면 현재 실행 중인 큰 작업의 자원 일부를 빠르게 할당받아 응답 시간을 단축시킬 수 있다. 설정 파일(fair-scheduler.xml)을 통해 풀의 계층 구조, 스케줄링 정책(DRF[1] 등), 선점 시간outs 등을 세밀하게 제어할 수 있다. 이 스케줄러는 Apache Spark 및 다양한 대화형 워크로드가 혼재된 환경에서 널리 사용된다.

환경 설정 파일은 YARN 클러스터의 동작을 정의하는 핵심 요소이다. 주로 XML 형식으로 작성되며, 클러스터의 자원 할당, 스케줄링 정책, 보안, 로깅 등 다양한 측면을 제어한다. 주요 설정 파일은 yarn-site.xml, capacity-scheduler.xml(또는 fair-scheduler.xml), mapred-site.xml 등이 있다. 이러한 파일들은 보통 $HADOOP_HOME/etc/hadoop/ 디렉토리에 위치한다.

가장 중요한 설정 파일인 yarn-site.xml은 YARN 데몬들의 기본 동작을 구성한다. 여기에는 ResourceManager와 NodeManager의 호스트 주소, 포트, 자원 계산 방식, 애플리케이션 마스터 관련 설정 등이 포함된다. 예를 들어, yarn.resourcemanager.hostname은 ResourceManager의 주소를, yarn.nodemanager.resource.memory-mb는 각 노드 매니저가 관리할 수 있는 총 물리 메모리 양을 지정한다.

스케줄러별 설정 파일은 선택한 스케줄러에 따라 다르다. Capacity 스케줄러를 사용한다면 capacity-scheduler.xml 파일을 편집하여 큐의 계층 구조, 각 큐의 용량(Capacity)과 최대 용량(Maximum Capacity), 사용자 제한 등을 정의한다. Fair 스케줄러의 경우 일반적으로 yarn-site.xml 내에서 할당 파일(allocations file)의 경로를 지정하는 방식으로 구성한다.

설정 파일을 변경한 후에는 변경 사항이 적용되도록 관련 YARN 데몬들을 재시작해야 한다. 또한, 클러스터의 모든 노드에서 설정 파일이 일관되게 유지되는 것이 중요하다. 구성 오류는 자원 할당 실패나 데몬 기동 실패로 이어질 수 있으므로, 설정값을 변경할 때는 공식 문서와 클러스터의 실제 자원 사양을 신중히 고려해야 한다.

YARN 클러스터 배포는 일반적으로 하나의 ResourceManager와 다수의 NodeManager를 물리적 또는 가상 머신에 설치하여 구성한다. 배포 방식은 주로 수동 설치, 패키지 관리자를 통한 설치, 또는 Apache Ambari나 Cloudera Manager와 같은 클러스터 관리 도구를 활용하는 방법으로 나뉜다. 수동 배포는 각 노드에 Hadoop 배포판을 다운로드하고, 환경 설정 파일들을 직접 수정하여 구성하는 방식이다.

클러스터 배포의 핵심 단계는 다음과 같다. 먼저 모든 노드에 Java 런타임 환경을 설치하고 호스트 이름 및 네트워크 구성을 완료한다. 이후 Hadoop 소프트웨어를 모든 노드에 배포하고, yarn-site.xml, core-site.xml 등의 설정 파일을 중앙에서 관리하며 각 노드에 동기화한다. 주요 설정 항목으로는 ResourceManager의 호스트 주소, NodeManager의 가용 자원(메모리, CPU 코어), 그리고 사용할 스케줄러의 종류와 정책이 포함된다.

배포 후에는 클러스터의 정상 동작을 확인하기 위해 일련의 검증 절차를 수행한다. ResourceManager와 NodeManager 데몬을 시작한 후, yarn node -list 명령어를 통해 모든 NodeManager가 정상 등록되었는지 확인한다. 간단한 MapReduce 예제 애플리케이션을 실행시켜 자원 요청, 할당, 실행, 완료의 전 과정이 문제없이 이루어지는지 테스트하는 것이 일반적이다.

대규모 프로덕션 환경에서는 고가용성 구성을 위해 ResourceManager를 액티브-스탠바이(Active-Standby) 쌍으로 배포하거나, NodeManager의 재시작 정책과 로그 관리를 자동화한다. 또한, Kerberos를 통한 보안 인증을 적용하는 경우 배포 과정에서 해당 설정이 추가된다.

yarn 명령어는 YARN 클러스터를 관리하고 애플리케이션을 제출 및 모니터링하기 위한 기본적인 CLI(Command Line Interface) 도구이다. 이 명령어는 사용자가 클러스터 자원 상태를 확인하고, 애플리케이션을 실행하거나 종료하며, 로그를 조회하는 등의 작업을 수행할 수 있게 해준다.

주요 하위 명령어와 그 기능은 다음과 같다.

가장 빈번하게 사용되는 명령어 그룹은 yarn application이다. 예를 들어, yarn application -list는 실행 중이거나 완료된 애플리케이션 목록을 보여주며, yarn application -kill <Application_ID>는 지정된 애플리케이션을 강제로 중지시킨다. 또한 yarn logs -applicationId <Application_ID> 명령어는 특정 애플리케이션의 모든 컨테이너 로그를 수집하여 사용자에게 제공한다. 이러한 명령어들은 Hadoop 분산 환경에서 애플리케이션의 생명주기를 효과적으로 제어하는 데 필수적이다.

YARN 클러스터에서 실행 중인 애플리케이션의 상태와 자원 사용 현황을 모니터링하는 것은 시스템 운영의 핵심이다. YARN은 명령줄 도구와 웹 기반 GUI를 통해 포괄적인 모니터링 기능을 제공한다.

가장 기본적인 방법은 yarn 명령어를 사용하는 것이다. yarn application -list 명령은 제출된 모든 애플리케이션의 목록과 상태(예: ACCEPTED, RUNNING, FINISHED, FAILED)를 보여준다. 특정 애플리케이션의 상세 로그를 확인하려면 yarn logs -applicationId <애플리케이션_ID> 명령을 사용한다. 또한 yarn node -list 명령으로 클러스터 내 모든 NodeManager의 상태와 가용 자원을 점검할 수 있다.

보다 직관적인 모니터링을 위해 ResourceManager와 각 ApplicationMaster는 내장 웹 UI를 제공한다. ResourceManager의 웹 UI(기본 포트 8088)에서는 클러스터 전체의 자원 사용률, 실행 중인 애플리케이션 목록, 스케줄러 큐 정보, 그리고 각 노드의 상태를 한눈에 확인할 수 있다. 여기서 특정 애플리케이션을 클릭하면 해당 애플리케이션의 ApplicationMaster 웹 UI로 연결되어 태스크 수준의 상세 실행 로그, 진행 상황, 자원 소비 내역 등을 심층적으로 분석할 수 있다.

이러한 도구들을 조합하여 운영자는 애플리케이션의 실패 원인을 진단하거나, 자원 병목 현상을 식별하며, 클러스터 성능을 최적화할 수 있다. 또한 모니터링 데이터는 JMX를 통해 외부 모니터링 시스템(예: Prometheus, Grafana)에 연동하여 대시보드 구축 및 알림 설정에 활용될 수 있다.

리소스 관리 정책은 YARN 클러스터에서 자원의 할당, 사용, 제한을 정의하는 규칙의 집합이다. 이 정책들은 클러스터의 효율성, 다중 테넌시 지원, 안정성을 보장하는 데 핵심적인 역할을 한다. 주요 정책은 컨테이너의 자원 할당량 관리, 큐 기반의 자원 분배, 그리고 실제 사용량 모니터링 및 제한으로 구분된다.

자원 할당의 기본 단위는 Container이며, 여기에는 CPU 코어(vCore)와 메모리(MB)가 지정된다. YARN은 사용자나 애플리케이션이 요청할 수 있는 최소/최대 자원 한도를 설정할 수 있다. 예를 들어, 특정 큐에 속한 애플리케이션은 컨테이너당 최소 1 vCore, 1024MB, 최대 4 vCore, 8192MB를 사용하도록 제한될 수 있다. 이러한 정책은 yarn-site.xml 및 capacity-scheduler.xml(또는 fair-scheduler.xml)과 같은 환경 설정 파일을 통해 정의된다.

큐 기반의 자원 분배는 선택한 스케줄러에 의해 구현된다. Capacity 스케줄러는 미리 정의된 용량(예: 전체 클러스터 자원의 30%)을 각 큐에 보장하는 반면, Fair 스케줄러는 실행 중인 애플리케이션 간에 자원을 동적으로 균등하게 분배하려고 한다. 두 스케줄러 모두 다음과 같은 고급 정책을 지원한다.

실제 자원 사용 모니터링과 제한을 위해 YARN은 Linux Container Executor와 같은 실행기를 통해 운영 체제 수준의 제어를 활용한다. 이는 cgroups와 같은 기술을 사용하여 컨테이너가 할당된 CPU와 메모리 한도를 초과하여 사용하지 못하도록 강제한다. 또한, 로그 집계 정책을 설정하여 애플리케이션이 완료된 후 NodeManager의 로그를 HDFS와 같은 중앙 저장소로 자동 이동시켜 로컬 디스크 공간을 관리할 수 있다. 이러한 정책들을 종합적으로 구성함으로써 관리자는 클러스터 자원의 공정한 분배, 안정적인 운영, 그리고 높은 활용률을 동시에 달성할 수 있다.

YARN 클러스터의 보안을 강화하기 위해 Kerberos 네트워크 인증 프로토콜을 통합할 수 있다. 이는 Hadoop 생태계 전반에 걸쳐 인증을 제공하는 데 널리 사용되는 방식이다. Kerberos는 중앙 집중식 키 분배 센터(KDC)를 통해 티켓 기반의 강력한 상호 인증을 수행하여, 사용자와 서비스가 서로의 신원을 확인하도록 한다. YARN에서 Kerberos를 활성화하면, ResourceManager와 NodeManager 같은 데몬 프로세스뿐만 아니라 제출된 애플리케이션도 안전하게 인증되어야만 클러스터 자원에 접근할 수 있다.

주요 구성 요소는 다음과 같다.

설정 과정은 크게 두 단계로 나뉜다. 첫째, KDC 서버에 YARN 관련 서비스와 사용자에 대한 보안 주체를 생성하고 키탭 파일을 생성하여 각 호스트에 배포한다. 둘째, YARN 구성 파일(yarn-site.xml)을 수정하여 Kerberos 인증을 활성화한다. 여기에는 인증 매커니즘을 kerberos로 설정하고, 각 서비스의 보안 주체명과 키탭 파일 위치를 지정하는 작업이 포함된다.

이러한 설정이 완료되면, 모든 RPC 통신은 SASL/GSSAPI를 통해 암호화되고 인증된다. 사용자는 kinit 명령어로 티켓을 획득한 후에만 애플리케이션을 제출하거나 클러스터와 상호작용할 수 있다. 또한, Access Control List(ACL)과 같은 권한 부여 메커니즘과 결합하여, 인증된 사용자가 수행할 수 있는 작업을 세부적으로 제어할 수 있다. 이는 다중 사용자 환경에서 자원의 안전한 공유와 데이터 무결성을 보장하는 데 필수적이다.

YARN의 고가용성 구성은 ResourceManager가 단일 장애점이 되는 문제를 해결하기 위한 기능이다. 기본 구성에서는 ResourceManager 하나가 중단되면 전체 클러스터의 자원 관리와 애플리케이션 스케줄링이 중단된다. 고가용성 모드는 Active/Standby 쌍의 ResourceManager를 설정하여 이 문제를 완화한다.

고가용성 구현은 주로 Apache ZooKeeper를 기반으로 한다. ZooKeeper는 Active ResourceManager의 선출, 상태 동기화, 장애 감지 및 페일오버 조정을 담당한다. 구성 요소 간의 상태 정보는 공유 스토리지(예: HDFS 또는 LevelDB를 사용하는 ZKRMStateStore)에 지속적으로 저장되어, Standby ResourceManager가 페일오버 시 최신 상태를 이어받을 수 있게 한다. 주요 설정 파일인 yarn-site.xml에서 관련 속성을 정의한다.

고가용성 구성 시 주의할 점은 모든 NodeManager와 클라이언트가 ResourceManager에 접근할 때 고가용성을 인식해야 한다는 것이다. 이를 위해 yarn.resourcemanager.ha.rm-ids에 정의된 모든 ResourceManager 주소를 라운드 로빈 방식으로 시도하도록 설정하거나, 가상 IP 주소나 로드 밸런서를 통해 단일 접근점을 제공하는 방법을 사용한다. 정상적인 페일오버가 발생하면 실행 중인 애플리케이션은 중단되지 않고 계속 진행되지만, 새로운 애플리케이션 제출은 짧은 지연 후 새 Active ResourceManager로 처리된다.

YARN은 Hadoop 2.0부터 도입된 핵심 자원 관리 플랫폼으로, MapReduce를 포함한 다양한 데이터 처리 애플리케이션을 실행할 수 있는 기반을 제공한다. YARN 이전의 Hadoop 1.0에서는 JobTracker가 자원 관리와 애플리케이션 라이프사이클 관리를 모두 담당하는 단일 아키텍처를 사용했다. 이로 인해 확장성과 다른 처리 프레임워크 지원에 한계가 있었다. YARN은 이러한 문제를 해결하기 위해 자원 관리 기능을 범용화했으며, 그 결과 MapReduce는 YARN 상에서 동작하는 여러 애플리케이션 중 하나가 되었다.

YARN과 MapReduce의 연동은 MapReduce ApplicationMaster를 통해 이루어진다. 사용자가 MapReduce 잡을 제출하면, YARN의 ResourceManager는 먼저 컨테이너를 할당하여 이 잡 전용의 MapReduce ApplicationMaster를 실행한다. 이 ApplicationMaster는 YARN에게 자원을 요청하고 할당받은 컨테이너에서 Map 태스크와 Reduce 태스크를 실행한다. 또한 태스크의 진행 상태를 모니터링하고, 실패한 태스크를 재시도하는 등 전체 잡의 라이프사이클을 관리한다. 이 구조는 MapReduce 프레임워크의 로직과 클러스터 자원 관리의 책임을 명확히 분리한다.

기존의 MapReduce API와 배포판은 YARN을 완벽히 지원한다. 사용자는 hadoop jar 명령어를 사용하여 기존의 MapReduce 프로그램을 변경 없이 YARN 클러스터에서 실행할 수 있다. 구성 파일(mapred-site.xml, yarn-site.xml)을 통해 YARN의 자원 할당량, 스케줄러 종류, ApplicationMaster 메모리 크기 등을 세부적으로 조정할 수 있다. YARN의 도입으로 MapReduce는 더 큰 규모의 클러스터에서 실행될 수 있게 되었고, Capacity 스케줄러나 Fair 스케줄러를 통해 여러 잡 간에 자원을 효율적으로 공유할 수 있게 되었다.

이러한 연동 구조는 Hadoop 에코시스템의 진화에 중요한 기반이 되었다. MapReduce는 여전히 배치 처리 작업에 사용되지만, YARN이라는 공통 플랫폼 위에서 Apache Spark, Apache Tez, Apache Hive 등과 같은 다른 데이터 처리 엔진과 동일한 클러스터 자원을 효율적으로 공유하며 병렬로 실행될 수 있다.

YARN은 Hadoop 2.0부터 도입된 범용 자원 관리 플랫폼으로, MapReduce 외에도 다양한 데이터 처리 프레임워크를 실행할 수 있는 기반을 제공한다. Spark, Hive, Flink, Tez와 같은 에코시스템의 핵심 프로젝트들은 YARN 위에서 자원을 할당받고 실행되어, 하나의 클러스터 인프라를 효율적으로 공유한다.

Apache Spark는 YARN과의 통합을 통해 두 가지 모드로 실행될 수 있다. YARN 클라이언트 모드에서는 Spark 드라이버가 클라이언트 머신에서 실행되며, YARN 클러스터 모드에서는 드라이버가 YARN ApplicationMaster 내에서 실행되어 클러스터 내부에 위치한다. 두 경우 모두 Spark의 익스큐터는 YARN Container로 실행되어, YARN의 ResourceManager와 NodeManager가 자원 할당과 모니터링을 담당한다. 이를 통해 Spark 애플리케이션은 HDFS에 저장된 데이터에 효율적으로 접근하면서도, 다른 YARN 애플리케이션과 자원을 안정적으로 나누어 사용할 수 있다.

Apache Hive는 쿼리 실행 엔진으로 MapReduce, Tez, 또는 Spark를 사용할 수 있으며, 이들 엔진은 모두 YARN 위에서 실행된다. 특히 Hive에 Tez 실행 엔진을 사용할 경우, 복잡한 DAG 기반의 작업을 YARN 컨테이너에서 실행하여 대화형 쿼리 성능을 크게 향상시킨다. Hive 서버 2의 각 세션은 YARN 애플리케이션으로 제출되어 자원을 할당받는다. 주요 통합 구성은 다음과 같다.

이러한 통합 구조는 여러 프레임워크가 단일 클러스터 자원 풀을 공유하면서도 데이터 지역성을 최대화할 수 있게 한다. 사용자는 YARN의 Capacity 스케줄러나 Fair 스케줄러를 통해 Spark, Hive, MapReduce 등의 작업 큐에 자원을 할당하고 우선순위를 관리할 수 있다. 결과적으로 YARN은 하둡 에코시스템의 통합 운영 체제 역할을 수행하며, 복잡한 데이터 워크로드의 통합 관리와 자원 효율성을 실현한다.