류프리

리소스 매니저(Resource Manager)의 구성 요소

리소스 매니저는 다음의 구성요소를 가집니다.

① 리소스 매니저와 클라이언트간의 통신하는 구성요소들

ClientServie

리소스 매니저의 클라이언트 인터페이스입니다. 이 컴포넌트는 애플리케이션 제출, 애플리케이션 종료, 큐 정보 획득, 클러스터 상태 등과 같은 작업을 포함하여 클라이언트에서 리소스 매니저로 오는 모든 RPC 인터페이스를 관리합니다.

AdminService

관리자의 요청(Admin request)이 일반 사용자의 요청 때문에 실행되지 못하는 경우가 없도록 작업 명령에 더 높은 우선 순위(Higher priority)를 부여합니다. 노드-목록(node-list)을 새로 고치거나, 큐의 설정(Queues’ onfiguration) 등과 같은 관리자 작업(Admin Operation)은 별도의 인터페이스를 통하여 제공합니다.

② 리소스 매니저와 노드들을 연결하는 컴포넌트들

ResourceTrakerService

이 컴포넌트는 모든 노드에서 오는 RPC에 응답을 합니다. 새로운 노드를 등록하거나, 유효하지 않거나 사용이 중지된 노드로부터의 연결을 거부하거나, 노드의 하트비트(Heartbeat) 획득해서 얀 스케쥴러(YarnSheduler)에게 전달합니다. 리소스 트랙커 서비스(ResoureTrakerServie)는 NMLivelinessMonitor 와 NodesListManager와 긴말하게 협력합니다.

NMLivelinessMonitor

정상적으로 동작하는 노드들을 추적하고, 특히, 죽은 노드를 내리기 위해서 이 구성요소는 각 노드의 마지막 하트비트(Heartbeat) 시간을 추적합니다. 노드들이 설정된 간격(기본 10분) 안에 하트비트를 보내지 않으면 죽은것으로 간주하고, 리소스 매니저가 죽은 노드의 사용을 만료시킵니다. 만료된 노드에서 현재 수행중인 모든 컨테이너는 죽은것으로 표시되며, 그 노드에게는 새로운 컨테이너를 배정하지 않습니다.

NodesListManager

유효하거나 제외된 노드들의 집합입니다. yarn.resourcemanager.nodes.inlude-path와 yarn.resouremanager.nodes.exclude-path를 통해 지정된 호스트 설정 파일을 읽고, 그 파일를 기반으로 노드의 초기 목록을 생성을 담당합니다. 또한 시간이 진행됨에 따라 폐기하는 노드를 추적합니다.

③ 응용 프로그램별 ApplicationMasters와 통신하는 구성요소

AppliationMasterServie

모든 ApplicationMasters와의 RPC에 응답하는 구성 요소입니다. 그것은 새로운 ApplicationMasters의 등록과 종료되는ApplicationMasters에서의 종료/해제 요청, 동작중인 모든 ApplicationMasters에서의 컨테이너 할당/해제 요청을 받아 YarnSheduler로 전송하는 역할을 담당합니다. 이 요소는 아래에 설명된 AMLivelinessMonitor와 밀접하게 연관되어 있습니다.

AMLivelinessMonitor

살아 있는 ApplicationMasters의 리스트와 정지/응답하지 않는 ApplicationMasters의 리스트에 대한 관리를 돕기 위해서, 이 구성 요소는 각 ApplicationMasters의 추적과 마지막 하트비트(Heartbeat) 시간을 유지합니다. 미리 정의된 간격(기본 10분) 내에 하트비트를 보내지 않는 ApplicationMasters는 정지한 것으로 여기고, ResourceManager에 의해서 만료됩니다. 만료된 ApplicationMasters에서 현재 동작하거나/할당된 모든 컨테이너는 죽은(dead) 것으로 표시됩니다. ResoureManager은 동일한 ApplicationMasters을 새로운 컨테이너에 동작시키기 위해서 스케쥴합니다. 이러한 동작은 최대 4번 시도될 수 있습니다.

④ ResoureManager의 핵심 – 스케쥴러와 관련된 구성 요소들

ApplicationsManager

제출된 응용프로그램의 컬렉션(Colletion, 집합)을 유지 관리할 책임이 있습니다. 또한 웹 UI나 응용 프로그램의 명령행을 통해서 사용자가 요청할 수 있도록 응용 프로그램의 캐시를 유지합니다.

ApplicationACLsManager

사용자가 클라이언트(Client) APIs와 관리 요청(Admin requests) APIs를 사용하려면 권한이 부여된 사용자만 접근할 수 있는 문(Gate)이 필요합니다. 이 구성요소는 응용 프로그램 당 ACL(Access-Control-List)의 목록을 유지하고, 응용 프로그램의 상태를 보거나 응용 프로그램을 중단과 같은 요청을 받을 때마다 권한을 적용합니다.  

ApplicationMasterLauncher

몇가지 이유로 인하여 종료된 이전 Application Master의 시도들과 새로 제출된 응용 프로그램의Application Master를 개시하기 위한 스레드 풀(Thread-pool)를 관리합니다. 또한 응용 프로그램이 정상적으로 또는 강제적으로 종료되었을 경우에 Application Master를 마무리 할 책임이 있습니다.

YarnScheduler

스케쥴러는 용량(Capacity), 큐(Queue) 등의 제약사항에 따라서 다양하게 실행되는 응용 프로그램에게 자원(Resource)을 할당하는 책임이 있습니다. 또한 메모리, CPU, 디스크, 네트워크 등과 같은 응용 프로그램의 자원 요구 사항을 기반으로 스케쥴링 기능을 수행합니다. 스케쥴러 기능은 현재 메모리만 제공하고 있으며, CPU에 대한 지원도 곧 완료될 예정입니다.

ContainerAllocationExpirer

이 구성요소는 모든 할당된 컨테이너들이 Application Master들을 통해서 사용되고 있으며, 이후에 컨테이너가 해당되는 노드 매니저에서 실행되고 있는지 보장할 책임이 있습니다. Application Master들은 신뢰할 수 없는 사용자 코드를 실행하고, 잠재적으로 그들을 사용하지 않고 할당을 유지할 수 있으며, 이로 인하여 클러스터를 충분히 활용하지 못하는 원인이 될수 있습니다.

이러한 문제를 해결하기 위해서, ontainerAllocationExpirer는 해당하는 노드 매너저에서 사용되지 않는 할당된 컨테이너들의 목록을 유지합니다. 어떠한 컨테이너이든 해당하는 노드 매니저가 정해진 시간(기본 10분) 안에 Resource Manager에게 컨테이너의 동작 상태를 보고하지 않으면 컨테이너가 정지했다고 간주하고 Resource Manager에 의해서 만료됩니다.

⑤ TokenSecretManagers (for security)

리소스 매니저는 토큰(Token)을 관리하고, 다양한 RPC 인터페이스에 대한 요청을 인증/권한부여 하는데 사용되는 비밀키(Secret-key)들을 청구하는 SecretManager의 콜렉션을 가지고 있습니다. 얀 보안에 대한 미래의 글에는 토큰, 비밀키, Secret-Manager들에 대한 상세한 설명을 포함할 것이며, 지금은 아래에 간략하게 요약만 합니다.

ApplicationTokenSeretManager

리소스 매니저 스케쥴링 요청을 보내는 임의의 프로세스를 피하기 위해서, 리소스 매니저는 애플리케이션 토큰(ApplicationTokens)을 사용합니다. 이 구성요소는 응용 프로그램이 종료될 때까지 메모리에 지역적으로 토큰을 저장하고, 유효한 Application Master 처리에서 발생하는 요청들을 인증하는데 사용됩니다.

ContainerTokenSecretManager

컨테이너 토큰(ContainerToken)은 리소스 매니저가 특정 노드에 존재하는 컨테이너를 관리하고 있는 Application Master에게 발급한 특별한 토큰입니다. ContainerTokenSecretManager는 ContainerToken을 위한 SecretManager입니다.

ContainerToken은 컨테이너가 할당된 해당 노드 매니저와의 연결을 생성하는 Application Master에 의해서 사용됩니다. 이 구성요소는 리소스 매니저 특정이고, 기본 마스터와 비밀키를 추적하고 가끔 키들을 롤백(Roll)합니다.

RMDelegationTokenSecretManager

ResourcManager specific delegation-token secret-manager. 이 구성요소는 리소스 매니저와 인증되지 않은 프로세스로 작업하길 원하는 클라이언트에게 위임 토큰(Delegation token)을 생성할 책임이 있습니다.

⑥ DelegationTokenRenewer

보안 모드에서 리소스 매니저는 Kerberos 인증이며, 응용 프로그램을 대신하여 파일 시스템 토큰을 갱신하는 서비스를 제공합니다. 이 구성요소는 응용 프로그램이 실행되는 동안 그리고 토큰이 더 이상 갱신할 수 없을때까지 제출된 응용프로그램의 토큰을 갱신합니다.

결론

얀에서 리소스 매니저는 주로 스케쥴링 작업에 국한됩니다. 예를 들면 단지 경쟁 응용 프로그램들 간의 시스템에서 사용 가능한 자원을 중재하고 응용프로그램들의 상태 관리는 관심을 가지지 않습니다. 이 때문에 위에서 설명한 모듈 방식과 더불어 분명한 책임의 분리 그리고 이전 포스트에서 설명한 강력한 스케쥴러 API로 인하여, 리소스 매니저는 확장성과 다른 프로그래밍 패러다임에 대한 지원등 가장 중요한 설계 요구 사항을 충족할 수 있습니다. 서로 다른 정책 제한을 허용하기 위해서 리소스 매니저는 플러거블(Pluggable)하고 다른 알고리즘 사용을 허가합니다.

[ 리소스 매니저 ]

노드 매니저(Node Manager)의 구성 요소

노드 매너저는 노드(Node) 마다 설치되는 에이전트이며, 하둡 클러스터에 있는 각 연산 노드를 처리합니다. 여기에는 리소스 매니저와의 동기화, 컨테이너의 생명주기 관리를 감독하고, 각 컨테이너의 리소스(메모리, CPU) 사용을 모니터링하며, 노드의 건강, 로그의 관리, 다른 얀 응용 프로그램에 의해 악용될 수 있는 보조 서비스들을 감시합니다.

NodeStatusUpdater

시작 시점에 이 구성요소는 리소스 매니저에 등록을 수행하고, 노드에서 사용할 수 있는 자원에 대한 정보를 전송합니다. 그 후에 노드 마스터와 리소스 매니저간의 통신은 컨테이너의 상태에 대한 업데이트를 제공합니다. (노드에서 동작중인 새 컨테이너의 상태, 완료된 컨테이너, 기타). 또한 리소스 매니저는 이미 실행중인 컨테이너를 잠재적으로 종료하기 위해서 NodeStatusUpdater에게 신호를 줄 수 있다.

ContainerManager

ContainerManager는 노드 매니저의 핵심입니다. 노드에서 실행되는 컨테이너를 관리하는데 필요한 기능의 일부를 수행하는 하위 구성 요소로 구성됩니다.

ⓐ RPC server

컨테이너 매니저(ContainerManager)는 애플리케이션 마스터(Application Master)로부터 새로운 컨테이너를 시작하거나 실행중인 컨테이너를 정지하도록 요청을 받습니다. 컨테이너 매니저(ContainerManager)는 아래에서 설명할 ‘ContainerTokenSecretManager’와 작업하여 모든 요청을 인증합니다. 이 노드에서 실행중인 컨테이너에서 수행되는 모든 작업은 보안 툴에 의해서 후 처리될수 있도록 감사 로그(audit-log)에 기록됩니다.

ⓑ ResourceLoalizationService

컨테어너가 필요한 다양한 파일 리소스를 안전하게 다운로드하고 관리합니다. 이 구성 요소는 가능한 모든 디스크에 파일을 분산하도록 노력합니다. 또한 다운로드 받은 파일들의 접근권한과 적절한 사용량을 제한합니다.

ⓒ ContainersLauncher

컨테이너를 가능한 빠르게 준비하고 시작하기 위해서 스레드 풀을 유지합니다. 또한 리소스 매니저나 애플리케이션 마스터에서 보내진 요청이 있다면 컨테이너의 프로세스들을 정리합니다.

ⓓ AuxServices

노드 매니저는 보조 서비스를 구성하여 노드 매니저의 기능을 확장하기 위한 프레임 워크를 제공합니다. 이 기능은 특정한 프레임 워크들이 필요로 하는 노드 별 커스텀 서비스 사용을 허가하면서 여전히 노드 매니저의 다른 부분으로부터 분리합니다. 이 서비스는 노드 매니저가 시작하기 전에 설정되어야 합니다. 보조 서비스들은 노드에서 응용 프로그램의 첫번째 컨테이너가 시작될때와 응용 프로그램이 완료된 것으로 간주될 때 통지 됩니다.

ⓔ ContainersMonitor

컨테이너가 시작되면 이 구성 요소가 컨테이너가 실행되는 동안의 자원 활용에 대한 관찰를 시작합니다. 메모리 같은 자원의 공정한 공유와 격리를 강화하기 위해서, 각 컨테이너는 리소스 매니저에게 이러한 자원의 일부를 할당 받습니다. ContainersMonitor는 각 연속적인 컨테이너의 사용을 모니터링하고, 컨테이너가 할당을 초과할 경우, 컨테이너를 종료시키기 위해 신호를 보냅니다. 이것은 동일한 노드에서 실행중인 정상 컨테이너들에게 영향을 미치는 모든 폭주 컨테이너를 방지하기 위한 것입니다.

ⓕ LogHandler

컨테이너의 로그들을 로컬 디스크에 유지하거나 압축하여 파일 시스템에 업로드할 수 있도록 설정할 수 있는 탈착 가능한 구성 요소입니다.

ContainerExeutor

컨테이너가 필요로 하는 파일 및 디렉토리를 안전하게 배치시키기 위해서 그리고 안전한 방법으로 컨테이너에 상응하는 프로세스들을 시작하거나 정리하기 위해서 기본 운영 체제와 상호 작용합니다.

NodeHealthCheckerService

이 구성 요소는 자주 구성된 스크립트를 주기적으로 실행하여 노드의 상태를 검사하는 기능을 제공합니다. 또한 디스크에 가끔 임시 파일을 생성하여 디스크의 상태를 모니터링합니다. 시스템의 모든 상태 변화를 차례로 리소스 매니저로 전송하는 NodeStatusUpdater로 통보 됩니다.

Security

ⓐ ApplicationACLsManager

노드 매니저는 권한이 부여된 사용자만 접근할 수 있도록 웹UI에 컨테이너 로그 표시와 같은 API를 직접 대면하는 사용자가 필요합니다. 이 구성 요소는 응용 프로그램 당 ACL 목록을 유지하고 요청을 수신 할 때마다 이를 적용합니다.

ⓑ ContainerTokenSeretManager

모든 수신 작업이 제대로 리소스 매니저에 의해서 승인되는 것을 보장하기 위해서 다양한 도착 요청을 확입합니다.

WebServer

응용 프로그램 주어진 시점에서 실행중인 컨테이너들과 노드 건강 정보 및 컨테이너에 의해서 생성된 로그들의 목록을 보여준다.

[ 노드 매니저 ]

아파치 하둡 얀은 리소스 관리와 컴포넌트 처리를 분리한 하둡 2.0에 도입된 아파치 소프트웨어 재단의 서브 프로젝트입니다. 얀은 맵-리듀스의 차세대 기술로서 맵-리듀스의 확장성과 속도문제를 해소하기 위해 새로 개발된 프로젝트입니다. 얀 이전의 맵-리듀스에서는 4000노드 이상의 클러스터에서 시스템 확장에 문제가 발생하여 야후(Yahoo)에서 새로 설계하였습니다.

가장 큰 변화로는 얀 자체로 맵-리듀스를 구동할 수 있으며, 추가로 다른 분산 처리 프레임워크(Tez, HBase, Giraph, Spark 등)를 사용자의 인터페이스 개발만으로 구동이 가능하게 되었습니다.

[ 하둡 2.0 스택 ]

얀(YARN)은 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)의 상단에서 빅 데이터용 애플리케이션들을 실행하는 대용량 분산 운영체제 역할을 수행합니다. 얀(YARN)을 이용하면 안정적인 기반에서 배치 작업과 양방향 실시간 작업을 수행할 수 있습니다. 아파치 재단은 얀(YARN)을 ‘맵-리듀스 버전 2(MRv2)’로 명명했습니다.

YARN의 구조

얀(YARN)은 크게 리소스 매니저(Resource Manager), 노드 매니저(Node Manager), 애플리케이션 마스터(Application Master), 컨테이너(Container)로 구성되어 있습니다.

① 리소스 매니저(Resource Manager)

클러스터 전체를 관리하는 마스터 서버의 역할을 담당하며, 응용 프로그램의 요청을 처리합니다. 리소스 매니저는 클러스터에서 발생한 작업을 관리하는 애플리케이션 매니저(Applications Manager)를 내장하고 있으며, 응용 프로그램들 간의 자원(resource) 사용에 대한 경쟁을 조율합니다. 여기서 말하는 자원이란 CPU, 디스크(disk), 메모리(memory)등을 의미합니다.

② 노드 매니저(Node Manager)

노드당 하나씩 존재하며, 슬레이브 노드(slave node)의 자원을 모니터링(monitoring) 하고 관리하는 역할을 수행합니다. 노드 매니저는 리소스 매니저의 지시를 받아 작업 요구사항에 따라서 컨테이너를 생성합니다.

③ 애플리케이션 마스터(Application Master)

노드 매니저와 함께 번들로 제공되며, 작업당 하나씩 생성이 되며, 컨테이너를 사용하여 작업 모니터링과 실행을 관리합니다. 또한, 리소스 매니저와 작업에 대한 자원 요구사항을 협상하고, 작업을 완료하기 위한 책임을 가집니다.

④ 컨테이너(Container)

CPU, 디스크(Disk), 메모리(Memory) 등과 같은 속성으로 정의됩니다. 이 속성은 그래프 처리(Graph processing)와 MPI와 같은 여러 응용 프로그램을 지원하는데 도움이 됩니다. 모든 작업(job)은 결국 여러 개의 작업(task)으로 세분화되며, 각 작업(task)은 하나의 컨테이너 안에서 실행이 됩니다. 필요한 자원의 요청은 애플리케이션 마스터(Application Master)가 담당하며, 승인 여부는 리소스 매니저(Resource Manager)가 담당합니다. 컨테이너 안에서 실행할 수 있는 프로그램은 자바 프로그램뿐만 아니라, 커맨드 라인에서 실행할 수 있는 프로그램이면 모두 가능합니다.

[ YARN의 전체 구성도 ]

리소스 매니저(Resource Manager)의 구조

리소스 매니저는 클러스터마다 존재하며, 클러스터 전반의 자원 관리와 작업(task)들의 스케쥴링을 담당합니다. 리소스 매니저는 클라이언트로부터 애플리케이션 실행 요청을 받으면 그 애플리케이션의 실행을 책임질 애플리케이션 마스터(Application Master)를 실행합니다. 또한 클러스터 내에 설치된 모든 노드 매니저(Node Manager)와 통신을 통해서 각 서버마다 할당된 자원과 사용중인 자원의 상황을 알 수 있으며, 애플리케이션 마스터들과의 통신을 통해 필요한 자원이 무엇인지 알아내어 관리하게 됩니다.

리소스 매니저(Resource Manager) 내부에는 여러 개의 컴포넌트들이 존재하며, 스케쥴러(Scheduler), 애플리케이션 매니저(Application Manager), 리소스 트랙커(Resource Tracker) 세개의 메인 컴포넌트가 있습니다.

① 스케쥴러(Scheduler)

노드 매니저(Node Manager)들의 자원 상태를 관리하며 부족한 리소스들을 배정합니다. 스케쥴러는 프로그램의 상태를 검사하거나 모니터링 하지 않으며, 순수하게 스케쥴링 작업만 담당합니다. 스케쥴링이란 자원 상태에 따라서 작업(task)들의 실행 여부를 허가해 주는 역할만 담당하며, 그 이상의 책임은 지지 않습니다. 즉, 프로그램 오류나 하드웨어의 오류로 문제가 발생한 프로그램을 재 시작시켜주지 않으며, 프로그램에서 요구하는 리소스(CPU, Disk, 네트워크등)에 관련된 기능만 처리합니다.

② 애플리케이션 매니저(Application Manager)

노드 매니저(Node Manager) 에서 특정 작업을 위해서 애플리케이션 마스터(Application Master)를 실행하고, 애플리케이션 마스터(Application Master)의 상태를 관리합니다. 여기서 애플리케이션 마스터(Application Master)라는 용어가 나오는데 얀에서 실행되는 하나의 작업(task)을 관리하는 마스터 서버를 말합니다.

③ 리소스 트랙커(Resource Tracker)

컨테이너(Container)가 아직 살아 있는지 확인하기 위해서, 애플리케이션 마스터(Applications Master) 재 시도 최대 횟수, 그리고 노드 매니저(Node Manager)가 죽은 것으로 간주 될 때까지 얼마나 기다려야 하는지 등과 같은 설정 정보를 가지고 있습니다.

[ 리소스 매니저: 서브 컴포넌트 ]

노드 매니저(Node Manager)의 구조

노드 매니저는 노드(컴퓨터) 당 한 개씩 존재합니다. 해당 컨테이너(Application Container)의 리소스 사용량을 모니터링 하고, 관련 정보를 리소스 매니저에게 알리는 역할을 담당합니다. 애플리케이션 마스터(Application Master)와 애플리케이션 컨테이너(Application Container)로 구성되어 있습니다.

① 애플리케이션 마스터(Application Master)

하나의 프로그램에 대한 마스터 역할을 수행하며, 스케쥴러로부터 적절한 애플리케이션 컨테이너(Application Container)를 할당 받고, 프로그램 실행 상태를 모니터링하고 관리합니다.

② 애플리케이션 컨테이너(Application Container)

프로그램에 할당된 자원을 나타냅니다.

얀의 작업 순서

다음 그림은 얀 클러스터(YARN Cluster)에서 응용 프로그램이 실행되는 과정을 보여줍니다.

①  클라이언트(Client)가 새 응용 프로그램을 요청하기 위해서 리소스 매니저(Resource Manager)와 통신을 합니다. (리소스 매니저(Resource Manager)의 애플리케이션 매니저(Application Manager) 담당)

②  리소스 매니저(Resource Manager)는 애플리케이션 아이디(Application Id)를 클라이언트(Client)에게 보냅니다.

③  클라이언트(Client)는 메모리(Memory), CPU, 우선 순위(Priority) 등과 같은 세부 요구 사항을 요청하는 Application Submission Request 생성합니다.

④  애플리케이션 매니저(Application Manager)는 클라이언트(Client)로부터 요청을 받으면, 노드 매니저(Node Manager)에게 작업(Job) 당 하나의 애플리케이셔 마스터(Application Master)를 생성하도록 요청합니다.

⑤  노드 매니저(Node Manager)는 애플리케이션 마스터(Application Master)를 생성합니다.

⑥  애플리케이션 마스터(Application Master)는 리소스 매니저(Resource Manager)에게 리소스 할당에 대한 요청을 생성합니다. 애플리케이션 마스터는 작업(Job)이 종료될 때까지 작업에 대한 책임을 집니다.

⑦  리소스 매니저(Resource Manager)는 컨테이너(Container)의 리스트를 반환합니다.

⑧  애플리케이션 마스터(Application Master)는 노드 매니저(Node Manager)에게 특정 작업에 대한 컨테이너(Container)의 시작을 요청합니다.

⑨  노드 매니저(Node Manager)는 컨테이너(Container)를 생성합니다. 컨테이너는 클라이언트의 특정 코드를 실행합니다.

⑩  애플리케이션 매니저(Application Manager)는 작업(Job)이 완료될때까지 작업 실행을 관리합니다.

⑪  클라이언트(Client)는 응용 프로그램의 상태 보고서를 요청합니다.

[ 얀의 작업 순서 ]

맵-리듀스(Map-Reduce)는 구글이 분산 컴퓨팅을 지원하기 위한 목적으로 제작하여, 2004년 발표한 소프트웨어 프레임워크입니다. 이 프레임워크는 대용량 데이터를 신뢰할 수 없는 컴퓨터로 구성된 분산 클러스터 환경에서 대규모 데이터를 병렬로 처리하기 위해 개발되었습니다.

맵-리듀스의 혁신적인 부분은 데이터 집합에 대한 쿼리를 입력 받아, 분할 한 후, 여러개의 노드에서 병렬로 처리하는데 있습니다. 이러한 분산 처리는 단일 장비에서 처리하기에는 부적합한 대규모 데이터 처리 문제를 해결합니다.

[ 분산 환경에서의 Map-Reduce 실행 ]

위의 그림은 네임노드(NameNode)의 잡트랙커(JobTracker)가 데이터노드(DataNode)의 테스크트랙커(TaskTracker)에게 일을 분배해 주는 개념도입니다. 데이터노드는 컴퓨터 한대라고 생각하시면 되며, 맵-리듀스 함수들은 컴퓨터 마다 상주하여 병렬로 작업을 수행함으로써 대규모 데이터를 짧은 시간안에 처리할 수 있습니다.

맵-리듀스(Map-Reduce)의 개념

맵-리듀스는 맵 단계와 리듀스 단계로 처리 과정을 나누어 작업합니다. 맵(map)은 흩어져 있는 데이터를 관련 있는 데이터끼리 묶는 작업을 통해서 임시 데이터 집합으로 변형되며, 리듀스(Reduce)는 맵 작업에서 생성된 임시 데이터 집합에서 중복 데이터를 제거하고 원하는 데이터를 추출하는 작업을 진행합니다.

[ Map-Reduce 작업 ]

맵-리듀스 처리 순서

맵리듀스가 분산, 병렬 처리하기 좋은 이유는 입력 데이터에 대한 맵 함수는 동시에 독립적으로 병렬 처리할 수 있는 구조이기 때문입니다. 아래 그림을 통해서 맵-리듀스에서 파일안에 있는 단어들의 합을 구하는 단순한 작업에 대해서 간략하게 알아보겠습니다.

[ 맵-리듀스 처리 방법 ]

처음 작업은 입력 데이터를 라인 단위로 분할(Splitting) 합니다. 분할된 라인 단위의 문장을 맵(map) 함수로 전달하면, 맵 함수는 공백을 기준으로 문자를 분리 한 후에 단어의 개수를 계산합니다. 메모리에 저장되어 있는 맵 함수의 출력 데이터를 파티셔닝과 정렬을 해서 로컬 디스크에 저장한 후에 네트워크를 통해서 리듀서에게 전달하는 셔플링(Shuffling) 작업을 진행합니다. 리듀스(reduce) 함수는 단어 목록들을 반복 수행하면서 합을 계산하여 클라이언트에게 결과 파일을 제공합니다.

Data Processing: Map

파일을 작은 블록으로 나눈 후에 클러스터를 통해서 확산을 시키면 매우 빠르고 효율적인 병렬처리를 제공할 수 있습니다. 하둡에서 핵심 서비스에 해당하는 병렬 처리 프레임워크(Parallel Processing Framework)는 맵-리듀스(Map-Reduce)에서 담당을 합니다. 맵-리듀스의 이름도 맵 작업과 리듀스 작업의 이름을 따서 만들어졌습니다.

첫번째 순서인 맵 처리(Map Process)는 로컬 블록의 데이터에서 계산을 수행하기 위해서 동시에 데이터 노드에게 작업을 요청합니다. 여기서는 File.txt 안에 존재하는 ‘Refund’ 단어의 출현 빈도수를 계산하기 위해서 데이터 노드에게 요청을 합니다. 이 작업을 시작하기 위해서 먼저 클라이언트(Client)는 “File.txt 안에 ‘Refund’ 단어가 몇번 나오는지” 에 대한  맵-리듀스 작업을 잡 트랙커(Job Tracker)에게 요청합니다.

잡 트랙커(Job Tracker)는 File.txt의 해당 블록을 가진 데이터 노드(Data Node)들의 위치를 알기 위해서 네임 노드(Name Node)에게 물어봅니다. 잡 트랙커는 File.txt와 연관된 데이터 노드들에게 ‘Refund’의 출현 빈도수를 알아내기 위해서 데이터 노드(Data Node)에서 동작중인 태스크 트랙커 (Task Tracker)에게 작업을 지시합니다.

태스크 트랙커(Task Tracker)는 ‘Refund’의 출현 빈도수를 알아내기 위해서 맵 작업을 시작하고, 작업의 진행 상황을 모니터링합니다. 또한 태스크 트랙커는 ‘heartbeats’와 작업의 상태를 잡 트랙커에게 제공합니다. 맵 작업이 완료가 되면 각 노드들은 임시 로컬 저장소(Temporary local storage)에 계산 결과를 저장하며, 저장되는 데이터를 중간 데이터(Intermediate data) 라고 부릅니다.

다음 단계는 데이터 노드에서 생성된 중간 데이터 파일들을 네트워크를 통하여 리듀스 작업(Reduce task)을 하기 위해서 작업을 담당하는 데이터 노드에게 중간 데이터 파일들을 전송합니다.

[ Map Task ]

What if data isn’t local?

잡 트랙커는 항상 맵 작업을 위해서 데이터 노드들을 선택하여 작업을 해야 하지만, 그렇지 못한 경우가 발생을 합니다. 그 이유중 하나로는 데이터 노드들이 로컬 데이터를 사용하여 이미 다른 작업을 진행중이어서 더 이상 작업을 진행할 수 없는 경우입니다. 이러한 경우가 발생을 하면 잡 트랙커는 동일한 랙(rack)에 있는 다른 데이터 노드을 선택하기 위해서 네임 노드에 있는 랙 인식(rack awareness) 정보를 참조합니다.

잡 트랙커는 동일한 랙에 있는 데이터 노드에게 작업을 할당하고, 자신에게 없는 데이터 블록을 가져오기 위해서 네임 노드을 통하여 해당 데이터 노드로부터 데이터 블록을 가져옵니다.

[ What if Map Task data isn’t local? ]

Data Processing: Reduce

맵-리듀스 프레임워크의 두번째 단계는 리듀스(reduce) 작업입니다. 맵 작업(map task)은 중간 데이터(intermediage data)들을 생성하여 각자의 데이터 노드에 저장하는 단계입니다. 이제 우리는 최종 결과를 얻기 위해서 분산되어 저장되어 있던 중간 데이터들을 정제하고 결합하기 위해서 데이터들을 한곳으로 모아야 합니다.

잡 트랙커는 클러스터에 있는 하나의 노드에서 리듀스 작업(reduce task)를 시작하고, 리듀스 작업(reduce task)은 맵 작업(map task)에서 완료된 중간 데이터들을 수집합니다. 여러 곳에서 분산되어 실행되던 맵 작업의 중간 데이터들은 각자의 데이터 노드의 번호로 구분되어 TCP를 통하여 거의 동시에 리듀서(reducer)에게 응답을 합니다. 리듀스 작업은 중간 데이터를 수집하고 최종 계산 작업을 진행할 수 있습니다.

이 예제의 경우에는 “Refund” 단어의 출현 빈도수를 합산하여 결과를 ‘Results.txt’ 파일에 저장합니다. 작업이 완료되면 클라이언트는 하둡 분산 파일 시스템(HDFS)에 저장되어 있는 ‘Results.txt’을 읽을 수 있습니다.

[ Reduce Task computes data received from Map Tasks ]

맵-리듀스의 문제점

최근까지 하둡은 하둡 분산 파일 시스템(HDFS)의 대규모 데이터를 처리하는 계층으로 맵-리듀스를 선택했습니다. 하지만 최근 소개된 차세대 하둡으로 알려진 얀(YARN, Yet Another Resource Negotiator)은 하둡 환경의 맵-리듀스에 대한 의존성을 제거하였습니다.

이러한 변화에는 맵-리듀스가 가지고 있는 확장성 문제와 처리 속도가 느리다는 제약사항 때문입니다. 맵-리듀스의 이러한 한계로 인하여 많은 개발업체들이 속도 향상를 위하여 다른 방법을 생각하도록 유도하였습니다. ( 예를 들면 IBM의 어댑티브 맵-리듀스(Adaptive Map-Reduce)을 들수 있다.)

[ 하둡 2.0 스택 ]

위의 그림을 보시면 하둡 2.0에서는 클러스터 리소스 관리(Cluster Resoruce Management)를 맵-리듀스 대신에 얀(YARN)이 담당하고 있습니다. 얀은 기존의 맵-리듀스 API와의 호환성을 유지하면서도 타 회사에서 개발된 다양한 도구에서도 실행될 수 있도록 확장성을 부여하였습니다. 이를 통해서 속도가 느린 맵-리듀스의 단점을 해결할 수 있는 기반을 마련한 것입니다.

랙 인식(Rack Awareness)

하둡에는 랙 인식(Rack Awareness)이라는 개념이 있습니다. 하둡의 관리자가 수동으로 클러스터의 각 슬레이브 데이터 노드의 랙 번호(Rack number)를 정의할 수 있습니다. 데이터 복제시 랙을 선택하는 문제는 데이터의 손실을 방지하는 것과 네트워크의 성능을 높이는 측면에서 아주 밀접한 관계가 있습니다.

우리가 다시 기억해야 될 사항은 데이터를 여러곳에 복제해 놓지 않으면, 데이터를 가지고 있는 노드가 고장날 경우에 서비스가 중단이 됩니다. 또한 데이터의 복사본들이 동일한 랙에 저장이 되면, 스위치(Switch) 장비의 고장이나 정전으로 인하여 복제를 했는데도 마찬가지로 서비스를 받지 못하게 됩니다. 이러한 문제를 미연에 방지하기 위해서 데이터 복제본이 클러스터의 어느 장소에 위치시켜야 하는지에 대한 지적인 결정(Intelligent decision)을 해야 하는데, 바로 네임 노드(Name Node)에서 담당을 합니다.

네트워크 성능면에서 비교를 하면, 동일한 랙안에 존재하는 두 노드가 서로 다른 랙에 각각 존재하는 두 노드보다 대역폭(Bandwidth)이 크고, 낮은 지연시간(Lower latency)을 가집니다. 이러한 사실을 토대로 네트워크 성능만을 고려한다면, 데이터 손실로 인한 지속적인 서비스 제공이 어렵게 됩니다.

복사본들이 어떤 랙의 어느 위치에 저장되는 것이 네트워크 성능 측면과 데이터 손실 측면에서 가장 합리적인지에 대한 결정을 해야 되는데, 이은 네임 노드(Name node)의 역할이며, 클라우드에 있는 전체 데이터 노드(Data Node)에서 서비스 가능한 데이터 노드들에 대한 정보를 최신으로 유지해야 가능합니다. 더욱 흥미로운 사항은 오픈플로우(OpenFlow)를 사용할 경우에는 오픈플로우 컨트롤러(Controller)에게 물어본 후에 결정할 수도 있으며, 언제든지 컴퓨터를 통해서 수동으로 정보를 갱신할 수도 있습니다.

Preparing HDFS writes

클라이언트(Client)는 'File.txt'를 여러 개의 블록으로 나누고, 블록들을 저장하기 위해서 네임 노드(Name Node)에게 블록들이 저장될 데이터 노드(Data Node)들의 위치를 묻습니다. 네임 노드는 'Rack Awareness' 데이터를 사용하여 합리적인 데이터 노드의 리스트를 클라이언트에게 보냅니다. 네임 노드(Name Node)에서 데이터를 저장할 데이터 노드(Data Node)를 선택하는 가장 중요한 규칙은 하나의 랙(Rack)안에 두개의 복사본을 저장하고, 다른 랙에 나머지 복사본을 저장하는 방법입니다.

[ Preparing HDFS Writes ]

클라이언트는 File.txt에서 분할된 블록들을 클러스터로 복사하기전에 관련된 모든 데이터 노드들에게 블록을 받을 준비가 되었는지 확인하는 작업을 진행합니다. 먼저 클라이언트는 ‘Data Node 1’ 에게 TCP의 50010(Port)를 통해서 블록을 받을 준비가 되었는지 물어봅니다. 마찬가지로 ‘Data Node 1’ 은 TCP를 통해서 ‘Data Node 5’에게 데이터를 수신할 준비가 되었는지 물어봅니다. 동일한 방법으로 ‘Data Node 5’ 역시 ‘Data Node 6’에게 물어봅니다.

준비 요청에 대한 승인 여부는 마지막 노드에서 처음 노드로 역순으로 ‘Ready’ 메시지를 보내줍니다. ‘Data Node 6’에서 ‘Data Node 5’와 연결되어 있는 TCP의 파이프라인을 통해서 ‘Ready’ 메시지를 보내고, ‘Data Node 5’는 ‘Data Node 1’에게 보내고, 최종적으로 ‘Data Node 1’은 클라이언트에게 ‘Ready’ 메시지를 보내면 블록을 복사할 준비가 끝나게 됩니다.

HDFS Write Pipeline

블록을 클러스터에 복사하기 위해서 이미 데이터 노드들간에 연결된 TCP 통신을 통해서 이루어집니다. 즉, 데이터 노드가 블록을 받자 마자 다음 데이터 노드에게 블록을 바로 전송한다는 말입니다. 다음 그림은 클러스터 성능을 향상시키기 위해서 네임 노드가 ‘Rack Awareness’ 데이터를 활용하는 방법을 나타낸 것입니다.

‘Data Node 5’와 ‘Data Node 6’은 같은 ‘Rack 5’에 위치하고 있습니다. 이 말은 ‘Data Node 1’이 ‘Data Node 5’로 데이터를 전송하기 위해서는 하나의 스위치(Switch)만 거치면 되며, 두개의 데이터 노드들이 동일한 랙을 횡단할 필요가 없으며, 동일한 랙에 있기 때문에 높은 대역폭과 낮은 대기 시간으로 네트워크 성능을 높일 수 있습니다. 또한 현재 블록의 복사 작업이 완료가 되지 않으면 다음 블록에 대한 작업은 시작하지 않습니다.

[ HDFS Write Pipeline ]

Pipelined Write

세개의 데이터 노드들이 성공적으로 블록을 받게 되면, 메시지를 성공적으로 받았다고 네임 노드에게 ‘Block Received” 메시지를 보냅니다. 마찬가지로 “Success” 메시지를 TCP 통신을 통해서 클라이언트에게도 보낸후에 기존에 연결된 TCP 세션을 닫습니다. 클라이언트는 “Success” 메시지를 받으면 네임 노드에게도 “Success” 메시지를 보냅니다. 네임 노드는 “Success” 메시지를 받으면 블록의 노드 위치와 정보를 자신의 메타 데이터에 반영합니다. 이러한 절차가 완료가 되면 클라이언트는 다음 블록에 대한 작업을 진행합니다.

[ HDFS Pipeline Write Success ]

Multi-block Replication Pipeline

하둡은 빅데이터와 같은 대규모의 데이터를 저장하는데 사용되며, 이 때문에 네트워크 대역폭 또한 많이 사용합니다.일반적으로 테라 바이트(TB, Tera Byte) 크기의 파일들을 다루고 있으며, 기본적으로 3번의 복제가 이루어집니다. 만약1TB의 파일이 있는 경우에는 3TB의 네트워크 대역폭과 3TB의 디스크 공간이 필요합니다.

[ HDFS Multi-block Replication Pipeline ]

Name Node

네임 노드는 클러스터의 모든 파일 시스템 메타데이터(File System metadata)를 보유하고, 데이터 노드를 관리하며, 데이터에 대한 접근을 조정합니다. 네임 노드는 하둡 분산 파일 시스템(HDFS)의 중앙 컨트롤러(Central Controller) 입니다. 이 말은 네임 노드가 정상적으로 동작하지 않으면, 하둡 분산 파일 시스템은 서비스를 멈추게 됩니다. 네임 노드는 파일들이 어떤 블록들로 구성되어져 있고, 그 블록들이 클러스터의 어느 위치에 저장되어 있는지에 대한 정보를 알고 있습니다.

데이터 노드는 네임 노드에게 TCP 핸드쉐이크(handshake)를 통해서 매 3초마다 ‘heartbeat’를 보냅니다. TCP 핸드쉐이크는 보통 9000포트를 사용합니다. 매번 10번째 ‘heartbeat’는 데이터 노드들이 보유한 블록들의 정보를 네임 노드에게 보고합니다. 네임 노드는 이를 통해서 메타 데이터를 구축하고, 블록들의 사본들이 저장되어 있는 랙(Rack)과 노드(Node) 정보를 수집합니다.

네임 노드는 하둡 분산 파일 시스템의 핵심 컴포넌트입니다. 네임 노드가 없으면 하둡 분산 파일 시스템에 블록을 작성하거나 읽을 수 없으며, 스케쥴(Schedule)이 불가능하며, 맵-리듀스 작업을 할 수 없습니다. 이 때문에 네임 노드는 엔터프라이즈급(Enterprise class) 서버에 구성하는 것이 좋습니다.

[ Name Node ]

Re-replicating missing replicas

네임 노드는 데이터 노드에서 ‘heartbeat’를 수신받지 못하면, 그 데이터 노드는 죽은것으로 가정합니다. 네임 노드는 죽은 데이터 노드가 이전에 보냈던 블록 리포트(Block Report) 정보를 참조하여 다른 데이터 노드에 복제를 결정할 수 있습니다.

네임 노드는 블록의 사본을 새로운 데이터 노드에 복제하기 위해서 ‘Rack Awareness’ 데이터를 참조하여 결정을 합니다. 결정시, 하나의 랙(Rack)에 두개의 복사본을 저장하고, 또 다른 랙에 나머지 하나의 복사본을 복제해야 하며, 랙 스위치의 장애 또는 전원 장애로 인한 문제시에도 시스템이 정상적으로 작동되도록 고려합니다.

[ Re-replicating Missing Replicas ]

Secondary Name Node

하둡은 보조 네임 노드(Secondary Name Node)라는 서버를 가지고 있습니다. 보조 네임 노드에 대해서 오해하는 사항은 네임 노드에 대한 고 가용성 백업(High availability backup) 기능을 수행한다는 것인데, 이것은 사실이 아닙니다. 보조 네임 노드는 네임 노드에 접속을 해서 네임 노드의 메모리에 있는 메타데이터와 파일들의 사본을 주기적((기본 1시간 간격) 으로 가져옵니다.

보조 네임 노드는 자체적으로 복사본을 유지하면서, 파일 집합의 정보를 통합하여 네임 노드에게 다시 제공합니다. 네임 노드가 죽을 경우에 보조 네임 노드에 남아 있는 파일들을 통해서 네임 노드를 복구하는데 사용할 수 있습니다.

[ Secondary Name Node ]

Client reading files from HDFS

클라이언트가 하둡 분산 파일 시스템으로부터 파일을 가져올 때, 네임 노드와 상담하고 파일의 블록 위치를 요청합니다. 네임 노드는 파일의 블록을 가지고 있는 데이터 노드의 리스트를 반환합니다. 클라이언트는 블록 리스트로부터 데이터 노드를 선택하고, TCP 50010 포트를 통해서 한번에 하나의 블록을 읽습니다. 이전 블록의 작업이 완료되기 전까지 다음 블록의 작업은 진행되지 않습니다.

[ Client Read from HDFS ]

빅데이터 환경에서 생산되는 데이터는 그 규모와 크기가 방대하기 때문에 기존의 파일 시스템 체계를 그대로 사용할 경우 많은 시간과 높은 처리 비용을 필요로 합니다. 따라서 대용량의 데이터를 분석하기 위해서는 두대 이상의 컴퓨터를 이용하여 적절히 작업을 분배하고 다시 조합하며, 일부 작업에 문제가 생겼을 경우 문제가 발생된 부분만 재 처리가 가능한 분산 컴퓨팅 환경을 요구합니다.

하둡 분산 파일 시스템(HDFS)은 아파치 하둡 프로젝트의 분산 파일 시스템으로 처음에는 아파치 너치(Apache Nutch) 라는 웹 검색 엔진 프로젝트를 위한 하부 구조를 위해서 만들어졌습니다. 아파치 너치는 확장 가능한 오픈 소스 웹 크롤러 소프트웨어 프로젝트입니다.

2002년 미국 출신의 프로그래머인 더그 컷팅(Dug Cutting)과 마이크 카페렐라(Mike Cafarella)가 검색 소프트웨어를 개발하면서 루씬(Lucene)이라는 텍스트 검색 엔진을 만들고 이에 대한 파서(Parser)및 크롤러(Crawler)로서 너치(Nutch)라는 프로젝트를 진행하였는데, 너치에서 가져오는 웹사이트에 대한 방대한 데이터를 처리할 길이 없어 난감하던 차에2004년 Google이 발간한 구글 파일 시스템(GFS, Google File System) 논문과 맵-리듀스(Map-Reduce) 논문을 기초로 하여 약 3~4개월간의 프로그래밍을 통해 하둡 분산 파일 시스템(HDFS)을 너치에 이식하였습니다.

하둡 분산 파일 시스템(HDFS)은 대용량 파일을 저장하고 처리하기 위해서 개발된 파일 시스템입니다. 하둡 분산 파일 시스템(HDFS)은 하나의 서버에서 동작하는 것이 아니라, 여러 개의 서버에 설치되어서 서비스가 됩니다. 하둡 분산 파일 시스템(HDFS)만을 위한 별도의 스토리지가 필요 없으며, 일반 리눅스 장비에 탑재되어 있는 로컬 디스크를 이용해서 확장 가능한 유연성 있는 구조를 가지고 있습니다.

하둡 클러스터의 이해

하둡 핵심 서비스는 중요한 역할을 담당하는 세가지 모듈로 분류할 수 있습니다. 세가지 모듈로는 클라이언트 머신(Client machines)과 마스터 노드(Master node) 그리고 슬레이브 노드(Slave node)가 있습니다.

[ 하둡 서버의 역할 ]

마스터 노드(Master node)

마스터 노드(Master node)는 많은 양의 데이터를 하둡 분산 파일 시스템(HDFS)에 저장하고 맵-리듀스(Map-Reduce)를 통하여 병렬 계산(Parallel computation)을 수행하는 두 가지 핵심 기능을 담당합니다. 잡 트랙커(Jab Tracker)가 맵(Map)과 리듀스(Reduce)를 사용하여 데이터의 병렬 처리(Parallel processing)를 관리하고 조정하는 동안에 네임 노드(Name Node)는 하둡 분산 파일 시스템(HDFS)의 데이터 저장 기능을 관리하고 조정합니다.

슬레이브 노드(Slave node)

슬레이브 노드는 머신(Machine)의 대부분을 구성하고 데이터를 저장하고 계산을 실행하는 세부적인 일들을 담당합니다. 각 슬레이브는 서로간에 통신을 하고, 마스터 노드(Master Node)의 지시를 받기 위해서 데이터 노드(Data Node)와 태스크 트랙커(Task Tracker) 데몬을 실행합니다. 태스크 트랙커 데몬(Task Tracker daemon)은 잡 트랙커(Job Tracker)의 슬레이브이며, 데이터 노드 데몬(Data Node daemon)은 네임 노드(Name Node)의 슬레이브입니다.

클라이언트 머신(Client machine)

클라이언트 노드는 모든 클러스터 설정(Cluster setting)이 완료된 하둡 시스템(Hadoop System)을 가지고 있지만, 이것은 마스터 노드 또는 슬래이브 노드를 말하는 것은 아닙니다. 클라이언트 머신의 역할은 클러스터에 작업 데이터를 보내어서 맵(Map)과 리듀스(Reduce) 작업을 통하여 데이터를 분석한 후에 완료된 작업 결과를 사용자에게 보여주는 역할을 담당합니다.

하둡 클러스터(Hadoop Cluster)의 구성

실제로 제품 클러스터(Production cluster)에서는 서버 가상화(Server virtualization)나 하이퍼바이저 레이어(Hypervisor layer)가 없는데, 이러한 이유로는 성능을 저해하는 불필요한 오버헤드(Overhaed)라고 보기 때문입니다. 다음 그림은 하둡 클러서터의 일반적인 구조를 나타냅니다.

[ 하둡 클러스터 ]

우선 랙(Rack)이란 용어를 알아야 하는데, 랙(Rack)은 전산실을 구성할 때 작은 공간을 효율적으로 사용하고 장비들을 안정적으로 보호하기 위해서 사용하는 도구로써, 서버나 네트워크 장비들을 수용하기 위해서 사용되는 철제 프레임을 말합니다. 랙 안에는 여러대의 서버들로 구성되어 있습니다. 서버의 구성은 마스터(Master)역할을 담당하는 네임 노드(Name Node)와 잡 트랙커(Job Tracker), 슬래이브 역할을 담당하는 데이터 노드(Data Node)와 태스크 트랙커(Task Tracker)로 구성이 되어 있습니다.

스위치(Switch)의 역할은 네트워크 단위들을 연결하는 통신 장비로서 허브보다 전송 속도가 빠릅니다. 속도가 빠른 이유는 컴퓨터에서 주고 받는 데이터를 허브처럼 다른 모든 노드에 전송하는 것이 아니라, 데이터를 필요로 하는 노드에만 전송하기 때문입니다. 랙(Rack)안에 있는 스위치(Switch)는 클러스터를 형성하기 위해서 균일한 대역폭으로 상위의 스위치(Switch)와 연결이 되어 있습니다. 이 스위치는 다른 랙들과의 연결을 담당합니다.

랙(Rack)

랙(Rack) 안의 존재하는 대부분의 서버들은 슬레이브 노드(Slave Node) 역할을 담당하며, 몇 개의 서버들만 마스터 노드(Master Node)의 역할을 담당합니다. 그리고 각각의 서버들은 로컬 디스크 스토리지(Local Disk Storage)와 CPU와DRAM으로 구성되어 있습니다.

하둡 분산 파일 시스템(HDFS)의 구성

하둡 분산 파일 시스템(HDFS) 클러스터는 일반적으로 네임노드(Namenode)를 담당하는 서버가 한대 존재하며, 하나의 노드에 붙은 스토리지(Storage)를 관리하는 수 많은 데이터노드(Datanode)로 구성이 됩니다.

블록(Block) 단위로 읽기 쓰기 수행

하둡 분산 파일 시스템(HDFS)는 파일을 저장할 때 블록 단위로 읽기(Read)와 쓰기(Write)를 수행합니다. 하나의 파일이 물리적인 저장소에 저장될 때에도 블록 단위로 분할해서 저장이 됩니다. 하둡 분산 파일 시스템(HDFS)에서의 블록 사이즈는 기본적으로 64MB로 설정되어 있으며, 블록의 크기를 변경하고 싶다면 환경설정을 통해서 손 쉽게 변경할 수 있습니다. 보통은 128MB를 사용합니다.

[ 하둡 분산 파일 시스템(HDFS)의 구조 ]

네임노드(Namenode)는 마스터 노드(Master node) 또는 파일 시스템 네임스페이스(File System Namespace) 역할을 담당하는 노드로써, 파일과 디렉토리에 대한 메타 데이터(Meta data) 정보를 저장하는 역할을 담당합니다. 메타 데이터에는 디렉토리(Directory)의 구조, 파일에 대한 정보와 파일이 저장되어 있는 물리적인 위치와 같은 정보가 저장됩니다. 또한 데이터노드로의 블록 매핑을 판단합니다. 데이터노드(Datanode)는 요청한 파일을 읽거나 저장하는 역할을 담당하고 네임노드의 지시에 따라 블록을 생성, 삭제 그리고 복제 작업을 수행합니다.

네임노드와 데이터노드는 컴퓨터에서 실행하도록 설계된 소프트웨어의 조각입니다. 이러한 컴퓨터들은 일반적으로 GNU 리눅스(Linux) 운영체제를 사용합니다. 하둡 분산 파일 시스템(HDFS)은 자바 언어(Java Language)를 사용하여 만들어졌습니다. 자바를 지원하는 어떤 컴퓨터에서도 네임노드 또는 데이터노드 소프트웨어를 수행할 수 있습니다. 높은 이식성의 자바 언어의 사용은 하둡 분산 파일 시스템(HDFS)가 광범위한 컴퓨터에 배포될 수 있음을 의미합니다.

파일 쓰기 동작 설명

클라이언트(Client)가 파일을 디스크에 저장하기 위해서 먼저 ①네임노드(Namenode)에게 파일을 저장해도 되는지 물어봅니다. 쓰기 권한이 있는 경우에는 네임노드(Namenode)에서 블록을 저장할 데이터노드(Datanode)의 정보를 클라이언트에게 알려줍니다. ②클라이언트는 블록(Block)들을 지정된 데이터노드(Datanode)에 저장합니다.  

[ HDFS Write Operation ]

데이터 복제(Data Replication)

클라이언트(Client)는 파일을 128MB(기본, 64MB) 작은 블록(Block) 단위로 분할하고, 같은 블록을 클러스터(Cluster)에 있는 세곳의 노드(Node)에 복제(Replication)시킵니다. 동일한 블록으로 분할되기 때문에 병렬 처리(Parallel Processing)가 가능하며, 작업 노드(Node)에서 문제가 발생하여 데이터를 참조하지 못할 경우에도 다른 노드에 복제되어 있는 내용으로 작업을 계속할 수 있으므로 지속적인 서비스가 가능합니다. 하둡에서 동일한 데이터를 복제하는 기본값은 3이며, ‘hdfs-site.xml’에 있는 ‘dfs.replication’ 파라메터를 통하여 재 설정할 수 있습니다.

아래의 그림은 클라이언트에서 파일을 A, B, C 블록으로 분할하고, A 블록을 클러스터의 어느 위치에 저장할지를 물어봅니다. 네임 노드(일반적으로 TCP 9000)는 A블록을 저장할 데이터 노드의 목록을 클라이언트에게 보냅니다.

클라이언트는 데이터 노드(일반적으로 TCP 50010)에 직접 A블록을 기록합니다. 수신받은 데이터 노드는 다른 데이터 노드에 블록을 복제하고, 나머지 블록에 대해서도 반복적으로 작업을 합니다. 네임 노드는 데이터의 경로를 가지고 있지 않으며, 데이터가 클러스터의 어느 위치에 저장되어 있는지에 대한 지도를 제공합니다. 즉 네임 노드는 랙안의 노드들의 정보와 메타 데이터에 저장된 노드 정보를 이용하여 데이터의 위치를 찾을수 있습니다.

[ 하둡의 데이터 복제 ]

2005년 더그 커팅과 마이크 카파렐라에 의해 개발된 하둡(Hadoop, High-Availability Distributed Object-Oriented Platform)은 대량의 자료를 처리할 수 있는 클러스터 컴퓨터 환경에서 동작하는 분산 응용 프로그램을 지원하는 프레임워크입니다. 하둡에 대해서 간단히 말하자면, 방대한 양의 데이터를 분산 처리하여 빠른 시간 내 결과를 제공하는 오픈소스 기반 데이터 처리 기술입니다.

하둡의 탄생은 구글(Google)이 대규모 자료를 검색하고 분석하는데 사용한 구글 파일 시스템(GFS, Google File System)과 맵-리듀스(Map-Reduce)에 대한 논문을 접하고 이를 참고하여 구현하였습니다. ‘하둡’ 이란 명칭은 더그 커팅의 아들이 가지고 놀던 장난감 코끼리의 이름을 따서 지어졌다고 전해집니다.

[ 하둡의 심볼 ]

지금까지의 데이터 분석 기술은 대부분 컴퓨터 한대로 메모리, 파일시스템, 데이터베이스에 데이터를 저장하고, 이를 기반으로 데이터를 분석하는 구조였는데 하둡이 보급되면서 저가의 x86 컴퓨터들을 이용하여 대규모 데이터를 저장하고 분석할 수 있는 길이 열린것입니다.

하둡 에코 시스템 1.0

아래의 그림은 하둡 초기 버전인 하둡 에코 시스템 1.0에 대한 전체 구성도입니다. 하둡 에코 시스템 1.0에 대해서 간략하게 설명을 드리겠습니다.

[ 하둡 에코 시스템 1.0 ]

데이터 수집 기술

하둡에서 데이터 수집을 담당하는 기술로는 아파치의 스쿱(Apache’s Sqoop), 클라우데라의 플룸(Cloudera’s Flume), 아파치의 척와(Apache’s Chukwa)등이 있으며, 하둡에서 제공하는 데이터 수집 기술은 아니지만,  페이스북에서 만들어서 사용하고 있는 스크라이브(Facebook’s Scribe)등이 있습니다.

대용량 데이터는 정형데이터와 비정형데이터 두가지 형태로 분류할 수 있습니다. 정형데이터는 저장된 형태가 규칙적인 데이터를 말하며, 비정형 데이터는 저장된 형태가 규칙적이지 않는 데이터를 말합니다. 정형데이터는 기업이나 공공기관에서 관리하고 있는 관계형 데이터베이스(RDB, Relational Database)를 말하며, 비정형데이터는 트위터(Twitter), 페이스북(Facebook)과 같은 소셜 네트워크 서비스(SNS, Social Network Service)에서 만들어지는 데이터를 말합니다.

정형데이터를 수집하는 기술로는 스쿱(Sqoop)이 있으며, 비정형데이터를 수집하는 기술로는 클라우데라(Cloudera)의 플룸(Flume)과 아파치(Apache) 척화(Chukwa)등이 있으며, 페이스북에서 사용하는 스크라이브(Scribe)도 비정형데이터 수집 기술입니다.

데이터 저장 및 관리 기술

하둡에서 핵심 코어에 속하는 기술로는 데이터를 저장하는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)과 저장된 데이터를 관리하는 맵-리듀스(Map-Reduce)등이 있습니다. 하둡 분산 파일 시스템(HDFS)은 대용량 파일을 지리적으로 분산되어 있는 수많은 서버에 저장하는 솔루션이며, 맵-리듀스는 분산되어 저장된 대용량 데이터를 병렬로 처리하는 솔루션입니다.

초기에 설계된 하둡 에코 시스템 1.0의 경우 배치 처리(Batch processing)를 목적으로 만들어진 시스템으로 맵과 리듀스간의 셔플링(Shuffling) 작업에 많은 시간을 허비하여 실시간 분석에 적합하지 않으며, 기존에 사용하고 있거나 새로 만들어진 솔루션을 확장하여 적용하는데 문제점을 가지고 있었습니다.

이러한 하둡 에코 시스템 1.0의 문제점은 관계형 데이터베이스 분석 시스템에 익숙한 많은 분석가들과 사용자들을 하둡으로 끌어들이는데 실패하는 원인이 되었으며, 이러한 문제점를 해결하기 위해서 하둡 에코 시스템 2.0에서는 맵-리듀스(Map-Reduce)를 버리고 YARN(Yet Another Resource Negotiator)을 채택하여 확장성과 데이터 처리 속도를 개선시켰습니다.

[ 하둡 에코 시스템 1.0 과 2.0 변경 사항 ]

분산 데이터베이스 H베이스(HBase)

하둡에서 제공하는 NoSQL(Not Only SQL) 데이터베이스입니다. H베이스는 자바 언어로 만들어졌으며, 하둡 분산 파일 시스템(HDFS)를 이용하여 분산된 컴퓨터에 데이터를 저장합니다. H베이스는 압축 기능과 자주 사용되는 데이터를 미리 메모리에 캐싱하는 인-메모리(In-Memory) 기술을 사용하여 데이터 검색 속도를 높입니다. 

하둡에서 사용하는 데이터베이스는 관계형 데이터베이스가 아닌 NoSQL(Not Only SQL) 입니다. 관계형 데이터베이스는 대용량 데이터를 처리하기 위해서 만들어진 시스템이 아니며, 국가나 회사에서 관리하는 정보 자원을 저장하고, 사용자가 손쉽게 SQL언어를 사용하여 저장된 정보를 다양한 방법으로 분석해 주는 시스템입니다. 현재도 많은 분석가들과 사용자들이 관계형 데이터베이스를 사용하고 있는데, 이러한 이유로는 관계형 데이터베이스를 통하여 정보(Information)를 다양한 도구를 사용하여 여러가지 측면에서 분석이 가능하며, 또한 결과를 실시간으로 조회할 수 있기 때문입니다.

NoSQL(Not Only SQL)은 대용량 데이터를 처리하기 위해서 탄생된 데이터베이스입니다. 대용량 데이터를 저장하고 처리하기 위해서는 지리적으로 분산되어 있는 노드들에 대한 안정적인 관리가 필요하며, 속도보다는 데이터를 손실하지 않고 저장하는 방법과 더 많은 데이터를 처리하기 위해서 노드들을 쉽게 확장할 수 있는 방법에 중점을 두고 설계가 되었습니다. 이로 인하여 현장에서 데이터베이스를 운영하고 관리하는 분석가들과 사용자들이 원하는 빠른 속도와 쉬운 분석 방법 제공 그리고 관계형 데이터베이스에서 사용하고 손에 익었던 도구들을 그대로 사용하고 싶은 욕구를 충족시키지 못하는 문제점을 가지고 있습니다.

NoSQL(Not Only SQL) 데이터베이스에는 다양한 제품들이 있으며, 이 제품들을 특성에 맞게 'Key-Value store', 'Graph Database', 'Document Store', 'Wide Column Store' 4개의 제품군으로 군집화 시킬수 있습니다. 

'Key-Value store' 제품군으로는 멤캐시드(Mem-Cached)와 레디스(Redis, Remote Dictionary Server)등이 있으며, 키-밸류 형태로 이루어진 비교적 단순한 데이터 타입을 데이터베이스에 저장합니다. 'Graph Database' 제품에는 네오포제이(Neo4j)가 있으며, 그래프 모델에서 필요한 정점(Vertex)와 간선(Edge) 그리고 속성(Property)등과 같은 정보를 데이터베이스에 저장합니다. 'Document Store' 제품군에는 카우치DB와 몽고DB가 있으며, 문서 형태의 정보를 JSON 형식으로 데이터베이스에 저장합니다. 마지막으로 'Wide Colum Store' 제품군에는 H베이스(HBase)와 카산드라(Cassandra)가 있으며, 컬럼안에 여러 정보들을 JSON 형태로 저장할 수 있습니다.

하둡 진영에서는 관계형 데이터베이스에 호감을 가지고 있는 분석가와 사용자들의 마음을 돌리기 위해서, 빠른 속도와 손 쉬운 사용 그리고 관계형 데이터베이스에서 사용하던 도구들을 이용할 수 있는 시스템을 만들기 위해서 노력하고 있습니다. 우리는 이러한 데이터베이스 제품들을 'NewSQL'이라고 부르고 있으며, 여기에는 그루터(Gruter)의 타조(Tajo), 구글의 드레멜(Dremel), 호튼웍스의 스팅어(Stinger), 클라우데라의 임팔라(Impala)등이 있습니다. 

하이브(Hive)

아파치의 하이브(Hive)는 ‘SQL 온 하둡(SQL On Hadoop)’ 시스템입니다. 'SQL 온 하둡'은 하둡에서 SQL 언어를 사용하여 편리하게 정보를 조회(Query)하는 방법을 제공합니다. 하둡은 하이브(Hive)가 없었던 시절에는 맵-리듀스(Map-Reduce) 언어를 사용하여 하둡 분산 파일 시스템(HDFS)에 저장된 정보들을 조회(Query) 했습니다. 프로그램을 모르는 일반 사용자들이 맵-리듀스 언어를 사용하여 조회(Query)하는 일이 어려웠습니다. 하이브는 하이브큐엘(HiveQL)이라는SQL과 거의 유사한 언어를 사용하여 일반 사용자들이 쉽게 데이터를 조회(Query)할 수 있도록 지원합니다. 

하지만 하이브에도 몇가지 단점이 있습니다. 하이브큐엘(HiveQL)을 통해서 조회(Query)를 실행하면 내부적으로 맵-리듀스 언어로 변환하는 작업을 거칩니다. 맵-리듀스는 맵과 리듀스간의 셔플링 작업으로 인하여 속도가 느리다는 단점이 있습니다. 하이브큐엘(HiveQL)이 일반 사용자들에게 손쉽게 조회(Query)할 수 있는 방법을 제공하고 있지만 처리 속도가 느리다는 문제점은 여전히 가지고 있습니다. 또한 하이브큐엘(HiveQL) 언어는 SQL과 비슷한 언어이지만 표준 SQL(Ansi SQL)의 규칙을 준수하지 않으며, 사용자들은 이러한 차이점을 다시 배워야하는 문제점을 가지고 있습니다.   

SQL 온 하둡(SQL On Hadoop)

하이브가 가지고 있는 문제점을 개선하기 위한 하둡 진영은 크게 두 갈래로 나뉩니다. "하이브를 완전히 대체하는 새 기술을 쓸 것인가?" 아니면 "하이브를 개선해 속도를 높일 것인가?"

하이브를 살려야 한다는 입장을 가장 강력하게 내세운 회사는 호튼웍스입니다. 호튼웍스는 하이브를 최적화하고 파일 포맷 작업을 통해 하이브 쿼리 속도를 100배 끌어올리겠다는 비젼을 내 놓았습니다. 이것이 바로 스팅어(Stinger)입니다.

하이브를 버리고 새로운 엔진을 찾아야 한다는 진영은 그루터의 타조와 클라우데라의 임팔라가 있습니다. 타조는 하이브를 개선하는데 한계가 명확하기 때문에 대용량 SQL 쿼리 분석에 적합하지 않다는 입장이며, 기획 단계부터 하이브를 대체하는 새로운 엔진을 개발하고 있습니다.

클라우데라의 임팔라는 좀 특이한 경우인데, 일정 규모 이상의 데이터는 임팔라로 분석이 불가능합니다. 임팔라는 메모리 기반 처리 엔진이어서, 일정 용량 이상에서는 디스크 환경의 하이브를 사용해야 합니다. 하지만 전체 틀에서는 하이브를 버리는 쪽으로 무게를 두고 있습니다.

[ 임팔라 스택 ]

대표적인 Hadoop 솔루션 업체로는 클라우데라(Cloudera)와 호튼웍스(Hotonworks)가 있습니다. 클라우데라는 빅데이터와 클라우드시장의 고육 및 기술지원을 제공하고 있으며, 호튼웍스는 하둡 코어기술과 아키텍처 개선을 담당하고 있습니다. 또, IBM은 아파치 하둡 (Apache Hadoop)을 기반으로 자신들의 Basic, Enterprise 배포판을 가지고 있고, 오라클(Oracle)은 자신들의 하드웨어에 클라우데라를 결합한 하둡 어플라이언스(Hadoop Appliance)를 제공하고 있습니다.