rsync는 이제 놓아줄 때가 되었나? eBPF 기반 파일시스템 복제 도구 Foxing 딥다이브

수십 년간 리눅스 환경에서 파일 동기화와 백업의 표준은 단연 rsync였습니다. 하지만 페타바이트 단위의 스토리지와 수천만 개의 작은 파일들이 쏟아지는 현대의 인프라 환경에서 rsync는 종종 한계를 드러냅니다. inotify 기반의 도구들은 이벤트 유실 문제로 골치를 썩이고, DRBD 같은 블록 레벨 복제는 설정이 무겁고 유연성이 떨어지죠.

최근 Hacker News에서 제 눈길을 끈 프로젝트가 있습니다. 바로 eBPF를 활용해 리눅스 파일시스템 복제를 구현한 Foxing입니다. Rust로 작성된 이 도구는 커널 레벨에서 파일시스템 이벤트를 낚아채어 비동기로 타겟에 리플레이하는 방식을 취합니다. 솔직히 처음엔 “또 하나의 장난감 프로젝트인가?” 싶었지만, 아키텍처 문서를 뜯어볼수록 현업의 페인 포인트를 정확히 짚어낸 엔지니어링에 감탄하게 되었습니다.

아키텍처 딥다이브: fxcp와 foxingd

Foxing은 크게 두 가지 컴포넌트로 나뉩니다. BPF나 루트 권한 없이 단독으로 동작하는 스마트 복사 도구인 fxcp와, eBPF 기반으로 실시간 이벤트를 처리하는 데몬인 foxingd입니다.

가장 흥미로운 부분은 이들이 채택한 Auto-Adaptive Copy Strategy입니다. 단순히 read()와 write()를 반복하는 것이 아니라, 타겟 스토리지의 특성을 파악해 최적의 I/O 경로를 동적으로 선택합니다.

  • Tier 0.5 (NFS Bypass): NFSv4.2 환경에서는 OPEN, WRITE, CLOSE를 단일 RPC로 묶어서 보냅니다. VFS 경로를 우회하여 작은 파일 전송 시 rsync보다 2.8배 빠른 속도를 냅니다.
  • Tier 1 (FICLONE): Btrfs나 XFS 같은 CoW 파일시스템에서는 ioctl을 통해 즉각적인 reflink 복제를 수행합니다.
  • Tier 3 (io_uring): 대용량 파일이나 크로스 디바이스 전송에서는 io_uring을 활용해 비동기 파이프라인을 구축합니다.

여기에 BLAKE3 해시 기반의 Merkle 트리 델타 감지 기능까지 더해져, 변경된 청크만 전송하는 극강의 효율성을 보여줍니다.

eBPF를 활용한 이벤트 캡처의 우아함

기존의 실시간 동기화 도구들이 inotify의 스케일링 이슈로 고통받았던 것과 달리, Foxing은 eBPF를 통해 vfs_write_iter, security_inode_create 등의 커널 함수를 직접 후킹합니다.

캡처된 이벤트는 33MB의 링 버퍼를 거쳐 CAKE 알고리즘에서 영감을 받은 4-Tier 우선순위 큐(TinnedDispatcher)로 인입됩니다. 여기서 눈여겨볼 점은 분산 시스템의 고질적인 문제인 ‘순서 보장(Ordering)‘을 해결한 방식입니다. 파일 생성이나 이름 변경 같은 Control-plane 이벤트는 Worker 0에서 직렬화하여 처리하고, 단순 데이터 쓰기(Bulk)는 여러 워커에 해시 분산시킵니다. 로컬 파일시스템 동기화에 분산 시스템의 CQRS 패턴을 도입한 셈인데, 매우 훌륭한 설계라고 평가하고 싶습니다.

비판적 시선: 정말 프로덕션 레벨인가?

물론 장점만 있는 것은 아닙니다. 15년 차 엔지니어의 관점에서 볼 때 몇 가지 우려되는 지점들이 있습니다.

첫째로, 자체 테스트 슈트의 Phase 3 (Rename Chain Storm) 에서 실패가 발생한다는 점입니다. 2.5초 동안 500개의 이벤트가 쏟아질 때 중간 과정에서 ‘고스트 파일’이 일시적으로 생성된다고 문서에 명시되어 있습니다. 개발자는 “일시적이며 자가 치유된다”고 말하지만, 트랜잭션이 민감한 데이터베이스나 실시간 로그 파이프라인이 이 타겟 스토리지를 읽고 있다면, 이 짧은 순간의 불일치가 치명적인 애플리케이션 에러로 이어질 수 있습니다.

둘째로, 메타데이터 오버헤드입니다. XFS나 Btrfs에서는 xattr을 사용해 오버헤드가 거의 없지만, 이를 지원하지 않는 환경에서는 파일당 4KB의 .foxing_meta 사이드카 파일이 생성됩니다. 수백만 개의 작은 파일이 있는 환경이라면 이 사이드카 파일 자체가 아이노드(inode) 고갈을 유발할 수 있습니다. 따라서 이 도구는 철저하게 XFS나 Btrfs 환경에서만 사용하는 것을 권장합니다.

Hacker News 커뮤니티의 반응

HN 스레드에서는 이 도구를 Syncthing과 비교하는 의견이 많았습니다. 한 유저는 “Syncthing을 대체할 수 있는 설정이 적은 도구였으면 좋겠다”고 언급했죠. 하지만 Foxing은 양방향 동기화가 아닌 단방향 리플리케이션(Mirroring) 엔진이므로 결이 다릅니다. 여담으로 인디 록 밴드 ‘Foxing’과 이름이 같다는 농담도 오가더군요.

원격 서버로의 동기화 방식에 대한 질문도 흥미로웠습니다. Foxing은 자체 네트워크 프로토콜을 발명하는 대신, 유닉스 철학에 맞게 표준 파이프를 활용합니다.

fxcp snap export /source | ssh remote fxcp snap import /destination

이런 식으로 SSH 위에서 스트리밍 임포트/익스포트를 수행하는 방식은 보안과 심플함을 동시에 잡은 영리한 접근입니다.

총평: 도입을 고려해야 할까?

Foxing은 현재 v0.8.1 단계이지만, 내부 아키텍처의 성숙도는 웬만한 상용 솔루션 못지않습니다. 특히 NFS 서버 간의 마이그레이션이나, 로컬 NVMe에서 백업 스토리지로의 실시간 미러링 용도라면 당장 PoC를 진행해 볼 가치가 충분합니다.

다만 Active-Active 클러스터의 공유 스토리지 용도나, 앞서 언급한 Rename Storm 이슈가 크리티컬하게 작용할 수 있는 환경에서는 아직 보수적으로 접근하는 것이 좋습니다. rsync의 완벽한 대체재라기보다는, 현대적인 파일시스템과 커널 기술(eBPF, io_uring)의 이점을 극대화한 고성능 단방향 미러링 엔진 으로 바라보는 것이 정확할 것입니다.

References: