PostgreSQL 테이블스페이스를 활용한 성능 최적화
발표자는 VPS 환경에서 PostgreSQL을 호스팅하며 직면한 디스크 성능 불균형 문제를 해결하기 위해 테이블스페이스를 활용했습니다.
디스크 성능 분석
-
문제점: VPS 구매 시 메모리와 RAM을 기준으로 사양을 결정하고 디스크는 별도로 연결하나, 로컬 NVMe 드라이브와 원격 네트워크 블록 장치(예: Amazon EBS) 간의 성능 차이가 매우 컸습니다.
-
성능 격차: Hzna 환경에서 원격 볼륨은 쓰기 작업이 약 5배, 읽기 작업이 약 3배 느린 것으로 확인되었습니다.
테이블스페이스 활용 전략
-
개념: PostgreSQL 설치 시 기본 테이블스페이스가 제공되며, 추가 테이블스페이스 생성이 가능합니다. 과거에는 느린 디스크와 빠른 디스크에 테이블스페이스를 분리하여 인덱스를 빠른 디스크에 배치하는 것이 일반적이었습니다.
- 구현:
- 로컬 NVMe 드라이브에
CREATE TABLESPACE명령을 사용하여 새로운 테이블스페이스를 생성했습니다. ALTER INDEX명령을 사용하여 중요한 인덱스(예: 기본 키, ISBN 인덱스)를 새로 생성한 빠른 테이블스페이스로 이동시켰습니다.- 외래 키 제약 조건이 있는 인덱스의 경우
REINDEX명령을 통해 재구축해야 했습니다. - 테이블 이동은
ALTER TABLE ... SET TABLESPACE명령을 사용합니다.
- 로컬 NVMe 드라이브에
- 작업 주의사항: 이러한 작업은 배타적 잠금(exclusive locks)을 유발하므로, 서비스 중단을 최소화하기 위해 논리적 복제본(logical replica)과 같은 보조 데이터베이스에서 먼저 테스트하거나 심야 시간을 활용하는 것이 권장됩니다. 발표자는 소규모 테이블은 운영 중에도 몇 초 안에 이동했으며, 12GB 규모의
products테이블 인덱스는 2분 소요되어 야간에 처리했습니다.
성능 측정 및 결과
-
측정 도구:
pgbench를 사용하여 성능을 측정했습니다. - 결과:
- 인덱스를 이동하기 전: 약 3,100 TPS (초당 트랜잭션)
- 인덱스를 로컬 NVMe로 이동 후: 약 5,870 TPS
- 효과: 단 2분간의 서비스 중단으로 거의 2배에 달하는 성능 향상을 달성했습니다.
추가 최적화 고려사항
-
WAL(Write-Ahead Log) 이동: WAL을 빠른 디스크로 이동시키면 모든 쓰기 작업이 먼저 WAL에 기록되므로 추가적인 성능 향상을 기대할 수 있습니다. 발표자는 PostgreSQL 18로 마이그레이션하면서 기본적으로 모든 것을 빠른 디스크에 배치하고 큰 데이터만 원격 볼륨으로 이동시켰습니다.
-
쿼리 플래너 튜닝:
seq_page_cost,random_page_cost,effective_io_concurrency와 같은 PostgreSQL 구성 항목을 테이블스페이스별로 다르게 설정하여 쿼리 옵티마이저가 디스크 특성을 반영하도록 유도할 수 있습니다. NVMe 드라이브의 경우random_page_cost를 낮게 설정하는 것이 유리합니다.