분산처리 프레임웍 Apache Hadoop 아키텍쳐 소개 - #1/2 (HDFS)

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에 대해서 살펴보기로 한다.