▲

CDC 파일 전송

 (github.com/google)
1P by GN⁺ 12일전 | ★ favorite | 댓글 1개
  • CDC File Transfer는 Google에서 개발한 오픈 소스 도구로, Windows와 Linux 간 파일 동기화 및 스트리밍을 지원함
  • 파일을 변경된 부분만 전송하는 Content Defined Chunking (CDC) 기술을 활용해, 기존 rsync 대비 최대 30배 빠른 속도를 달성함
  • cdc_rsync와 cdc_stream 두 가지 주요 도구를 제공하며, 각각 파일 동기화와 실시간 스트리밍 기능을 수행함
  • Windows 기반 개발자가 Linux 환경에 효율적으로 파일을 배포·테스트하도록 설계되어, 원격 개발·게임 개발환경에서 탁월함
  • ssh와 sftp 기반 인증을 지원하며, 사용은 직관적이며, 다양한 플랫폼에 맞는 바이너리를 제공함

개요 및 프로젝트의 중요성

  • CDC File Transfer는 Google에서 오픈 소스로 공개한 파일 전송 도구 모음으로, Windows에서 Linux 또는 Windows 간의 파일 동기화 및 스트리밍을 빠르고 효율적으로 처리함
  • 이 프로젝트는 Stadia 게임 개발 환경을 위해 만들어졌으며, 기존 scp나 rsync의 한계(느린 전송, 전체 파일 복사, 델타 모드 부재) 를 해결하기 위해 탄생함
  • 핵심 기술은 FastCDC라는 Content Defined Chunking 알고리듬이며, 파일 변경 시 실제 변경된 데이터만 전송해 대용량 반복 동기화에 최적화됨
  • 오픈 소스임에도 상용 수준의 성능(예: 1500 MB/s 동기화 속도, sshfs 대비 2~5배 빠른 스트리밍)을 제공하며, 클라우드/원격 개발 환경에서 경쟁 서비스보다 확연한 효율을 갖춤

주요 도구 설명

cdc_rsync

  • Windows에서 Linux로 파일 동기화하는 도구이며, 기존 리눅스 rsync의 단점을 극복함
  • 시간 및 파일 크기가 일치하는 파일은 신속히 건너뛰고, 변경된 파일만 효율적으로 전송함
  • FastCDC를 활용하여, 변경된 데이터의 위치만 감지해 전송함으로써, 최소한의 트래픽과 빠른 전송을 제공함
  • 동기화 테스트 결과, Cygwin에서 실행한 rsync보다 약 3배, 표준 리눅스 rsync보다 훨씬 빠른 성능을 보임
  • 고속 압축 지원과, 파일을 바이트 단위까지 검증하는 간단하면서도 효율적인 알고리듬 구조를 갖춤

cdc_stream

  • Windows의 폴더·파일을 Linux에서 마치 로컬 파일처럼 실시간으로 스트리밍해 접근 가능하게 만듦
  • 기존 sshfs 구조와 유사하나, 파일 읽기 속도와 캐시 성능이 최적화되어 있음
  • 변경 감지 및 차등 스트리밍을 통해, 변경된 데이터만 재전송하며 메타데이터 처리도 빠름
  • Linux 디렉터리는 readonly로 제공, Windows에서 변경된 파일이 거의 즉시(최대 수 초 수준) Linux에 반영됨
  • 게임 데이터 등 대용량 파일 접근이 필요한 개발 환경에서, 실제로 sshfs 대비 2~5배의 성능 향상을 보임

지원 플랫폼

  • cdc_rsync: Windows x86_64 ↔ Ubuntu 22.04 x86_64 간 주로 지원, 원격 동기화/로컬 동기화 모두 점진적 지원
  • cdc_stream: Windows x86_64에서 Ubuntu 22.04 x86_64로의 스트리밍 지원, 반대 방향이나 다른 플랫폼은 미지원

인증/설정 방식

  • ssh.exe 및 sftp.exe를 통한 패스워드 없는 인증 방식(키 기반 인증 권장)
  • Windows에서 명령 줄 경로나 환경 변수로 커맨드 세부 경로 지정 가능
  • 추가적인 SSH 명령어 옵션, 사용자별 설정 파일(%USERPROFILE%.ssh\config) 활용 가능
  • Google 사내 사용자는 별도의 보안 키 기반 인증 환경 변수 제공

사용 예시

cdc_rsync 사용 예시

  • 파일 동기화: cdc_rsync C:\path\to\file.txt user@linux.device.com:~
  • 와일드카드 및 디렉터리 전체 재귀 동기화 지원: cdc_rsync C:\path\to\assets\* user@linux.device.com:~/assets -r
  • 동기화 상태 실시간 확인(-v 옵션), 로컬 파일 간 동기화도 가능

cdc_stream 사용 예시

  • 디렉터리 스트리밍 시작: cdc_stream start C:\path\to\assets user@linux.device.com:~/assets
  • 스트리밍 세션 중단: cdc_stream stop user@linux.device.com:~/assets
  • 와일드카드로 여러 세션 관리 가능

문제 해결 및 로깅

  • cdc_stream은 백그라운드 서비스 기반 동작, 로그는 기본적으로 %APPDATA%\cdc-file-transfer\logs 경로 저장
  • 상세 로그 및 디버깅 옵션 제공(verbosirty 레벨 JSON 설정)
  • cdc_rsync는 콘솔 로그 출력, -vvv, -vvvv로 상세 로그 출력 가능
  • 실패한 SSH/SFTP 커맨드 추적 및 직접 실행해 문제 원인 분석 용이

기술 스택 및 운영 정보

  • 주요 개발 언어는 C++ , 일부 파이썬/빌드관리용 Starlark
  • Apache-2.0 라이선스, 8인 이상의 기여자 보유, GitHub 기준 3.3k stars 달성
  • 2023년 이후로는 추가 개발 없이 Archived 상태

요약

  • CDC File Transfer는 Windows-Linux 간의 대용량 파일 및 디렉터리 반복 전송에 있어서 업계 최상위 수준의 효율과 속도를 제공함
  • 원격 개발, 게임, 미디어, 데이터 분석 등 크로스플랫폼 작업환경에서 동기화와 스트리밍 과정을 크게 단축시키는 이점이 있음
  • 타 동기화/스트리밍 툴 대비 단순성, 빠른 부분 변경 감지, 뛰어난 캐시 기능으로 강력한 경쟁력을 갖춤
  • SSH/SFTP 인증, 다양한 명령 줄 또는 설정 파일 기반의 유연한 환경 설정으로 엔지니어가 쉽게 도입 및 운용 가능함
  • 소스 코드 열람 및 커스터마이즈가 가능하며, 오픈 소스 커뮤니티에서 이미 높은 평판과 활용도를 기록 중임
▲
GN⁺ 12일전  [-]
Hacker News 의견

  • 작년부터 Content Defined Chunking에 대해 다양하게 실험해보고 있음 (특히 bonanza.build). 가장 널리 쓰이는 FastCDC 알고리즘에도 개선 여지가 있다는 걸 발견했으며, lookahead 방식을 활용하면 성능이 크게 향상됨. 이에 대한 구현체로는 buildbarn/go-cdc 참조 바람

    • 이 lookahead 방식은 Lempel-Ziv 압축기에서의 “lazy matching”과 매우 비슷해 보임 (관련 블로그). Buzhash와의 비교 결과가 궁금함. 보통 gearhash가 구조가 단순해서 더 빠를 것으로 예상함. 참고로 gear init에는 mt19937 대신 rand/v2의 seeded generator가 더 적합할 수 있음
    • bonanza.build가 상당히 인상적임. 아직도 Bazel을 사용 중이었다면 꼭 써보고 싶음
    • go-cdc를 fastcdc 대신 cdc_rsync에서 사용할 경우 성능 면에서 어느 정도 차이가 발생할지 궁금함
    • AI가 이 분야에 기여할 여지가 있을지 생각해보게 됨. 데이터 압축 (AI 기반 압축 사례), RF 변조 최적화 (논문 링크) 등에서 이미 AI가 유용하게 쓰이고 있음. 작은 모델(특히 SSM 계열)로 chunk 경계 최적화를 학습시키는 것도 가능할 것으로 기대함

  • rsync가 이미 content-defined chunk 경계를 rolling hash 조건으로 정의해 사용하고 있지 않음? (위키 링크1, 위키 링크2). rsync 대비 속도 개선은 rolling hash의 효율성과 네이티브 윈도우 실행 파일 사용(윈도우 파일 시스템이 느림) 등 때문이 아닐까 의심됨. 어쨌든 성능 향상이 흥미로우며, 오픈 소스화된 점도 긍정적임. 이 방법이 rsync 내부로도 들어가길 바람

    • rsync는 content-defined chunking을 사용하지 않고, 목적 파일 위에서 고정 크기 블록을 사용함. rolling hash로 소스 파일 어느 위치에서든 해당 블록을 감지해 재전송을 피할 수 있음 (기술 문서)
    • 레포의 README에서 rsync와의 접근법 차이를 무척 친절하게 설명함
    • rsync는 사실상 정지된 프로젝트로 느껴짐. 오랜 기간 유지되고 있지만, 많은 품질 개선이 누락됐고 지금은 마치 vim처럼 이론상만 관리되고 실제론 발전이 없는 듯한 인상임

  • Stadia가 이렇게 또 하나의 장기적인 이득을 남겼다는 게 반가움. 직접 호스팅 버전이 안 나와서 아쉬운데, 요즘 DRM 세상에서 만약 나온다면 곧바로 해적판 취급 받게 됨

    • 셀프 호스팅 게임 스트리밍엔 moonlight와 sunshine 조합이 추천임. 매우 잘 작동함
    • Stadia에서 직접 호스팅이 불가능했다고 들었음. 개발자들이 Stadia 지원을 별도로 빌드해야 했고, 별도의 DirectX 대체 플랫폼이었을 수도 있음. Proton 같은 가벼운 에뮬레이션 환경이었을수도 있지만, 실제로 플레이한 게임들은 Stadia 전용 커스텀 키 바인딩(스태디아 전용 심볼)이 게임 내에 표시됨. 분명한 커스터마이징이 있던 것임. 이 방식은 PlayStation, Xbox, Nvidia의 게임 스트리밍과도 확연히 차별됨. Amazon Luna는 잘 모르겠음
    • 셀프 호스팅 리모트 게임 스트리밍엔 Moonlight/Sunshine(Apollo) 참고 바람. Stadia는 별도의 전용 빌드가 필요해 큰 의미가 없음
    • DRM 시대에 ‘해적판’이란 게 정확히 무슨 의미인지 궁금함. 직접 소유한 PC 게임을 클라우드로 스트리밍하는 것을 의미하는지?
    • "셀프 호스팅 stadia"는 실상 이미 여러 서비스, 툴에서 구현된 바 있음. Steam 자체에 훌륭한 게임 스트리밍 내장되어 있음. Nvidia, AMD도 과거 GPU 드라이버에 해당 기능을 넣었었고, Steam Deck에서도 게임을 스트리밍할 수 있음. Sony의 PS4/PC 스트리밍이나, Microsoft의 Xbox 스트리밍처럼 다양한 사례가 존재함

  • Content Defined Chunking이 실제로 어떻게 chunk를 생성하는지 궁금했던 사람은 이 블로그, 이 블로그 두 개가 개념을 매우 쉽게 설명함

    • 고마움. 원래 링크에서 자세한 설명이 부족해 답답했는데, 곧 읽어볼 계획임

  • 핵심 문구: "이 remote diffing 알고리즘은 CDC(Content Defined Chunking)를 기반으로 하며, 테스트 결과 rsync보다 최대 30배 빠름(1500MB/s 대 50MB/s)"

  • 혹시 이 기능을 rsync 표준 도구에 통합하려는 작업이 진행 중인지 아는 사람 있는지 궁금함. 이 기능이 널리 쓰였으면 좋겠는데 공식 웹사이트만 보면 리눅스-리눅스 간에는 지원이 아예 안 돼서 아쉬움

    • 리눅스-리눅스 지원 및 더 범용적인 호환성에 대한 논의가 여기 1, 여기 2에 정리되어 있음

  • 이 프로젝트도 꽤나 멋지다고 느낌. 비슷한 기능을 내 업무에 맞게 자체 구현한 적이 있는데, 조건이 까다로울 땐 꽤 중요함. 그런데 rsync로부터 시작하는 게 더 쉽지 않았을까 하는 생각이 듦

    • “scp는 전체 파일만 복사하고 delta 모드가 없으며, 작은 파일이 많으면 느리고 압축도 느림”이라고 하지만, rsync에서 -z 옵션을 이용해 압축도 쓸 수 있음(설명). CPU가 충분하면 -z 옵션을 권장하며, 속도도 빨라짐. 아주 빠르진 않아도 scp보단 rsync가 더 나은 출발점이라 생각함
    • “리모트 diffing 알고리즘이 CDC 기반이며, 테스트 결과 rsync보다 최대 30배 빠름(1500 MB/s vs 50 MB/s)”
    • rsync가 일부 분야 특히 게임 개발 등에서는 최적화가 부족한 듯함. 게임 개발에는 수십~수백만 개의 파일과 디렉터리를 복사하는 상황이 잦은데, rsync는 디렉터리/파일 생성을 직렬화하는 성향 탓에 속도가 급격히 저하됨. GNU parallel 등으로 N개의 rsync 작업으로 쪼개 동작시키거나 직접 파일 목록을 생성해서 돌려봤지만, 결국엔 syncthing처럼 프리인덱싱이 가능한 툴로 해결했음

  • 이 기술이 git에도 적용될 수 있을지 궁금함. git blob은 길이 정보를 포함해 해시를 만드는데, 데이터 일부만 바꿔도 처음부터 해시를 다시 계산해야 함. CDC라면 훨씬 효율적일 것 같음

    • xet에서 git lfs를 대체하기 위해 CDC 방식이 실제로 적용되었음 (관련 사례)
    • 백업 도구인 restic/borg 등도 CDC를 쓰고 있는데, git 대체용은 아직 제대로 시도된 게 있는지 궁금함

  • “최신 릴리스의 precompiled 바이너리를 윈도우에 다운로드해 압축 해제하면 됨. 리눅스 바이너리는 윈도우 툴에서 자동으로 ~/.cache/cdc-file-transfer에 배포됨. 별도 설치가 필요 없음”이라는 설명이 인상적임. rsync와 달리 리눅스 목적지에 별도의 서비스 설치 없이 동작하는 점이 좋음. rsync의 이런 점이 살짝 번거로웠음

    • 실제로 rsync의 가장 흔한 사용 방식은 ssh로 원격에서 받는 쪽을 자동 실행시키는 것임. cdc도 동일하게 동작하므로, rsync 사용하려면 별도 서비스 설치가 필요하다는 부분은 오해임

  • IBM Aspera도 이 방식과 비슷하게 동작하는지 궁금함. 게임 퍼블리셔 QA로 일할 때 Aspera로 화면 녹화를 업로드했는데, 사무실 인터넷 일반 업로드 속도보다 훨씬 빠른 속도를 보여줬음 (IBM Aspera 소개)

답변달기