Uber MyRocks 차등 백업으로 LSM 스토리지 비용 줄이기

SST 파일의 불변성이 백업 구조를 바꾼 사례

페타바이트 규모의 분산 데이터베이스에서는 저장 공간 자체보다 백업본이 비용 문제를 더 크게 만들 수 있다. Uber는 MySQL InnoDB 기반 스토리지 서비스를 MyRocks로 이전한 뒤, SST 파일이 생성 후 변경되지 않는 성질을 이용해 차등 백업 시스템을 설계했다. 그 결과 백업 저장 비용을 최대 70% 절감했다.

핵심은 단순히 압축률을 높이는 데 있지 않았다. 동일한 SST 파일을 여러 백업이 함께 참조하도록 만들어, 매번 전체 백업을 저장할 때 생기는 중복을 없앤 것이다.

MySQL 위에서 동작하는 RocksDB 스토리지 엔진

MyRocks는 Meta(구 Facebook)가 개발한 오픈소스 프로젝트로, RocksDB를 MySQL 스토리지 엔진으로 통합한다. RocksDB는 Google의 LevelDB에서 파생된 LSM 트리 기반 키-값 저장소이며, 쓰기가 많은 워크로드와 압축 효율에 초점을 둔다.

InnoDB는 B-Tree 구조를 사용한다. 읽기 성능에는 강점이 있지만, 제자리 갱신 방식의 쓰기에서 랜덤 I/O가 발생하고 단편화로 공간이 낭비될 수 있다. 반대로 LSM 트리는 쓰기를 순차 I/O로 처리해 쓰기 성능과 압축률을 함께 끌어올린다.

Meta는 Facebook 소셜 그래프 서비스에 MyRocks를 배포한 결과, 같은 데이터에서 InnoDB 대비 저장 공간을 50% 절감했다고 VLDB 2020 논문에서 제시했다.

쓰기와 컴팩션으로 이어지는 LSM 트리

MyRocks의 동작과 차등 백업의 설계 근거는 LSM 트리 구조에 있다.

⤢✕

데이터는 먼저 MemTable에 기록되며, 동시에 WAL(Write Ahead Log)에 순차 기록된다. MemTable이 일정 크기에 이르면 Immutable MemTable로 바뀌고, 백그라운드 스레드가 이를 SSTable 파일(SST)로 플러시한다.

SST 파일은 한 번 만들어진 뒤 수정되지 않는다. 데이터 변경은 기존 파일을 고치는 대신 새 SST 파일을 생성하는 방식으로 반영된다. 파일 내부에는 정렬된 키-값 쌍, 이진 탐색용 인덱스 블록, 블룸 필터가 들어간다.

SST 파일은 레벨별로 관리된다. L0에는 메모리에서 직접 플러시된 파일이 놓이고, L1부터는 컴팩션을 거쳐 정렬된 런이 유지된다. 컴팩션은 L-N의 일부 SST 파일과 L-(N+1)의 겹치는 파일을 병합하면서 삭제 마커와 오래된 값을 제거하고 공간을 회수한다. RocksDB는 Leveled Compaction, Tiered Compaction, FIFO Compaction을 지원하며, MyRocks는 기본적으로 Leveled Compaction을 사용한다.

InnoDB에서 MyRocks로 옮긴 뒤 드러난 백업 문제

Uber의 분산 스토리지 팀은 2019년부터 MySQL InnoDB 기반 Schemaless와 Docstore 인스턴스를 MyRocks로 이전하기 시작했다.

⤢✕

초기 벤치마크에서는 InnoDB 대비 디스크 공간이 30% 이상 줄었다. 정렬된 데이터 블록에 zstd, snappy 등의 압축 알고리즘을 적용할 수 있는 LSM 트리 구조가 높은 압축률에 기여했다.

하지만 백업 비용은 별개의 문제였다. 이전에는 MySQL XtraBackup으로 증분 백업을 수행할 수 있었다. XtraBackup은 InnoDB의 LSN(Log Sequence Number)을 추적해 바뀐 페이지만 백업한다.

MyRocks 엔진은 XtraBackup의 증분·부분 백업 대상이 아니었다. 각 데이터베이스 파티션은 매번 전체 백업을 해야 했고, 개별 백업에는 이전 백업과 중복된 데이터가 최대 95% 포함됐다. 페타바이트 규모에서 이 중복은 Blob 스토리지 비용 증가로 직결됐다.

공유 SST 풀과 매니페스트로 백업을 구성하는 방식

Uber 팀은 SST 파일이 컴팩션으로 삭제되기 전까지 바뀌지 않는다는 점을 백업 설계의 기반으로 삼았다. 같은 파일은 여러 백업이 참조해도 되므로, 이미 업로드된 SST 파일을 다시 저장할 필요가 없다.

⤢✕

최초 전체 백업에서는 메타데이터와 SST 파일 전체를 Blob 스토리지의 공유 풀에 저장한다. 그다음 백업에서는 현재 데이터베이스의 SST 목록과 풀의 목록을 비교한다. 풀에 없는 신규 SST 파일만 업로드하고, 해당 시점에 필요한 SST 파일 목록을 매니페스트 파일에 기록한다.

복원은 매니페스트에 적힌 파일을 공유 풀에서 수집해 데이터베이스를 재구성하는 방식으로 이뤄진다. 백업별 복원이 가능하며 스냅샷 일관성도 보장된다.

컴팩션은 이 구조에서 가장 신경 써야 할 변수다. 컴팩션이 발생하면 기존 SST 파일이 병합되고 새 파일이 생성되며 원본 파일은 삭제된다. 따라서 컴팩션이 활발한 핫 파티션에서는 대부분의 SST 파일이 교체되어 차등 백업의 중복 제거 효과가 낮아진다. Uber 팀은 이 한계를 고려해 핫 파티션에서는 차등 백업의 적용 빈도나 전략을 조정했다.

읽기·압축·컴팩션에서 조정할 지점

블룸 필터는 특정 키가 SST 파일에 없음을 빠르게 판단하는 확률적 자료구조다. 불필요한 디스크 I/O를 막아 읽기 증폭(Read Amplification)을 줄인다. MyRocks는 optimize_filter_for_hits 옵션으로 가장 큰 레벨인 마지막 레벨에서 블룸 필터를 생략해 메모리 효율을 높인다. 최신 RocksDB는 블룸 필터보다 공간 효율이 높은 Ribbon Filter도 지원한다.

⤢✕

압축은 레벨마다 다르게 적용할 수 있다. L0~L1에는 압축을 생략하거나 빠른 Snappy를 적용하고, L2 이상 콜드 데이터에는 압축률이 높은 Zstd나 LZ4를 적용한다. compression_size_percent 파라미터로 압축 적용 비율을 조절하며, 이런 계층형 전략은 Uber의 30% 이상 디스크 절감에 기여한 요인 중 하나다.

쓰기 증폭(Write Amplification)은 논리적 쓰기 하나가 유발하는 물리적 쓰기 횟수의 비율이다. Leveled Compaction은 공간 증폭이 적은 대신 쓰기 증폭이 크고, Tiered Compaction은 반대 특성을 가진다. RocksDB의 Tiered+Leveled 혼합 전략은 작은 레벨에는 Tiered를, 큰 레벨에는 Leveled를 적용한다. kMinOverlappingRatio 옵션으로 컴팩션 우선순위를 조정하면 쓰기 증폭을 낮추면서 처리량을 높일 수 있다.

Jellyfish가 분리한 핫 데이터와 콜드 데이터

Uber는 MyRocks 전환과 별도로 Schemaless 스토리지 비용을 줄이기 위해 Jellyfish 데이터 계층화 시스템을 만들었다. 데이터는 생성 직후에는 자주 접근되지만, 시간이 지나면 접근 빈도가 급감하는 패턴을 보인다.

Jellyfish는 이를 기준으로 데이터를 두 테이블에 나눈다. 신규 데이터는 고성능 실시간 테이블에 기록되고, 설정된 임계 시간이 지난 데이터는 배치 압축을 거쳐 저비용 배치 테이블로 이동한다. 배치 테이블은 추가 압축으로 비용을 낮추면서도 요청 시 빠른 접근을 제공한다.

⤢✕

비용 최적화가 가능했던 조건

지표	개선 내용
백업 저장 비용	최대 70% 절감
백업 데이터 중복률	개별 백업 기준 최대 95% → 신규 SST 파일만 저장
마이그레이션 초기 디스크 절감	InnoDB 대비 30% 이상
Facebook 사례 비교	InnoDB 대비 50% 저장 공간 절감

이 사례의 핵심은 SST 불변성과 컴팩션 메커니즘을 백업 아키텍처에 직접 반영했다는 점이다. 범용 도구가 해결하지 못하는 제약을 스토리지 엔진의 특성에 맞춘 설계로 보완했다.

대규모 분산 시스템에서는 엔진 내부 동작을 알아야 백업과 저장 비용의 최적화 여지를 찾을 수 있다. MyRocks 차등 백업은 그 연결을 보여주는 사례다.