[빅데이터]HDFS와 Cloud Storage 비교 & 장단점

https://cloud.google.com/blog/products/storage-data-transfer/hdfs-vs-cloud-storage-pros-cons-and-migration-tips

HDFS vs. Cloud Storage: Pros, cons and migration tips | Google Cloud Blog

* 위 글을 참조하여 작성되었으나, 주관적인 생각이 녹아있습니다. 물론 위 링크의 글도 객관적이라고 할 수 없습니다만, 아래 글을 읽다가 불편하시다면 위 글을 참고하시면 좋을 것 같습니다.

 

---

클라우드 시대의 Bigdata 시장의 변화 

최근의 Hadoop 진영의 두 회사, Cloudera와 Hortonwork의 합병과 함께 몇 가지 의구심들이 떠오르고 있습니다. 두 회사의 합병은 기술적 시너지를 내기 위한 것이라는 내부 발표가 있었음에도 불구하고 말입니다.

Hadoop File System이 공식적인 사망선고를 당한 것인가? 
(참고 : https://www.datanami.com/2018/10/18/is-hadoop-officially-dead/) 

 두 회사의 합병 사실을 둘러싼 이야기들은 클라우드 서비스를 제공하는 IT공룡들(AWS, MS, Google Cloud 등) 이 공격적으로 마케팅하면서 반복적으로 이야기되고 있습니다. 그리고 모두 이러한 시장 분위기에서 무엇이 정답인지 확신 있게 말할 수 있는 사람들은 거의 없는 것으로 보입니다. 이미 많은 보고서에서 Cloud Storage(GCP에서 제공하는 서비스이지만 이 글에서는 AWS S3와 MS WASB를 포괄한 의미로 사용하겠습니다.)를 사용하면 기존에 on-primise에서 사용하는 hadoop storage 비용을 줄일 수 있다고 이야기하고 있습니다. 그리고 동시에 cloud storage들이 로컬에 구성된 HDFS를 빠르게 대체하고 있습니다. 이런 분위기에서 두 회사의 합병은 기대보다는 걱정이 더 많이 드는 것이 사실입니다. CloudEra가 클라우드 시대가 도래하자 하향길을 걷고 있다니 참으로 웃픈 상황이 아닐 수 없습니다. 

 HDFS는 Hadoop Stack의 근본이자 근간이 되는 컴포넌트 입니다. Hadoop(HDFS+YARN)을 나타내는 노란 코끼리가 실제로 Hadoop Stack과 가장 인기 있는 범용 처리 엔진인 Spark에서 계속해서 사용이 된다면 큰 문제는 없을 것입니다. 하지만 기존에 이를 사용하고 있던 Data Architects와 Engineers들은 Object Storage로 대체되고 있는 분위기가 조금 과장된 것이 아닌가 생각할 수도 있습니다. 새로운 기술에 대해 나름 개방적이라고 생각하는 저도 아직은 Cloud Storage의 활용에 대해서 보수적으로 생각하고 있으니까요. (참고 : https://www.caringo.com/blog/back-basics-object-storage) 

 

 그도 그럴 것이 HDFS와 Object Storage(이 글에서 말하고 있는 Cloud Storage들은 Object Storage 를 이야기한다)는 매우 다른 Data Storage Architecture를 가지고 있습니다. 그렇기 때문에 이미 HDFS의 개념을 가지고 개발된 많은 패러다임(컴포넌트, 플랫폼, 시스템 등)들이 이것 모두가 1:1로 Object Storage로 변경되지 않을 수 있습니다. 그렇기 때문에 이 것의 정확한 비교를 통해 HDFS와 Cloud Storage의 차이점이 무엇이고 과연 현존하는 시스템을 Object Storage로 대체할 수 있을 것인지, 가능하다면 그것의 trade-off는 무엇인지 알아야 할 것입니다. 

---

HDFS 대비 Cloud Storage 의 단점  

1. 데이터에 대한 I/O 분산variance이 큽니다. 
 > Cloud Storage는 연속된 데이터라고 하더라도 File/Block storage와는 다르게 연속해서 저장하지 않습니다. 이런 부분은 data locality에 문제가 발생할 수 있는데, HBase나 NoSQL을 사용하여 애플리케이션이 수행되는 경우가 이에 해당됩니다. 단순히 read I/O 분산이 큰 문제는 read-replica와 caching작업을 통해 이를 해결할 수 있습니다. 지속적으로 발생하는 write I/O variance라면 범용적인 목적으로 제공되는 Cloud storage를 사용하는 것이 아닌 별도의 서비스(Google Bigtable, AWS redshift 등)를 사용하여 데이터를 저장하는 것이 권장됩니다. 

2. 파일의 append / truncates가 필요한 경우 
 > Object Storage는 데이터를 하나의 object로 처리하기 때문에 object의 변경은 불가능합니다.  한번 upload 된 object는 변경을 위해서는 기존의 object를 삭제한 후 새로운 object를 생성해야 합니다. 이러한 이유로 실제적으로 점증적 incremental으로 변경사항을 object에 적용하는 것이 불가능합니다. 그리고 이러한 작업은 append 연산이나 truncate 연산에서 사용된다.  대신에 이 object 전체를 덮어씀으로써 incremental update를 대체할 수 있습니다. 

3. Application에서 POSIX 연산을 사용해야 하는 경우
 > HDFS도 엄밀히 말하면 모든 POSIX 를 제공해 주지 않습니다. 하지만 HDFS는 몇 년간의 성숙과정을 통해 많은 POSIX 연산을 지원해주게 되었고 이것은 Hadoop/Spark  애플리케이션에서 유용하게 사용되고 있어 
Coud Storage 로 데이터를 이관하는 데 있어서 장애가 될 수 있습니다. 예를 들어 Cloud Storage는 'rename' 작업을 원자적 atomic 하지 못합니다. 그 이유는 그들은 실제적으로 metadata에 대한 포인터이고 실제 directory가 아니기 때문입니다. 

3-1. 보안 도구에서 ACL 기능을 사용할 수 없습니다.
 > Directory metadata와 권한이 HDFS와 동일하지 않기 때문에 Ranger와 Sentry와 같은 Hadoop stack의 보안 컴포넌트는 이러한 HDFS 의 권한을 사용합니다. 이러한 application을 cloud storage로 이관할 때는 다른 방식으로 파일에 대한 보안 정책을 수립(IAM) 해야 하며, 모든 경우에 대해서 의도한 대로 동작하는지 확인할 필요가 있습니다. 

4. Cloud Storage는 File system 정보를 노출하지 않습니다.
> 만약 'hadoop fsck -files -blocks' 명령을 수행하게 되면 수행한 디렉토리에 대해 corrupted block이나 replica 정보와 같은 매우 중요하고 의미 있는 정보를 보여줍니다. 하지만 cloud storage는 전체 관리 레이어가 추상화되어 있기 때문에 구체적인 storage에 대한 정보는 확인할 수 없습니다. 하지만 Cloud Storage를 사용할 때에는 완전히 관리되는 서비스임으로 이것을 확인할 필요가 없을 수 있습니다. 

5. Cloud Storage는 응답성이 떨어집니다. 
> HDFS 에 비해서 round trip latency가 큽니다. 일반적으로 HDFS에서도 full-scan이 필요한 큰 규모의 ETL 작업들은 고려대상이 아닙니다. 파일 내부의 일부 데이터만 사용하거나, 작은 작업들 같은 경우 여러 개의 작은 파일들을 사용해야 하고 많은 파일들에 대해  연속적인 sequential 파일 시스템 연산이 이루어 지기 때문에 요청에 대해 지연 현상이 발생할 수 있습니다.

 

---

HDFS 대비 Cloud Storage의 장점   

1. 데이터 저장을 위한 가격이 현저히 낮습니다.
>  cloud storage 를 사용하게 되면 H/W 를 산정해서 일정 기간 동안 사용할 H/W를 구매하는 것보다 사용량에 대해서만 비용을 내면 됨으로 가격이 저렴합니다. HA를 위해 존재하는 replica에  대해서는 비용이 산정되지 않습니다. ESG(Enterprise Strategy Group의 연구에 따르면 HDFS를 사용해서 on-prime에 저장하는 것보다 cloud storage를 사용하는 것이 약 57% 정도의 비용이 절감된다고 한다. 

2. Storage 와 Computing 리소스를 분리할 수 있습니다. 
> Tear-down/up 에 유용하고 데이터 이동 없이 cluster를 생성하는데 유용합니다. 이러한 특성은 job-scoped cluster(특정 업무를 위한 클러스터)를 구성하는데 유리하다. 

3. 상호처리성이 높아집니다.
> 기존의 hadoop/spark cluster에서의 사용뿐 아니라, cloud 서비스업체(AWS, GCP, Azure 등)에서 제공하는 다양한 기능들을 병행하여 사용할 수 있습니다. 예를 들어 Export 된 cloud storage 파일은 google bigquery에서 임포트 될 수 있고 cloud storage는 쉽게 cloud data flow를 만들 수 있어 동일한 데이터에 대해 다양한 처리가 가능합니다. 
기존에 HDFS 사용하는 클러스터와 호환이 가능하고, 성능이 더 좋아질 수 있다고 합니다(구체적인 이야기는 없네요)  단순히 file uri의 prefix를 수정(hdfs:// -> s3:// , wasb://, gs:// )하는 것으로 기존의 경로를 쉽게 변환하여 대다수의 workload를 대체할 수 있습니다. 


4. 데이터에 대한 HA를 지원합니다. 
> Globally replicated 되기 때문에 (multi regional storage) SPOF 가 발생하지 않는다. 이것은 HDFS에서도 제공되는 기능임으로 큰 장점으로 보기 어렵습니다. 

5.  Storage 관리로 인한 오버헤드가 없습니다.
> 일반적으로 storage 서비스는 완전 관리형으로 서비스가 제공되어 사용자는 아무것도 관리할 필요가 없게 되는 것이 cloud 서비스의 장점입니다. GCP의 경우 관리적인 측면에서의 지원은 Google Site repliability engineering(SRE) 팀이 별도로 지원해준다고 합니다. 하지만 100명의 유저가 총을 서바이벌을 하기로 유명한 뭐 게임이 사용했던 A사의 cloud storage가 장애가 났었던 적이 있었죠. 

6. 빠르게 시작할 수 있습니다. 
> HDFS 같은 경우 전체 크기에 따라 Namenode가 올라오면서 safemode가 off되기 까지 시간이 걸리게 됩니다. (몇 초~몇 분)  Cloud storage 같은 경우 node 가 시작되자 마자 작업을 실행할 수 있습니다. Google cloud는 초 단위로 비용을 청구하기 때문에 빠르게 시작하는 것이 비용을 아낄 수 있다고 합니다. 

7. 자체작인 IAM을 제공합니다.
> GCP 보안 모델을 IAM을 통해서 적용할 수 있습니다. 그러므로 별도로 HDFS 상에서 권한을 관리할 필요가 없습니다. 자체 도구를 통해 쉽게 보안정책을 수립하고 적용할 수 있다는 장점으로 보아야 할 것 같습니다.  

8. Global 일관성을 제공합니다.
> Cloud Storage 는 global 하게 데이터 일관성을 보장합니다(data+metadata). 여러 site에서 복잡한 작업 없이 하나의 global 한 dataloke에서 작업할 수 있다는 점은 매력적입니다. 하지만 위에서 말한 지연 현상이 발생해서 사용성이 조금 떨어질 수도 있습니다.

---

결론 : 그러면 언제 우리는 HDFS를 Cloud Storage로 옮겨야 할까? 

- 아래의 경우가 아니라면 일반적으로 Cloud Storage를 사용하는 것이 유리하다고 합니다. 물론, 어떤 업체를 선택하냐에 따라서 사용성과 가격 모두 달라지겠지만 말이죠. 

1.  Hadoop 2.7 아래 버전의 Hadoop2를 사용하는 경우 
- Hadoop2.7 아래 버전의 FileOutputComiiter가 HDFS 에서 보다 Cloud Storage에서 더 느리게 동작합니다. 이것을 해소해주는 MAPREDUCE-4815가  hadoop 2.7에서 반영되었기 때문에, 그 이전 버전에서는 사용하는 것이 바람직하지 않습니다. 그러므로 hadoop 2.7 미만의 버전에서 HDFS를 Cloud Storage로 변경하기 위해서는 hadoop을 우선적으로 업그레이드해야 합니다. 

2.  작업의 성능이 일정하게 유지되어야 하는 작업이나, 빠르게 metadata나 작은 파일들에 접근하는 경우 
- Interactive한 작업은 다른 작업들보다 지연시간 latency에 민감합니다. 이러한 작업은 작은 파일들에서 계속해서 random -access read가 이루어지고 metadata에 대해서 연속적인 sequential 요청이 지연 현상을 가져오게 됩니다. 이때에는 HDFS를 사용하는 것이 좋습니다. 

3. POSIX 기능이 필요한 작업들 
- 작업들에서 원자atomic적인 directory rename이나 세밀한 HDFS 권한 또는 symlink가 필요한 경우는 HDFS를 사용해야 합니다. 

4. Table 또는 lookup values에 대한 참조가 필요한 작업
> 작은 부분의 데이터에 대해서 자주 반복적으로 쿼리 되거나 셔플 작업이 필요하지 않은 것에 대해서는 로컬 HDFS를 사용하는 것이 더 낫습니다.  HDFS는 자동으로 disk buffer cache를 사용하게 됩니다.

5/ 작은 데이터 셋에대해서 iterative 하게 수행되는 분석작업, reculsive 하게 이루어지는 작업
- 작은 데이터셋에 iteration이 많고, 전체 가용한 메모리보다 더 작은 공간을 사용해야 하는 경우들은 HDFS에서 disk buffer cache를 써서 더 빠르게 처리할 수 있다. 결론적으로 가장 좋은 방법은 일차적으로 Cloud Storage에서 데이터를 저장하고 해당 작업을 수행할 때 사용할 때 HDFS에 데이터를 가져와 처리하는 것이다. 

---