Architecture Matters

Hadoop 을 활용한 성공적인 운영을 위해서는 플랫폼이 데이터를 레코드 체계로 저장하고 애플리케이션을 연중 무휴로 실행할 뿐만 아니라 나머지 엔터프라이즈 데이터 아키텍처 및 툴과 간편하게 통합이 가능해야 합니다. MapR 은이러한기능을즉시사용할수있는 유일한 배포 프로그램이며, 이를 달성하기 위한 방법의 핵심이 바로 아키텍처입니다. M.C.
MapR CTO, M.C. Srivas talks about
the MapR architecture

일반 시판용 서버를 사용해 신뢰성과 성능이 높은 클러스터를 구축하려면 막대한 엔지니어링 작업이 요구됩니다. 해당 클러스터에서 실행되는 데이터와 서비스에 고가용성을 제공하고 노드 장애 시 완벽하게 보호하여 전체 클러스터 성능에 영향이 없도록 해야 합니다. 일반 시판용 서버를 토대로 그처럼 빠른 속도와 신뢰성을 달성하기는 한층 더 어려운데, 이중화된 데이터 경로, RAID 구성 구축을 위한 비휘발성 RAM 또는 노드 사이의 특화된 접속이 빠져 있기 때문입니다.

일반 시판용 하드웨어로 신뢰성을 달성하려면 복제 기능을 사용해야 하는데, 그러면 여러 개의 중복된 데이터 사본이 저장됩니다. 정상 작동 시 클러스터는 들어오는 데이터를 가능한 한 신속하게 쓰고 복제하고, 일관성 있는 읽기를 제공하고, 메타데이터 및 서비스 정보 또한 중복 관리되도록 해야 합니다. 충돌이 발생하면 복제본을 복구하여 재동기화할 때까지 고객은 데이터 손실에 노출됩니다. MTTDL(데이터 손실 간평균시간)이이복구와관련된측정 기준입니다. 기본적으로 전체적인 클러스터 성능과 신뢰성에 영향이 미치지 않도록 손실된 복제본을 즉시 재동기화하여 MTTDL 을 극대화하는 것이 목표입니다.

HDFS 솔루션

HDFS 는 이 문제에 대해 다른 방식으로 접근합니다. HDFS 는 모든 것을 읽기 전용으로 설정하여 핵심적인 문제점을 완전히 우회하며, 재동기화는 주요 사항이 아닙니다. 파일당 하나의 쓰기가 가능하고 쓰기 작업 중에는 파일 읽기가 허용되지 않으며, 파일 닫기는 읽기 작업에서데이터를볼수있도록하는 트랜잭션입니다. 장애가 발생하면 닫히지 않은 파일은 삭제됩니다. 변경된 데이터를 본 사람이 없으면 이를 삭제해도 된다는 가정에 따른 모델입니다. 마치 데이터가 전혀 존재하지 않았던 것과 같습니다.

이 접근 방식은 웹 크롤링이라는 HDFS 의 원래 목적을 만족시키는데, 이 경우 다운로드한 웹 페이지가 분실되면 다음 번 크롤링에서 다운로드됩니다. 그렇지만 대규모 기업의 CIO 또는 CFO 가 중요한 비즈니스 정보에 대해 이런 모델을 시도하려 할까요? 아무도 데이터를 읽지 않으면 전혀 존재하지 않았던 것이라고 정말로 말할 수 있을까요? 분명 그렇지 않을 것입니다.

HDFS 의 제한적인 의미 체계는 역시 몇 가지 문제점을 드러냅니다.

HDFS 에서 실시간은 가능하지 않습니다. HDFS 에서 데이터가 표시되도록 하려면 쓰기 후에 즉각 파일을 닫아야 하므로, 적은 양을 쓰고 파일을 닫는 식의 프로세스를 반복해야 합니다. 문제는 HDFS 는 중앙 집중식 메타데이터 스토리지 아키텍처이기 때문에 너무 많은 파일을 생성하게 되는데, 이는 문서화되었을 정도의 심각한 문제점입니다.

또한 HDFS 는 NFS 를 통해 읽기-쓰기를 완벽하게 지원할 수 없는데, HDFS 에 대해 쓰기를 할 때에는 NFS 프로토콜이 파일에서 “닫기” 작업을 호출할 수 없기 때문입니다. 이러한 한계는 파일을 닫을 시기를 HDFS 가 추측해야 한다는 것을 의미합니다. 추측이 틀리면 데이터가 손실됩니다.

이제 핵심 파일 시스템 기능을 유지하면서 이러한 문제점을 해소할 다른 접근 방식이 필요하다는 점이 분명해졌습니다.

복제본을 얼마나 빨리 다시 온라인 상태로 만들어야 할까?

먼저 데이터를 재동기화하는 데 실제로 얼마나 걸리는지 살펴보겠습니다. 예를 들어 서버에 24TB 가 있다고 가정합니다. 24TB 는 사실 한 대의 서버에 드라이브가 12 개 있고, 각각의 크기는 2TB 입니다. 초당 1GB 속도라면 재동기화하는 데 7 시간이 걸립니다. 그렇지만 실질적으로는 처리량이 200MB/s 여서 실제로는 35 시간이 걸린다는 뜻이 됩니다. 이를 온라인 상태에서 수행하려면 재동기화 속도를 1/10 로 조절해야 할 것이고 그러면 재동기화에 350 시간(15 일)이 걸린다는 뜻이 됩니다.

그렇다면 MTTDL(데이터 손실 간 평균 시간)은 얼마일까요? 3 년에 한번씩 드라이브에 장애가 생긴다고 할 때, 드라이브의 MTTF(고장 간 평균 시간)는 3 년입니다. 이제 클러스터에 노드가 100 개 있고, 각 노드에 드라이브가 10 개 있다고 하면 클러스터에 드라이브 1000 개가 있는 것입니다. 드라이브가 고장 나는 데 3 년이 걸리면 매일 고장 난 드라이브가 생겨버리는 것입니다. 그러면 디스크 2 개 또는 3 개가 고장 나면 얼마나 오래 기다려야 할까요? 이미 또 다른 드라이브 15 개가 고장 나 있는데 재동기화하는 데 정말 15 일이나 기다릴 수 있을까요? 그런 속도라면 십중팔구 데이터가 손실될 것입니다.

기존 솔루션

이와 같은 신속한 재동기화의 문제점에서 한 발짝물러선기존접근방식은유휴스페어를 갖춘 RAID-6 를 실행하는 듀얼 포트 디스크를 사용하는 것입니다. 듀얼 포트 디스크 어레이는 각 포트에 서버 하나씩, 두 대의 서버에 연결됩니다. 이들 서버는 NVRAM, 즉 비휘발성 RAM 을 사용해 디스크를 관리합니다. 운영 서버는 NVRAM 을 끊임없이 복제본 서버로 복제합니다. 운영 또는 복제본 서버에 장애가 생기면 다른 서버가 작업을 인계하며 재동기화할 대상은 없습니다. 드라이브가 작동하는 데 필요한 것이 모두 있기 때문입니다. 이 시나리오를 실행할 수는 있지만 다년간의 예비부품계획이포함된대규모구매계약을 체결해야 하기 때문에 확장성이 없습니다.

더구나 앞에서 설명한 솔루션의 경우 성능 문제가 발생하는데, SAN 또는 WAN 이 데이터베이스에 연결되어 있고, 이 데이터베이스에 많은 애플리케이션이 연결되어서 처리 수요가 발생한 곳으로 데이터가 끊임없이 이동하는 기존 아키텍처로 되돌아가야 하기 때문입니다. 이러한 모델은 변화하는 요구에 맞춰 높은 성능을 제공하지 않습니다. 고객에게 정말 필요한 것은 분산 스토리지, 그리고 데이터상에서 기능이 로컬로 실행되고 시스템은 지리적으로 분산된 위치를 포함해 극한까지 원활하게 확장되는 Hadoop 과 같은 처리 플랫폼입니다.

MapR 솔루션

MapR 은쓰기를하면그즉시표시되는일반 파일을 구현합니다. 하지만 일반 시판용 하드웨어를 사용해 높은 속도와 신뢰성 수준에서 재동기화 문제를 해결하고자 MapR 은 새로운 아키텍처를 만들었습니다.

컨테이너 아키텍처

MapR 은 각 노드의 데이터를 컨테이너라고 부르는 작은 조각 1000 개로 자릅니다. 이러한 컨테이너는 클러스터 간에 복제됩니다. 예를 들어 100 개의 노드로 구성된 클러스터가 있고 각 노드의 데이터를 1000 개로 잘라 고르게 배분합니다. 그러면 각 노드는 모든 노드 데이터의 1/100 을 보유하게 됩니다.

서버에 장애가 생기면 전체 클러스터는 해당 노드 데이터를 재동기화합니다. 이러한 동기화 방식의 속도는 얼마나 될까요? 병렬로 재동기화하는 노드가 99 개 있고, 따라서 드라이브 99x 개, 이더넷 포트 99x 개, CPU 99x 개, VRAM 모듈 99x 개가 됩니다. 각 노드는 데이터의 1/100 을 재동기화합니다. 그래서 실제 속도는 약 100x 수준입니다. 즉, MTTDL 이 100 배 가량 우수합니다. 클러스터 크기가 커질수록 이 MTTDL 도 더 우수해집니다. 노드가 1000 개인 클러스터의 경우 MTTDL 은 실제로 1000 배 가량 우수합니다.

극한 조건에서도 컨테이너 재동기화

MapR 은 극한 조건에서도 높은 속도로 컨테이너를 재동기화합니다. 예를 들어 그림에 나오는 3 개의 컨테이너의 경우 3 개의 복제본이고, 이들 복제본은 동기화가 진행 중입니다.이들중하나에장애가생기면그리큰 문제는 아닙니다. 나머지로 해당 복제본을 되살릴 수 있기 때문입니다. 그렇지만 이 3 개가 한동안 실행되다가 결국 모두 작동이 중단된다고 가정합니다. 클러스터 내에서 동시에 실행되는 다양한 작업이 아주 많으므로 이 3 개가 모두 서로 다른 방향으로 분기할 가능성이 큽니다. 그렇다면 이제 복구는 했는데 어느 것이 마스터가 되느냐가 문제입니다.

직접적인 문제는 어느 복제본이 작동 중단을 견딜지 모른다는 것입니다. 어느 것이 되돌아 올까요? 그래서 소프트웨어가 완전히 무작위로 복제본중하나를새로운마스터로만들수 있어야 합니다. MapR 의 혁신 기술과 특허는 매우 까다로운 이 컴퓨터 공학적 문제의 해결을 중심으로 전개됩니다.

기본적으로는 회신된 모든 쓰기가 동작 중단을 반드시 견디도록 해야 합니다. MapR 은 초당 2GB 의 업데이트 속도에서도 복제본이 분기할 정확한 시점을 감지하는 기능을 갖추고 있습니다. MapR 은 세 복제본 중 하나를 새 마스터로 무작위로 선택하고, 나머지 중단되지 않은 복제본은 분기 시점으로 롤백한 다음, 선택한 마스터와 함께 분기하도록 롤포워드할 수 있습니다. MapR 은 정상 작업에 거의 영향을 미치지않고순식간에이작업을수행할수 있으며, 그렇게 하기란 매우 까다롭습니다.

컨테이너 아키텍처 활용

MapR 은 이 혁신적인 아키텍처를 적극 활용하여 Hadoop 사용자에게 독자적인 기능 집합을 제공합니다.

비 NameNode

MapR 컨테이너 아키텍처는 메타데이터 저장 면에서 NAS, SAN 또는 HDFS 방식보다 뛰어납니다. MapR 은 NameNode 데이터를 가져와 클러스터에 배열하고, NameNode(아래 그림 왼쪽에 있는 회색 영역) 내부에 무엇이 있든 이를 일반 클러스터로 이동했습니다. MapR 의 비 NameNode 솔루션을 통해 이제 모든 것이 3 중으로 존재하고 신뢰성이 극도로 높아졌습니다. 비 NameNode 의 경우 MapR 에 저장할수있는파일수에사실상제한이없어서 엑사바이트 단위로 중단 없이 확장할 수 있습니다. 이 솔루션의 추가적인 주요 이점은 규모에따라변화하는파일수제한을여러개의 NameNode 로 처리해야 하고 여러 대의 액티브/스탠바이 서버로 NameNode HA 를 구축해야 하는 HDFS 에 비해 클러스터 내부의 하드웨어가 적어서 비용이 훨씬 저렴하다는 것입니다.

진정한 고가용성 클러스터

모든 Hadoop 구성 요소 역시 고가용성이 지원됩니다. 예를 들어 Apache YARN 의 경우 ApplicationMaster(기존의 JobTracker)와 TaskTracker 가 구성 요소의 상태를 MapR 에 기록합니다. 노드 장애 시 ApplicationMaster 는 MapR 에서 구성 요소의 상태를 복구합니다. 이처럼 MapR 은 독자적인 방식으로 모든 작업이 동작 중단 이전에 위치해 있던 상태에서 재개될 수있도록 해 줍니다.이방식은전체 클러스터가 다시 시작되는 경우에도 유효합니다. 따라서 80% 정도 진행된 작업이 있는데 클러스터가 중단된다면 다시 회복되면 80% 이후부터 계속 작업이 진행됩니다.

MapR 고유의 HA 라는 이점을 고객의 코드에 활용하는 것 역시 정말 간단합니다. 서비스 상태와 데이터를 MapR 에 저장하고, Zookeeper 를 사용해 서비스 장애를 알리고, 어디서든 서비스를 다시 시작할 수 있습니다. 그러면 데이터와 상태가 해당 위치로 자동 이동합니다. MapR 을 사용하는 경우에만 Impala, Hive, Oozie, Storm, MySQL, SOLR/Lucerne, Kafka 에서 HA 를 구현할 수 있습니다. 여기서 중요한 점은 Hadoop 에코시스템의 각 프로젝트를 위한 일회용 솔루션에 그치는 것이 아니라는 것입니다. HA 는 기본적인 인프라 그 자체이고, 코드를 통해 할 수 있는 것과 똑같이 Hadoop 의 모든 부분에서 이용할 수 있습니다.

성능및확장성비교

다음 그림은 100 바이트를 쓰고 파일을 닫는 NameNode 벤치마크를 나타냅니다. HDFS 의 실시간 성능에 문제가 있음이 분명하게 드러납니다. 테스트에서는 많은 파일을 쓰고 이를 즉시 닫습니다. 노드 10 개인 클러스터에서 테스트를 수행했습니다. 파란색 선은 MapR 성능을 나타내고, 아래쪽의 빨간색 선은 HDFS 기반 배포 프로그램입니다. X 축은 생성된 파일 수이고, Y 축은 초당 생성된 파일 수를 나타냅니다. MapR 이 여타 배포 프로그램 대비 40 배 우수합니다. HDFS 성능이 두 배, 세배 또는 네 배가 되더라도 MapR 이 여전히 10 배 이상 빠릅니다.

속도 면에서 MapR 은 MapReduce 세계 기록을 보유하고 있습니다. TeraSort 기록은 1TB 를 얼마나빨리정렬할수있는지에대한 기록입니다. MapR 의 최신 기록은 45 초입니다! MinuteSort 기록은 1 분 동안 얼마나 많이 정렬할 수 있는지를 측정하는 또 다른 벤치마크입니다. MapR 은 이 부문 최고 기록도 보유하고 있습니다.

데이터 직접 보관이 허용되는 MapR 의 NFS

MapR 아키텍처는 읽기-쓰기 파일 시스템 기능을 유지하고 또 이용하여 클러스터 액세스를 위한 표준 NFS 인터페이스를 제공하므로, 특별한 커넥터 없이도 클러스터에 데이터를 직접 보관(deposit)할 수 있습니다. 웹 서버든, 아니면 데이터베이스 서버나 애플리케이션 서버든 이들 서버는 매우 빠른 속도로 MapR 에 직접 데이터를 덤프할 수 있습니다. MapR 은 완벽하게 HA 를 지원하는 거대한 NFS 서버처럼 작동할 수 있습니다. 이러면 데이터를 Hadoop 에 넣는 데 드는 시간과 노력이 크게 절약됩니다. MapR 을 사용하면 중간단계를거칠필요없이곧바로 실행할수 있습니다.

MapR M7 Enterprise Database Edition 테이블

MapR 은 MapR M7 Enterprise Database Edition 에 데이터베이스 테이블을 도입했으며, 이 테이블은 Apache Hbase 와 호환되고 여러 가지 경로 이름을 사용해 간편하게 액세스할 수 있습니다. M7 만의 독특한 특징은 이 테이블이 스토리지 시스템에 통합된다는 것입니다. 테이블이 컨테이너 아키텍처 기반으로 구축되어서 모든 노드에서 항상 사용할 수 있고 100% 데이터 인접성(locality)을 제공합니다. 데이터베이스 테이블에 대한 추가 관리가 필요하지 않고 테이블 수가 무제한이어서 역시 조 단위까지 테이블 수를 중단 없이 확장할 수 있습니다. 더 중요한 점은 MapR 이 구축된 상태에서 업데이트가 가능하기 때문에 압축 작업을 하지 않아도 된다는 것입니다. 이러한 기능 때문에 MapR 은 5 배 우수한 성능과 탁월한(95 백분위수 및 99 백분위수) 대기 시간을 제공합니다.

결론

MapR 은 임기응변식 소프트웨어 패치를 통해서는구축할수없는강력한기본 아키텍처를 기반으로 하는 Hadoop 분야의 기술 리더입니다. 여기서 적절한 사례를 들면, 지난 수년간 여타 배포 프로그램(모두 HDFS 기반)은 최적수준에못미치는포인트솔루션을통해 MapR 플랫폼의 핵심 기능을 따라잡고자 했습니다. NameNode 용 HA 솔루션 하나, JobTracker 용 또 하나, HBase 용의 완전히 다른 HA 아키텍처 등이었습니다. 더구나 이러한 솔루션들은 아무래도 불완전하고 다른 시도에서도 마찬가지여서 기초적인 엔터프라이즈급 기능을 보더라도 스냅샷이 지정 시간 복구를 제공할 수 없고 NFS 액세스는 읽기 전용이고 성능도 낮습니다.

연중 무휴로 가동되고, 최고의 성능을 제공하고, 작업하기 간편한 플랫폼을 필요로 하는 광범위한 빅 데이터 사용자의 요구에 부응하는 빅 데이터 플랫폼의 경우에는 아키텍처가 중요합니다. 저렴한 일반 시판용 하드웨어를 사용하면서도 즉각적인 재시작, 스냅샷, 미러링, 완벽한 이중화를 통한 엔터프라이즈급 신뢰성을 지원하고 NFS, ODBC 및 Hadoop 등의 표준 프로토콜에 대한 액세스를 지원하는 아키텍처 기능을 제공하는 것은 MapR 의 Hadoop 배포 프로그램뿐입니다.