하둡 파일 시스템의 이기종 스토리지 지원 모델의 진화

This article is based on Hortonworks Partner Content and Expertise

하둡 2.0은 기존의 하둡 1.0과는 전혀 다른 아키텍쳐라는 의견들이 많습니다.
이러한 빠른 발전때문에 오히려 초창기부터 하둡을 접했던 아키텍트들은 이러한 많은 변화를 수용하는 데 어려움을 많이 느끼고 있다는 생각이 듭니다.

그 동안 데이터를 처리하는 YARN(Yet Another Resource Negotiator)의 관점에서 많은 토픽을 잡았지만 사실 하둡 파일 시스템 자체도 많은 컨셉의 변화가 있었습니다.

그 동안 다뤘던 부분은 다음과 같습니다.
하둡 파일 시스템의 새로운 아키텍쳐
하둡 파일 시스템을 기업의 다양한 스토리지 환경에 적용하는 방법

전통적으로 하둡 파일 시스템은 균일한 로컬 하드디스크에 초점을 두고 만들어졌습니다.

대용량 파일을 일정한 단위(Data Block)로 쪼개서 많은 서버의 로컬 하드디스크에 저장하고 분석을 위한 코드를 직접 이 서버에 보내서 각 서버 상에서 분석을 실행한다

아마 일반적으로 하둡에 대한 이미지는 위의 컨셉을 기반으로 하고 있습니다.
하지만 엔터프라이즈 환경은 많은 다양한 스토리지 시스템에 대한 투자가 이미 이루어져 있으며 최근에 이른바 메모리 기반 스토리지(Full SSD Stoage) 등이 보다 신속하고 실시간 분석을 위해서 도입이 되고 있습니다.

하둡 파일 시스템은 본격적으로 엔터프라이즈의 이러한 니즈에 대응하기 위해서 기업의 다양한 스토리지 환경을 최대한 이용해서 최고의 성능을 낼 수 있도록 진화를 했습니다.

heterostorage

위의 다이어그램에서 보는 것처럼 워크로드에 따라서 메모리, SSD Storage, 하드디스크 그리고 분산파일시스템의 스토리지까지 이른바 이기종(Heterogeneous) 환경을 지원하는 형태로 변화했습니다.

최근에는 각 서버의 메모리 용량이 커지고 가격도 지속적으로 하락하여 처리 속도를 향상시키기 위해서 메모리를 캐싱(Caching Storage) 스토리지로 이용하고자 하는 니즈가 더욱 커졌습니다.

현재는 이른바 요청이 많은 파일(hot file)에 일종의 태그(Tag)를 붙임으로써 이러한 파일이 캐싱이 되는 형태로 구현이 되어 있습니다.

하지만 앞으로는 파일의 사용 패턴에 따라서 이 과정을 자동화하기 위한 연구가 계속되고 있으며 하둡 에코시스템의 성능을 전반적으로 향상시키기 위해서 많은 노력을 기울이고 있는 분야입니다.

그 중에서 핵심적이라고 할 수 있는 DDM(discardable distributed memory)라는 새로운 컨셉에 대해서 잠깐 더 살펴보고자 합니다.

향후 실시간 분석에 대한 니즈가 커지고 분석 성능을 향상시키고 기존의 인프라 투자를 최대한 효율적으로 이용한다는 여러 가지 측면에서 반드시 검토해 볼 필요가 있습니다.

DDM의 목적은 메모리 스토리지를 추상화시켜서 하둡 에코시스템 및 어플리케이션이 이용할 수 있도록 하는 형태로 제공하는 것입니다.

DDM은 SSD 스토리지를 이용하는 정책 등과 함께 연동되어서 위의 다이어그램에서 본 것처럼 이기종 스토리지를 충분히 활용하기 위해서 메모리를 스토로지의 한 형태로 제공하는 기술입니다.

보다 자세한 사항은 아래 페이지를 참조하시기 바랍니다.
HDFS-5851

이러한 기술들은 워크로드의 데이터 니즈에 따라서 가장 효과적인 스토리지로 데이터를 자동으로 옮기는 이른바 스토리지 티어링(Storage tiering)을 위해서도 핵심적인 요소입니다.

이기종 스토리지의 동작 방식은 다음과 같습니다.

- 데이터노드(Datanode)는 데이터 블록을 저장할 스토리지의 타입을 인식하여 이것을 네임노드(NameNode)에 리포트합니다.

- 네임노드는 각 데이터블록의 위치뿐만 아니라 각 데이터노드가 관리하는 스토리지의 타입도 지속적으로 추적해서 업데이트합니다.

- 클라이언트는 데이터 블록의 위치와 더불어 저장되어 있는 스토리지 타입에 대한 정보도 네임노드를 통해서 얻게 됩니다.

이러한 이기종 스토리지 지원을 통해서 다양한 용도에 이 모델을 적용할 수 있습니다.

1. 특정 어플리케이션은 파일을 생성하고 이 파일을 구성하는 데이터 블록(Data Block)을 특정한 스토리지 타입에 저장되도록 지정할 수 있습니다.

예를 들어, 3개의 복제 데이터 중에 2개는 일반적인 하드디스크에 저장하고 1개는 빠른 SSD타입 스토리지에 저장되도록 세팅할 수도 있습니다.
이러한 세팅은 기존의 값비싼 SSD 타입 스토리지의 투자를 충분히 활용할 수 있습니다.

2. 특정 어플리케이션은 어떤 파일의 저장 스토리지를 다른 타입으로 변경해서 저장할 수 있습니다.

즉, 일전에는 분석 작업의 주기가 길어서 하드디스크에 저장했던 데이터를 분기나 혹은 특정 시기에 빠른 분석이 필요할 때 SSD와 같은 빠른 스토리지 타입으로 옮긴 이후에 작업을 진행할 수 있습니다.

3. 하둡 시스템 관리자는 각 스토리지 타입별로 쿼터(Quata)를 지정해서 효율적으로 관리할 수 있습니다.

4. 파일에 대한 액세스 패턴(Access Pattern)에 따라서 가장 많이 쓰이는 데이터를 가장 빠른 스토리지로 자동으로 옮기도록 세팅할 수 있습니다.

하둡 파일 시스템은 엔터프라이즈 데이터 플랫폼으로 진하하는 데 반드시 필요한 스토리지 자원의 극대화에 대해서도 점차 완전하게 지원하는 쪽으로 진화하고 있습니다.

이러한 진화에 대해서는 앞으로도 자주 소개하도록 하겠습니다.

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

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

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