PostgreSQL 병렬 복원과 성능 최화 전략

개요

대용량 PostgreSQL 데이터베이스를 복원할 때 단일 스레드 복원은 시간이 많이 소요된다. 이 글은 병렬 복원 postgres pg_restore를 활용해 복원 시간을 줄이는 방법과 restore 성능 튜닝 postgres 관점의 실무적 고려사항을 설명한다. 처음 접하는 사람도 이해할 수 있도록 기본 개념부터 명령 예시, 성능 점검 항목까지 순서대로 다룬다.

병렬 복원의 기본 개념

왜 병렬 복원이 필요한가

단일 프로세스로 처리하면 테이블, 인덱스, 데이터 로드가 순차적으로 진행된다. 반대로 병렬 복원은 여러 작업을 동시 수행해 IO와 CPU를 더 효율적으로 사용한다. 특히 다수의 독립적 테이블이 존재하는 스키마에서 효과가 크다.

제약 사항

• 병렬 복원은 덤프가 custom(-Fc) 또는 directory(-Fd) 형식일 때만 지원된다.
• 의존성이 있는 객체(예: 외래키가 얽힌 테이블)는 병렬 효과가 제한된다.
• 병렬 수를 무작정 높이면 오히려 성능 저하 또는 리소스 경쟁이 발생한다.

pg_restore 병렬 옵션 사용법

가장 기본적인 옵션은 -j 또는 --jobs 이다. 사용법은 간단하다. 먼저 덤프를 custom 또는 directory 형식으로 생성한다.

덤프 생성 예시

pg_dump -Fc -f /backup/mydb.dump mydb

병렬 복원 예시

pg_restore -d targetdb -j 8 /backup/mydb.dump

위 명령은 최대 8개의 작업을 병렬로 실행한다. 상황에 따라 -j 값을 조정한다. 대개 CPU 코어 수와 IO 성능을 고려해 결정한다.

디렉토리 형식 예시

pg_dump -Fd -j 4 -f /backup/mydb_dir mydb
pg_restore -d targetdb -j 8 /backup/mydb_dir

디렉토리 형식은 여러 파일로 분할 저장한다. 대규모 환경에서 네트워크나 디스크 병목을 줄이는 데 유리하다.

성능 튜닝 포인트

단순히 -j 값을 높이는 것만으로 최적화가 완성되지는 않는다. 서버와 복원 전략을 함께 튜닝해야 한다.

서버 설정 권장 사항

• maintenance_work_mem: 인덱스 생성과 같은 작업에 큰 영향을 준다. 복원 시 일시적으로 늘리면 속도가 개선된다.
• synchronous_commit: 복원 중 일시적으로 off로 설정하면 WAL 동기 작업 비용을 줄인다. 복원 완료 후 다시 설정한다.
• checkpoint 관련 파라미터: checkpoint 빈도를 낮추면 복원 중 디스크 I/O를 줄일 수 있다.

데이터베이스 수준 전략

• 인덱스는 가능한 한 데이터 로드 후에 생성한다. 데이터 로드와 인덱스 생성의 동시 실행은 비효율적일 수 있다.
• 외래키와 제약 조건은 데이터 로드 후 적용하거나, 복원 도중 disable 형태를 고려한다.
• 통계(ANALYZE)는 최종 단계로 이동한다. 불필요한 최적화 비용을 줄일 수 있다.

실전 구성과 체크리스트

실무에서는 다음 절차를 권장한다. 단계별로 진행하면서 성능을 측정한다.

• 1) 덤프를 -Fc 또는 -Fd로 생성
• 2) 대상 서버의 일시적 설정 조정(maintenance_work_mem, synchronous_commit 등)
• 3) pg_restore -j N으로 병렬 복원
• 4) 인덱스 및 제약 조건 적용(필요 시 병렬로 실행 가능 여부 검토)
• 5) ANALYZE 및 통계 수집
• 6) 서버 설정 원복과 검증

실제 명령 예시 모음

# 서버 설정 일시 변경 (psql에서 실행)
ALTER SYSTEM SET maintenance_work_mem = '1GB';
ALTER SYSTEM SET synchronous_commit = off;
SELECT pg_reload_conf();

# 복원 실행
pg_restore -d targetdb -j 12 /backup/mydb.dump

# 복원 후 작업
ANALYZE VERBOSE;
ALTER SYSTEM RESET maintenance_work_mem;
ALTER SYSTEM RESET synchronous_commit;
SELECT pg_reload_conf();

성능 문제 진단 팁

병렬로 실행했는데도 속도가 느리면 원인을 확인한다. 대표적인 원인은 다음과 같다.

• 디스크 I/O 포화: 복원은 주로 쓰기 작업이며, 디스크가 병목이면 -j 값을 낮춘다.
• CPU 한계: 복원 작업이 인덱스 생성 등 CPU 집약적이면 코어 수를 고려한다.
• 연결 수 제한: 데이터베이스의 max_connections나 리소스 제한으로 작업이 병목될 수 있다.
• 객체 의존성: 외래키나 트리거 때문에 병렬화 이득이 제한되는 경우가 있다.

모범 사례 요약

• 덤프는 가능한 custom 또는 directory 형식으로 생성한다.
• 복원 전에 서버 설정을 임시로 조정해 인덱스 생성과 WAL 비용을 최소화한다.
• -j 값은 테스트를 통해 최적값을 찾는다. 일반적으로 코어 수와 IO 성능을 고려한다.
• 복원 후에는 반드시 ANALYZE와 설정 원복을 수행한다.
• 작업을 자동화할 때는 복원 실패 시 원인 로그를 남기도록 구성한다.

결론

병렬 복원 postgres pg_restore는 대규모 복원 시간을 크게 줄일 수 있는 강력한 도구다. 그러나 단순히 병렬 수만 높이는 것으로는 충분하지 않다. 서버 설정, 덤프 형식, 객체 의존성, 디스크 및 CPU 특성을 함께 고려해야 최적의 결과를 얻는다. 제시한 절차와 체크리스트를 따라 단계적으로 적용하면 restore 성능 튜닝 postgres 효과를 안정적으로 확보할 수 있다.