32TB도 42분, PlanetScale이 백업을 복원하며 다음 백업을 만드는 이유

32TB도 42분, PlanetScale이 백업을 복원하며 다음 백업을 만드는 이유

IT & AI 뉴스 썸네일

대형 Postgres 데이터베이스는 백업 파일을 만드는 시간부터 부담이에요. PlanetScale은 이전 백업을 임시 노드에 직접 복원하고 WAL을 재생한 뒤, 그 상태를 새로운 백업으로 저장해요. 샤드마다 이 과정을 동시에 돌려 프로덕션 부하와 전체 소요 시간을 함께 줄였어요. 2

핵심 요약

구분	핵심	왜 볼 만한가요
백업 방식	이전 백업을 임시 노드에 복원하고 WAL로 현재 상태까지 따라잡아요	주기마다 기존 백업의 복구 가능성을 실제 복원 과정에서 확인해요
프로덕션 부하	오래된 WAL은 S3에서 읽고 최근 몇 분만 primary에서 받아요	서비스 쿼리와 무거운 백업 작업이 같은 자원을 두고 경쟁하는 시간을 줄여요
병렬 처리	샤드마다 별도 백업 노드를 띄워 동시에 처리해요	32TB 예시에서 8 샤드는 2.8시간, 32 샤드는 42분까지 줄어들어요
운영 활용	같은 복원 경로를 노드 교체와 데이터베이스 크기 변경에도 써요	재해 상황에서만 쓰던 복구 절차를 평소에도 반복해 낯선 경로로 남겨 두지 않아요

1. 백업을 실제로 복원하면서 다음 백업을 만들어요

PlanetScale의 방식은 12시간 전에 만든 정상 백업에서 시작해요. 샤드별 임시 EC2 인스턴스가 S3의 백업을 스트리밍으로 복원해요. 이후 지난 12시간의 WAL을 재생해 현재 시점까지 따라잡고, 모든 샤드를 같은 시각에 멈춘 뒤 새 백업을 암호화해 저장해요. 작업이 끝나면 임시 인스턴스는 종료해요. 1

primary에서는 최근 변경분만 가져와요

12시간 치 WAL 전체를 primary에서 읽으면 디스크와 네트워크 부하가 커질 수 있어요. PlanetScale은 `wal-g`로 WAL을 계속 객체 스토리지에 보관해요. 임시 노드는 대부분의 WAL을 S3에서 재생하고, 아직 아카이브되지 않은 최근 몇 분만 primary에서 직접 받아요. 서비스 트래픽을 처리하는 노드가 백업 때문에 오래 바빠지는 상황을 줄이는 설계예요. 2

Postgres는 WAL 세그먼트가 완성된 뒤 아카이브해요. 쓰기가 적은 샤드에서는 세그먼트가 늦게 채워질 수 있어서 `archive_timeout`을 5분으로 두고 전환을 유도해요. 그래도 S3에 아직 도착하지 않은 마지막 구간은 생길 수 있어요. 그래서 객체 스토리지와 primary 스트리밍을 함께 써요.

728x90

샤드별 백업 노드가 시간을 줄여요

원문은 32TB 데이터베이스가 압축 후 20TB가 되고, 노드와 네트워크가 초당 500MB를 처리한다고 가정해요. 샤딩하지 않으면 S3에서 복원하고 다시 업로드하는 전체 과정에 약 22시간이 걸려요. 같은 데이터를 8개 샤드로 나누면 약 2.8시간, 32개 샤드로 나누면 약 42분까지 줄어들어요. 각 샤드의 데이터 전송이 동시에 진행되기 때문이에요. 2

이 수치는 정해진 성능 보장이 아니라 원문이 제시한 계산 예시예요. 실제 시간은 압축률, 객체 스토리지 대역폭, WAL 발생량, 인스턴스 성능에 따라 달라져요. 그래도 데이터 용량이 커질수록 더 큰 단일 노드에 의존하기보다 작업 단위를 나눠 병렬화하는 방향은 분명해요.

매번 복원하니 복구 경로가 평소에도 쓰여요

백업 파일이 존재해도 실제로 열리지 않으면 장애 때 쓸 수 없어요. 이 구조는 다음 백업을 만들 때 이전 백업을 먼저 복원해요. WAL 재생까지 마쳐야 새 백업을 저장할 수 있으니, 오래된 백업과 복구 절차의 이상을 정기적으로 발견할 기회가 생겨요.

PlanetScale은 같은 경로를 Metal 데이터베이스의 크기 변경과 장애 노드 교체에도 사용해요. 새 노드에 최근 백업을 복원하고 WAL을 따라잡게 한 뒤 기존 primary의 standby로 붙여요. 동기화가 끝나면 전환하거나 읽기 복제본으로 투입해요. 백업 복원이 비상시에만 처음 실행되는 작업으로 남지 않는 셈이에요. 2

왜 중요한가요

대규모 데이터베이스의 백업 설계에서는 저장 공간만큼 복원 시간과 프로덕션 영향도 함께 봐야 해요. PlanetScale 사례는 객체 스토리지, 일회성 컴퓨팅 노드, WAL 아카이브를 조합해 무거운 작업을 서비스 노드 밖으로 옮겨요. 샤딩은 쿼리 처리뿐 아니라 백업 작업을 나누는 단위로도 작동해요. 2

운영팀이 참고할 지점은 세 가지예요. 백업 주기 안에 작업이 끝나는지, 모든 샤드가 같은 시점의 데이터를 담는지, 최근 백업으로 노드를 실제 복구할 수 있는지를 확인해야 해요. 여기에 객체 스토리지 전송 비용과 임시 인스턴스 비용도 더해져요. PlanetScale은 추가 비용을 쓰는 대신 프로덕션 쿼리와 백업의 자원 경쟁을 줄이는 쪽을 택했어요.

이 구조를 그대로 복제할 필요는 없어요. 데이터 규모가 작다면 단순한 관리형 백업이 더 경제적일 수 있어요. 다만 백업 성공 로그만 확인하고 복원 절차를 거의 실행하지 않는 환경이라면, 실제 복원을 일상적인 운영 경로에 넣는 방법을 검토할 만해요.

참고 자료

1. PlanetScale은 이전 백업을 복원해서 다음 백업을 만든다 — GeekNews
2. Massively parallel Postgres backups — PlanetScale