클라우드 스토리지 파일 중복 제거 전략

파일 중복 제거는 워크로드에 따라 클라우드 스토리지를 20~90% 줄이며, 세 가지 기법 중 하나를 사용합니다. 파일 단위(SHA-256 해시로 키를 지정해 동일한 파일을 한 번만 저장), 블록 단위(파일을 4~128 KB 블록으로 청크하고 블록별로 중복 제거), 또는 Rabin 지문을 이용한 가변 길이 청킹인 콘텐츠 정의 청킹(CDC). VM 백업은 10:1 절감, 일반 오피스 파일은 2:1, 미디어 라이브러리는 거의 없습니다. 데이터에 맞는 기법을 선택하세요. 이미 고유한 .mp4 파일 라이브러리에 블록 중복 제거를 실행하면 CPU만 낭비됩니다.

파일 단위 중복 제거: 가장 간단한 절감

파일 단위 중복 제거는 전체 파일 해시를 비교합니다. SHA-256이 같은 두 파일은 동일합니다. 하나를 보관하고 나머지는 그것을 가리키게 합니다. 구현은 주말 하나면 됩니다.

버킷 콘텐츠 목록 작성(S3 Inventory, Azure Inventory, GCS bucket list)
각 객체의 SHA-256 계산(또는 주의 사항이 있는 공급자 제공 ETag 사용)
해시로 그룹화하고 그룹별 정규 키를 선택한 뒤 참조를 업데이트하고 중복 삭제

주의 사항: S3 ETag는 5 GB 미만 단일 파트 업로드에서만 SHA-256과 일치합니다. 멀티파트 업로드는 다른 공식(해시의 해시)을 사용합니다. 안정적인 중복 제거를 위해 aws s3 cp s3://bucket/key - | sha256sum으로 직접 해시를 계산하거나 업로드 시 계산해 메타데이터에 저장하세요.

파일 단위 중복 제거는 사용자가 같은 파일을 반복 업로드할 때 효과적입니다. 공급업체 PDF, 회사 템플릿, 공유 이미지 등. 일반적인 오피스 워크로드에서 10~30% 절감을 기대하세요.

블록 단위 중복 제거: 큰 배율

블록 단위는 각 파일을 고정 크기 청크(4 KB, 16 KB, 64 KB)로 분할하고 각 청크를 해시합니다. 청크의 80%를 공유하는 두 파일은 고유한 20%와 공유 블록 한 복사본만 저장합니다. 백업 제품(Veeam, Rubrik, Commvault), 파일 시스템(dedup=on의 ZFS, Btrfs), 일부 백업 클라우드(클라이언트 측 중복 제거가 있는 Backblaze B2)가 이 방식을 사용합니다.

장점: VM 이미지, 데이터베이스 백업, 넓은 범위를 공유하는 로그 아카이브에서 대폭 압축. 단점: 높은 메모리 사용(중복 제거 인덱스가 RAM에 있음), 쓰기 시 CPU 비용, 인덱스 손상 시 심각한 증폭.

클라우드 오브젝트 스토리지의 경우 블록 중복 제거는 보통 네이티브 기능이 아닌 백업 제품 내부에서 이루어집니다. S3 자체는 중복 제거를 하지 않습니다. Backblaze B2는 클라이언트가 먼저 블록 해시를 보낼 때 업로드 시점에 중복 제거합니다(b2_start_large_file에 사전 해시된 파트 사용).

콘텐츠 정의 청킹(CDC)

고정 크기 청킹은 파일 앞에 바이트 하나가 삽입되면 이후 모든 블록의 해시가 달라지는 문제가 있습니다. 콘텐츠 정의 청킹은 롤링 해시(Rabin-Karp 지문)로 콘텐츠 패턴에 기반해 청크 경계를 정의합니다. 바이트 하나가 삽입되면 바로 그 청크만 변경됩니다.

CDC는 restic, BorgBackup, Duplicacy, Kopia의 기반입니다. 이 오픈소스 도구들은 평균 1~4 MB의 가변 청크로 클라이언트 측에서 중복 제거합니다. 점진적으로 변경되는 500 GB 파일을 백업하면 CDC 기반 백업은 50 GB 미만의 고유 스토리지를 사용하는 경우가 많습니다.

백업 또는 동기화 시스템을 구축한다면 fastcdc-rs나 chunky 같은 라이브러리를 통한 CDC가 현대적 선택입니다. 직접 롤링 해시를 구현하지 마세요. 엣지 케이스가 미묘합니다.

인라인 중복 제거 대 사후 처리 중복 제거

인라인 중복 제거는 쓰기 시점에 실행됩니다. 데이터가 디스크에 닿기 전에 시스템이 블록이 이미 존재하는지 확인합니다. 존재하면 참조를 쓰고, 없으면 블록을 씁니다. ZFS, 대부분의 백업 어플라이언스, 일부 클라우드 스토리지 티어가 사용합니다.

사후 처리 중복 제거는 먼저 쓴 다음 백그라운드 작업으로 중복을 찾아 공간을 회수합니다. Windows Server의 데이터 중복 제거, NetApp의 SnapVault, 대부분의 사용자 공간 도구가 사용합니다. 사후 처리는 쓰기 지연이 낮지만 최대 스토리지가 더 필요합니다(회수 전에 중복이 잠시 존재).

클라우드 워크로드의 경우 인라인 중복 제거는 보통 불가능합니다. S3가 제공하지 않습니다. 예약 작업이 있는 사후 처리(일별 인벤토리, 일별 중복 제거 실행)가 현실적인 패턴입니다.

중복 제거가 도움이 되지 않는 경우

이미 압축되거나 암호화된 데이터는 중복 제거 효과가 낮습니다. 비슷한 내용이라도 두 개의 다른 .mp4 파일은 거의 바이트를 공유하지 않습니다. 같은 평문의 두 암호화된 .zip 파일은 암호화 후 0 바이트를 공유합니다. 그것이 암호화의 요점입니다.

즉 종단간 암호화 파일 스토리지는 사용자 간 중복 제거가 불가능합니다. 수렴 암호화(평문을 해시하고 해시를 키로 사용)는 E2EE에서 중복 제거를 활성화하려는 시도였지만 보안 문제가 있습니다. 파일 확인 공격이 가능합니다. E2EE 파일 서비스의 경우 중복 제거가 사용자 간이 아닌 사용자 자신의 파일 내에서만 이루어진다는 점을 받아들이세요.

중복 제거의 보안 측면

비 E2EE 시스템의 사용자 간 중복 제거는 부채널을 만듭니다. 업로드한 파일이 기존 블록과 중복 제거되면 서버는 다른 누군가가 이미 그 파일을 가졌음을 알게 됩니다. Dropbox가 2011년에 이 문제가 노출됐고 다른 서비스도 마찬가지입니다. 공유 비즈니스 계정에서는 괜찮지만, 개인정보를 주장하는 서비스에서는 유출입니다.

기밀성이 중요하다면 전체 시스템이 아닌 사용자 고유 데이터 내에서만(사용자별 키로 솔트된) 중복 제거하세요. 또는 E2EE가 중복 제거 없음을 의미한다는 점을 받아들이고 스토리지를 그에 맞게 계획하세요. 개인정보를 우선시하는 도구들, 예를 들어 암호화된 임시 전송을 위한 HexaTransfer는 두 사용자가 같은 파일을 갖는지 아무도(서비스 포함) 알 수 없다는 보장을 위해 중복 제거 효율성을 포기합니다.

중복 제거 효과 측정

그냥 중복 제거를 활성화하고 기대하지 마세요. 비율을 측정하세요.

dedup_ratio = logical_bytes / physical_bytes

비율 2:1은 물리적 1 바이트당 논리적 2 바이트를 저장함을 의미합니다. 보고 도구: ZFS의 zpool get dedupratio, Windows Server의 Get-DedupStatus, restic/Borg의 저장소별 통계.

워크로드별 건강한 비율:

VM 이미지: 8~20:1
데이터베이스 백업: 10~30:1
파일 서버(오피스 문서): 1.5~3:1
이메일 아카이브: 2~5:1
미디어 라이브러리: 1.0~1.1:1 (시도할 가치 없음)
암호화된 아카이브: 1.0:1 (불가능)

워크로드 비율이 1.5:1 미만이라면 중복 제거를 끄세요. CPU와 메모리 비용이 본전도 못 뽑습니다.

백업 제품 통합

대부분의 기업은 처음부터 중복 제거를 구현하지 않고 이를 수행하는 백업 제품을 사용합니다. 제품 선택 시 비교 기준:

Veeam: 인라인 블록 중복 제거, 기본 512 KB 청크, 중복 제거 후 압축
Rubrik: 콘텐츠 정의 가변 청크, 서브 블록 중복 제거
Commvault: 클라이언트 측 중복 제거, 클라이언트별 및 글로벌 풀
restic/Borg/Kopia: 오픈소스 CDC, 클라이언트 측, S3/B2/Azure 백엔드
BackupPC: 하드링크 기반 파일 단위, 단순하지만 구식

S3 Glacier에 2 TB를 백업하는 소규모 기업이라면 Glacier Instant Retrieval에 restic을 사용할 경우 5:1 중복 제거로 월 약 20,000원이 소요됩니다. 500 TB 기업 데이터 자산의 경우 중복 제거가 있는 제대로 된 백업 플랫폼이 첫 해 스토리지 절감으로 투자비용을 회수합니다.

압축을 추가할 때

중복 제거는 중복 바이트를 제거하고, 압축은 고유 바이트 내의 중복성을 제거합니다. 두 가지는 쌓입니다. 중복 제거 후 zstd 압축을 적용하면 텍스트 위주 데이터에서 1.5~2배 추가 절감됩니다. BorgBackup은 --compression zstd를 지원하고, restic은 --compression max, AWS EFS는 OneZone-IA에 투명 압축을 제공합니다.

순서가 중요합니다. 중복 제거 먼저(중복 블록 노출), 그런 다음 고유 블록을 압축합니다. 먼저 압축하면 보통 중복 제거를 방해합니다. 입력의 작은 변화가 압축 출력 전체에 전파되기 때문입니다. 모든 진지한 백업 제품은 이를 올바르게 처리합니다. 매개변수만 선택하면 됩니다.

중복 제거는 지루하고 화려하지 않지만, 혼합 워크로드에서 스토리지 비용을 당기는 가장 큰 레버입니다. 데이터 목록을 작성하고, 콘텐츠에 맞는 기법을 선택하고, 비율을 측정하고, 예산을 회수하세요.

hexatransfer.com에서 사용해보세요 — 무료, 계정 불필요, 최대 10 GB.