# ChatGPT 8억 명을 지원하기 위한 PostgreSQL 확장

> Clean Markdown view of GeekNews topic #26077. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26077](https://news.hada.io/topic?id=26077)
- GeekNews Markdown: [https://news.hada.io/topic/26077.md](https://news.hada.io/topic/26077.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-24T07:32:59+09:00
- Updated: 2026-01-24T07:32:59+09:00
- Original source: [openai.com](https://openai.com/index/scaling-postgresql/)
- Points: 2
- Comments: 1

## Topic Body

- OpenAI는 **ChatGPT와 API 트래픽 급증**에 대응하기 위해 PostgreSQL 인프라를 대규모로 확장, 단일 **Azure PostgreSQL 플렉서블 서버**와 약 50개의 리드 리플리카로 수백만 QPS를 처리  
- **읽기 중심 워크로드**에 최적화된 구조를 유지하면서, 쓰기 부하 완화를 위해 **Azure Cosmos DB**로 일부 워크로드를 마이그레이션  
- **PgBouncer 연결 풀링**, **캐시 락킹**, **레이트 리미팅**, **워크로드 격리** 등 다양한 최적화로 안정성과 지연 시간 개선  
- **단일 프라이머리 구조의 한계**를 극복하기 위해 고가용성(HA) 구성과 **핫 스탠바이**, **계단식 복제(cascading replication)** 테스트를 병행  
- 이 접근으로 **99.999% 가용성**과 **두 자릿수 밀리초 수준의 p99 지연 시간**을 달성, 향후 **샤딩 PostgreSQL**이나 분산 시스템으로의 확장 가능성 확보  

---

### PostgreSQL 확장 개요
- PostgreSQL은 ChatGPT와 OpenAI API의 핵심 데이터 시스템으로, 지난 1년간 **부하가 10배 이상 증가**  
  - 단일 프라이머리 인스턴스와 전 세계에 분산된 약 50개의 리드 리플리카로 **8억 명 사용자**의 요청 처리  
- 읽기 중심 구조를 유지하면서 **쓰기 부하 완화**를 위해 일부 워크로드를 **Azure Cosmos DB**로 이전  
- 새로운 테이블 추가는 금지하고, 신규 워크로드는 기본적으로 샤딩 시스템에 배치  

### 단일 프라이머리 구조의 과제와 대응
- 단일 작성자 구조는 **쓰기 확장성 한계**와 **단일 장애점(SPOF)** 문제를 가짐  
  - 읽기 트래픽은 리플리카로 분산, 쓰기 트래픽은 샤딩 가능한 워크로드를 Cosmos DB로 이전  
  - **핫 스탠바이**를 통한 고가용성 구성으로 장애 시 빠른 승격(failover) 지원  
- **읽기 부하 급증** 시 캐시 미스 폭주로 인한 CPU 포화 문제 발생  
  - 캐시 락킹 메커니즘을 도입해 동일 키에 대한 중복 쿼리 방지  

### 쿼리 및 리소스 최적화
- **복잡한 다중 조인 쿼리**가 CPU를 과도하게 점유해 서비스 지연을 유발  
  - ORM이 생성한 비효율적 SQL을 검토하고, 복잡한 조인 로직은 애플리케이션 계층으로 이동  
  - **idle_in_transaction_session_timeout** 설정으로 장기 유휴 쿼리 방지  
- **“Noisy neighbor” 문제** 해결을 위해 트래픽을 **우선순위별 인스턴스**로 분리  
  - 저우선순위 요청이 고우선순위 서비스에 영향을 주지 않도록 격리  

### 연결 관리 및 부하 제어
- Azure PostgreSQL의 **5,000개 연결 제한** 문제를 해결하기 위해 **PgBouncer**를 프록시 계층으로 도입  
  - 연결 재사용으로 평균 연결 시간 **50ms → 5ms**로 단축  
  - 지역 간 네트워크 지연을 줄이기 위해 프록시·클라이언트·리플리카를 동일 리전에 배치  
- **레이트 리미팅**을 애플리케이션, 프록시, 쿼리 레벨에 적용해 급격한 트래픽 폭주 방지  
  - ORM 계층에서도 특정 쿼리 다이제스트를 차단할 수 있도록 개선  

### 복제 및 스키마 변경 관리
- 프라이머리가 모든 리플리카에 **WAL 로그를 스트리밍**해야 하므로, 리플리카 수 증가 시 네트워크 부하 상승  
  - **계단식 복제(cascading replication)** 를 Azure 팀과 협력해 테스트 중  
  - 중간 리플리카가 하위 리플리카로 WAL을 전달해 **100개 이상 리플리카 확장 가능성** 확보  
- **전체 테이블 재작성(full table rewrite)** 을 유발하는 스키마 변경은 금지  
  - 5초 타임아웃 내에서 가벼운 변경만 허용, 인덱스 생성·삭제는 동시 수행 가능  
  - 백필(backfill) 시에도 엄격한 속도 제한 적용  

### 성과 및 향후 계획
- PostgreSQL은 **수백만 QPS**를 처리하며, **지연 시간 수십 밀리초(p99)** , **가용성 99.999%** 달성  
  - 지난 12개월간 SEV-0 사고는 단 한 건(ChatGPT ImageGen 출시 시 발생)  
- 남은 쓰기 중심 워크로드도 단계적으로 **Cosmos DB로 이전 중**  
- **계단식 복제** 완성 후 리플리카 확장성과 안정성 강화 예정  
- 향후 **샤딩 PostgreSQL** 또는 **대체 분산 시스템** 도입 가능성 검토 중

## Comments



### Comment 49833

- Author: neo
- Created: 2026-01-24T07:32:59+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46725300) 
- 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](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/memory-optimized/mdsv3-vhm-series?tabs=sizebasic) 같은 모델임  
    이런 건 월 약 17만5천 달러 수준이지만, OpenAI는 아마 **대폭 할인**을 받았을 것임  
    개인적으로는 HPC용 [HX176rs](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/high-performance-compute/hx-series?tabs=sizebasic) VM을 DB 서버로 쓰는 걸 선호함  
    HBM 캐시 덕분에 **메모리 처리량**이 훨씬 높고, 비슷한 가격대의 일반 VM보다 성능이 훨씬 좋았음

- Azure PostgreSQL과 CosmosDB를 함께 쓰는 건 **비용이 엄청날 것**임  
  그래도 이번 글은 “PostgreSQL을 확장한 실제 사례” 중 가장 현실적인 편이었음  
  커널 수정이나 소스코드 해킹 없이, **표준 클라우드 환경**에서 운영하는 접근이라 공감이 갔음