OpenAI, 단일 PostgreSQL로 8억 사용자까지 확장한 비결

핵심 요약

OpenAI는 오픈소스 관계형 데이터베이스를 기반으로 ChatGPT와 API 플랫폼을 8억 명 규모로 운영하며, 단일 주서버가 모든 쓰기를 처리하고 약 50개의 지역 분산 읽기 복제가 조회를 담당한다. 수백만 QPS를 소화하면서 p99 지연을 낮은 두 자릿수 밀리초로 유지하고, 99.999% 가용성을 달성했다. 핵심 교훈은 유행하는 인프라나 막연한 규모 공포가 아니라 실제 워크로드 패턴과 운영 제약에 맞춰 아키텍처를 결정하라는 것이다.

OpenAI의 데이터베이스 아키텍처

단일 쓰기 + 전역 읽기 복제

모든 쓰기는 한 대의 Azure PostgreSQL Flexible Server가 처리하고, 읽기는 여러 지역에 배치된 약 50개의 리드 레플리카가 담당한다. 이 구성은 단일 작성자 병목을 관리 가능한 형태로 유지하면서도 전 세계 트래픽에 낮은 지연으로 응답할 수 있게 한다.

성능과 가용성 지표

시스템은 수백만 건의 초당 쿼리를 처리하며 p99 지연을 낮은 두 자릿수 ms로 유지한다. 또한 다중 지역 읽기 분산과 엄격한 운용 규율을 통해 99.999% 가용성을 달성했다.

왜 PostgreSQL인가

서비스 특성상 읽기 비중이 매우 높아 이 엔진이 적합했다. 반면 MVCC 특성상 쓰기 부하가 커지면 행 전체 복사로 인한 쓰기 증폭과 다중 버전 스캔 비용이 커진다. OpenAI는 이 한계를 억지로 극복하기보다, 어떤 워크로드를 이곳에 남기고 어떤 워크로드를 다른 저장소로 옮길지 명확한 기준을 세워 운영한다.

핵심 최적화와 운영 전략

연결 풀링과 캐시 락

연결 풀링으로 연결 시간을 50ms에서 5ms로 낮췄고, 캐시 미스로 인해 동일한 쿼리가 폭주하는 ‘번떼 효과(thundering herd)’를 막기 위해 캐시 락을 도입했다. 이를 통해 급격한 트래픽 스파이크에도 핵심 데이터베이스의 안정성을 확보했다.

하이브리드 데이터 전략

핵심 원칙은 “새 테이블은 더 이상 PostgreSQL에 만들지 않는다”이다. 신규 워크로드는 기본적으로 Azure Cosmos DB 같은 샤딩 가능한 시스템을 사용하고, 수평 분할이 가능한 기존의 쓰기 중심 워크로드는 점진적으로 이관한다. 반대로 읽기 중심이거나 이행 비용이 큰 항목은 공격적으로 최적화해 현행 시스템에 남긴다. 이는 초기부터 CockroachDB·YugabyteDB 같은 분산 SQL로 전환하거나 전면 샤딩을 택할 때 수반되는 복잡성(샤드 라우팅, 분산 트랜잭션, 운영 부담)을 피하면서 실질적 확장을 달성하는 방법이다.

다층 방어와 격리

애플리케이션·프록시·쿼리 레벨에서 레이트 리밋을 적용하고, 우선순위가 낮은 트래픽과 높은 트래픽을 인스턴스 차원에서 격리해 신규 기능의 비효율이 핵심 서비스에 악영향을 주지 않도록 했다.

ORM SQL 점검

Django·SQLAlchemy·Hibernate 같은 ORM이 생성하는 쿼리를 프로덕션에서 지속적으로 검토한다. 실제로 12개 테이블을 조인하는 ORM 생성 쿼리 하나가 트래픽 급증 시 다수의 중대 장애를 유발한 사례가 있었기에, 자동 생성 SQL에 대한 상시 모니터링을 표준 절차로 삼았다.

엄격한 변경 관리

전체 테이블 재작성(Rewrite)을 유발하는 변경은 금지하고, 스키마 변경에는 5초 타임아웃을 걸었다. 장기 실행 쿼리는 자동 종료해 유지보수 작업을 막지 않으며, 백필은 1주 이상 걸릴 정도로 강력한 레이트 리밋을 적용해 기본 부하를 보호한다.

기업을 위한 시사점

읽기 위주에 간헐적 쓰기 급증이 있는 워크로드는 단일-프라이머리 PostgreSQL로 예상보다 오래 버틸 수 있다. 샤딩 여부는 사용자 수가 아니라 워크로드 패턴과 운영 제약으로 결정해야 한다. 특히 트래픽 변동성이 큰 AI 애플리케이션에서 유효하며, 핵심은 병목을 정확히 찾아 검증된 인프라는 최대한 최적화하고, 필요한 부분만 선별적으로 이전하는 것이다.