WarehousePG 재해복구 사례: RPO·RTO 약 180배 개선과 도입 계획

논리 백업에 의존하던 한 은행 고객에게는 시간이 지나면서 더 이상 외면할 수 없는 심각한 문제가 쌓였습니다. 전체 백업을 완료하는 데 거의 2일이 걸렸습니다. 이 데이터웨어하우스에는 수백 TB의 핵심 업무 데이터뿐 아니라 업무 지식과 수십 년간 축적된 비즈니스 로직이 담겨 있었고, 24시간 연중무휴로 온라인 상태를 유지해야 했습니다. 백업은 매일 거의 온종일 실행됐으며, 재해복구(DR) 클러스터로 복원하는 데도 비슷한 시간이 걸렸습니다.

DR 정책은 복구 시점 목표(RPO)와 복구 시간 목표(RTO)를 각각 2시간으로 요구했습니다. 업무가 요구하는 수준과 도구가 제공할 수 있는 수준 사이에 24배의 격차가 있었던 셈입니다. 절차나 규율을 더 강화하거나 유지보수 시간을 늘리는 것만으로는 좁힐 수 없는 격차였습니다. 도구의 전환이 필요했습니다.

쉽게 말하면 이렇습니다. 클러스터가 중단됐다면 최대 2일치 데이터를 잃고, 복구에 다시 2일을 써야 했을 것입니다. 매일의 의사결정을 지원하는 24시간 연중무휴 분석 파이프라인의 중심에서 고객·트랜잭션·운영 데이터를 보관하는 플랫폼에 이는 단순한 불편이 아닙니다. 문제가 터질 때까지 조용히 남아 있는, 대비하지 못한 위험입니다.

현재 이 클러스터는 상위 애플리케이션 아키텍처를 바꾸지 않고도 최근 15분 이내 시점으로 복구합니다. RPO와 RTO가 모두 약 180배 개선됐습니다. 이 글은 EDB Postgres AI로 이를 어떻게 달성했고, 무엇보다 실제로 어떤 준비가 필요했는지를 설명합니다.

WarehousePG 재해복구 계획이 필요한 운영 환경

모든 배포 환경에 지금부터 설명할 구성이 필요한 것은 아닙니다. 다음 중 하나 이상에 해당하는 팀을 위한 글입니다.

• 규제 산업에서 운영하며 RTO와 RPO가 단순한 희망 사항이 아닌 경우입니다. 제삼자가 감사하는 절차가 있고, 목표 미달을 가볍게 넘길 수 없습니다.
• ELT 파이프라인이 지속적으로 실행되는 경우입니다. 긴 백업 때문에 데이터가 밀리더라도 단순히 ‘재실행’ 버튼을 눌러 따라잡을 수 없습니다.
• 높은 동시성이나 HTAP 워크로드를 운영하는 경우입니다. 백업이 잠금과 I/O 자원을 두고 경쟁하면 실제 사용자의 쿼리 성능 저하로 즉시 드러납니다.
• 운영 환경이 어느새 ‘백업하기에는 너무 커진’ 경우입니다. 제가 고객에게 표현했듯 ‘성공의 희생양’이 된 것입니다. 10 TB에서 작동하던 백업 도구가 데이터가 80배로 늘어난 환경에서는 더 이상 작동하지 않습니다.
• 인프라 부족을 비롯한 여러 이유로 현재 백업을 전혀 하지 않는 경우입니다. 계획이 없다는 사실 자체가 위험이 되었습니다.
• 하나 이상의 고가 솔루션에서 실행 중인 워크로드를 DR 계획이 필요한 합리적인 정액제 솔루션으로 통합해 IT 예산을 줄여야 하는 경우입니다.

소규모 배포 환경이거나 몇 시간의 데이터 손실을 사고로 보지 않는 개발·테스트 시스템이라면 위 상황에 해당하지 않을 수 있습니다. 그래도 유용한 배경지식이 되겠지만, 이 글에서 다루는 긴박함이 아직 자신의 문제로 느껴지지는 않을 것입니다. 그 밖의 팀이라면 계속 읽어 보시기 바랍니다.

논리 백업의 잠금과 MPP 클러스터 일관성 문제

규모의 증가는 허락을 구하지 않습니다. 테이블 수, 데이터량, 동시성이 증가할 때 백업 도구도 함께 확장되거나, 도구 자체가 병목이 됩니다.

논리 백업은 먼저 일관된 상태를 확보해야 합니다. 스키마와 데이터가 동일한 한 시점을 반영하도록 모든 테이블에 ACCESS SHARE 잠금을 획득합니다. 이 잠금은 DROP TABLE이나 TRUNCATE를 차단하고 일관된 스냅샷을 보장합니다.

테이블이 수십만 개이고 데이터가 수백 TB에 이르면 이 잠금에도 비용이 따릅니다. 잠금 요청이 대기열에 쌓이고 카탈로그가 비대해집니다. 극단적인 경우 잠금 테이블이 고갈되면서 다음 메시지가 발생합니다.

ERROR: out of shared memory

HINT: You might need to increase max_locks_per_transaction.

실제로는 위와 같은 상황이 벌어졌습니다. 기다릴 필요가 없어야 했던 잠금 뒤로 실제 쿼리가 줄지어 대기했습니다. 이것이 고객의 현실이었습니다. 전체 백업을 애플리케이션 스키마나 스키마 그룹별로 작은 백업 세트로 나누어도 효과는 미미했습니다. 백업은 여전히 하루 거의 모든 시간대에 실행됐습니다.

비용은 추상적인 문제가 아닙니다. SLA 미달, SLO의 타당성에 대한 의문, ELT 파이프라인 지연, 백업 작업이 실행될 때마다 서서히 나빠지는 사용자 경험으로 나타납니다.

볼륨 스냅샷으로 바꾸는 것만으로는 해결되지 않습니다. 대규모 병렬 처리(MPP) 클러스터에서 ‘일관성’은 노드 하나의 상태를 뜻하지 않습니다. 코디네이터와 모든 세그먼트가 동시에 같은 시점에 합의해야 한다는 뜻입니다. 단일 노드 Postgres 백업보다 어려운 문제이며, 인프라 솔루션이 가장 먼저 한계를 드러내는 부분입니다.

계속 읽어 보세요. 위 그래프는 whpg-dr로 전환한 당일부터 논리 백업을 중단할 때까지의 상황을 보여 줍니다.

WarehousePG DR 계획: 용량·WAL·복원 지점 측정

계획 수립에 필요한 네 가지 기초 정보

어떻게 이 결과에 도달했을까요? 계획하고, 현황을 파악하고, 다시 계획했습니다. DR 계획을 세우려면 결국 다음 네 가지 데이터가 필요합니다.

• 네트워크 연결 스토리지(NAS)의 용량과 기능 또는 클라우드 스토리지 예산 제약
• 계획한 전체 백업 시간대의 로그 파일을 제외한 클러스터 프라이머리 세그먼트 크기
• 모든 세그먼트가 하루에 생성하는 선행 기록 로그(WAL) 파일로 측정한 데이터베이스 활동량
• 마지막으로 평균 WAL 압축률

NAS 스토리지 용량은 물론 성공에 매우 중요합니다. 하지만 중복 제거와 압축 기능은 보존할 수 있는 양과 기간을 크게 늘릴 수 있습니다. 중복 제거는 전송 데이터량을 줄여 백업 과정 자체에도 도움이 되는 경우가 많습니다. 이런 기능을 갖춘 솔루션은 다양하며, 기능의 중요성은 아무리 강조해도 지나치지 않습니다. 적절한 솔루션을 사용하면 200 TB의 과거 데이터를 전체 백업하는 데 10시간이 걸리던 작업이 2 TB, 30분으로 줄어들 수 있습니다. 중복 제거의 비용 효율성은 높이 평가할 만합니다.

이 글에서 다루는 배포 환경은 클라우드였으므로, 실제로는 오브젝트 스토리지와 비용 최적화, 예산의 문제였습니다. 원문에서 검토한 Amazon S3 Standard — Infrequent Access와 Google Cloud Storage Coldline은 모두 이 용도에 적합한 가격 수준이었습니다.

WarehousePG의 미러 세그먼트는 백업하지 않고 프라이머리 세그먼트만 백업합니다. 데이터베이스 크기는 \l+ 명령을 psql에서 실행한 뒤 클러스터 내 모든 논리 데이터베이스의 used 열을 합산해 간단히 추정할 수 있습니다. 다른 방법으로는 gpssh -f segment_hosts "df -h /data1 /data2" 명령의 데이터 볼륨을 자신의 클러스터에 맞게 바꿔 실행하고 used 열을 합산한 뒤 2로 나눕니다. 전체 백업에는 log/ 디렉터리가 포함되지 않으므로 이 방법은 대략적인 추정치입니다.

WarehousePG는 다른 PostgreSQL 파생 제품과 마찬가지로 모든 데이터베이스 변경을 WAL 파일에 기록합니다. WAL은 DR에 필수적이므로 모두 아카이빙합니다. WAL 파일이 하나라도 빠지면 아카이브가 유효하지 않게 됩니다. 매시간 pg_catalog.gp_stat_replication을 기록하는 작업을 예약하세요. 이 정보를 통해 클러스터가 시간당 얼마나 많은 일을 처리하는지 더 잘 이해할 수 있습니다.

cron으로 예약할 스크립트:

#!/bin/sh

. /usr/edb/whpg7/greenplum_path.sh

psql -qAt -d mydatabase -U gpadmin -c "INSERT INTO myschema.wal_tracking SELECT now(),* FROM pg_catalog.gp_stat_replication;"

현재 WAL 위치와 기타 정보를 스냅샷으로 기록하는 추적 테이블:

CREATE TABLE myschema.wal_tracking (

 period           timestamptz DEFAULT now(),

 segment_id       integer,

 pid              integer,

 usesysid         oid,

 usename          name,

 application_name text,

 client_addr      inet,

 client_hostname  text,

 client_port      integer,

 backend_start    timestamp with time zone,

 backend_xmin     xid,

 state            text,

 sent_lsn         pg_lsn,

 write_lsn        pg_lsn,

 flush_lsn        pg_lsn,

 replay_lsn       pg_lsn,

 write_lag        interval,

 flush_lag        interval,

 replay_lag       interval,

 sync_priority    integer,

 sync_state       text,

 reply_time       timestamp with time zone,

 spill_txns       bigint,

 spill_count      bigint,

 spill_bytes      bigint,

 sync_error       text

) DISTRIBUTED RANDOMLY;

WAL 파일을 기준으로 활동량을 측정하는 시간별 요약:

SELECT period, sum(wal_files_per_hour)

  FROM (

SELECT segment_id, period

     , pg_catalog.pg_wal_lsn_diff(

        sent_lsn,

        LAG(sent_lsn) OVER (PARTITION BY segment_id ORDER BY period)

       ) AS wal_files_per_hour

  FROM myschema.wal_tracking

 ORDER BY segment_id, period

) x

 GROUP BY period

 ORDER BY period;

이제 이 정보를 바탕으로 백업과 아카이브 보존 요구사항이 현실적인지 판단할 수 있습니다. 다음 질문에 답해 보세요.

• 데이터센터에 스토리지가 더 필요한가요?
• 클라우드 스토리지를 사용한다면 예산을 조정해야 하나요?
• 전체 백업을 더 자주 수행해야 하나요, 아니면 빈도를 낮출 여유가 있나요?

복원 지점과 추가 활용

백업 측면에서 마지막으로 짚을 항목은 복원 지점(restore point)입니다. 복원 지점은 데이터베이스가 일관된 상태에 있다고 합의한 특정 시점입니다. 실제 구현과 운영에서는 CHECKPOINT를 수행하고 모든 프라이머리 세그먼트의 로그 시퀀스 번호(LSN)를 모아 파일에 기록한 뒤 아카이브에 보관합니다.

저희는 매시간 복원 지점을 만들었습니다. 플랫폼과 애플리케이션은 모든 수신 데이터 피드와 분석 작업을 완전히 재실행할 수 있었습니다. 복원 지점은 처리 과정과 스토리지 측면에서 비용이 낮습니다. 한 줄짜리 cron 작업을 매시간 또는 5분마다 예약하는 것만으로 필요한 만큼 생성할 수 있습니다.

복원 지점은 단순 DR을 넘어 WarehousePG 재해복구 유틸리티의 여러 활용 가능성을 드러냅니다.

• 월말이나 분기말 결산 직후로 클러스터를 복원해 대규모 기말 보고서 작업을 별도 환경으로 분산합니다.
• QA와 성능 테스트를 위한 프로덕션 사본을 만듭니다.
• 클라우드나 온프레미스 등 한 환경에서 다른 환경으로 클러스터를 이전합니다.

복구 클러스터에서 WAL 재생 시간 측정하기

복구 테스트 없이는 DR 계획이 완성되지 않습니다. 하이브리드 클라우드 환경은 사실상 무한에 가까운 클라우드의 오브젝트 스토리지와 컴퓨팅에 비해 자원 제약이 큽니다. 반면 하이브리드 환경에 연결된 스토리지는 디스크 처리량과 장기 비용에서 언제나 클라우드보다 유리합니다. 다만 이 두 요소는 실제 복구에서 큰 역할을 하지 않는다는 점이 아쉽습니다.

측정할 가치가 있는 것은 WAL 재생 시간입니다. 아카이브에서 WAL 파일을 가져와 압축을 풀고 재생하는 데 필요한 시간입니다.

세그먼트 로그가 길잡이가 됩니다. 아카이브 가져오기 항목에 초점을 맞춰 현재 항목과 이전 항목 사이의 시간을 재는 스크립트를 작성하면 평균 재생 시간을 구할 수 있습니다. 여러 차례 수행한 경험을 미리 말씀드리면 평균은 0.75~1.1초 사이에 들어옵니다. 차이를 만드는 요인은 아카이브 위치와 DR 클러스터 사이의 네트워크 지연, 그리고 WAL 파일의 내용입니다. 전자는 제어할 수 있지만 후자는 제어할 수 없습니다. WAL의 내용은 반드시 재생해야 합니다.

왜 WAL 재생 시간을 측정할까요? 짧게 답하면 RTO 때문이지만, 예로 보면 더 분명합니다. DR 클러스터가 1시간 이상 뒤처지면 안 된다면 WAL을 재생할 수 있는 시간도 한정됩니다. 평균 WAL 재생 시간은 RTO를 충족하는 최소 재생 빈도를 정하고, 누군가 카티전 JOIN을 사용하는 CTAS를 실행해 WAL이 폭증했을 때 얼마나 여유가 있는지 판단하는 기준이 됩니다. 실제로 일어날 수 있는 일이라는 점을 잘 아실 것입니다.

고객 사례 결과: 백업 시간·잠금·복구 성능 개선

핵심 결과 요약

다음은 이 한 배포 환경에서 얻은 실제 수치입니다. 이후 몇 차례 더 수행했지만 방법론은 크게 달라지지 않았고, 스크립트는 훨씬 좋아졌습니다. Claude 덕분입니다!

• 595 TB 데이터베이스가 약 160 TB로 감소
• 주당 1.29 PB의 WAL 생성
• 쿼리 잠금 시간 99% 감소(반올림한 값)
• 전체 백업 시간 44시간에서 11시간으로 단축
• 비용 최적화를 위해 소형 컴퓨팅 인스턴스로 DR 클러스터 운영
• 시간별 복원 지점 재생에 평균 16분 소요
• 중복 제거를 사용하지 않은 클라우드 배포 환경이라는 점을 다시 강조

WAL 생성량과 보존 용량

측정 결과는 저희도 놀라게 했습니다. 그래프는 한 달 동안의 시간당 최대 WAL 생성량을 보여 줍니다. 임의의 24시간 동안 예상되는 최대 WAL 수는 8M개에 조금 못 미치며, 비압축 크기로 484 TB입니다. 평균 압축률은 3:1이었고, 압축 후 161 TB로 줄었습니다. 보존 정책 목표가 7일이었다는 점을 고려하면 여전히 상당한 규모입니다. 평균 시간당 WAL 생성량은 5M개였고, 시간대에 따라 약 ±10% 차이가 났습니다.

실제로는 다음 전체 백업이 완료될 시간을 확보하기 위해 8일치를 보관했습니다. 그 결과 전체 백업과 재생 가능한 WAL이 항상 함께 유지됐습니다. 클라우드 스토리지에는 8일이 지난 객체를 제거하는 수명 주기 보존 정책도 적용했습니다. WAL 규모는 1.29 PB에 이릅니다. 훨씬 효율적인 방식입니다.

전체 백업: 44시간에서 11시간 9분 4초로

“Greg, 백업 자체에 걸리는 시간은 어떤가요?”라고 물으실 수 있습니다. 잊지 않았고, 걱정하지도 않습니다. 물리 파일 시스템 백업은 논리 백업보다 수행할 작업이 훨씬 적습니다. 피해야 할 부담을 다음과 같이 피할 수 있습니다.

• 추가 작업에 최적화된 열 지향(Append-Optimized Column-Oriented, AOCO) 테이블을 행 형태로 구체화할 필요가 없습니다.
• 데이터베이스 외부에서 작업하므로 잠금이 필요하지 않습니다.
• 각 테이블 덤프가 SELECT가 아닌 파일 복사이므로 쿼리 오버헤드가 없습니다.
• 인덱스 자체가 드문 것은 아니지만 일반적으로 이 작업에서는 사용하지 않으므로 관련 부하가 작습니다.

논리 백업 유틸리티로 거의 44시간 걸리던 작업이 11시간 9분 4초로 줄었습니다. 백업 중 자원 사용량은 당연히 늘었지만, 이전 백업 때의 증가 수준에는 한참 못 미쳤습니다.

• 스토리지 사용률 증가는 약 22%로 추정됐고, 논리 백업에서 관측한 수준보다 낮아 스토리지에 무리가 없었습니다.
• CPU 사용률은 압축 작업 때문에 5% 증가하는 데 그쳤습니다.
• 메모리 사용량 증가는 너무 작아 별도로 기록하지 않았습니다.
• 네트워크 전송량은 증가했지만 프로덕션 쿼리를 방해하지 않았습니다.

위 그래프는 눈길을 끄는 데서 그치지 않고 기존 방식에 대한 안일함을 깨워야 합니다. 당일 15시대에 논리 백업을 중단하고 whpg-dr가 이를 대체한 상황을 보여 줍니다. 잠금으로 차단된 쿼리의 평균 대기 시간(초)은 98.86260811% 감소했습니다.

복구 클러스터: WAL 재생으로 RTO 검증하기

복구를 테스트하지 않고는 DR 계획을 완성할 수 없습니다. 장애 호출을 받았을 때 실제로 중요한 지표는 WAL 재생 시간입니다.

측정에는 간단한 스크립트가 필요합니다. 세그먼트 로그에서 아카이브 가져오기 항목을 분리하고 연속된 가져오기 사이의 시간을 잽니다. 온프레미스, AWS, GCP에서 여러 차례 수행한 결과 평균은 0.75~1.1초 사이였습니다. 중간값을 잡아 WAL 파일 하나당 0.9초로 보겠습니다. 아카이브 가져오기부터 압축 해제와 재생까지의 전체 시간입니다.

이 수치는 환경이 달라도 놀라울 만큼 일정합니다. 그 일관성은 유용한 사실을 알려 줍니다. 재생의 한계는 순수 컴퓨팅 성능보다 가져오기와 압축 해제의 오버헤드에 있습니다. 그래서 DR 클러스터는 프로덕션급 하드웨어를 그대로 복제하는 대신 비용을 최적화한 더 작은 인스턴스에서도 무리 없이 작동합니다. 프로덕션의 일을 대신하는 것이 아니라 빠르게 따라잡는 것이 목적이기 때문입니다.

실제 수치로 계산해도 같은 결론이 나옵니다. 프라이머리 세그먼트 192개가 하루 약 5M개의 WAL 파일을 생성한다면, 평균적인 1시간 동안 세그먼트 하나당 약 1,085개의 WAL 파일이 생성됩니다. 파일당 0.9초면 1시간치 변경을 재생하는 데 약 16분이 걸립니다. 2시간 요구사항과 비교하면 업무에서 요구한 수준보다 7배 넘는 여유를 확보한 셈입니다.

매시간 복원 지점을 만드는 이유가 바로 여기에 있습니다. 복구가 밤새 진행하는 프로젝트가 아니라 잠시 커피를 마시는 정도의 시간이 됩니다.

결론: 도구 전환에 앞서 필요한 DR 계획과 검증

진정한 공로는 WarehousePG와 Barman 도구를 만든 엔지니어링 팀에 있습니다. 핵심 기능과 경계 사례를 반복해 테스트하는 데 쏟은 관심과 시간이 페타바이트 규모 분산 클러스터 전체의 백업과 지속적인 WAL 아카이빙을 조율하는 제품으로 이어졌다는 점은 인상적입니다. 이 모든 기능을 단순하고 정교한 유틸리티로 묶었고, 비교적 짧은 기간에 완성했습니다. 업계의 다른 유사 시점 복구(PITR) 기능 사례보다 눈에 띄게 빠른 출시였습니다.

하지만 이 도구가 계획까지 대신해 주지는 않습니다. WAL 양 측정, 적절한 스토리지 규모 산정, 스토리지 기능 검증, 압축 알고리즘 선택, 감당할 수 있는 복원 지점 수 결정 등은 모두 전환 전에 수행해야 할 현황 파악과 체계적인 준비입니다. 어떤 유틸리티도 대신해 주지 않습니다.

이 글이 도움이 되었기를 바랍니다. EDB Postgres AI for WarehousePG로 전환할 때 whpg-dr를 통해 이 사례에서 달성한 결과를 기억해 주세요.

• 2일에서 16분으로
• 44시간에서 11시간으로
• 잠금 경합 99% 감소
• 애플리케이션 변경 없이 달성

기술은 이미 존재했습니다. PITR은 수년간 Postgres의 일부였습니다. 달라진 것은 전환하기 전에 제대로 계획하는 체계적인 준비였습니다.

이제 DR 계획을 갖추지 않을 이유는 없습니다.

전체 설치 및 구성 방법은 EDB 공개 문서에서 확인할 수 있습니다.

자주 묻는 질문

이 사례에서 WarehousePG 재해복구 성능은 얼마나 개선됐나요?

원문은 해당 은행 고객 환경에서 복구가 2일에서 평균 16분으로, 전체 백업이 거의 44시간에서 11시간 9분 4초로 줄었다고 설명합니다. 잠금으로 차단된 쿼리의 평균 대기 시간은 98.86260811% 감소했습니다. 이 수치는 단일 배포 환경의 결과입니다.

WarehousePG DR 계획을 세울 때 어떤 정보를 측정해야 하나요?

NAS의 용량·기능 또는 클라우드 스토리지 예산, 로그를 제외한 프라이머리 세그먼트 크기, 전체 세그먼트의 일일 WAL 생성량, 평균 WAL 압축률이 필요합니다. 복구 테스트에서는 WAL 가져오기·압축 해제·재생 시간을 측정해 RTO에 맞는 재생 빈도와 여유를 판단합니다.

복원 지점은 재해복구 외에 어떻게 활용할 수 있나요?

월말·분기말 결산 직후로 클러스터를 복원해 보고서 부하를 분산하거나, QA·성능 테스트용 프로덕션 사본을 만들 수 있습니다. 클라우드와 온프레미스를 포함한 환경 간 클러스터 이전에도 활용할 수 있습니다.

DR 유틸리티를 도입하면 사전 계획을 생략해도 되나요?

아니요. WAL 양 측정, 스토리지 규모와 기능 검증, 압축 알고리즘 선택, 복원 지점 수 결정은 전환 전에 수행해야 합니다. 원문은 어떤 유틸리티도 이런 현황 파악과 계획을 대신하지 않는다고 강조합니다.