1. 서 론

Rsync는 클라이언트와 서버 사이의 파일 동기화 알고리즘이자 유틸리티이다. 클라이언트 파일이 수정되면 서버측 파일과 동기화를 위해 파일 전체를 전송하는 대신, rsync는 클라이언트와 서버의 두 파일의 차이점만을 전송하는 델타 인코딩을 사용하여 데이터 전송량을 감소한다. 이런 이유로 rsync는 리눅스 시스템의 표준 유틸리티이며 이를 기반으로 한 다양한 동기화 프로그램들이 개발되었다. Dropbox, One drive, Google drive, iCloud drive 등 상용 클라우드 스토리지 서비스들 역시 델타 인코딩 기반의 파일 동기화 방법을 사용하는 것으로 알려졌으나 구체적인 알고리즘은 공개된 바가 없다.

델타 인코딩은 클라이언트 파일의 수정된 부분만 서버로 전송하기 때문에 전체 파일 전송보다 데이터 전송량이 작기 때문에 동기화 시간을 감소할 수 있다. 하지만, 델타 인코딩은 수정된 클라이언트 파일과 기존 서버 파일의 차이점을 찾기 위해 두 파일의 블록 단위 체크섬을 비교하는 추가적인 프로세싱 과정을 필요로 한다. 델타 인코딩의 대략적인 과정은 다음과 같다. 클라이언트 파일이 수정되면, 이 사실을 서버에 알린다. 서버는 서버측 파일을 블록으로 나누어 각 블록 별 체크섬을 계산한다. 서버는 블록 체크섬 정보를 클라이언트로 전송한다. 클라이언트는 수정된 파일의 첫 번째 블록부터 체크섬을 계산하여 서버의 체크섬과 매치되는 블록이 있는지 검색한다. 매치되는 블록이 있으면 블록 번호만 서버에 보내고 블록 데이터를 전송할 필요는 없다. 클라이언트는 매치된 블록을 건너 뛴 다음 블록에 대해 마찬가지로 매치되는 서버측 블록을 검색한다. 매치되는 블록이 검색되지 않으면, 클라이언트는 블록 윈도우를 한 바이트씩 이동하고 이 윈도우 자리의 블록의 체크섬과 매치되는 서버측 블록을 계속 검색한다. 이 때, 서버와 매치되지 않은 클라이언트 파일의 바이트는 모아서 서버로 전송하여 서버 파일을 업데이트한다.

이와 같이, 델타 인코딩은 변경된 내용만 전송하는 대신 추가적인 체크섬 계산 등의 계산 비용이 필요하다. 일반 파일 전송 방법은 추가적인 계산은 필요 없지만 변경되지 않은 내용까지 모두 다시 전송해야 하는 부담이 있다. 델타 인코딩에서의 수정된 데이터를 체크섬으로 계산 및 검색하여 전송하는 비용과 파일의 모든 데이터를 다시 전송하는 방법은 파일의 크기와 수정된 바이트 수, 클라이언트와 서버 사이의 전송 속도에 따라 동기화 성능에 영향을 준다. 따라서, 본 논문에서는 여러 상황에서의 파일 동기화 성능을 실험을 통해 분석하고, 두 가지 동기화 방법을 가변적으로 사용하는 방안을 제안한다.

델타 인코딩과 파일 전송을 비교하기 위해, 본 논문에서는 기존 통신 프레임워크(CM)에 rsync 알고리즘 기반의 파일 동기화 기능을 구현했으며 이를 CM 서비스로 추가했다. 애플리케이션 개발자는 CM API를 이용하여 기존의 파일 전송 기능과 함께 파일 동기화 기능을 추가한 클라이언트-서버 애플리케이션을 개발할 수 있다. CM은 파일 동기화 시작 및 종료, 선택한 파일의 온라인 모드 및 로컬 모드 변경 서비스를 제공한다. 클라이언트가 파일 동기화를 시작하면, 지정된 동기화 디렉토리 내의 파일들을 서버와 동기화하고 동기화 디렉토리 내의 변경 내용을 탐지하기 위해 모니터링을 시작한다. 모니터링 과정에서 파일 추가, 삭제, 수정 등 변경 내용을 탐지할 때마다 서버와의 동기화를 수행한다. 클라이언트는 동기화된 파일을 온라인 또는 로컬 모드로 변경할 수 있다. 파일이 온라인 모드이면, 원본 파일은 서버에만 존재하고 클라이언트의 파일은 디스크 공간을 할당받지 않아 저장 공간을 절약할 수 있다. 로컬 모드는 동기화된 파일의 일반적인 형태로 클라이언트와 서버의 파일 모두 동기화된 원본 파일이다. 본 논문에서는 또한 파일 동기화 방법의 특성을 살펴보기 위해, 델타 인코딩과 파일 전송 방법을 비교 실험하고 그 결과를 바탕으로 하이브리드 동기화 방법을 제안한다. 실험 결과, 파일 전체 내용을 전송해야 하는 신규 파일 동기화의 경우에는 파일 크기와 상관없이 델타 인코딩보다 파일 전송이 오히려 동기화 완료 시간이 짧았다. 반면에 기존 파일 뒤에 내용을 추가하는 경우, 작은 파일은 델타 인코딩과 파일 전송의 완료 시간이 큰 차이가 없다. 1MB보다 큰 파일부터는 원본 파일과 추가된 파일 사이의 매치된 블록 때문에 델타 인코딩이 파일 전송보다 완료 시간이 작다. 파일의 기존 내용을 수정할 때의 동기화 완료 지연 시간을 비교했을 때는 파일 크기와 파일 수정 범위에 따라 다른 결과를 나타냈다. 1MB 미만의 작은 파일은 파일 수정 범위와 상관없이 델타 인코딩과 파일 전송이 큰 차이가 없으며 오히려 파일 전송 방법이 완료 지연 시간이 더 작았다. 1MB 이상의 파일부터는 파일 크기 대비 수정 범위가 작을수록 델타 인코딩이 파일 전송보다 완료 시간이 작다. 하지만, 파일 수정 범위가 일정 비율 이상이 되면 델타 인코딩보다 파일 전송을 사용했을 때의 완료 시간이 더 짧다. 즉, 파일의 일부 범위만 수정하는 경우에는 확실히 델타 인코딩이 이점을 보인 반면에 신규 파일이나 파일의 많은 범위를 수정하는 경우에는 델타 인코딩보다 파일 전송 방법이 완료 시간이 더 작은 것을 알 수 있다. 이와 같이 델타 인코딩과 파일 전송의 비교 실험 결과를 바탕으로, 제안하는 하이브리드 파일 동기화 기법에서는 신규 파일 여부, 파일 수정 타입, 파일 크기 및 파일 수정 범위에 따라 델타 인코딩과 파일 전송의 두 가지 방법을 선택적으로 사용함으로써 동기화 완료 지연을 감소할 수 있음을 보였다.

2. 관련 연구

Rsync는 클라이언트의 파일과 원격지 서버의 파일을 동기화하는 알고리즘이자 툴이다. ⁽¹⁾ Rsync 알고리즘은 두 파일 사이의 차이점만 전송하는 델타 인코딩을 사용하여 동기화를 위한 데이터 전송 비용을 줄이는 장점을 가지고 있다. Rsync는 리눅스 표준 유틸리티이기도 하고 이를 기반으로 한 다른 동기화 툴들도 다수 개발되었다. Rsync의 델타 인코딩은 파일을 일정 크기의 블록으로 나누어 각 블록의 체크섬을 계산 및 비교함으로써 두 파일 사이에 내용이 같은 블록을 검색하는 방법이다. 파일의 내용 대신 각 블록의 체크섬을 비교하기 때문에 비교 오버헤드를 줄일 수 있다. 클라이언트는 파일의 시작부터 블록 크기의 윈도우를 1 바이트씩 이동하며 블록의 체크섬을 빠르게 계산하기 위해 롤링(rolling) 체크섬 방식을 사용한다. Rsync의 파일 동기화 방법은 본 논문의 파일 동기화 방법에도 적용했다.

클라우드 스토리지에서 파일 동기화 성능을 향상시키기 위한 연구들도 꾸준히 진행되어 왔다 ^{(2)(3)(4)(5)(6)(7)}. ⁽²⁾의 연구에서는 Cloud4NetOrg라고 하는 클라우드 스토리지 동기화 아키텍처를 제안했다. 주로 개인 사용자가 아닌 기업의 대용량 스토리지를 사용하여 협업하는 사용자들을 대상으로 하고, 동기화 성능을 향상시키기 위해 2단계 캐시와 private 네트워크를 구성했다. ⁽³⁾의 연구에서는 상용 클라우드 스토리지 서비스들의 성능을 측정 실험과 네트워크 패킷 분석을 통해 이들 서비스의 동기화 설계 방식을 분석한 결과를 제시했다. 특히, 델타 인코딩 관련 실험 결과, 이 논문은 Dropbox만 델타 인코딩을 구현했고, 나머지 (Microsoft SkyDrive, Google Drive, LaCie Wuala, Amazon Cloud Drive) 클라우드 스토리지는 파일 전송 방식을 사용한 것으로 분석했다. 하지만, 델타 인코딩과 파일 전송 방식에 대한 동기화 지연 시간 등의 비교 분석은 수행하지 않았다. ⁽⁴⁾의 연구는 파일에서 적은 양의 수정이 자주 발생하는 경우 동기화 성능이 현저하게 저하되는 문제를 해결하기 위해 수정 지연 동기화(update-batched delayed synchronization, UDS) 메카니즘을 제안했다. UDS는 파일들의 수정 이벤트가 발생했을 때, 바로 클라우드 스토리지와 동기화를 여러번 진행하지 않고 수정된 데이터 양의 총합이 정해진 기준에 다다를 때까지 기다린다음 한 번에 동기화를 진행하는 방법을 사용한다. ⁽⁵⁾의 연구는 기존의 클라우드 스토리지 서비스들을 통합하여 MetaSync라고 하는 안전하고 신뢰적인 동기화 방법을 제안했다. MataSync는 파일 수정 내용을 여러 클라우드 서비스들 사이에 일관성있게 동기화를 수행하기 위해 기존 Paxos ⁽⁸⁾ 알고리즘을 클라이언트 기반으로 수정한 pPaxos 알고리즘과, 복제 데이터의 일관성 유지 비용을 줄인 데이터 복제 알고리즘을 제안했다. ⁽⁶⁾의 연구에서는 ObjectMQ라고 하는 경량 메시지 큐 프레임워크를 기반으로 탄력적인 파일 동기화 기능을 제공하는 StackSync 아키텍처를 제안했다. 탄력적 파일 동기화는 동기화 오버헤드에 따라 서버나 메시지 큐 객체 등의 자원을 늘리거나 줄이는 등 효율적으로 제공하는 방법이다. ⁽⁷⁾의 연구에서는 동기화 과정에서의 네트워크 트래픽 사용 효율성 지수(Traffic Usage Efficiency, TUE)를 정의하고, 상용 클라우드 스토리지 서비스들을 대상으로 실험을 통해 이를 측정 및 분석하여 동기화 트래픽을 효율적으로 사용하는 방안을 제시했다.OneDrive, Google Drive 등 클라우드 스토리지 서비스들의 경우 유료 서비스들인만큼 구체적인 파일 동기화 방법이 공개되지 않고 서비스 사용 실험과 트래픽 분석을 통해 간접적으로 분석하는 연구들이 있다 ⁽³⁾⁽⁹⁾. 또한, 각 클라우드 스토리지 서비스의 특징은 기술 문서로 ^(10)(11)(12) 제공하고 있다. Dropbox와 OneDrive는 각각 스마트 동기화(Smart Sync)와 파일 온디맨드(Files on Demand)라는 이름으로 원본 파일을 서버에만 저장하고 클라이언트는 파일의 메타 정보만 유지하여 클라이언트 스토리지 공간을 절약하는 방법을 사용한다.

이 밖에도 클라우드 스토리지 및 클라우드 파일 시스템과 관련된 연구들도 ^{(13)(14)(15)(16)(17)} 진행되어 왔다. ⁽¹³⁾의 연구에서는 기존 클라우드 스토리지 시스템의 신뢰성, 내구성, 파일 공유의 비효율성 문제를 해결하기 위해 강한 일관성을 제공하는 공유 클라우드 파일 시스템(Shared Cloud-backed File System, SCFS)을 제안했다. ⁽¹⁴⁾의 연구에서는 확장성 있는 분산 파일 시스템이고 대규모 데이터 처리 애플리케이션에 적합한 구글 파일 시스템(Google File System, GFS)을 소개했다. 또한, 구글 파일 시스템은 저비용 하드웨어 상에서 작동하면서도 고장감내 기술을 제공하고 대규모 클라이언트들에게 우수한 성능을 제공하고 있다. ⁽¹⁵⁾의 연구에서는 클라우드 스토리지에 데이터뿐만 아니라 데이터의 생성 및 수정 관련 히스토리 정보(Provenance)를 제공하는 방안을 제안했다. 이는 데이터가 언제 생성되었는지, 어느 선행 데이터들로부터 파생된 것인지 등의 정보를 포함한다. ⁽¹⁶⁾의 연구에서는 대규모 데이터의 저장과 관리보다 많은 수의 개인 사용자의 데이터 관리를 위한 클라우드 스토리지인 CSTORE를 제안했다. CSTORE에서는 사용자별로 독립 네임스페이스를 제공하여 데이터 보안을 강화하고, 로그 기반으로 같은 사용자의 다중 로그인 및 파일 수정 과정에서의 데이터 충돌을 피하도록 했다. 또한 데이터를 블록 레벨로 관리하여 데이터 중복을 회피하는 방법을 사용했다. ⁽¹⁷⁾의 연구에서는 대규모 데이터의 분산 처리 방법에 초점을 맞춘 하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)을 다룬다. HDFS에서는 대규모 클러스터로 구성된 수천 대의 서버가 대규모 데이터를 신뢰적으로 분산 처리 및 저장하고, 대규모 데이터셋을 사용자 애플리케이션에게 빠른 속도로 계속 전송하도록 설계되었다.

3. 파일 동기화 프레임워크

이번 장에서는 본 논문에서 제안하는 rsync 기반의 파일 동기화 프레임워크의 구조와 동기화 과정을 기술한다. 이 파일 동기화 프레임워크는 기존의 통신 프레임워크(Communication Framework, CM)⁽¹⁸⁾에 새로운 모듈로써 추가되었다. CM은 클라이언트 서버 구조 애플리케이션 개발에 필요한 여러 가지 응용 레벨 통신 서비스를 제공하는 통신 프레임워크이다. 애플리케이션 개발자는 CM 라이브러리에서 제공하는 애플리케이션 프로그래밍 인터페이스(API)를 이용하여 서버 로그인과 사용자 관리 등 기본적인 서비스뿐만 아니라 파일 전송, 소셜 네트워크 서비스, 메시지 전송 등의 기능들을 간단하게 구현할 수 있다. 특히, CM은 각 통신 서비스별로 다양한 옵션을 API 매개변수와 설정 파일을 통해 제공하기 때문에, 개발자는 애플리케이션 요구사항에 따라 다른 서비스 전략을 선택할 수 있다. 본 논문에서는 CM에 파일 동기화 서비스를 추가했다. CM 파일 동기화 서비스는 사용자 관리, 파일 전송 등 기존 CM 서비스들과 유기적으로 연결되어 개인 클라우드 스토리지 서비스 개발을 용이하게 해준다. 파일 동기화 서비스는 기능 추가와 확장을 계속 진행할 예정이며, 본 논문에서는 다음과 같이 우선 파일 동기화 서비스의 기본 기능 개발에 초점을 둔다. 파일 동기화는 하나의 클라이언트와 서버 사이에 대해서만 고려하고, 클라이언트의 파일을 기준으로 서버 파일을 동기화하는 단방향 동기화를 대상으로 한다. 양방향 동기화, 클라이언트의 다중 로그인, 및 다른 클라이언트와의 파일 공유 등 확장 기능은 아직 다루지 않는다. 파일 동기화 서비스 기본 구조는 [그림 1]과 같다. 클라이언트와 서버 애플리케이션은 각각 하부 통신 프레임워크로 CM을 이용한다. 파일 동기화 공통 모듈은 클라이언트와 서버 양쪽에서 공통으로 사용하는 CM 모듈이다. 동기화 디렉토리 모니터링 태스크는 클라이언트 측 CM에서 동기화 디렉토리의 변경사항을 감지하기 위해 별도 스레드로 동작하는 모듈이다. 클라이언트가 동기화를 중지하면, 이 모니터링 태스크가 중지되고, 동기화를 재시작하면 모니터링 태스크가 다시 시작된다. 블록 체크섬 생성 태스크는 서버측 CM에서 별도의 스레드로 동기화 대상 파일을 선별하고 파일별 블록 체크섬을 생성하는 역할을 수행하는 모듈이다. 이 모듈은 클라이언트와 동기화를 수행하는 동안에만 클라이언트별로 생성하여 작동한다. 클라이언트는 서버에 로그인한 후에 파일 동기화 서비스를 시작하거나 중지할 수 있다. 클라이언트가 파일 동기화 서비스를 시작하면, CM은 클라이언트의 동기화 디렉토리 내에 있는 파일들을 서버와 동기화한다. 서버 측 CM은 클라이언트별로 별도의 동기화 디렉토리를 관리한다. 서버와의 동기화가 완료된 후, 클라이언트 CM은 계속 클라이언트의 동기화 디렉토리를 모니터링하며 파일 추가, 수정, 삭제 등의 이벤트가 발생할 때마다 서버와 동기화를 반복한다.

그림 1 CM 파일 동기화 전체 구조

Fig. 1 Overall structure of CM file synchronization

3.1 CM 파일 동기화 구조

[그림 2]는 클라이언트 및 서버측 CM에서 파일 동기화와 관련한 핵심 클래스 구조를 나타낸 것이다. 기타 CM 모듈은 파일 동기화 이외의 서비스 및 노드간 통신을 지원하는 클래스들로써 본 논문의 핵심 모듈은 아니기 때문에 간단히 나타냈다. 파일 동기화 공통 클래스는 CM 서버와 클라이언트에서 같은 역할을 담당하는 모듈이다. CMFileSyncManager는 파일 동기화 시작 및 종료, 파일의 블록 체크섬 계산, 동기화 완료 여부 확인 등 파일 동기화 알고리즘에서 필요로 하는 세부 메소드들을 제공한다. CMFileSyncEventHandler는 클라이언트와 서버가 파일 동기화 과정에서 상대방이 보낸 이벤트를 수신했을 때, 이를 처리하는 역할을 수행한다. 파일 동기화 이벤트는 CMFileSyncEvent 클래스를 상속하여 정의되어 있으며 각 이벤트의 전송 및 이에 대한 처리는 다음 장의 파일 동기화 과정에서 구체적으로 기술한다. CMFileSyncInfo는 클라이언트와 서버가 파일 동기화 과정에서 필요한 여러 가지 정보를 관리한다. 클라이언트가 필요로 하는 정보로는 동기화 디렉토리 내 파일 리스트, 서버가 보낸 파일별 블록 체크섬 리스트, 파일 별 동기화 완료 여부 등이 있다. 서버가 관리하는 정보로는 클라이언트가 보낸 파일 정보 리스트, 클라이언트 별 파일 블록 체크섬 정보, 클라이언트별 서버측 동기화 파일 리스트 등이 있다.

그림 2 CM 파일 동기화 세부 모듈

Fig. 2 Internal modules of CM file synchronization

CMWatchServiceTask는 파일 동기화를 위한 클라이언트 특화 클래스로써 [그림 1]의 동기화 디렉토리 모니터링 태스크를 구현한 것이다. 이 클래스는 파일 동기화가 시작될 때 별도 스레드 객체로 생성되어 클라이언트 동기화 디렉토리 내의 파일 변경 이벤트를 모니터링하는 역할을 수행한다. 신규 파일 추가, 기존 파일 내용 수정, 파일 삭제 등의 이벤트가 발생하면 CMWatchServiceTask는 서버와 수정 파일의 동기화를 시작한다. 파일 동기화가 중지되면, CMWatchServiceTask 스레드 객체가 종료되어 모니터링 작업도 중지된다. CMFileSyncGenerator는 파일 동기화 서버의 특화 클래스로써 [그림 1]의 블록 체크섬 생성 태스크를 구현한 것이다. 클라이언트가 동기화를 시작하여 파일 리스트를 전송하면, 서버는 이 클라이언트에 대한 CMFileSyncGenerator 객체를 별도 스레드로 생성한다. 이 객체는 클라이언트가 보낸 파일 리스트와 서버가 가진 서버 파일을 비교하여 동기화를 수행해야 하는 파일을 선별하고, 동기화 대상 파일의 블록 체크섬을 생성하고, 이 정보를 클라이언트로 전송한다. 클라이언트로 블록 체크섬 정보를 전송하면, CMFileSyncGenerator 스레드는 종료되고 나머지 동기화 작업은 파일 동기화 공통 클래스에서 수행한다.

3.2 CM 파일 동기화 과정

CM의 파일 동기화 과정의 기본 알고리즘은 rsync를 따르고 있다. 이번 장에서는 파일 동기화 과정을 아래와 같이 세분화하여 각 단계별 과정을 구체적으로 살펴본다.

1) 동기화 시작

클라이언트 애플리케이션은 CM 스텁 모듈의 API를 호출하여 CM 서비스를 요청할 수 있다. 파일 동기화를 시작하거나 중지할 때 호출하는 함수는 [표 1]과 같다. CM의 대부분 서비스를 이용할 때도 마찬가지이지만, 클라이언트는 파일 동기화 서비스를 요청하기 위해 먼저 CM 서버에 로그인해야 한다. 클라이언트가 파일 동기화를 시작하면 CM 스텁 모듈은 CMFileSyncManager를 통해 파일 동기화 작업을 시작한다. CMFileSyncManager는 우선 CMWatchServiceTask 객체를 생성하여 동기화 디렉토리 모니터링을 시작한다. 이는 현재 동기화 작업 중에 발생할지 모르는 파일 변경 사항을 감지하기 위해서이다. CMWatchServiceTask는 CM의 스레드풀에 등록되어 다른 태스크들과 병행적으로 (concurrently) 모니터링 작업을 수행한다. 클라이언트의 동기화 홈 디렉토리는 CM의 파일 전송용 홈 디렉토리 내에 FileSyncHome 이름으로 설정되어 있다. 이에 대응하는 서버의 파일 동기화 디렉토리는 CM 파일 전송 홈 디렉토리 내 클라이언트 아이디 이름의 서브 디렉토리 내에 FileSyncHome으로 설정되어 있다. CMFileSyncManager는 동기화 홈 디렉토리의 모니터링 작업을 시작한 후, 동기화 작업을 본격적으로 시작한다.

표 1 CM 파일 동기화 API

Table 1 CM file synchronization API

파일 동기화 시작	public boolean startFileSync()
파일 동기화 중지	public boolean stopFileSync()

2) 동기화 디렉토리 파일 리스트 전송

클라이언트의 CMFileSyncManager의 다음 작업은 동기화 홈 디렉토리 내의 파일 리스트를 생성하여 서버로 전송하는 것이다. 클라이언트 파일 리스트의 전송 과정은 [그림 3]과 같다. 클라이언트는 동기화 홈 디렉토리 내의 모든 파일 리스트를 생성하고 서버에게 파일 리스트 전송 시작을 알리기 위한 이벤트(CMFileSyncEventStartFileList)를 전송한다. 서버는 이 클라이언트의 서버측 동기화 홈 디렉토리 존재 여부 등을 확인하고 클라이언트로 수신 준비가 되었다는 의미의 응답 이벤트(CMFileSyncEventStartFileListAck)를 전송한다. 이제 클라이언트는 자신의 파일 리스트에서 서버에게 보낼 파일 엔트리 리스트를 구성한다. 파일 엔트리 정보는 CMFileSyncEntry 클래스로 정의했으며 여기에는 파일의 동기화 홈 디렉토리부터의 상대 경로, 파일 크기, 마지막 수정 시간 등 정보를 포함한다. 전송할 파일의 개수가 많은 경우에는 하나의 이벤트에 모든 정보를 넣을 수 없기 때문에, CM이 허용하는 최대 크기 이내에서 파일 엔트리 리스트를 넣은 이벤트(CMFileSyncEventFileEntries)를 여러 개 생성하여 차례로 서버로 전송한다. 서버는 파일 엔트리 리스트를 수신하면 이를 클라이언트별로 저장하고 수신 확인용 응답 이벤트(CMFileSyncEventFileEntriesAck)를 클라이언트로 보낸다. 서버는 이 파일 엔트리 리스트를 나중에 서버 파일의 동기화 대상 여부를 조사할 때 비교 대상으로 사용한다. 클라이언트는 서버로부터 마지막 파일 엔트리 리스트의 응답 이벤트를 수신하면, 종료 이벤트(CMFileSyncEventEndFileList)를 서버로 보내 파일 엔트리 리스트 전송을 완료했다고 알려준다. 서버는 수신한 모든 파일 엔트리 리스트를 확인하고 이 종료 이벤트에 대한 응답 이벤트(CMFileSyncEventEndFileListAck)를 보낸다. 서버는 파일 동기화의 다음 작업을 수행하기 위해 CMFileSyncGenerator 객체를 생성하여 CM의 스레드풀에 등록한다. CMFileSyncGenerator는 파일 동기화의 다음 작업을 시작한다.

그림 3 클라이언트의 파일 엔트리 리스트 전송 과정

Fig. 3 Transmission process of file entry list

3) 동기화 대상 파일 선별

서버는 클라이언트마다 별도의 CMFileSyncGenerator를 생성한다. CMFileSyncGenerator는 다음 과정을 거쳐 서버 파일들 중 동기화가 필요한 파일을 선별하고, 이 파일들의 블록 체크섬을 생성하여 클라이언트로 전송하는 역할을 수행한다. CMFileSyncGenerator는 서버 파일 리스트와 클라이언트가 보낸 파일 엔트리 리스트를 비교하여, 클라이언트에는 없고 서버에만 있는 파일은 삭제한다. Rsync에서는 옵션에 따라 서버에만 존재하는 파일을 삭제하거나 유지 여부를 선택할 수 있는데 CM에서는 일단 삭제 처리하고 유지 옵션은 다음 버전에서 다룰 예정이다. 다음 작업으로, CMFileSyncGenerator는 클라이언트에는 있고 서버에는 없는 파일을 선별한다. 이런 파일들은 클라이언트에서 신규로 추가한 것이다. Rsync 공식 문서(https: //rsync.samba.org/how-rsync-works.html)에서는 신규 파일도 기존 수정 파일과 동일한 방식으로 블록 체크섬 비교 과정을 거치도록 하는데, 서버에는 파일이 없는 상태이기 때문에 빈 블록 체크섬 정보를 클라이언트로 보낸다. 그 외 다른 동기화 알고리즘들에서는 이 부분을 명시적으로 기술하지 않기 때문에, 본 논문에서는 이들 방법에 대해서도 신규 파일은 rsync와 마찬가지로 동일한 델타 인코딩을 사용하는 것으로 가정한다. 이 때, 클라이언트는 파일에서 매치되는 블록이 하나도 없기 때문에 모든 바이트를 서버로 전송하게 된다. CM은 신규 파일인 경우 rsync 방식 대신 CM의 파일 전송 서비스를 이용하여 전체 파일 내용을 전송하는 방법도 이용할 수 있다. 이 두 방식은 4장에서 실험을 통해 별도 비교를 진행한다.

이제 삭제 대상과 신규 파일을 제외한 나머지 파일들은 클라이언트와 서버 양쪽에 존재한다. CMFileSyncGenerator는 이 파일들에 대해서 동기화할 필요가 있는지 여부를 검사한다. 클라이언트 파일과 서버 파일의 크기와 마지막 수정 시간이 모두 같으면, 이 두 파일은 동일한 상태로 판단하고 동기화 대상에서 제외한다. 서버 파일이 크기와 마지막 수정 시간 중 한가지라도 클라이언트 파일과 다르면, 이 파일은 동기화 대상이 된다.

4) 파일 블록 체크섬 리스트 전송 및 파일 수정 내용 판별

CMFileSyncGenerator는 rsync 알고리즘에 따라 동기화 대상인 서버 파일의 블록 체크섬 배열을 만들어서 클라이언트로 전송한다. 파일 블록 하나의 체크섬 정보는 CMFileSyncFileBlock Checksum 클래스로 정의했다. 이 클래스 안에는 이 블록의 파일 내 위치를 나타내는 인덱스 값 (0 베이스), 블록의 약한(rolling) 체크섬과 강한(MD5) 체크섬 값을 포함한다. [그림 4]는 서버가 한 파일의 블록 체크섬 배열을 클라이언트로 전송하고 서버 파일을 업데이트하는 과정을 나타낸 것이다. 서버는 먼저 파일의 체크섬 배열 전송을 시작한다는 이벤트(CMFileSyncEvent StartFileBlockChecksum)를 클라이언트로 보내면서 파일 엔트리 리스트 내의 이 파일 인덱스, 이 파일 내의 총 블록 개수, 이 파일의 블록 크기 정보를 알려준다. 클라이언트는 이 정보를 가지고 서버가 보내는 파일 블록 체크섬 배열 정보를 저장할 준비를 하고 응답 이벤트(CMFileSyncEventStartFileBlock ChecksumAck)를 전송한다. 파일의 크기에 따라 블록의 개수가 많으면, 서버는 이를 하나의 이벤트로 전송할 수 없기 때문에 CM 이벤트의 최대 크기에 맞춰 블록 체크섬 배열을 여러 이벤트(CMFileSyncEventFileBlockSChecksum)로 나누어 전송한다. 하나의 블록 체크섬 배열 이벤트 안에는 전체 블록 체크섬 배열의 일부가 담겨 있기 때문에, 이 부분 배열이 전체 배열 내에서의 상대 위치를 알 수 있도록 전체 배열에서의 시작 인덱스, 이 부분 배열의 블록 개수 정보 등이 포함되어 있다. 클라이언트는 블록 체크섬의 부분 배열 이벤트를 수신하면, 이벤트 내의 이런 정보들을 가지고 전체 블록 체크섬 배열을 다시 구성한다. 서버는 파일의 모든 블록 체크섬 배열을 전송하고, 전송 종료 이벤트(CMFileSyncEventEndFileBlockChecksum)를 전송한다. 클라이언트는 이 배열 전송 종료 이벤트를 수신하면, 먼저 수신한 파일 블록의 해시테이블을 생성한다. 이 해시테이블을 이용하면, 파일 블록의 약한 체크섬으로부터 구한 해시값을 키로 하는 블록이 존재하는지 빠르게 검색할 수 있다. 파일 블록 해시 테이블을 생성한 후, 클라이언트는 자신의 파일과 서버가 보낸 블록 체크섬 정보를 이용하여 rsync 알고리즘에 따라 파일 전체의 수정된 부분과 변경되지 않은 블록을 검색한다. 매치되는 블록을 검색하거나 비매칭 바이트 버퍼가 가득 찰 때마다 클라이언트는 서버로 파일 업데이트 이벤트(CMFileSyncEvent UpdateExistingFile)를 전송하여 서버에게 파일 수정 내용을 알려준다. 클라이언트는 모든 파일 수정 정보를 전송한 후에 마지막으로 서버에게 블록 체크섬 배열에 대한 응답 이벤트(CMFileSyncEventEndFileBlockChecksumAck)를 전송한다. 이 이벤트는 서버가 보낸 파일의 블록 체크섬 배열 정보에 대한 응답임과 동시에 파일 수정 내용 전송을 완료했다는 두 가지 의미를 담고 있다.

그림 4 서버의 파일 블록 체크섬 배열 전송 및 서버 파일 업데이트 과정

Fig. 4 Transmission of file block checksum array and server file update

5) 서버 파일 업데이트

서버는 클라이언트로부터 파일 업데이트 이벤트(CMFileSyncEvent UpdateExistingFile)를 수신하면 다음 동작을 통해 임시 파일에 기존 서버 파일의 내용을 업데이트한다. 서버는 파일 업데이트 이벤트 안에 있는 비매칭 버퍼의 내용과 매칭 블록의 인덱스 정보를 순서대로 적용한다. 즉, 수정된 내용인 비매칭 버퍼 안의 바이트를 임시 파일에 쓴다. 다음으로, 매칭 블록 인덱스 정보가 있는 경우에는 해당 블록의 서버 파일 내용을 그대로 임시 파일에 쓴다. 이 과정을 거치면, 서버는 기존 파일에서 변경된 부분은 이벤트에 담긴 새로운 내용을 임시 파일로 쓰고, 변경되지 않은 부분은 서버 파일에서 블록 단위로 임시 파일로 쓰면서 업데이트된 새로운 파일을 생성하게 된다.

서버가 클라이언트로부터 블록 체크섬 종료에 대한 응답 이벤트(CMFileSyncEventEndFileBlockChecksumAck)를 수신하면, 이 파일의 모든 업데이트 정보를 받았다는 의미로 마무리 작업을 진행한다. 먼저 임시 파일의 내용이 클라이언트 파일의 내용과 동일한지 검사한다. 이를 위해 클라이언트는 응답 이벤트에 파일 체크섬 값을 추가한다. 서버는 임시 파일의 파일 체크섬을 계산하여 이벤트 안의 체크섬과 비교함으로써 두 파일이 동일한지 확인한다. 마지막으로 서버는 임시 파일을 기존 서버 파일로 덮어쓰고 마지막 수정 시간도 클라이언트로부터 수신했던 파일 엔트리의 시간으로 수정하여 이 파일의 동기화 작업을 완료한다.

4. 델타 인코딩 및 파일 전송 성능 분석

파일 동기화 프레임워크의 성능을 분석하기 위해 CM의 파일 동기화 서비스를 이용한 서버와 클라이언트 프로토타입을 구현했다. 클라이언트는 서버에 로그인한 후에 파일 동기화 서비스를 시작하거나 중지할 수 있다. 클라이언트가 파일 동기화 서비스를 시작하면, 클라이언트의 동기화 홈 디렉토리내의 파일들과 서버의 해당 클라이언트용 동기화 디렉토리안의 파일들이 동기화된다. 클라이언트가 파일 동기화 서비스를 중지하면, 동기화 홈 디렉토리에 대한 모니터링 태스크를 중지하여 파일 변경 등 이벤트가 발생해도 서버와의 동기화를 수행하지 않는다. 클라이언트와 서버는 무선랜(WiFi)을 통해 연결하고 실험에 사용한 각 장비의 사양은 [표 2]와 같다.

그림 5 신규 파일 동기화 완료 시간 (10KB~1MB)

Fig. 5 Synchronization delay of new files (10KB~1MB)

파일 동기화의 성능은 다양한 크기의 파일에 대해 CM 파일 동기화 프레임워크의 델타 인코딩과 파일 전송 방법을 각각 사용했을 때의 파일 동기화 완료 지연 시간을 측정하여 비교했다. 동기화 완료 지연 시간은 클라이언트가 CM 동기화 서비스를 시작한 시간부터 서버로부터 동기화 완료 이벤트를 수신할 때까지의 시간으로 측정했다. 모든 측정값은 각 파일에 대해 10회 동기화를 수행한 평균값을 나타낸다.

첫 번째 실험은 신규 파일에 대한 동기화 완료 지연 시간을 측정했다. 실험은 클라이언트와 서버의 동기화 홈 디렉토리가 비어있는 상태에서 시작한다. 클라이언트는 파일 하나를 동기화 홈 디렉토리에 추가하고 파일 동기화를 시작하여 동기화 완료 시간을 측정한다. 실험에서 사용한 파일들은 각각 10KB, 100KB, 1MB, 10MB, 100MB, 1GB 크기의 랜덤 바이트로 구성되도록 임의로 생성했다. [그림 5]는 신규 파일의 동기화 과정에서 델타 인코딩(delta-encoding)과 파일 전송(file-transfer)을 각각 사용했을 때의 파일 크기별 동기화 완료 시간을 비교한 결과이다. [그림 5(a)]는 1MB 이하의 작은 파일 그룹의 측정 결과이고 [그림 5(b)]는 10MB 이상의 큰 파일 그룹에 대한 결과이다. 측정 결과에서 나타나듯이 신규 파일의 동기화에서는 파일 크기와 상관없이 파일 전송이 델타 인코딩보다 짧은 완료 시간을 보여준다. 완료 시간의 차이는 작게는 10KB 파일의 23%에서 크게는 100MB 파일의 57%까지 벌어졌다. 이 측정 결과는 델타 인코딩의 특징에 기인한 것으로 분석된다. 즉, 신규 파일은 서버에 비교 대상인 파일이 없기 때문에 클라이언트는 파일 블록 비교 과정에서 블록 윈도우를 파일의 첫 번째 블록부터 마지막 바이트까지 1바이트씩 이동하면서 모든 데이터를 비매칭 바이트로 처리하게 된다. 이렇게 파일의 거의 전 범위를 1바이트씩 읽고 비매칭 바이트 블록을 서버로 전송하는 비용이 파일 전체를 블록 단위로 전송하는 비용보다 크다고 볼 수 있다.

두 번째 실험에서는 클라이언트가 파일 뒤에 내용을 추가했을 때의 동기화 성능을 비교 분석했다. 100KB, 1MB, 10MB의 원본 파일을 생성하고, 각 파일별로 랜덤한 바이트 수를 본 파일 크기의 100%에서 900%까지 추가한 파일을 생성했다. 실험은 클라이언트와 서버의 동기화 홈 디렉토리에 이미 원본 파일 하나가 동기화된 상태에서 시작한다. 클라이언트는 동기화된 파일을 같은 이름의 수정된 파일로 대체함으로써 파일 수정 동작을 구성했다. 이렇게 각 파일에 대해 내용 추가 범위를 변경하면서 파일 동기화 완료 시간을 측정했고 결과는 [그림 6]과 같다.

100KB 파일의 경우는 델타 인코딩이 파일 전송보다 약간 증가하지만 그 차이가 최대 58ms 정도로 크지 않다. 실험 데이터의 평균값이 아닌 최소값으로 비교했을 때는 두 방법의 완료 시간이 거의 동일하다. 1MB 파일에서는 두 방법의 상관 관계가 나타나지 않았으며, 10MB 크기에서는 파일 전송이 델타 인코딩보다 완료 시간이 증가했음을 알 수 있다. 파일 내용을 추가하고 이를 델타 인코딩으로 동기화하면, 내용이 같은 기존 부분은 빠르게 넘어가고 새롭게 추가된 바이트들에 대해서는 블록 비교 비용이 추가된다. 파일 전송을 이용하면 블록 비교 비용은 없지만 내용이 같은 부분도 다시 전송하는 비용이 추가된다. 1MB 정도 크기까지는 이 두 방법의 비용이 유사하다가 10MB가 되면 델타 인코딩에서 동일한 내용의 일정 블록을 건너뛰는 장점이 나머지 블록 계산 및 비교 비용보다 커지기 때문에 전체적인 파일 동기화 완료 시간이 감소한 것으로 분석된다.

세 번째 실험에서는 클라이언트가 파일의 기존 내용을 수정했을 때의 동기화 성능을 비교 분석했다. 파일 수정 분량에 따른 동기화 완료 시간의 변화를 측정하기 위해 신규 파일 동기화에 사용한 각 파일별로 10%에서 100%까지 수정한 10개의 파일을 별도로 생성했다. 예를 들어, 10% 수정한 파일은 원본 파일의 첫 번째 바이트부터 파일 크기의 10% 범위를 랜덤 바이트로 덮어쓴 새로운 파일이다. 실험은 클라이언트와 서버의 동기화 홈 디렉토리에 이미 파일 하나가 동기화된 상태에서 시작한다. 클라이언트는 동기화된 파일을 같은 이름의 수정된 파일로 대체함으로써 파일 수정 동작을 구성했다. 이렇게 여러 크기의 파일에 대해 수정 범위를 변경하면서 파일 동기화 완료 시간을 측정했다. [그림 7]은 파일 수정 범위에 따른 델타 인코딩의 동기화 완료 시간 변화를 나타내고, 비교를 위해 파일 전송 방법을 사용했을 때의 동기화 완료 시간을 같이 표시했다. 파일 전송 방법은 신규 파일 동기화 실험의 값을 나타낸 것이고, 항상 파일 전체를 전송하기 때문에 파일 수정 범위와 상관없이 동기화 완료 시간이 동일하다.

파일 크기가 1MB 미만인 작은 파일인 경우에는 (10KB, 100KB) 파일 수정 범위 변화에 따른 동기화 완료 시간이 상관 관계를 보이지 않았다. 파일 전송과 비교했을 때는 파일 수정 범위와 상관없이 델타 인코딩의 완료 시간이 더 길지만 그 차이는 100 ms로 체감할 정도로 크지는 않았다. 파일 크기가 1MB 이상으로 큰 경우에는 파일 수정 범위가 증가함에 따라 파일 완료 시간도 같이 증가하는 추세가 나타난다. 파일 전송 과 비교했을 때, 델타 인코딩은 파일 수정 범위가 작을수록 파일 완료 시간이 단축되었다. 즉, 매칭 파일 블록의 수가 많을수록 델타 인코딩은 블록 윈도우의 스캔 속도도 빨라지고 서버로 전송하는 비매칭 바이트의 빈도가 작기 때문에 완료 시간이 감소한다. 특히, 10MB 이상의 파일에 대해 수정 범위가 10%일 때는 델타 인코딩이 파일 전송보다 파일 동기화 완료 시간이 43%에서 64%까지 절반 가까이 감소했다. 파일 수정 범위가 커질수록 델타 인코딩의 시간은 증가하는데 일정 범위 이상으로 커지면 동기화 완료 시간은 파일 전송 방법보다도 커지는 것을 볼 수 있다. 10MB 파일은 70%, 100MB 파일은 60%, 1GB 파일은 50% 이상 파일을 수정했을 때 파일 완료 시간이 파일 전송 방법보다 커졌다.

5. 하이브리드 파일 동기화

4장의 델타 인코딩 및 파일 전송 비교 실험을 통해, 제안하는 CM 파일 동기화 프레임워크의 동기화 정책은 다음과 같다. 매칭 블록이 전혀 없는 신규 파일을 동기화할 때는 파일 전송 방법을 이용하고, 파일 내용을 추가한 경우는 델타 인코딩을 사용한다. 파일의 기존 내용이 수정된 경우, 1MB 이상 크기의 파일에 대해 약 50% 이내로 수정했을 때는 델타 인코딩을, 50% 이상 수정하는 경우에는 파일 전송 방법을 이용하는 것이 동기화 시간을 감소할 수 있다. 1MB 미만의 작은 크기 파일인 경우에는 수정 범위와 상관없이 파일 전송을 사용하는 것이 유리하다. 즉, 델타 인코딩과 파일 전송의 사용 여부를 결정하는 요소는 파일 크기와 파일 수정 비율이 있다. 이 두 가지 요소를 고려하여 제안하는 하이브리드 파일 동기화 알고리즘은 [그림 8]과 같다.

그림 8 하이브리드 파일 동기화 알고리즘

Fig. 8 Hybrid file synchronization algorithm

하이브리드 파일 동기화 알고리즘에서 FILE_SIZE_THRESHOLD는 파일 크기 임계값으로, 수정된 파일의 크기가 이 임계값보다 작으면 델타 인코딩을 적용하고 임계값 이상이면 다음 임계값을 검사한다. FILE_MOD_THRESHOLD는 파일 수정 비율 임계값으로, 파일 수정 비율이 이 임계값보다 작으면 델타인코딩을, 임계값 이상이면 파일 전송을 사용한다. 파일 크기 임계값과 파일 수정 비율 임계값은 파일 동기화 클라이언트와 서버 및 네트워크 상황에 따라 파일 동기화 지연 시간을 최소화할 수 있는 최적 값이 달라질 수 있다. 따라서, CM 파일 동기화 프레임워크에서는 설정 파일에 이 두 가지 임계값을 파라미터화하여 값을 조절할 수 있다. [그림 9]는 100MB 파일에 대해 파일 수정 비율 임계값의 변화에 따라 하이브리드 파일 동기화 기법을 적용했을 때 지연 시간의 변화를 측정한 것이다. 각 지연 시간은 파일을 10%부터 100%까지 수정한 동기화 지연시간의 평균값이다. 임계값이 0인 경우는 하이브리드 파일 동기화가 파일 전송과 동일하게 작동하고 임계값이 100%인 경우는 델타 인코딩과 동일하게 작동한다. 실험 결과, 파일 수정 비율 임계값이 50%일 때 파일 동기화 지연 시간이 최소가 되었다.

그림 9 파일 수정 비율 임계값에 따른 하이브리드 파일 동기화 지연 (100MB 파일)

Fig. 9 Hybrid file synchronization delay according to modification ratio threshold (100MB file)

그림 10 파일 수정 동기화 완료 시간

Fig. 10 Synchronization delay of modified file

[그림 10]은 파일 크기 별로 하이브리드 파일 동기화와 델타 인코딩, 파일 전송의 동기화 완료 시간을 비교한 그래프이다. 이전 실험의 결과에 따라 하이브리드 파일 동기화의 파일 크기 임계값은 1MB로, 파일 수정 비율 임계값은 50%로 설정했다. 파일 수정 비율 임계값은 파일 크기에 따라 동기화 완료 시간을 최소화하는 비율이 다르기 때문에 각 파일 크기별 최적 임계값의 평균값으로 결정했다. 그래프에서 나타난 바와 같이, 하이브리드 파일 동기화 방법은 델타 인코딩과 파일 전송이 이점을 나타내는 부분을 적용하기 때문에 항상 두 방법보다 빠른 동기화 완료 시간을 나타낸다.

6. 결 론

본 논문에서는 델타 인코딩 기반의 rsync 알고리즘과 파일 전송을 선택적으로 통신 프레임워크(CM)에 적용한 하이브리드 파일 동기화 프레임워크를 제안했다. 델타 인코딩은 파일의 전체를 전송하는 파일 전송 방법 대신 동기화 대상인 두 파일의 블록 매칭 과정을 통해 차이점만을 전송하기 때문에, 두 파일의 차이가 작을수록 동기화 성능이 향상된다. 반면에, 클라이언트와 서버 파일의 차이가 클수록 델타 인코딩이 여전히 파일 전송에 비해 나은지 확인을 위해 신규 파일 및 수정된 파일의 동기화 완료 시간을 비교했다. 실험 결과, 공통 블록이 존재하지 않는 신규 파일은 파일 전송이 델타 인코딩보다 동기화 완료 시간이 더 짧았다. 반면에, 파일 내용 추가를 통해 공통 블록이 존재하는 경우에는 델타 인코딩이 파일 전송보다 동기화 완료 시간을 단축했다. 기존 파일 내용을 수정하는 경우, 파일 크기가 작거나 수정 범위가 큰 파일은 파일 전송이 델타 인코딩보다 동기화 완료 시간이 더 짧았다. 델타 인코딩은 1MB 이상의 파일에서 수정 범위가 작을수록 동기화 완료 시간을 크게 단축했다. 결론적으로, 하이브리드 파일 동기화 프레임워크는 동기화 대상 파일의 크기, 수정 타입과 수정 범위에 따라 델타 인코딩 및 파일 전송을 선택적으로 사용함으로써 최적의 동기화 성능을 보일 수 있음을 보였다. 향후 연구에서는, 파일 동기화 클라이언트 파일의 로컬 모드 및 온라인 모드 기능을 분석하여 파일 액세스 시간과 저장 공간을 같이 고려한 동기화 성능 향상 방법을 연구할 계획이다.