하둡의 등장 배경

산업 전반적으로 방대한 양의 데이터가 생성되면서 데이터를 다루는 기술이 비즈니스의 흥망성쇠를 좌우하기에 이르렀다. 늘어나는 데이터를 수집ㆍ보관ㆍ가공ㆍ분석하기 위해서는 효율적인 IT 시스템을 구축하는 것이 매우 중요하다. 이 시각에서 볼 때 빅데이터 처리 기술은 당면한 문제를 해결할 수 있는 유일한 열쇠이기도 하다.
빅데이터를 얘기할 때 반드시 언급될 정도로 하둡은 빅데이터 기술에서 매우 중요한 요소로 자리잡고 있다. 하둡은 본래 기능뿐 아니라 다양한 기능을 지원하기 위한 주변 기술까지 포괄하면서 에코 시스템을 형성하고 있다. 하둡은 대용량 데이터를 처리하기 위한 분산처리 시스템에서 출발했으며, 데이터 처리를 통한 통찰력을 제공하는 데 중심적인 역할을 하고 있다.

하둡의 탄생 배경은 다음과 같다.

• 하둡은 아파치 그룹의 프로젝트로 시작돼 발전한 대용량 데이터 처리를 위한 분산처리 프레임워크를 말한다. 구성의 핵심은 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)과맵리듀스(MapReduce) Function 및 다양한 에코시스템으로 구성됐다.
• 하둡은 아파치그룹의 더그 커팅(Douglas Cutting)에 의해 루신(Lucene) 하부 프로젝트로 시작되었으며, 다양한 과정을 거쳐 개발ㆍ적용됐다. 현재도 오픈소스 활동 및 하둡 벤더사들을 중심으로 지속적으로하둡을 진화시켜 나가고 있다.

하둡에 저장ㆍ운영되는 많은 데이터는 아직까지 웹로그 분석 등 비정형 데이터가 큰 부분을 차지하고 있는 것이 현실이며, 다양한 업무에 맞게 하둡의 에코시스템도 지속적으로 발전하고 있다.

하둡은 다음과 같은 이유로 빅데이터 생태계의 중심이 되고 있다.

• 빅데이터 분석은 대용량의 데이터를 기반으로 이뤄진다. 이러한 업무를 수행하기 위해 하둡은 대용량 데이터를 저장할 수 있는 분산 파일 시스템(HDFS)을 제공하고 있다. 이러한 HDFS는 정형, 비정형 데이터 분석에 매우 효율적이다.
• 전통적인 정보계 시스템에서는 분석업무 수행 시 서버와 저장장치에서 IO(Input/Output) 병목 현상이 발생하기 쉽다. 이러한 병목 현상을 해결하기 위해 각종 벤더에서는 데이터 웨어하우스 어플라이언스를 내놓았다. 어플라이언스에는 수퍼컴퓨팅 기술에서 적용되는 인피니밴드와 같은 네트워크 스위칭이 적용됐다. 하지만 하둡에서는 I/O 병목현상이 발생할 가능성이 없다.클러스터링 기술을 통해 서버를 분산해 I/O 병목 현상을 줄였기 때문이다.
• 클러스터링 기술로 서버를 증설하면, 성능은 선형적으로 향상된다. 이때 기존의 스케일업 방식이 아닌, 스케일아웃 방식으로 수많은 서버를 단일화한 클러스터로 구성할 수 있다.
• 하둡 기반의 빅데이터 분석 인프라는 기존 RDB 데이터 웨어하우스 인프라에 비해 가격 측면에서 매우 경제적이다. 하둡은 오픈소스이기 때문에 비용에 대한 부담이 없고 OS(Operating System)등에 대한 부담도 매우 낮다.

이와 같은 이유 때문에 하둡 플랫폼은 대용량 데이터를 분산 처리하기 위한 시스템으로 각광 받고 있다. 하둡 시스템에서는 64MB~128MB 단위(일부 하둡 벤더에서는 효율성 차원에서 Kb 단위로 파일을 나누기도 한다)로 파일을 나누어 분산 저장하는 HDFS(Hadoop Distributed File System)가 신뢰도가 높은 파일의 저장소 역할을 한다. HDFS는 크게 네임 노드와 데이터 노드로 양분돼 작동하기 때문에 시스템 확장을 위해 데이터 노드를 추가할 때, 특별한 어려움 없이 선형적으로 성능을 끌어올릴 수 있다.

하둡의 특징

하둡 분산 파일 시스템의 기본 구조는 구글 파일 시스템(Google File System)과 비슷하며, 구글의 논문을 바탕으로 설계됐다. 따라서 구글 파일 시스템의 주요 기능을 포함하고 있다. 하둡 분산 파일 시스템은 네트워크의 여러 서버에 존재하는 디스크들을 마치 하나의 디스크처럼 활용한다. 일반적인 파일 시스템과 달리 볼륨 기반으로 파일을 적재하거나 파일 단위로 저장하지 않고, 파일을 블록 단위로 쪼개 여러 서버에 분산ㆍ저장한다. 따라서 서버의 디스크 용량보다 큰 대용량 파일도 저장ㆍ처리할 수 있다. 하나의 클러스터를 구성하는데 수백에서 수천 대 이상의 서버를 이용하므로 페타바이트급 이상의 데이터도 손쉽게 저장할 수 있다. 네트워크 속도와 디스크 I/O 속도, 복제본 수를 보완해 얼마든지 그 성능도 조절할 수 있다. 현재 하둡은 1.X대와 2.X대 두 개의 메이저 버전으로 나뉘어 관리ㆍ배포되고 있다. 1.X는 버전 1.2.1까지, 2.X는 버전 2.60까지 릴리즈됐다. 클라우데라에서 배포하는 CDH(Cloudera Hadoop) 버전도 있다. 각 버전은 구조와 기능이 서로 상이해서 별도로 버전 관리가 되고 있다. 하둡을 스토리지로 활용하는 이유는 다음과 같다.

손쉬운 확장

기존 스토리지 장치나 어플리언스는 미리 데이터 크기를 예측해 구축해야 했다. 또한 한 번 구축되고 나면 용량 확장과 이미 저장된 데이터를 분산시키는 추가 작업이 뒤따랐다. 물론 디스크만 확장해 용량을 확보하는 어플라이언스도 있지만, 그럴 경우 특정 디스크의 입출력은 분산되지 않는 단점이 있다. 하지만 하둡 분산 파일 시스템은 단순히 x86 서버를 증설해 데이터 노드를 설치ㆍ실행하면 스토리지 용량이 자동으로 늘어난다. 뿐만 아니라 데이터 리밸런싱 명령을 실행하면, 기존 데이터 노드에 몰려 있는 블록 데이터를 적당한 비율로 모든 데이터 노드에 재배치한다. 이렇게 손쉽게 스토리지 용량을 확장할 수 있어 데이터 증가 추이에 따라 당일 확장 작업도 가능하다.

메타 정보의 중앙 집중적 관리

파일의 메타 정보를 네임 노드에서 중앙 집중적으로 관리하므로, 데이터 노드에 문제가 생기더라도 파일 손실 위험이 없다. 그리고 파일 리던던시(Redundancy)를 피할 수 있다.

선형적인 디스크 입출력 분산

네임 노드는 충분한 데이터 노드가 있으면, 중복된 데이터 노드 정보를 반환하지 않는다. 이 덕분에 데이터 노드에 파일을 전송할 때, 서로 다른 데이터 노드에 전송하게 된다. 따라서 모든 데이터 노드의 로컬 디스크 입출력을 최대한 활용할 수 있어 멀티테넌시(Multi-tenancy)를 확보할 수 있다.

선형적인 네트워크 부하 분산

선형적인 디스크 입출력 분산에 의해 파일이 분산ㆍ저장돼 있기 때문에 데이터 노드의 네트워크 부하가 분산되는 효과를 얻게 된다. 또한 파일 크기가 크면 블록으로 쪼개서 저장하므로 한 서버에 네트워크 트래픽을 오랫 동안 점유하지 않는다. 따라서 서비스의 멀티테넌시를 확보할 수 있다.

안정적인 데이터 관리

하둡 분산 파일 시스템은 파일의 복제본 수를 지정할 수 있다. 복제본 수를 온라인 상태에서 다이내믹하게 지정할 수 있고, 네트워크 토폴로지(Network Topology) 기반으로 복제본을 분산할 수 있으므로 데이터의 안정성을 확보할 수 있다. 예를 들어 복제본 수가 3이면 데이터 노드 로컬 디스크에 하나, 동일한 랙에 있는 다른 데이터 노드에 하나, 다른 랙에 있는 데이터 노드에 하나를 각각 저장해 데이터 노드가 있는 랙 전체에 문제가 생겨도 파일을 안정적으로 보관할 수 있다. NAS(Network-Attached Storage)는 응용 계층에서 이 부분을 처리하지만, 하둡 분산 파일 시스템은 네트워크 토폴로지를 기반으로 처리한다.

하지만 하둡 분산 파일 시스템은 다음과 같은 단점이 있다.

저장하는 파일 수의 제한

하둡 분산 파일 시스템은 파일의 메타 정보를 모두 네임 노드에서 관리한다. 그리고 네임 노드는 이 정보를 모두 메모리에서 처리하므로 네임 노드 서버의 메모리 크기만큼 파일 메타 정보를 관리하는 단점이 있다. 기본적으로 한 개 파일의 메타 정보인 네임스페이스 정보는 수백 바이트의 크기이므로 그 수가 매우 제한적이다. 따라서 하둡 분산 파일 시스템은 작은 파일보다는 큰 파일을 저장하는 용도에 적합하다. 하둡 버전 2.0에서는 이런 단점을 해결하기 위해 네임 노드 페더레이션(Namenode Federation) 구조를 추가했다. 이는 여러 개의 네임 노드에 네임스페이스 정보를 분산시키는 방식이다. 데이터 노드는 공유하고, 여러 개의 네임 노드를 풀로 관리하는 방식이다. 현재 야후에서 테스트 중이고 호튼웍스(hortonworks)에서 주도적으로 팔로업하고 있다.

파일 저장보다는 읽기가 많은 서비스에 적합

하둡 분산 파일 시스템은 파일을 자주 저장하는 서비스보다 한 번 저장하고 자주 읽는 서비스에 적합하다. 하둡에 파일을 저장할 때, 하둡 인프라(Infrastructure)에서는 네트워크와 디스크 자원을 많이 사용하게 된다. 복제본 전송이 발생하기 때문이다. 하지만 파일이 블록 단위로 분산돼 있고 복제본도 존재하므로, 파일을 읽을 때는 자원을 분산해서 특정 노드에 병목 현상이 발생하지 않는다. 다시 말해서 파일을 저장하는 것보다 읽는 것에 최적화된 기술인 셈이다.

포직스 인터페이스를 지원하지 않는다

하둡 분산 파일 시스템은 파일 시스템이지만 시스템에서 사용하는 명령을 사용해 파일을 관리할 수 없고 FUSE(Filesystem in Userspace)를 이용해 시스템에 마운트할 수는 있지만, POSIX 인터페이스 중 ls, rm, cp 파일 처리 명령어만 사용할 수 있을 뿐이다. 그래서 하둡 분산 파일 시스템에 응용프로그램을 설치하거나 실행할 수는 없다. 단순히 파일을 저장하고 읽는 용도로만 사용할 수 있다.

랜덤 쓰기를 지원하지 않는다

하둡 분산 파일 시스템은 일반적인 시스템이나 NFS에서 지원하는 랜덤 쓰기를 지원하지 않는다. 그래서 한 번 저장한 파일은 변경할 수 없으며, 만약 변경이 필요하면 파일을 덮어 씌우는 방식을 사용해야 한다. 하둡 0.2.1버전 이후부터 파일을 덧붙일 수 있는 기능을 제공한다.

네임 노드 이중화 문제

버전 1.X의 하둡 네임 노드는 SPOF(Single Point Of Failure, 단일 고장점) 문제를 갖고 있다. 분산된 파일 블록의 위치 정보와 파일 메타 정보를 한 곳에서 관리함에 따라 생기는 문제다. 데이터 노드에는 장애가 발생해도 스토리지 서비스를 정상적으로 할 수는 있지만, 네임 노드에 장애가 발생하면 서비스 자체가 불가능하다. 장애 발생 시 보조 네임 노드를 이용해 서비스를 다시 시작할 수는 있지만, 서비스 다운타임은 피할 수 없다. 그래서 많은 하둡 개발자는 네임 노드 이중화 방법에 대해 연구를 하였으며, 마침내 2.X버전에서 이중화 문제가 해결되었다.

하둡 분산 파일 시스템을 잘 알고 그 장점을 최대한 활용한다면, 스토리지 서비스로 그 역할을 충분히 할 수 있다. 하둡 분산 파일 시스템이 단순히 파일을 분산 환경에 저장하는 기능만 있는 것은 아니다. 분산 환경에 산재된 데이터 블록으로 최적화한 분석 처리를 하는 맵리듀스와 합쳐지면 엄청난 성능을 발휘한다.