HDFS: Computing Resource와 Storage의 분리

Computing Resource와 Storage의 분리

Hadoop은 태생부터 분산파일시스템인 HDFS가 연산 프레임워크인 MapReduce와 독립적으로 사용될 수 있었다. 게다가 HDFS에 저장한 데이터를 분산처리 하기 위한 프레임 워크가 Map Reduce 밖에 없어 매우 경직되었으며 개방적이지 못한 상태였다. Hadoop v2에 들어서면서 YARN이라는 개방적인 프레임워크가 등장하였고 이를 토대로 Spark 등 많은 분석 환경이 YARN위에서 자유로운 scale-in/out을 하면서 동작하게 되었다. Spark 자원 관리는 mesos, YARN, standalone등 선택이 가능하지만 추가/제거되는 서버상황을 자동 인지하고 이에 맞추어 동작시키려면 YARN 기반하에 사용해야 한다.

hadoop을 구축하고 운영하면서 부딪히는 어려움 중 하나는 증가하는 Computing resource 사용량과 Storage capacity간의 조화이다.

구축 초기에는 대체로 데이터를 저장하기에 급급하다. 즉, Storage 사용량이 증가한다. 분석을 위해 더 많은 데이터의 저장을 요구하고 이에 따라 새로운 데이터를 정의하고 수집한다. 수집된 데이터를 탐색하고 중간 데이터들을 만들어 내면서 임시 파일과 테이블들이 급격히 증가하게 된다. 이러한 상황은 대개 데이터 거버넌스가 제대로 동작하지 않거나 그 정도의 기간에 미치지 못한 경우가 많다. 또한 분석가들이 빅데이터에 익숙하지 않은 채 이것 저것 해 보는 경우가 있다. CPU 사용량은 비정기적으로 튀고 있으며 누군가는 자원을 독점하여 문제를 일으키기도 한다. 그러다 보면 Storage가 모자라게 된다. 그러나 CPU와 메모리 사용량은 크지 않은 경우가 많다. 그래서 Storage를 늘리기 위해 hadoop node를 늘린다. CPU, 메모리 역시 같이 늘리게 된다. 클라우드에서야 점진적인 확장이 가능하지 On-premise에서는 한두대씩 사는 것이 가격 결정력을 떨어뜨리기 때문에 대개 계단형으로 늘리게 된다.시간이 지나 분석가들이 하나 둘씩 늘어나고 정규 배치작업들이 구동하기 시작하면서 이제는 CPU, 메모리 등 컴퓨팅 자원이 부족해 지게 된다. 역시 늘릴 필요도 없는 Storage와 함께 늘리게 된다. 이러한 문제는 aws라면 S3가 있기에 애초에 고민할 필요도 없다. 그러나 On-premise에서는 상황이 다르다. S3와 같이 규모의 경제를 만들어 주는 저렴한 스토리지는 없다. EMC, NetApp, Pure Storage 등의 스토리지는 기존 hadoop 구축 비용과 비교가 불가할 정도이다. 또한 이러한 구조는 대용량의 bandwidth를 갖는 네트워크 스위치가 필요하다.

하나의 hadoop 클러스터로 모든 것을 하기에는 위험하다.

hadoop 클러스터는 데이터 수집 및 저장, 분석 그리고 서비스용 데이터 제공까지 다양한 역할을 수행한다. 이러한 역할로 인해 클러스터에 설치되는 SW 역시 다양하다. 각 역할간의 자원 경합, 각 SW 간의 간섭 등 하나의 거대한 클러스터로는 운영에 있어 위험 요소가 너무나 다양하고 복잡하다. 따라서 데이터 플랫폼과 이를 운영하고 사용하는 조직이 발전하면서 클러스터는 용도별로 분리되고 있다.[1]

• 분석용 클러스터: 컴퓨팅 자원을 주로 사용하며 사용자간 자원 분배가 중요
• 데이터 입수/저장용 클러스터: 스토리지 위주이나 데이터 입수에 장애가 발생하지 않도록 하기 위해 입수용 자원은 일정 수준을 보장해야 함.입수에 필요한 배치 작업의 수행 시간 임계치 등 설정 필요
• 서비스용 클러스터: SLA(응답시간, 정기점검 등) 필요. 분석, 모델링 등과의 자원 경합에서 독립적이어야 함
• 명확히 대용량의 스토리지가 필요한 경우를 제외하고는 hadoop이 필요없을 수 있음

Computing resource와 Storage를 분리하는 것은 어떠한 가능성을 가지고 있을까?

• 효과적인 증설: Storage를 반드시 고가의 All flash가 아닌 기존 서버 기반의 hadoop이라고 해 보자. 여전히 hadoop은 서버 기반이기에 함께 늘려야 한다는 생각을 버리고 CPU와 메모리만 탑재된 랙 공간을 효과적으로 사용할 수 있는 서버를 꽂는다. 그렇다면 hadoop의 사용성을 유지하려면 무엇을 해야 하는가? 네트워크 구간을 확장해 주어야 한다. 이것을 기반으로 비교적 합리적인 분리가 가능하다. 그렇다면 hadoop의 최대 장점이라 여겨지는 data locality는 어떻게 되는가? data locality가 중요시 여겨지던 때는 네트워크가 디스크 속도를 따라오지 못할 때다. 또한 MapReduce는 연산 작업을 작게 쪼개고 이를 해당 데이터가 존재하는 곳에서 구동시킨다. 두 번째 연산 부터는 어떻게 하나? disk locality와 별 관계가 없어진다. 한편 Spark을 주로 사용하는 환경에서 data locality는 MapReduce 환경에 비해 크게 문제가 되지 않는다. Disk에서는 어차피 한번 읽어 오면 된다. 그래서 네트워크가 확보되면 data locality로 인한 문제는 상당히 감소될 수 있다.[1][2]

Thus, as observed previously, reads from local disk are comparable to reads from local network. Figure 1 confirms this by showing that the bandwidth difference is about 8%. (실험 결과 로컬 디스크에서 읽는 것과 로컬 네트워크에서 읽는 것은 8% 정도의 대역폭 차이를 보인다.)

• 분석용 SW의 빠른 릴리즈, 빠른 업데이트: 2019년 초인 현 시점에서 볼 때 한 가지는 여전히 빠르게 릴리즈 되고 있는 분석, 모델링용 SW의 신속한 업데이트가 있다고 할 수 있다. Tensorflow는 많으면 한달에 2번 이상 릴리즈 되고 있다. 신규 기능들이 나오고 새로운 알고리즘들이 배포되면 분석가들은 사용해 보고 싶어하고 그것을 통해 자신이 만든 모델의 성능을 높이고 싶어한다. Spark는 어떤가? 지난 3월말 2.4.1버전의 릴리즈까지 거의 매달 릴리즈가 되고 있다.

5 References

[1] Architecting Modern Data Platform, 2018, Lars George, Jan Kunigk, Paul Wilkinson, Ian Buss

[2] Disk-Locality in Datacenter Computing Considered Irrelevant, 2011, Ganesh Ananthanarayanan, Ali Ghodsi, Scott Shenker, Ion Stoica, University of California, Berkeley

[3] Decoupling Storage and Computation in Hadoop with SuperDataNodes, 2010, George Porter, UC San Diego