Hadoop 3 버전을 도입해야하는 3가지 이유

하둡은 1.0을 시작으로 2.0버전을 넘어 현재는 3.3버전까지 릴리즈가 되어 있습니다.

이렇게 많은 버전업이 진행되는 기간 동안 더 이상 하둡은 새로운 것이 아닌 빅데이터의 기반으로 자리 잡았습니다.

그리고 아직까지는 많은 곳에서 하둡 3 버전보다는 2버전을 많이 사용하고 계시리라 예상됩니다. 

그래서 이제는 하둡 2버전에서 3버전으로 넘어가야하는 이유에 대해 이야기해보려 합니다.

 

Erasure Coding

하둡이 3버전으로 업그레이드 되면서 가장 눈에 띄었던 특징 중에 하나는 Erasure coding(EC)이 도입되었다는 것입니다. 기존 2버전의 하둡은 Hot data든, Cold data든 모두 같은 복제 정책(기본 3copy)을 가지고 보관해야만 했습니다. 이런 3copy 데이터 보관은 Fault tolerance을 보장해주고 분산처리에서 Read 성능에 장점이 있긴 하지만 디스크 효율 측면에서는 보관하고자 하는 데이터의 3배의 디스크 공간이 필요했기에 큰 단점으로 작용하였습니다. 이러한 단점을 보완하고자 나온 것이 Erasure Coding(EC) 입니다.

 

EC를 통해서 저장할 데이터의 3배 달하는 디스크 공간이 필요하던 것을 약 1.4배의 디스크 공간만 필요하도록 구현하였습니다. EC는 RAID5와 유사한 방식인 Parity cell을 이용하여 3copy와 거의 유사한 Fault tolerance를 보장합니다. 이러한 EC를 통해서 모든 데이터 또는 Cold data를 보관한다면 HDFS를 저장하기 위한 디스크 비용을 현저히 낮출 수 있을 것 입니다.

 

Observer Namenode

하둡 3버전에는 Observer Namenode(ONN)라는 새로운 Namenode 역할이 등장했습니다. ONN은 이름 그대로 관찰자의 역할을 하는 네임노드 입니다. 그러면 이 ONN이 하는 역할은 무엇일까요?

 

바로 기존에 Active Namenode 혼자 하던 Read Operation에 대한 클라이언트 요청 처리를 분산하여 처리해주게 됩니다. HDFS는 데이터 블록이 많아질 수록 네임노드에 걸리는 오버헤드가 커지게 됩니다. 따라서 점차 클러스터가 커져 단일 네임노드가 처리하기 버거워지는 블록 수를 가지게 되면 네임노드가 HDFS 성능에서 병목구간이 되어 버립니다. 그리고 ONN이 이러한 병목이 발생할 수 있는 부담을 분산해 주게 되는 것입니다. Observer Namenode를 도입하며 테스트하였던 분산효과에 대한 내용은 추후에 별도로 다루도록 하겠습니다.

 

HDFS Router-based Federation

HDFS Federation은 기존 하둡 2버전에서도 존재하던 기능이지만, 3번으로 넘어오면서 단순히 HDFS Federation이 아닌 HDFS Router-based Federation이 등장했습니다. 기존 HDFS Federation은 논리적으로 Namenode와 Namenspace를 추가하여 Datanode를 공유하여 subcluster를 추가하는 것과 같은 아키텍쳐였으나, 하둡3에서는 HDFS Router라는 역할이 추가되며 물리적인 클러스터간에 Federation이 가능하게 된 것입니다.

 

HDFS Router-based Federation Architecture        출처 : https://hadoop.apache.org/

 

다음과 같은 아키텍쳐를 가지고 있으며, HDFS Router가 클라이언트의 요청을 받아 각 요청에 적절한 클러스터의 Namenode를 호출하여 Datanode의 정보를 전달하게 되는 구조 입니다. 자세한 구조로는 State Store라는 역할도 존재하지만 좀 더 자세한 내용 역시 추후에 별도로 다루도록 하겠습니다. 기존 HDFS Federation에는 주요 하둡 컴포넌트와 호환성 문제가 있어 사용하지 못하였지만 HDFS Router-based Federation은 다른 컴포넌트와의 호환성이 어떠할지 도입전 필수로 검증은 필요할 것 같습니다. 하지만 이러한 호환성 부분만 검증이 된다면 분명 매우 매력적인 아키텍쳐임에는 분명한 것 같습니다.

 

결론

하둡 3를 도입해야하는 3가지 이유에 대해 이야기 해보았습니다. 한마디로 정리하자면 하둡2가 가지는 단점을 보완하고자 등장한 기능 입니다. 따라서 HDFS Router-based Federation과 같이 호환성 검증등의 문제만 해결된다면 넘어가지 않을 이유는 없어 보입니다. 이제 막 하둡 3.3까지 릴리즈가 되었기 때문에 아직 안정성 문제에서 이르지 않나 싶을 수도 있지만 하둡은 이미 많은 검증을 거쳐왔고 개인적으로 3.3 정도라면 슬슬 검토해보고 POC를 진행해보아도 나쁘지 않지 않을까하는 견해 입니다. 

 

이상으로 다음 글에서는 각각의 기능에 대해 좀 더 심도 있게 다뤄볼 수 있도록 하겠습니다. 끝.