PostgreSQL에서 오래 실행되는 idle 쿼리가 흔히 문제를 일으킴
우리 회사 코드베이스에는 “connect → transaction 시작 → 작업 → 성공 시 commit” 패턴이 많았음
이 방식은 실제 DB를 쓰지 않아도 연결 슬롯을 계속 점유하게 되어, 결국 Postgres의 연결 수를 수천 단위로 늘려야 했음
그래서 Rust 코드에서 컴파일 타임 검사를 추가해, async 함수 내에서 연결을 들고 있는 상태로 .await를 호출하면 컴파일러가 바로 경고하도록 함
100곳 넘게 수정했지만, 덕분에 이제는 10,000개 연결 대신 32개 풀로 부하 테스트를 돌려도 느려지지 않음
단순히 idle timeout을 줄이는 것도 방법이지만, 정적 검사가 훨씬 확실한 해결책이었음
“작업 먼저 수행 → 성공 시 연결 풀에서 가져와 트랜잭션 시작 → 커밋 후 반환” 순서로 바꾸면 더 낫지 않겠냐는 제안임
그 정적 검사는 lint 규칙인지, 타입 시스템을 이용한 구현인지 궁금하다는 질문임
글이 너무 피상적이고 “우린 샤딩했어요!” 같은 키워드만 반복함
세부 내용은 거의 없고, SEO용 문장처럼 느껴졌음
인프라 파트너 광고처럼 보이기도 함
캐싱, 커넥션 풀링, 조인 최적화 등도 너무 일반적인 설명뿐이었음
글의 요지는 “단일 writer는 확장되지 않으니, 쓰기를 줄이고 읽기를 분리했다” 정도로 요약됨
새로운 내용은 거의 없고, 쿼리 최적화·샤딩·리드 리플리카 같은 흔한 접근만 언급했음
내가 Postgres를 좋아하는 이유는, 단순히 CPU와 디스크를 늘리는 것만으로도 꽤 큰 규모까지 버틸 수 있기 때문임
그 시점이 되면 샤딩 전문가를 고용할 여유도 생김
사실 PostgreSQL은 이미 FDW와 파티셔닝으로 기본적인 샤딩을 지원함
그래서 “샤딩하려면 Postgres를 떠나야 한다”는 말은 좀 이상하게 들림
하지만 “전문가를 고용할 여유가 생긴다”는 말에는 의문이 있음
예를 들어 OpenAI는 지금도 막대한 적자를 내고 있고, 2027년까지 버틸 수 있을지도 불확실하다는 뉴스가 있음
스키마 변경과 타임아웃에 대해, 단순히 타임아웃 설정만이 아니라
스키마 롤아웃 중에 충돌하는 트랜잭션을 자동으로 종료하는 스크립트를 병행 실행하면 훨씬 효율적임
Postgres가 이런 기능을 기본 제공하면 좋겠음 — 무거운 락이 걸려 대기하는 것보다, 일부 트랜잭션을 취소하는 편이 낫기 때문임
하지만 Postgres는 이미 트랜잭션 기반 스키마 변경을 지원하는데, 굳이 작업을 죽일 필요가 있냐는 반론도 있음
OpenAI Engineering 블로그의 첫 글이라 흥미로웠음
앞으로 더 많은 사례를 보고 싶음
실제로는 잦은 다운타임과 새벽 2시 긴급 수정으로 버텼을 것 같다는 농담 섞인 반응도 있었음
복제 설정이 궁금했음
50개의 리드 리플리카를 두고도 복제 지연이 거의 없었다고 하는데,
실제로는 CPU나 메모리 스파이크로 일부 리플리카가 지연될 가능성이 높음
그럴 경우 WAL 전송 대기로 인해 프라이머리도 느려질 수 있음
하지만 TCP ACK 대기 때문에 프라이머리가 느려지진 않고, 단지 WAL 세그먼트 보관량이 늘어날 뿐이라는 의견도 있었음
“새 기능이 추가 테이블을 필요로 하면 PostgreSQL이 아닌 Azure CosmosDB에 넣는다”는 부분이 있었음
즉, 기존 시스템은 유지하고 새로운 기능만 다른 DB로 옮기는 식으로 보였음
다만 CosmosDB는 가격이 매우 비쌈, OpenAI처럼 자금이 넉넉한 회사가 아니면 쓰기 어려움
“인스턴스 크기를 늘렸다”고 했는데, 그 수준이 궁금했음
어떤 CPU·RAM을 쓰는지, 일반 사용자와 같은 인스턴스인지, 아니면 맞춤형 하드웨어인지 알고 싶었음
주요 클라우드들은 두 소켓 서버 전체를 VM 하나로 할당하는 SKU를 제공함
예: Azure Standard_E192ibds_v6 (96코어, 1.8TB RAM, 10TB SSD, 3M IOPS)
더 큰 건 SAP HANA용으로 896코어, 32TB 메모리, 185Gbps 네트워크를 제공하는 Standard_M896ixds_24_v3 같은 모델임
이런 건 월 약 17만5천 달러 수준이지만, OpenAI는 아마 대폭 할인을 받았을 것임
개인적으로는 HPC용 HX176rs VM을 DB 서버로 쓰는 걸 선호함
HBM 캐시 덕분에 메모리 처리량이 훨씬 높고, 비슷한 가격대의 일반 VM보다 성능이 훨씬 좋았음
Azure PostgreSQL과 CosmosDB를 함께 쓰는 건 비용이 엄청날 것임
그래도 이번 글은 “PostgreSQL을 확장한 실제 사례” 중 가장 현실적인 편이었음
커널 수정이나 소스코드 해킹 없이, 표준 클라우드 환경에서 운영하는 접근이라 공감이 갔음
Hacker News 의견들
PostgreSQL에서 오래 실행되는 idle 쿼리가 흔히 문제를 일으킴
우리 회사 코드베이스에는 “connect → transaction 시작 → 작업 → 성공 시 commit” 패턴이 많았음
이 방식은 실제 DB를 쓰지 않아도 연결 슬롯을 계속 점유하게 되어, 결국 Postgres의 연결 수를 수천 단위로 늘려야 했음
그래서 Rust 코드에서 컴파일 타임 검사를 추가해, async 함수 내에서 연결을 들고 있는 상태로
.await를 호출하면 컴파일러가 바로 경고하도록 함100곳 넘게 수정했지만, 덕분에 이제는 10,000개 연결 대신 32개 풀로 부하 테스트를 돌려도 느려지지 않음
단순히 idle timeout을 줄이는 것도 방법이지만, 정적 검사가 훨씬 확실한 해결책이었음
글이 너무 피상적이고 “우린 샤딩했어요!” 같은 키워드만 반복함
세부 내용은 거의 없고, SEO용 문장처럼 느껴졌음
글의 요지는 “단일 writer는 확장되지 않으니, 쓰기를 줄이고 읽기를 분리했다” 정도로 요약됨
새로운 내용은 거의 없고, 쿼리 최적화·샤딩·리드 리플리카 같은 흔한 접근만 언급했음
내가 Postgres를 좋아하는 이유는, 단순히 CPU와 디스크를 늘리는 것만으로도 꽤 큰 규모까지 버틸 수 있기 때문임
그 시점이 되면 샤딩 전문가를 고용할 여유도 생김
그래서 “샤딩하려면 Postgres를 떠나야 한다”는 말은 좀 이상하게 들림
예를 들어 OpenAI는 지금도 막대한 적자를 내고 있고, 2027년까지 버틸 수 있을지도 불확실하다는 뉴스가 있음
스키마 변경과 타임아웃에 대해, 단순히 타임아웃 설정만이 아니라
스키마 롤아웃 중에 충돌하는 트랜잭션을 자동으로 종료하는 스크립트를 병행 실행하면 훨씬 효율적임
Postgres가 이런 기능을 기본 제공하면 좋겠음 — 무거운 락이 걸려 대기하는 것보다, 일부 트랜잭션을 취소하는 편이 낫기 때문임
OpenAI Engineering 블로그의 첫 글이라 흥미로웠음
앞으로 더 많은 사례를 보고 싶음
복제 설정이 궁금했음
50개의 리드 리플리카를 두고도 복제 지연이 거의 없었다고 하는데,
실제로는 CPU나 메모리 스파이크로 일부 리플리카가 지연될 가능성이 높음
그럴 경우 WAL 전송 대기로 인해 프라이머리도 느려질 수 있음
“새 기능이 추가 테이블을 필요로 하면 PostgreSQL이 아닌 Azure CosmosDB에 넣는다”는 부분이 있었음
즉, 기존 시스템은 유지하고 새로운 기능만 다른 DB로 옮기는 식으로 보였음
“인스턴스 크기를 늘렸다”고 했는데, 그 수준이 궁금했음
어떤 CPU·RAM을 쓰는지, 일반 사용자와 같은 인스턴스인지, 아니면 맞춤형 하드웨어인지 알고 싶었음
예: Azure Standard_E192ibds_v6 (96코어, 1.8TB RAM, 10TB SSD, 3M IOPS)
더 큰 건 SAP HANA용으로 896코어, 32TB 메모리, 185Gbps 네트워크를 제공하는 Standard_M896ixds_24_v3 같은 모델임
이런 건 월 약 17만5천 달러 수준이지만, OpenAI는 아마 대폭 할인을 받았을 것임
개인적으로는 HPC용 HX176rs VM을 DB 서버로 쓰는 걸 선호함
HBM 캐시 덕분에 메모리 처리량이 훨씬 높고, 비슷한 가격대의 일반 VM보다 성능이 훨씬 좋았음
Azure PostgreSQL과 CosmosDB를 함께 쓰는 건 비용이 엄청날 것임
그래도 이번 글은 “PostgreSQL을 확장한 실제 사례” 중 가장 현실적인 편이었음
커널 수정이나 소스코드 해킹 없이, 표준 클라우드 환경에서 운영하는 접근이라 공감이 갔음