하둡 기반으로 빅데이터 플랫폼을 구축하는데 있어 플랫폼 구축 단계에서 많이 놓치는 것이 있는데 운영 단계로 넘어 갔을 때 어떻게 하둡 클러스터를 구성할 것인가에 대한 그림이다. 일반적으로 초기 단계에서는 raw 데이터 저장 후 분석 이슈가 주로 다루어 지는 내용이기 때문에 서버의 사이징 등을 데이터의 용량과 분석에 촛점을 맞춘다. 이 단계가 지나서 어느 정도 의미 있는 데이터를 찾게 되면 이 분석 작업을 정기적인 작업으로 전환하고 분석 결과를 RDB 또는 HBASE 등과 같은 실시간 데이터 제공이 가능한 저장소에 저장을 해야 한다. 이 시점에 되면 정기적인 업무는 안정적인 실행 시간을 보장 받아야 하며 혹시라도 분석 결과 데이터가 커 HBase에 저장해서 제공하는 형태라면 HBase의 성능도 고려를 해야 한다. 하나의 하둡 클러스터만 운영하는 경우에는 곤란해진다. 다양한 측면으로 데이터를 분석하는 작업은 여전히 필요하게 되고, 이 작업은 클러스터의 리소스를 대부분 가져가게 된다. 물론 fair-scheduler 등과 같은 스케줄러를 사용하여 리소스를 나누어서 사용할 수는 있지만 HBase와 같은 솔루션이 하둡 위에 올라가는 상황이라면 서비스에 필요한 성능을 보장 받을 수 없게 된다. 이때 취할 수 있는 방법은 다음과 같다.
1. 하나의 클러스터 전체 규모를 키운다. 2. 클러스터를 분리하여 서비스용, 개발/분석용으로 구분한다.
1번의 경우에도 여전히 안정적인 서비스 품질을 보장 받기 어렵기 때문에 가능하면 2번 방으로 가는 것이 좋을 것이다.
따라서 처음 도입 단계에서는 예상하기 어렵겠지만 어느 정도 분석에서 성과가 나타나기 시작하는 시점에서는 운영용 클러스터를 도입하는 것을 고려하여 예산, 인프라 계획 등을 잡는 것이 좋다.
빅데이터 외부 프로젝트를 수행하면서 새롭게 하둡을 도입하고자 하는 여러 기업을 만나 보았습니다. 이때 항상 물어 보는 것이 유지보수에 대한 내용입니다. 그래서 하둡이나 하둡 에코 시스템에 대한 유지보수에 대한 이야기를 좀 해볼까 합니다. 하둡 관련 프로젝트를 하면서 필자가 항상 주장하는 것은 반드시 내부 기술 역량을 갖추어야 한다는 것입니다. 내부적으로 갖추어여 할 역량은 대략 다음과 같은 것이 있습니다.
1. Hadoop 및 에코 시스템에 대한 전반적인 이해 2. 시스템 운영 능력 및 문제해결 능력 3. Hadoop 및 에코 시스템을 이용한 응용(분석 프로그램) 개발 능력
1, 3번 항목에 대해서는 실제 도입하고자 하는 회사에서도 어느 정도 인식하고 있는 부분입니다. 2번 항목의 경우 대부분의 기업은 인프라 운영 부서로 업무를 이관하려고 합니다. 하지만 하둡의 현재 솔루션 상태를 보면 인프라 운영 부서로 운영 업무를 이관하는 것이 쉬운 상황은 아닙니다. 그 이유를 몇가지 생각해보면 다음과 같습니다.
- 하둡과 에코 시스템은 복잡한 분산 아키텍처입니다. 실제 사용되는 데몬의 종류도 많고 데몬의 상태도 다양합니다. 이런 복잡한
아키텍처를 제대로 이해해야만 운영할 수 있는데 인프라 운영 조직에서 복잡한 아키텍처를 이해하면서까지 운영할 수 있는 조직은 많지
않습니다. - 인프라 운영 부서의 대부분의 중요 미션은 장애율을 줄이는 것입니다. 거기에는 하드웨어 장애까지 포함하고 있습니다. 하지만 하둡이나 하둡 에코 시스템의 경우 기존 시스템보다 CPU, 디스크, 메모리 등을 시스템의 극한 상황까지 사용하는 경우가 많으며 다른 업무의 서버에 비해 장애가 자주 발생합니다. 하지만 서버에 장애가 발생하였다 하더라고 즉시 대응할 필요가 없는 아키텍처를 가지고 있는 것이 하둡인데 인프라 운영 조직의 특성상 이런 장애 상태를 보고만 넘어가지 않을 가능성이 많습니다. 장애 보고서와 재발 방지 대책 등등... 기존의 프로세스대로 운영을 하게 되면 운영하는 분들도 무지 스트레스를 받을 겁니다. - 하나의 문제가 전체의 문제가 될 수도 있고 하나의 문제가 아무런 문제를 발생시키지 않을 수도 있는 복잡한 상황 - 원인 파악의 어려움 - 다양한 버전의 오픈소스
따라서 인프라 운영 조직의 경우 당연히 기존의 방식과 동일하게 벤더에서 제공하는 하둡 어플라이언스를 도입하는 것이 더 좋을 것 같다라는 의견을 많이 제시합니다. 하둡 어플라이언스를 도입한다고 해서 앞의 운영 문제가 해결될까는 의문입니다. 아직 필자도 하둡 어플라이언스를 제공하는 벤더의 유지보수 SLA을 보지는 못했습니다. 하지만 추측하건데 하드웨어 장애에 대한 즉시 대응이라던가, 장애 원인 파악 보고서 작성 등과 같이 기존의 엔터프라이즈 시스템에서 제공되던 많은 항목들이 없어지거나 수준이 낮아졌을 가능성이 높습니다.
버그나 문제가 발생할 경우 다음과 같은 해결 방법이 있습니다.
1. 오픈소스 커뮤니티의 버그 패치나 문제 해결 방법에 의존 2. 개발팀 스스로 버그 픽스 또는 문제 해결 3, 어플라이언스의 경우 제공하는 벤더에서 패치를 제공하거나 문제를 해결
벤더의 제품을 구매하는 경우 3번을 기대하고 구매하는 것인데 현재의 하둡 어플라이언스를 제공하는 업체들은 자체 하둡 코어를 수정할 수 있는 능력이나 문제를 해결할 수 있는 능력이 높은 것 같지는 않습니다. 대부분은 Cloudera 배포판을 사용하거나 아파치 버전을 조금 수정해서 사용하는 정도라고 볼 수 있습니다. 따라서 어플라이언스를 도입하고도 오픈 소스 커뮤니티에 의존하거나 심지어는 자체 해결해야 할 경우가 많아질 가능성이 높습니다. 또 하둡의 파편화는 어떻게 해결할 것인지도 고민입니다. 물론 어플라이언스를 도입했을 때 장점은 있습니다. 그런 문제 발생 시 문제의 원인, 문제의 책임을 인프라 조직이 아닌 벤더에게로 전가시킬 수 있습니다. 이 장점을 제외한다면 하둡 어플라이언스를 구매했을 때의 장점은 거의 없다고 할 수 있습니다. 물론 많은 업체들이 이런 이유때문에 벤더 솔루션을 선정하는 경우도 많습니다.
그러면 하둡을 도입하고자 하는 기업은 하둡의 운영을 어떻게 해야 할까요? 당장의 대답은 개발팀에서 운영을 같이 해야 한다는 것입니다. 필자는 기회가 있을때 마다 어플라이언스 도입 비용으로 내부 기술력을 키우는데 투자하는 것이 더 좋다고 강조하고 있습니다. 운영의 주체를 지금 당장 인프라 운영 조직으로 넘기기 보다는 내부 개발 조직에서 기술력을 내재화 시키고 이를 기반으로 OS/하드웨어는 인프라 운영 조직에서 하둡 이후 부터는 내부 개발 조직에서 운영하는 것이 좋다고 생각합니다. 현재의 하둡은 단순히 솔루션을 사용하는 관점이 아니라 다양한 에코 시스템을 연계하여 하나의 거대한 데이터 처리 플랫폼을 만들어야 하는데 이를 위해서는 내부 개발팀에서 운영도 같이 병행하여 빠른 시간에 기술력을 올려야 하기 때문입니다.
마지막으로 빅데이터를 추진하는 대부분의 기업은 대기업입니다. 국내 소프트웨어의 경쟁력을 확보한다는 큰 뜻을 위해서라도 이런 기회에 오픈 소스 중심의 생태계를 만들어 보는 것도 좋지 않을까 제안해봅니다. 오픈 소스에서는 외국 벤더도 어쩔 수 없습니다.
두서 없이 적다 보니 내용 정리가 잘 안되지만 제 의견은 나름 전달할 수 있을 것 같아 포스팅합니다. 글 중 잘못된 내용있으면 알려주시면 바로 수정하겠습니다.
좋은 조언 고맙습니다.
현재 인프라팀에 근무중에 있으며
개발팀에서 hadoop 프로젝트를 진행중이면 인프라 이관에 대해
고민하고 있습니다.
저희쪽에서는 OS, 하드웨어, hadoop 정도까지 생각중에 있습니다.
에코시스템도 알아야 될것 같아서 VM 에 pig, hive, hbase, zookeeper, oozie,
ganglia, nagios 등을 설치하고 한번씩 실행해 보고 있습니다.
테이터 크기가 작아서 실운영환경에서 나타나는 문제들은 확인하기
어려울것 으로 보입니다.
그냥 테스트 정도 하고 있습니다.
아래 와 같은 부분에대해 좀더 공부해 볼려고 하는데 가는 길이 맞는지 조언 부탁드립니다.
- nosql(몽고, 카산드라) 과 hadoop 버그패치, 에코시스템 업그레이드등의 운영방법
계속 새해 복많이 받으세요 라는 글만 있어서 뻘쭘함이 있어 오랜만에 팁하나 올립니다.
최근 Hadoop 클러스터간 데이터 이동하려고 DistCp를 사용했는데 네트워크 bandwidth 때문에 copy map 갯수를 5개로 주고 실행했는데 복사 성능이 너무 느리게 나왔습니다. 몇 가지 확인한 결과 5개의 copy map task가 하나의 TaskTracker에 할당되어 한 서버의 네트워크 용량만큼만 복사되는 문제가 있었습니다.
DistCp의 map task 할당 정보에는 tasktracker 정보가 없는데 이럴 경우 기본 스케줄러는 하나의 TaskTracker heartbeat에 하나의 Task 만 할당하도록 되어 있습니다.
하지만 fair-scheduler를 사용할 경우 TaskTracker의 remain slot 만큼 할당하도록 되어 있어 첫번째 접속해서 heartbeat을 보낸 TaskTracker가 5개를 모두 다 할당 받는 문제였습니다.
해결방법은 fair-scheduler.xml에 다음과 같은 옵션 설정
오랜만에 기술적인 글 올리네요... Hadoop 파일 시스템 사용중에 에러가 발생하여 원인 분석한 내용 정리합니다. 버전은 1.0.0 입니다.
그림으로 대략 설명이 되었는데 요약하면 특정 DataNode에 문제가 발생하여 DFSClient가 Recover 요청을 하게 되는데 이 요청을 받은 DataNode가 recover는 정상적으로 수행하였지만 Recover 결과 생기게 되는 새로운 blockid를 DFSClient에 전달 못하는 경우 발생하는 에러입니다. 새로운 blockid를 전달하지 못하는 경우는 recover 처리하는데 시간이 오래 걸리게(다른 DataNode의 부하, 문제 등으로 인해) 되면 DFSClient는 RPC Timeout이 발생하게 되어 recover 요청에 문제가 있다고 판단하고 다시 다른 DataNode에 recover을 하게 됩니다. 13번에서 받은 DataNode가 새로운 blockid를 보내주는 방법으로 개선 가능할 것 같은데 패치가 있는지는 찾아보지 않았습니다. 이렇게 되었을 때 문제는 close 처리시 이미 close되었다는 메시지가 나타납니다. 따라서 close에서도 예외 처리를 해주는 습관이 중요합니다. 데이터 유실은 발생하지 않습니다.
Bamboo에 이어 이번에는 그루터에서 만든 Hadoop, Hadoop Echo 시스템 관리 도구인 Cloumon에 대해 소개하겠습니다. Cloumon은 처음 개발은 오픈소스로 시작하였지만(www.cloumon,org, www.github.com/gruter/cloumon) UI를 전면 개편하고 Hadoop 이외에 Hive, Flume, ZooKeeper 등 여러 솔루션을 관리하는 기능을 추가하여 엔터프라이즈 버전으로 만들었습니다. Cloumon을 엔터프라이즈 버전으로 만든 이유는 아직 국내 기업에게 오픈 소스 솔루션으로만 판매하기 어려운 시장 상황 때문입니다. Cloumon은 처음에는 판매하는 솔루션이 아니라 그루터 내부 시스템을 관리/운영하기 위해 만들었기 때문에 그루터 내부에서 계속 사용하고 있으며 기능 개선, 솔루션 추가, 업그레이드 등이 꾸준하게 진행되고 있습니다. 다음은 Cloumon에 대한 소개 글입니다.
===================================================================== 클라우몬은 하둡 에코 시스템 기반의 빅데이터 플랫폼을 통합적으로 관리하는 기능을 제공한다. 클라우몬을 이용하여 데이터의 수집, 저장, 분석에 이르는 다양한 오픈 소스를 쉽게 관리, 모니터링 할 수 있다. 하둡과 하둡 에코 시스템은 대부분 오픈 소스로 구성되어 있으며 빅데이터 처리에 강력하고 안정적인 기능을 제공하는 소프트웨어 스택이다. 기능은 강력하지만 각각의 솔루션의 관리 및 모니터링 기능은 취약하며 이를 하나의 관리도구에서 통합 관리하는 것은 쉽지 않다. 모니터링을 위해 Ganglia, Nagios 등과 같은 오픈 소스 모니터링 도구를 활용할 수 있지만 이런 구성은 단순 모니터링만 지원하며 하둡 에코 시스템 내 일부 솔루션은 Ganglia, Nagios 등과 연동되는 기능을 제공하지 않는다. 클라우몬은 기본적으로는 하둡 에코 시스템의 각 개별 컴포넌트에 대한 모니터링 기능 뿐만 아니라 하둡의 파일, 작업 관리, Zookeeper의 노드 관리, Flume의 Data Flow 관리, Hive query workbench 등과 같은 관리하는 기능을 제공한다. 또한 그루터의 빅데이터 플랫폼 솔루션인 BAAS와 연동하여 웹 UI 기반으로 데이터 Flow 제어, 실시간/배치 분석 질의 관리, 분석 결과 조회 기능 등을 제공하는 솔루션이다.
클라우몬은 관리 기능 및 사용자에게 관리화면을 제공하는 애플리케이션 서버와 수집된 모니터링 데이터를 저장하기 위한 데이터베이스로 구성되어 있다. 애플리케이션 서버에서는 각 솔루션의 데몬들에 대한 모니터링 정보를 수집하여 데이터베이스에 저장한다. 각 솔루션 별로 수집되는 정보 및 방식은 모두 다르며 관리자가 설정된 특정 항목의 값이 임계 값보다 큰 값이 수집되면 메일 또는 SMS로 관리자에게 전송한다. 데이터베이스에는 수집된 모니터링 데이터와 설정 정보 등이 저장되며 기본 구성에서는 MySQL 을 사용한다.
빅데이터 통합 관리 클라우몬은 기본적으로는 하둡과 하둡 에코 시스템을 관리, 모니터링하는 기능을 제공하지만 빅데이터 플랫폼을 구성할 경우 플랫폼 전체를 유기적으로 관리하는 역할을 수행한다. 다음은 빅데이터 처리 흐름에 따른 클라우몬의 관리 기능을 매핑한 그림이다.
Hadoop File System 관리 - 모니터링 및 상태 정보 관리 NameNode, DataNode의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다.
- 파일 관리 파일 관리 기능은 하둡에 저장된 파일을 웹 브라우저에 파일 탐색기와 비슷한 사용자 인터페이스를 제공하여 파일 관리를 쉽게 할 수 있다. 파일의 기본 정보뿐만 아니라 파일이 여러 개의 블록으로 분리되어 있는 경우 블록 정보와 블록이 저장된 서버 정보도 쉽게 볼 수 있는 기능을 제공한다.
- 멀티 클러스터 관리 하나의 클라우몬 화면에서 여러 개의 하둡 파일 시스템 클러스터를 동시에 관리할 수 있다.
- 자동 서버 등록 기능 NameNode, DataNode의 환경설정 중 metrics 관련 설정에서 클라우몬 서버에 대한 정보를 설정하면 하둡 데몬 실행 시 자동으로 클라우몬에 등록하고 등록된 이후에는 자동으로 상태 정보를 수집하고 모니터링 한다.
Hadoop MapReduce 관리 - MapReduce 클러스터 관리 JobTracker, TaskTracker의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다. - MapReduce Job 모니터링 MapReduce 작업 목록과 진행 상황을 관리하는 기능으로 하둡에서 기본적으로 제공하는 모니터링 화면에서는 일정 시간이 지나면 과거의 작업에 대한 상세 정보는 볼 수 없으며 JobTracker를 재시작하면 과거의 작업 실행 이력 정보는 볼 수 없다. 클라우몬에서는 과거의 모든 작업 목록을 조회할 수 있으며 일자로 검색할 수 있다. 작업 목록뿐만 아니라 작업의 Summary, Counter 정보와 job.xml 정보도 볼 수 있으며 진행 중인 작업의 경우 작업 진행 상황과 Map, Reduce Task 목록 정보도 조회 가능하다. - Job 스케줄링 주기적으로 수행되는 작업을 등록하여 관리할 수 있는 기능으로 작업 등록은 사용자가 만든 Jar 파일 또는 Streaming 명령어, HiveQL 등을 이용하여 등록할 수 있다. 스케줄러에서는 현재 대기 상태에 있는 작업 목록이나 특정 작업의 과거 실행 이력 정보를 제공한다.
Hive 관리 빅데이터 분석에 있어 개발자나 시스템 전문가가 아닌 도메인 전문가, 데이터 전문가가 데이터에 쉽게 접근하게 분석을 수행할 수 있어야 한다. 매번 분석 시 마다 하둡 MapReduce를 프로그램을 개발하는 것은 데이터에 대한 접근을 어렵게 하고 다양한 분석 시도를 하기 어렵다. Hive는 SQL과 유사한 질의 언어를 이용하여 데이터를 쉽게 볼 수 있는 기능을 제공한다. Hive를 이용한다 하더라도 명령행 라인과 하둡 파일 시스템 명령어, MapReduce 작업 관리 명령어 등을 알고 있어야 하기 때문에 비전문가에게는 쉽지 않다. 클라우몬의 Hive 관리 기능은 웹 기반 질의 실행, 스키마 관리, 질의 실행 결과 조회, 작업 관리 등을 실행할 수 있기 때문에 쉽게 데이터에 접근할 수 있게 해준다. Hive 관리 도구 중 대부분은 Hive Server를 이용하는 방식으로 구현되어 있는 반면 Cloumon의 Hive 관리 기능은 Hive 모듈을 Cloumon에 탑재하여 Hive session, history, Job 연동 등과 같은 다양한 기능을 제공한다.
- 스키마 관리 Hive의 데이터베이스, 테이블 정보를 관리하는 기능으로 테이블 목록, 생성, 삭제 등 기본 기능과 테이블의 컬럼 정보, SerDe 정보, 파티션 정보 등 상세 정보를 볼 수 있는 화면을 제공한다. 또한 테이블의 데이터 파일에 있는 데이터를 직접 조회하거나 다운로드 할 수 있다.
- 질의 Workbench HiveQL을 실행하고 실행 결과를 브라우저에서 관리할 수 있는 기능을 제공한다. 질의 저장 기능은 질의를 저장하여 나중에 불러와서 사용할 수 있다. 클라우몬의 Workbench 기능은 Hive Shell 에서 제공하는 History 기능과 세션 기능을 가지고 있어 페이지가 리로딩 되거나 다른 페이지로 이동 후에 다시 접속해도 이전 수행 내역을 볼 수 있다. Hive 질의는 질의 수행 후 결과 조회까지 많은 시간을 기다려야 하는데 이 기능을 이용하면 작업이 종료될 때까지 기다릴 필요 없으며 향후 재 접속 시에 실행 정보를 확인할 수 있다. Query의 진행 상황 정보를 제공하여 질의가 어느 정도 수행되었는지 한눈에 확인할 수 있다.
- MapReduce 작업 모니터링 연동 Hive 작업은 대부분 하둡 MapReduce 작업으로 실행되기 때문에 MapReduce 작업에 대한 모니터링도 필요하다. 클라우몬은 MapReduce 관리 기능을 제공하기 때문에 이 기능과 Hive 관리 기능을 연동하여 특정 Query에 의해 생성된 MapReduce 작업만 선택하여 관리할 수 있는 화면을 제공한다.
ZooKeeper 관리 - ZooKeeper 클러스터 관리 ZooKeeper 클러스터를 구성하는 서버의 상태 정보 및 각 서버에 접속되어 있는 클라이언트의 접속 상태와 네트워크 트래픽, 큐 대기 시간 등을 모니터링 할 수 있는 기능을 제공한다. ZooKeeper 클러스터에 장애가 발생하면 다른 기능을 수행하는 클러스터에도 영향을 미치는 중요한 컴포넌트이기 때문에 ZooKeeper의 서버들 중 일부 서버에 장애가 발생하면 가능한 빠르게 처리하는 것이 좋다. 클라우몬은 ZooKeeper 서버 장애 즉시 장애 상황을 알려준다.
- 노드 관리 ZooKeeper는 메모리 기반으로 트리 구조의 노드를 가지고 있으며 이들 노드의 정보는 전체 클러스터에서 중요한 메타 정보의 역할을 수행한다. 따라서 운영 중이나 개발 중에 노드의 생성, 삭제 등을 관리하는 작업이 빈번하게 발생한다. ZooKeeper에서 기본적으로 제공하는 관리 기능은 Shell 기반의 명령행으로 관리하기 때문에 한눈에 파악하기도 어렵고 관리가 불편한다. 클라우몬은 탐색기와 같은 구조로 노드의 구조를 보여주고 노드를 쉽게 추가, 삭제, 수정할 수 있는 기능을 제공한다.
- 노드 권한 관리 ZooKeeper의 각 노드는 중요한 메타 정보를 저장하기 때문에 권한 관리가 중요하다. 하지만 명령행 라인으로 권한 관리를 하는 것은 직관적이지 않아 불편하다. 클라우몬에서는 각 노드의 권한 정보를 쉽게 보여주고 노드 생성 시 권한 설정도 쉽게 할 수 있는 기능을 제공한다.
- 노드 Watcher 등록 ZooKeeper는 노드의 자식 노드 생성, 삭제, 수정 등의 이벤트 발생 시 원격에서 등록되어 있는 Watcher를 호출해 주는 기능을 가지고 있다. 이 기능을 이용하여 분산 환경에서 클러스터 멤버쉽, 공유 자원에 락 획득 및 해제 등 중요한 작업을 수행할 수 있는 기능을 제공한다. 이런 기능을 수행하기 위해서 Watcher를 등록하는데 Watcher를 등록하기 위해서 별도의 데몬을 실행해야 하는데 필요할 때 마다 이런 프로그램을 만들어 사용하는 것은 어렵다. 클라우몬은 관리 화면에서 쉽게 지정된 Watcher를 등록할 수 있다, 기본적으로 제공하는 Watcher는 이벤트 발생 시 메일을 전송해주는 MailNotiWatcher가 있으며 Plug-in이 가능하여 사용자가 만든 Watcher를 바로 등록할 수 있다.
Flume 관리
- Flume 클러스터 모니터링 Flume의 Master 서버와 Agent, Collector의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다(일부 기능 제공).
- Data Flow 관리 Flume은 데이터 수집을 위한 솔루션으로 데이터의 소스로부터 저장소까지 일련의 데이터 흐름을 관리하는 것이 중요하다. Flume에서 기본적으로 제공되는 관리 기능에서는 각 단위 데몬에 대한 설정만 가능하고 Data flow 라는 관점에서 관리하는 뷰를 제공하지 않는다. 클라우몬의 Flume Data Flow 관리 기능에서는 하나의 관리 뷰로 데이터 소스, 수집기, 데이터 저장소를 지정하여 관리하는 기능을 제공하여 Agent, Collector의 각 Source, Sink 설정도 chain, fanout을 flow 형태로 정의할 수 있는 화면을 제공한다.
- 다양한 Source, Sink, Decorator 제공 Flume에서 기본적으로 제공되는 Source, Sink, Decorator모듈만으로는 사용자 요구사항에 만족하는 데이터 수집 기능을 구성하는 것은 어렵다. 클라우몬에는 RollingFileTailSource, CheckpointDecorator, MultiSink 등 다양한 Plug-in 모듈을 제공한다.
HBase 관리 - HBase 클러스터 모니터링 Master, RegrionServer의 데몬 상태와 메모리 Heap 사용 상태, 쓰레드 개수 등의 데이터를 관리하는 기능으로 수집된 데이터는 데이터베이스에 저장되어 장애 발생 시 분석 자료로 활용할 수 있다. 각 수집 항목은 1분 주기로 수집되며 수집 데이터가 관리자가 설정한 임계 값보다 큰 값이 수집되면 관리자에게 알람 메시지를 전송한다. 항목의 임계 값은 서버별로 설정할 수 있다.
- HBase Data 관리 HBase에 저장된 데이터를 웹 관리화면에서 조회, 수정, 삭제할 수 있는 기능(향후 제공 예정)
서버 기본 정보 관리 클라우몬은 하둡과 하둡 에코 시스템을 관리, 모니터링하는 솔루션이기 때문에 물리적인 서버 자체에 대한 세부 관리, 모니터링 기능은 제공하지 않는다. 하지만 하둡을 관리하기 위해서는 하둡이 설치되는 서버의 디스크 용량, 네트워크 사용량 등과 같은 기본 정보에 대해서는 모니터링을 수행해야 하기 때문에 물리적인 서버의 기본 정보에 대해서는 모니터링 기능을 제공한다. 다음은 클라우몬에서 관리하는 서버 모니터링 관리 항목이다.
- CPU 사용률, Disk 사용률(파티션 별), 네트워크 In/Out 트래픽, 메모리 사용률
지난 글에서 hadoop 파일시스템의 변화에 대해 간단하게 살펴 보았습니다. 이번 글에서는 mapreduce의 변화에 대해 살펴보도록 하겠습니다.
hadoop 0.23 버전에서의 가장 큰 변화는 YARN 이라고 할 수 있습니다. YARN은 Yet Another Resource Negotiator 의 약자라고 합니다. hadoop은 YARN을 통해 분산 환경에서의 애플리케이션 서버로 진화하려는 시도를 하고 있습니다. 0.23 이전 버전의 mapreduce는 분산된 서버에서 안정적으로 map/reduce task를 실행 관리하는 기능을 수행했다면 YARN에서는 분산된 환경에서 다양한 분산 시스템을 운영할 수 있는 환경을 제공하고 있습니다. 그래서 이름에도 Resource 관리라는 개념을 붙였고요. 따라서 hadopo-0.23 에서의 YARN은 MapReduce 뿐만 아니라 사용자가 쉽게(?) 분산된 작업을 만들어서 실행할 수 있는 환경을 제공하고 있습니다. 즉 분산 애플리케이션 서버의 역할을 수행한다고 할 수 있습니다. 지금 버전에서는 다소 기능이 약하지만 지향하는 방향이 그쪽이라서 버전이 올라갈수록 좋아 질것이라 예상해봅니다.
먼저 YARN에서 MapReduce의 시스템 실행을 보면 다음 그림과 같습니다.
YARN은 ResourceManager와 NodeManager 두 종류의 데몬으로 구성되어 있습니다. ResourceManager는 마스터 서버의 역할을 수행하며 1대의 서버에 실행됩니다. NodeManager는 worker 역할을 수행하며 N대의 서버에 실행됩니다.
ResourceManager 내부에는 Scheduler와 ApplicationManager라는 두개의 메인 컴포넌트로 구성되어 있습니다.
- Scheduler: NodeManager들의 자원 상태를 관리한다. 0.23 버전에서 자원은 NodeManager의 여유 메모리로 관리된다.
- ApplicationManager: 특정 작업을 위한 Master 서버가 되는 Application Master를 실행하고 Application Master의 상태를 관리한다.
여기서 Application Master라는 새로운 용어가 나오는데 YARN에서 실행되는 하나의 작업을 관리하는 마스터 서버를 Application Master라고 부릅니다. MapReduce 작업의 경우 JobTracker가 Application Master입니다.
YARN의 두 데몬과 각 컴포넌트들이 Map/Reduce 작업을 어떻게 실행하는지 위 그림을 보고 간단하게 설명하겠습니다.
ResourceManager의 Scheduler는 NodeManager로 부터 주기적으로 NodeManager의 상태 정보를 수신하여 가용한 리소스 정보를 관리합니다. 사용자 요청(MapReduce 작업 실행)을 받으면 ResourceManager의 ApplicationManager는 Scheduler에게 ApplicationMaster(JobTracker)를 실행시키기 위한 NodeManager를 할당 받은 후 해당 NodeManager에 JobTracker를 실행을 요청합니다. NodeManager는 JobTracker를 fork하여 실행합니다.
JobTracker는 ResourceManager의 Scheduler에게 TaskTracker 실행을 위한 NodeManager 할당을 요청하여 NodeManager 목록을 받습니다. 각 NodeManager에 TaskTracker 실행을 요청하면 NodeManager는 TaskTracker를 fork하여 실행합니다. 이후 부터는 기존의 MapReduce 작업 실행과 동일하게 JobTracker에 의해 스케줄링되고 작업이 TaskTracker에 할당되고 실행됩니다. 작업이 종료되면 JobTracker, TaskTracker 모두 종료됩니다. 기존 버전에서는 JobTracker, TaskTracker는 종료되지 않고 사용자가 실행시킨 Task만 종료되었는데 YARN에서는 JobTracker/TaskTracker 자체가 사용자가 실행시킨 작업이기 때문에 작업이 종료되면 해당 데몬들은 종료시킵니다.
JobTracker가 종료되면 기존의 작업에 대한 로그 정보들이 유실되는데 이를 위해 JobHistoryServer하는 별도의 데몬이 있습니다. 이 데몬을 실행하면 작업 로그는 이 데몬에 의해 관리되고 이 데몬에서 제공하는 웹 UI를 이용하여 작업 history 정보를 볼 수 있습니다.
이렇게 많이 바뀌었기 때문에 기존의 MapReudce 작업은 실행되지 않을까 걱정할 수 있는데 기존의 Map/Reduce 프로그램도 잘 돌아가게 구성되어 있습니다.
YARN에서는 JobTracker/TaskTracker는 하나의 특화된 작업입니다. 개발자는 MapReduce 프레임워크와 같은 분산된 환경에서 작업을 처리할 수 있는 다양한 시스템을 YARN 에서 실행시킬 수 있습니다. 예를 들어 그래프 분석을 처리하는 GoldenORB나 Hama와 같은 프로그램은 각각 리소스 관리 체계, 데몬 관리, 사용자 작업 분배 처리 등과 같은 분산 작업에 필요한 모듈을 모두 새로 개발해야 했었습니다. 하지만 YARN에서는 이런 기능들은 미리 제공하고 있어 별도의 추가 개발할 필요 없이 실행하고자 하는 로직만 처리하도록 구성할 수 있도록 해줍니다.
물론 YARN 환경에서도 새로운 분산 시스템을 만드는 것도 쉬운 작업은 아닙니다. MapReduce 프레임워크만 보더라도 아직 복잡하게 구성되어 있으니까요... 작업의 제어, 장애 시 재시도 등에 대한 것들을 개발자가 직접 모두 만들어 줘야하는 것은 여전합니다.
그러면 YARN의 장점은 무엇일까요? 아직까지 직접 만들어 보지 못했기 때문에 정확하게 말할 수는 없지만 다음 정도로 정리해 볼 수는 있을 것 같습니다.
- Application Master에 대한 장애 관리 제가 본 코드(10월 버전)에서는 아직 이 기능은 들어오지 않았는데 스펙상 지원된다고 하니 정식 버전에는 지원하지 않을까 생각합니다.
- 분산된 서버의 리소스 관리 및 리소스 할당, 반납 - 서버(NodeManager)의 장애 상황 감지 및 통보 - 표준화된 분산 관리 체계 지원으로 정형화된 프로그램 개발 가능 -> 과거에 어렵고 복잡했던 시스템 개발을 표준화된 모습으로 정리 -> 앱스토어 형태의 생태계 구축 가능
현재까지는 이정도 수준입니다.
그리고 0.23의 코드는 거의 새로 만들어진 수준입니다. Map/Reduce 부분의 경우 JobTracker 클래스 자체가 없어졌습니다. 물론 작업의 스케쥴링, TaskTracker의 처리 등내부적으로 Task를 처리하는 기능에 대한 코드는 그대로 사용하고 있습니다. YARN의 구현은 새로운 개념이기 때문에 모두 새롭게 만들어졌는데 State Machine을 사용하여 데몬, 작업 등의 상태 처리와 이 상태 변환에 따른 로직 구현으로 되어 있기 때문에 각각에 대한 State를 이해하는 것이 필수라고 할 수 있습니다.
거의 2년만에 hadoop의 새로운 버전이 나올 예정입니다. 중간에 릴리즈된 0.21, 0.22는 호응을 얻지 못하고 바로 0.23 버전으로 올라갈 예정이라고 합니다. 정식 버전은 2012년 2Q 정도나 되어야 나올 것 같네요... 0.23에서는 기존 hadoop 개념에서 많은 내용들이 변경되었고 코드도 많이 바뀌었기 때문에 지금부터 차근차근 준비하는게 좋습니다. 그래서 몇회에 걸쳐 조금씩 정리해볼까 합니다.
첫번째로 먼저 hdfs의 block pool에 대해서 살펴보겠습니다.
(오해의 소지가 있어 그림을 조금 수정했습니다.) Block Pool 개념은 간단하게 정의하면 DataNode를 Block을 관리하는 데몬으로 사용하고 NameNode는 Block의 메타 정보를 관리하는 데몬 역할을 수행합니다(조금 차이는 있지만 설명을 쉽게 하기 위해). 그리고 DataNode는 하나의 NameNode에만 속하는 것이 아니라 여러 NameNode에 속할 수 있습니다. 각 BlockPool은 하나의 NameNode에만 속할 수 있고 하나의 DataNode에서는 BlockPool 별로 isolation 되어 있어 간섭되지 않는 구조입니다. 그리고 하나의 NameNode에서 관리하는 namespace 영역은 다른 NameNode의 namespace와는 별개로 동작합니다. 즉 통합된 global namespace는 제공되지 않습니다. 이 구조만 보면 NameNode 단위로 볼륨관리를 할 수 있게 하는 기능이 추가되었다고 볼 수 있습니다. 그리고 운영중에 NameNode에 namespace 용량이 모자라면 클러스터 내에 NameNode를 하나 더 실행해서 확장해 나갈 수 있는 방법을 제공하고 있습니다. 하지만 통합된 namespace를 제공하지 않기 때문에 몇개의 NameNode에 있는 디렉토리를 통합해서 보기 위해서는 별도의 프로그램을 구성해야 합니다. 물론 이런 기능도 같이 제공하고 있습니다. 서버단은 아니고 클라이언트 계층에서 ViewFS라는 기능을 이용하여 통합된 뷰로 볼 수 있습니다.
기존 버전 형태로 사용할 경우에는 하나의 NameNode만 실행하면 기존 버전과 동일한 구성으로 실행됩니다.
hive 처음 설치할때 metastore로 그냥 기본으로 제공하는 derby 사용하게 되는데 이럴 경우 동시에 여러명이 작업할 수 없는 문제가 있습니다. derby의 경우 기본은 embedded 라서 한명이 접속하면 파일 lock을 잡게 됩니다. m/r 작업이 여러명이 동시에 할 수 없기는 하지만요. ㅋㅋㅋ 여기서 테이블 만들어서 이것저석 테스트 한 후 이제 본격적으로 사용해봐야지라고 할때 보통 metastore를 mysql, oracle과 같은 db를 사용하는데 마이그레이션 방법에 대한 설명입니다. 주의할 점은 테이블 생성 script에 ORDER, DESC와 같은 컬럼명을 사용하고 있는데 이게 reserved word라서 생성된 script에서는 "ORDER" 이런식으로 되어 있습니다. DBMS에 맞게 적절하게 수정해서 사용해야 합니다.
