블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

클러스터 상에서 하둡 배포 아키텍쳐


조대협 (http://bcho.tistory.com)


오늘 빅데이타 관련 교육을 받다가 클라우드 상에서 하둡 클러스터 활용에 대한 영감을 받은 부분이 있어서 정리해보고자 한다. 하둡의 경우에는 On-prem 환경에 적절하게 디자인이 된 오픈 소스라서, 이걸 클라우드에서 사용할 경우에도 on-prem에서 사용하는 형태와 유사하게 사용하는 경우가 많다. 일종의 습관 또는 관성이라고 해야 하나? 인프라가 바뀌면 그 장점에 맞는 아키텍쳐를 선택해야 하는데, 이 부분을 놓치고 있지 않았나 싶다.

Job별 클러스터를 생성하는 아키텍쳐

job을 수행하는 방법을 보면, 일반적으로 On-Prem에서 사용하는 방법은 하나의 하둡 클러스터에 Job을 실행하고 Job이 끝나면 다음 Job을 수행하는 방식을 사용한다.



이러한 경험(습관)때문인지 보통 클라우드 상에 하둡 클러스터를 만들어놓고 그 클러스터에 On-prem과 마찬가지 방식으로 Job을 넣고 그 작업이 끝나면 같은 클러스터에 Job을 넣는 방식을 사용한다.

그런데 클라우드의 특성상 자원이 거의 무한대인데, 여러개의 Job을 하나의 클러스터에서 순차적으로 실행할 필요가 있을까?


Job별로 클러스터를 생성해서 연산을 하고 Job이 끝나면 클러스터를 끄는 모델을 사용하면, 동시에 여러 작업을 빠르게 처리할 수 있지 않을까?



이 경우 문제가 될 수 있는 것이 같은 데이타셋을 가지고 여러가지 Job을 실행할 경우 기존의 On-Prem의 경우에는 동시에 같은 데이타셋에 접근할 경우 오버로드가 심하기 때문에, 어렵지만 클라우드의 경우에는 바로 HDFS를 사용하는 것보다는 GCS와 같은 클라우드 스토리지를 사용하는데, 여기서 오는 장점이 이런 클라우드 스토리지에 저장된 데이타는 동시에 여러 하둡 클러스터에서 접근이 가능하다.


이러한 아키텍쳐를 생각하게된 이유는 구글 클라우드의 특성 때문인데, 구글 클라우드의 과금 모델은 분당 과금 모델을 사용한다. 그래서 Job별로 클러스터를 전개했다가 작업이 끝난 다음에 끄더라도 비용 낭비가 없다. 시간당 과금인 경우에는 클러스터를 껐다켰다 하면 비용 낭비가 발생할 수 있기 때문에 바람직하지 않을 수 있다. 예를 들어서 1시간 10분이 걸리는 작업과 20분이 걸리는 작업을 각각 다른 클러스터에서 돌린다면 2시간, 그리고 1시간 비용이 과금되기 때문에 총 3시간이 과금된다.

그러나 구글의 분당 과금을 적용하면 총 1시간30분이 과금되기 때문에 비용이 1/2로 절감된다.


또한 구글 클라우드의 경우 하둡 클러스터 배포시간이 통상 90초이내로 빠르기때문에, Job마다 클러스터를 생성하고 끈다고 해도, 실행 시간이 크게 늘어나지 않는다.


클러스터별로 인프라를 최적화

만약에 위에처럼 Job별로 클러스터를 나눈다면, Job 의 특성에 맞춰서 클러스터의 인스턴스 수나 구조(?)를 변경하는 것도 가능하다.

즉 많은 컴퓨팅 작업이 필요한 Job이라면 클러스터에 많은 인스턴스를 넣고, 그렇지 않다면 인스턴스 수를 줄일 수 있다.




조금 더 나가면, 상태 정보 같이 HDFS에 저장하는 데이타가 적을 경우 워커노드가 중간에 정지되더라도 전체 연산에 크게 문제가 없을 경우에는 Preemptible VM과 같이 가격은 싸지만 저장 기능이 없는 VM의 수를 늘려서 전체 비용을 낮출 수 있다.




여기서 한걸음 더 나가면, 구글 클라우드의 인스턴스 타입중의 하나가 Cutomizable 인스턴스로 CPU와 메모리 수를 마음대로 조정할 수 있다. 즉 Job이 메모리를 많이 사용하는 Spark과 같은 Job일 경우 클러스터를 구성하는 인스턴스에 CPU보다 메모리를 상대적으로 많이 넣고 구성하는 것들이 가능하다.


아키텍쳐 설계도 의미가 있었지만, 그동안 간과하고 있었던 점이 기술이나 인프라가 바뀌면 활용 하는 방법도 다시 고민해야 하는데, 그동안의 관성 때문인지 기존 시스템을 활용하는 방법을 그대로 의심 없이 사용하려 했다는 것에 다시한번 생각할 필요가 있었던 주제였다.






저작자 표시 비영리
신고

E-tailing

  • Recommendation engines — increase average order size by recommending complementary products based on predictive analysis for cross-selling.
  • Cross-channel analytics — sales attribution, average order value, lifetime value (e.g., how many in-store purchases resulted from a particular recommendation, advertisement or promotion).
  • Event analytics — what series of steps (golden path) led to a desired outcome (e.g., purchase, registration).

Financial Services

  • Compliance and regulatory reporting.
  • Risk analysis and management.
  • Fraud detection and security analytics.
  • CRM and customer loyalty programs.
  • Credit scoring and analysis.
  • Trade surveillance.

Government

  • Fraud detection and cybersecurity.
  • Compliance and regulatory analysis.
  • Energy consumption and carbon footprint management.

Health & Life Sciences

  • Campaign and sales program optimization.
  • Brand management.
  • Patient care quality and program analysis.
  • Supply-chain management.
  • Drug discovery and development analysis.

Retail/CPG

  • Merchandizing and market basket analysis.
  • Campaign management and customer loyalty programs.
  • Supply-chain management and analytics.
  • Event- and behavior-based targeting.
  • Market and consumer segmentations.

Telecommunications

  • Revenue assurance and price optimization.
  • Customer churn prevention.
  • Campaign management and customer loyalty.
  • Call Detail Record (CDR) analysis.
  • Network performance and optimization.

Web & Digital Media Services

  • Large-scale clickstream analytics.
  • Ad targeting, analysis, forecasting and optimization.
  • Abuse and click-fraud prevention.
  • Social graph analysis and profile segmentation.
  • Campaign management and loyalty programs.

From http://www.cloudera.com/why-hadoop/

 

저작자 표시
신고

Hadoop Architecture Overview

요즘 클라우드와 빅데이타 그리고 분산 컴퓨팅이 유행하면서 가장 많은 언급 되는 솔루션중하나가 Hadoop이다. Hadoop 이 무엇이길래 이렇게 여기저기서 언급될까? 본 글에서는 Hadoop에 대한 소개와 함께, Hadoop의 내부 동작 아키텍쳐에 대해서 간략하게 소개 한다.

What is Hadoop?

Hadoop의 공식 소개를 홈페이지에서 찾아보면 다음과 같다.

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using a simple programming model. ’

정의를 요약하면, Hadoop은 여러 컴퓨터로 구성된 클러스터를 이용하여 큰 사이즈의 데이타를 처리하기 위한 분산 처리 프레임웍이다.

구조를 보면 엔진 형태로 되어 있는 미들웨어와 소프트웨어 개발 프레임웍의 형태를 띄고 있고, 대용량 데이타를 분산처리를 통해서 처리할 수 있는 솔루션으로, OLTP성의 트렌젝션 처리 (웹과 같이 즉시 응답이 필요한 시스템)보다는 OLAP성의 처리 (데이타를 모아서 처리 후 일정 시간 이후에 응답을 주는 형태)를 위해 디자인된 시스템으로 수분~수일이 소요되는  대규모 데이타 처리에 적합한 프레임웍이다.

Hadoop을 기반으로 한 여러가지 솔루션이 있으나 본 글에서는 Hadoop 자체에 대해서만 설명하도록 하겠다.

Map & Reduce의 기본

Hadoop의 분산 처리 방식은 기본적으로 “Map & Reduce”라는 아키텍쳐를 이용한다. Map & Reduce는 하나의 큰 데이타를 여러개의 조각으로 나눠서 처리 하는 단계 (Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는 단계 (Reduce)로 나뉘어 진다.

 

 

<그림 Map & Reduce의 기본 개념 >

예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자. 우리한테는 한국에 있는 모든 사람의 수입이 적혀 있는 텍스트 파일이 하나 있다. 이 파일을 이용해서 각각 사람의 수입을 순차적으로 더해서할 수 도 있지만, 전체 파일을 10조각, 100조각으로 나눠서 각 조각의 수입합을 계산한후, 그 결과를 하나로 더하면, 조각을 나눈만큼의 계산을 병렬로 처리할 수 있기 때문에 조금 더 빠른 결과를 가질 수 있다. 이렇게 하나의 파일을 여러 조각으로 나눠서 계산 하는 것을 Map, 그리고 합치는 과정을 Reduce라고 한다.

이러한 Map & Reduce를 하기 위해서는 Input 데이타를 저장하고, 이 데이타를 조각으로 나눠서 저장하고, 조각에서 처리된 임시 결과를 저장 그리고 합쳐서 저장할 각각의 저장 공간이 필요하다. 이 공간은 전체 분산 처리 시스템에 걸쳐서 접근이 가능해야 하고, 대용량의 데이타를 저장할 수 있어야 하는데, Hadoop에서는 이 공간으로 분산 파일 시스템 (Distributed File System)을 사용하며, 이를 HDFS (Hadoop Distributed File System)이라고 한다. 그리고 위에서 설명한 것 처럼 MR을 위해서 데이타를 처리하는 부분을 Map & Reduce 모듈이라고 한다.

사용 시나리오

Hadoop Map & Reduce는 대용량 데이타에 대한 분석에 대해서 최적화 되어 있다.

즉 웹 시스템이나 OLTP (Online Transaction Processing)과 같은 1~5초내에 응답이 오는 형태의 Request/Response 방식의 Synchronous 형식의 시나리오에는 적합하지 않고, Input을 넣은 다음 수분 후에 결과를 받아서 보는 비동기 (Asynchronous) Deferred 형태의 시스템에 적절하다.

 수학적 계산을 위한 연산 처리, 대규모 저장 및 분석, BI (Business Intelligence)와 같은 데이타 분석과 같은 후처리(지연처리) 중심의 분석 시나리오에 적합하다.

Hadoop 구성

앞에서 설명한 것과 같이 Hadoop은 크게 분산 데이타 처리를 하기 위한 Map & Reduce 모듈(이하 MR) MR Input/Output 데이타를 저장하는 파일시스템인 HDFS (Hadoop Distributed File System)으로 구성되어 있다.

HDFS (Hadoop Distributed File System)

HDFS는 분산 데이타 처리를 위해서 데이타를 저장하기 위한 파일 시스템으로, 다음과 같은 특징을 가지고 있다.

  • 대용량의 파일 (페타 바이트)을 저장할 수 있다.

  • 많은 수의 파일을 저장할 수 있다.

  •  Streaming Data Access

  •  Commodity Hardware

  • Multiple writers, arbitrary file modifications

HDFS의 구성 컴포넌트는 크게 두가지로 나뉘어 진다. (Namenodes, Datanodes).

Namenodes

Namenodes는 일종의 Master node로 파일에 대한 메타 데이타를 저장하는 노드로, 디렉토리 구조, 파일에 대한 각종 메타 데이타, 그리고 물리적 파일이 저장되어 있는 위치등을 저장한다.

Datanodes

Datanodes는 실제 파일을 저장하고 읽어온다. 하나의 파일을 블록이라는 단위로 나눠서 저장하는 역할을 수행한다. 그리고 Namenodes와 주기적으로 통신하여 저장하고 있는 블록에 대한 정보를 Namenodes에 저장하도록 한다.

Namenodes에는 모든 블록에 대한 메타정보가 들어와 있기 때문에, Namenodes가 장애가 나면 전체 HDFS 이 장애가 나는 SFP ( Single Failure Point )가 된다. Namenodes에 대한 이중화가 필요하다. Namenodes에 대한 이중화 방안에 대해서는 추후에 설명하도록 한다. Namenodes SFP로 작용하는 것은 Hadoop 운영상에 아주 중요한 운영 포인트로 존재한다. 근래에는 HDFS의 약점을 보완하기 위해서 GlusterFS Hadoop을 지원하면서, 파일 시스템으로 HDFS를 사용하는 대신 GlusterFS로 대처할 수 있다.

블럭 (Block)

블럭은 HDFS에서 Read Write를 하는 최소 단위이다. 하나의 파일을 여러개의 블럭으로 나눠서 저장된다. Hadoop의 블럭 사이즈는 일반적인 파일 시스템의 블럭사이즈 ( Kilobytes – 일반적으로 파일시스템에서는 512 KB )에 비해서 큰 블럭사이즈를 사용한다. Hadoop에서는 디폴트로 64MB를 사용하고, 보통 128MB를 사용한다.

클 블럭사이즈를 사용하는 이유는, MR 처리에 있어서 Map Task가 하나의 파일 사이즈 단위로 처리하기 때문에, 작은 파일 억세스 보다는 Map Task 단위로 처리할 수 있는 단위가 필요하다. (이것이 블럭) 이를 위해서 큰 사이즈 단위로 파일 처리를 할 수 있는 블럭을 지정하는 것이다.

또한 블럭 크기를 크게 함으로써, 해당 파일에 대한 Seeking Time을 줄일 수 있고, 블럭 사이즈를 적게 하면 Master Node에서 저장 및 처리해야 하는 데이타의 양이 많아지기 때문에 Master Node에 많은 부하가 걸리기 때문에 큰 블럭 사이즈를 사용한다. 이런 이유로 반대로 블럭 사이즈가 작거나 사이즈가 작은 데이타 처리의 경우 Hadoop에서는 충분한 분산 처리 성능을 기대하기 어렵다.

HDFS는 대규모 분산 처리에 필요한 대용량 input 데이타를 저장하고 output 데이타를 저장할 대용량 파일 시스템을 지원한다. HDFS 시절 이전에는 고가의 SAN (Storage Area Network)장비나 NFS 장비를 사용했어야 했는데, Hadoop은 일반 x86 서버에 Disk를 붙인 형태의 저가의 서버 여러개를 연결하여 대규모 분산 파일 시스템을 구축할 수 있게 해줌으로써, 값비싼 파일 시스템 장비 없이 분산 처리를 가능하게 해주는 것이다

Read/Write Operation

1) Read Operation

Client에서 Read를 수행하면, 먼저 Client SDK Namenode에 해당 파일의 데이타 블럭들이 어디에 있는지 블록의 위치를 먼저 물어온 다음에, 순차적으로 해당 데이타 블록이 저장되어 있는 datanodes로 부터 데이타를 블록을 읽어온다.

 

<그림. HDFS Read Operation >

이 과정에서 Namenode라는 놈이 아주 기특한 일을 하는데, 기본적으로 HDFS는 하나의 파일 블록을 저장할때 하나의 datanode에 저장하는 것이 아니라 N개의 datanode에 복제해서 저장한다. (장애 대응을 위하여). Namenode가 블록의 위치를 리턴할때, Hadoop Client로 부터 가까운 곳에 있는 datanode (같은 서버, 같은 Rack, 같은 데이타 센터 순서로..)를 우선으로 리턴하여 효율적인 Read Operation을 할 수 있도록 한다.

2) Write Operation

 

<그림. HDFS Write Operation>

파일 블록 저장은 약간 더 복잡한 과정을 거치는데

파일을 Write를 요청하면,

     먼저 Namenode에서 File Write에 대한 권한 체크등을 수행한다.

     Namenode에서 파일이 Writing Block의 위치한 Datanode를 리턴한다. (1)
파일을 쓰다가 해당 블록이 다 차면, Namenode에 다음 Block이 저장되는 Datanode의 위치를 물어본다.

     Client Stream을 통하여 해당 Datanode Block에 파일을 Write한다. (2)

     Write된 파일을 복제 Datanodes (※ 여기서는 복제노드와 원본 노드를 포함하여 총 3개의 노드가 있다고 가정하자)로 복제(복사)한다. (3,4)

     복제되는 Datanodes들 쌍을 pipeline이라고 하는데, 내부 정책에 따라서 서로 복제할 Datanodes들을 미리 정해놓고 이를 통해서 복제한다. (pipeline Datanode의 물리적 위치 – Rack, 데이타 센터 등을 고려해서 자동으로 결정된다.)

     복제가 모두 끝나면 ACK를 보낸다. (5,6,7)

     파일 Writing을 완료한다.

 

이번 글에서는 간단하게 Hadoop에 대한 개념 소개와 Hadoop의 하부 파일 시스템인 HDFS에 대해서 알아보았다. 다음 글에서는 Hadoop의 Map & Reduce Framework에 대해서 살펴보기로 한다.

 

저작자 표시
신고