PostgreSQL 성능 문제의 범인은 저장소다

핵심 요약

• POSETTE 2026에서 발표된 '당신의 저장소가 느리다' 주제의 강연이 PostgreSQL 성능과 저장소의 관계를 분석했다.
• 대규모 PostgreSQL 운영 환경에서 나타나는 다섯 가지 증상이 있다: 느린 수집 파이프라인, 예측 불가능한 P95 읽기 지연, VACUUM 지연, 느린 체크포인트, 논리적 복제 지연.
• 이 증상들의 공통 원인은 저장소 성능이다. 캐시 미스, WAL 플러시, VACUUM, 논리적 디코딩 등이 저장소의 대역폭과 IOPS를 경쟁하기 때문이다.
• 벤치마크는 3.3억 행의 같은 워크로드를 EBS와 로컬 NVMe에서 실행했다. m6id.4xlarge 인스턴스(16 vCPU, 64GB RAM, 16GB shared_buffers)에서 64개 클라이언트로 UPDATE 작업을 5분간 수행했다.
• 결과: NVMe는 초당 16,030 트랜잭션(중앙값), EBS는 1,734 트랜잭션으로 9.24배 차이가 났다. 트랜잭션 지연은 36.9ms에서 4.0ms로 단축됐다.
• VACUUM은 NVMe에서 366초, EBS에서 964초가 걸렸고, 논리적 복제 지연 제거는 각각 139초, 238초였다.
• 지연의 원인 분석: EBS의 37ms 지연 중 페이지 읽기가 19ms, WAL fsync가 11ms, 락/스케줄링 오버헤드가 5ms였고 순수 CPU 작업은 2ms였다.
• pg_stat_activity 스냅샷에서 EBS는 64개 백엔드 중 29개(45%)가 IO 대기 중이었고 NVMe는 9개(14%)였다.
• CPU 프로파일링에서 역설적으로 NVMe 호스트가 240초 동안 2,253 CPU초(약 9.4개 코어)를 사용했고 EBS는 251 CPU초(1개 코어)였는데, EBS 프로세스들이 저장소 대기로 오프-CPU 상태에 있었기 때문이다.
• 인스턴스 스토어 NVMe는 머신 수명에 묶여 있어 노드 손실 시 데이터가 사라진다는 문제가 있다.
• 프로덕션 운영 패턴: 두 개의 스탠바이로 쿼럼 기반 동기 복제를 하고, WAL-G 같은 도구로 EBS 외부에 물리 백업과 WAL 아카이빙을 유지하며, 인스턴스 타입별 NVMe 용량을 기반으로 수용량을 계획한다.
• Instacart와 Datadog 등이 지연 민감 워크로드에서 NVMe 기반 PostgreSQL을 사용하고 있으며, 동기 복제로 가용성을 보장하고 별도 저장소의 백업·WAL 아카이브로 복구를 지원한다.
• 결론: PostgreSQL이 확장 정체를 보이면 데이터베이스와 저장소를 함께 진단해야 한다. 로컬 NVMe는 저장소 바운드 워크로드의 I/O 비용을 크게 줄일 수 있지만 다른 운영 모델이 필요하다.