Postgres가 느린 게 아니라 스토리지가 느린 것이다

동일한 33억 행 PostgreSQL 무작위 UPDATE 부하에서 로컬 NVMe는 3,000 IOPS의 기본 gp3 EBS보다 처리량이 9.24배 높았음. 이 결과는 해당 워크로드와 스토리지 구성에 한정됨 작업 데이터가 메모리와 운영체제 페이지 캐시를 넘어서면 물리 I/O가 늘어나고, 쿼리와 백그라운드 유지보수가 같은 스토리지 자원을 두고 경쟁함 벤치마크의 지연 차이는 CPU 연산보다 페이지 읽기와 WAL 동기화 대기에서 주로 발생했으며, NVMe에서는 대기가 줄어 더 많은 CPU를 실제 작업에 활용했음 로컬 NVMe는 노드가 사라지면 데이터도 사라지므로, 프로덕션에서는 동기 복제와 노드 외부의 백업/WAL 아카이브로 가용성과 복구를 설계해야 함 수집 지연, 불안정한 읽기 응답 시간, VACUUM 적체, 체크포인트 간섭, 복제 지연이 나타나면 데이터베이스와 스토리지를 함께 진단해야 함 규모가 커질 때 나타나는 다섯 가지 증상 POSETTE 2026 발표는 수백 GB에서 TB 규모의 PostgreSQL이 높은 동시성과 처리량을 감당할 때 나타나는 다섯 가지 증상을 스토리지 성능과 연결함 수집 속도 저하: UPDATE와 UPSERT가 많은 파이프라인에서 데이터가 늘수록 수초 걸리던 작업이 수분으로 길어질 수 있음 불안정한 읽기 지연: 대부분의 쿼리는 빠르지만 일부가 급격히 느려지고, P95 지연이 밀리초에서 초 단위로 늘며 대시보드에 타임아웃이 발생함 VACUUM 적체: UPDATE와 UPSERT 처리량 증가를 autovacuum이 따라가지 못하면 테이블 팽창이 GB에서 TB 규모로 누적됨 체크포인트 지연: 체크포인트가 클라이언트 부하와 I/O 및 CPU를 두고 경쟁하면서 반복적인 지연 급증을 일으킬 수 있음 논리 복제 지연: Kafka나 ClickHouse로 데이터를 보낼 때 WAL 디코딩이 느려지고 복제 슬롯이 커지면서 문제가 심화될 수 있음 모든 증상이 같은 원인에서 발생하는 것은 아니지만, 스토리지 성능이 공통 원인일 수 있음 스토리지 병목이 여러 작업에 번지는 이유 작업 데이터 집합이 PostgreSQL 메모리와 운영체제 페이지 캐시를 넘어서면 더 많은 읽기에 물리 I/O가 필요함. 느린 스토리지에서는 읽기 비용과 대기열이 평균 지연 및 꼬리 지연을 높일 수 있음 클라이언트 쿼리와 유지보수 작업은 대역폭, IOPS, 대기열 용량을 공유함 힙과 인덱스 쓰기, WAL 동기화, 체크포인트, VACUUM, 논리 ...