OpenAI, 샤딩 없이 PostgreSQL로 100만 QPS 달성 및 확장 전략 분석

핵심 기술: OpenAI는 샤딩 없이 PostgreSQL을 사용하여 수억 명의 사용자 트래픽을 처리하는 방법을 PGConf.dev 2025에서 공유했으며, 쓰기 병목 해결, MVCC 한계 극복, WAL 트래픽 관리, 쿼리 최적화 등 극한 환경에서의 PostgreSQL 운영 노하우를 상세히 공개했습니다.

기술적 세부사항:
* 아키텍처: Azure 관리형 PostgreSQL 기반의 단일 Primary + 40개 이상 Replica 구성
* 트래픽 처리: 최대 100만 QPS (읽기+쓰기) 달성
* 쓰기 병목 해결: 쓰기 분산, 애플리케이션 레벨 오프로딩, 불필요한 쓰기 방지
* 읽기 부하 분산: 다수의 Replica 활용, 지리적으로 분산된 Replica 배치
* PostgreSQL 한계 및 극복:
* MVCC로 인한 테이블/인덱스 팽창: 쿼리 최적화, 긴 트랜잭션 제한, ORM 최소화
* WAL 트래픽 급증: 복제 지연 완화 전략 필요
* 고가용성: 장애 시에도 높은 가용성 보장 (9개월 간 SEV0 장애 1건)
* 스키마 변경: CONCURRENTLY 옵션 사용, 5초 이내 경량 작업만 허용
* 운영 도구: Azure 관리형 PostgreSQL, Kubernetes + PgBouncer, Datadog 모니터링
* 요구사항: 인덱스 비활성화 기능, latency 기반 지표 제공, 스키마 변경 이력 저장, 모니터링 뷰 의미 명확화, 기본 파라미터 최적화

개발 임팩트:
* 샤딩 없이도 PostgreSQL로 고성능, 고가용성 시스템 구축 가능성을 제시합니다.
* 대규모 서비스 환경에서 발생하는 실제적인 PostgreSQL 운영 난제와 해결 방안을 학습할 수 있습니다.
* 하드웨어 성능 향상에 따라 단일 PostgreSQL 클러스터로도 공격적인 확장이 가능함을 시사합니다.

커뮤니티 반응:
* 해당 발표가 PGConf에서 가장 많은 호응을 얻은 세션 중 하나였으며, 제품 성장 시 스택 확장 전략의 중요성을 보여주는 사례로 평가받았습니다.
* PostgreSQL 커뮤니티의 친절하고 열린 분위기가 돋보였으며, 코어 개발자들이 사용자 사례를 배우고자 하는 질문이 많았습니다.
* 일부 의견은 OpenAI의 대규모 인프라 운영 경험 부족을 지적하며 ORM 사용의 위험성을 강조했으나, 다른 의견은 오픈소스 커뮤니티의 발전과 다양한 DB 운영 방안에 대한 긍정적인 토론을 이끌었습니다.
* 샤딩을 사용하지 않는 이유에 대한 명확한 설명 부족은 답답하다는 지적이 있었으나, OpenAI 측은 워크로드 샤딩의 복잡성과 현재 Azure PostgreSQL만으로도 충분한 확장성을 확보했다는 답변을 제시했습니다.
* ORM 사용에 대한 찬반 논쟁과 함께 sqlc와 같은 대안이 제시되었습니다.