Apache Ozone

서두

---

평소 업무를 하며 사내 빅데이터 플랫폼 아키텍처에 대해 고민할 일이 있었습니다.

클라우데라와 호튼웍스가 합병하며 Cloudera Data Hub (CDH), Hotenworks Data Platform (HDP)이 이번에 Cloudera Data Platform (CDP)로 통합되었고, 이는 무료로 사용할 수 없습니다. 변경된 사항을 정리하면 다음과 같습니다.

• CDH 와 HDP 는 CDP 로 통합되고, CDH 와 HDP 는 2021년까지만 유지한다.
• CDP 는 서크스크립션 계약을 한 경우에만 다운로드 가능하다.
• 기존에 On-presmise 로 운영중이던 하둡 플랫폼(CDH, HDP)은 변경되는 라이센스 정책에 영향받지 않는다

이에 On-presmise로 운영중인 하둡 플랫폼을 유지할 것이지 변화할 흐름에 맞춰 CDP를 도입할 것인지, 아니면 또 다른 무엇인가가 나올 때 까지 기다릴지 생각해봐야할 시기였습니다.

간단히 결론부터 말하면, CDP를 도입함으로서 얻게되는 이점은 다음과 같이 표로 정리할 수 있습니다.

하지만 HDFS Erasure Coding의 경우, 운영중이던 CDH6.2(Hadoop 3.0)에 도입하고 있는 상황이며 Virtual Private Clusters의 경우에도 CDH5.0부터 지원되던 아키텍처지만 매력적인 선택지는 아니었던지, 도입이 되고 있는 상황은 아니었습니다. 

하지만, 세번째에 보이는 Ozone Object Storage의 경우, 낯선 개념이었고 어떤 것인지 궁금하였기에 공부하게 되었습니다. 그리고 이번 포스트는 제가 궁금했던 부분을 위주로 정리해보려 합니다. Apache Ozone에 대한 자세한 내용은 Apache Ozone 공식문서와 여타 블로그에도 잘설명되어 있으니 한번쯤 찾아보시면 좋을 것 같습니다.

 

Apache Ozone

---

One billion files in Ozone

Apache 재단에서 개발하고 있는 Ozone의 모토이다. Apache Ozone은 small size와 large size file모두를 핸들링하는데 특화된 key-value기반 분산저장소입니다. Ozone은 HDFS의 small size file 저장과 관련한 scale limitation을 보완하기 위해 탄생하였습니다. 널리 쓰이고 있는 HDFS의 경우 Large size file(block size default 128mb)을 저장하도록 고안되었으며(이보다 작은 사이즈의 파일을 저장시 저장공간 비효율적 사용) Namenode에 권장 저장 파일수는 300milion입니다. 

무엇이 문제냐, 쉽게 한문장으로 짚어 본다면, 바로 HDFS의 저장 주소체계라고 할 수 있습니다. HDFS에서는 하나의 file을 한개의 block에 매핑하여 저장하며, 이때 발생하는 데이터는 namenode기준 발생하는 데이터는 해당 file data, file 저장 meta data,  inode data이며, 매 file마다 2개를 더 추가적으로 저장해야하는 구조입니다. 여기에 수많은 small size file을 저장한다면 더욱이 128mb *3의 저장공간을 비효율적으로 사용하게 되는 상황이게 됩니다. 

Ozone은 이러한 문제를 극복하기 위해 설계되었는데, 구조는 다음과 같습니다. 

출처 : https://docs.cloudera.com/runtime/7.0.3/ozone-storing-data/topics/ozone-architecture.html

기억할 것은 바로, block, storage container, datanode, SCM(storage container manager)입니다. block이 모여 container를 형성하고 container들은 datanode에 저장되며 SCM에 의해 관리됩니다. 

각 컴포넌트별 역할은 다음과 같습니다.

BlocksBlocks are the basic unit of storage. In Ozone, each block is of 256 MB in size. A collection of blocks forms a storage container. SCM allocates blocks inside storage containers for the client to store data.Storage ContainersA storage container is a group of unrelated blocks managed together as a single entity. A container exists in a DataNode and is the basic unit of replication, with a capacity of 2 GB to 16 GB.Ozone ManagerOzone Manager is the metadata manager for Ozone. Ozone Manager manages the following storage elements:

• The list of volumes for each user
• The list of buckets for each volume
• The list of keys for each bucket

In addition, Ozone Manager also handles metadata operations from client applications. The clients request for keys (file names) for performing the read and write operations. Ozone Manager maintains the mappings between the keys and their corresponding Block IDs. Ozone Manager also interacts with Storage Container Manager (SCM) for information about blocks relevant to the read and write operations, and provides this information to the client.

출처 : https://docs.cloudera.com/runtime/7.0.3/ozone-storing-data/topics/ozone-architecture.html

눈에 띄는 기존 구조와이 차이점은 바로, namespace와 container layer를 분리한 것입니다. namenode의 역할에 비유할 수 있는 namespace management는 Ozone Manager server에서 담당하며, datanode의 역할은 storage container manager (SCM)이 담당하게 됩니다. 이러한 아키텍처로 부터 오는 장점은 다음과 같습니다.

Principal features of Ozone which help it achieve scalability are:

• The namespace in Ozone is written to a local RocksDB instance, with this design a balance between performance (keeping everything in memory) and scalability (persisting the less used metadata to the disk) can be easily adjusted.
• Namespace and block space management are separated into two different daemons OzoneManager(OM) and StorageContainerManager(SCM) respectively. Each of these daemons can be scaled independently of each other.
• Unlike HDFS, Ozone block reports are reported via container reports which aggregate reports for multiple blocks in the container.

출처 : https://blog.cloudera.com/one-billion-files-in-ozone/

One billion files in Ozone - Cloudera Blog

마지막으로 왜 Apache Ozone(Object Storage)는 small size file저장에도 효율적인 것인가? 라는 질문에 대한 답을 제가 이해한바에 기반하여 말씀드리겠습니다.

초반에 언급한 one bilion files in ozone으로 돌아가서, one bilion files를 hdfs에 저장하게 되면, one bilion 만큼의 meta data(여기선 key라고 지칭)가 생기게 됩니다. 하지만, apache ozone은 여러 block들로 구성된 storage container 당 meta data를 생성하기 때문에, 기하급수 적으로 저장 비용이 줄어들게 되는 것입니다. 

제가 위와 같이 이해하게 된 내용의 원문은 다음과 같습니다.

Small Metadata Overhead

A billion keys each of 10KB size were stored on 2121 5GB containers, this significantly reduces the block metadata for SCM from 1 billion blocks to be reported in HDFS versus the 2121 containers to be reported in Ozone. On the other hand, a billion keys on OM  took a total of 127 GB space on the SSDs.

출처 : https://blog.cloudera.com/one-billion-files-in-ozone/

원문에서 Apache Ozone에 대해 내리는 결론은 다음과 같습니다.

Conclusion

HDFS’s known limitations around small files and namespace scale limits lead to underutilization of storage nodes, GC issues and instability of Namenode, and fragmentation of namespace for large data lake deployments. Ozone overcomes these limitations by handling billions of files of all sizes and thus enables large data lake deployments in a single namespace. Ozone architecture with higher scale, and with the support for object storage use cases, addresses the big data storage requirements in private cloud environments where disaggregated compute and storage is a rapidly emerging trend.

이에 대한 저의 생각은, 아직까지 Apache Ozone을 현업에 도입한 사례가 NAVER CLOUD외에 보지 못하였으며 (더 있을 것 같지만) 10여년간 사용되고 인정받은 HDFS의 자리를 대체하진 않을 것 같습니다. 다만, HDFS만의 장점을 살리고 단점을 보완하는 용도로서 Apache Ozone을 도입하는 사례는 갈 수록 늘어날 것 같습니다.

개인적으로 사내에 Apache Ozone을 도입한다면, 과거 데이터를 back up하고 읽기 작업 용도로 사용할 것 같습니다. 추후 object storage내에서도 data locality를 활용한 분산 병렬 처리작업을 지원하는 쪽으로 점점 발전해나갈 예정이라고 하니, 앞으로 지켜볼 예정입니다.

이상으로 긴글 읽어주셔서 감사합니다.