Postgres가 느린 게 아니다, 스토리지가 느린 것이다
Postgres isn't slow, your storage is
POSETTE 2026에서 Sai Srirampur가 발표한 내용으로, 33억 행 규모의 PostgreSQL 워크로드를 baseline gp3 EBS와 로컬 NVMe에서 비교한 벤치마크를 다룬다. NVMe는 중앙값 16,030 TPS로 EBS의 1,734 TPS보다 9.24배 높았고, 트랜잭션 지연은 36.9ms에서 4.0ms로 줄었다. EBS의 추가 지연 대부분은 CPU가 아닌 스토리지 대기에서 발생했다. 발표는 로컬 NVMe의 수명 문제를 해결하기 위해 쿼럼 기반 동기 복제와 WAL-G 백업을 결합한 프로덕션 아키텍처를 제안한다.
Postgres가 확장을 멈춘 것처럼 보일 때는 데이터베이스와 스토리지를 함께 살펴보라. 느린 수집, 예측 불가능한 읽기 지연, vacuum 압박, 방해되는 checkpoint, 복제 지연은 스토리지 계층이 한계에 도달했다는 신호일 수 있다.
HN 토론
178- mmnfrdmcx
클라우드는 미친 듯이 비싸고 비효율적이다. 너무 많은 엔지니어들이 네트워크 스토리지에서의 I/O 왕복이 얼마나 느린지, 혹은 VM이 베어메탈에 비해 얼마나 시끄러운 이웃과 비교되는지 이해하지 못한다...
- bob1029
SQLite + NVMe는 때때로 반칙처럼 느껴진다. 내 최우선 요구사항이 가능한 한 낮은 지연시간이라면, 다른 걸 선택할 상상조차 할 수 없다.
Kestrel (AspNetCore) + SQLite + NVMe를 모두 같은 머신에 두는 것이 내 경험상 정말 흥미진진해지는 지점이다. 데이터베이스 상태를 변경하는 전체 폼 제출을 수십에서 수백 마이크로초 안에 처리한다고 상상해보라. 어떤 HTTP 요청을 처리하는 데 필요한 총 벽시계 시간은 1밀리초 미만일 수 있다. 요청당 평균 CPU 시간이 30uS라면, 16-32 코어 머신에서 초당 50만 건에 근접할 수 있다.
- CharlieDigital
"옛날에는" 데이터베이스 서버에서 성능을 한 방울까지 짜내기 위해 기반 스토리지 배열을 신중하게 계획해야 했다.
큰 메모리 풀과 SSD를 당연하게 여기는 개발자 세대가 있는 것 같다. 데이터베이스가 기반 스토리지를 매핑한다는 사실에 정신적 단절이 있다.
그들과 논의할 때 이 점을 꺼내면 금방 명확해지고, 거의 전구가 켜지는 게 보인다(파티셔닝과 샤딩을 논의할 때 그랬다). 하지만 그들은 쿼리가 스토리지에 있는 어떤 아티팩트에 매핑된다는 연결을 결코 하지 않는다.
- iancarroll
최근에 우리 RDS 인스턴스를 r8g.에서 r8gd.로 옮겼는데, 로컬 NVMe가 추가되어 평균 I/O 지연시간이 1.0ms에서 0.1ms로 줄었다고 생각한다. 큰 쿼리에서는 이게 쌓인다!
- smartbit
CloudNativePG는 Kubernetes Local Storage를 주요 기능 중 하나로 지원한다 [0]
영구 볼륨 관리, 포함:
PVC 템플릿을 사용한 Local Persistent Volumes 지원.
Pod에서 Persistent Volumes 스토리지 재사용.
WAL 파일과 테이블스페이스를 위한 별도 볼륨.
Chapter Temporary PostgreSQL Cluster Degradation [1]은 이를 설정하는 방법을 설명하며 이렇게 시작한다
> 표준 접근 방식은 서비스 신뢰성을 보장하고 Kubernetes의 자가 치유 기능을 활용하지만, 일시적으로 성능이 저하된 클러스터로 운영하는 것이 허용될 수 있는 시나리오가 있다. 이는 특히 PostgreSQL 데이터베이스를 실행하는 Kubernetes 워커 노드에 로컬인 스토리지에 의존하는 PostgreSQL 클러스터와 관련이 있다. 노드 로컬 스토리지, 간단히 로컬 스토리지는 성능을 향상시키기 위해 사용된다.
[0] https://cloudnative-pg.io/docs/devel/#main-features
[1] https://cloudnative-pg.io/docs/devel/kubernetes_upgrade/#tem...
- dangoodmanUT
이것이 네트워크 스토리지의 근본적인 문제다: 그 위의 모든 앱은 작은 I/O가 빠르고 로컬이라고 가정하므로 네트워크 지연시간이 상각되지 않는다.
애플리케이션 수준 복제를 사용하면 몇 단계로 상각할 수 있다(예: 커밋 시 2PC 수행).
물론 다른 노드에서 읽어야 하는 경우 등 미묘한 차이가 있지만, 이것이 복제를 스택에서 가능한 한 위로 옮기는 것이 일반적으로 DB에서 더 나은 성능을 내는 이유다 -- DB는 디스크보다 네트워크를 언제 건드려야 하는지 더 잘 안다.
- nasretdinov
솔직히 네트워크 연결 스토리지는 HDD에서만 의미가 있었다. 단지 "운영상의 유연성"을 위해 IOPS와 지연시간 모두에서 10배의 페널티를 지불해야 한다는 것은 터무니없다. 로컬 NVMe와 복제를 고수하면 훨씬 더 단순하고 훨씬 더 견고한 아키텍처를 얻는다 -- (역시 복제되는) 네트워크 블록 스토리지 솔루션에서 하나를 포기할 수 있는 것도 아니지만...
- kebsup
PostgreSQL을 부끄러울 정도로 오랫동안 사용한 후에야 "index scans"와 "index only scans"의 차이를 배웠다.
인덱스에 관련 컬럼을 포함하면 성능이 크게 향상될 수 있다. 왜냐하면 PostgreSQL이 원본 테이블에서 무작위로 정렬된 튜플을 읽을 필요가 없기 때문이다.