Tags

엔터프라이즈 플랫폼을 위한 하둡의 현재 위치 및 발전 방향 (summary of Hadoop summit 2014)

This article is based on Hortonworks Partner Content and Expertise

이번 하둡 서밋 2014는 여러 가지 의미를 가지고 있습니다만 개인적으로는 드디더 하둡이 엔터프라이즈 데이터 허브로서 적용될 수 있는 프레임워크를 완성했다는 것에 두고 싶습니다.

먼저 호튼웍스의 키노트 영상을 먼저 보겠습니다.

다양한 사례들과 하둡의 향후 모습에 대해서 미리 엿볼 수 있습니다만 그 중에서도 뒤쪽에 있는 ‘Hadoop Innovation’이라는 부분에 주목을 하는 것이 좋을 듯 합니다.

하둡에 대해서 많은 얘기들이 나오고 있지만 아직은 하둡 1.0의 패러다임과 하둡 2.0의 새로운 진화가 공존하고 있는 상황으로 보입니다.
하둡 2.0이 ‘빅데이터 저장 및 관리’ 와 ‘빅데이터 처리’의 두 가지 관점에서 어떻게 변했고 앞으로 어떻게 변해갈 것인지 이해하는 부분이 중요해 보입니다.

더이상 하둡은 하둡파일시스템과 배치 처리를 위한 맵리듀스가 결합된 단일 목적의 빅데이터 처리 플랫폼이 아니라 다양한 어플리케이션이 공통의 저장 패러다임을 공유하면서 목적에 맞게 다양한 데이터 처리 방식을 수용하는 플랫폼이 되었다는 것에 대해 인사이트를 얻을 수 있을 것입니다.

hadoop_second

현재까지 진행된 상황을 한 페이지로 요약한 다이어그램입니다.

- 데이터 관리
- 데이터 접근(Access)
- 거버넌스(Governance) 와 연동 혹은 통합(Integration)
- 보안
- 운영 (Operations)

5가지의 핵심적인 요소들이 이 블로그에서 소개드린 다양한 에코시스템의 통합을 통해서 지원하는 수준으로 발전했습니다.

그리고 그 동안 하둡이 엔터프라이즈에 적용되면서 나왔던 니즈들을 어떻게 수용하게 되었는 지도 한 번 검토해 볼 필요가 있습니다.

hadoop_third

먼저 데이터 관리의 측면에서 하둡의 새로운 아키텍쳐가 어떻게 기업의 니즈를 수용했는 지에 대한 개요입니다.
그 동안 많은 요구가 있었던 안정성 측면에서 이른바 ‘FullStack HA’구성이 가능해 진 점과 멀티 데이터센터의 DR(Disaster Recovery)를 수용하게 되었다는 점에 주목하시면 좋을 듯 합니다.

hadoop-yarn

많은 기사를 통해서 소개드리고 있는 데이터 접근 측면의 변화입니다.
아마도 기존의 하둡의 접근과 완전히 달라졌기 때문에 혼란이 많이 있는 영역이지만 이제는 YARN(Yet Another Resource Negotiator)의 도입으로 기존에 맵리듀스의 배치처리 방식 뿐만 아니라 Batch, Interactive, Realtime, Streaming의 네가지 주요 데이터 처리 방식을 모두 지원하게 되었습니다.

YARN은 하둡 클러스터의 전체 리소스를 관리하는 시스템으로서 각 어플리케이션에 필요한 리소스를 할당하고 모니터링하는 업무에 집중함으로써 다양한 어플리케이션이 하둡 클러스터의 리소스를 공유할 수 있도록 탈바꿈하게 만든 핵심 요소입니다.

그 외에 기업 환경에 적용하는 데 핵심적인 보안 및 운영 관리의 측면에도 기업 니즈를 반영함으로써 엔터프라이즈 데이터 허브에 적합한 플랫폼을 갖추게 되었습니다.

hadoop-streaming

일례로 스톰(Storm) 어플리케이션이 YARN 위에서 돌아가면서 기존의 배치 처리와 상반되어 보이는 머신로그, 센서로그, 서버로그 등의 스트리밍 데이터를 실시간으로 처리하는 기반이 완성되었습니다.

저희도 많은 관심을 갖는 분야이고 지속적으로 소개해 드리고 있습니다.

hadoop-storage

그리고 기존의 하둡의 이미지라고 할 수 있는 로컬디스크가 달린 서버를 균등하게 연결하는 시스템도 기업의 니즈에 의해 변모했습니다.
바로 전의 기사에서 소개드린 것처럼 메모리, SSD 스토리지, 하드디스크 등의 기업 현장의 스토리지를 충분히 이용하는 방향으로 발전이 이루어 지고 있습니다.

hadoop-slide

하지만 가장 주목해야 할 부분은 바로 ‘Others’입니다.
한국에도 많은 기업용 솔루션을 기존에 개발한 회사들도 있고 운용 중이지만 이러한 솔루션을 어떻게 빅데이터를 처리할 수 있도록 할 것인가는 아주 실질적인 문제이고 중요한 문제입니다.

이제는 기존의 어플리케이션을 직접 하둡 클러스터에 적용되어서 빅데이터 솔루션으로 변모하기 위한 프레임워크인 슬라이드(Slide)의 발표가 있었습니다.
참고로 호튼웍스에서 NoSQL을 YARN에서 바로 동작하는 샘플을 발표했으니 함께 검토해 보시기 바랍니다.

전체적으로 빅데이터 시대를 위한 가장 비용 효율적이고 범용적인 플랫폼이 등장했다는 인사이트에 집중해서 보시면 좋을 듯 합니다.

———————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
———————————————————————————————————–

실시간 하둡의 기반 스톰(Storm)의 컨셉과 적용 방법 (The concept of realtime hadoop with storm)

This article is based on Hortonworks Partner Content

그 동안 실시간 처리 시스템 혹은 리얼타임 시스템으로서의 하둡에 대해서 여러 가지 기사를 통해서 소개를 드렸습니다.
엔터프라이즈 레벨 실시간 시스템의 최강 조합 (하둡 + 인메모리 데이터베이스)
리얼타임 하둡의 가능성
실시간 하둡 데모와 간단한 테스트 코드

이상의 글에서 설명드렸던 것처럼 YARN(Yet Another Resource Negotiator)의 도입으로 기업이 데이터를 어떤 방식으로 처리할 것인지의 니즈에 맞춰서 처리 방식을 배치, 인터랙티브 SQL, 온라인, 스트리밍 등 다양하게 적용할 수 있도록 진화되었습니다.
그 중에서도 스트리밍 되는 대량의 이벤트를 실시간으로 처리하는 시스템은 하둡의 가능성을 극적으로 높혔다는 것에 대부분 동의할 것으로 생각합니다.

센서나 각종 서버 등에서 발생하는 대량의 이벤트 로그는 그 데이터 포맷이 정형화되어 있지 않다는 점과 대량으로 발생한다는 두 가지 측면에서 하둡을 합리적인 옵션으로 고려할 만한 결정적인 이유를 만들고 있습니다.
그래서 이러한 실시간 처리 시스템을 가능하게 하는 스톰(Storm)의 컨셉과 설계할 때 어떤 부분에 주안점을 두었는 지를 좀 더 자세히 살펴 보려고 합니다.

스톰-YARN의 결합은 하둡클러스터에서 하둡 파일시스템(HDFS)뿐만 아니라 HBase의 리소스도 함께 사용할 수 있게 해 주기 때문에 실시간 시스템을 어떻게 적용할 지에 대해서 많은 유연성을 제공합니다.

Elasticity
스톰을 설계할 때 염두해 두었던 가장 핵심적인 설계 철학은 탄력성(Elasticity)를 부여하는 것이었다고 합니다.
(It provides a huge potential for elasticity. Real-time processing will rarely produce a constant and predictable load.)

즉, 실시간 처리 시스템은 시스템에 대한 로드를 미리 예상하는 것이 어렵기 때문에 기반 파일시스템 및 처리 시스템이 확장성을 가져야 한다는 점입니다.
하둡은 데이터 노드를 신속하게 확장함으로써 ‘용량’ 뿐만 아니라 ‘처리 능력’도 확장 가능한 시스템이기 때문에 하둡과 궁합이 맞는 시스템으로 판단했습니다.
하둡을 YARN에서 운용함으로써 시스템의 로드가 피크를 향해 가면 그 동안 배치 처리에 운용되던 리소스를 빌려 와서 처리를 하고 결과가 마무리 되면 다시 다른 작업에 돌려 줄 수 있습니다.

Launch Storm Cluster
스톰(Storm)은 이제 하둡 클러스터 관리 툴인 Ambari와 통합이 되어 있기 때문에 손쉽게 인스톨할 수 있습니다.
인스톨 방법은 위 링크에서 확인하시기 바랍니다.

실제로 스톰을 론칭하는 것은 간단합니다.
storm-yarn launch
여기서 ‘storm-yarn.yaml’은 스톰의 동작을 정해 놓기 위한 컨피규레이션(Configuration) 파일입니다.
예를 들어, 이 파일에는 ‘스톰 관리 모듈(Storm Supervisor)’를 처음에 몇 개로 론칭할 지를 지정하는 ‘master.initial-num-supervisors’ 혹은 각 스톰 관리 모듈을 위해서 할당해야 하는 메모리 사이즈를 지정하는 ‘master.container.size-mb’ 등과 같은 퍼래미터(Parameter)를 지정할 수 있습니다.
* Storm Supervisor는 실제 Worker Node에 생성되면 실제 부여된 태스크(task)를 관리하며, 맵리듀스의 Task Tracker와 비슷한 역할을 합니다.

yarncontainer

이 명령어를 실행시키면 아래와 같은 과정을 통해서 론칭이 진행됩니다.
1. 스톰-YARN은 YARN의 RM(Resource Manager)에게 스톰 AM(Application Master)을 론칭하기 위한 리소스를 요청합니다.
2. 스톰 AM은 각각 ‘스톰 님버스 서버(Storm Nimbus Server)’와 ‘스톰 UI(Storm UI) 서버’를 론칭합니다.
스톰 님버스 서버는 일종의 관리 서버로서 잡트랙커(Job Tracker)와 비슷하게 실행 코드를 클러스터에 분배하는 역할을 합니다.
스톰 UI 서버는 웹 인터페이스로 스톰을 관리하기 위한 서버로 이해하시면 됩니다.
3. 스톰 AM은 각 Worker Node에 스톰 관리 모듈(Storm Supervisor)를 실행하기 위한 리소스를 요청해서 론칭합니다.

그래서 ‘스톰 님버스 서버’가 각 태스크를 ‘스톰 관리 모듈’에 분배하고 ‘스톰 관리 모듈’은 부여된 태스크를 관리하는 구조로 요약할 수 있습니다.

Execute Storm Topologies
여기서 ‘스톰 토폴로지(Storm Topologies)’는 이벤트 스트림을 발생시키는 기능과 처리하는 기능을 하나의 워크플로우로 묶어 놓은 실행 코드로 생각하면 되겠습니다.

yarn2

위 다이어그램에서 보는 것처럼, 스톰 님버스 서버가 실행해야 할 태스크를 Storm superviser에 할당하면 Storm superviser는 실제 실행할 프로세스를 생성해서 ‘스톰 토폴로지’를 실행합니다.
그리고 Storm superviser는 실행 과정을 주기적으로 스톰 님버스 서버에게 보고합니다.

실제로 스톰을 실행하는 실행 코드와 데모는 아래 링크에서 다운로드해서 실행해 보면 전체적인 프로세스를 쉽게 이해할 수 있을 것입니다.
스톰을 이용한 간단한 워드카운트 데모
운송 회사의 예를 가지고 스톰을 이벤트 스트리밍 처리에 활용하는 예제 샘플

스톰-YARN은 하나의 하둡 클러스터에서 실시간 스트리밍을 처리할 수 있는 기반을 제공함으로써 그 활용 범위는 이미 여러 가지 사례를 통해서 적용되고 있습니다.

실시간 하둡의 사례에 대해서는 앞으로도 지속적으로 소개하도록 하겠습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

하둡 2.0 YARN의 컨셉에 대한 검토 및 적용 방법

This article is based on Hortonworks Partner Content

지금까지 다양한 적용사례나 아키텍쳐에 대한 검토를 할 때 자연스럽게 하둡 2.0 기반을 전제로 소개하고 있습니다.
그 핵심적인 이유에 대해서는 아래 블로그들에서 충분히 이해할 수 있을 듯 합니다.

현 시점에서 하둡 2.0을 반드시 적용해야 할 필요가 있을까?
기업의 데이터 정제 아키텍쳐로 하둡을 보는 관점
유통업을 위한 하둡 아키텍쳐
하둡 파일시스템(HDFS)의 새로운 아키텍쳐 – HDFS 2.0

이러한 다양한 적용 사례에서 공통적으로 활용되는 부분을 요약하자면 하나의 하둡 클러스터에서 배치, SQL 인터랙티브, 온라인, 실시간 스트리밍 처리와 같은 다양한 데이터 처리 방식을 요구 사항에 맞게 적용할 수 있다는 점입니다.
이것이 하둡 2.0을 기반으로 적용해야 할 가장 핵심적인 이유가 되겠습니다.

그래서 하둡 2.0에 이러한 유연성을 가져 오게 한 YARN(Yet Another Resource Negotiator)의 컨셉에 대해서 조금 더 검토해 보고자 합니다.

하둡 1.0의 맵리듀스(MapReduce)가 하둡 클러스터에서 동작하는 방식은 아래와 같습니다.

1.0

여기서 잡트랙커(JobTracker)는 사실 두 가지 기능을 함께 수행하고 있습니다.
첫째는, 실제로 분석이 이루어 지는 노드들(TaskTrackers)의 리소스(가용한 스토리지 등)가 이용 가능한지, 얼마나 사용되고 있는 지 등을 관리하는 리소스 관리 기능입니다.
두번째는, 실제로 분석을 실행하는 맵리듀스 잡(MapReduce Job)을 배포하고 스케쥴링하고 모니터링하는 실행 관리 기능입니다.

이 구조에서 TaskTracker는 잡트랙커(JobTracker)에서 일을 받아 와서 실행하고 실행 현황을 다시 보고하는 아주 단순한 역할을 수행합니다.

다음에는 하둡 2.0의 YARN(Yet Another Resource Negotiator)가 하둡 클러스터에서 동작하는 방식을 보겠습니다.

2.0

이 구조에서는 잡트랙커(JobTracker)의 두 가지 기능이 두 개의 모듈로 나누어 집니다.

Resource Manager(RM)
YARN에서 RM는 기본적으로 순수하게 하둡 클러스터의 전체적인 리소스 관리만을 담당하는 심플한 모듈입니다.
현재 가용한 리소스들(Job을 실행시킬 노드나 스토리지 등)에 대한 정보를 바탕으로 이러한 리소스들을 ‘각’ 어플리케이션에 일종의 정책으로서 부여하고 그 이용 현황을 파악하는 업무에 집중합니다.

Application Master(AM) & Node Manager(NM)
YARN에서 AM의 정확한 정의는 특정 프레임워크(MapReduce, Storm 등 다양한 어플리케이션) 별로 잡(Job)을 실행시키기 위한 별도의 라이브러리입니다.
예를 들면, 기존의 맵리듀스는 맵리듀스 AM에서, 기존의 스트리밍 처리는 스톰(Storm) AM에서 각자 담당하고 책임을 지게 됩니다.

AM은 다음과 같은 역할을 하는 모듈입니다.
1. RM과 협상하여 하둡 클러스터에서 자기가 담당하는 어플리케이션에 필요한 리소스를 할당받습니다.
2. NM과 협의하여 자기가 담당하는 어플리케이션을 실행하고 그 결과를 주기적으로 모니터링합니다.
3. 자기가 담당하는 어플이케이션의 실행 현황을 주기적으로 RM에게 보고합니다.

즉, 특정한 어플리케이션의 처리 라이브러리를 AM에 올림으로써 하나의 하둡 클러스터에서 다양한 어플리케이션이 돌아 가도록 하는 것이 핵심입니다.
이러한 구조의 변화에 의해서 사용자는 데이터의 속성에 맞는 다양한 어플리케이션을 처리하는 별도의 AM을 만들어서 확장시킬 수 있습니다.

그래서 다음과 같이 하둡 2.0이 진정한 데이터 플랫폼으로 진화하는 기반이 되었습니다.

YARN

오히려 이 그림에서는 ‘Others’에 주목하면 어떨까 싶습니다.
기존에 기업에서 활용하는 다양한 솔루션을 YARN에서 동작하는 어플리케이션으로 개발하여 플러그인할 수 있습니다.

최근에 다양한 기업들이 하둡 2.0을 지원한다고 발표하면서 자사의 솔루션과 하둡을 연동하는 움직임이 활발합니다.
블로그에서 소개해 드린 SAP, RedHat, IBM, EMC 등등 기사를 보시면 거의 대부분의 벤더들이 지원을 하고 있습니다.

이유는 하둡 2.0에서야 비로소 다른 솔루션 혹은 어플리케이션을 수용할 수 있는 ‘확장성’을 얻었기 때문입니다.
앞으로 글로벌 벤더만이 아니라 한국의 기업들도 자신만의 특화된 솔루션을 하둡과 연동시켜서 이 시장이 활발해 졌으면 하는 바램입니다.

기업 입장에서도 하둡 2.0을 기반으로 적용함으로써 현재 이용 가능한 어플리케이션 뿐만 아니라 다양한 다른 어플리케이션을 언제든지 기존에 구축한 하둡 클러스터에 응용할 수 있기 때문에 유연한 데이터 플랫폼으로 계속 진화할 수 있습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–