시작하세요 하둡 프로그래밍 CH 8. YARN 아키텍처의 이해

Q·2022년 11월 2일
0

시작하세요 하둡 프로그래밍

목록 보기
8/11

1. 얀 작업 흐름

먼저 전반적인 흐름에 대해 알아보고, 각 단계별 동작 방식에 대해 알아보도록 하자. 전반적인 흐름은 다음과 같다.

  1. 클라이언트 : 리소스 매니저에게 어플리케이션 실행 요청
    • 얀 API 구현한 프로그램이면 모든 어플리케이션 실행 가능
    • 리소스 매니저 : 클라이언트에게 신규 어플리케이션 ID 할당

2a. 리소스 매니저 : 노드 매니저에게 어플리케이션 마스터 실행 요청
2b. 노드 매니저 : 컨테이너에서 어플리케이션 마스터 실행

  1. 어플리케이션 마스터 : 리소스 매니저에게 어플리케이션 실행 위한 리소스 요청
    • 리소스 매니저 : 전체 클러스터 리소스 상태 확인, 어플리케이션 마스터에게 노드 매니저 목록 전송

4a. 어플리케이션 마스터 : 할당받은 노드 매니저들에게 컨테이너 실행 요청
4b. 노드 매니저 : 컨테이너에 새로운 JVM 생성, 어플리케이션 실행

2. 얀 단계별 동작 방식

이번에는 각 컴포넌트 간 어떠한 상호작용이 발생하는지에 대해 알아보자.

2-1 어플리케이션 실행 요청

위의 전반적인 흐름에서 클라이언트가 리소스 매니저에게 어플리케이션 실행을 요청하는 단계다.
(1 : submit YARN application 부분)

  1. 클라이언트가 어플리케이션을 얀 클러스터에서 실행하려면, 신규 어플리케이션 ID를 발급받아야 한다.

    • 클라이언트 : createNewApplication 메소드를 호출해 어플리케이션 ID 발급을 요청

  2. 리소스 매니저 : 신규 어플리케이션 ID, 리소스 정보 설정되어있는 GetNewApplicationResponse 객체 반환

  3. 클라이언트 : 어플리케이션 ID가 정상적으로 반환되었는지 확인

    • 리소스 매니저에게 submitApplication 메소드 호출

  4. 클라이언트 : 리소스 매니저에게 getApplicationReport 요청

  5. 리소스 매니저 : 어플리케이션이 정상적으로 등록되었을 경우 ApplicationReport 반환

2-2 어플리케이션 마스터 실행 요청 후 실행

리소스 매니저가 노드 매니저에게 어플리케이션 마스터 실행을 요청하고 실행하는 단계다.
(2a : start container, 2b : launch 부분)

  1. RMAppManager는 어플리케이션 목록을 관리하는 컴포넌트이다.
    • RMAppManager
      • 리소스 매니저 내부 스케쥴러에게 어플리케이션 등록
      • 어플리케이션 마스터 실행하기 위한 컨테이너 요청
      • 어플리케이션 실행 시도 횟수만큼 ApplicationAttemptId 생성
  1. 스케쥴러 : 어플리케이션이 사용하는 큐에 ApplicationAttemptId 등록
    • RMAppManager 스케쥴 등록 결과 알 수 있도록 RMAppAttemptEventType.ATTEMPT_ADDED 이벤트 발생
  2. RMAppManager : 스케쥴러에게 ApplicationAttemptId에 대한 컨테이너 할당 요청
  1. 스케쥴러 : ApplicationAttemptId에게 컨테이너 할당
    • RMAppManager 어플리케이션 마스터 실행하도록 RMContainerEventType.START 이벤트 발생
  2. RMAppManager : 어플리케이션 마스터를 실행하는 컴포넌트 ApplicationMasterLauncher 실행
  3. ApplicationMasterLauncher : AMLauncher 실행해 어플리케이션 마스터 실행
  1. AMLauncher : 컨테이너 정보 설정
    • 노드 매니저에게 어플리케이션 마스터 실행 요청
  2. 노드 매니저 : AMLauncher가 요청한 컨테이너 실행
    • 실행 결과가 저장되어있는 StartContinersResponse 반환

2-3 어플리케이션 마스터 등록

리소스 매니저는 클러스터 내 실행되는 여러 어플리케이션 마스터에게 자원 할당하고 상태를 모니터링한다.
따라서 어플리케이션 마스터가 실행되면 리소스 매니저에 등록되어야 한다.
(3: allocate resources 부분)

  1. 어플리케이션 마스터의 클라이언트 : registerApplicationMaster 메소드 호출해 어플리케이션 마스터 등록 요청
  2. ApplicationMasterService는 리소스 매니저의 어플리케이션 마스터 목록을 관리한다.
    • ApplicationMasterService
      • 어플리케이션 마스터 목록에 해당 어플리케이션 마스터 추가
      • AllocateResponse 객체 반환
  1. 어플리케이션 마스터 : allocate 메소드 호출해 어플리케이션 실행하는 데 필요한 리소스 할당 요청
  1. ApplicationMasterService
    • 컨테이너 할당 요청을 스케쥴러에게 위임
    • 어플리케이션 마스터에게 스케쥴러 응답 결과 반환

2-4 컨테이너 실행

어플리케이션 마스터는 자신이 할당받은 컨테이너에서 어플리케이션을 실행한다.
(4a: start container, 4b: launch 부분)

  1. 어플리케이션 마스터의 클라이언트 : startContainer 메소드 통해 노드 매니저에게 컨테이너 실행 요청
  1. 노드 매니저의 ContainerManager : 어플리케이션 마스터가 요청한 컨테이너 실행
    • 실행 결과로 StartContainersResponse 객체 반환
  1. 어플리케이션 마스터 : 각 컨테이너에서 어플리케이션들 작동여부 모니터링
    • getContainerStatus 주기적으로 호출해 컨테이너 실행 상태 확인
  2. ContainerManager : 컨테이너 실행상태를 GetContainerStatusesResponses 객체 통해 반환

3. 보조 서비스 (Auxiliary Service)

보조 서비스는 노드매니저 간의 서비스 제어를 위한 기능이다.
이러한 서비스를 이용해 서로 다른 노드 매니저 사이에 데이터를 전달하거나 다른 노드 매니저를 제어할 수 있다.

보조 서비스 설정은 다음과 같이 진행하면 된다.

<?xml vesrsion="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
 <property>
  <name>yarn.nodemanager.aux-service</name>
  <value>mapreduce_shuffle</value>
 </property>
 <property>
  <name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name>
  <value>org.apache.hadoop.mapred.ShuffleHandler</value>
 </property>
</configuration>

4. 프리엠션 (Preemption)

얀의 capacity scheduler는 계층적인 큐 형식으로 리소스를 정의한다.
capacity scheduler는 리소스에 여유가 있을 경우 큐에 설정된 자원보다 더 많은 자원을 사용할 수 있다.
하지만 리소스에 여유가 없는 경우 다른 큐에서 실행 중인 어플리케이션이 종료될 때까지 대기해야한다.

이처럼 자원을 공평하게 할당받지 못하는 상황에서, 다른 어플리케이션의 자원을 회수할 수 있는 기능을 프리엠션이라고 한다.

프리엠션의 호출 방식에 대해 알아보자.

  1. 리소스 매니저 : 프리엠션 구현 클래스를 SchedulingMonitor에 등록

  2. SchedulingMonitor

    • 프리엠션 모니터 주기 반환하는 getMonitorInterval 메소드 호출
    • 프리엠션 실행 구현할 editSchedule 메소드 호출

  3. SchedulingEditPolicy : editSchedult 메소드에 구현된 프리엠션 실행

5. 타임라인 서비스

타임라인 서비스는 얀 클러스터에서 실행되는 어플리케이션의 히스토리 상태, 메트릭 정보를 유지하기 위한 서비스다.

타임라인 서비스 아키텍쳐는 다음과 같다.

  • 타임라인 저장소 : 인메모리 저장소와 레벨DB 저장소 사용 가능
  • 타임라인 클라이언트 : 타임라인 서비스의 REST API 중 POST 메소드 래핑
  • 서비스 클라이언트 : 타임라인 서비스의 REST API 호출하는 클라이언트
  • REST API : HTTP, HTTPS로 호출 가능, 처리 결과 JSON 형태로 전달

6. 얀 이벤트 처리

얀이 동작할 때에 내부적으로 다양한 이벤트가 발생한다.
얀은 효율적인 이벤트를 처리하기 위해 비동기 디스패처와 스테이트 머신 모델을 제공한다.

6-1 비동기 디스패처 (Async Dispatcher)

얀은 비동기 방식으로 이벤트를 처리하며, 이를 지원하기 위한 비동기 디스패처를 제공한다.
비동기 디스패처는 싱글 스레드 기반으로 동작하여 속도가 빠르고 시스템 자원을 적게 소모한다.

다음은 비동기 디스패처의 동작 과정이다.

  1. 클라이언트 : 비동기 디스패처의 handle 메소드 호출해 이벤트 처리 요청

  2. 비동기 디스패처 : eventHandlingThread로 이벤트 요청 처리, 싱글 스레드로 실행

  3. eventHandlingThread : handle 메소드 호출해 이벤트 처리 클래스에게 이벤트 요청 전달

  4. 이벤트 핸들러 : 요청받은 handle 메소드에 정의된 로직 실행

6-2 스테이트 머신 (State Machine)

리소스 매니저와 노드 매니저의 내부 컴포넌트들은 상태 정보가 다양하게 변경된다.
얀은 상태 변경을 효율적으로 처리하기 위해 스테이트 머신 모델을 제공한다.
스테이트 머신 모델은 상태 변경을 자동으로 인지하고 관련된 로직을 처리할 수 있다.
또한 잘못된 상태 전환이 발생했을 때 자동으로 장애 처리가 가능하다.

다음은 스테이트 머신 모델의 동작 과정이다.

  1. ResourceTrackerService : 노드 매니저가 하트비트 전송하지 않으면 해당 노드 매니저 재부팅 요청

  2. 비동기 디스패처 : NodeEventDispatcher의 handle 메소드 호출해 이벤트 처리 요청

  3. NodeEventDispatcher : handle 메소드 호출해 이벤트 처리

  4. RMNodeImpl : 스테이트 머신의 doTransition 메소드 호출해 상태 변경

  5. RMNodeImpl : 리소스 매니저가 관리하는 노드 매니저 목록에서 삭제되기 위해
    DeactivateNodeTransition 메소드는 NodesListManagerEventType.NODE_UNUSABLE 이벤트 요청

7. 아키텍처 심화 학습

리소스 매니저와 노드 매니저는 다양한 내부 컴포넌트로 이루어져 있다.
이번에는 리소스 매니저와 노드 매니저의 구조에 대해 알아본다.

7-1 리소스 매니저

리소스 매니저는 전체 클러스터의 가용 리소스를 스케쥴링하고 어플리케이션들에게 리소스를 중재한다.
또한 노드 매니저와 어플리케이션 마스터를 제어하여 어플리케이션들이 정상적으로 실행될 수 있도록 한다.

아래 그림은 리소스 매니저의 컴포넌트 구성을 기능별로 분류한 그림이다.

주요 컴포넌트들만 살펴보자.

  • RMContext : 리소스 매니저의 컨텍스트 정보 유지
  • Dispatcher : 이벤트 전달 위한 인터페이스
  • ResourceScheduler : 클러스터에서 실행되는 어플리케이션에게 리소스 할당

7-2 노드 매니저

노드 매니저는 슬레이브 서버 역할을 하는 모든 서버에서 실행되어 컨테이너의 생명주기를 관리한다.
또한 노드 매니저가 실행되는 서버 자원을 모니터링하여 상태 정보를 리소스 매니저에게 전송한다.

아래 그림은 노드 매니저의 컴포넌트 구성을 기능별로 분류한 그림이다.

마찬가지로 주요 컴포넌트만 살펴보자.

  • NMContext : 노드 매니저의 주요 컨텍스트 정보 제공
  • 비동기 디스패처 : 노드 매니저의 내부 이벤트를 처리
  • WebServer : 웹 인터페이스로 실행되는 어플리케이션, 컨테이너 목록과 같은 정보 제공
  • NodeManagerMetrics : 컨테이너와 시스템 리소스 정보 모니터링
  • ContainerExecutor : 서버에서 컨테이너 실행하는 기능 제공
  • DeletionService : 클라이언트에게 할당되었던 디렉토리와 파일 삭제
profile
Q
Data Engineer
이전 포스트

시작하세요 하둡 프로그래밍 CH 7. 부분 정렬

다음 포스트

시작하세요 하둡 프로그래밍 CH 9-1. YARN Application 개발

0개의 댓글