PostgreSQL을 확장하여 8억 명의 ChatGPT 사용자에게 전력 공급
OpenAI는 PostgreSQL을 확장해 8억 명의 사용자와 초당 수백만 건의 쿼리를 지원했으며, 단일‑프라이머리 아키텍처가 철저한 엔지니어링 최적화와 결합될 때 대규모 읽기‑중심 워크로드를 안정적으로 처리할 수 있음을 입증했습니다. 단일 Azure PostgreSQL flexible server 인스턴스를 프라이머리로 사용하고 전 세계 여러 지역에 걸쳐 거의 50개의 읽기 복제본을 배포함으로써 OpenAI는 두 자릿수 밀리초 수준의 p99 클라이언트‑측 지연 시간과 “다섯 9” 가용성을 유지하고 있습니다.
단일 프라이머리 제한 극복
단일‑프라이머리 아키텍처는 읽기‑중심 트래픽에 효율적이지만, 쓰기 작업에 병목을 만들고 단일 장애 지점을 초래할 수 있습니다. OpenAI는 다음 전략을 통해 이러한 문제를 해결했습니다:
쓰기 부하 완화
쓰기 급증 시 프라이머리 인스턴스가 과부하되지 않도록, OpenAI는 샤드 가능한 쓰기‑중심 워크로드를 Azure Cosmos DB와 같은 샤드 시스템으로 이전했습니다. 이제 기존 PostgreSQL 배포에 새로운 테이블을 추가하는 것을 금지하고, 모든 신규 워크로드를 샤드 시스템에 기본 배치합니다. 또한 중복 쓰기를 수정하고 지연 쓰기(lazy writes)를 도입하는 등 애플리케이션‑레벨 최적화를 적용해 트래픽 급증을 완화했습니다.
고가용성 및 장애 완화
프라이머리를 완전한 단일 장애 지점으로 만들지 않기 위해, OpenAI는 중요한 읽기 쿼리를 복제본으로 오프로드했습니다. 이를 통해 프라이머리 인스턴스가 장애가 발생해도 읽기 전용 요청은 계속 제공됩니다. 완전 복구를 위해 프라이머리는 고가용성(HA) 모드에서 핫 스탠바이와 함께 실행되며, 동기화된 복제본이 즉시 승격되어 다운타임을 최소화합니다.
고 QPS를 위한 기술 최적화
OpenAI는 PostgreSQL이 자원 고갈 및 성능 저하에 빠지지 않도록 여러 아키텍처 레이어를 구현했습니다.
연결 풀링 및 지연 시간
PgBouncer를 프록시 레이어로 사용해 statement 또는 transaction 풀링 모드로 전환함으로써, 활성 클라이언트 연결 수를 줄이고 평균 연결 시간을 50 ms에서 5 ms로 낮췄습니다. 네트워크 오버헤드를 최소화하기 위해 PgBouncer 포드는 클라이언트와 복제본이 같은 지역에 배치되었습니다.
캐싱 및 "Cache-Miss Storms"
캐시 미스로 인한 급격한 읽기 트래픽 급증을 방지하기 위해 OpenAI는 캐시 락(lease) 메커니즘을 도입했습니다. 특정 누락 키를 가져오는 첫 번째 리더만 PostgreSQL에 질의해 캐시를 재생성하도록 하고, 동일 키에 대한 다른 동시 요청은 데이터베이스를 동시에 공격하지 않도록 대기하게 합니다.
쿼리 및 스키마 관리
OpenAI는 복잡한 다중 테이블 조인을 피하는 등 OLTP 안티패턴을 방지하도록 쿼리를 최적화합니다. 한 사례에서는 12개 테이블을 조인하는 쿼리가 고심각도 사고의 원인으로 밝혀졌으며, 팀은 이제 복잡한 조인 로직을 애플리케이션 레이어로 이동하고 idle_in_transaction_session_timeout을 사용해 오래 실행되는 유휴 쿼리가 autovacuum을 방해하지 않도록 합니다.
스키마 변경은 엄격히 통제됩니다: 전체 테이블 재작성 없이 수행 가능한 가벼운 작업만 허용되며, 모든 스키마 변경에 5초 타임아웃을 강제합니다.
읽기 복제본 확장 및 워크로드 격리
전 세계적인 성능을 유지하기 위해 OpenAI는 거의 50개의 읽기 복제본을 운영합니다. 그러나 프라이머리는 모든 복제본에 Write Ahead Log(WAL) 데이터를 스트리밍해야 하므로, 복제본 수를 더 늘리면 결국 프라이머리의 CPU와 네트워크 대역폭이 포화될 수 있습니다.
계단식 복제
OpenAI는 Azure PostgreSQL 팀과 협력해 중간 복제본이 WAL 데이터를 하위 복제본에 전달하는 계단식 복제를 구현하고 있습니다. 이를 통해 프라이머리 인스턴스를 과부하시키지 않고 100개 이상의 복제본으로 확장하는 것이 목표입니다.
워크로드 격리
"소음이 심한 이웃" 문제를 방지하기 위해 OpenAI는 요청을 저우선순위와 고우선순위 계층으로 나누어 별도 인스턴스로 라우팅합니다. 이를 통해 리소스를 많이 소모하는 저우선순위 요청이 핵심 고우선순위 기능의 성능을 저하시키는 일을 방지합니다.
성능 결과
이러한 최적화를 통해 OpenAI는 다음과 같은 프로덕션 지표를 달성했습니다:
- 가용성: 다섯 9(99.999%) 가용성.
- 지연 시간: 두 자릿수 밀리초 수준의 p99 클라이언트‑측 지연 시간.
- 신뢰성: 지난 12개월 동안 SEV‑0 PostgreSQL 사고는 단 한 건뿐이며, 이는 ChatGPT ImageGen 출시 시 쓰기 트래픽이 10배 이상 급증했을 때 발생했습니다.