클라우드 파일 시스템과 De-duplication

요즘 Personal Storage Service를 분석하다보니, Cloud Storage쪽을 많이 보게 되는데,
트렌드가 대부분 S3나 SWIFT같은 Blob Storage를 뒤에 넣고, 중간에 이를 File System으로 바꿔주는 서버 계층을 두고, Client에 마치 NDrive 처럼 Fuse를 이용해서 마운트 하는게 대세다.
CyberDuck같은 오픈 소스를 보면 KT SS나 Amazon S3등을 Storage로 저장해서 파일을 저장할 수 있게 해준다.

요즘 관심이 가는 부분이 이 구조에서 중간에 File System으로 바꿔주는 엔진 부분인데,
De-duplication쪽이 관심이다. 이유인 즉, SWIFT의 경우 데이타 안정성(무결성)을 보장하기 위해서 물리적으로 3Copy를 유지하기 때문에 Storage용량이 많이 소요되고, 이를 줄이는 방법은 De-duplication이 적절하다.

Deduplication이란, 파일을 여러개의 블럭(Chunk)로 나눈후에, 저장시에 나눠서 저장하고, Update될때는 변경된 Block만 저장하는 방식으로 파일이 일부만 변경되거나 여러명이 같은 파일을 사용할 경우 용량 절감 효과를 볼 수 있다.

S3나 SWIFT같은 Object Storage는 하나의 파일을 하나의 Object로 저장한다. 우리가 알고 있는 파일 시스템과 그 구조가 틀리기 때문에 중간 계층을 두는데, KT나 RackSpace의 파일 저장 서비스는 하나의 파일을 하나의 Object로 저장하는 구조지만, OpenDedup이나 몇몇 솔루션은 하나의 파일을 여러개의 Chunk로 나눈 후에, Chunk를 하나의 Object로 처리해서 저장한다.  이렇게 Chunk로 나눌 경우 Chunk를 동시에 전송해서 접근 속도를 높일 수 있고, dedup을 지원하여 스토리지 용량을 절약할 수 있지만, 반대로 Chunk를 나누고 계산하는 시간에 CPU가 많이 소요 되는 단점을 가지고 있다.

대표적인 오픈소스가 Opendedup이 있는데, 코드 구조가 정말 마음에 든다. :)
http://opendedup.org/
에 있다.
코드를 분석해보니 구조가 대충 다음과 같이 나온다.

 

크게 두개의 컴포넌트가 있는데, DedupFileEngine과 DedupStoreEngine이 있다. FileEngine은 파일단위의 관리를 하고, DedupStorageEngine은 실제 Storage 저장소에 저장되는 Chunk를 관리한다.

하나의 파일은 Dedup 파일이라는 클래스로 관리가 된다. Chunk단위로 나뉘어진 데이타는 WritableCacheBuffer라는 형태로 메모리에 저장되고, Disk에 Writing될때, HCServiceProxy라는 컴포넌트가 Routing을 해서 DedupStorageEngine으로 보낸다. 이때 Routing을 Chunk의 첫번째 Byte의 Hash값을 0~255로 계산하여 Routing을 한다.

파일에 대한 메타 정보 - 디렉토리,Path,LastAccess,Permission등은 MetaDataDedupFile이라는 저장공간에 저장이 되며, 이 컴포넌트는 JDBM이라는 오픈 소스를 사용한다.

이 DedupFile들은 묶음으로 DedupFileStore라는 곳에 저장된다.
파일 전송을 위해서 각 DedupFile은 DedupFileChannel을 가지고 있고, 클라이언트에 파일을 전송하는 Network interface로 사용된다.

OpenDedup은 이 파일 시스템을 NFS나 CIFS등으로 시스템에 Mount할 수 있는데, 이 파일 시스템을 Mount하는 것은 Open Source의 Fuse를 사용한다.