casync 알아보기 (Content Addressable Data Synchronizer)

재미난 Opensource 없을까는 항상 고민거리이다.

코딩이 재미있고, 어느 하나에 몰입해 하고 싶지만 마땅한 게 없었다.
규모 있는 코드를 보고 있자니, 한강을 보고 입만 벌리고 있는 기분이고...
규모 작은 건 뭐 어디서 찾아야 하는지, 이게 모하는 건지 모르겠고... (이미 망했거나)
그래서 어느날 부턴가 Github Trending을 살펴보기 시작했다.
매일 매일 Today 필터를 걸어 살펴보기 시작했다.

그래봤자 대부분은 유명한 것들 뿐이다. 당연한 이야기겠지만 매일매일 커밋이 핫하게 올라오는게 그런 것들일 수 밖에...
(※여기서 '그런 것들' : linux, vim, git, tensorflow 등)

그러던 어느날 재미난 게 올라왔다.
systemd/casync

무려 systemd 밑에 있는데, star가 300개에 커밋도 300여개 뿐이었다.
살펴보고 난 뒤의 마음에 들었던 점을 나열해 보겠다. (마음에 드는 차순으로)

1. 연예인이 만든거다.
    : Lennart Poettering, 그는 systemd, Pulse Audio, Avahi 의 개발자이다.
      systemd의 메일링을 구독중인데 태반이 이사람 메일이다.
      이정도면 오픈소스계의 연예인이라고 개인적으로 결론지었다.
    : Project 를 진행하면서 몇몇 요구사항에 대해, 어떻게 대응하는게 최선일까
      고민하던 것 중 systemd의 방범론을 차용해 해결한 적이 몇번 있었다.
      (그때부터 마냥 동경했던 듯 싶다.)

2. 코드를 보아하니 양이 엄청 적다.
    : 코드를 보고있는 현 시점에서 매우 적다.

3. fuse 관련 부가 보여서 나에게 친숙했다.
    : File system을 전공한 사수에게서 프로그래밍을 배웠고, fuse를 이용한
      Project를 경험하고부터 뭐든 File system 관점에서 보는 습관이 생겼다.
      어쨌든 친숙했고 좋은 인상으로 다가왔다.
      (물론 fuse 관련부가 casync의 핵심은 아니다.)

어쨌든 뭔가 재미있는 오픈소스 같아, 지켜보고, 조사하고, 가능하면 참여도 해보고자 한다.
(이 말인 즉슨, 나도 잘 모르지만 대충 wiki 보고 정리해보며 공부하겠다...는 말)

casync의 github 주소는 다음과 같다. (https://github.com/systemd/casync)

Readme를 참고해 key-feature를 설명하면,

1. rsync 와 content-addressable storage의 결합이다.
    - rsync : 원격 서버에 파일전송 시, block 단위로 검사해 변경점만 보내 트래픽을 절약 할 수 있음.
    - content-addressable storage : 저장소의 주소가 아닌, Content 기준으로 검색할 수 있는 정보저장 방식 이라고 합니다. (어렵;;)

2. 파일 시스템이나, 디렉토리 트리의 여러 버젼을 효과적으로 저장, 검색 가능.

3. OS, VM, IoT, container 등에 대해서 효과적인 배포가 가능합니다.
    - HTTP나 CDN에 friendly 하다 함.
    - casync가 이미지에 대한, block level 직렬화와, file-system 수준에서의
      직렬화를 모두 지원하기 때문에, VM, IoT의 이미지 배포 (블럭 레벨 직렬화)와
      container(파일시스템 레벨 직렬화) 에 모두 적합하다고 한다.

4. 효과적인 백업

기본적으로 테스트해 보고 blog를 보고 한 결과, 내가 느낀 점은 파일을 tar 처럼
뭉쳐주기도 하고 (=직렬화; serialization), 비슷한 chuck로 나눌 수도 있다.

또 해보지는 않았지만, 이 chuck를 web server에 올려 제공하면,
HTTP Request로 (또는 ssh) 파일을 받아 와 extract 하는 것도 가능해 보인다.

만든 배경과 상세한 구조 설명은 다음 링크에 (영어로) 작성되어 있다.

http://0pointer.net/blog/casync-a-tool-for-distributing-file-system-images.html

동작 원리는 링크에 나온 그림을 보면 이해가 수월하다. (CC 등에 대한 기재가 없어 퍼오지 않았다.)

그림을 보고 있을거라 믿고 설명하면,
블럭 단위 device나 File system상의 Directory tree 모두 하나의 스트림으로 직렬화 한다.
(그림에서는 "Serialized stream" 이라 표현했다.)

그리고 이를 적정 단위 청크로 쪼갠다. (대부분 청크들 사이의 크기가 일정하되, 같지는 않다.)
쪼개서 모아놓은 디렉토리를 "Chunk Store"라 부른다.

그리고 이들을 쉽게 찾을 수 있게, Hash값들을 모아놓은 "Chunk Index" 라고 불리는 파일을 생성한다.

나중에 이렇게 만들어진 Chunk Store와 Index만 가지고도

1. 압축을 풀어 원본 파일을 다시 생성하거나

2. fuse를 이용해 특정 directory에 mount 시켜서 일반 파일 인터페이스로도 접근이 가능하다.
    : fuse는 일종의 "사용자 정의 파일시스템" 라이브러리 이다.
      지정한 디렉토리 아래로 오는 File operation들을 나만의 함수로 재정의가
      가능하고, 이런 방식으로 Cloud Storage를 로컬 파일 시스템에 마운트 시키는
      Naver사의 Ndrive가 Window에서 특정 드라이브로 마운트 되는 것과 같은
      구현이 Linux에서도 가능해진다.
      유명하게는 Amazon S3를 Linux에 마운트하는 s3fs Project가 있다.

결국 파일을 직렬화 -> 다시 청크로 쪼갬으로써, Network을 통한 delivery시
rsync와 같이 변경점에 대한 청크만 전달해 Network 효율을 얻을 수 있고

Index 파일을 생성해 컨텐츠도 쉽게쉽게 잘 찾는다는 장점으로 보인다.

이미 빌드도 해놓았고 몇몇 명령어도 테스트 해보았는데, 정리하자니 밤이 너무 깊었다.

자고 다음에 이어서 포스팅 해야겠다.