CDCファイル転送

 (github.com/google)
2 ポイント 投稿者 GN⁺ 2025-10-02 | 1件のコメント | WhatsAppで共有
  • CDC File Transfer は Google が開発したオープンソースツールで、Windows と Linux 間のファイル同期およびストリーミングをサポートする
  • ファイルの変更された部分だけを転送する Content Defined Chunking (CDC) 技術を活用し、既存の rsync と比べて最大 30 倍高速な速度を実現する
  • cdc_rsync と cdc_stream の 2 つの主要ツールを提供し、それぞれファイル同期とリアルタイムストリーミング機能を担う
  • 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 へファイル同期するツールで、既存の Linux 版 rsync の欠点を克服する
  • 時刻とファイルサイズが一致するファイルは素早くスキップし、変更されたファイルだけを効率的に転送する
  • FastCDC を活用して、変更されたデータの位置だけを検出して転送することで、最小限のトラフィックと高速転送を実現する
  • 同期テストの結果、Cygwin 上で動かした rsync より約 3 倍、標準の Linux 版 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 パスに保存される
  • 詳細ログおよびデバッグオプションを提供（verbosity レベルの JSON 設定）
  • cdc_rsync はコンソールにログを出力し、-vvv、-vvvv で詳細ログを出力可能
  • 失敗した SSH/SFTP コマンドを追跡し、直接実行して問題原因を分析しやすい

技術スタックと運用情報

  • 主な開発言語は C++、一部に Python / ビルド管理用 Starlark を使用
  • Apache-2.0 ライセンス、8 人以上のコントリビューターを擁し、GitHub で 3.3k stars を獲得
  • 2023 年以降は追加開発がなく、Archived 状態となっている

要約

  • CDC File Transfer は Windows-Linux 間での大容量ファイルやディレクトリの反復転送において、業界トップクラスの効率と速度を提供する
  • リモート開発、ゲーム、メディア、データ分析などのクロスプラットフォーム作業環境で、同期とストリーミングのプロセスを大幅に短縮できる利点がある
  • 他の同期/ストリーミングツールと比べても、シンプルさ、高速な部分変更検知、優れたキャッシュ機能によって強い競争力を持つ
  • SSH/SFTP 認証や、各種コマンドラインまたは設定ファイルに基づく柔軟な環境設定により、エンジニアが容易に導入・運用できる
  • ソースコードの閲覧やカスタマイズが可能で、オープンソースコミュニティですでに高い評価と活用実績を記録している

関連記事

1件のコメント

 
GN⁺ 2025-10-02
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 条件で定義して使っているのでは？（Wiki リンク1, Wiki リンク2）。rsync と比べて速いのは、rolling hash 自体の効率や、ネイティブ Windows 実行ファイルを使っていること（Windows のファイルシステムは遅い）などが理由ではないかと疑っている。いずれにせよ性能向上は興味深く、オープンソース化されたのも好印象。この方法が rsync 本体にも入ってほしい

    • rsync は content-defined chunking を使っておらず、宛先ファイル上で固定サイズのブロックを使う。rolling hash によってソースファイル中のどの位置にそのブロックがあっても検出でき、再送を避けられる（技術文書）
    • レポジトリの README では rsync とのアプローチの違いがとても丁寧に説明されている
    • rsync は事実上停止したプロジェクトのように感じる。長年保守はされているが、多くの品質改善が取り込まれておらず、今では vim のように理論上は管理されているが実際には発展していない印象がある

  • Stadia がこうしてまた一つ長期的な利益を残したのはうれしい。セルフホスト版が出なかったのは残念だが、今の DRM の世界では、もし出ていたらすぐ海賊版扱いされていただろう

    • セルフホストのゲームストリーミングなら moonlight と sunshine の組み合わせがおすすめ。非常によく動く
    • Stadia はセルフホストできなかったと聞いている。開発者が Stadia 対応版を別途ビルドする必要があり、別個の DirectX 代替プラットフォームだった可能性もある。Proton のような軽量エミュレーション環境だったのかもしれないが、実際に遊んだゲームでは Stadia 専用のカスタムキーバインド（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 を作るのか気になっていた人には、このブログ と このブログ の2本が概念をとても分かりやすく説明している

    • ありがとう。元のリンクでは詳しい説明が足りずもどかしかったので、近いうちに読むつもり

  • 核心となる一文: 「この remote diffing アルゴリズムは CDC(Content Defined Chunking) に基づいており、テスト結果では rsync より最大 30 倍高速（1500MB/s 対 50MB/s）」

  • この機能を rsync 標準ツールに統合しようとする作業が進んでいるのか、知っている人がいるだろうか。広く使われてほしい機能だが、公式サイトを見る限り Linux-Linux 間ではまったくサポートされていないようで残念

    • Linux-Linux 対応と、より汎用的な互換性に関する議論は こちら 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 バイナリを Windows にダウンロードして展開すればよい。Linux バイナリは Windows ツールから自動的に ~/.cache/cdc-file-transfer に配置される。別途インストールは不要」という説明が印象的。rsync と違って Linux 側に別サービスをインストールせず動作するのがよい。rsync のその点は少し面倒だった

    • 実際には rsync の最も一般的な使い方は ssh 経由で受信側を自動起動することだ。cdc も同じように動作するので、rsync の利用に別サービスのインストールが必要というのは誤解だ

  • IBM Aspera もこれに近い方式で動いているのだろうか。ゲームパブリッシャーの QA をしていたとき、Aspera で画面録画をアップロードしたことがあるが、オフィス回線の通常アップロード速度よりはるかに速かった（IBM Aspera の紹介）