▲

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

 (openai.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 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 또는 대체 분산 시스템 도입 가능성 검토 중
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 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을 확장한 실제 사례” 중 가장 현실적인 편이었음
    커널 수정이나 소스코드 해킹 없이, 표준 클라우드 환경에서 운영하는 접근이라 공감이 갔음

답변달기