PostgreSQL 장애 대응: RTO/RPO 사례 모음

개요

이 글은 PostgreSQL 장애 대응을 위한 실무적 플레이북이다. 목표는 RTO와 RPO 기준을 명확히 하고, 실제 사례 중심의 복구 절차를 제공하는 것이다. 처음 접하는 사람도 흐름을 따라 할 수 있도록 단계별로 정리했다. 또한 운영 환경에서 흔히 발생하는 실패 유형별 대처를 포함한다.

RTO와 RPO의 이해

RTO(복구 시간 목표)

RTO는 서비스가 정상 동작으로 복구될 때까지 허용 가능한 시간이다. 예를 들어 RTO가 30분이면 장애 발생 후 30분 내에 서비스가 복구되어야 한다. RTO 산정은 비즈니스 영향도와 SLA에 기반한다.

RPO(복구 시점 목표)

RPO는 허용 가능한 데이터 손실 기간이다. 예를 들어 RPO가 5분이면 장애 시 최대 5분 전의 데이터까지 복구 허용 범위이다. RPO는 백업 빈도와 WAL 보존 정책으로 결정된다.

준비 단계

장애 대응은 사전 준비로 성공률이 달라진다. 아래 항목을 체크해 두면 복구 시간이 단축된다.

• 정기 백업 정책(전체, 증분, WAL 아카이브) 구성
• 심플한 복구 절차 문서화 및 담당자 지정
• 스탠바이(Streaming Replication)와 페일오버 테스트 주기적 수행
• 모니터링과 알람(RDS, Prometheus, pg_stat) 통합
• 백업 저장소의 접근성 및 권한 검증

장애 유형별 대응 흐름

1) 단일 노드 하드웨어 장애

일반적으로 스탠바이를 빠르게 승격시켜 RTO 목표를 맞춘다. 절차는 간단하다. 먼저 장애 노드 격리. 그런 다음 스탠바이 상태 확인과 WAL 동기화 상태를 점검한다. 문제가 없으면 스탠바이 승격(promotion)을 수행한다. 승격 후 클라이언트 라우팅을 전환한다.

2) 데이터 손상(디스크 손상, 파일 손상)

데이터 손상은 복구 시간이 길어진다. 이 경우 최신 전체 백업과 WAL을 사용해 포인트 인 타임 리커버리(PITR)를 수행한다. RPO가 촘촘하면 데이터 손실을 최소화할 수 있다. 복구 환경에서 먼저 복구 테스트를 수행해 무결성을 확인한다.

3) 논리적 오류(삭제된 테이블 등)

논리적 오류는 WAL 단위 복구로 해결 가능하다. 오류 발생 시점 이전의 WAL 위치를 식별하고, PITR로 복구한 뒤 필요한 데이터만 덤프하여 다시 적용한다. 이 과정은 사전 테스트가 중요하다.

실제 사례: RTO 30분, RPO 5분 사례

사례 개요는 다음과 같다. 주요 서비스는 OLTP이며 RTO 30분, RPO 5분을 요구한다. 환경은 마스터 1대, 스탠바이 2대, WAL 아카이브를 외부 스토리지에 보관한다. 모니터링은 지연 알람과 자동 스탠바이 승격 스크립트를 사용한다.

사례 절차

• 장애 인지: 모니터링 알람으로 장애 감지
• 장애 노드 격리: VIP 또는 라우터에서 트래픽 차단
• 스탠바이 상태 확인: pg_stat_replication, pg_is_in_recovery 확인
• 승격 실행: 스탠바이에서 promotion 실행
• 클라이언트 전환: HA 프록시 또는 DNS로 신규 마스터로 라우팅
• 후속 검증: 쓰기 및 읽기 트랜잭션 확인, 데이터 무결성 점검

명령 예시

아래는 자주 쓰는 복구 관련 명령 예시이다. 환경에 따라 경로나 옵션을 조정한다.

sudo systemctl stop postgresql
sudo systemctl start postgresql
# 스탠바이 승격
sudo -u postgres pg_ctl promote -D /var/lib/postgresql/data
# WAL 아카이브에서 복구 시작
pg_basebackup -h primary_host -D /var/lib/postgresql/data -U repuser -Fp -Xs -P
# pg_wal 복사 예시
cp /mnt/wal_archive/0000000100000000000000 /var/lib/postgresql/data/pg_wal/

체크리스트와 검증

복구 후에는 반드시 다음 항목을 검증한다.

• 애플리케이션 정상 응답 확인
• 트랜잭션 손실 여부 확인
• 레플리케이션 정상화 확인
• 장애 원인 분석을 위한 로그 수집
• 복구 과정 문서화 및 개선 계획 작성

사후 관리

복구가 끝난 뒤에는 사후 조치가 중요하다. 원인 분석으로 재발 방지 대책을 마련한다. 백업 정책과 RTO/RPO 목표를 재검토한다. 또한 복구 절차를 주기적으로 시뮬레이션하여 실제 성능을 확인한다. 이 과정을 통해 운영 역량을 지속적으로 개선할 수 있다.

맺음말

이 플레이북은 postgres 장애 대응 계획 수립과 실무 적용 사례를 중심으로 구성되었다. RTO와 RPO를 명확히 정의하고, 준비와 반복 테스트를 통해 목표를 달성하는 것이 핵심이다. 현장에서는 환경 특성에 맞춰 절차를 조정하고, 정기적인 검증을 생활화해야 한다.