테라바이트급 Postgres 백업, 병렬화로 하드웨어 한계 속도까지 끌어올리는 법

데이터베이스가 작을 때는 백업이 별 고민거리가 아니에요. pg_dump 한 줄이면 끝나니까요. 그런데 데이터가 수백 GB, 수 TB로 커지면 이야기가 완전히 달라져요. 백업 한 번에 몇 시간, 심하면 하루 종일 걸리고, 정작 더 무서운 건 장애가 났을 때 그 백업을 '복원'하는 데 걸리는 시간이거든요. 최근 PlanetScale이 이 문제를 정면으로 다룬 글을 공개했어요. Postgres 백업을 대규모로 병렬화해서, 하드웨어가 낼 수 있는 최대 속도로 백업을 만드는 접근에 대한 이야기예요. PlanetScale은 원래 유튜브의 MySQL 샤딩 기술인 Vitess를 기반으로 성장한 회사인데, 2025년부터 Postgres 지원을 시작하면서 특유의 하드코어한 엔지니어링 글을 계속 내놓고 있죠.

기존 백업 방식은 왜 느릴까

먼저 기존 Postgres 백업이 왜 느린지부터 볼게요. 대표적인 논리 백업 도구인 pg_dump는 데이터를 SQL 형태로 뽑아내는데, 기본적으로 하나의 프로세스가 테이블을 순서대로 읽어요. -j 옵션으로 병렬 처리를 켤 수 있긴 하지만, 병렬화의 단위가 '테이블'이라는 게 함정이에요. 전체 데이터의 80%가 몰려 있는 초대형 테이블이 하나 있다면, 다른 워커들이 일을 다 끝내고 놀고 있어도 그 큰 테이블을 읽는 워커 하나가 끝날 때까지 전체 백업이 끝나지 않거든요. 물리 백업 도구인 pg_basebackup은 데이터 파일을 통째로 복사하는 방식이라 좀 낫지만, 이것도 기본적으로는 스트림 하나로 순차 복사하는 구조라, 요즘 NVMe 디스크가 낼 수 있는 속도를 한참 남겨두고 병목에 걸려요.

핵심 아이디어: 병렬화 단위를 '조각'으로 내리기

PlanetScale 접근의 핵심은 병렬화의 단위를 테이블이 아니라 '테이블 조각'으로 내리는 거예요. 동작 방식을 풀어보면 이래요. 백업의 생명은 '일관성'인데요. 이게 뭐냐면, 백업 안의 모든 데이터가 정확히 같은 시점의 상태여야 한다는 뜻이에요. 주문 테이블은 오후 3시 상태인데 결제 테이블은 3시 10분 상태라면 그 백업은 쓸 수 없는 데이터가 되죠. 다행히 Postgres는 MVCC라는 동시성 제어 방식 덕분에 특정 시점의 데이터를 '스냅샷'으로 고정해서 볼 수 있고, pg_export_snapshot 같은 기능으로 이 스냅샷을 여러 세션이 공유할 수 있어요. 그러면 수십 개의 커넥션이 전부 같은 시점의 데이터를 보게 되는 거죠.

이 기반 위에서 각 테이블을 기본 키 범위로 잘게 쪼개요. 예를 들어 1억 행짜리 테이블이라면 ID 구간별로 수천 개의 조각으로 나누는 거예요. 그다음 수십, 수백 개의 워커가 각자 조각을 하나씩 맡아 병렬로 읽고, 압축해서 S3 같은 오브젝트 스토리지에 동시에 업로드해요. 이렇게 하면 병목의 위치가 완전히 바뀌어요. 단일 프로세스의 처리 속도가 아니라 디스크 읽기 속도와 네트워크 대역폭 전체가 한계가 되는 거죠. PlanetScale은 데이터베이스를 네트워크 스토리지가 아닌 로컬 NVMe에서 돌리는 'Metal' 아키텍처를 밀고 있는데, 초당 수 GB를 읽어내는 NVMe와 이 병렬 백업이 만나면 기존 방식과는 차원이 다른 속도가 나와요. 조각 단위로 만들어진 백업은 복원할 때도 똑같이 병렬로 밀어 넣을 수 있어서, 장애 복구 시간(RTO)까지 같이 줄어들고요. 사실 이 방식은 PlanetScale이 Vitess로 MySQL을 다루던 시절부터 갈고닦아 온 '일관된 스냅샷 + 청크 단위 복사' 패턴을 Postgres에 가져온 것에 가까워요.

비슷한 도구들과 비교하면

MySQL 진영에는 예전부터 mydumper라는 병렬 논리 백업 도구가 있었고, Postgres 쪽에서는 pgBackRest가 물리 백업의 병렬 처리와 증분 백업을 지원해요. AWS Aurora 같은 스토리지 분리형 DB는 아예 스토리지 계층에서 스냅샷을 떠버리는 방식으로 이 문제를 우회하고요. 각자 트레이드오프가 있는데, 이런 청크 기반 병렬화는 속도를 챙기면서도 특정 테이블만 골라 복원하거나 다른 버전으로 옮기는 유연함을 가질 수 있다는 게 강점이에요.

우리 팀은 뭘 챙겨야 할까

Postgres를 운영하는 팀이라면 챙겨갈 게 분명해요. 첫째, 백업이 '되고 있다'와 '쓸 수 있다'는 완전히 다른 문제예요. 지금 데이터 크기로 복원에 몇 시간이 걸리는지 실제로 재보고, 복원 훈련을 마지막으로 해본 게 언제인지 돌아보세요. 둘째, 규모가 아직 크지 않아도 pg_dump에 -Fd(디렉터리 포맷)와 -j 옵션을 조합하는 것만으로 백업 시간을 꽤 줄일 수 있어요. 셋째, 데이터가 TB급으로 가고 있다면 스냅샷 공유와 청크 분할이라는 이 패턴은 백업뿐 아니라 무중단 마이그레이션이나 대량 데이터 이동에도 그대로 써먹을 수 있는 기본기예요.

한 줄로 정리하면, "백업의 병렬화 단위를 테이블에서 키 범위 조각으로 내리면 하드웨어의 한계 속도까지 백업할 수 있다"는 이야기예요. 여러분 팀의 백업 전략은 어떤가요? 실제로 복원까지 해보는 훈련, 하고 계신가요?