PostgreSQL 하나로 수억 명? OpenAI의 초대형 확장 전략 완전 해부

https://www.pixelstech.net/article/1747708863-openai%3a-scaling-postgresql-to-the-next-level

PostgreSQL 하나로 수억 명의 사용자 트래픽을 처리한다는 말, 믿기 어렵죠? 하지만 OpenAI는 이걸 해냈습니다. 샤딩 없이도 단일 PostgreSQL 클러스터로 100만 QPS를 감당하고, 40개가 넘는 복제본을 활용해 안정성과 성능을 모두 확보했습니다.

이 글에서는 OpenAI가 PostgreSQL을 어떻게 확장했는지, 어떤 한계를 마주했고, 이를 어떻게 극복했는지 구체적인 사례를 통해 살펴봅니다. 단순한 기술 나열이 아니라 실제 운영에서 부딪히는 문제와 해결 방식, 그리고 얻은 교훈까지 담았습니다.

PostgreSQL의 확장성과 안정성에 대한 믿음을 다시 갖고 싶은 분, 대규모 트래픽을 다뤄야 하는 실무자에게 실용적인 인사이트가 될 것입니다.

반응형

---

OpenAI와 PostgreSQL, 왜 중요한가

OpenAI는 자사 핵심 서비스 대부분을 PostgreSQL에 의존하고 있습니다. ChatGPT를 비롯한 수많은 서비스가 여기에 연결돼 있고, 하나의 장애가 전체 서비스 중단으로 이어질 수 있습니다.

과거에도 실제로 PostgreSQL 문제로 인해 서비스가 중단된 경험이 있습니다. 이 때문에 OpenAI는 안정성과 확장성 확보를 가장 중요한 목표로 설정했습니다.

현재 OpenAI는 Azure의 관리형 PostgreSQL 환경에서 단일 Primary와 40개 이상의 Replicas를 운영하며, 월간 5억 명에 달하는 사용자 요청을 처리하고 있습니다.

---

PostgreSQL 확장의 구조적 한계

PostgreSQL은 전통적으로 단일 Primary 구조를 기반으로 하며, 이는 쓰기 병목이라는 구조적 한계를 내포합니다.

대표적인 한계는 다음과 같습니다.

• 쓰기 요청 병목: 모든 쓰기 요청은 Primary에 집중되며, 이는 확장의 가장 큰 장애물입니다.
• MVCC 문제: 다중 버전 동시성 제어 구조로 인해 테이블 및 인덱스가 팽창하고, 가비지 컬렉션이 복잡해집니다.
• WAL 부하: Write-Ahead Logging으로 인해 Replica 수가 증가하면 네트워크 대역폭이 병목이 되기도 합니다.
• 긴 트랜잭션 문제: 장기 트랜잭션이 시스템 자원을 과도하게 점유해 전체 퍼포먼스에 악영향을 줍니다.

---

OpenAI의 대응 전략

OpenAI는 단순히 성능을 높이는 것이 아니라, 구조적인 쓰기 병목과 관리 문제를 해결하기 위한 다양한 전략을 적용했습니다.

1. 쓰기 오프로딩

• 가능한 모든 쓰기 요청을 오프로딩해 Primary 부담을 줄였습니다.
• Lazy Write를 적용하고, 데이터 백필 주기를 조정해 실시간 처리를 지연시키는 방식으로 병목을 완화했습니다.

2. 읽기 부하 분산

• 읽기 트래픽은 최대한 Replicas로 분산했고, 반드시 Primary에서 처리해야 할 경우에도 높은 효율성을 확보했습니다.
• 고우선 요청은 전용 Replica에서 처리하도록 분리했습니다.

3. 쿼리 최적화

• 세션, 쿼리, 클라이언트별 Timeout 설정을 통해 장기 점유를 방지했습니다.
• ORM 사용을 최소화하고, 복잡한 multi-join 쿼리를 최적화했습니다.
• Idle in transaction 세션을 제한해 가비지 컬렉션 지연을 예방했습니다.

---

장애 대응 및 스키마 관리

장애 대응 전략

• 단일 Primary 장애 시 쓰기 불가 상황에 대비해 고가용성 아키텍처를 유지하고 있습니다.
• 일부 Replica 장애에도 읽기 요청은 중단되지 않도록 설계됐습니다.
• 최근 9개월간 PostgreSQL 관련 SEV0 장애는 단 1건만 발생했습니다.

스키마 변경 제한

• 신규 테이블 생성, 컬럼 추가/삭제는 5초 이내의 경량 작업만 허용됩니다.
• 인덱스는 CONCURRENTLY 옵션으로만 생성/삭제 가능하며, 전체 테이블 재작성은 금지됩니다.
• 장기 쿼리가 스키마 변경을 블로킹하지 않도록 애플리케이션에서 쿼리를 오프로딩하거나 최적화합니다.

---

운영 도구와 모니터링 체계

OpenAI는 PostgreSQL을 운영하면서 다양한 도구를 함께 활용하고 있습니다.

• PgBouncer: 커넥션 풀링으로 DB 연결 수를 효율적으로 관리합니다.
• Datadog: 성능 모니터링, 장애 탐지에 사용되며, 비용과 리소스 부담이 있다는 단점도 존재합니다.
• Azure PostgreSQL 관리형 기능: 제한적이지만 안정성 있는 환경을 제공합니다.

관측성 확보를 위해 latency 분위수 지표(p95, p99)를 요청했으며, 실제로는 pg_stat_monitor, eBPF 등 우회적인 방법을 사용합니다.

---

PostgreSQL 커뮤니티에 제안된 개선점

OpenAI는 실전 경험을 바탕으로 PostgreSQL 커뮤니티에 여러 가지 기능 개선을 제안했습니다.

• 인덱스 관리 개선: 불필요한 인덱스를 안전하게 비활성화할 수 있도록 disable 기능 요청
• 관측성 향상: latency 기반 분위수 히스토그램 지원
• 스키마 변경 이력 저장: DDL 변경 내역을 시스템 뷰/테이블에 기록할 수 있는 기능
• 모니터링 뷰 명확화: ClientRead 상태 지속 현상에 대한 분석 및 대응
• 기본 파라미터 최적화: 보수적인 기본값을 더 나은 휴리스틱 기반 값으로 개선 요청

---

728x90

OpenAI의 사례는 PostgreSQL이 단순한 중소형 데이터베이스에 그치지 않고, 수억 명을 상대하는 대규모 시스템에도 충분히 사용될 수 있음을 보여줍니다.

중요한 건 단지 PostgreSQL 자체가 아니라, 그 위에 쌓은 운영 전략과 실천력입니다.

샤딩 없이도, 복잡한 분산 DB 없이도 PostgreSQL 하나로 100만 QPS를 처리할 수 있는 구조를 만든다는 것은 누구에게나 도전해볼 만한 과제입니다.

당신이 PostgreSQL의 확장성에 대해 고민 중이라면, 이 글이 실마리가 될 수 있습니다.

지금 당신의 PostgreSQL은 얼마나 확장 가능할까요?

https://www.pixelstech.net/article/1747708863-openai%3a-scaling-postgresql-to-the-next-level

OpenAI: Scaling PostgreSQL to the Next Level | PixelsTech