OpenAI, 8억 명의 ChatGPT 사용자를 위한 PostgreSQL 스케일링 비법 공개
AIOpenAIPostgreSQL인프라데이터베이스
안녕하세요, Tom입니다.
오늘은 OpenAI의 PostgreSQL 스케일링 이야기를 들고 왔어요. ChatGPT의 8억 사용자를 지원하기 위해 PostgreSQL을 초당 수백만 건의 쿼리(QPS)까지 확장한 엔지니어링 노하우를 공개했거든요. 이건 정말 실전에서 쓸 수 있는 인사이트라서 꼭 공유드리고 싶었습니다.
핵심 아키텍처
OpenAI의 PostgreSQL 구성은 이렇습니다:
- 단일 프라이머리 Azure PostgreSQL Flexible Server 인스턴스
- 약 50개의 읽기 레플리카 (전 세계 다중 리전 분산)
- 지난 1년간 10배 이상의 부하 증가에도 안정적 운영
💡 놀라운 점: 단일 프라이머리로 8억 사용자를 지원한다는 게 정말 대단합니다.
주요 확장 전략
1. 프라이머리 부하 최소화
읽기 트래픽 → 레플리카로 오프로드
쓰기 집약 워크로드 → Azure CosmosDB로 마이그레이션
- 샤딩 가능한 쓰기 워크로드는 CosmosDB 등 샤드 시스템으로 이전
- 불필요한 쓰기 제거 및 지연 쓰기(lazy writes) 도입
- 새 테이블은 PostgreSQL에 추가 금지 → 샤드 시스템에 생성
🎯 핵심: 프라이머리는 최소한의 쓰기만 처리하도록 설계
2. 쿼리 최적화
| 문제 | 해결책 |
|---|---|
| 12개 테이블 조인 쿼리 | 쿼리 분해 → 애플리케이션 레이어에서 조인 |
| ORM 생성 비효율 쿼리 | SQL 직접 검토 및 최적화 |
| 장시간 유휴 쿼리 | idle_in_transaction_session_timeout 설정 |
⚠️ 교훈: ORM이 생성하는 쿼리를 믿지 마세요. 복잡한 쿼리는 직접 SQL로 최적화해야 합니다.
3. 단일 장애점(SPOF) 완화
- High-Availability 모드: 핫 스탠바이로 빠른 페일오버
- 읽기 전용 요청은 프라이머리 다운시에도 레플리카에서 처리
- 리전당 충분한 레플리카 배치로 개별 레플리카 장애 대응
제가 배운 점
1. 단일 프라이머리도 충분할 수 있다
샤딩이 무조건 정답은 아닙니다. OpenAI는 단일 프라이머리 + 50개 레플리카로 8억 사용자를 지원합니다. 쓰기 워크로드만 잘 분리하면 됩니다.
2. 쿼리 최적화가 핵심
12개 테이블 조인을 애플리케이션 레이어로 분해한 것처럼, 쿼리를 단순화하는 게 중요합니다.
3. 모니터링과 자동화
OpenAI는 자체 개발한 도구로 쿼리 패턴을 분석하고 자동으로 최적화합니다. 이 부분은 우리도 적용해볼 수 있을 것 같아요.
언제 적용하면 좋을까요?
💰 추천 시나리오:
- 읽기 트래픽이 쓰기보다 훨씬 많은 경우
- 글로벌 서비스로 다중 리전 배포가 필요한 경우
- PostgreSQL에 익숙하고 샤딩은 부담스러운 경우
비추천:
- 쓰기 트래픽이 읽기보다 많은 경우
- 실시간 데이터 일관성이 절대적으로 중요한 경우
마무리
OpenAI의 PostgreSQL 스케일링 전략은 "단순함의 미학"을 보여줍니다. 복잡한 샤딩 대신 레플리카와 쿼리 최적화로 문제를 해결했죠.
우리도 PostgreSQL을 쓰고 있다면, OpenAI의 전략을 참고해보세요. 생각보다 단순한 방법으로 큰 성과를 낼 수 있습니다.