jaso extends j2ee

모두들 새해 복많이 받으세요.

2012년 새해 첫 포스팅입니다. 많은 이슈가 되고 있는 빅데이터에 대해 간단하게 제 의견을 정리해 보았습니다. 본문의 내용은 지극히 개인적인 의견일뿐입니다. 잘못된 부분도 있을 수 있고 왜곡된 부분도 있을 수 있습니다. 태클은 댓글로 남겨주세요.

빅데이터 개요
2011년 하반기부터 빅데이터라는 용어가 해외 블로그 또는 저널로부터 나오기 시작했습니다. 국내에서도 이 시기에 언론에서 빅데이터에 대해 관심을 가지면서 관련 기사들이 나왔습니다.
필자는 몇년 동안 Hadoop, NoSQL 등과 같은 분야를 연구하고 있었지만 이런 기술셋들에 대해 정확하게 분류할 수가 없었습니다. 2006년 처음 시작할 때에는 분산컴퓨팅, 그리드 컴퓨팅이라는 용어로 시작했는데 뭔가는 맞지 않는 부분도 있었습니다.
Hadoop의 경우 분산 파일 시스템 분야와 분산 처리 분야에 속해 있고 NoSQL은 분산 데이터 베이스에 속해 있었다고 할 수 있죠. 2008년부터 클라우드 컴퓨팅이라는 새로운 용어가 나오면서 가상화 기술(서버 가상화, 스토리지 가상화 등) 들을 비롯한 여러 기술 분야가 클라우드 컴퓨팅을 구현하기 위한 기술 분야로 묶이게 되었습니다. 이때 Hadoop, NoSQL 등도 클라우드 컴퓨팅이라는 용어로 묶이는 분위기였습니다.
클라우드 컴퓨팅을 구현하기 위해서는 서버 가상화뿐만 아니라 VM 이미지나 VM에 마운트 시킬 수 있는 디스크 또는 스토리지 등의 기술이 필요했으며 사용자의 파일 등을 서비스할 수 있는 오브젝트 스토리지 기술도 필요하게 되었습니다.
또한 이렇게 저장된 데이터를 분석하는 기술도 필요하고요. 데이터베이스도 기존의 하나의 서비스만을 위한 데이터베이스가 아닌 하나의 큰 인스턴스로 여러 업무 여러 사용자에게 서비스하는 클라우드 개념을 지원하는 데이터베이스 기술도 필요하게 되었습니다.
이런 이유 때문에 Hadoop, NoSQL 등이 클라우드 컴퓨팅의 한 기술 분야로 정리되지 않았나 생각합니다.
그래도 이 기술 자체만으로는 클라우드의 개념과는 약간은 거리가 있는 듯한데 2010년말 ~ 2011년에 이르러 이런 기술을 정의 내릴 수 있는 용어가 나왔는데 바로 빅데이터입니다. 기술적인 측면이 아닌 데이터 적인 측면에서도 정의를 하겠지만 빅데이터라는 용어를 등장시킨 결정적인 기술이 Hadoop, NoSQL이 아닐까 생각합니다.

빅데이터 정의
그럼 빅데이터에 대한 정의를 간단하게 내려 보겠습니다. 이것도 클라우드 컴퓨팅이라는 정의와 함께 많이 오해하고 있는 용어 중의 하나인 것 같습니다. 지금까지 제가 살펴본 여러 컬럼이나 문서를 통해 보면 다음과 같이 정의할 수 있을 것입니다.

"빅데이터란 시스템, 서비스, 조직(회사) 등에서 주어진 비용, 시간내에 처리 가능한 데이터 범위를 넘어서는 데이터이다."

정의는 제 주관적인 정의입니다.
위 정의에서 좀 더 자세하게 짚고 넘어 가야 할 부분이 있습니다. 먼저 "처리" 라는 용어입니다. 이 부분이 국내 많은 개발자나 언론, 회사 IT 담당 부서에서 혼동하고 있는 부분이 아닐까 합니다.
"처리"는 단순히 배치 분석 작업을 의미하는 것이 아닙니다. 즉 기존의 BI/DW 등에서의 데이터 웨어 하우스만을 의미하는 것이 아니라는 것입니다. 실시간으로 처리되는 데이터도 같이 포함하고 있는 개념입니다.
예를 들어 국내에서만 서비스되는 쇼핑몰이 있습니다. 이 쇼핑몰은 하루에 수백만명의 제품 검색, 구매 요청을 처리 가능합니다. 이 서비스를 아시아권으로 확대 서비스 했을 때에도 사용자의 요청을 처리할 수 있을까요?
서비스 개발에 조금이라도 아는 사람이라면 안된다는 것을 알 것입니다. 사용자가 늘어나면 사용자의 실시간 검색 요청, 구매 요청 등에 대응하기 위해 여러 부분이 바뀌어야 합니다. 웹 서버의 용량, 네트워크 증설, 세션 처리 용량 등이 필요합니다.
이런 증설에서 가장 중요한 부분이 데이터에 대한 부분일 것입니다. 검색도 데이터에 대한 내용이고 구매한 이력을 저장하는 것도 데이터에 대한 내용입니다. 상품을 추천하는 것도 구매한 정보를 이용하여 분석하여 다시 피드백을 주는 데이터에 대한 내용입니다.
빅데이터에서의 "데이터 처리"의 개념은 이렇게 단순 분석이 아닌 사용자의 모든 데이터 요청 유형을 의미하는 것입니다.
그러면 일반적인 데이터와 빅데이터를 나누는 기준은 무었일까요? 이 부분에 대한 답이 앞에서 정의한 빅데이터 정의 부분에서 "비용/시간"이라고 볼 수 있습니다. 그리고 "비용/시간"은 어떤 기술을 사용할 것인가를 결정하는 요소입니다.
데이터를 처리하는데 있어 기업이 투자 가능한 비용의 범위 내에 있으면 빅데이터라고 하지 않습니다. 예를 들어 하루에 수억건 발생하는 이동통신회사의 콜 데이터를 저장하기 위해 이동통신회사는 수십억 ~ 수백억의 비용을 지불해서 고가의 하드웨어, 고가의 데이터베이스 솔루션에 투자하는 것이 가능하다고 하면 그것은 빅데이터라고 보기 어렵습니다.
현재에도 많은 통신회사가 이런 방식으로 과금 시스템이 구축되어 있습니다. 통신회사가 이렇게 비용을 지불할 수 있는 것은 다루는 데이터가 과금에 사용되는 가장 중요한 데이터이기 때문이겠죠. 이런 중요한 데이터를 저장, 처리하는데 기업들은 기꺼이 비용을 지불할 것입니다.
그러면 동일한 데이터이지만 이렇게 저장된 데이터를 이용하여 과금보다는 조금 덜 중요한 기지국의 증설, 통화 품질 등을 분석하는 자료 중의 하나로 활용하는 경우라면 어떨까요? 그리고 기지국의 증설, 통화 품질 분석 등을 위해서 사용자 콜 정보 이외의 다른 여러가지 부가 정보도 같이 사용되어 진다면 앞에서와 같이 사용자 콜 데이터를 저장, 분석하는데 수십 ~ 수백억의 비용을 지불하면서 시스템을 구축할 수 있을까요?
즉 같은 데이터라도 기업에게 어느 정도로 중요하고 그 중요성 만큼의 비용을 지불할 수 있는 수준을 넘어서는 데이터를 다루는 기술을 빅데이터라고 할 수 있습니다. 과거에도 사용자 콜 데이터를 저장하고 과금 처리를 하고 있었는데 이를 빅데이터라고는 하지 않습니다.
따라서 빅데이터를 다루는 기술은 기본적으로 기존의 데이터 방식에 비해 구축 및 운영 비용이 매우 저렴한 기술이라야 합니다.

빅데이터의 특징을 이야기 할때 다음 세가지 특징을 많이 이야기 합니다.

- volume: 데이터의 크기인데 물리적인 크기 보다는 앞에서 설명드린 크기에 대한 내용입니다. 웹 로그 데이터나 한메일, gmail 등의 메일 MIME 데이터는 수 PB 이상이 되지만 트위터 네트워크 데이터는 수십 GB 미만입니다. 앞의 데이터는 안정적인 저장이 가장 큰 해결 과제인 반면 네트워크 데이터는 분석 및 처리가 가장 큰 이슈입니다. 따라서 단순히 물리적인 크기가 아닌 데이터의 어떤 속성이 더 중요하고 그것을 처리하는데 어려움이 있느냐 없느냐 입니다.

- velocity: 데이터를 처리하는 속도입니다. 정의 부분에서도 설명했듯이 배치 분석만을 의미하는 것이 아닙니다. 필요에 따라서 수 많은 사용자 요청을 실시간으로 처리한 후 처리 결과를 반환해주는 기능도 필요합니다. -
 
various: 전통적인 기업의 데이터 분석은 기업 내부에서 발생하는 운영데이터인 ERP, SCM, MES, CRM 등의 시스템에 저장되어 있는 데이터베이스 데이터 였습니다. 이런 데이터는 잘 정제되어 있고 의미도 명확합니다. 최근에는 이런 데이터뿐만 아니라 기업 외부에서 발생하는 SNS, 블로그, 뉴스, 게시판 등의 데이터나 사용자가 업로드 한 파일, 콜 센터의 고객 상담 내용 등 비정형 데이터도 처리할 수 있는 능력이 있어야 합니다.

그러면 이런 빅데이터는 어떤 회사가 주도하고 있을까요? 지금까지의 소프트웨어는 Oracle, IBM, HP, MS 등과 같은 미국의 소프트웨어 회사 중심이었다면 클라우드 컴퓨팅 이후부터의 기술은 인터넷 서비스 업체인 Google, Yahoo, Facebook, Amazon 등이 주도적으로 이끌고 있습니다.
전통적인 소프트웨어 회사는 그 기술 자체가 회사의 경쟁력이고 판매 되는 상품이었기 때문에 공개되지 않았습니다. 하지만 인터넷 서비스 업체는 기술 자체로 비즈니스를 하는 것이 아니라 그 기술을 이용한 서비스로 비즈니스를 하기 때문에 기술 공개에 있어 자유롭다고 할 수 있습니다.
그리고 이런 회사들이 진정한 빅데이터를 다루고 운영하는 경험이 있는 회사라고 할 수 있습니다. 따라서 빅데이터는 전통적인 소프트웨어 벤더에 의해 만들어진 시장이 아니라 글로벌 인터넷 서비스 업체들에 의해 만들어진 시장과 기술입니다.
 
관련 기술
그러면 빅데이터를 다루는 기술들은 어떤 것들이 있을까요? 빅데이터라는 용어를 이끌어 낸 것도 Hadoop과 NoSQL의 성공에 있다고 볼 수 있기 때문에 가장 중요한 기술은 Hadoop 이라고 할 수 있습니다.
Hadoop 자체는 파일 시스템과 분산 처리 플랫폼이지만 Hadoop을 중심으로 다양한 에코 시스템이 구축되면서 이제 Hadoop은 빅데이터에 있어 산업계 표준이라고 할 수 있습니다.
다음은 빅데이터를 다루는데 필요한 기술입니다.


이런 기술이 필요에 따라 적절하게 도입되어야 빅데이터를 처리할 수 있는 시스템을 구축할 수 있습니다. 언급한 기술 하나하나 쉽지 않은 기술이며 아직 성숙되지 않은 기술도 많습니다. 다행인것은 대부분 오픈소스로 코드가 공개되어 있고 기술이 많이 공개되어 있다는 것입니다.
여러 기술이 있지만 이 중 가장 중요한 기술은 마지막에 있는 어떤 데이터를 분석할 것인가를 정의하고 데이터간의 관계를 찾아서 의미 없는 데이터로부터 의미를 찾아내는 기술이 가장 중요한 기술입니다.
이 기술은 솔루션이 아닌 사람의 기술입니다. 기업이 빅데이터 처리를 도입하는데 있어 닭이 먼저냐, 달걀이 먼저냐라는 논의가 여기서 나오지 않나 생각합니다.
시스템을 구축하는 기업 입장에서는 "무엇"과 "효과"를 알아야만 시스템 도입을 진행할 수 있지만 국내에는 아직까지 데이터 분석을 잘 할 수 있는 전문가는 많지 않습니다. 따라서 기업에게 "무엇"과 "효과"를 명확하게 제시할 수 있는 경우가 많지 않습니다. 그러면 사람을 키워야 하는데 데이터를 다루는 사람을 키우기 위해서는 데이터를 자주 보게해야 하고 데이터를 만지는 것이 쉬워야 합니다.
그러기 위해서는 빅데이터를 처리하는 시스템을 구축해야 하기 하는데 투자를 위해 다시 "무엇"과 "효과"로 돌아오게 되는 겁니다.

시스템 구축 방안
빅데이터 시스템 구축에 있어 어려움은 시스템 구조가 너무 복잡하다는 것 입니다. 앞에서의 기술에서 보듯이 하나의 솔루션으로 구축되는 것이 아니라 여러 개의 솔루션이 조합되어야 하고 요구사항에 따라 솔루션 선택도 달라지게 됩니다.
일반적으로 운영조직은 복잡한 시스템 구성을 좋아하지 않습니다. 이유는 당연히 운영의 어려움(비용증가)와 장애때문일 것입니다.
과거에 전통적인 시스템은 주로 웹서버(Apache), 애플리케이션서버(Tomcat, JBoss, Weblogic), 데이터베이스(Oracle, MSSQL, MySQL) 등의 구조로 시스템이 구축되어 운영이나 장애 발생에 쉽게 대응할 수 있었습니다.
하지만 빅데이터를 다루기 위해서는 이런 단순한 구조로 시스템을 구축할 수 있다는 생각을 버려야 합니다. 앞에서 설명했듯이 "무엇"과 "효과"에 대해서는 잘 모르겠고 전문가(시스템, 데이터 분석 모두)도 부족한 상황입니다.
구축 하고자 하는 시스템의 복잡도는 과거의 시스템에 비해 비교도 안될 정도 복잡합니다. 기술도 어렵고 전문 기술 지원 회사도 부족합니다. 글로벌 솔루션 회사들의 솔루션은 대부분 고가의 솔루션으로 빅데이터라는 정의에 부합되지 않습니다. 그러면 어떻게 시스템을 구축하고 전문가를 키워나갈 수 있을까요?
다음은 필자가 생각하는 빅데이터 시스템을 구축할 수 있는 최적의 방안입니다.


방안의 핵심은 쉬운것부터, 욕심을 버리고, 지속적으로 할 수 있는 체계를 갖추는 것입니다. 이렇게 하기 위해서는 기업 내부에서 투자를 결정하는 의살결정권자의 전폭적인 지지와 관심이 있어야만 가능합니다.
기존의 방식처럼 특정 사업부에 맞기고 그 사업부의 임원의 성과로만 치부해버리면 단기간의 화려한 성과에 매달리게 되고 주변의 도움도 받지 못하게 됩니다. 가능하면 CEO 또는 CTO 직속으로 조직을 두고 여러 사업부에 영향력을 행사할 수있는 임원급에게 업무를 할당하는 것이 성공의 첫 단추입니다.
전사적인 부서로 두어야 하는 필요성 중의 하나는 여러 부서로부터의 데이터를 수집해야 하고 처리된 결과를 다시 필요로 하는 부서로 제공해야 하기 때문이기도 합니다.

그 다음은 내부에 엔지니어링 조직을 갖추는 것입니다. 많은 기업이 IT 관련 부분은 아웃 소싱으로 처리하고 있습니다. 빅데이터는 한번의 프로젝트로 완료되는 것이 아니라 지속적으로 운영, 개선해나가야 하는 것이 가장 중요하기 때문에 내부에 엔지니어링 조직을 갖추는 것이 가장 좋습니다.
물론 비용이 많이 든다고 생각할 수도 있지만 회사의 규모에 따라 다르겠지만 앞에서 언급한 기술을 유지하는 수준이라면 뛰어난 인력 3 ~ 5명 정도를 핵심으로 구성하고 필요에 따라 아웃소싱할 수 있습니다.
문제는 3 ~ 5명의 팀을 제대로 구성하기 위해서는 전통적으로 지급되었던 급여 수준보다는 높은 수준의 급여를 지불해야 할 것입니다. 그 수준에 맞는 인력을 채용해야 합니다.
자체 엔지니어링 팀 구성이 어려우면 아웃소싱이 대안이 될 수 있습니다. 아웃 소싱의 경우에도 앞에서 높은 기술력을 유지하고 있는 회사를 소싱해야 하며 엔지니어링 분야 뿐만 아니라 데이터 분석 분야도 같이 다룰 수 있는 회사를 소싱해야 합니다.
그리고 지속적인 관계를 유지할 수 있는 회사라야 할 것입니다.

데이터 특성을 고려한 시스템
빅데이터 시스템을 구축하는데 있어 한가지 더 중요하게 생각해야 될 점은 "데이터의 특징에 맞는 시스템을 구축해야 한다"라는 것입니다.
일반적으로 데이터의 특징은 다음과 같습니다.

- Consistency 저장된 데이터는 모두에게 같은 데이터가 보여야 한다.
- Availability 언제든지 데이터를 저장/조회할 수 있어야 한다.
- Durability 저장된 데이터는 안정적으로 저장되어야 한다.

현재의 데이터 저장 솔루션(DBMS)은 이런 속성을 잘 만족시키고 있습니다. 그렇기 때문에 고가인 것입니다. 빅데이터 처리에 있어서도 반드시 이 속성을 만족해야 하는지 검토해 봐야 합니다.
페이스북 서비스를 보면 Consistency는 일부 포기하고 있습니다. 내가 쓴 글이 나에게는 보이는데 내 친구에게는 일정 시간 내에는 안보이는 경우도 있습니다. 이것은 서비스 측면에서 Consistency보다는 다른 속성을 더 중요하다고 판단했기 때문에 Consistency 속성을 일부 희생한 것입니다.
국내 서비스 기획자나 의사 결정권자는 절대 받아들이지 않을 속성일 것입니다. 하지만 이제 변해야 합니다. 페이스북이 Consistency 속성을 버린 이유는 그 속성을 유지하는 것보다는 그 속성을 일부 희생하더라도 10억명의 사용자 글을 받아주는 기본 기능이 더 중요했기 때문일 것입니다.
이렇듯 구축하고자 하는 시스템에서 중요하게 생각하는 속성이 무엇인지를 정의하고 그것에 따라 시스템을 구축해야 합니다. 모든 속성을 다 만족하고 몇억명의 사용자에게 서비스되고 안정적으로 운영되는 시스템을 구축하기를 원하는 의사결정권자의 바램은 바램일뿐입니다. 현재의 기술로는 불가능하다고 할 수 있습니다.
중요한 하나를 취하고 덜 중요한 하나를 버리는 의사결정이 필요한 시대입니다.

결론
마지막으로 빅데이터 시스템을 구축하는데 있어 중요한 몇가지를 정리 했습니다.


많은 연구기관에서 2012년에 떠오르는 기술중의 하나로 빅데이터를 꼽고 있습니다. 기업의 경쟁력을 높이는 방법 중의 하나로 데이터 분석의 시대가 오고 있는 것은 사실이지만 쉽지 않은 기술임에는 틀립없습니다.
이런 분위기를 글로벌 소프트웨어 업체들이 편승해서 자사의 솔루션 판매에 열을 올리고 있습니다. 물론 이런 솔루션이 도움은 줄 수 있을 겁니다. 기업에서 고민하는 운영이나 기술 지원의 문제도 어느 정도는 해결해 줄 수 있을 겁니다. 하지만 데이터의 시대에서는 그 어떤 시스템보다도 데이터 그 자체에 대한 이해가 가장 중요하며 이것은 쉽게 얻을 수 있는 것은 아니라는 사실은 반드시 기억해 주시기 바랍니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

2011년 마지막 포스트입니다. 2011년 시작하면서 세웠던 목표를 다 이루지는 못했지만 그래도 성장은 했습니다. 새로운 일을 하면서 그동안 겪어 보지 못한 다양한 경험(?)들도 겪으면서 개발자로써 롱런할 수 있는 토대를 하나씩 만들어 나가고 있습니다. 아쉬웠던 한해를 뒤로 하고 내년에는 더 큰 걸음으로 걸을 수 있도록 열심히 하겠습니다. 저를 아시는 모든 분들 새해 복많이 받으시고 건강하세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

www.jaso.co.kr 도메인이 내일(12/17)이면 10년이 됩니다.


블로그를 통해 많은 분들과 소통하고 기술을 정리하면서 엔지니어로써 부족한 부분이었던 글쓰기 역량과 기술에 대한 의견을 정리하는 방법을 많이 배웠던 것 같습니다. 트위터, 페이스북 등 새로운 서비스의 사용으로 인해 블로그를 이용한 소통의 역할은 점점 줄어들고 있지만 컨텐츠 그 자체를 가지고 소통하는 공간으로는 제 역할을 다 하고 있다고 생각합니다. 제가 60세가 되어도 이 도메인으로 여전히 기술에 대해 토론하고 있었으면 하는 바램입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

지난주 토요일(12/3) 제1회 Korea Community Day에서 발표한 내용입니다.

http://www.slideshare.net/babokim/big-data-20111203

출처는 반드시 남겨주세요.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

지난 글에서 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.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

거의 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만 실행하면 기존 버전과 동일한 구성으로 실행됩니다.

오늘은 여기까지 입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

얼마전 oracle에서도 nosql을 공개했습니다. 소스 공개는 아니고 바이너리 형태로 공개했습니다.
http://www.oracle.com/technetwork/database/nosqldb/overview/index.html

오라클 NoSQL은 로컬 저장소로 berkeley db java edition을 사용하며 데이터 분산 및 복제를 지원하고 있습니다. 따라서 N대의 서버에 로컬 디스크를 이용하여 안정적으로 데이터를 서비스할 수 있습니다.
데이터 모델은 단순 key/value 모델을 약간 확장한 형태로 key를 복합키 형태로 줄 수 있습니다. 여러개의 값을 키로 지정할 수 있어서 조회시에도 동일 키 값을 가지는 데이터를 한번에 가져올 수 있는 구조로 되어 있습니다. 다만 기대하신 분들도 있을텐데 관계형 모델도 아니고 테이블 기반도 아니기 때문에 SQL은 지원하지 않습니다.

어느 정도의 성능을 나타낼지 잠깐 테스트를 수행해 보았습니다. 테스트 환경은 다음과 같습니다.

- 테스트 서버: 4대, quad core * 1, 16GB RAM
- nosql instance는 기본 JVM heap 설정
- replica factor: 2, replica group: 2
- 테스트 클라이언트: 3대(별도의 서버), 각 서버당 10개 쓰레드
- 저장 데이터는 random key 20 bytes, data 1024 bytes
- replica 전략: Durability.ReplicaAckPolicy.SIMPLE_MAJORITY 사용

다음은 테스트 결과 입니다.(그래프는 전체 서버에 대한 그래프입니다)
 - write(SYNC)

- write(Master SYNC, Slave NO_SYNC)
- read
- 결과 분석
   . SYNC 옵션을 주면 미디어(하드 디스크)까지 데이터를 저장하는 옵션이기 때문에 성능이 느려짐.  Latency가 20ms 정도. 따라서 TPS도 높지 않음(1500TPS 정도,  Replica 그룹당 700TPS 정도)
  . Master SYNC, Slave NO_SYNC로 할 경우  Latency는 0.x ~ 1ms 정도이며 TPS는 15,000 정도. 대신 주기적으로 sync 처리할 때 중간 중간 latency가 급격하게 올라가는 구간이 있음
  . read의 평균 latency는 수 ms 수준으로 그다지 빠르지 않음

- 몇가지 주의 사항이 있습니다.
   . 한번 정의된 클러스터는 변경할 수 없다 -> 향후 버전에서 지원한다고 하네요.
     즉 서버 10대에 replica factor 2로 하면 shard(replica group)은 5개로 분리되고 이것으로 계속 서비스
   . 서버간 타임 동기화(2초 이상 지연이 발생)가 되지 않으면 서버 시작이 안됨

이상 간단하게 테스트 해본 내용입니다. 다르게 테스트해보신 분들도 공유해주시면 감쏴...
제가 테스트한 다른 솔루션 성능 테스트 글은 다음 참고
- 카산드라: http://www.jaso.co.kr/426(좀더 최근 내용은 http://charsyam.wordpress.com/2011/11/13/aws%EC%97%90%EC%84%9C-cassandra%EC%9D%98-%ED%99%95%EC%9E%A5%EC%84%B1-%EB%B2%A4%EC%B9%98%EB%A7%88%ED%82%B9-%EC%B4%88%EB%8B%B9-%EB%B0%B1%EB%A7%8C-write-%EB%84%98%EA%B8%B0%EA%B8%B0/)
- Hbase : http://www.jaso.co.kr/411(이거는 버전이 옛날 거라서 잘 안맞을 수도...)
- Mongodb: http://www.jaso.co.kr/416

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

hive 처음 설치할때 metastore로 그냥 기본으로 제공하는 derby 사용하게 되는데 이럴 경우 동시에 여러명이 작업할 수 없는 문제가 있습니다. derby의 경우 기본은 embedded 라서 한명이 접속하면 파일 lock을 잡게 됩니다. m/r 작업이 여러명이 동시에 할 수 없기는 하지만요. ㅋㅋㅋ
여기서 테이블 만들어서 이것저석 테스트 한 후 이제 본격적으로 사용해봐야지라고 할때 보통 metastore를 mysql, oracle과 같은 db를 사용하는데 마이그레이션 방법에 대한 설명입니다.
주의할 점은 테이블 생성 script에 ORDER, DESC와 같은 컬럼명을 사용하고 있는데 이게 reserved word라서 생성된 script에서는 "ORDER" 이런식으로 되어 있습니다. DBMS에 맞게 적절하게 수정해서 사용해야 합니다.

http://search-hadoop.com/m/J15J0FwAg1/v=plain

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

최근 클라우드 컴퓨팅이라는 키워드를 넘어 이제는 BigData 분석이라는 용어가 난무하고 있습니다. 흔히 BigData 분석이라고 하면 아주 크기가 큰 데이터를 저장 및 분석하는 것을 의미합니다. 하지만 실제로 BigData에는 3V(Volume, Various, Velocity) 가 포함되어 있습니다. Various는 다양한 데이터 타입을 의미하고 Velocity는 분석의 속도를 의미합니다.
BigData 분석을 위해서는 데이터의 수집, 저장, 분석, 분석 결과 저장, 분석 결과 제공 등 데이터를 관리하는 모든 컴포넌트가 일련의 데이터 흐름에 대해 처리할 수 있는 체계가 만들어져야 합니다.

이번에 그루터에서 서울시장 보궐선거와 관련하여 트위터 상에서 서울시장 후보와 관련된 정보를 분석하는 페이지를 만들었습니다. http://www.seenal.com 입니다.
이 사이트를 위해서 BigData 처리 기법을 적용해 보았습니다. 주로 적용된 솔루션은 다음과 같습니다.

- 트위터 데이터 수집: 자체 개발 모듈
- 데이터 원본 저장: Hadoop FileSystem
- 데이터 원본 구조화된 저장소: Cloudata (자체 개발 NoSQL, http://www.cloudata.org)
- 데이터 검색: ElasticSearch
- 수집 -> 분석용 저장소(HDFS)로 수집: Flume
- 실시간 분석: 자체 개발
- 실시간 분석 결과 저장소: MongoDB
- 배치 분석: Hive
- 배치 분석 결과 저장소: MongoDB

저희 클러스터의 장비가 좋지 않아서 데이터 원본 저장소와 분석용 저장소를 구분한 이유는 분석 작업이 실행되면 원본 저장소의 성능이 급격하게 저하되기 때문에 원본 저장과 동시에 flume을 이용하여 분석용 저장소로 데이터를 계속 복제 시켜 처리하고 있습니다.
기타 자세한 내용은 다음 세니마 때 공개하도록 하겠습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준

삽집끝에 hadoop-0.23 hdfs 하고 yarn 실행했습니다. 성공 기념 관리화면 인증샷

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준