[Cloudera 블로그 번역] 왜 우리들은 HDFS상에 플랫폼을 구축하는가

 

일어 원문 : http://www.cloudera.co.jp/blog/why-we-build-our-platform-on-hdfs.html - 일본 Cloudera Blog

영어 원문 : http://blog.cloudera.com/blog/2012/07/why-we-build-our-platform-on-hdfs/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 본 글은 Cloudera Cloudera 프로덕트 바이스 프레지던트인 Charles Zedlewski가 쓴 글을 번역한 것입니다.

 

 Hortonworks의 E14와 같은 의견을 가질 기회는 좀처럼 없습니다만, 그의 최근 블로그 글은 그 절호의 기회를 가져다 주었습니다. 저는 E14가 지적한 부분 중 몇 가지를 토대로 저의 의견을 추가하려 합니다.

 

 최근 GigaOm의 기사에서 HDFS를 대체하는 8개의 제품이 소개 되었습니다. 그들은 실제로는 그 외에도 적어도 4개 제품을 소개하지 않았습니다. 1년 이상에 걸쳐 ParaScale은 HDFS의 대체로 자사제품을 판매하였습니다. (Hitachi(히타치)에 자산을 매각하기 전까지). Appistry는 HDFS의 대체품을 계속 판매하고 있습니다. 아직 릴리즈 되었는지 안되었는지는 모르겠지만, Symantec(시만텍)의 Veritas 부문도 HDFS를 대체하는 클러스터 파일 시스템(CFS)를 제안하고 있는 것은 명백합니다. HP Ibrix는 여러 해 전부터 HDFS API를 지원하고 있습니다.

 

 GigaOm의 기사가 의미하고 있는 것은, 대체물을 추진하고 있는 12개의 다른 벤더의 존재는 HDFS의 어떤 결함을 지적해야만 한다는 것입니다. 그 외에 누가 그런 지적을 하겠습니까. 이건 정말 틀린 결론입니다. 저는 이 일에 대해 묻고 싶습니다.

 

 우리들은 아래의 사실에서 어떤 결론을 끌어낼 수 있을까요.

  • 12종류의 파일 시스템은 HDFS의 대체로써 자기자신을 홍보하고 있습니다.
  • 12개의 대체품 대부분은 HDFS보다도 6~14년 더 긴 역사를 가지고 있습니다. (시장에 오래 남아있다는 것은 그것들에 우세한 부분이 있다는 것을 의미하는 것이겠지요)
  • 하지만 HDFS는 다른 대체품을 압도할 정도의 엔터프라이즈 데이터(수백 페타바이트)를 저장하고 있습니다.
  • HDFS는 대규모 벤더 지원 (Cisco, Dell, HP, IBM, NetApp, Oracle, SAP, SGI, SuperMicro)의 광범위한 기반을 가지고 있습니다.

 저희 Cloudera는 HDFS가 데이터 매니지먼트 업계 표준으로써 이들 레거시 파일 시스템을 한창 압도하고 있다고 결론 내렸습니다.

 

 실제로 저희는 전에도 비슷한 스토리를 봐왔습니다. 20년전으로 돌아갈 수 있다면, 우린 비슷한 상황을 떠올릴 수 있겠죠. 그 때의 시장에는,

 

  • 12 이상의 선택지가 있었습니다. 그것들은, AIX, HP-UX, Solaris, Seequent, Darwin, BSD, SCO, Unixware 등으로 불리고 있었습니다.
  • 모든 대체품은 아주 먼 옛날에 기능 포화 상태에 이르렀고, 엔터프라이즈 마케팅 담당자는 이를 감추려고 고심하고 있었죠. 쓸데없는 질문일 수 있겠습니다만, SCO와 OpenBSD 사이의 기능적 차이를 기억하고 계십니까?
  • 그들은 종종 독자적인 고가의 하드웨어에 밀접하게 결합 시켰습니다.
  • 그런 단편화는 한 번의 R&D 사이클로 폭넓은 시장을 타겟으로 하는 어플리케이션 개발자와 하드웨어 제조업자에게 있어서는 악몽이었습니다.

 이 상황은 Linux의 점화를 기다리는 화약 창고와 같은 것이었습니다. Linux가 성숙해 지고 인기가 늘어남에 따라 많은 Unix 벤더가 유행과 맞서 싸우려고 했습니다. 많은 마케팅과 PR 비용은 운영 시스템의 새로운 것에 대한 공포, 불확실성, 의문을 만들어 내기 위해 쓰여졌습니다. 하지만 이 일은 헛되이 끝났고, 시간이 지남에 따라 Linux는 IT 업계에 매우 큰 임팩트를 주게 되었습니다. Linux가 모든 하드웨어 벤더에게 공평한 경쟁의 장을 만들어줌에 따라 하드웨어 비용 절감으로 이어지게 되었습니다. Linux가 플랫폼의 단편화를 줄여줌에 따라 보다 많은 어플리케이션 도입으로 이어졌습니다. 그리고 또 Linux는 호환성을 확보하기 위해 소프트웨어, 하드웨어, 디바이스 제조업자가 Linux에 공헌하게 되는 공유 R&D 시스템으로 이어져 나갔습니다.

 

 HDFS 단편화, 과도한 마진, 수상한 도구의 불필요한 기능에 대한 답답한 마케팅에 지쳐 있던 고객들의 시장에 Linux 같은 역할로 뛰어 나갈 준비가 되어 있습니다. 오늘날도 아직 독점적인 Unix 운영 시스템은 넓게 사용되어 오고 있습니다. 독점적인 파일 시스템에 대해서도 분명 같은 얘기를 있을 것입니다. 오래된 제품은 죽지 않습니다, 단지 관련성을 잃을 뿐인 것입니다.

 

 Eric HDFS 경제성, 데이터 처리의 대역폭과 신뢰성을 강조하였습니다. 기능 레벨에서는 우수한 보안, 내장애성, 고가용성 (그렇습니다, 이것은 SPOF 문제를 해결해 줍니다. CDH4 다운로드는 여기서!) 추가합니다. HDFS 제공하는 엔터프라이즈 고객용 기능보다도 아마 중요한 것은,

  • 선택 - 고객은 임의의 거대 하드웨어 벤더와 협력하여 가능한 한 최적의 비용으로 손에 넣을 수 있습니다. 결정권은 고객에게 있는 것으로, 벤더가 번들로 하기로 결정한 것이 아닙니다.
  • 이식성 - 고객은 클러스터 재포맷이나 대량 데이터를 복사할 필요 없이 HDFS 기반의 Hadoop 분산에서 다른 HDFS 기반의 분산으로 옮길 수 있습니다. 만약 페타바이트 데이터를 가지고 있을 경우, 이런 이식성은 매우 중요합니다. 만약 이식성이 없다면, 다음 리뉴얼 교섭 때, 벤더는 믿기 어려울 정도의 힘을 가지게 됩니다.
  • 공유의 업계 R&D - 저희는 Cloudera에서 개개인의 사원에 의한, HDFS에 대한 개별 공헌을 자랑스럽게 생각합니다. 우리는 모두 Hortonworks의 동업자들과 협력하고 있습니다. 하지만 오늘날에는 IBM, 마이크로소프트, VMWare가 각 회사의 제품을 향상시키기 위해 HDFS에 공헌하고 있는 것을 발견할 수 있겠죠. 이 후에는 하드 드라이브, 네트워크, 서버 등의 벤더도 자사의 제품이 HDFS에 최적화 가능하도록 HDFS에 패치를 추가할 것으로 저는 예상하고 있습니다.

 역사가 완전 같은 방식으로 반복되는 일은 매우 드문 일로, 이건 HDFS에 대해서도 마찬가지 입니다. 오늘날 HDFS는 컨텐츠용 스토리지(Content Addressable Storage)나 니어 라인 아카이브(nearline archive)로써는 최적의 파일 시스템이 아닐지도 모릅니다. 하지만 Linux가 노트북이나 라우터(네트워크에서 데이터의 전달을 촉진하는 중계 장치), 휴대폰이나 공항의 키오스크 단말에 사용되는 등의 일을 15년전에 누가 상상이나 했을까요?

 

 Linux는 우리에게 지도를 그려주었습니다. 현명한 투자가는 이미 뒤따라오고 있습니다.

 

관련 글

 

 CDH4.1의 컬럼 베이스 저널링 (일어 원문사이트)

 

 MR2와 YARN에 대한 짧은 해설 (한국어 번역글)

 

 Cloudera 5주년! (일어 원문사이트)

 

 

Posted by 이슈타르네스
TAG cloudera, HDFS

[Cloudera 블로그 번역] MR2와 YARN에 대한 짧은 해설

 

일어 원문 : http://www.cloudera.co.jp/blog/mr2-and-yarn-briefly-explained.html - 일본 Cloudera Blog

영어 원문 : http://blog.cloudera.com/blog/2012/10/mr2-and-yarn-briefly-explained/ - 미국 Cloudera Blog

 

- 본 글은 위 일어 원문 링크의 글을 번역하였습니다.

- 일어 원문 글은 위 영어 원문 글을 번역한 글입니다.

 


 

 

 MapReduce에 대해 배울 수 있는, Cloudera 개발자 트레이닝

본 글은 Cloudera 커스터머 오퍼레이션즈 엔지니어 Harsh Chouraria가 쓴 글을 번역한 것입니다.

 

 CDH4 이후, Apache Hadoop의 컴포넌트는 Hadoop 사용자에 대응하여 두 가지 새로운 용어를 도입했습니다. MR2와 YARN입니다. 아쉽게도 이 용어들은 혼동되어 있어 많은 사람들이 혼란스러워하고 있습니다. 두 개는 같은 의미일까요, 다른 의미일까요?

 

 본 글은 이들 두 가지 용어를 명확하게 하는 것이 목표입니다.

 

YARN이란?

 

 YARN은 "Yet-Another-Resource-Negotiator"를 의미합니다. 이것은 임의의 분산처리 프레임워크나 어플리케이션의 작성을 쉽게 만드는 새로운 프레임워크입니다.

 

 YARN은 범용적인 분산어플리케이션 개발이나, 그런 어플리케이션에서 오는 (메모리나 CPU와 같은) 리소스 요구의 핸들링, 스케줄링을 실시하여, 실행을 감독하기 위한 데몬과 API를 제공합니다.

 

 YARN의 실행 모델은 이전의 MapReduce 구현보다도 범용적인 것입니다. YARN은 오리지널 Apache Hadoop의 MapReduce (MR1이라고도 부름) 와는 달리, MapReduce 모델에 따르지 않는 어플리케이션을 실행할 수 있습니다.

 

MR2란?

 

 YARN의 출현으로, 잡을 실행하는 단일의 JobTracker와 잡 태스크를 실행하기 위한 TaskTracker는 이제 사용할 수 없습니다. 기존 MR1의 프레임워크는 YARN상에 서밋(submit)된 어플리케이션 안에서 실행되도록 고쳐 쓰여졌습니다. 이 어플리케이션은 MR2 혹은 MapReduce 버전2로 이름 붙여졌습니다. 이것은 실행플로우 (예를 들면 태스크 스케줄링이나, 투기적 실행(speculative execution)의 핸들링, 장애처리 등)를 살피는 ApplicationMaster를 경유하여 각 잡이 자신의 운명을 컨트롤하는 경우를 빼고는, 실은 많이 봐온 MapReduce 실행입니다. 이것은 단일의 JobTracker가 모든 리소스 관리, 스케줄링, 태스크 감시 작업을 실행하는 MR1과 비교하여 보다 분리되어 있고 확대축소 가능한(scalable) 모델입니다.

 

 MR2와 DistributedShell이라 불리는 새로운 컨셉을 실증하는 어플리케이션은 CDH4의 YARN API를 사용하는 최초의 두 가지 어플리케이션입니다.

 

요약

 

 YARN이 어떤 형태의 분산 어플리케이션이라도 실행할 수 있는 범용적인 플랫폼인 반면, MR2는 그 중 하나의 어플리케이션으로 YARN상에서 동작하는 MapReduce 프레임워크입니다. 이 주제에 관한 보다 많은 내용은 여기를 확인 해 주세요.

 

 

관련 글

 

 CDH5와 Cloudera Manager 5가 릴리즈 되었습니다! (일어 원문사이트)

 

 Spark 활용하기 : 빅데이터 어플리케이션용 고속 인메모리 컴퓨팅 (한국어 번역글)

 

 왜 우리들은 HDFS상에 플랫폼을 구축하는가 (한국어 번역글)

 

 

Posted by 이슈타르네스
TAG cludera, mr2, yarn