데이터 중복 제거는 백업 데이터 집합 등에서 중복되는 데이터 블록을 찾아 제거하는 프로세스다. 파일 내의 데이터를 검사해서 이전의 백업 작업 이후 변경된 블록만 분류하는 방식으로 작동한다.
데이터 중복 제거 프로세스는 데이터에서 중복성을 제거하는 것을 기반으로 한다. 대폭 간소화해서 예를 들면, 이 포스팅 내용의 초안을 잡았다고 해보자. 첫 날 오전 우선 100KB 크기의 첫 초안을 만들어서 로컬 드라이브에 저장한다. 그 날 오후에 백업 소프트웨어는 새 파일을 확인하고 네트워크를 통해 중복 제거 스토리지 솔루션으로 이 파일을 백업한다. 파일은 100KB를 차지한다.
다음 날, 로컬 드라이브에 있는 파일을 열어서 몇 문장을 추가한 다음 저장한다. 이제 문서 파일의 크기는 101KB가 된다. 그 날 오후에 백업 소프트웨어가 파일이 변경되었음을 확인하고 다시 백업. 이번에는 101KB를 차지한다.
새 데이터가 중복 제거 스토리지 솔루션에 도착하면 솔루션은 첫 날 저장한 것(100KB)과 비슷한 데이터를 찾아서 그 날의 100KB 파일과 대조한다. 원래 있던 데이터에 대한 포인터로 대체한 다음, 첫 날과 두째 날사이 변경된 1KB를 저장한다. 데이터 중복 제거는 기존 100KB 데이터에 대한 포인터와 함께 1KB의 새로운 데이터만 찾아서 저장하게 된다.
데이터 중복 제거의 중요성
클라우드와 온프레미스를 불문하고 스토리지 블록을 저장하는 데는 비용이 든다. 그렇기 때문에 중복 데이터를 제거하는 것은 비용 효율 차원에서 중요하다.
한편, 중복 제거를 하지 않는 경우, 혹은 잘못된 중복 제거 기술을 선택하는 경우 어떤 상황이 발생할까. 크기가 100TB인 데이터 집합을 관리하면서 12주 동안 매주 백업을 보존한다고 가정해 보자. 백업이 기한을 초과하기 시작하는 시점이 되면 100TB 데이터 집합은 1.2PB(Petabites, 12주x100TB)의 스토리지를 점유하게 된다.
데이터 100TB를 보호하기 위해 1.2PB에 대한 비용을 지불해야 하는 이유를 재무팀에 설명하는 것은 누구에게나 껄끄러운 일이다. 그리고 시간이 지날수록 상황은 악화된다. 중복 데이터로 인해 낭비되는 리소스는 스토리지 블록의 경우만은 아니다. 네트워크, 디바이스, 시간 모두 아래와 같은 이유로 낭비된다.
네트워크 – 중복 데이터 블록을 기기에서 백업 서버와 스토리지로 불필요하게 전송하면 네트워크 경로가 여러 지점에서 포화 상태가 된다. 또한 이를 감수할 정도의 데이터 보호 강화 효과도 없다.
기기 – 파일을 호스팅하는 기기든 단순히 데이터를 전달하는 기기든 백업 경로상의 모든 기기는 중복 데이터를 위해 프로세서 사이클과 메모리를 낭비하게 된다.
시간 – 기업은 애플리케이션과 데이터를 24시간 사용할 수 있어야 하므로 백업으로 인한 성능 저하는 달갑지 않은 현상이다. 이런 이유로 IT 관리자는 백업이 시스템 성능에 미치는 영향을 최소화하도록 일반적으로 백업 윈도우(작업을 수행하는 시간)를 야간에 계획한다. 중복 데이터는 이 윈도우의 귀중한 시간을 낭비한다.
중복 데이터에 점유된 모든 스토리지 블록은 비용 낭비로 이어지므로 스토리지 관리자는 동일한 데이터를 2번 이상 저장하지 않기 위해 데이터 중복 제거를 활용한다. 시간이 지나면서 데이터 중복 제거와 압축을 함께 사용하면 스토리지 요구사항을 90% 이상 낮출 수 있다.
중복 제거와 압축의 차이
중복 제거와 압축의 목표는 사실 동일하다. 저장되는 백업 데이터의 양을 줄이는 것이다.
중복 제거는 알고리즘을 사용해 이미 저장된 데이터와 일치하는 데이터를 확인한다. 이 알고리즘은 중복 데이터를 찾은 뒤 이미 저장된 데이터를 가리키는 포인터로 해당 데이터를 대체한다. 그리고 나서 저장해야 하는 고유한 데이터만 전송하는 것이다.
데이터 중복 제거는 일반적으로 비율로 표시하는데, 예를 들어 10:1의 축소율은 스토리지 용량 요구사항이 90% 낮아진다는 의미이다.
데이터 압축 알고리즘은 중복 제거와 달리 이미 저장된 데이터를 감안하지 않는다. 지정된 파일 또는 파일 집합을 흡수해서 반복 시퀀스를 토큰으로 대체하고, 데이터에 있는 불필요한 파일 및 공간을 제거하는 방법으로 압축한다.
중복 제거와 압축 기술은 서로 다르게 동작하고 사용례도 다르지만 상호보완적이다. 데이터 중복 제거 소프트웨어는 압축 유틸리티를 내장한 경우가 많다.
데이터 중복 제거의 스토리지 내 작동
데이터 중복 제거의 또 다른 중요한 측면은 구현 지점이다. 애플리케이션 또는 데이터가 호스팅되는 소스에서 중복 제거를 하는 것이 더 나은지, 아니면 백업 복사본이 저장되는 타겟에서 하는 것이 더 나은지에 대한 의견이 다양하다.
앞서 설명했듯이 중복 데이터는 스토리지뿐만 아니라 네트워크 트래픽, 백업 윈도우의 시간 및 네트워크에 있는 다른 기기에도 영향을 미친다. 목표는 중복 제거 워크로드를 전체적인 영향이 가장 낮은 곳에 두는 것이다. 그 위치는 대부분 소스 영역이다(소스 측 중복 제거).
알고리즘이 소스 서버의 백업 스트림에서 실행되면 고유 데이터만 네트워크를 통해 전송하면 된다. 소스 애플리케이션 서버에 약간의 오버헤드가 발생하지만, 네트워크 경로가 포화되는 것보다 전체적인 영향이 훨씬 더 적다.
소스 측 중복 제거는 시간 측면에서도 유리하다. 네트워크를 통해 움직이는 데이터가 더 적은 만큼 더 많은 백업 작업을 병렬로 실행할 수 있다. 결과적으로 동일한 백업 윈도우에서 더 많은 데이터를 백업하거나, 윈도우를 줄이고 더 빨리 정상 시스템 성능으로 돌아갈 수 있다.
데이터 중복 제거는 파일 스토리지 외에 데이터를 맞춤형 메타데이터와 고유 식별자가 있는 파일로 관리하는 객체 스토리지에서도 중요하다. 클라우드의 객체 스토리지는 아마존 S3(Simple Storage Service), 마이크로소프트 애저 블롭(Microsoft Azure Blob) 스토리지, 구글 클라우드 스토리지와 같은 상용 클라우드 서비스에서 보편적인 모델로 자리잡았다.
이런 서비스는 사용량에 따라 비용을 청구하므로 가능한 모든 방법으로 스토리지 사용량을 줄여야 한다. 데이터 중복 제거와 압축은 저장되는 백업 데이터의 양을 줄여준다. 데이터 중복 제거를 클라우드 티어링과 조합해 사용하면 클라우드 비용을 크게 절감할 수 있다.
데이터 중복 제거의 안전성
데이터 중복 제거 알고리즘은 어느 데이터가 더 중요한지를 판단하는 것이 아니라, 오직 중복 데이터만을 확인한다. 또한 스토리지를 절약하기 위해 데이터를 삭제하지도 않는다. 데이터 중복 제거는 복원 프로세스를 통해 백업 데이터를 완전히, 안정적으로 재구성할 수 있다.
데이터 중복 제거는 백업 같은 스트림에서 중복 데이터를 제거하는 프로세스다. 스토리지 요구사항이 높아지고 비용을 절감해야 할 필요가 있으면 중복 제거가 해결책이 될 수 있다. 중복 제거는 기업에 필요한 스토리지 공간의 크기와 비용을 줄이는 것 외에, 네트워크 혼잡을 완화하고 백업을 통합하며, 귀중한 백업 윈도우를 더 효과적으로 사용할 수 있도록 도와준다.
(* 본 기고문은 GTT KOREA의 편집 방향과 다를 수 있습니다.)