ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [빅데이터 전문가의 하둡관리] 2. 하둡 아키텍처 개요
    Software Development/Big Data 2022. 8. 31. 21:22

    http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788931555752

     

    빅데이터 전문가의 하둡 관리 - 교보문고

    스파크 얀 HDFS 관리, 튜닝 및 보안 비법 대공개! | 빅데이터 전문가의 하둡 관리 데이터 양이 많은 페이스북같은 기업에서 서버의 트래픽이 몰리지 않고 사용자가 빠른 피드백을 받도록 하려면?

    www.kyobobook.co.kr

    위 책의 내용을 읽으며 공부한 내용을 요약 및 정리한 글입니다. 자세한 내용은 위 책에서 알 수 있습니다.

    분산 컴퓨팅과 하둡

    분산 컴퓨팅은 다음과 같은 필요조건들을 충족시키고자 한다.

    • 확장성: 머신 수가 증가함에 따라 컴퓨팅 능력과 스토리지 공간이 선형적으로 증가해야 한다.
    • 장애 허용: 분산 클러스터의 노드들 중 하나가 정상적으로 작동하지 않을 때, 이것이 메인 컴퓨팅 프로세스를 실패하게 하거나 부정적인 영향을 미치지 않아야 한다.
    • 회복력: 잡이나 잡의 일부가 잘못돼도 어떤 데이터도 손실되면 안된다.

    하둡의 아키텍처는 다음과 같은 전략과 원칙으로 분산 컴퓨팅 문제를 해결한다.

    • 데이터는 전체 또는 대부분이 클러스터 노드에 저장된다. 데이터에 코드를 제공해주고, 그 반대되는 경우는 일어나지 않게 함으로써 하둡은 많은 양의 데이터를 효과적으로 처리한다.
    • 개발자들은 데이터와 알고리즘에 집중하고, 하둡은 분산 프로그래밍의 하위 레벨 로직을 처리한다.
    • 하둡 잡은 높은 장애 허용성을 가진다. 클러스터에 있는 하나 이상의 노드들이 실패한 경우나 잡의 일부 컴포넌트에 문제가 발생하더라도 잡 자체는 아무 문제없이 동작한다.

    하둡 아키텍처

    분산 파일 시스템을 기반으로 하며, 데이터 청크들을 신속하게 처리하기 위해 매루 큰 데이터 블록을 사용한다. 데이터 중복을 허용한다.

    HDFS, YARN은 하둡의 2개의 메인 빌딩 블록이다.

    하둡 클러스터

    분산 파일 시스템(HDFS)과 클러스터 리소스 매니저(YARN)를 기반으로 하는 하둡 소프트웨어를 사용하는 컴퓨터들의 집합체다.

    마스터 노드와 워커 노드

    마스터 노드: 클러스터의 작업을 중재한다. 클라이언트는 컴퓨팅을 하기 위해 마스터에 접속한다.

    워커 노드: 마스터 노드의 지시에 따라 명령을 수행한다. 실제로 데이터가 저장되고 프로세싱하는 노드다.

    하둡 서비스

    HDFS 서비스: HDFS 스토리지를 관리.

    • 네임노드: 마스터 노드에서 동작하면서 HDFS 파일 시스템 디렉토리 트리와 파일의 위치와 같은 HDFS 스토리지에 관련된 메타데이터를 유지시킨다.
    • 세컨더리 네임노드와 스탠바이 네임노드: 메타데이터 파일을 업데이트하는 태스크를 수행함으로써 네임노드의 부담을 줄인다.
    • 데이터노드: HDFS 데이터 블록들을 리눅스 파일 시스템에 저장하는 워커 노드에 실행되는 서비스다. 데이터 노드들은 네임노드와의 접속을 계속 유지하고 파일 시스템에서 일어나는 모든 변화를 네임노드에 업데이트한다.

    YARN 서비스: HDFS처럼 마스터 노드와 워커 노드 양쪽에서 모두 동작하는 몇몇 서비스들이 있다.

    • 리소스 매니저: 클러스터에 하나만 실행되는 서비스로, 마스터 노드 중 하나에서 실행된다. 클러스터의 리소스를 나눠주는 역할을 한다. 워커 노드에 태스크를 스케줄링하는 일도 담당한다.
    • 애플리케이션마스터: 마스터 서비스로, 클러스터에서 실행하는 애플리케이션마다 하나씩 실행된다. 애플리케이션 마스터는 클러스터에 있는 애플리케이션의 실행을 조율하고 애플리케이션을 위한 리소스들에 대해 리소스매니저와 협상하면서 리소스를 조절한다.
    • 노드 매니저: 모든 워커 노드에서 동작하는 서비스다. 노드매니저 서비스는 태스크를 워커 노드에서 실행하고 관리한다. 노드매니저는 리소스매니저와 긴말한 관계를 유지하고 노드 상태 및 자신들이 동작시키고 있는 태스크 상태를 업데이트한다.

    HDFS와 YARN 두 엔티티가 분산 컴퓨팅 태스크를 어떤 원리로 작동하는지 알아보자. 먼저 HDFS에 대한 논의다.

    데이터 스토리지 - 하둡 분산 파일 시스템

    커다란 규모의 데이터는 클러스터의 노드들에 걸쳐 퍼져있지만, 맵리듀스는 이 데이터들을 하나의 단일 파일로 본다.

    각각 노드들은 로컬 디스크(각각 노드들의 로컬 디스크)에서 모든 데이터를 읽어 처리한다. 이렇게 하면 네트워크로 전송할 필요가 없다.

    HDFS 특징들

    대규모 분산 프로세싱에 적합한 특징을 알아보자.

    • 대용량 데이터 세트 다루기
      • 일반적인 작은 데이터베이스는 수 테라바이트의 데이터를 수개의 파일로 처리한다.
      • 하둡은 페타바이트로 된 데이터를 다룰 수 있고, 파일 수천 개를 다룰 수도 있다.
    • 장애 허용
      • 서버들 사이의 병렬화가 가능하다. 각각의 블록이 기본적으로 3번 복제되어, 다른 노드에 저장된다.
    • 데이터 스트리밍
      • 배치 프로세싱을 위해 디자인됐고, 데이터 세트에 대해 스트리밍 접속이 가능하도록 만들어졌다. 
    • 단순 데이터 일관성 모델
      • 한 번 입력하고 여러 번 읽는 액세스 모델을 사용한다.
    • HDFS 아키텍처
      • 128MB 기본 블록 크기를 사용하는데, 거대한 양의 데이터를 갖고 작업하도록 디자인됐기 때문이다.
    • 마스터 노드와 데이터 노드
      • 마스터노드: HDFS 메타데이터를 관리하는 네임노드나 잡이나 태스크를 관리하는 리소스매니저 같은 하둡의 핵심 서비스가 실행된다.
      • 데이터노드(워커노드): 실제로 데이터 블록들을 저장한다. 워커 노드들은 노드매니저(YARN)을 실행한다.
        • 워커 노드들은 실제로 HDFS 파일 시스템에 클러스터 데이터를 저장한다.
    • 네임노드의 기능
      • 파일 시스템에 속하는 파일 계층 구조나 각 파일의 블록 위치 같은 메타데이터 유지
      • 데이터 파일에 대한 사용자 접속 관리
      • 블록 데이터를 클러스터의 데이터노드에 맵핑
      • 파일이나 디렉토리를 열고 닫기는 파일 시스템 오퍼레이션에서 수행
      • 데이터노드 클러스터에 대한 등록 서비스 및 데이터노드에 대한 주기적 하트 비트 처리
      • 어떤 노드들이 복제되고 복제된 후에 삭제될지 결정
      • 데이터노드에서 보낸 블록 리포트 처리 및 데이터 블록 위치 유지
      • 네임노드가 HDFS에 있는 파일에 대한 데이터 블록을 갖고 있는 데이터노드를 알고 있다고는 하지만, 블록의 정확한 위치를 갖고 있진 않다. 네임노드는 단지 클러스터가 시작할 때 데이터노드가 보내오는 데이터를 갖고 정보를 재구성한다. 네임노드는 이 정보를 메모리에 저장하여 빠르게 액세스할 수 있도록 한다.
    • 데이터노드의 기능
      • 로컬 파일 시스템에 블록을 저장하는 방식으로 블록 스토리지 서비스를 제공
      • 데이터노드에 있는 데이터에 대한 읽기/쓰기 기능 제공
      • 데이터 블록들 생성 및 삭제
      • 클러스터에 걸쳐 데이터 복제
      • 주기적인 하트비트 및 블록 정보 전송으로 네임노드와 정보를 유지.
      • 여기서 HDFS 데이터가 네임노드로 이동하진 않는다. 클라이언트는 항상 데이터노드들에 위치하는 파일 시스템에 접속한다. 네임노드는 클아이언트가 데이터노드에 쉽게 접속할 수 있도록 해준다. 클라이언트 애플리케이션은 데이터가 있는 노드에서 데이터를 처리하는 방식을 사용해 효율을 높이려고 한다.
    • HDFS 파일 시스템
      • 블록 기반 파일 시스템. 일반적으로 128MB.
        • 큰 크기의 블록은 파일 시스템의 메타데이터 크기가 작다.
        • 클 청크 데이터는 보통 순차적으로 읽혀지는데, 이런 특성은 스트리밍 방식으로 빠르게 데이터를 읽는 작업을 수월하게 한다.
    • 파일 시스템 구조
      • 트리 구조
      • WORM 액세스 모델을 사용하기 때문에 HDFS에 파일을 작성하면 내용을 수정할 수 없다. 기존에 존재하는 것과 동일한 이름은 사용할 수 없다. HDFS를 사용할 때 파일 자체는 변경하지 못하는 다음과 같은 오퍼레이션만 사용이 가능하다.
        • 파일 이동
        • 파일 삭제
        • 파일 이름 변경
    • HDFS의 데이터 형식
      • 텍스트 포맷보다 바이너리 포맷을 선호한다. 바이너리 포맷을 사용하면 파일에 데이터를 기록할 떄 불완전한 레코드가 생성되는 것을 막을 수 있다. 바이너리 포맷이 데이터의 중복이나 불완전 데이터 생성을 미리 감지하거나 무시해 버릴 수 있기 때문이다.
    • HDFS 파일에 작성하기
      • 클라이언트 애플리케이션이 HDFS에 데이터를 기록할 때는 클라이언트 로컬 파일에 임시로 먼저 기록한다.
      • 하둡은 클라이언트가 기록을 마치고 프로그램을 종료할 때나 임시 파일의 크기가 정해진 블록의 크기를 초과할 때 새로운 파일을 만들어 데이터 블록으로 새롭게 만들어진 파일을 할당한다.
      • 첫 번째 블록은 클러스터의 다른 데이터노드에 두 번 복사된다.(기본값은 세 벌의 복제).
      • 모든 데이터들이 다른 노드에 온전히 복사된 후에 쓰기 오퍼레이션이 완전히 완료된 것으로 본다.
    • 데이터 복제
      • HDFS는 자동으로 일정 수의 복사된 데이터 블록을 유지한다.
    • 네임노드 오퍼레이션
      • 네임노드가 fsimage 파일로 디스크에 저장하는 정보.
        • HDFS에 있는 모든 파일 이름
        • HDFS 디렉토리 구조
        • HDFS에 있는 모든 파일의 퍼미션 정보
      • 네임스페이스에는 계층 구조로 디렉토리와 파일이 저장된다. 각각의 네임스페이스는 모든 클러스터에 저장되는 유일한 ID가 된다. 네임스페이스 ID를 사용함으로써 데이터노드가 다른 클러스터에 잘못 연결되는 것을 방지한다.
      • HDFS에서 파일 생성이나 파일 삭제가 일어나면 메타데이터가 변경돼야 하고, 이것은 언제나 일어날 수 있다. 이 모든 것이 fsimage(파일 시스템 이미지)에 즉시 반영되진 않는다. 변경내용은 디스크의 다른 파일에 기록한다. 그리고 매 시간 보조 네임노드가 변경된 내용과 fsimage 파일 합치는 작업을 한다. 이렇게 만들어진 새로운 정보가 fsimage 파일로 기록된다.
      • 클라이언트는 네임노드에 접근하여 파일 블록 넘버나 데이터 위치 정보를 받는다.
      • 클라이언트의 애플리케이션이 HDFS 파일에 작업을 할 때, 네임노드는 램에 HDFS 메타데이터에 대한 내용을 업데이트한다. 그리고 edit 파일에 변화된 내용을 기록한다. 램 문제시 사용하기 위해서이다.
      • 세컨더리 네임노드가 주기적으로 fsimage 파일을 체크포인트하는 관리 업무를 담당한다.
    • 세컨터디 네임노드
      • 네임노드가 없으면 어떤 데이터노드에 어느 블록들이 파일로 저장돼 있는지 알 방법이 없다.
      • edit 파일이 크면 재시작이 시간이 오래 걸린다.
      • 위 문제를 피하기 위해 세컨터리 네임노드를 사용한다.
      • 세컨더리 네임노드를 주기적으로 edit 로그를 요청한다. 
    • HDFS의 HA와 스탠바이 네임노드
      • 네임노드 HA는 2개의 네임노드를 운영할 수 있기 때문에 가능하다.
    • 아파치 주키퍼
      • 하둡의 HDFS를 위해 분산 동기화와 그룹 서비스를 제공한다. 네임노드가 갖는 고가용성이라는 특징은 주키퍼 서비스에 의존한다. 
    • 불균형 데이터의 가능성
      • 하둡 밸런서: 데이터 균형 유지 툴

    하둡 운영 시스템인 얀을 사용한 데이터 프로세싱

    얀슨 프로세싱 레이어다. 얀은 네트워크 안에 있는 다수의 컴퓨터들을 실행하는 분산 애플리케이션을 관리하기 위한 관리 프레임워크다.

    얀은 하둡 클러스터에 있는 모든 리소스를 관리한다.

    얀은 하둡 프로세싱 레이어로 리소스매니저와 잡 스케줄러를 포함한다. 얀은 다수의 프로세싱 프레임워크를 동일한 하둡 클러스터에서 동작할 수 있게 한다.

    얀의 아키텍처

    얀은 리소스 매니저에 의존한다.

    리소스매니저는 하둡 클러스터에서 동작하는 모든 애플리케이션 사이에서 중재자 역할을 한다. 그리고 클러스터에 있는 모든 워커노드(데이터 노드)를 관리하는 노드매니저와도 협력한다.

    리소스 매니저와 노드별 노드매니저들이 데이터 프로세싱 프로엠워크를 형성한다.

     

    얀 위에서 동작하는 각각의 애플리케이션은 애플리케이션마스터를 가진다.

    애플리케이션마스터는 리소스에 대해 리소스매니저와 협상하고 각 애플리케이션의 태스크를 실행하기 위한 노드매니저들와 연동한다.

    얀과 관련된 용어 정리

    • 클라이언트: 클러스터에서 얀으로 실행할 잡을 서밋하는 프로그램.
    • 잡: 하나 이상의 태스크를 포함하는 애플리케이션을 의미.

    얀 클라이언트는 앱을 만들어 실행.

    리소스 매니저는 스케줄링과 리소스 관리를 담당.

    노드매니저 데몬은 각 데이터노드에서 동작하면서 컨테이너를 실행해 관리.

    각 잡을 관리하기 위해 각 잡별로 애플리케이션 매니저가 존재.

    리소스 매니저가 애플리케이션 마스터를 만든다.

    얀 컨테이너 - 얀이 리소스들을 할당하는 방법

    얀은 컨테이너를 사용해 애플리케이션을 실행 컨테이너는 메모리, CPU와 같은 리소스의 양을 구체적으로 표현하는 논리적 구조다.

     

    하둡은 기본값으로 컨테이너별 8기가 램을 사용할 수 있도록 하는 기본 설정값을 갖고 있다.

    리소스매니저는 컨테이너를 각 애플리케이션에 할당한다. 노드매니저는 컨테이너의 파이프사이클을 관리하고, 리소스 매니저는 컨테이너를 스케줄링한다.

    태스크의 수, 한 번에 실행도리 수 있는 얀 애플리케이션의 수는 클러스터가 생성할 수 있는 컨테이너들의 수에 의해 한계가 정해진다.

    리소스매니저

    클러스터마다 하나만 존재한다.

    • 모든 얀 애플리케이션의 시작을 위한 처리
    • 잡 스케줄링과 실행 관리
    • 모든 데이터노드의 리소스 할당

    리소스매니저는 스케줄러와 애플리케이션매니저라는 2개의 핵심 컴포넌트를 가진다.

    스케줄러는 시스템의 리소스 한계와 큐의 크기에 따라 실행 중인 애플리케이션에 리소스를 할당한다.

    애플리케이션 매니저는 클라이언트가 요청한 잡 리퀘스트를 받아들이고 새로운 애플리케이션 마스터를 실행하기 위해 첫 번째 컨테이너를 실행한다.

    리소스 매니저의 주요 기능

    • 애플리케이션을 위한 첫 번째 컨테이너를 만든다. 이 컨테이너에서 애플리케이션마스터가 실행된다.
    • 데이터노드를 관리하기 위해 노드매니저의 하트 비트를 관리한다.
    • 클러스터 사이에 리소스 할당을 결정하기 위해 스켈루러를 실행한다.
    • 클러스터 레벨 보안을 관리한다.
    • 애플리케이션에서 온 리소스를 요청 처리한다.
    • 애플리케이션마스터의 상태를 관찰하고, 실패할 경우 컨테이너를 재시작한다.
    • 애플리케이션이 완료되거나 소멸된 후, 컨테이너 할당을 해제한다.

    리소스매니저의 스케줄러 요소의 일부분인 스케줄링 알고리즘은 다음과 같은 기능을 수행한다.

    • 미리 설정된 스케줄링 정책에 따라 예측 가능한 방법으로 사용자들이 클러스터를 공유할 수 있도록 한다.
    • 사용자가 책임지는 다수의 SLA의 구현을 지원한다.
    • 규모가 크고, 리소스 집약적이며 장기간 실행되는 잡들이 실행되고 있어도 작은 규모이고 작업이 빨리 끝나는 잡이 실행되도록 한다.
    • 크기가 다른 잡들을 함께 실행할 때 잡 지연 시간을 줄인다.

    노드매니저

    데이터노드는 얀 기능들을 수행하기 위해 노드매니저를 실행한다.

    • 하트비트와 컨테이너 상태 알임을 통해 리소스매니저와 정보를 주고받는다.
    • 애플리케이션 프로세스를 등록하고 시작한다.
    • 애플리케이션마스터를 시작하고, 애플리케이션 매니저의 응답에 따라 애플리케이션 리소스 컨테이너의 나머지(맵, 리소스 태스크)도 시작한다.
    • 애플리케이션 컨테이너의 라이프 사이클을 관리한다.
    • 컨테이너의 리소스 사용량과 관련된 정보를 관찰, 관리, 제공한다.
    • 데이터노드의 상태 추적
    • 컨테이너 리소스의 사용량 모니터링 및 불필요한 프로세스 제거
    • 잡의 로그들을 수집하고 통합해 HDFS에 저장하는 등의 로그 관리
    • 얀 애플리케이션을 위한 보조 서비스를 제공한다.
    • 노드 레벨 보안 유지

    애플리케이션마스터

    각각의 얀 애플리케이션에는 하나의 전용 애플리케이션마스터가 있다.

    • 태스크 스케줄링과 실행 관리
    • 애플리케이션 태스크를 위해 로컬 리소스 할당

    애플리케이션마스터는 실행중인 애플리케이션과만 관련돼 있다.

    리소스매니저는 클러스터의 한 노드에 애플리케이션마스터를 실행하는 컨테이너를 할당한다.

    리소스를 할당하기 위해 애플리케이션마스터가 리소스매니저와 협력하는 방법

    모든 얀 프로세스들 처럼 애플리케이션마스터는 얀 컨테이너 내에서 동작한다.

    프로세싱을 위한 컨테이너에 대해 리소스매니저와 협상한다.

    그 후, 각각의 데이터 노드에서 실행 중인 노드매니저들에게 컨테이너를 제공한다. 리소스매니저는 컨테이너를 위해 데이터노드 리소스를 할당한다.

    애플리케이션마스터는 리소스 컨테이너를 실행하고, 할당된 리소스를 어떻게 사용하는지 모니터링하기 위해 각 데이터노드에서 실행중인 노드매니저에 연결한다.

    애플리케이션마스터의 주요 임무는 리소스의 내고장성/내결함성을 제공하는 것이다.

    리소스매니저에게 리소스 요청 시, 다음과 같은 것들을 매우 구체적으로 요청한다.

    • 잡을 처리하는데 필요한 파일 블록들
    • 애플리케이션을 위해 만들어야 하는 컨테이너 수
    • 컨테이너 크기
    • 리소스가 할당된 위치. 이 정보들은 네임노드를 통해 할당받는다. 또 데이터 블록이 저장되는 위치도 요청한다.
    • 리소스 요청 우선순위

    잡히스토리서버

    전체 클러스터에 잡히스토리서버는 하나만 존대 얀 잡의 평가, 지표들과 메타데이터를 보관.

     

     

     

     

    댓글

Designed by Tistory.