델타 동기화는 목적지에 이미 있는 블록을 다시 보내지 않습니다. 대신 계산 비용을 지불합니다. Rsync는 가능한 바이트 오프셋을 따라 약한 체크섬을 굴리고, 강한 다이제스트로 후보를 확인하며, 목적지가 보낸 지문 목록을 검색합니다. Dsync 같은 콘텐츠 정의 방식은 가변 크기 경계를 찾고 비슷한 비교를 수행합니다. 양쪽 종단이 델타를 만드는 시간이 실제 전송 시간보다 길어질 수 있습니다.
이 작업은 저장 계층에서 이미 수행됐을 수 있습니다. BTRFS와 ZFS는 저장 블록의 체크섬을 관리하고, fs-verity와 dm-verity는 암호학적 다이제스트를 보관합니다. 중복 제거, 객체 저장소, 백업 시스템도 무결성이나 데이터 식별을 위해 지문을 계산합니다. SkySync는 파일의 모든 바이트를 다시 해시하지 않고 이러한 결과를 동기화 프로토콜이 사용할 수 있는지 묻습니다.
단순히 체크섬 필드 하나를 공개해서는 해결되지 않습니다. 저장 블록과 동기화 청크의 경계 및 알고리즘이 다를 수 있습니다. 파일시스템은 블록별 CRC32C를 기록하지만 프로토콜은 더 큰 고정 청크의 Adler32 또는 콘텐츠 정의 구간의 SHA-256을 요구할 수 있습니다. 따라서 SkySync는 저장 체크섬을 그대로 토큰으로 쓰지 않고 조합 알고리즘의 입력으로 사용합니다.
고정 크기와 콘텐츠 정의 델타의 서로 다른 재사용 경로
고정 크기 경로인 SkySync-F는 rsync를 수정합니다. 저장 메타데이터가 작은 블록의 체크섬을 제공하면 클라이언트와 서버가 인접 값을 결합해 페이로드를 다시 읽지 않고 프로토콜 청크의 체크섬을 얻습니다. 강한 다이제스트로 후보를 최종 확인하고, 수정한 해시 테이블로 기존의 여러 단계 약한 체크섬 탐색을 줄입니다.
조합 결과는 데이터를 직접 해시한 값과 같아야 합니다. CRC처럼 조합 가능한 체크섬은 다항식 성질과 구간 길이를 이용해 이어 붙인 범위의 값을 계산할 수 있습니다. 청크 경계의 일부 블록은 별도 처리가 필요합니다. SkySync는 덮이지 않은 조각을 읽거나 계산해 완전한 블록 메타데이터와 결합하므로 최적화 경로가 델타의 정체성을 바꾸지 않습니다.
콘텐츠 정의 경로인 SkySync-C는 dsync를 수정합니다. 저장 체크섬으로 지문 계산을 가속하고 배타적 논리합 및 0 추가 연산을 이용해 청크 발견에 필요한 약한 값을 만듭니다. 경량 매칭 구조가 강한 체크섬 비교 전에 후보를 줄입니다. 유용한 메타데이터를 이미 가진 쪽에서 페이로드 스캔을 덜 하도록 클라이언트와 서버가 역할을 나눕니다.
델타 정의를 유지한 채 줄이는 계산량
SkySync는 rsync 및 dsync와 같은 전송 구조를 유지합니다. 체크섬 목록, 매칭 토큰, 변경된 페이로드를 주고받으며 평가 경로는 32비트 CRC32C와 256비트 SHA-256을 사용합니다. 강한 체크섬의 추가 비트 때문에 일부 조건에서 트래픽이 조금 늘지만, 보내는 변경 구간은 본질적으로 같습니다.
이 호환성은 속도 향상이 더 약한 검출이나 거친 델타에서 나온 것이 아님을 보여 줍니다. 저장 시스템이 이미 지문 비용을 지불했고, SkySync는 대수적 조합과 경계 보정으로 동기화 알고리즘에 필요한 식별자를 만듭니다. 파일 복원 결과를 유지하면서 반복 작업을 제거하는 범위의 최적화입니다.
체크섬 재사용에는 정확성 계약도 필요하므로, 메타데이터가 동기화 대상 파일과 정확히 같은 버전을 나타내야 합니다. 메타데이터 추출 중 쓰기가 경합하면 서로 다른 시점의 지문이 섞일 수 있습니다. 스냅샷, 버전 식별자, 파일시스템 잠금으로 페이로드와 체크섬을 한 시점에 묶어야 합니다. 무결성 체크섬도 해당 신뢰 모델 안에서 손상을 찾을 뿐, 신뢰할 수 없는 원격 저장소가 보낸 인증 진술로 자동 승격되지는 않습니다.
종단 계산과 전송을 분리한 WAN 시험
평가는 서로 다른 데이터센터의 Alibaba Cloud 인스턴스 두 개를 사용했습니다. 각 인스턴스는 Intel Xeon 8269CY 가상 CPU 4개, 메모리 32GB, 초당 300MB급 1TB 클라우드 SSD를 갖췄습니다. Linux 5.15의 Ubuntu 22.04와 BTRFS를 사용했고, 두 장비 사이 평균 왕복 지연은 35밀리초, 대역폭은 500Mbps였습니다. 일부 시험은 100Mbps로 제한했습니다.
미세 시험은 10MB와 100MB 파일에 삽입, 잘라내기, 바이트 반전 변경을 적용했습니다. 작은 파일은 256바이트에서 1MB, 큰 파일은 2KB에서 8MB까지 변경했습니다. 각 변경은 무작위 위치의 겹치지 않는 256바이트 수정으로 구성했습니다. 양쪽 파일이 같은 조건도 포함해 페이로드를 다시 읽지 않고 동일성을 확인하는 비용을 측정했습니다.
SkySync-F는 하드웨어 체크섬 지원이 없을 때 클라이언트에서 rsync보다 1.2배에서 2.0배 빨랐고 계산량을 32.1%에서 64.9% 줄였습니다. 하드웨어 지원 조건에서는 각각 1.1배에서 1.8배, 20.5%에서 54.3%였습니다. SkySync-C는 지원이 없을 때 dsync보다 1.3배에서 1.7배 빨랐고 계산량을 25.7%에서 42.3% 줄였습니다.
서버에서는 최대 개선 폭이 더 컸습니다. Dsync 서버는 보통 지문을 계산하고 청크를 검색하기 때문입니다. 메타데이터 재사용과 단순화한 검색으로 계산량이 최대 89.3% 줄었고, 하드웨어 지원 조건에서는 최대 76.5% 줄었습니다. 하드웨어는 보고된 시간 차이를 최대 10.8% 좁혔지만, 청크 검색과 경계 처리가 남아 있어 이점을 없애지는 못했습니다.
실제 효과의 상한을 정하는 네트워크 대역폭
전체 동기화 시간에는 클라이언트 작업, 네트워크 전송, 서버 작업이 들어갑니다. 100Mbps에서는 500Mbps보다 전송 시간이 길었지만, 변경량이 작은 여러 조건에서는 체크섬 생성과 검색이 여전히 지배적이었습니다. 10MB 파일에서 2KB 미만, 100MB 파일에서 128KB 미만을 바꿨을 때 SkySync-F는 하드웨어 지원 없이 전체 시간을 26.7%에서 72.1% 줄였습니다.
변경 비율이 커지면 일치하지 않는 바이트가 지배적이 되고 모든 델타 방식은 전체 전송에 가까워집니다. 체크섬 기법으로 이 페이로드를 없앨 수는 없습니다. 또한 실제 델타가 큰 저대역폭·고지연 경로에서는 종단 CPU 절감이 네트워크 시간에 가려질 수 있습니다. 최대 체크섬 속도가 아니라 운영 변경률에서 측정한 종단 완료 시간이 도입 기준이어야 합니다.
실제 데이터셋 다섯 개는 채팅 데이터, Ubuntu 콘텐츠, Nutanix 스냅샷, 위키백과 데이터, 커널 트리를 포함했고 스레드 1개, 2개, 4개, 8개로 평가했습니다. SkySync는 하드웨어 지원 없이 약 1.2배에서 1.5배, 지원 조건에서 1.15배에서 1.4배 빨랐습니다. 종단 계산 구간은 19.2%에서 43.7% 줄었습니다. Ubuntu 데이터셋은 다른 일부보다 작았지만 수정 비율이 높아 더 많은 트래픽을 만들었으므로 파일 크기만으로 비용을 예측해서는 안 됩니다.
네트워크 트래픽은 rsync 및 dsync와 비슷했습니다. 강한 체크섬 때문에 메타데이터가 조금 늘었지만 CPU 절감을 큰 델타와 맞바꾸지는 않았습니다. 클라우드 사이 반출 바이트가 종단 계산보다 비쌀 수 있는 환경에서 꼭 확인해야 할 결과입니다.
저장 계층 인터페이스가 준비된 경우에만 싼 추출
연구진은 EXT4와 F2FS의 fs-verity에서 SHA-256 메타데이터를 추출하고, BTRFS의 내장 SHA-256 또는 CRC32C와 MeGA 저장 시스템의 전용 함수를 사용했습니다. 실제 데이터셋 다섯 개에서 추출 시간은 1.8초에서 119.2초였고, 같은 조건에서 체크섬을 직접 계산하면 26초에서 246초가 걸렸습니다.
BTRFS 추출은 전체 SkySync 시간의 0.11%에서 7.14%였습니다. EXT4와 F2FS는 fs-verity 메타데이터 추출 절차가 복잡해 더 느렸습니다. MeGA는 저자들이 메타데이터 배치와 조회 함수를 통제해 효율적이었습니다. 저장 시스템에 체크섬이 있다는 사실만으로 충분하지 않으며, 버전과 범위를 지정할 수 있는 저비용 내보내기 인터페이스가 필요합니다.
체크섬의 생성 시점도 비용에 포함해야 합니다. 쓰기 때 만들 수도 있고 첫 읽기 때 지연 생성하거나 파일을 봉인한 뒤에만 만들 수도 있습니다. 동기화 작업이 체크섬 생성을 촉발한다면 비용은 사라진 것이 아니라 다른 계층으로 이동한 것입니다. 운영자는 동기화 작업뿐 아니라 체크섬 생산자의 CPU와 쓰기 증폭도 함께 계산해야 합니다.
여러 계층이 공유하는 지문 서비스
SkySync는 파일 동기화를 저장 메타데이터의 소비자로 봅니다. 같은 인터페이스를 중복 제거, 백업 비교, 스크러빙, 복제에 쓸 수 있지만 공유 범위가 넓어질수록 알고리즘과 출처를 명확히 해야 합니다. 다이제스트 레코드에는 알고리즘, 블록 길이, 파일 버전, 생성 시점, 무결성 보호 방식을 기록해야 합니다.
이미 체크섬을 계산하고, 대부분 비슷한 큰 파일을 비싼 링크로 동기화하며, 메타데이터를 일관되게 공개할 수 있는 시스템이 가장 적합합니다. 체크섬이 없는 저장소, 자주 다시 쓰는 작은 파일, 델타가 객체 전체에 가까운 작업에서는 이점이 작습니다. 지문은 암호문이나 압축 블록을 나타내는데 동기화는 평문을 비교한다면 암호화와 압축도 재사용을 막습니다.
이 논문의 운영 교훈은 계층 사이의 반복 스캔을 찾는 것입니다. 저장, 백업, 복제, 동기화는 관련된 증거를 서로 독립적으로 계산하는 경우가 많습니다. SkySync는 경계, 버전, 신뢰를 명시하면 네트워크 분모를 바꾸지 않고 종단 계산을 최대 89.3% 줄일 수 있음을 보여 줍니다.
출처와 저작권 안내
이 글은 Silicon & Systems의 편집 분석입니다. 메커니즘, 평가 조건, 결과, 한계를 자체 문장으로 재구성했습니다. 원문의 문장, 표, 도판을 복제하지 않았으며 본문 도판은 이 글을 위해 새로 만들었습니다. 논문은 USENIX FAST 2026 발표 페이지에서 확인할 수 있습니다. 저작권은 저자에게 있으며 연도는 2026년입니다.